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 the
commit. 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.
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?
