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 ElementExecutionImplemented on State Machine ElementImplemented With Activity Diagram / Example
Start Event
Message Start Event
Timer 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.
The name of the transitions is generated as <name of the event with underscores>, e.g. Start_Event.

behavior_<name of the event with underscores>

behavior_Start_Event
behavior_Message_Start_Event

behavior_Timer_Start_Event

Service TaskOn 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 TaskOn 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.
When this is the case, the process state machine transitions to the next state with a transition <name of the receive task with underscores>Received, e.g. Receive_TaskReceived. This is the transition the implementation from the process is generated to.

behavior_<name of the task with underscores>behavior_Receive_Task
User TaskGet DataThe 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 ExitReceive 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.
When this is the case, the process state machine transitions to the next state with a transition <name of the receive task with underscores>Done, e.g. User_TaskDone. This is the transition the On Exit implementation from the process is generated to.
behavior_<name of the task with underscores>behavior_User_Task
Events

Events can be used as intermediate or boundary events.


Plain EventOn Event

For plain and message events, this makes not much of a difference in terms of generating the process state machine.
The state machine is either in a state that waits for the event to happen (intermediate usage), or in a task state, waiting for message reception (boundary usage).

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
behavior_Message_Event

Message EventOn Event
Timer EventOn 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.
The waiting time is generated as a Time Event to the transition to the next 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.
The name of the transition is generated as <name of the arrow relation with underscores>, e.g. Arrow_Relation_2.

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 EventThe 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 Documentation:
  • No labels