Post by Krisztina Lutean |
In this blog article we are going to take a look at state machines. State machines are a new concept in Microsoft Dynamics 365 for Finance and Operations (D365FO) and they are a really great feature that enables workflow events to be bound to state transitions on the underlying entity's state machine. This binding enables business logic to be centralized within the state machine and also enables the workflow system to be a declarative consumer of that state machine. The workflow metadata can reference a state transition that is performed when a specific workflow event occurs. Therefore, you can do state transitions within a workflow without writing any additional code, as opposed to AX2012 version where the control of status fields was handcrafted in code, which could be often hard to read as there was no obvious pattern to follow.
There is a restriction though: there must be one initial state and one final state. When we are at the final state there is no going back. For example, if we take the sales order status, we have two final states: Invoiced and Cancelled. There is another reason why we wouldn't use a state machine on this type of status: the sales order status is a reflection of an actual order state, it is system controlled. State machines are designed to enforced status change logic when the state is asserted by a user.
So, let’s see how we can implement this in D365FO.
What is a state machine?
The state machine is an abstract machine that can be in exactly one of a finite number of states at any given time.
State machines allow us to define, in metadata, how the status transitions from an initial state to its final state. These rules are then enforced by code that the state machine will generate.
Let’s take a look at an example of how we could use the state machines for a customer approval process.
Creating a state machine
In our workflow there is a requirement to perform a credit check before a customer can be submitted for approval. This is a very common requirement in legal firms. It represents the first step in our workflow business process, as you can see on the picture down below:
The Credit check block on the workflow editor diagram is a manual task and it’s created within Visual Studio by adding a new Workflow task item to your project and running the manual task wizard, found under the Business Process and Workflow category. This will generate the block for you and make it available in the workflow editor.
Adding a new workflow task
For our state machine example, we have created a table called AXUGCustTable. This table is an extension of the CustTable and it holds workflow related information.
The table has a status field with an initial and final status, such as the CustCreditCheck field which represents the state of the credit check manual task.
The CustCreditCheck field is represented by the AXUGCustCreditCheck base enumeration which contains the following elements:
How to do it
In order to create a new state machine we will expand and right-click on the State Machines node in the AXUGCustTable and add a new state machine. It should look something like this:
Adding a new state machine to the AXUGCustTable
After this step we need to define each state for the AXUGCustCreditCheck base enumeration and we then need to define the transition rules for the state machine. Make sure you provide labels and descriptions for each element. The result should look like the following screenshot:
State machine and its transition rules
Please note, the CreditCheckNotStarted represents the Initial state and the CreditCheckClosed represents the Final state. All the other enumerations are Intermediate. You can specify this by setting the State Kind property on each state, just like in the screenshot below.
The final step is to right-click on the CustomerCreditCheckStateMachine node and click Generate. This generates the code that will be used to control the credit check process progression.
Extending Microsoft Dynamics 365 for Operations Cookbook, Simon Buxton