Workflow in Dynamics AX 2009 : Workflow Architecture

Microsoft designed the workflow infrastructure based on a set of assumptions and goals relating to the functionality it wanted to deliver. Two assumptions were the most significant:

• Business logic (X++) invoked by workflow would always be executed in the Application Object Server (AOS).

• Workflows would be managed by Windows Workflow Foundation in .NET Framework 3.5, which operates in a managed environment.

The first assumption reflects the fact that most business logic resides and is executed in the AOS. The second assumption was based on the opportunity to use existing Microsoft technology for executing workflows in Dynamics AX 2009 instead of designing and implementing this functionality from scratch. The choice, however, required finding a suitable host for Windows Workflow Foundation, because it wasn’t possible to host by using the unmanaged AOS. In the end, Microsoft decided to host Windows Workflow Foundation by using Internet Information Services (IIS 6.0) and to establish a mechanism for communicating back and forth between AOS and IIS. Two workflow runtimes are the result of this decision: one in AOS, and another in IIS.

These primary goals influenced the architecture:

• To create an extensible/pluggable model for workflow integration (including events and providers), because the workflow infrastructure had to be flexible enough to address potentially unknown future requirements.

• To achieve reliable and durable communication between the AOS and IIS runtimes given that they would exist in separate processes.

• To secure communication between the runtimes given that they would be communicating across process boundaries.

• To minimize the performance impact on transactional X++ business logic to invoke workflow runtime services. For example, if workflow activation is triggered from saving a document, no adverse performance side-effects should result for doing this in the same physical transaction (ttsbegin/ttscommit) as the save operation.

• To build in scalability that accommodates the growth in use of workflow in Dynamics AX over time, and to provide options, such as multimachine deployments, to attain such scalability.

In the following section, we expand on the capabilities of each of the workflow runtimes.

AOS and IIS Workflow Runtimes

Figure 1 shows the parts of the AOS workflow runtime.

The AOS runtime includes the following parts:

• Workflow Application Framework A thin API that exposes the underlying workflow functionality to the rest of Dynamics AX 2009.

• Communication Manages the communication to IIS through CLR interop calls to the Web services that are exposed by the IIS workflow runtime. It then exposes the entry points for .NET Business Connector calls back into the AOS workflow runtime from IIS.

• Messaging Manages and processes workflow messages. Messages are processed on the AOS by a server-bound batch job.

• Tracking Manages the tracking information that is stored during workflow execution.

• Work items Manages the work items that are created when tasks and approvals get assigned to individual users.

• Expressions The condition evaluation engine that evaluates the Boolean expressions defined in a workflow configuration. Such Boolean expressions include workflow activation conditions, approval/task autocomplete conditions, approval step preconditions, and hierarchy stop and filter conditions.

• Configuration Manages the workflow configurations that are created using the workflow configuration form or the workflow configuration API.

• Metadata Manages the metadata for the workflow artifacts in the AOT. These artifacts include workflow categories, tasks, approvals, and templates.

Figure 2 shows the IIS workflow runtime.

These are the parts of the IIS workflow runtime:

• Workflow Web services Entry point into the IIS workflow runtime for calls originating from the AOS through workflow message processing.

• Workflow Message and Instance Manager Manages the correlation of incoming messages to running workflow instances and the activation of new workflow instances.

• Workflow activities and services Dynamics AX 2009 extensions, called custom activities, to the activity model in Windows Workflow Foundation. These extensions provide logic tailored to Dynamics AX 2009 and provide the run-time semantics for the workflow elements that are exposed in the workflow configuration (approvals, tasks, subworkflows).

• Windows Workflow Foundation The workflow framework provided in .NET Framework 3.5.

• .NET Business Connector facade Abstracts the workflow runtime away from the AOS. This thin abstraction surfaces a set of services and proxy classes that enable communication from the IIS workflow runtime back into the AOS through .NET Business Connector.

Workflow Runtime Interaction

Figure 3 shows the logical interaction between the IIS and AOS workflow runtimes. Three main elements are involved: the client (which represents both the Dynamics AX 2009 client and Enterprise Portal), the AOS workflow runtime, and the IIS workflow runtime.

Figure 3. Interaction diagram of the workflow infrastructure in Dynamics AX 2009

The IIS workflow runtime consists of the following parts:

• Workflow Web services These act as the interface to the IIS workflow runtime. Web service calls are made from the messaging batch job to the IIS workflow runtime by using these services.

• Windows Workflow Foundation and extensions The core of the IIS runtime is Windows Workflow Foundation and the Dynamics AX 2009 extensions, or custom activities, of the framework.

• .NET Business Connector The Dynamics AX integration component, used in this case to complete the request round-trip back to the AOS runtime.

The AOS workflow runtime consists of the following parts:

• Workflow Application Framework A thin API that exposes the underlying workflow functionality to the rest of the application.

• Workflow runtime services The collective set of workflow subsystems hosted by the AOS to facilitate workflow processing.

• Message queue The workflow runtime in the AOS interacts with the IIS runtime by exchanging messages, and the message queue in the AOS is used to stage workflow messages before being processed by the messaging batch job.

• Application code The X++ code that is invoked by workflow, for example, in event handlers and providers.

• Messaging batch job A server-bound batch job that is dedicated to periodically processing messages in the message queue and sending requests to the IIS workflow runtime.

As an example of how these elements interact at run time, the following list explains what happens when a user clicks Submit to activate workflow processing on a record in Dynamics AX 2009:

This communication metaphor is repeated throughout the life cycle of a given workflow instance for all types of workflow messages.

Logical Approval and Task Workflows

One way to visualize how the key workflow concepts and architecture come together is to look at the interaction patterns of approval and task elements at run time. Four main types of interactions can occur: workflow events, acknowledgments (of events), provider callbacks, and infrastructure callbacks.

• Workflow event A callback to the AOS to post a message, save the workflow instance, and remove/dequeue the originating message. The workflow then waits for the corresponding message to be processed. The AOS processes the message by invoking the event handler on the corresponding workflow template, task, or approval. Then the AOS posts the acknowledgment message.

• Acknowledgment An acknowledgment message responds to every event processed by the AOS. Upon receiving the acknowledgment, the IIS workflow runtime loads the workflow instance from the Dynamics AX database and resumes the instance from where it left off.

• Provider callback A call from the IIS workflow runtime into the AOS workflow runtime to retrieve users or due dates. Workflow providers are integration points for developers to inject custom code for resolving users and due dates. A provider callback is a synchronous call from the IIS workflow runtime back into an X++ workflow provider hosted in the AOS.

• Infrastructure callback A call from the IIS workflow runtime back into the AOS workflow runtime to perform infrastructure-related activities. One example is to create work items for each user returned from a call to a participant provider.

Figure 4 shows the logical workflow interactions for approvals.

In Figure 4, the outermost box represents the workflow itself. Nested inside are the approval (element) and within that, a single step. (An approval can contain multiple steps.) The smaller rectangular boxes represent events or outcomes. The symbols in the legend represent the four interaction types, which are positioned in Figure 9-6 where that type of interaction occurs. When the workflow starts, an event and an acknowledgment occur. Acknowledgments confirm that the AOS workflow runtime received and processed a preceding event initiated in the IIS workflow runtime. The same event and acknowledgment occur for the start of the approval element. When a step starts, there are callbacks for the workflow providers, which are invoked at this point. (Typically, the participant provider is executed to obtain workflow participants, and the due date provider is executed to determine due dates for work items.) The work items are then created via an infrastructure callback, and the workflow waits for the corresponding acknowledgment for each work item that was created. Acknowledgments for work items are triggered when users take action on assigned work items. After the step (or steps) completes, the outcome is determined based on the completion policies of the step, and the corresponding event is raised for that outcome. The workflow then waits for acknowledgment that the AOS processed the outcome’s event. Finally, the completion of the workflow itself raises an event.

The task interactions are similar to approvals, except no steps and outcomes can be unique per task. Figure 5 shows the logical workflow interactions for tasks.

In summary, the logical workflow interaction figures in this section clarify when event handlers fire during the life of a workflow and when a workflow needs to call out to providers.