Friday, October 12, 2007

Workflow API

•A function activity is usually defined by a PL/SQL stored procedure that performs some automated processing within a workflow process.
•The PL/SQL procedure for a function activity must follow a standard API.

All PL/SQL stored procedures called by function activities in a workflow process must follow the standard API format so that the Workflow Engine can properly execute the activity.

(itemtype in varchar2,

itemkey in varchar2,
actid in number,
funcmode in varchar2,
resultout out varchar2);

•itemtype: The internal name for the item type.
•itemkey: A string that represents a primary key generated by the workflow-enabled application for the item type. The item key uniquely identifies the item within an item type.
•actid: The ID number of the activity from which this procedure is called.
•funcmode: The execution mode of the function activity, either RUN or CANCEL.
•resultout: A result that is returned depending on the result type specified for the activity.

–Executed when activities are executed for the first time
–Executed following CANCEL mode when a loop is revisited with On Revisit set to Reset
–Executed for activities revisited in a loop with On Revisit set to Reset
–Executed for activities that are part of a process that has been canceled by a call to WF_ENGINE.AbortProcess( )

•If a result type is specified in the property page of the activity in the Workflow Builder, this parameter represents the expected result returned when the procedure completes.
•Possible resultout values are:

•A post-notification function can be used to couple processing logic to a notification activity.
•Post-notification functions for notification activities must follow the same standard API as PL/SQL procedures for function activities.
•However, notification activities use different execution modes than function activities

All PL/SQL stored procedures referenced by notification activities as post-notification functions in a workflow process must follow the standard API format so that the Workflow Engine can properly execute the activity.

•The resultout parameter is ignored for the ‘RESPOND’, ‘FORWARD’, and ‘TRANSFER’ execution modes, unless the parameter value is in the form ‘ERROR%’.
•If you want to fail the Respond, Forward, or Transfer operation after the post-notification function has executed, you can:
–Return resultout = ERROR:
–Raise an exception in your procedure

You can reference the following global WF_ENGINE variables in your post-notification function:
•WF_ENGINE.context_nid = notification_ID
•WF_ENGINE.context_text = new_recipient_roleif the function is called in TRANSFER or FORWARD mode
WF_ENGINE.context_text = responderif the function is called in RESPOND mode

Use WF_CORE APIs to raise and catch errors in your PL/SQL procedures.
•The Workflow Engine sets the status of the function activity to “ERROR” if:
–The PL/SQL procedure raises an unhandled exception
–The PL/SQL procedure returns a result beginning with “ERROR:”

Use the following APIs to start or run a workflow process:

Use the following APIs to communicate attribute information to the Workflow Engine:



Use the following APIs to communicate state changes to the Workflow Engine:


For standalone Oracle Workflow, a calling application can launch a Web browser and pass a Workflow Monitor URL.
You can monitor a specific item type and key through the following URLs:
–Process Diagram URL
–Notifications List URL
–Activities List URL

•To generate Workflow Monitor URL strings, call the following functions:
–Process Diagram: WF_MONITOR.GetDiagramURL( )
–Notifications List: WF_MONITOR.GetEnvelopeURL( )
–Activities List: WF_MONITOR.GetAdvancedEnvelopeURL( )
•The calling application must supply the Web agent string, item type, and item key, and specify whether to run the monitor in ADMIN or USER mode.

No comments: