How to perform authorizations during BPMN process instance initialization

When designing the BPMN workflow, users can define either the candidate start users or groups.  This permits only the allowed users to start an instance.

Requirements

• WSO2 Business Process Server 3.5.1 ( Beta version can be downloaded from here).
• BPMN Modeling tool. Further information on how to set up this tool can be found at WSO2 Business Process Server Documentation site. 

Candidate start users/groups can be configured like this in Activiti eclipse designer

candidate users/groups can be defined either directly or by defining variables. T

The direct way is to define the user name or group name like admin1, manager etc ...

On the other hand we can use the variables to define the user name or group name as well like ${user1}, ${mgr1}.

The value for these defined variables can be defined in 2 ways. Those are static way and dynamic way.

Static Way

This is similar to variable declarations. This value can be set under the "Data Objects" section of process definition.

Dynamic Way

When invoking the process definition with the REST start call,  you can define the dynamic variable inside "variables" json array.

When starting the process instance following URL should be hit with the json message request
https://localhost:9443/bpmn/runtime/process-instance.

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 authorization failure REST API will return with 401.

How to Skip the BPMN instances creation with same variable state in WSO2 BPS

This post describes on how to skip the BPMN instance creation with same variable state in
WSO2 Business Process Server 3.5.1 .

Currently in the BPMN Rest API, process instance start operations are not conditional. But there are occasions, process instances  should not be initialized when ever there is a already created instance with same variables state (variable values).

This is the sample request that we use to start a process instance.

In order to make sure that only single instance is being created for an unique value, we can use the "businessKey" attribute. Although this is the most preferred way this won't work every time.

This may fails on following occasions.

• Business key attribute value can not be updated during the run time. Therefore, If the business key is not known before the instance creation, we shall not be able to update it.
• In the event of considering more than one variables to determine the instance state, we can't use the business key attribute.

Therefore as a solution to those issues, WSO2 Business Process Server 3.5.1 introduces a new Boolean flag "skipInstanceCreationIfExist" in the request.  By default the value of the flag is false.

This sample request can be used to start the process instance

This flags looks for the process instances with variables which have the values  defined in the process instance request. In the event of existence of any process instances with the same variables state, instance creation will be skipped. 

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)