Workflow Architecture

The workflow infrastructure consists of two components that are hosted on the
AOS: the X++ workflow runtime and the managed workflow runtime.
The X++ workflow runtime consists of:

• Workflow runtime Application Programming Interface (API)

• A messaging batch job

• A message queue

The messaging batch job or the workflow runtime API can invoke the application
code, if it is required. The X++ workflow runtime is compiled into the common
intermediate language (CIL) of the .NET Framework.
The managed workflow runtime consists of the Windows Workflow Foundation
(WWF) and Microsoft Dynamics AX extensions.
Logically, the workflow infrastructure is an extension of Microsoft Dynamics
AX and is transparent to users. Physically, both the X++ workflow and the
managed workflow runtimes are hosted on the AOS. The workflow infrastructure
uses batch processing on the AOS and .NET Interop to integrate both subsystems
and pass messages from one subsystem to another. The X++ code executed in the
batch processor is compiled to .NET CIL. The batch processing runs in the .NET
common language runtime (CLR).

The following diagram provides the high-level architecture of the workflow
infrastructure.



Users can use the workflow forms and controls in the Microsoft Dynamics AX
client and in Enterprise Portal to participate in business processes.
Programmatically, any components that can invoke X++ code can use X++ to
invoke a workflow or submit a document to a workflow. The following table
describes the workflow steps that occur when a user submits an expense report to
the workflow system for approval.

Step	Runtime	Activity
1	X++ Workflow Runtime	A user submits an expense report by clicking theSubmit button on one of the workflow controls. This causes X++ code to activate a workflow instance by calling the workflow runtime API. The workflow runtime API posts a message to the message queue. The messaging batch job reads the message and sends a workflow activation request to the managed workflow runtime.NOTE: The messaging batch job processes the message queue at one-minute intervals.

2	Managed Workflow Runtime	.NET Interop from X++ receives the message and starts a new workflow instance through Windows Workflow Foundation. This workflow instance performs a callback function to the X++ workflow runtime API through .NET Interop to X++ CIL and posts a message that the workflow has started. After posting the message, the managed workflow runtime saves the idle workflow instance to the Microsoft Dynamics AX database. Runtime then removes it from memory. When the managed workflow runtime receives another message from the X++ workflow runtime for this workflow instance, it restores the workflow instance to memory and resumes it. Each workflow instance is unique. If you have two users who submit their expense reports for approval, two workflow instances are started.
3	X++ Workflow Runtime	The messaging batch job reads the “workflow started” message from the message queue and invokes the application event handler to process a “workflow started” event. The batch job then posts an acknowledgement message that the event was processed.
4	Both	This same messaging pattern is repeated as necessary throughout the life cycle of the workflow instance.

The workflow architecture provides for a reliable and durable messaging system.
It makes sure that the state of the workflow is always synchronized with the state
of the application. In case of an unexpected hardware or software failure, the
workflow instance state is returned to its last known save point and the message
stays in the queue. So, from an architecture perspective, the recovery model is to
fix the problem and resume the workflow.

Regards,
Hossein Karimi