Synchronous, Asynchronous, and Forced Synchronous Processes (Oracle Workflow Help)

Oracle Workflow Guide
Release 2.6.2
Part Number A95265-03


				Contents	Index	Glossary	Master Index	Feedback

Synchronous, Asynchronous, and Forced Synchronous Processes

A workflow process can be either synchronous or asynchronous. A synchronous process is a process that can be executed without interruption from start to finish. The Workflow Engine executes a process synchronously when the process includes activities that can be completed immediately, such as function activities that are not deferred to the background engine. The Workflow Engine does not return control to the calling application that initiated the workflow until it completes the process. With a synchronous process, you can immediately check for process results that were written to item attributes or directly to the database. However, the user must wait for the process to complete.

An asynchronous process is a process that the Workflow Engine cannot complete immediately because it contains activities that interrupt the flow. Examples of activities that force an asynchronous process include deferred activities, notifications with responses, blocking activities, and wait activities. Rather than waiting indefinitely when it encounters one of these activities, the Workflow Engine sets the audit tables appropriately and returns control to the calling application. The workflow process is left in an unfinished state until it is started again. The process can be restarted by the Notification System, such as when a user responds to a notification; by the background engine, such as when a deferred activity is executed; or by the Business Event System, such as when an event message is dequeued from an inbound queue and sent to the workflow process. With an asynchronous process, the user does not have to wait for the process to complete to continue using the application. However, the results of the process are not available until the process is completed at a later time.

In addition to regular synchronous and asynchronous processes, the Workflow Engine also supports a special class of synchronous processes called forced synchronous processes. A forced synchronous process completes in a single SQL session from start to finish and never inserts into or updates any database tables. As a result, the execution speed of a forced synchronous process is significantly faster than a typical synchronous process. The process results are available immediately upon completion. However, no audit trail is recorded.

There may be cases when your application requires a forced synchronous process to generate a specific result quickly when recording an audit trail is not a concern. For example, in Oracle Applications, several products require Account Generator workflows to generate a meaningful flexfield code derived from a series of concatenated segments pulled from various tables. The Account Generator workflows are forced synchronous processes that compute and pass back completed flexfield codes to the calling applications instantaneously.

To create a forced synchronous process, you need to set the itemkey of your process to #SYNCH or to wf_engine.eng_synch, which returns the #SYNCH constant, when you call the necessary WF_ENGINE APIs. Since a forced synchronous process never writes to the database, using a non-unique itemkey such as #SYNCH is not an issue. Your process definition, however, must adhere to the following set of restrictions:

No notification activities are allowed.

Limited blocking-type activities are allowed. A process can block and restart with a call to WF_ENGINE.CompleteActivity only if the blocking and restarting activities:

Occur in the same database session.

Contain no intervening calls to Oracle Workflow.

Contain no intervening commits.

No Error Processes can be assigned to the process or the process' activities.

Each function activity behaves as if On Revisit is set to Loop, and is run in non-cancelling mode, regardless of its actual On Revisit setting. Loops are allowed in the process.

No Master/Detail coordination activities are allowed.

No parallel flows are allowed in the process, as transitions from each activity must have a distinct result. This also means that no <Any> transitions are allowed since they cause parallel flows.

None of the following Standard activities are allowed:

Block (restricted by the conditions stated in the Limited Blocking bullet point above.)

Defer Thread

Wait

Continue Flow/Wait for Flow

Role Resolution

Voting

Compare Execution Time

Notify

No use of the background engine, that is, activities are never deferred.

No data is ever written to the Oracle Workflow tables and as a result:

The process cannot be viewed from the Workflow Monitor.

No auditing is available for the process.

Only the following WF_ENGINE API calls are allowed to be made, and in all cases, the itemkey supplied to these APIs must be specified as #SYNCH or wf_engine.eng_synch:

WF_ENGINE.CreateProcess

WF_ENGINE.StartProcess

WF_ENGINE.GetItemAttribute

WF_ENGINE.SetItemAttribute

WF_ENGINE.GetActivityAttribute

WF_ENGINE.CompleteActivity (for the limited usage of blocking-type activities)

WF_ENGINE API calls for any item besides the item for the current synchronous item are not allowed.

Attention: If you encounter an error from a forced synchronous process, you should rerun the process with a unique item key in asynchronous mode and check the error stack using the Workflow Monitor or the script wfstat.sql. If the synchronous process completes successfully, the error you encountered in the forced synchronous process is probably due to a violation of one of the above listed restrictions. See: Wfstat.sql.

Synchronous, Asynchronous, and Forced Synchronous Processes

See Also