PenstockGuide / Check your work
Transaction boundaries
Draw a bar on the canvas wherever the engine commits a transaction, so you can see how much of a process runs in one go and where it stops and picks up again.
What it is
On a Camunda 7 engine a process does not run from start to end in one piece. It runs until it reaches a place where it has to stop, commits what it has done to the database, and carries on later in a new transaction. If a step fails, everything since the last of those places is rolled back. Where those places are decides what is saved when something goes wrong, and how long a database transaction stays open.
Nothing in the picture of a BPMN diagram shows them. They come from the kind of element and from the asynchronous before and asynchronous after switches in the properties panel. Transaction boundaries reads those and draws them, so you do not have to remember which element type waits.
It reads only the diagram. It does not start a run and does not ask the engine. It is free.
Turn it on
- Open a process in the BPMN editor, with a Camunda 7, Operaton or CIB seven engine. See Engines.
- Open the More menu and choose Transaction boundaries, under View.
- A short bar appears on the edge of every element where a transaction is committed. The row stays pressed while the bars are on. Choose it again to hide them.
Rest the pointer on a bar and it says Transaction boundary: the engine commits here. The bars follow the diagram while you edit it: move a task, add an asynchronous switch, and they redraw.
The action is in the menu and not on the toolbar to start with, and it has no shortcut. It is off until a diagram is drawn. You can pin it, see The toolbar and the More menu.
What gets a bar
| Element | Bar before it | Bar after it |
|---|---|---|
| User task, receive task, event-based gateway | Always. They wait for something outside the engine. | Only with asynchronous after |
| Service task, send task, business rule task, intermediate throw event, end event, set to the external type | Always. The work is done by an external worker that fetches it. | Only with asynchronous after |
| Intermediate catch event with a message, timer, signal or conditional definition | Always. It waits for the event. | Only with asynchronous after |
| Any other element with asynchronous before switched on | Yes | Only with asynchronous after |
| A multi-instance activity | Yes, when asynchronous before is set on its multi-instance settings, or on the activity | Yes, when asynchronous after is set on its multi-instance settings, or on the activity |
An element that has none of these gets no bar. A label never gets one.
Where the bar sits
- A bar before an element is drawn where each incoming sequence flow arrives. An element with two incoming flows has two bars. An element with no incoming flow, such as a start event, has one on its left edge.
- A bar after an element is drawn where each outgoing sequence flow leaves, or on its right edge when nothing leaves it.
- The bar is a short line across the edge it sits on, in the accent colour of your theme. Message flows and associations are not counted.
Example
A process runs Receive order, Validate order, Approve order and Ship order. Validate order is a service task with asynchronous before on, Approve order is a user task and Ship order is an ordinary service task.
- There is a bar on the flow that arrives at Validate order, because of the switch.
- There is a bar on the flow that arrives at Approve order, because a user task always waits.
- There is no bar at Ship order. It has no switch and is not a waiting element, so it runs in the same transaction as the step that came before it.
Read the bars as the places where the process can pause. Between two bars, the steps run together and succeed or roll back together.
Camunda 8 and the other engines
The action is only in the menu for Camunda 7, Operaton and CIB seven. In a Camunda 8 or Classic BPMN diagram it is not offered. Camunda 8 has no transactions that span steps: every job and every wait is its own unit, so the asynchronous switches mean nothing there. When you convert a diagram, the migration report lists Asynchronous continuation is dropped for each element that had one, with the note that there is nothing to do. See Camunda 7 to 8.
What it does not do
- It adds nothing to the file and nothing to the undo history. The bars exist on the canvas only.
- It does not say whether a boundary is a good idea. A bar says the engine commits there, not that it should.
- It does not change any setting. To move a boundary, change the element's asynchronous switches in the properties panel.
What you see
- A short bar on the edge of each element where the engine commits.
- The Transaction boundaries row pressed in the More menu.
Common problems
- The menu has no Transaction boundaries.
- The diagram is for Camunda 8 or Classic BPMN. The action is for Camunda 7, Operaton and CIB seven. It is also off until the diagram is drawn.
- A user task has a bar before it, and I did not set anything.
- That is right. A user task, a receive task and an event-based gateway always wait, so the engine always commits before them.