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

Message Events

represents a message which you can send to the process engine. This message can start a case, or influence an already running case. A message event consists of a name, and optionally a set of data which you want to include in your message:



You can define as many data fields as you like, but they all have to get a unique name. For every data field you have to define a base type, whether this attribute is multivalued, and whether this attribute is required. If an attribute is required, then you can count on the fact that this attribute is filled when catching this message.

Icon

The process editor has two type of message events, the incoming and the outgoing message event.

The described  functionality of the message event is introduced in version 9.1. The incoming and outgoing message event were available already before but with different functionality. The old functionality is still available, but we do advise not to use it any more since it is marked as deprecated.  For sending messages using a task with a connected flow is advised, for an example see: 4.7 Sending messages between processes.

An in sequence placed incoming message event still contains the 'event type' and the 'event' for the same reason, these should not be used any more as well.

Incoming message event

An incoming message event is a node where the process will wait until the process engine receives the specified message event. After catching the message event the process engine will store the connected data in the process engine database.

Example of message node in the process flow

Icon

The checkbox 'Display enhanced overview' enables a business engineer to hide or show the name below a message node in the process editor. By default the checkbox is checked. Like the picture above.

Rationale
There is no need to open a message node to understand what the message is about. On the other hand, extracting information can be useful to get a cleaner view on the model by deselecting the checkbox.

Parameters:

  • Persistency id: Auto generated ID for the node. It can be edited but must be unique within the process module to function.
  • Message type: the direction of the message event, for an adhoc message event it is always an incoming message.
  • Event Type: For the definition of the process events which are needed to flow from the node, two types are available: plain and cancel. The event type and event will not function together with a message event.
  • Event: For the definition of the process events which are needed to flow from the node, the created process events are available to select. The event type and event will not function together with a message event. 
  • Message Event: Using a dropdown the name of one of the available Message Events can be selected. This way the message event is connected to this node and will respond as modeled when this message event is received by the process engine. The corresponding fields which are available for the selected message event will appear on the screen.
  • Catching condition: A condition which can be inserted to assure that only the message node for which the condition is TRUE. The catching condition is modeled by selecting the name of one of the data fields available in the message. The condition will become TRUE if the value in the message equals the value in the profile of the case.
  • Target instance(s): There are two options, (1) Singleton and (2) SelectExistingInstance. When Singleton is selected, you can only store data from a message event on one or more singleton instances. When SelectExistingInstance is selected, you can store information from a message event on multiton instances.
  • Match on: This parameter appears when selecting SelectExistingInstance at the Target instance(s) parameter and it functions similarly to the Catching condition. The main difference is that all instances of selected type that are present in the process profile are searched for a match. Each instance that matches is updated with data from the message event.

    In this fictitious example there can be multiple instance of entity Company present in the profile of a process. When sending the 'UpdateCompany' (ad-hoc) message event, we want to update the income of a single company. We find the correct company by supplying the name of the company in the message event. The process engine then does something similar to 'Select Company from ALL Company WHERE Company.Name = CompanyName', in which the CompanyName is supplied in the message event. Each company instance found is updated.

    In this example is the entity Person singleton. Its atributes can be updated even when using the SelectExistingInstance setting. It is not possible to update two multitons at the same time.

  • Datafield name: A list of names of the data fields which are available in the message. These name are modeled at the Message event.
  • Target attribute: The entity and attribute can be selected in which the data which is carried with the message event will be inserted in the profile. The process engine will retain this data in the process engine database.
  • Data type: Information on type of data received in the message
  • Multivalued: Indicates if the data in the field can be multivalued.
  • Required: Indicates if the a value is required at filling the message. This field must be mapped to a target attribute.

Recommended reading

Message events: BPMN 2.0


  • No labels