| Back to Main Page |
An important consideration as you get ready to write your own is error handling. Of course, no one wants their program to end in an error, but it happens to the best of us. In order to make sure that your procedure can deal with an unexpected condition, you have to make sure that your procedure follows Workflow’s defined error handling structure, and in order to follow the defined error handling structure, you have to understand how it works. There two components in the model, the Workflow error process, and the PLSQL exception handler. In this section, we’ll cover the error process, and later, in the next entry, I'll tackle the exception handler.
In a nutshell, when the Workflow Engine encounters an error condition in a process, it launches another process in response. This is what’s called the “error process.” The usual purpose of the error process is to alert an administrator about the error so that that person can intervene and resolve the problem.
|
|
| Figure 1: Defining an error process for an activity. In this case, if an error occurs in this activity, the Workflow Engine will launch an instance of the “DEFAULT_ERROR” process in the “WFERROR” itemtype. |
The process that will be launched is determined during design time. Within the Workflow Builder, you can specify an error process at the activity level and/or at the process level. When an error condition occurs, the Workflow Engine begins looking for a process to launch in response. It starts searching at the activity in which the error occurs. If an error process has been defined for that activity, the Workflow Engine launches an instance of that process. If not, then it checks the process of which the error is a part, and it continues up the chain until it locates an error process.
In the illustration in Fig 1, if an error occurs in this activity as it executes in a process, the Workflow Engine will create an instance of the “Default Error Process” from the “System:Error” itemtype and launch it. In the properties window, the designer has supplied the internal names of that process and itemtype, as is required.
For most purposes, the Default Error Process is sufficient. It serves its purpose of notifying the administrator about the problem, and it is robust enough to allow for a couple of variations. For example, if the administrator fails to respond to the error notification and it times out, the process is smart enough to check and see if the error condition still exists before re-notifying the administrator. Also, if the workflow designer wants to use the process functionality, but notify a different administrator, that can be accommodated, too, as we’ll see in a moment.
|
| Figure 2: The default error process. |
Whether you choose to use the Default Error Process or create your own, whenever the Workflow Engine launches any process as an error handler process, it provides values for twenty different attributes. If those attributes already exist in the error process, as they do in the Default Error Process, they are updated with information about the current error condition. If any of them do not exist, the Engine will first create them, and then supply the values. The information in these attributes allows the Default Error Process – or your custom process – to include the pertinent information in the notification, so that it can be corrected.
Five attributes for an error process:
|
By default, the Default Error Process will notify the role called “SYSADMIN”. But, if you would like to use that process but notify a different role, you can do that, too! As an example, say that you have one person who is tasked with handling errors that arise in Fixed Assets Workflow processes, and another who takes care of errors from HR Workflows. You can accomplish this without any modification to the Default Error Process.
The secret is that you need to create an attribute in the process where the error would be raised. This is important; you don’t add the attribute to the System:Error item type, it is placed into the itemtype where the error would occur. The attribute that should be added should have an internal name of “#WF_ADMINISTRATOR”. Don’t forget the pound sign in the first character position. Populate the attribute with the name of the role who should handle errors arising from this item type, and they’ll be notified.