Workflow instances

PolicyCenter saves a workflow instance as a row in the database marking the existence of a single running business flow. PolicyCenter creates a workflow instance in response to a specific need to perform a task or function, usually asynchronously. For example, in the base configuration, PolicyCenter creates a macro workflow as a companion to each newly-created Job (Submission, PolicyChange, Renewal, for example). This workflow is responsible for pushing the Job through its life cycle.

The newly created instance takes the form of a database entity called Workflow. Because PolicyCenter creates the Workflow entity in a bundle with other changes to its associated business data, PolicyCenter does nothing with the workflow until it commits the workflow. PolicyCenter does not send messages to any external application unless the surrounding bundle commits successfully.

After creation of the Workflow entity, nothing further happens from the viewpoint of the code that created the workflow. The workflow merely continues to execute asynchronously, in the background, until it completes. It is not possible, in code, to wait on the workflow, as you can wait for a code thread to complete, for example. This is because some workflows can literally and deliberately take months to complete.

All workflows have a state field ,a typekey of type WorkflowState, that tracks how the workflow is doing. This state, and the transitions between states, is simple:

• All newly beginning Workflow entities start in the Active state, meaning they are still running.
• If a Workflow entity finishes normally, it moves to the Completed state, which is final. A workflow in the Completed state takes no further action and exists from then on only as a record in the database.
• If you suspend a workflow, either from the PolicyCenterAdministration interface, from the command line, or through the Workflow API, the workflow moves to the Suspended state. A workflow in the Suspended state does nothing until manually resumed from the Administration interface, from the command line, or through the Workflow API.
• If an error occurs to a workflow executing in the background, the workflow moves into the Error state after it attempts the specified number of retries. A workflow in the Error state does nothing until manually resumed from the Administration interface, the command line, or the Workflow API.

The following graphic illustrates the possible workflow states:

This diagram does not convey any information about how an active workflow, a workflow in the Active state, is actually processing. For active workflows, Guidewire defines the workflow state in the WorkflowActiveState typelist, which contains the following states:

• Running
• WaitManual
• WaitActivity
• WaitMessage

Whether the workflow is actually running depends on whether it is the current work item being processed.