Previous	Next		Contents	Index	Glossary

Errors that occur during workflow execution cannot be directly returned to the caller, since the caller generally does not know how to respond to the error. In fact, the caller may be a background engine with no human operator. Instead, Oracle Workflow lets you define the processing you want to occur in case of an error by specifying an error handling process when you create your workflow process in Oracle Workflow Builder.

At design time, you can assign an error handling process for a process, function, or event activity in the activity's Details property page. You must specify the internal names of both the item type that owns the error handling process and the error handling process itself. See: To Define Optional Activity Details.

Oracle Workflow provides a special item type called System: Error, which contains error processes called Default Error process and Retry-only process that you can use for generic error handling in any of your processes. However, you cannot modify the error processes in the System: Error item type. If you want to incorporate functionality that is not available in these error processes, you should create your own custom error handling process in your own item type. An error process can branch based on error codes, send notifications, and attempt to deal with the error using automated rules for resetting, retrying, or skipping the failed activity.

Note: Rather than relying on an error process to handle errors due to specific business rule incompatibilities, you should try to model those situations into your workflow process definition. For example, if a function activity can potentially encounter an error because a business prerequisite is not met, you might model your process to send a notification to an appropriate role to correct that situation if it occurs, so that the workflow process can progress forward. If you do not model this situation into your workflow process, and instead rely on the error to activate an error process, the entire workflow process will have an 'Error' status and will halt until a workflow administrator handles the error.

At runtime, 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.

Note: 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.

The Workflow Engine then attempts to locate an error process to run by starting with the activity which caused the error and then checking each parent process activity until an associated error process is located. If the Workflow Engine finds an error process, it launches that process to handle the error. If no error process is assigned for the running process, the Workflow Engine performs a rollback to the savepoint and sets the activity to the ERROR status, but no error process can be launched.

Note: Both the error item type and the error process must be specified for an error process to be launched.

Customizing Error Notifications for an Item Type

The Default Error process and the Retry-only process both send notifications to inform an administrator that an error occurred. If you assign one of these processes as the error process for your own process activity, you can control the behavior of the error notifications through item type attributes that you define in your own item type. In this way you can customize your error handling without modifying the predefined error processes.

By default, the Default Error process and the Retry-only process send error notifications to the SYSADMIN role. You can optionally specify another role as the recipient of error notifications for your item type by creating an item type attribute named WF_ADMINISTRATOR in your item type and setting the value of this attribute to the role that you want to notify. If your item type includes the WF_ADMINISTRATOR attribute, the Default Error process and the Retry-only process send any error notifications to the role you specify in that attribute, overriding the default.

For example, suppose you have a requisition approval workflow and you want the purchasing administrator, not the system administrator, to resolve any problems that arise from this workflow. You can define an item attribute called WF_ADMINISTRATOR in the item type that owns your requisition approval workflow and set the WF_ADMINISTRATOR attribute to the purchasing administrator's role, which may be PO_ADMIN.

You can also optionally use an item type attribute in your own item type to control whether the error notification activity in the Default Error process or the Retry-only process times out. Create an item type attribute of type number named ERROR_TIMEOUT, and set the value of this attribute to the timeout interval you want, specified in minutes. The Workflow Engine interprets the timeout value of this attribute as a relative offset from the begin date of the activity. If the ERROR_TIMEOUT attribute contains a null value, a value of zero, or is not defined at all, the error notification activity does not time out.

See Also

Default Error Process

Retry-only Process

Copyright © 2003 Oracle Corporation.
All rights reserved.