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?
No comments:
Post a Comment