Events in Cordys

  

In certain occassions BPM processes need to able to process events.

 

Consider the example of a sales process (e.g. CloseDeal) that sends a quote to a customer and waits for the response.

Handling client responses may be the task of a separate process (e.g. ReceiveQuotationResponse) which listens to a specific channel (e.g. SMTP) for customer messages. Once a response (e.g. a reply on a quote) is received it simply should be passed on to the waiting process (CloseDeal), to allow it to process the response and continue.

 

The good news is that BPMN provides an event mechanism via  “Send Message” and “Receive Message”  steps. Though implementation of a case similar to the one above in Cordys BOP-4 (CU9) is a bit more complicated than one would expect. The issue is that Cordys supports only the Send Message step for child-processes to trigger an event in a parent process.

In our case this is not sufficient, as ReceiveQuotationResponse is not an child but an independent process.

 

Fortunately Cordys offers a work-around:

It allows to start new and to continue existing (waiting) process instances by using an “ExecuteProcess” webservice.

 

How does it work?

The process to be notified of the event (CloseDeal in our example case) should include a “Receive Message” step at the position where the notification event is expectewd (e.g. just after sending the quotation).

In the properties of the “Receive Message” step the input message must be set. This is the (Process Specific defined) message that is expected with the notification.  

 

The notifying process (ReceiveQuotationResponse ) now may invoke the ExecuteProcess web service (found in BPM runtime references “Method Set Process Execution”) to send a notification to the waiting process.

 

This invocation has 3 mandatory input parameters to be set:

• The field “type” must contain (the literal) “instance”
• The field “message” must contain a correct (and complete) message instance of the type that is expected by the waiting process (and hence is having the same definition as the one in the “Receive Message).
• The field “receiver” should contain the correct instance id of the waiting process. The instance id can be obtained from the instance properties (instance:identifier) of the waiting process.

 

Passing the instance Id

The question is: How can the notifying process (ReceiveQuotationResponse) obtain the instance id of the process to be notified?

 

The solution I developed requires a correlation id. The correlation id is an identifying field that is available in both processes and equal in instances of of these processes that are related in this context. In case of the sales process the Quotation Id may be used for instance.

The waiting process stores the instance id together with the correlation id in a database table. The notifying process may use the correlation id (e.g. received in the customer message) to retrieve the instance id, and use pass this with the ExecuteProcess invocation.

 

In concrete the solution requires:

-          A database table, consisting of (at least) two fields: CorrelationId (primary key) and InstanceId (and an access web services)

-          Two steps (at least) in de the process that should receive the notification:

o   The step is to store the instance id with in de database together with the correlation id

o   The second is a “Receive Message” step

-          Two steps (at least) in the notifying process

o   The first to read the instance id based on the correlation id

o   The second to invoke the ExecuteProcess

 

Note that the approach may require additional processing like cleaning up the database table and error checking.

 

A future enhancement in Cordys to the Send en Receive message steps that allows to specify a correlation id would be a great improvement.