Previous	Next		Contents	Index	Glossary

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.

There may be cases when your application requires a forced synchronous process to generate a specific result quickly and 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 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:

• And

• 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.