Generated Executions in Process State Machine
The executions you have defined in your BPMN process are - apart from the Get Data execution - generated to the process state machine (see MyProcess on xUML Service State Machines) to appropriate places.
Find below a list of where your code is generated to. This can be helpful if you are using the Analyzer to step through your generated service.
BPMN Element | Execution | Implemented on State Machine Element | Implemented With Activity Diagram / Example | ||
|---|---|---|---|---|---|
Start Event | On Event | All kinds of start event are triggering the process. Their implementations are generated to the transition that transitions the Initialized state of the root state machine to the first state of the process state machine. | behavior_<name of the event with underscores> | behavior_Start_Event | |
Service Task | On Exit | The implementation of service tasks is generated to the entry state within the process state machine that records that the service task has been performed (Executed_<name of the service task with underscores>, e.g. Executed_Service_Task). | behavior_<name of the task with underscores> | behavior_Service_Task | |
Receive Task | On Exit | Receive tasks are waiting in a state Waiting for <name of the receive task with underscores>, e.g. Waiting for Receive_Task, for the related message to arrive. | behavior_<name of the task with underscores> | behavior_Receive_Task | |
User Task | Get Data | The Get Data execution is not generated to the process state machine but to a dedicated REST resource <name of the process>Rest.InstanceResource.<name of the user task>Resource, e.g. ProcessRest.InstanceResource.User_TaskResource. | get_<name of the task with underscores> | get_User_Task | |
On Exit | Receive tasks are waiting in a state Waiting for <name of the user task with underscores>, e.g. Waiting for User_Task, for the form message to arrive. | behavior_<name of the task with underscores> | behavior_User_Task | ||
Events | Events can be used as intermediate or boundary events. | ||||
Plain Event | On Event | For plain and message events, this makes not much of a difference in terms of generating the process state machine. In both cases, when the event is registered, the process state machine transitions to the next state with a transition <name of the event with underscores>, e.g. Plain_Event. This is the transition the implementation from the process is generated to. | behavior_<name of the event with underscores> | behavior_Plain_Event | |
Message Event | On Event | ||||
Timer Event | On Event | Timer events define a waiting time, and after that time, continue the process (intermediate usage), or leave the current task (boundary usage). The state machine either waits in a dedicated timer state, or in the related user task state. | behavior_<name of the event with underscores> | behavior_Timer_Event | |
Decision Regular Sequence Flow | Decision | Gateways in the process are represented in the process state machine as choices. The sequence flows from the process are generated to transitions from the choice state to the next state. To these transitions the implementation on the sequence flows are generated. We recommend to give relations starting from a gateway meaningful names. This makes searching the trace data of the service execution a lot easier. | choice_<name of the arrow relation> | choice_Arrow_Relation_2 | |
End Event | On Event | The implementation that has been added to an end event is generated to all transitions that terminate with that end event. | behavior <name of the event with underscores> | behavior_End_Event | |
When tracing through a process with the Analyzer, you can use the Find function in the bottom left corner to search for the behavior diagrams listed in column Implemented With Activity Diagram.
Related Pages:
Related Documentation: