Starting the execution of a new process instance is equivalent to creating a new persistent state instance. According to the concept of persistent state, this is done by a create action of the persistent state adapter.
In contrast to the persistent state concept, a business process might have several divergent start events. In UML this is represented by divergent start signals send after the creation of the persistent state instance. For each distinct start event the generated model contains a port type operation that is creating a persistent state instance and sending the corresponding start signal immediately thereafter.
In the loan approval example, there is just one start, but nevertheless the signal has to be sent to trigger the process in the root state machine.
Each signal has its own corresponding message class assigned to. Message classes can be found in package Messages of the generated service. Port type operation createProcessByStart of the LoanApprovalExample receives messages of type CreateProcessByStart.
All these message classes contain the mandatory attribute processID as the primary key of the persistent state database to identify the process instance the message is send to. Additionally, user may add attributes that are needed to implement the process. In the example case these are creditAmount and customerID.
The action Prepare Process Instance is used to set the primary key (id) of the persistent state object and to initialize other attributes of the object that may have been added to the persistent state class. In the LoanApprovalExample these are customerID and creditAmount.
The picture below shows the implementation of the port type operation CreateProcessByStart. In action Prepare Process Instance, the additional attributes of the message class are mapped to the corresponding attributes of the persistent state class via action script.
In the picture below, changes with respect to the generated activity are marked in red.
Overview
Content Tools