State Machine Patterns

Process Patterns

The State Machine Cook Book describes how to build a state machine with the elements state, transition and event. However there are some recurring design problems that are needed in many processes. In this article common problems and their solution with state machine snippets are described.

Process Variants

It is a good approach to create a process per payment method and per shipping (drop shiping, cross docking, warehouse) per country.

Cross System Orchestration

A state machine process describes the entire control flow a sales order/sales order item can follow. This typically includes payment, fulfillment and return processes. The state machine is supposed to orchestrate the entire flow. If you consider the process a relay the baton needs to be handed over to different other systems. Let’s use the example of the fulfillment with an ERP system. At a given point the sales order is ready to be fulfilled. A command can be used to invoke a service from the ERP system that allows to trigger fulfillment for a specific sales order. At that point the ERP system will take over the control and start the pick pack ship process. Zed is passive during this time. It will wait until the ERP system sends an event to inform Zed that the fulfillment is complete. Technically Zed will provide a service that can be called by the ERP system. The service itself needs to identify the Sales Order (correlation) for which this event needs to be fired and then invoke the invokeEvent method from the OMS Facade. Same pattern can be used to do more fine granular status updates. In this case there would be more waiting states and corresponding events that are waited for. See also §4 async response pattern, for timeout and exception management.

Ticket System Integration

Most of the sales order processing will be automated. However there are still cases that need human interaction.

Async Response

Everytime the process needs to wait for an async response, this pattern can be applied. The first state indicates that an external service is ready to be invoked. The first transition fires automatically and executes a command that includes the coding to capture the payment in this example. Afterwards a state waiting for result is reached. This shows that the process is waiting for an external event to happen. It is good practice to include the case that the response does not arrive. Therefore a timeout event is bound to an exception transition. This state indicates that the normal flow of the process did not take place. It could be used to open a ticket (see §3). Nevertheless the event could still arrive. Therefore it needs a transition from the timed out state to the capture result received state.