The Details property page of the process activity indicates that the Requisition Approval process has an error process called WFDEMO_ERROR_PROCESS associated with it, which gets initiated only when an error is encountered in the process. For example, if you attempt to initiate the Requisition Approval process with a requisition that is created by someone who is not listed in the employee approval hierarchy, the Workflow Engine would raise an error when it tries to execute the Select Approver activity. This error would initiate WFDEMO_ERROR_PROCESS, which is the Demonstration Error Process. The Demonstration Error Process is associated with the System:Error item type. Currently the process simply executes the standard Default Error Notification activity to provide information associated with the error. You can customize the process further to suit your needs. See: Default Error Process.
When you display the Process window for the Requisition Approval process, you see that the process consists of 12 unique activities, several of which are reused to comprise the 15 activity nodes that appear in the workflow diagram. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.
The Requisition Approval workflow begins when you run a script called wfrundemo.sql or submit a requisition using the Requisition Approval Demonstration web page. In both cases, you must provide a requisition requestor, requisition number, requisition amount, requisition description, and process owner. See: Initiating the Requisition Approval Workflow.
The workflow begins at node 1 with the Start activity.
At node 2, the process attempts to select an approver for the requisition. If an approver cannot be found for the requisition, the requestor is notified and the process ends with the final process result of Rejected. If an approver is found, then the requestor is notified of who that approver is and a function records in the application that the requisition is being forwarded to the approver. Both of these activities must complete before the approver is actually notified in node 8.
Node 8 is a subprocess that requests the approver to approve the requisition by a specified period of time and if the approver does not respond by that time, the subprocess performs a timeout activity to keep sending a reminder to the approver until the approver responds. If the approver rejects the requisition, the requisition gets updated as rejected in node 9, and the requestor is notified in node 10. The process ends at this point with a result of Rejected.
If the approver approves the requisition, the process transitions to node 12 to verify that the requisition amount is within the approver's spending limit. If it is, the process approves the requisition in node 13, and notifies the requestor in node 14. The process ends in this case with a result of Approved.