Very few of us would deny the importance or significance of the processes that drive the businesses and organizations that we work for and interact with on a daily basis. Business processes represent the key activities that, when carried out, are meant to achieve a specific goal of value to the business or organization:
- Think of a manufacturing operation in which business process activities include the initiation, design, development, quality assurance testing, and delivery of a saleable (and hopefully profitable) range of goods.
- Think of sales process activities for manufactured items, including marketing, locating prospects, providing quotes, converting quotes to orders and prospects to customers, shipping the product, invoicing, and obtaining payment.
- Finally, think about some of the supporting business processes that are concerned with hiring new employees and managing employee expenses, which contribute to the business or organization in tangible ways.
Enterprise resource planning (ERP) suites, such as Dynamics AX, exist to automate business processes and to provide the capability to adapt these processes to the specific needs of businesses and organizations over time. Before Dynamics AX 2009, no standard workflow infrastructure existed, and each company had to write specific business logic to implement everyday activities, such as approvals. The Dynamics AX 2009 release includes a built-in workflow infrastructure precisely to make it easier for businesses and organizations to automate and manage business processes.
What is the relation between workflow infrastructure in Dynamics AX 2009 and Windows Workflow Foundation which is part of the .NET Framework 3.5?
There is a relationship between the workflow infrastructure in Dynamics AX 2009 and Windows Workflow Foundation, which is part of the .NET Framework 3.5.
Windows Workflow Foundation provides many fundamental capabilities that are used by the workflow infrastructure in Dynamics AX 2009. As a low-level infrastructure component, however, Windows Workflow Foundation has no direct awareness of or integration with 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.
Workflow Runtime Interaction:
Following figure 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.
Workflow Life Cycle:
The workflow life cycle has three phases:
- Design Business users decide what parts of a business process that traverses Dynamics AX 2009 need to be automated and then design a workflow to achieve this automation, leveraging their understanding of the business processes and the organization. They can collaborate with developers in this phase, or they might just communicate the workflow requirements to the developers, who then create the necessary artifacts in Dynamics AX 2009. The artifacts enable the workflow that the business users will later configure.
- Configure After the necessary artifacts are in place, business users configure the workflow in Dynamics AX 2009. If this work is carried out on a test system, after successfully testing the workflow, the administrator deploys the related artifacts and workflow configuration to the live or production system.
- Run Users interact with Dynamics AX 2009 as part of their day-to-day work, and in the course of doing so, might submit workflow documents to the workflow for processing as well as interact with workflows that are already activated.
This cycle is repeated when the workflow that has been designed, configured, and deployed needs to change in some way, for example, because of a change in a business process or in the organization.
