Other Examples

Other Examples Mentioned in the Book #

Beside the two bigger use cases of Customer Onboarding and Order Fulfillment there are a couple of smaller examples promised in the book. You can find respective links to runnable source example on this page.

Combining Process Models and Programming Code #

As mentioned in Chapter 3 (“Combining Process Models and Programming Code”), there are three conceptual ways to link BPMN process models with glue code.

Publish/Subscribe #

Connector

See:

Reference Code #

Connector

See:

Connector Example #

Connector

See:

BPMN For Status Inquiries #

Mentioned in Chapter 11 (“Status Inquiries”) you can also build a simple HTML page showing certain metrics on top of a BPMN model visualized by BPMN.io.

BPMN.io used to visualize status in an HTML page

An example can be found in this part of the order fulfillment example. But it might be easier to look at this example to understand parts of it: Simple Process Instance Status View using bpmn.io.

Synchronous Facade #

Stateful Retry #

Saga Pattern and BPMN Compensation #

Message Buffering Workarounds #

Some engines do not buffer messages if a process instance is not yet ready-to-receive, as discussed in Chapter 9 (“Aggregating Messages”).

If you don’t have message buffering at your disposal, you either

  • buffer and retry messages in front of the workflow engine (e.g. using message brokers)
  • accommodate this limitation in your model

As illustration:

  • Camunda Platform 7.x does not support message buffering, so the following solution applies and the example linked below is done using Camunda Platform.
  • Camunda Cloud does support message buffering, so you best rely on the built-in features for that.

The following model will always be ready-to-receive the next message, in parallel to processing any incoming message. This model is executable and will safely collect all messages, even if they arrive at the same time and your engine does not support message buffering.

Aggregator process model that buffers messages itself

This model uses a couple of BPMN elements which are new to you if you followed the book.

It leverages a non-interrupting subprocess whenever the next message arrives. This means that the main process is kept, but a parallel path of execution is spawned. And it uses an event-based gateway, as the main process waits for either the condition that all messages arrive is true, or a timeout happens. The condition event operates on data, so you might have a flag in the process variables to indicate if all variables have arrived.

You can find an example using Camunda Platform here: https://TODO.

Serverless Function Orchestration #

Workflow Engine And Actors #