4. Handling Message Events

Introduction

The Case bundles all kinds of information in order to help the case workers in achieving their goals. This information might change, possibly leading to a different approach on getting to the goal. Changing a contact person for example, might lead to the need for sending a notification from the Case, or the change of a house address might lead to a needed recalculation of an offer on an insurance policy which was not yet completed.

These are examples of some other party, notifying the case engine that something has changed. Blueriq offers a possibility to send this notification to the Case-Engine, and make sure the consequences are determined after receiving the message. However, it takes some skill for the Business Engineer to run through all necessary steps. Below is an explanation on how to achieve this.

How to model Handling a Message Event

An example on how message events can be modelled.

Step 1 - Create a REST interface to retrieve messages

If some other system should be able to send events to a Case, it would probably needs to to this using either a REST or SOAP message. Therefore the first step would be to construct a BAA(R)S service to receive the message. This service needs to determine:

• what message is should be thrown
• which cases are affected and should be updated using the message event

The Message Event Type could correspond to an actual Message Event Type in de model. This can be added using the process module. In my example We're going to assign a case to a case worker. Meaning we will add the person to the involved users list of the case. Granting him access to the case as a case worker. In my example I already know which case I want to assign, so the input REST message contains a specific Case ID, and the username + userid of the user I want to assign.

A webservice implementation flow could look like this:

Step 2 - Send an actual Message Event to the right case

First some extra checks on the input of the service, when everything is valid, We will throw the message event to the right case:

The REST service pushes a message to the queue of the Case Engine and flows to the exit.

When no CaseID s sent in the DCM_ThrowAsyncMessageEvent service (the field is left empty), the event is thrown to all cases with the same Application ID. This might for example make sense when you want to migrate all cases with the same type after publishing a new model to the Runtime/Case-Engine.

Step 3 - Catch the incoming Message Event

The Message is thrown to the process of the corresponding case. Make sure the process is listening to events of that specific type when the event is thrown. This can be done by adding the message event listener to the process. The Message Event will be processed by a flow, so it does not have to be connected to a followup action. Connecting it to some conditional or exit suffices, since the milestone is required, the process flow remains open.

When this process starts, it will start waiting on an incoming message event. When it has arrived, it will start processing the message event:

1. The message event is set to "started" in the database, in the same transaction the case will be locked
2. The event to process the message event is sent to the queue (including the incoming data fields).

Step 4 - Consume the incoming Message Event

The Runtime consumes the message by starting a MessageEventFlow. Just like an automatic task, the message is processed, and sent back to the Case-Engine (queue) to complete the message event.

1. A Runtime that consumes this queue picks up the message.
2. The Runtime searched for a flow of type "MessageEvent" configured to process the message event of the given type
3. The dossier is loaded containing the latest state of the case
4. The incoming data is mapped to the profile using the parameters of the MessageEventFlow
5. The flow is executed, so the Business Engineer can determine what to do in the case

After the Runtime is done, a MessageEventCompleted event is sent back to the Case-Engine. Containing all data to finish the MessageEvent

1. The resulting dossier is sent back to the Case-Engine to be processed, along with the process mapping that is configured in the MessageEventFlow parameters
2. The Case-Engine processes the message event data, performs a process mapping and determines what to do next
3. If the Message event is repeatable, it might be set to listen again