Skip navigation FileNet logo
Glossary  |  Help Directory  
  Help for Process Engine Reference  
  Search  |  Index  
Concepts
  About attachments
  About the Component Integrator
  About launching a workflow
  About milestones
  About operations
About the RMI registry
About rosters
About routing
About rules
  About security
  About security queues
  About step processors
  About step states
  About system maps
  About transfer
  About workflow fields
  About workflow maps
  About workflow participants
  Component queue security issues
  Content Engine (CE) operations
  Coordinate information
  Custom web applications
  Eliminating port 32771 conflicts
  Java Runtime Environment (JRE)
  Maximum index key size
  Naming conventions
  System fields
  Troubleshooting
  Wildcards
  Workflow database field size limitations
  Workflow exceptions
Events & Statistics
Expressions
Procedures
   

About step states

At a high level, each step in a workflow represents one activity within an overall business process—for 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.

  1. Before Step
    1. Join children with parent in Delay queue
    2. If last child, then advance parent into the step
  2. Pre-Condition
    1. Clear F_Comment
    2. Clear F_Responses and F_ResponseCount
  3. Pre-Assignment
    1. Execute pre-assignments
      1. [=> Exception]
  4. Milestone
    1. Execute pre-milestone
  5. Deadline
    1. Calculate deadline expression
      1. [=> Exception]
    2. If necessary calculate reminder expression
      1. [=> Exception]
  6. Queue
    1. If necessary split into multi-participant work items
    2. If necessary queue work item. While the work item is in a queue:
      1. [=> API call]
      2. [=> API exception]
      3. [=> Timer expiration]
  7. Post-Assignment
    1. Check responses
    2. Execute post-assignments
      1. [=> Exception]
  8. End Step
    1. Execute post-milestones
    2. Evaluate routing
    3. Clear F_Responses and F_ResponseCount
    4. Clear F_Comments
  9. Route
    1. If necessary split into children
    2. If necessary store the parent in the Delay queue
    3. Move the work item or work items into the next step

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.

Retry option ISI behavior upon return to calling map
Repeat Move work item to the beginning of the state it was in when the other map was called.
Skip Move work item to the beginning of the next state (that is, the state following the state the work item was in when the other map was called).

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:

  • The work item was created in a pre-5.0.0 system that you subsequently upgraded to release 5.0.0 or later, and
  • At the point of upgrading, the work item was in a submap.

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).