![]() ![]() |
|
Help for Process Engine Reference | |
Search | Index | |
![]() |
|
![]() |
![]() |
![]() |
About step statesAt a high level, each step in a workflow represents one activity within an overall business processfor example, verifying employment status in a loan processing workflow. For most users the concept of a step as a single action is appropriate, though in actuality a step goes through a series of discrete phases, known as states. Within each state, the system software performs one or more operations on the work item. Generally, step states are transparent to users; however, workflow authors and application developers might need to understand step states to make informed decisions in workflow definition and application design. Following is an overview of the operations that can occur within a step. The operations are listed sequentially and are grouped into their respective states (each state is numbered). The overview also shows points at which the flow of control can move to another workflow map (indicated by =>). NOTE Under certain circumstances, the behavior of work items created in an earlier version of the Process software that was subsequently upgraded deviates from the behavior described below. See Behavior for pre-5.0.0 work items for additional information.
A workflow map that takes control (at a point marked with => above) could contain a Return system function. Each Return includes a retry option that tells the Instruction Sheet Interpreter (ISI) to either skip or repeat the state containing the calling entity when control returns to the original workflow map. For example, if an exception occurs in the post-assignment state during execution of post-assignments (7b above), that exception is the calling entity. If the ISI reaches a Return system function on the called workflow map, control returns to the original (calling) workflow map. Depending on how the Return is defined, the ISI either repeats or skips the post-assignment state upon return to the calling workflow map. Note that the repeat or skip setting applies to the state, not to the operation within the state that triggered the calling entity. The table below indicates the ISI behavior corresponding to both return and skip.
For further details on setting the retry option to repeat or skip, see Return system function. Behavior for pre-5.0.0 work items Prior to release 5.0.0, there were only two step states: pre-step and post-step. The pre-step state included what are now states 1 through 6, while the post-step state included states 7 through 9. Following an upgrade to release 5.0.0 or later, most work items that existed in the system prior to upgrade are converted to the nine-state model for the remainder of their processing. However, if both of the following conditions are met, a work item retains the two-state model for part of its post-upgrade processing:
Under these conditions, the upgraded work item retains the two-state structure until the submap completes execution and control returns to the original map. Under the two-state model, the Return system function's repeat and skip options still behave as described above, in terms of moving the work item to the beginning of the current or next state. Once control returns to the original map, the work item is converted to the nine-state model for all subsequent steps (even for subsequent steps that call a submap).
|
![]() |
|
![]() |
|