This page summarizes process-automation patterns described in the March 2024 MDriven presentation. State machines can be used for business-oriented or technical flows. They describe the allowed ways an item can move through a process rather than requiring separate code to track every case.
Model a process as state changes
A state machine represents an item’s process position with a state attribute. The presentation describes this attribute as having one value at a time, while the state-machine definition can describe many possible operations and paths.
Use the state machine to describe:
- States — the current process position.
- Guards — whether a move in a particular direction is allowed.
- Entry actions — actions called when the process arrives in a specific state.
- Effects — actions associated with a particular route to a state.
| Process question | State-machine concept | Presentation example |
|---|---|---|
| What is the item’s current process position? | State | An item is in a processing or failed state. |
| Is this move allowed now? | Guard | A reminder can move forward when the timing condition permits it. |
| What should happen on arrival? | Entry action | Reaching a state calls an action. |
| What should happen on a particular route? | Effect | Moving to a reminded state sends an email. |
Example: process work initiated by a REST API call
The presentation gives an example in which a REST API call moves something into a process and a generic engine processes it. Process logic can be placed in methods and run by that engine.
A possible state-machine outline is:
- A REST API call moves the item into a processing path.
- An entry action is associated with the relevant state.
- The processing logic runs in methods.
- If there is a problem, move the item to a problem or failed state.
- Users can find items in the failed state, take corrective action, and use a retry path where appropriate.
The presentation describes the speaker as usually adding an exception-handling path for background jobs, with a state such as “there was a problem,” so failures are visible and can be acted on.
Example: send a reminder when it is due
The presentation describes a reminder pattern in which an item waits in a paused state. A guard determines when it may move to the reminder step. A process checks whether the move is permitted; if not, it checks again later. When the item takes the route to the reminded state, an effect sends an email.
- Move the item to a paused state.
- Define a guard that answers whether it is time to send the reminder.
- Recheck the guard until the transition is allowed.
- Associate an email-sending effect with the transition to the reminded state.
This keeps the timing condition and the reminder outcome connected to the process path.
State changes can trigger further work
The presentation notes that completion of a state change can have consequences such as sending an email, producing a report, or triggering another state machine. This allows a process definition to express what should happen after a step completes.
Deployment automation
For deployment-related automation, the continuous-integration documentation describes automating code generation, rebuild, and upload to MDrivenServer to initiate database evolution. It also documents environment variables used when launching Visual Studio model automation.