Bruce Silver's blog post - Standardizing BPMN Labels
Bruce Silver
Blog

Standardizing BPMN Labels

By Bruce Silver

Read Time: 4 Minutes

In my BPMN Method and Style training, I show the following BPMN and ask students, “What does this diagram say?”

You really cannot tell. It says something happens and then either the process ends or something else happens. Not very informative. But if you run Validation against the rules of the BPMN spec… no errors!

As far as the spec is concerned, it’s perfect. But if the goal is to communicate the process logic, it’s useless. If we run Validation against the Method and Style rules, we get this:

Now we get 6 errors, and they all pertain to the same thing: labels. Compare that process diagram with one containing labels and other “optional” elements:

Now the diagram says something meaningful. Beyond labels, the BPMN spec considers display of task type icons, event triggers, message flows, and black-box pools to be optional. Their meaning is defined in the spec, but modelers may omit them from the diagrams. Labels – their meaning, placement, or suggested syntax – are not discussed at all. They are pure methodology.

Obviously, to communicate process logic intelligibly through diagrams, labels and similar methodological elements are necessary. That was the main reason I created my own methodology, called Method and Style, over a decade ago, which includes rules about where labels are required, what each one means, and where corresponding diagram elements must be labeled identically. The best BPMN tools, like Trisotech Workflow Modeler, have Method and Style Validation built in, and thousands of students have been trained and certified on how to use it.

Here are some of the rules related to labeling:

One reason why the task force developing the BPMN 2.0 standard didn’t care about labels is that their focus was primarily on model execution, which depends heavily on process data. While it is possible to suggest process data and data flow in the diagrams, this is something that – in most tools – is defined by Java programmers, and as a consequence is omitted entirely in descriptive, i.e. non-executable, models. In order to reveal model meaning in descriptive models in the absence of process data, Method and Style introduced the concept of end states.

The end state of an activity or process just means how did it complete, successfully or in some exception state. End state labels, typically in the form Noun-adjective, serve as a proxy for the process data used to determine branching at gateways. For example, in the diagram above, the gate labels Valid and Invalid are by convention the end states of the preceding activity Validate request. An executable version of this process would not necessarily have a variable with those enumerated values, but the labels suggest the process logic in an intuitive way.

I’m not going to review the other Method and Style conventions and rules here. There is plenty of information about them on my website methodandstyle.com, my book BPMN Quick and Easy, and of course my BPMN Method and Style training. Method and Style makes the difference between BPMN diagrams that communicate the logic clearly and completely and those that are incomplete and ambiguous. BPM project team managers tell me that before Method and Style, their BPMN diagrams could be understood only by the person that created them. Standardization of the meaning and usage of diagram labels changed all that.

CMMN, the case management standard, has the same issue. For example, a plan item’s entry and exit criteria, modeled using sentries and ON-part links, require labels on both the ON-part (a standard event) and the IF-part (a data condition) to make sense, but labeling is not required or even suggested by the spec. Without labels, all we can tell is that some entry or exit condition exists. My book CMMN Method and Style suggests several labeling conventions for those diagrams, as well.

The Trisotech platform provides a key benefit to Method and Style practitioners: Method and Style rules about labels and other conventions can be checked in one click. Style rule validation not only improves model quality but reinforces the rules in the modeler’s mind. In the training, certification exercises must be free of any validation errors.

If your BPM project depends on shared understanding of BPMN diagrams, you need to go beyond the spec with labeling standards. You need Method and Style.

Follow Bruce Silver on Method & Style.

Blog Articles

Bruce Silver

View all

All Blog Articles

Read our experts’ blog

View all

Bruce Silver's blog post - DMN's Killer App
Bruce Silver
Blog

Interrupting Events in Automation

By Bruce Silver

Read Time: 2 Minutes

In my BPMN Method and Style training, we use examples like the one below to illustrate the difference between interrupting and non-interrupting boundary events:

Here an Order process with four subprocesses could possibly be cancelled by the Customer at any time. As you can see, a single physical Cancellation message from Customer is modeled as multiple message flows. That’s because the Cancellation message is caught by four different message boundary events, representing four different ways the message is handled depending the state of the process when Cancellation occurs. Note that if the message is received during Prepare invoice, i.e., after Ship order is complete, the Order process cannot be terminated, and explanatory information is instead sent to the Customer. And this is a fine way to show, in descriptive models – i.e., non-executable BPMN – the behavior expected with exceptions like Customer Cancellation.

But as I have begun to get more involved with Automation models – executable BPMN – I am discovering that modeling exception handling in this way is not ideal. The BPMN spec says that an interrupting boundary event terminates the activity immediately. As far as the process engine is concerned, the instance just goes away, along with all its data. A user performing some task inside a cancelled subprocess is unaware of this until the task is complete; the Performer gets no notification that their work on this Order is for naught. That’s the main problem. There is also the problem that some actions performed in the activity prior to cancellation may need to be undone. That can be done on the exception flow, so the main difficulty, as I see it, is notifying the user performing some task when the Cancellation occurs.

Let’s focus on the first subprocess, Enter order. In this simplified example, the Order is first logged into the Order table, then inventory is checked for each Order item, reserving the Order quantity for each one. If some items are out of stock, we need to Update Order table. An Order Acknowledgment message is sent to the Customer containing the OrderID, a unique identifier in the system. The Customer would need to provide this in any Cancellation message. These are all automated activities, occurring very fast. Then a User task Check credit authorizes the purchase for this Customer. That could take a while, so if the Customer decides to cancel shortly after submitting the order, it’s likely going to occur during Check credit. And if that happens, we don’t want the user performing Check credit to waste any more time on this Order, as would happen with an interrupting boundary event.

So instead we model it as a non-interrupting event subprocess. We could do it with a non-interrupting boundary event on the subprocess, but this way I think is cleaner. Now if the Cancellation message is received, before we terminate Enter order we do a bit of cleanup, including Update Order table to show a status of “Cancelled by Customer” and notifying the Check credit performer by email to stop working on this instance, after which we terminate the subprocess with an Error end event. The exception flow from this Error event in the parent level allows additional exception handling for the Cancellation.

The required exception handling requires some additional information about the process instance. We need to know who is the task performer of Check credit. This is platform-dependent, but on the Trisotech Low-Code Automation platform you can use a FEEL extension function to retrieve the current task performer. In a more complex subprocess, we may also need to know its state when the cancellation occurred, which tasks have been completed and may need to be undone. For this, Trisotech has provided additional extension functions as well. Cleaning up when a process instance is cancelled in-flight can be messy, but it’s still within the reach of Low-Code Business Automation.

Follow Bruce Silver on Method & Style.

Blog Articles

Bruce Silver

View all

All Blog Articles

Read our experts’ blog

View all