How To Implement Correlation support for BPMN workflow

Abstract

WSO2 Business Process Server 3.5.1 will be introducing new BPMN Rest API to support correlating among the client and BPMN workflow instances.

Typically in a BPMN workflow scenario to correlate instances, we use either intermediate message catch event or signal catch event. Since intermediate catch events are used for correlating with single message instance, this blog post will consider one such scenario.

In order to explain this use case we have implemented following workflow diagram.

Requirements

• WSO2 Business Process Server 3.5.1 ( Beta version can be downloaded from here ).
• The BPMN workflow can be downloaded from here.

Once the BPMN Archive file is deployed to the server, BPMN instance can be started by hitting the url https://localhost:9443/bpmn/runtime/process-instances with following request.

Prior to sending the request please make sure to set the following header values.
Those are

• Content-Type: application/json or application/xml
• Accept: application/json or application/xml
• Authorization: Basic base64encode(username:password)

Authorization header has to be set with the base64 encoded values of "username:password".

In the event of successful initialization of the instance, it will return with following response.

Next we can send the following message to execute the correlated instance among already existing instances by hitting the url https://localhost:9443/bpmn/runtime/receive. Make sure to set the header values as well. Currently BPS 3.5.1 supports both json and xml as well.

Instances to be correlated can be identified the field "correlationVariables". This variable can be used to detect the instance with the same variables state.

In addition "variables" can be used to define the variables, that should be updated prior to the resumption of execution of the correlated instance.

Following are the fields that can be used in the correlation request.

processDefinitionKey/processDefinitionId/messageName/signalName (compulsory)

Either one relevant property out of four should be specified in the request.

action (compulsory)

actions can be either messageEventRecieved/signalEventRecieved/signal.

signalName (optional)

If we have any signal related actions, then signalName has to be specified.

variables (optional)

All the variables that should be updated prior to the resumption of execution of the correlated instance can be defined inside the variable.

correlationVariables (compulsory)

All the correlation variables should be mentioned here. By default it performs the equal operation of that variables.

 tenantId (optional)