BPMN and Metadata - Leveraging app capabilities - KIE Community

Introducing Metadata

As much as we aim to empower users with a versatile, easy-to-use tool, sometimes that isn’t enough. Most solutions require specific data or interactions that are hard to provide out-of-the-box. The BPMN2.0 specification already covers those situations in more than one way, now so does the BPMN Editor. After our latest release (Business Central v7.12 and Kogito v0.12.0), adding custom data to all BPMN nodes is possible through the metadata field. You can find it under the node property tab in the advanced category.

Metadata field in the BPMN Editor.

Using Metadata

Although not required, this feature alongside a listener is the most common use case. In a hypothetical scenario, the user could add audit/logging data, combine it with a process listener, and create a custom audit/logging strategy based on node-provided information. In another, author information can be used to support document creation or for any other regulatory purpose.

Simple BPMN and Metadata

The following example shows a a custom event listener using custom metadata to start a process:

Metadata attribute in the BPMN file

<bpmn2:process id="test" drools:packageName="com.example" drools:version="1.0" name="test" isExecutable="true" processType="Public">
  <bpmn2:extensionElements>
    <drools:metaData name="riskLevel">
      <drools:metaValue><![CDATA[low]]></drools:metaValue>
    </drools:metaData>
  </bpmn2:extensionElements>
</bpmn2:process>

public class MyListener implements ProcessEventListener {
    ...
    @Override
    public void beforeProcessStarted(ProcessStartedEvent event) {
        Map < String, Object > metadata = event.getProcessInstance().getProcess().getMetaData();
        if (metadata.containsKey("low")) {
            // Implement some action for that metadata attribute
        }
    }
}

Going deep with BPMN and Metadata

Here, in a more in-depth example, the jBPMN engine uses metadata to control process flow:

Process in BPMN editor showing flow control.

Nothing too fancy here. Just a simple process with two distinct flows. The main flow, containing two tasks (1st Task and 3rd Task) and a secondary flow with a single task (2nd Task) inside a sub-process (sb1). They are simple and only print out their names. The node start-sb1-throw-signal emits a signal listened to by start-sb1-catch-signal. The node end-sub1-catch-signal listens for the signal emitted by end-sb1-throw-signal.

Without a doubt, this is a basic diagram. The expected output for its execution follows 1st Task, 2nd Task, 3rd Task. But in reality, what we get is 1st Task, 2nd Task. In a closer inspection, we can see the flow never completes and stops at end-sub1-catch-signal. The reason for that is not fundamental for this post, so we are not going to dive into the details. But basically, the signal listened by end-sub1-catch-signal is emitted before the node setup, losing it and halting the execution. 

To work around that, jBPMN uses the executeActionAfterComplete flag, which allows the flow to move on to the next element before doing any other actions. So for our diagram, all we need is to add new metadata withexecuteActionAfterComplete as name and True as a value in the start-sb1-throw-signal node. This way, the flow proceeds to the next node (end-sub-catch-signal)before signaling and reaches the end without trouble.

Metadata attribute entry in BPMN editor.

The possibilities are endless. We hope this feature helps you take your application to the next level. That is all for today. Stay tuned for more jBPM features!