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.
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:
The
Submit action invokes the Workflow Application Framework to post an
activation message for the selected workflow configuration. This causes a
message to be inserted into the message queue, the purpose of which is
to instantiate the workflow in the IIS workflow runtime.
The
message is processed by the messaging batch job, and the request is
dispatched to the Workflow Web services on the IIS workflow runtime.
The Workflow Web services process the request and invoke the Windows Workflow Foundation activation API.
After
a workflow instance is activated, a workflow-started message is
dispatched from the IIS workflow runtime to the AOS workflow runtime
using a Dynamics AX 2009 custom activity, which calls through .NET
Business Connector. The state of the workflow instance is persisted to
the Dynamics AX database together with the posting of the
workflow-started message. The activation message is also
removed/dequeued at this time.
The workflow-started message is then processed by the workflow messaging batch job, which invokes the WorkflowStarted event handler for the corresponding workflow template.
After the WorkflowStarted
event handler has been invoked, an acknowledgment message is posted to
the message queue, to be sent back to the IIS workflow runtime to
continue execution of the workflow instance. The workflow-started
message is also removed/dequeued at this time.
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.