Recently I had a chance to discuss concept of token in BPMN with my students and thought you may also find this topic interesting.
So, first of all – what is a token? As opposed to other elements of BPMN like Tasks, Events or Gateways, tokens do not have visualizations.
Specification defines Token as: “a theoretical concept that is used as an aid to define the behavior of a Process that is being performed”.
Token is born when a Start Event is triggered (e.g. by receiving a Message, when some condition becomes true or for a plain Start Event simply when some employee starts the process).
Token then follows the Sequence Flow (it cannot use Message Flows or other arrrows) and flows through a process (passing through elements such as Gateways or Tasks/Sub-processes) right till the End Event where it is consumed.
Important thing about token is that it helps figure out what can happen in a process.
Let’s take a look at the following process. As you can see it is a simple sequence.
It means that you can start doing B only after A is complete and so on. If you are MS Project user this should remind you of Finish to Start link between tasks. Using example from Microsoft – you cannot Pour concrete until Dig foundation is done 🙂
But what happens in a context of a single Task (or Sub-Process)?
If you are not ready for technical explanation of a BPMN Activity lifecycle (from specification chapter 13.3.2) here is my quick and dirty introduction to what can happen to a Task (or Sub-Process). Elements marked with bold are important from a point of view of a Token handling.
In the beginning all Activities in a process are Inactive.
When a Token arrives Activity becomes Ready. In our example B could be Ready after A was done and Token moved to the right, but C, D and so on would be Inactive. It does not mean that some work begins right away. In real life this can be case when you prepared a report and passed to your colleague for additional check, but your colleague is busy. Task is on his (or her) list of things to do, but nothing happens yet.
Actual work begins when our Task/Sub-process changes state to Active. Technically speaking it can happen only when we have all the needed data. In some cases Activities take very long to complete (e.g. Sub-Process “Negotiations” could last for weeks) and sometimes they are quick (e.g. Task “Send reminder” could finish in a second if our process is automated).
If everything went fine, our Activity is done and we do not need to wait for anything it is Completed (if there would be some non-interrupting boundary events to handle we would be in intermediate state Completing). Outgoing Sequence Flow of this Activity gets a token, data is output.
If something went not as we expected Activity can move to state Withdrawn (if you used super-rare way of modelling when Receive Tasks are used after Event-based gateway only one path can be selected – all others will be withdrawn), Failed or Terminated (if the Activity was interrupted by some error or interrupting event; those states also have interim states Failing and Terminating). If the Activity was done but had to be undone we will have state Compensated (yes you guessed – preceded by Compensating). Theoretically compensation could go wrong and finish Failed or Terminated.
Now the last state – when last token reaches the End Event and life of a process instance ends our Activities will become Closed, since nothing more can happen to them.
This is how token behaves in a simple sequential process. However things get more interesting when we start splitting and merging process paths (with Gateways or without). Stay tuned for part 2!