Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Include Page
_DCM2ServiceCall
_DCM2ServiceCall

With the DCM_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 Ids

The id(s) of the receiving case(s). The specific caseId(s) do not have to be part of the message, but could be.

parameter valueresult
not specifiederror
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.
Expressionfalse
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 integerfalse
Message eventThe name of the message event that will be triggered.Message eventtrue
ValuesThese elements represent the content of the message. You have to specify what the result attributes will be.Elementsfalse



Image RemovedImage Added

DCM_ThrowMessageEvent vs DCM_ThrowAsyncMessageEvent

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 of 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 consider carefully which service you need for your use case. It's also possible to broadcast a message event to all listening cases using the DCM_ThrowAsyncMessageEvent, this is not possible using the synchronous service call.

...