Logo
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
PREGNANCY
 
 
Windows Server

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

5/14/2013 5:56:36 PM

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

Figure 1. Workflow life cycle in Dynamics AX 2009


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 1. Workflow Artifacts
ArtifactSteps
Workflow categoryDefine the module within which the workflow template is enabled. 
ApprovalDefine the approval workflow document.

Define approval event handlers for Started and Canceled.

Define approval workflow providers for Participant, DueDate, and Hierarchy.

Define approval menu items for Document, DocumentWeb, Resubmit, ResubmitWeb, Delegate, and DelegateWeb.

Enable or disable approval outcomes.

Define approval outcome menu items for Action and ActionWeb.

Define approval outcome event handler.

Define the DocumentPreviewFieldGroup.
TaskDefine the task workflow document.

Define task event handlers for Started and Canceled.

Define task workflow providers for Participant, DueDate, and Hierarchy.

Define task menu items for Document, DocumentWeb, Resubmit, ResubmitWeb, Delegate, and DelegateWeb.

Add/remove task outcomes.

Define task outcome menu items for Action and ActionWeb.

Define task outcome event handler.

Define the DocumentPreviewFieldGroup.
Workflow templateDefine the workflow document.

Define event handlers for workflow Started, Completed, ConfigDataChanged, and Canceled.

Define menu items for SubmitToWorkflow, SubmitToWorkflowWeb, Cancel, and CancelWeb.

Define the workflow category. (Select from the existing categories.)

Define required approvals and tasks, and sequencing of required approvals and tasks. Enable or disable activation conditions for workflow configurations based on the template.


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

Table 2. Dependent Workflow Artifacts
Dependent Workflow ArtifactDescription
Workflow document queryDefines the data in Dynamics AX 2009 that a workflow acts on, and exposes certain fields that the business user uses for constructing conditions in the workflow configuration form. The query is defined under the AOT\Queries node, and it is required for all workflows.
Workflow document classReferences the workflow document query and any calculated fields to be made available when constructing conditions. This X++ class is created under the AOT\Classes node. It is required because workflow templates and elements must bind to a workflow document class. 
SubmitToWorkflow classThis X++ class is the menu item class for the SubmitToWorkflow menu item that displays the Submit To Workflow dialog box in the Dynamics AX 2009 user interface. The Submit To Workflow dialog box allows the user to enter comments associated with the submission. The SubmitToWorkflow class then activates the workflow. If state is being managed in the record that has been submitted to workflow, this class can be used to update the state of the record. This class is created under the AOT\Classes node.
State modelA defined set of states and state transitions (supported changes from one state to another) used to track the status of workflow document records during their life cycle. For example, a document can have the following states: Not Submitted, Submitted, ChangeRequested, or Approved. There is currently no state model infrastructure in Dynamics AX, so you have to implement any state model that is required. 
Event handlersEvent handler code consists of business logic that is written in X++ and then referenced in the workflow template, the approval element, approval outcomes, the task element, and task outcomes. If a workflow document has an associated state model, you must write event handler code to transact workflow document records through the state model when being processed by using workflow. Event handler X++ code is created under the AOT\Classes node.
Action and display menu items

Both types of menu item are created under the AOT\Menu Items or AOT\Web\Web Menu Items node.

For more information about the menu items used in the workflow infrastructure, see:

http://msdn.microsoft.com/en-us/library/cc602158.aspx

http://msdn.microsoft.com/en-us/library/cc604521.aspx

Custom workflow providersIf the functionality of the workflow providers shipped with Dynamics AX 2009 isn’t adequate for a given set of requirements, you can develop your own workflow provider. Custom workflow provider X++ classes are created under the AOT\Classes node and then referenced in one or more workflow elements. For more information about workflow providers, including where they are used, see http://msdn.microsoft.com/en-us/library/cc519521.aspx.
canSubmitToWorkflow methodThis method is required on each Dynamics AX 2009 client form that is enabled for workflow, and it is used to inform the workflow common controls that the record in the form is ready to be submitted to the workflow.

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.

Figure 2. State management dependency chain


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.

Other -----------------
- Workflow in Dynamics AX 2009 : Workflow Architecture
- 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
- SQL Server 2008 R2 : Performance Monitoring Tools (part 4) - Managing the Data Collector in T-SQL
- SQL Server 2008 R2 : Performance Monitoring Tools (part 3) - The System Data Collectors, Data Collector Reports
- SQL Server 2008 R2 : Performance Monitoring Tools (part 2) - Installing and Configuring the Data Collector
- SQL Server 2008 R2 : Performance Monitoring Tools (part 1)
- Microsoft Systems Management Server 2003 : Package Distribution and Management - Monitoring Status
- Microsoft Systems Management Server 2003 : Configuring the Client (part 4) - Managing the Advanced Client Download Cache, Advertised Programs Process Flow
- Microsoft Systems Management Server 2003 : Configuring the Client (part 3)
- Microsoft Systems Management Server 2003 : Configuring the Client (part 2) - Running Advertised Programs on Clients - Advertised Programs Wizard
- Microsoft Systems Management Server 2003 : Configuring the Client (part 1)
 
 
Most view of day
- System Center Configuration Manager 2007 : ConfigMgr Classic Reports Versus SQL Reporting Services
- Microsoft Visio 2010 : Sharing and Publishing Diagrams - Publishing Visio Drawings to SharePoint 2010 Visio Services
- Extending the Real-Time Communications Functionality of Exchange Server 2007 : Exploring Office Communications Server Tools and Concepts
- Advanced Windows 7 Programming : Working in the Background - DEVELOPING TRIGGER-START SERVICES (part 6)
- Workflow in Dynamics AX 2009 : Workflow Life Cycle (part 3) - Activating the Workflow
- BizTalk Server 2009 : Editing and Resubmitting Suspended Messages (part 2) - Pseudo-Walkthrough to Perform Edits and Resubmits
- Windows Server 2012 : File Services and Storage - Configuring iSCSI storage (part 1) - Understanding iSCSI storage
- Windows Phone 8 : Configuring Basic Device Settings - Passwords and Screen Timeouts (part 1) - Setting the Screen Timeout
- Securing the Workstation : Applying the Castle Defense System (part 6) - Working with external access - Working with the Windows Firewall with Advanced Security
- SQL server 2008 R2 : Reverting to a Database Snapshot for Recovery
Top 10
- Microsoft Project 2010 : Linking Tasks (part 8) - Auditing Task Links,Using the Task Inspector
- Microsoft Project 2010 : Linking Tasks (part 7) - Creating Links by Using the Mouse,Working with Automatic Linking Options
- Microsoft Project 2010 : Linking Tasks (part 6) - Creating Links by Using the Entry Table
- Microsoft Project 2010 : Linking Tasks (part 5) - Creating Links by Using the Task Information Dialog Box
- Microsoft Project 2010 : Linking Tasks (part 4) - Entering Leads and Lags, Creating Links by Using the Menu or Toolbar
- Microsoft Project 2010 : Linking Tasks (part 3) - Using the Start-to-Start Relationship,Using the Finish-to-Finish Relationship
- Microsoft Project 2010 : Linking Tasks (part 2) - Using the Start-to-Start Relationship,Using the Finish-to-Finish Relationship
- Microsoft Project 2010 : Linking Tasks (part 1) - Defining Dependency Links
- Microsoft Project 2010 : Defining Task Logic - Manipulating Your Schedule
- Microsoft Lync Server 2013 : Director Troubleshooting (part 3) - Synthetic Transactions,Telnet
 
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro