Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Workflow in Dynamics AX 2009 : Workflow Architecture

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
5/14/2013 5:53:11 PM

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.

Figure 1. 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.

Figure 2. 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:

  1. 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.

  2. The message is processed by the messaging batch job, and the request is dispatched to the Workflow Web services on the IIS workflow runtime.

  3. The Workflow Web services process the request and invoke the Windows Workflow Foundation activation API.

  4. 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.

  5. The workflow-started message is then processed by the workflow messaging batch job, which invokes the WorkflowStarted event handler for the corresponding workflow template.

  6. 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.

Figure 4. Logical approval workflow interactions


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.

Figure 5. Logical task workflow interactions


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.

Other -----------------
- SharePoint 2010 : Configuring Search Settings and the User Interface - Search Tabs and Pages
- SharePoint 2010 : Configuring Search Settings and the User Interface - Search Scopes
- SQL Server 2008 R2 : Performance Monitoring Tools (part 12) - Viewing Data Collector Set Results in Performance Monitor
- SQL Server 2008 R2 : Performance Monitoring Tools (part 11) - Creating Data Collector Sets in Performance Monitor
- SQL Server 2008 R2 : Performance Monitoring Tools (part 10) - Creating an Extended Events Session
- SQL Server 2008 R2 : Performance Monitoring Tools (part 9) - Creating an Extended Events Session
- SQL Server 2008 R2 : Performance Monitoring Tools (part 8) - Extended Events Catalog Views and DMVs
- SQL Server 2008 R2 : Performance Monitoring Tools (part 7) - SQL Server Extended Events
- SQL Server 2008 R2 : Performance Monitoring Tools (part 6) - SQL Server Utility
- SQL Server 2008 R2 : Performance Monitoring Tools (part 5) - Creating a Customized Data Collection Set
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server