You are viewing the documentation for Blueriq 15. Documentation for other versions is available in our documentation directory.
This service call is part of the ongoing effort to support more DCM features natively in the Blueriq Runtime. Its signature and behavior may change over time. Please check release notes and upgrade instructions when using it.
This service call definition is part of the DCM library. It is only available when the case-engine-client profile is enabled.
How the process engine behaves when receiving a message event is completely dependent on what was modeled in the process module. There is no default action executed when receiving a message event. Examples of behavior that you can model include: Starting a new case or making a task available to the worklist, cancelling a case, or placing information in the domain of the case.
With this service you can send a Message Event to the case engine, which will send it to the process engine. You can select a message event which you have previously defined in the process module. For every defined data field, you can define an expression to fill the field with information. The context of this expression is the module in which you place this service.
Contrary to the DCM_ThrowMessageEvent, this service is asynchronous. When the DCM_ThrowAsyncMessageEvent service is called, it will publish a message on a queue which will then be picked up and processed by the case engine. This means that it is not possible to receive the affected case ids. For this, use the DCM_ThrowMessageEvent.
Parameters
| Name | Description | Type | Required | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Message event | The name of the message event that will be triggered. | Message event | true | ||||||||||||
| Values | These elements represent the content of the message. You have to specify what the result attributes will be. | Elements | false | ||||||||||||
| Send to specific Case Ids | If you want to send the message to (a) specific case(s), then you can supply the id(s) of the receiving case(s) here. The specific caseId(s) do not have to be part of the message, but could be. If you do not specify this parameter, the message event is broadcasted to all cases
| Expression | false |
When sending a message to a specific case, it is not necessary to have a catching condition on the receiving message node.
A combination of a catching condition and specific case Id is possible. You can send a message to a select number of cases and still use the catching condition to decide to process the message or not.
When sending a message that is used as an event to create an process, then only the new process is created. The event is not broadcast to all other cases. So if you use an event as ProcessStartNode you should not reuse it as an Adhoc event or inline event inside processes.
Non-existing processess
When the message is sent to specific processes, and some of these do not exist any more, the service ends with a FAIL exit IdError. You have to map this exit to an event in your model in order to catch this. In this case, no processes will receive the message.
Inner workings
The service publishes an event to the Case Engine which will in turn ask the Process Engine to which cases it should send the Message event. The case engine will then publish an event to the queue for every case. If a message fails it will automatically be retried. While this service is asynchronously handled, the affected caseIds will not be added to the profile.
Overview
Content Tools