Workflow in Dynamics AX 2009 : Workflow Life Cycle (part 1) - State Model

In this section, we describe the workflow life cycle, shown in Figure 1, and explain the design phase of the life cycle in detail.

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.

1. Designing Workflows

As a developer, once you understand the workflow requirements the business user has provided, you must create the corresponding workflow artifacts, dependent workflow artifacts, and business logic. You create all these in the AOT by using the Dynamics AX 2009 client. You write the business logic in X++.

Table 1 lists each workflow artifact and the steps you need to perform when creating it. The artifacts are explicitly listed in order of dependency.

Table 2 identifies the dependent workflow artifacts that are referenced in Table 1.

1.1 State Model

A state model defines a set of states and the transitions that are permitted between the different states for a given record type, along with an initial state and a final state. The reason state models exist is to provide a very prescriptive life cycle for whatever data they are associated to. The current state value is often stored in a field on a record. For example, the PurchReqTable table (the header for a purchase requisition) has a status field that is used to track the approval state of a purchase requisition. The business logic for purchase requisitions has been coded to respect the meaning of each state and the supported state transitions so that a purchase requisition record can’t be converted into a purchase order before the state is approved.

The simplest way to add and manage state on a record is to use a single field on the record to store the current state, but you have to determine what approach makes the most sense. You would then create a static X++ class that implements the state transition business logic. Conceptually, you can think of this class as the StateManager class. All the existing business logic that performs the state transitions should be refactored to use this single, central class to perform the state transitions, in effect isolating the state transition logic into a single class. From a workflow perspective, state transitions always occur at the beginning or conclusion of a workflow element. This is why all workflow tasks and workflow approvals have EventHandlers that can be used to invoke the StateManager class. Figure 2 shows the dependency chain between an event handler and the workflow document state.

After you decide to enable a workflow for a table in Dynamics AX 2009, and that the table has state that must be managed, you must refactor all the business logic to respect the state model that you define to avoid getting unpredictable results. Create operations should always create a record with the initial state (for the state model). Update operations must respect the current state and fail if the state isn’t as expected. For example, it shouldn’t be possible to change the business justification of a purchase requisition after it has been submitted for approval. Managing the state of the record during each update so that the current state is verified and the next logical state is updated would typically be implemented in the update method on the table by calling the StateManager class; if it returns true, go ahead and do the update. If not, throw an exception and abort. Figure 3 shows a simple state model for a record.

Figure 3. A simple state model for approvals

In Figure 9-10, the initial state is NotSubmitted. When a record is submitted to workflow, the state changes to Submitted. After the workflow is activated, the state becomes PendingApproval. If a workflow participant selects the Request Change action, the state changes to ChangeRequested. After all approvals are submitted, the final state is Approved.

1.2 Creating a Workflow Category

Workflow categories are used to associate a workflow template to a module. This association restricts the list of templates that are shown when you’re configuring a workflow for a particular module. To avoid showing a long list of all the workflow templates in the system, you group the templates by module using workflow categories. For example, if a user is in the Accounts Payable module, the user sees only the workflow templates bound to Accounts Payable. The mechanism behind this grouping is a simple metadata property on the workflow template called Workflow category. This property allows you to select an element from the module enum (AOT\Data Dictionary\Base enums\ModuleAxapta).

With this mechanism, it is easy for ISVs and partners who create their own modules to extend the module enum and thus have workflow templates that can be associated to that module. Note that a workflow category can only be associated to one module.