The workflow infrastructure consists of the workflow runtime for Internet Information Services (IIS) and the workflow runtime for the Application Object Server (AOS). The workflow runtime for IIS consists of Workflow Web Services, Windows Workflow Foundation, and the .NET Business Connector. The workflow runtime for the AOS hosts the X++ workflow services, messaging batch job, and message queue, along with the application code.
Logically, the workflow infrastructure is an extension of Microsoft Dynamics AX and is transparent to the Microsoft Dynamics AX end-users. Physically, the workflow runtime is hosted by IIS and the AOS, and as a result, a peer-to-peer communication service is required. The AOS workflow services and the messaging batch job are the cornerstones of a proprietary message exchange service (peer-to-peer communications service) between IIS and AOS workflow runtimes.
The following diagram provides the high-level architecture of the workflow infrastructure.
Any component that can invoke the X++ code can start a workflow process. The Microsoft Dynamics AX application provides workflow forms and controls for the Windows client and Enterprise Portal that users can use to participate in business processes. In addition, batch jobs can also call the workflow service. Let's assume that a user has started the workflow by submitting an expense report for approval. The following table tracks the steps that take place in the workflow process:
|
Step # |
Server |
Activity |
|---|---|---|
|
1 |
AOS |
X++ code calls the workflow service to submit a document to the workflow process. For example, a user submits an expense report for approval which invokes X++ code to submit the document to the workflow process. The workflow service posts a message to the message queue. The messaging batch job reads the message and sends a “workflow activation” request to the IIS workflow runtime. The messaging batch job reads the message queue at one-minute intervals. |
|
2 |
IIS |
The workflow Web service receives this message and the IIS workflow runtime starts a new workflow instance via Windows Workflow Foundation. This workflow instance performs a call back to the AOS via the .NET Business Connector to post a message that the workflow has started. The instance will keep running for as long as it needs to communicate with the AOS. After posting the message, the IIS workflow runtime saves the idle workflow instance to the Microsoft Dynamics AX database and removes it from volatile memory. When the runtime receives another message from the AOS for this workflow instance, it restores the workflow instance to volatile memory. Each workflow instance is unique. If you have two users submitting expense reports for approval, two workflow instances are started. |
|
3 |
AOS |
The messaging batch job will read the “workflow started” message from the message queue and invoke the code to process a “workflow started” event. It then posts a notification that the event was processed. |
|
4 |
AOS & IIS |
This same messaging pattern is repeated as necessary throughout the lifecycle of the workflow instance. |
The Workflow system architecture provides for a reliable and durable messaging system to ensure that the state of the workflow instance (in IIS) is always synchronized with the state of the application (in the AOS). If any failures occur, the workflow instance state is returned to its last known save point (in IIS) and the message stays in the queue (in the AOS). Thus, from an architecture perspective, the recovery model is simply to fix the problem and resubmit the message. For workflow installation instructions, see the Installation Guide. For setting up workflow, see the System and Application Setuphelp from the Helpmenu.
