You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.

With the AQ_ThrowMessageEvent service call you can throw Message event towards 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.

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, canceling a case, or placing information in the domain of the case.


Parameters

NameDescriptionTypeRequired
Send to specific Case Id:

If you want to send the message to (a) specific case(s), and not broadcast it to all running cases, 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.

parameter valueresult
not specifiedmessage is broadcasted to all running cases
invalid expressionerror
expression results in unknownerror
expression results in empty listnothing is sent
expression results in a list of case idsmessage is sent to the case ids in the list. Note that if one or more of the case ids does not exist, the service will take a fail exit called IdError. You have to map this on an event in your model.
ExpressionNo
Case Ids Target AttributeThe case ids of the case affected by the message event are placed in the selected attribute. This attribute must be multivalued and of the type integer.Multivalued integerNo
Message eventThe name of the message event that will be triggered.Message eventYes
ValuesThese elements represent the content of the message. You have to specify what the result attributes will be.ElementsNo

AQ_ThrowMessageEvent vs DCM_ThrowAsyncMessageEvent

DCM 2.0

The DCM_ThrowAsyncMessageEvent service call type is only available when you use the Case Engine setup, which is still in development.

Next to this service, the DCM_ThrowAsyncMessageEvent is also available. As the name suggests, that service works asynchronously as opposed to this service which is synchronous. The benefit of using the asynchronous service is that a user does not have to wait for the message event to be processed, which could take some time if the message event is broadcast to a lot (if not all) cases. The downside of the asynchronous service is that you no longer receive the affected case ids, as you do not have to wait. So assess carefully which service you need for your use case.

Note that you also need to enable the case-engine-client  profile in the runtime to execute the DCM_ThrowAsyncMessageEvent service.

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.

If you have created a process and you want to extract it's Id and save it in an aggregate then extract the value returned from the Case Ids Target Attribute. For example use the AQ_InstanceUpdate service to unpack the multivalued attribute by using an expression like this: UNPACK(Control.ProcessIds).

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 broadcasted 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.

Events are stored in the database (events table) for when they need to be replayed. When an event is not thrown to a specific process-id (for example broadcast to all processes or create a new process), the event is never automatically cleaned from the database, and should be deleted manually.

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.