Introduction
In computing, “exceptions” are recognized as unforeseen error events that disrupt the normal flow of a running process. Exceptions, however, can be unique to a particular user environment. Some potential reasons can be due to network issues, restricted user permissions, task priority, changes in resources or faulty workflow design. Because today's business and IT processes operate in dynamic failure-prone environments, it is quite common that a number of expected and/or unexpected exceptions may occur during execution. Workflow level exceptions are especially critical, as workflows normally encompass a sequence of long-running tasks or high level processes. Unhandled workflow errors, in most cases, result in a restart of the entire workflow. This can lead to costly delays that negatively impact production.
A common expectation in automated workflow systems is their ability to detect and respond efficiently to exceptions that may occur. Some workflow modeling methods provide little or no support for detecting exceptions that can occur in a given process and how they can be resolved. When exceptions do occur, these systems typically perform basic operations, such as starting a specific process that contains general error handling steps, like sending a message to a user that an error occurred. For the most part, however, these systems are ill-suited in their ability to further resolve the issue. On the other hand, Automate BPA Server 8 undoubtedly meets such expectations with its dynamic approach to handling exceptions at the step, task and workflow level. This tri-level scheme provides flexibility to deal with both predictable and unpredictable exceptions.
Because of the inherent complexity of workflows, this article will largely emphasize workflow level exception handling with regards to workflow item error detection and repair. It will also present some common workflow design techniques, point out specific methods to deal with exceptional cases and illustrate some basic workflow layouts that implement an assortment of error handling techniques.
Error Causes
There are many common situations that take place during workflow execution that generate an error. For example, an error occurs when workflow execution arrives at a sub-workflow that is currently disabled, or when a task whose assigned agent is currently off-line. The Error Causes feature can be used to determine which workflow item event(s) should be taken into account as actual exceptions and which ones should be ignored. With this capability, you can globally set all workflows to ignore non-critical or insignificant error events, allowing execution to proceed without interruption. With regards to workflow items assigned to an agent group, Error Causes can dictate whether specific event types should lead to an error as they relate to individual agents contained in a group. It can also dictate whether the workflow item should throw an exception depending on the numerical ratio or percentage of agents in the group that caused an error.
To access global workflow Error Causes properties, from the SMC’s Navigation (left) pane, select Options > Default Properties. The Main (right) pane becomes populated with the available default properties. Scroll down to the section titled Default Workflow Item Properties and double-click Error Causes.
On Error
The On Error properties work hand-in-hand with Error Causes. These properties allow you to globally dictate how a workflow should react in the event that one of its items causes an error as specified in the Error Causes properties as well as modify the way the errors are logged. With this functionality, you can configure workflows to continue or halt execution upon error. You can configure multi-branch workflows to stop execution on only the branch that caused the error, allowing all other branches to proceed or stop execution of all other branches except the one that caused the error. Also, you can determine whether the execution should be logged as “failed” or “successful” in the event that one of its items causes an error.
To access global On Error properties, from the SMC’s Navigation (left) pane, select Options > Default Properties. The Main (right) pane becomes populated with the available default properties. Scroll down to the section titled Default Workflow Item Properties and double-click On Error. The following table contains a listing of available On Error properties and describes each option available for each property.
On Workflow Error
During execution of a workflow, one of its processes or tasks might cause an error that needs immediate attention from a user, administrator or department. For example, a task might not be able to locate a file, open an Excel document, or perhaps cannot upload files to an FTP server, at which point, information about the error may need to be sent to the proper individual so he/she can attempt to solve the problem. The On Workflow Error feature is ideal for this situation. When a fatal workflow problem occurs, or a workflow finishes in a “failed” state, this feature allows an error notification email to be sent to the specified address. Details about the error (i.e., error description, date/time of the error, error code) will be included in the body of the email. This option can be used to speed up the process of alerting the proper individual or department that can remedy the situation.
To access global On Workflow Error properties, from the SMC’s Navigation (left) pane, select Options > Default Properties. The Main (right) pane becomes populated with the available default properties. Scroll down to the section titled Default Workflow Properties and double-click On Workflow Error. In the properties, simply enable the option E-mail error notification for this workflow. Note that error notifications can also be handled at the task level or step level.
Conditional Branching
An Automate workflow is both powerful and multifaceted. You can use a workflow to quickly add conditional logic to your business process without writing a single line of code. As powerful as they are, workflows are also prone to a variety of problems that occur, mainly because they house all of the items that actually perform the work. By default, if an exception happens that is not handled, execution immediately terminates at the item that caused the exception and information about the error is logged. This usually indicates an incomplete operation resulting in unfinished work. In an automated environment, this may not be a suitable solution. Instead, you may want execution to continue and conceivably, the workflow can attempt to recover from the problem causing the exception. A common method is creating a workflow designed to use “conditional branching” to logically handle errors and alter the course of a workflow in case one is encountered.
Conditional branching is similar to an If statement in that it gives a workflow the ability to utilize intuitive decision making in order to respond accordingly to any exceptions and ideally allow the workflow to branch off to another task, process or sub-workflow designed to remedy the problem and continue processing. If continuation is not possible, conditional branching allows a workflow to branch to an alternate task, process or sub-workflow that can perform a thorough clean-up, such as returning documents or other content to their original state, logging the appropriate information and gracefully shutting down unnecessary processes or the system itself.
Flow control arrows allow conditional branching to take place by determining a workflow’s progress depending on specific events or conditions that transpire. The sample workflow below illustrates exception handling by way of conditional branching at its simplest form. A workflow executes along the path of any arrow containing the value equaling that of the previous object. Therefore, if Task1 completes successfully, execution follows the path containing the Success (green) arrow. If Task1 fails, execution follows the path containing the Failure (red) arrow instead.
Using Conditions to Handle Exceptions
Automate conditions are sophisticated multi-role objects that can trigger, pause or alter the course of a workflow. When a condition is placed as the first object in the beginning of a workflow, it takes on the role of trigger object, at which point, it can monitor for the occurrence of a condition and "fire off" a task or workflow when the condition is met. When placed at any point on a workflow’s path other than its start, the condition takes on the role of conditional (i.e. decision making) object which can change the path of a workflow depending on whether or not the specified condition is met. In addition, it can be used as a wait object to suspend workflow execution until a specific condition is met. For example, if a File condition is selected, it can be used in the following scenarios:
- Trigger— Used as a trigger object to initiate workflow or task when a particular file appears in the monitored folder (i.e. If File X exists in Folder Y, execute Task1).
- Wait— Used as a Wait object to pause workflow execution at the condition object until a certain file exists (i.e. Wait for File X to exist before running Task A). For instance, an error handler sub-workflow can contain steps to notify the user of the exact error that occurred so he/she can manually perform the appropriate steps to fix the problem. A wait object can be used in this situation to allow the workflow to wait for the appropriate fixes to be performed.
- Conditional — Used as a conditional object to determine which path a workflow should take depending on whether or not a file currently exists. If TRUE, execution proceeds to the Success (green) flow control arrow. If FALSE, it proceeds to the Failure (red) flow control arrow. A condition’s behavior is influenced primarily by its Behaviorproperties (illustrated below).
They are comprised of two main options that dictate whether the workflow should wait for the condition to take place or perform the evaluation immediately. By default, a newly created condition is always set to the parameter Wait for condition and sub-parameter Indefinitely, which means that it will behave as a trigger object. To set a condition to act as a wait object, select the Timeout After parameter. This suspends workflow branch execution at the condition object until the monitored condition occurs or the specified timeout period expires.
To set a condition as a conditional or decision making object, select the Don't wait, execute immediately parameter. In this situation, the condition does not wait. Instead, it evaluates immediately whether the specified condition has occurred. If the evaluation results to TRUE, the execution is marked as success and therefore execution follows the path marked by a Success (Green) Arrow. If the evaluation results to FALSE, the execution is marked as failure and execution follows the path marked by a Failure (Red) Arrow.
Universal Exception Handler
In certain situations, an exception can be handled by saving the current state of execution in a predefined place and switching the execution to a universal or “all-purpose” exception handler subroutine. Depending on the situation, the handler may perform a general cleanup of the system, stop un-needed services and shut down unnecessary processes. A technique to handle an exception in this manner is to create a sub-workflow that contains generic error handling steps and simply point a failure (red) arrow from all relevant workflow items to this sub-workflow.
The sample workflow below illustrates usage of a generic exception handler subroutine. If an error occurs during execution of Task1, Task2 or Task3, the workflow will follow the path of the failure (red) arrow which points to the Exception Handler sub-workflow.
Evaluation Object/Result Arrow
An Evaluation object is another form of conditional branching within the workflow level, which is similar to an If action within the task level. It is used primarily in conjunction with Result (blue) arrows to evaluate whether a specific condition is TRUE or FALSE, results to YES or NO or matches a specified value, and alters the path of the workflow depending on the result of the evaluation. The Evaluation object’s properties (shown below) consist of the following parameters:
- Simple— Specifies a simple expression. For example: city = "Los Angeles" or count > 100.
- Complex— Specifies the use of a complex expression.
- Value of this variable— Specifies the value of the specified variable. Commonly used to evaluate whether the value of a variable contained in a task that links to this object matches the value entered. Click the down arrow to select available variables. Note that the variable specified must be declared as a shared variable in order for it to be properly evaluated via the workflow level.
Result arrows stem from an Evaluation object to determine the path of a workflow. Unlike other flow control arrows (i.e. Success and Failure) the Result arrow contains its own properties to permit specific result values to be entered. During workflow execution, the path that the workflow will proceed on is dependent on which Result arrow matches the value of the Evaluation object it stems from. To use the Result arrow from the Workflow Designer drag the blue arrow from the Available Objects pane onto the workspace. Then, drag the nock (side opposite the point of the arrow) to the Evaluation object it should stem from and its point to the desired workflow item it should stem to. The Result arrow’s properties (shown below) consist of the following parameters:
- Yes/True — If this option is selected, the workflow will proceed to the object followed by a Result arrow with a YES or TRUE value matching that of the Evaluation object it stems from.
- No/False— If this option is selected, the workflow will proceed to the object followed by a result arrow with a NO or FALSE value matching that of the Evaluation object it stems from.
- Value— If this option is selected, the workflow will proceed to the object followed by a result arrow with a Value parameter matching that of the Evaluation object it stems from.
- All other values — If this option is selected, the workflow will proceed to the object followed by a result arrow if no other Resultarrows are followed.
AMError
To fix errors, you need as much information about them as possible. It is often the case that the logged error description alone isn't enough information for the workflow to handle the error or even determine what went wrong. When an Automate task generates an error, it automatically creates a fixed name dataset called AMError which can be used to examine important properties about the error that occurred (i.e. error number, error description, task name and step number that caused the error, etc.) in subsequent task steps. When declared in a shared variable, specific AMError values can be passed to subsequent workflow items.
AMError return data is laid out like a database table, which has a unique name and consists of columns and rows, thus, datasets are accessed in the same way that one would access information in a database; by specifying the column and row where the data resides. Because datasets are more like tables (as opposed to variables, which can be thought of more like containers that hold one value), they are referenced differently than other Automate objects. Essentially, the dataset name must be referenced followed by the column name enclosed in percentage signs. For example, using a Message Dialog step with the Message to display parameter set to %AmError.ErrorDesc% would display a message dialog returning a text description of the error. The following table provides a list of available fields that AMErrorpopulates:
AMError Parameters
When an AMError value is passed to an Evaluation object, robust exception handling with the use of conditional branches can be employed, as the sample workflow below illustrates. The workflow starts upon a specific event being logged (“Start on Event” condition) then runs a task that processes data (“Process Data” task), transmits the processed data (“Transmit Data” task) and generates a report (“Generate Report” task). The “Process Data” task contains an exception branch that points to an Evaluation object to deal with anticipated exceptions that might occur. In the properties of the Evaluation object, the Value of this variable parameter is enabled and the provided text box is populated with the value AMError.ErrorNumber, which returns the error number (or error code) associated to the error that occurred. Three Result arrows stem from the Evaluation object, each pointing to a separate error handler task. If the “Process Data” task generates an error during workflow execution, it proceeds to the path pointing to the Evaluation object, which evaluates the error number and runs the appropriate task that handles that error, eventually directing the workflow back to its original ending.
Conclusion
So now we have a pretty good idea of how to go about properly handling exceptions in our workflows as well as how to build sophisticated workflows with flexible exception handling capabilities. With Automate BPA Server’s robust and multifaceted error handling properties, we can apply the simple option to send an email upon failure, or utilize a more granular approach allowing exceptions to be handled at each step and use exception branches to change the flow of a workflow when an error is encountered. In addition, we can easily define customized exception handlers containing actions to be executed in response to the type of exceptions that occur and construct highly adaptable workflows with the use of AMError along with Evaluation objects and Result arrows.
Applies to: Automate 10
