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[edit source]
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[edit source]
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[edit source]
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[edit source]
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[edit source]
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.