WebSphere Lombardi Edition 7.2 > Modeling processes > Advanced modeling tasks > Modeling events

Model message events

Use a message event to represent a point in your process where an incoming message is received. Incoming messages can originate from a Web Service that you create, a message that you post to the JMS Listener, or simply by calling a UCA in a Lombardi service.

To create Web Services to initiate inbound requests from external systems, see Publish Lombardi Web Services.

To post a message to the JMS Listener, the Event Manager has a defined XML message structure that it must receive from an external system.

You can include the following types of message events in your BPD:

Event	When to use...	For more information, see...
	Use to model the start of a process if you want an incoming message event to kick off the process. A BPD can include more than one Start Message Event.	Use start message events
	Use to model a message event received during execution of the activities in a process. Intermediate Message Events can be attached to activities within your BPDs or they can be included in the process flow, connected with sequence lines.	Use intermediate message events

Before including any type of message event in a BPD, you should be aware of the following:

• Messages can be received by any running process that contains one or more message event.

• By default, when a message is delivered to a running process, the message is consumed by the first message event in the BPD that can accept it (as determined by the UCA that is attached to the message event). When a message is consumed, it will not be processed again by that message event, or any other message event in the BPD instance that can accept it, should the execution of the BPD instance loop back and reach the same message event(s). If a new instance of the message is delivered to the process instance, this message is available for consumption again and is accepted by the message event.

• Message events can be used to enable roll-forward scenarios in which the same message needs to be passed through multiple steps until it reaches the appropriate step in the process where it is to be consumed. To enable rolling a message forward through multiple message events, enable the Consume Message option only for the last message event in the chain of roll-forward message events. You can also use conditions to further control message consumption.

• Occasionally, you may need to set conditions on the processing of incoming messages. If the condition that you specify evaluates to true, the message is accepted and processing continues—otherwise, it is stopped. Because the message condition is evaluated before the message values can be passed to the input variables of the process definition, the message values are passed to the condition in a special namespace, tw.message. If the message condition evaluates to true, the values are passed from the tw.message namespace to the BPD input variables.

Use start message events

If you want a process to start when a message is received, use a Start Message Event in your BPD. For example, you may want an employee on-boarding process to start when a record for each new employee is created in your SAP HR system. When the record is created, the SAP systems sends an event to Lombardi. Lombardi captures the event and starts the follow-on steps for each new employee such as setting up the necessary space and computer equipment, requesting and creating a security badge, and so on. The following example describes how to model the Start Message Event in a BPD for this type of process.

When including start message events in a BPD, you should be aware of the following:

• The general information that applies to all types of message events covered in Modeling message events.

• When a message is received by a start message event (specifying that an incoming message is to start a process at run time), a new instance of the BPD is created and a unique BPD instance ID is assigned to it.

• If you use multiple start message events in a single BPD, use a separate UCA for each. If you use the same UCA for multiple start message events, Lombardi instantiates multiple instances of the BPD.

1. Open the BPD in the Designer and click the Diagram tab.

2. Drag a Start Message Event component from the palette onto the diagram.

3. Click the Implementation option in the properties.

4. In the Message Trigger section, click the Select button next to the Attached UCA field to select a preexisting Undercover Agent.

   To create a new UCA, click the New button

5. In the Condition text box, type a JavaScript expression if you want to define conditions under which the message event is processed.

   If you do specify a condition and the condition evaluates to true, the message is accepted and processing continues. If the condition evaluates to false, processing stops. In most cases, special message conditions are not necessary.

6. The Consume Message check box is selected by default. Clear the Consume Message check box if you do not want the incoming message to be consumed after it has been received by the message event. Refer to the bulleted list in Modeling message events to learn more about message consumption.

7. The Durable Subscription check box is not available for start message events, only for intermediate message events.

8. In the UCA Output Mapping section, map one or more of the listed UCA output variables to appropriate input variables when you want their run-time values passed to the BPD instance.

   For example, if the Start Message Event starts an instance of an on-boarding process when an employee record is created in your SAP HR system, you can map the employee information from the UCA to a local variable in the BPD :

   

Use intermediate message events

Include an intermediate message event in your BPD when you want to model a message event received during execution of the steps in a process. Intermediate message events can be attached to activities within your BPDs or they can be included in the process flow, connected with sequence lines.

To build a sample inbound integration that includes an intermediate message event

When including intermediate message events in a BPD, you should be aware of the following:

• The general information that applies to all types of message events covered in Modeling message events.

• By default, intermediate message events have a durable subscription. When a message arrives before a process has executed to a point where the event can accept the message, the durable subscription causes the message to be stored until the message event is reached. Only the most recently received message is stored.

• When the process execution reaches an intermediate message event, further execution along that path is blocked until an incoming message arrives.

• When you use an attached or intermediate message event, you must map an appropriate UCA output variable to a local variable in the BPD to ensure that the parameter values of the run-time message are passed to the correct BPD instance.

1. Drag an Intermediate Message Event component from the palette onto the BPD diagram so that it is attached to an activity.

   The event is anchored to the activity. To verify this, select the activity. If the activity's outline includes the event, the event is attached.

   For a sample of an intermediate message event that is included in the process flow, connected with sequence lines,

2. In the Attached Event Details section, the Close Attached Activity check box is enabled by default. This setting closes the attached activity when the message event is triggered. You want this behavior in cases where the receipt of the message event signals completion of the activity. Otherwise, clear this check box.

3. In the Message Trigger section, click the Select button next to the Attached UCA field to select a preexisting Undercover Agent.

   To create a new UCA, click the New button

4. In the Condition text box, type a JavaScript expression if you want to define conditions under which the message event is processed.

   If you do specify a condition and the condition evaluates to true, the message is accepted and processing continues. If the condition evaluates to false, processing stops. In most cases, special message conditions are not necessary because you should implement each message event with a separate UCA.

5. The Consume Message check box is selected by default. Clear the Consume Message check box if you do not want the incoming message to be consumed after it has been received by the message event. Refer to the bulleted list in Modeling message events to learn more about message consumption.

6. The Durable Subscription check box is selected by default for intermediate message events.

   This setting enables the message event to receive an incoming message, even when the message event is not in an active state. When a token is on a step, that step is in an active state.

7. In the UCA Output Correlation section, you must map an appropriate UCA output variable to a local variable in the BPD to correlate the message event with the BPD instance (Lombardi only requires one variable mapping to correlate the event).

Parent topic: Modeling events

+

Search Tips   |   Advanced Search