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:

• Activities should be labeled (Verb-object) to indicate an action.
• A Message start event should be labeled Receive [message name].
• A Timer start event should be labeled with the frequency of occurrence.
• The label of a child-level page should match the name of the subprocess.
• Two activities in the same process should not have the same name unless they are identical.
• A boundary event should be labeled.
• An Error or Escalation boundary event on a subprocess should be labeled to match the throwing Error event.

• A throwing or catching intermediate event should be labeled.
• If a process level has multiple end events, each end event should be labeled with the name of the end state (Noun-adjective).
• Each gate of an XOR gateway should be labeled with the name of an end state of the previous activity. If 2 gates, the gateway may be labeled as end state plus ? and the gates labeled yes and no.
• Gates of an AND gateway should not be labeled.
• Non-default gates of an OR gateway should be labeled.
• Two end events in a process level should not have the same name. If they mean the same end state, combine them; otherwise give them different names.

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.

Occasionally in my BPMN Method and Style training, a student will submit a Certification exercise containing a Conditional event. I have always rejected that. Conditional events are not part of Method and Style, and that’s because I have always considered them to mean “some magic occurs”.

According to the spec, a Conditional event may be used either as the Start event of a process or event subprocess, a Catching Intermediate event, or a Boundary event, triggered when its Boolean expression attribute becomes true.But what data can that expression reference? This is the problem, because the spec does not say. In fact, the only place where the BPMN 2.0 spec speaks to it is in the context of a process Start event, where no instance data yet exists!

For that, it says:

Here you should interpret the term “out of scope” to mean undefined, or to use my word, “magic.”

If you were a generous sort, you might infer that for other Conditional events, the expression references the “data context”, i.e. what we call process data. And it turns out that this is exactly how Trisotech has implemented Conditional events. Because non-executable processes, our focus in Method and Style, do not define process data, I will continue to avoid Conditional events there. But in Business Automation, they enable some event-triggered behaviors that are otherwise more complicated to model.Recall from previous posts that in Trisotech BPMN, process data and expressions are defined using FEEL, the Low-Code language defined in the DMN spec. The condition expression of a Conditional event is thus a FEEL Boolean expression referencing instance data.A Conditional event is triggered when the value of one or more process variables change such that the condition expression becomes true.

So when can that occur?

Except for cloud datastores, which may be updated from outside the process, the value of a process variable is changed only when its incoming data association occurs, i.e. at the completion of the activity or event at the source of that connector. Thus it is always possible that Conditional event behaviors could alternatively be modeled more conventionally using gateways, sometimes in combination with Signal events. For example, suppose we have an established decision service Validate Input, but starting in 2023 we want to perform additional validations under certain conditions. We could model this using a non-interrupting Conditional event subprocess, as shown below.

However, we could model the same logic more conventionally using an OR gateway leading to a regular subprocess.

In the BPMN Method and Style training we discuss two ways a process can receive information from outside: either via a message or shared data. In Business Automation, using shared data is probably more common. If that shared data used a cloud datastore (as opposed to an external app or database), you might think you could wait for a condition on the datastore to become true. Unfortunately, the Conditional event cannot be used for this. At least on the Trisotech platform today, the datastore update must be caused by a data association from within the process, not externally. For example, the scenario below, in which a Service request process waits for payment via a separate Payment process, does not work with Conditional events. Changes to the datastore Orders are not visible to the Conditional event.

But we could put the Payment process inside our main process using a call activity, which would allow the wait-for-Condition to work:

Although one could debate the point, on balance this solution is probably better than the more conventional alternative using a Signal event thrown by Payment process.

If you are willing to have Payment process throw a Signal, throwing a Message is even simpler.

Conditional boundary events have the same basic issue. Because the condition cannot be triggered from outside the process, it must be caused by a parallel thread of execution within the process. (In the absence of parallel flow, a simple gateway testing the condition is always going to be simplest.) So again, the modeler’s choice is between a Conditional boundary event testing shared process data and Signal throw-catch. And again, I believe that in this case the Conditional event solution is better.

Bottom line, while Conditional events appear useful on the surface, their utility is in practice limited to scenarios in which actions on one parallel thread of a process control actions on another thread.

For many years my work has focused on non-executable BPMN using a set of conventions called Method and Style.

In the past year or two I have turned my attention to Low-Code Business Automation, based on executable BPMN. When I wrote my book BPMN Method and Style – over a decade ago! – I imagined that harmonizing executable BPMN with Method and Style would be a natural thing, but that never happened. Now, with a good bit of experience with Business Automation under my belt, I understand why. In this post we’ll look at the differences between non-executable and executable BPMN modeling.

Data

The most obvious difference between the two concerns data. Executable models explicitly define process variables (data objects) and show the data flow in the diagram. Non-executable models do neither. The reason for that is fundamental. The BPMN 2.0 spec does not specify a language for defining process data and expressions, and for years most BPMN tools have used Java. That made executable BPMN accessible to programmers only. But actually, most BPMN modelers are business users, not programmers. They are just looking to document and improve their business processes, not automate them. Method and Style was created with those users in mind.

BPM teams spend countless hours trying to document how their processes work and capture that knowledge in BPMN, but too often the resulting models are understandable only to the person that created them. The challenge for non-executable BPMN is revealing the process logic clearly and completely from the diagrams… to someone who doesn’t already know how it works. You need a bit of data to do that, and Method and Style provides it implicitly using the concept of end states. The end state of an activity or process names a possible way it could end, either successfully or in some exception state. With processes and subprocesses, we use a separate end event labeled to indicate the end state. Method and Style says that an activity – task or subprocess – with multiple end states must be followed by an XOR gateway with gates labeled to match each end state. These labels reveal, at a basic level, the conditions under which any instance follows a particular path through the diagram.Executable BPMN works differently. Here the goal of the model is executability on a BPMN engine, and this requires explicit definition of process and task variables. You can still label gates and end events as end states, but these labels are just annotations; what counts in executable routing is a boolean condition on process variables attached to each gate.

Executable BPMN distinguishes process variables from task variables. Process variables are defined by the modeler and visualized in the diagram as data objects, data inputs, and data outputs. Task variables do not appear in the diagram. They are properties of each task, and for some task types are not defined by the modeler at all but by an invoked REST API. The modeler must map process variables to and from the task variables. On the Trisotech platform, both process and task variables are converted to FEEL data, so the data mapping is Low-Code, using FEEL and boxed expressions borrowed from DMN.

A final data-related difference between Business Automation and Method and Style is the need for data validation and error handling in executable models. To avoid runtime errors, executable BPMN cannot assume data inputs are complete or valid. In Method and Style we don’t worry about that.

Task Types

A second key difference is task types. In Method and Style we pay almost no attention to task types, except to distinguish human from automated tasks. Often modelers don’t assign a task type at all. In executable BPMN, task types are essential, as each task type performs a specific function. A task without an assigned task type does nothing.

• A Service task executes an external REST API catalogued in the model’s Operation Library, as described previously.
• A Decision task (in the tool called a Business Rule task) executes modeler-defined business logic in the form of a DMN decision service.
• A Script task executes simple modeler-defined business logic – a single FEEL literal expression.
• A User task routes a task form to a human performer and returns its output to the process.
• A Call Activity executes modeler-defined process logic in the form of a BPMN process service.

Each task type has its own configuration details, but all use the same Low-Code data mapping. In a Service task, Decision task, or Call Activity, the task inputs and outputs are defined by the invoked API, not by the calling process. In a Script or User task, the task inputs and outputs are defined by the process modeler.

In executable models, Service, Script, and User tasks are extremely fine-grained. While in Method and Style an automated task (typically represented as a Service task) can be imagined to perform a complex action containing multiple discrete operations, in executable BPMN a Service task is limited to a single service operation. That means that a complex automated function is more likely implemented as a Call Activity, a process involving a sequence of Service tasks. User tasks are similar. While in Method and Style a User task is imagined to perform complex human activities involving multiple system interactions, an executable User task on the Trisotech platform is a single task form and involves no system interactions. Again, a complex human task would be modeled as a process invoked by a Call Activity.

Black-Box Pools and Messages

In Method and Style we use message flows from and back to a black-box pool to represent the process request and final status response. Executable BPMN doesn’t have a clear implementation of black-box pools. Instead we use data inputs and data outputs. On the Trisotech platform, processes are deployed as REST services, so a process request is the same as a call to the Execute operation of that service. A data input represents the data provided in that request, and a data output represents data returned to the requesting client upon completion. The identity of the requesting client – the black-box pool in Method and Style – is immaterial. Any client with the appropriate bearer token can request the service.

I have previously described a mechanism in Trisotech by which a message flow from a black-box pool to a start event may substitute for a data input and a message flow to a catching message event can trigger process behavior. Outgoing message flows to a black-box pool are more of a problem, because unlike Method and Style, where these mean any communication to the external entity, a process cannot really send a “message” to an abstract entity. Instead, a Send task or throwing message event can be configured to send an email to a user. It’s not really the same thing, and in my own processes I tend to use a Service task from the Trisotech Connectors Library to send emails.

A Common Language Nevertheless

Despite these differences, which are not insignificant, BPMN remains a common language shared by modelers documenting processes and those automating them. Below you see two versions of a Vacation Request process. The first is based on Method and Style, with black-box pools and message flows, end state labels, and simple distinction between human and automated tasks.

Interest in Business Automation is being accelerated by the thousands of public REST APIs available from countless service providers.

Most are available on a Freemium basis – free low-volume use for development, with a modest monthly fee for production use. The Trisotech Low-Code Business Automation platform lets you incorporate these services in your BPMN models without programming. You just need to configure a connection to them using the model’s Operation Library. With many public APIs, that configuration requires simply importing an OpenAPI file from the service provider. OpenAPI – sometimes called Swagger – is a file format standard for REST APIs. The problem is that most public APIs don’t provide one. Instead they provide documentation that you can use to configure the Operation Library entry yourself. If you’re not a developer, that sounds daunting, but it’s really not that hard. This post will show you how to do it.

A REST API is organized as an interface containing a set of operations. The interface specifies a base address, or server URL, and some means of authorization, such as an API key. Each operation performs a specific function, and is addressed by a path appended to the base address or endpoint. To invoke the operation, a client app sends an http message that contains the required information to a URL concatenating the base address and path. That information includes:

• The http method: POST, GET, PUT, PATCH, or DELETE, indicating whether the operation is reading, writing, modifying, or deleting data.
• The authorization credential
• Input parameters for the operation, required and optional, typically specified as json

Upon receipt of the message, the service is executed and returns some response message, which includes:

• A standard http response code. A code of 200 indicates success, 404 means the base URL was not found, 401 not authorized, 500 either a bad request or internal server error, etc.
• Output values for the operation, separately for each response code, again specified as json

Compared to the earlier generation of SOAP-based web services, REST APIs are simple and standardized. This is their great attraction!

In my Business Automation training, we make use of a real-time stock quote service from Rapidapi.com, a popular aggregator of public APIs. The service we use is called YH Finance, a clone of the old Yahoo Finance API. The documentation page looks like this:

The interface is huge, with operations collected in groups. The one we want is in the group market, with the path /market/v2/get-quotes. Selecting that from the panel on the left, we see the operation documentation in the center panel, which specifies the parameters of the operation, and where in the message they are placed: in the message header, message body, or query portion of the URL. Here two parameters are required in the http message header: X-RapidAPI-Host is the server URL, yh-finance.p.rapidapi.com. X-RapidAPI-Key is the requester’s personal authorization credential. Two more parameters are required in the query: region, enumerated text, and symbols, a comma-delimited string containing stock tickers.

This documentation is all we need to create the input side of the Operation Library entry. Manually add an interface YH Finance and an operation Get Quotes. In the interface properties enter the Server URL and the authorization type. In the operation properties enter the method, path, and under Inputs the required parameters except for the API key, which is assigned to an individual and entered separately when the process containing the service invocation is compiled and published. Clicking the pencil for each input lets you specify its datatype, a FEEL type you must create from the documentation. It’s actually quite easy!

Configuring the operation output is slightly trickier. Notice in the API documentation the button Test Endpoint in the center panel. Clicking that executes the operation with the default parameters shown, in this case a string listing three stocks.

The documentation page then shows the resulting output, as you see here: an outer element quoteResponse with two components, an array of result – one per stock – and error. Expanding result, we see it contains 97 components – wow, that’s quite a lot – of which we only need three: quoteType, bid, and ask. But we do not need to construct a FEEL type with all 97 components. As long as we respect the basic structure, we can omit the 94 result components we don’t need! So we can create FEEL type tTradeQuote, a structure with enclosing element quoteResponse containing a collection of result plus error, and the type of result contains just the three components we need. When the service is invoked, the json response message is mapped automatically to the FEEL tTradeQuote structure.

To incorporate this operation in your Business Automation model, simply click the gear icon on a Service task and bind the task to the Operation Library entry. The service inputs – symbols, region, and x-rapidapi-host – become the task inputs, and the service output quotes becomes the task output. Then, using the Low-Code data mapping explained in a previous post, you just need to map data objects in the process to the task inputs and output. When you Cloud Publish the process, you will need to enter your API key. And that’s it!

So just because your API provider doesn’t offer an OpenAPI file, don’t think it’s inaccessible to Low-Code Business Automation. It’s actually quite easy.