Introduction
Activity States
During process execution the engine manages a succession of activities through a number of states, from creation to deletion. While there are a number of activity types, each with its own properties and behavior (see “Activity Types” on
page 165), as a general rule, the engine takes each activity through a succession of states shown in the following table and illustrated in Figure
Activity state | Description |
|
|
PENDING | An activity is normally created and placed in PENDING state when |
| the router method of a completed (or aborted) activity or of an |
| expired timer names the new activity. The activity remains in the |
| pending state until all trigger conditions are met, at which time the |
| engine performs any work specified by a Ready method in the |
| process definition and then places the activity in READY state. |
READY | When an activity is placed in READY state, it is made available to |
| client sessions based on assignment rules specified for the activity in |
| the process definition. Depending on the type of activity, the engine |
| either offers it to each session whose user profile matches one or |
| more of the activity’s assignment rules (offered activity), places the |
| activity in a queue (queued activity), or places it directly in ACTIVE |
| state (automatic activity). When offered to a session, the activity is |
| placed on the session’s activity list (a list of offered activities |
| maintained by the engine for each session) and is then available to |
| the session’s client application. When placed in a queue, the activity |
| is available to any session whose user profile matches one or more of |
| the activity’s assignment rules. |
|
|
