The runtime engine is implemented with an asynchronous transport based message driven interface whereby a message or document must be sent to the running instance of the engine to instantiate an instance of a business process. From within the design-time environment, all inbound messages or documents are modeled as WSDL-based service interactions of type ‘Notification’. Additionally, the design-time environment requires that distinctions must be made between messages that can instantiate a new instance of a business process and those that cannot. This requirement is important from a design perspective in that every business process must have at least one notification defined with the ‘initializer’ property set to true.
The distinction between messages that can instantiate a new instance of the business process and those that cannot also requires knowledge of the order by which messages can arrive during runtime. The following examples illustrate how the order of message types is relevant to business process instantiation:
A purchase order process might require that the business process can only begin with a message representing the purchase order request. All other message types such as status request, or credit verification are required to be preceded by a purchase order request. The business process definition would only require a single notification defined with the ‘initializer’ property set to true.
A customer service process might encapsulate any number of sub-processes and have corresponding request message types such as a billing inquiry, order status, or new order. In this case, all of these message types would include the customer number as the means for instantiating the business process instance. The business process definition would require that each of these notifications be defined with the ‘initializer’ property set to true.
The other key feature of the runtime engine is that the identifier used for the business process instance once it is instantiated is generated from attributes within the inbound message and subsequently used as a global correlation mechanism for the routing of all messages. The implication of this feature is that all messages associated with a business process instance are ultimately correlated based on data within the messages.
Important! When notification that are defined without the ‘initializer’ property set to true arrive before notifications with 'initializer' set to true, they will be held for processing until after the initializer notification arrives and the business process instance is created. For example, notifications B and C would be held until notification A arrives as detailed in the properties for the notifications in these examples of notification set as initializer and notification not set as initializer.
