Overview of the Workflow Engine

Overview of the Workflow Engine

You now know the function of the Workflow Engine in Oracle Workflow. In this section, you will learn more about how the Workflow Engine executes and enforces each item’s defined workflow process. You will also learn how to use Workflow Engine APIs.
The following section explains how the workflow engine manages a process and how to
apply Workflow Engine APIs to functional activities.

How the Workflow Engine Manages a Process

The Workflow Engine drives items through workflow processes defined in Oracle Workflow. Each item has a set of attribute values that contains information about the specific item. A workflow process consists of a combination of activities and transitions. An activity can be a function, a notification, or a process. At any point in time, there may be more than one item passing through the workflow process. These items, which can be at found at any activity or at any transition within the workflow process, have their own sets of attribute values. When in the middle of the workflow process, each one of these items with its own set of attribute values is referred to as one instance of the workflow process. Each instance can have a different state. The state of the instance or item is defined by the states of all activities of the workflow process. The Workflow Engine manages all instances of defined workflow processes.

The following describes how the Workflow Engine manages a workflow process. The
Workflow Engine is a PL/SQL program residing on the server. It receives APIs from the
clients whenever an activity needs to change state. Valid states of an activity are Active,
Complete, Deferred, Error, Notified, Suspended, and Waiting. Once the Workflow Engine
changes the state of the activity, it evaluates the changed state of the activity. If the
activity is changed to a state of Error, the Workflow Engine rolls back the changes made
by the erred activity and initiates the defined error-handling routine. The Workflow Engine will first try to run the error-handling routine associated with the erred activity. If no error handling routine is attached to the erred activity, the Workflow Engine will trace back to the erred activity and determine the parent of the activity. If no error-handling routine is attached to the parent activity, the Workflow Engine trace back to the parent of the parent activity until there is an error-handling routine. Oracle Workflow comes with a default error process, or you can create your own custom error-processing routine that will reset, retry, or ship the erred activity.

If the activity is changed to a state of Active, the activity will be executed, unless the
activity has a processing cost higher than the Workflow Engine threshold. Executing an
activity means running a function activity in run mode, sending notification for notification activity, or initiating a subprocess in a process activity.
In the case where an activity’s processing cost is higher than the Workflow Engine
threshold, the state of the activity will change to Deferred. Activities are marked as
Deferred in order to streamline processing. Deferred activities are run in background
batches, not in real time. The Workflow Engine running in the foreground has a defined
threshold activity processing cost. If the processing cost of an activity exceeds the
defined threshold, the foreground Workflow Engine will not execute the activity and marks
it as Deferred. The background Workflow Engine picks up all deferred activities and
executes them. You can have more than one background Workflow Engine. To further
streamline workflow processing, each Workflow Engine can have different thresholds so
that other background Workflow Engines can pick up deferred activities with varying
processing costs. Setting up background Workflow Engines is optional, but you need at
least one background Workflow Engine to handle timed-out notifications.
If the activity is changed to a state of Complete, the Workflow Engine issues a savepoint
and evaluates all of the transitions tied to the completed activity. A savepoint is different
than a commit. You can roll back to the savepoint, but you cannot roll back after commit. The Workflow Engine never issues a commit; the calling application is responsible for thecommit. If the activities that depend on the completed activity have not been executed before, the Workflow Engine will change the state of the dependent activities to Active. If the activities that depend on the completed activity have been executed before, this will cause a loop. Depending on the setup, the Workflow Engine will then do one of two things.

If the executed activities are marked as Run Once, the Workflow Engine will simply skip
those transitions. If the executed activities are marked as Loop Reset, the Workflow Engine reverses all of the executed activities in the loop from the loop reset point and reexecutes the activities. Reversing all of the executed activities means running the function activities in cancel mode and marking notification activities as Cancelled. The Workflow Engine reverses all of the executed activities in reverse order back to the loop reset point and reexecutes the activities in the normal order from the loop reset point on. If the completed activity also marks the completion of the workflow process, the Workflow Engine will mark the workflow process as Complete and all outstanding or incomplete activities will be marked Complete with a result code of #FORCE.

In summary, the Workflow Engine can perform the following functions for clients:
· Change the state of an activity
· Function activities
· Notification activities
· Process activities
· Transitions
· Error handling
· Maintain workflow history

Changing the State of an Activity

The Workflow Engine changes the state of the activity. Valid states are:
· Active The activity is ready for execution.
· Complete The activity has been completed and is ready to transition to the next
activity.
· Deferred The activity is ready for execution; however, when the processing cost
is higher than the foreground Workflow Engine cost threshold, the activity is deferred
and eventually executed in the background by the Workflow Engine.
· Error The activity erred and must be rolled back.
· Notified The notification activity needs a response and a notification has been
sent to solicit a response.
· Suspended The activity has been completed, but the transition is on hold until the
activity is resumed.
· Waiting The completed activity is waiting for other activities in a master detail
process to be completed before transitioning.

Function Activity
Function activities are stored in PL/SQL procedures. Each function activity should have
two modes: run and cancel. The run mode is for execution of the function activity, while
cancel mode is for reversing the function activity. The Workflow Engine can accept
parameters from the clients and, depending on processing cost, execute the function
activity either in real time or in the background.
Notification Activity
Notification activities are messages. The Workflow Engine can accept parameters from the clients and send messages to users or roles, which are groups of users. A notification
activity can also solicit responses.


Process Activity
A process activity is a separate workflow process, which can be a subprocess or a process within a process.
Transitions
When an activity is completed, the Workflow Engine evaluates the transitions and
determines whether to mark activities that depend on the completed activity as Active.
When the activity marking the completion of the workflow process is finished, the Workflow Engine can mark the process as Complete. If the transition to Active has already been executed, the Workflow Engine may ignore the transition or reverse and reexecute activities.
Error Handling
If an activity erred, the Workflow Engine rolls back the activity and executes the defined
error-handling process.
Maintain Workflow History
The Workflow Engine maintains records of all completed or erred activities so that they can be reviewed online or through reports. Workflow Monitor uses this history for reporting the status of an item.

Review Questions
1. When will an activity be deferred?
2. What will the Workflow Engine do if the activity erred?
3. If you have Loop Reset on, and the Workflow Engine comes to an activity that has
been executed, what will happen?
4. What can happen when evaluating transitions?


1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17
*/