Using start message events

1. If receiving and processing the message causes completion of the parent process, make sure that the Interrupt Parent Process option is selected, which is the default setting. When this option is selected, when the subprocess reaches its end, the parent instance is completed. Otherwise, clear the selection so that the parent process is not interrupted or completed when the message is received.
2. If Interrupt Parent Process is not selected, the Repeatable option is available. If the start message event can be triggered more than once, select the Repeatable option so that the subprocess can receive multiple messages.

1. For Triggering Mechanism, select UCA.
2. To select an existing undercover agent, click Select next to the Attached Message UCA field.
3. To create an undercover agent, click New. See Undercover agents.
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 undercover agent.

5. If you want the incoming message to be consumed after it is received by the message event, enable Consume Message. Refer to the bulleted list in Modeling message events to learn more about message consumption.
6. The Durable Subscription check box is not available for start message events, only for intermediate message events as described in the following section.

1. For Triggering Mechanism, select SCA Service.
2. For Message Object Type, click Select to select a business object (BO) type, click New to define a new BO type, or leave it to be set automatically when you select a service definition. The business object type that you select determines the output parameters of the start message event. The message object type must be a complex type.
3. For Service Identifier, a default value is provided, based on the name of the event, as shown in the BPD diagram. If you want, you can either specify a different service identifier name, or select one from the drop-down list of services that match the selected message object type. If you enter a name, it is restricted to using the NMToken character set.
   • If you selected an existing service definition and the message object type was not set, the message object type is updated to match the service definition.
   • The service identifier is used with the BPD name to generate a unique SCA service for this event point. The generated service interface name is displayed.
   • If you selected an existing service definition, the associated events are added to the list of events that the definition includes.
   • To restore the default value, click the X (delete) icon.
   • If you specify the same SCA identifier for multiple message events, any changes to the service identifier or message object type affect all the events that provide the service. Making such changes can break data mappings for the events.
   Tip: If your BPD includes more than one start message, each one should use a different SCA service identifier. Otherwise, if multiple start message events specify the same SCA service identifier, the start event that receives the start message is selected arbitrarily.

   If you specify the same SCA identifier for multiple message events, the service interface can trigger multiple events in the BPD. However, each incoming message is received by only one of the events. Which event receives the message, or whether it is stored for future delivery, depends on whether a correlating process instance is found, and if so, which compatible message events are in the waiting state. For details of the semantics, see Using Service Component Architecture to interact with processes.

   Important: It is possible to define unintentionally the same service identifier on multiple events. For example, if different events have identical names (which is shown as an error on the General tab), or if different service identifiers map onto identical NMToken strings. If such a naming clash happens, you can break the unintended polymorphism by renaming the duplicate event names and then click X (delete) to restore the default service identifier name.

1. On the Properties tab, click Data Mapping.
2. Open the Correlation and Output Mapping section.
3. Select the output variable that you want to use to for correlation. The value that is assigned to it ensures that the parameter values of the runtime message are passed to the correct BPD instance. The variable that is selected for correlation is identified by an assignment symbol (). This correlation ensures that the parameter values of the runtime message are passed to the correct BPD instance.
   • For undercover agents that are implemented using a complex variable rather than a service, you can select the complex variable or the top-level child properties of the variable for mapping or correlation.
   • If you use SCA, you must select a variable that is marked as a process instance identifier that ensures that the message is passed to the correct BPD instance based on the value of that variable.
4. Map each output variable to a local variable in the BPD. For each variable, click the variable selector icon to map each output variable to be passed into a local variable in the BPD.

For example, if the start message event starts an instance of an on-boarding process when an employee record is created in your HR system, you can map the employee information from the undercover agent to a local variable in the BPD.

If your start message event is inside an event subprocess, you must select a variable to be used for correlating process instances. Correlation allows IBM BPM to identify the process instance that the message is meant for.

For example, an employee number might be used to uniquely identify an instance of an on-boarding process. Selecting this variable for correlation ensures that when the data related to a specific employee number is passed to the event subprocess, the appropriate instance of the on-boarding process is found.