Overview of the Workflow Engine
The Workflow Engine manages all automated aspects of a workflow process for each item. The engine is implemented in server-side PL/SQL and is activated whenever a call to a workflow procedure or function is made. Since the engine is embedded inside the Oracle database server, if the Workflow server goes down for any reason, the Oracle database server is able to manage the recovery and transactional integrity of any workflow transactions that were running at the time of the failure.
Additionally, Workflow Engines can be set up as background tasks to perform activities that are too costly to execute in real time.
The Workflow Engine performs the following services for a client application:
- It manages the state of all activities for an item, and in particular, determines which new activity to transition to whenever a prerequisite activity completes.
- It automatically executes function activities (execution is either immediate or deferred to a background engine) and sends notifications.
- It maintains a history of an activity's status.
- It detects error conditions and executes error processes.
The state of a workflow item is defined by the various states of all activities that are part of the process for that item. The engine changes activity states in response to an API call to update the activity family of calls. The API calls that update activity states are:
Based on the result of a previous activity, the engine attempts to execute the next activity directly. An activity may have the following status:
- Active--activity is running.
- Complete--activity completed normally.
- Waiting--activity is waiting to run.
- Notified--notification activity is delivered and open.
- Deferred--activity is deferred.
- Error--activity completed with error.
- Suspended--activity is suspended.
Attention: The Workflow Engine traps errors produced by function activities by setting a savepoint before each function activity. If an activity produces an unhandled exception, the engine performs a rollback to the savepoint, and sets the activity to the ERROR status. For this reason, you should never commit within the PL/SQL procedure of a function activity. The Workflow Engine never issues a commit as it is the responsibility of the calling application to commit.
For environments such as database triggers or distributed transactions that do not allow savepoints, the Workflow Engine automatically traps "Savepoint not allowed" errors and defers the execution of the activity to the background engine.
