Page History
...
| Tip |
|---|
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. |
| Tip |
|---|
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). |
| Info |
|---|
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. |
| Info |
|---|
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. |
| Info | ||
|---|---|---|
| ||
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. |
Overview
Content Tools