Page History

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:

...

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:

...

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 - Receive the Message Event in the Case Process

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. Make sure there is some follow up action modelled to actually process the message event. Probably an automatic task. For example:

...

When this process starts, it will start waiting on an incoming message event. When it has arrived, it will map the information to the process profile (selected on the right) and flow to the task below. The task is an automatic task to process the data which has just been stored in the process. In my example, this process is a repeatable ad-hoc process, so it will restart itself after the task has finished.

Step 4 - Process the data in an automatic task

The automatic task to process the message event should contain a DCM_GetCaseInfo to retrieve the actual data from the message event, and map this to the dossier. From this point on, you can do whatever is needed to process the data. In my example just adding an involved user to the set of users. But this could also mean retrieving the "changed" data from the source that has sent the message event in the first place. When a contact person has changed his details for example, toe response could be calling the system to retrieve the new contact details and adding them to the case for later use.

...

Another change could be that your logic on how to proceed with the case changes, for example an extra task becomes available to assess the new change, or maybe the goal of the case has been reached after change. It is up to the Business Engineer to do whatever is needed.

Future state

We are aware of the number of steps needed to process a message event. In the future we are aiming to make this much easier for the Business Engineer.