Workflows and State Machines
Warning: You are browsing the documentation for Symfony 3.x, which is no longer maintained.
Read the updated version of this page for Symfony 7.1 (the current stable version).
Workflows
A workflow is a model of a process in your application. It may be the process of how a blog post goes from draft to review and publish. Another example is when a user submits a series of different forms to complete a task. Such processes are best kept away from your models and should be defined in configuration.
A definition of a workflow consists of places and actions to get from one place to another. The actions are called transitions. A workflow also needs to know each object's position in the workflow. The marking store writes the current place to a property on the object.
Note
The terminology above is commonly used when discussing workflows and Petri nets
Examples
The simplest workflow looks like this. It contains two places and one transition.
Workflows could be more complicated when they describe a real business case. The workflow below describes the process to fill in a job application.
When you fill in a job application in this example there are 4 to 7 steps
depending on the job you are applying for. Some jobs require personality
tests, logic tests and/or formal requirements to be answered by the user. Some
jobs don't. The GuardEvent
is used to decide what next steps are allowed for
a specific application.
By defining a workflow like this, there is an overview how the process looks like. The process logic is not mixed with the controllers, models or view. The order of the steps can be changed by changing the configuration only.
State Machines
A state machine is a subset of a workflow and its purpose is to hold a state of your model. The most important differences between them are:
- Workflows can be in more than one place at the same time, whereas state machines can't;
- In order to apply a transition, workflows require that the object is in all the previous places of the transition, whereas state machines only require that the object is at least in one of those places.
Example
A pull request starts in an initial "start" state, a state for e.g. running tests on Travis. When this is finished, the pull request is in the "review" state, where contributors can require changes, reject or accept the pull request. At any time, you can also "update" the pull request, which will result in another Travis run.
Below is the configuration for the pull request state machine.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
# app/config/config.yml
framework:
workflows:
pull_request:
type: 'state_machine'
supports:
- AppBundle\Entity\PullRequest
initial_place: start
places:
- start
- coding
- travis
- review
- merged
- closed
transitions:
submit:
from: start
to: travis
update:
from: [coding, travis, review]
to: travis
wait_for_review:
from: travis
to: review
request_change:
from: review
to: coding
accept:
from: review
to: merged
reject:
from: review
to: closed
reopen:
from: closed
to: review
You can now use this state machine by getting the state_machine.pull_request
service:
1
$stateMachine = $this->container->get('state_machine.pull_request');