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

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.

  Example

  

  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.