BulePrism进阶教程-8. Error Management

There are two main features of Error Management:
First, the occurrence of unexpected events in a Process or Business Object can be identified (or to use a programming analogy, caught). This gives the developer the opportunity to build additional robustness into the logical flow in an attempt to handle the unexpected. For example, by taking the flow along a different route or by repeating the sequence that failed.
Second, cases that could not be worked can be identified. If, for whatever reason, a case cannot be completed, rather than stopping, the case can simply be marked as an exception and the process can move on to the next case. As you may have realized, this feature is naturally related to Case Management.
In our previous examples and exercises, we have only looked at ideal scenarios and have not really considered what to do when things do not go to plan. In the real world, problems will inevitably occur and we should aim to create a robust solution capable of dealing with them. Thorough testing should reveal the most common problems and we can then make adjustments for them.
We have seen how to use a Wait stage to allow a Business Object to pause for an application, but as yet we have not considered what to do if our Wait stage times out. Maybe a simple retry is enough to resolve an issue, or perhaps there is something unusual with the data we are working with (e.g., a suspended account) and retrying is of no use. It would be better to make a note of the problem and move on.
Simply moving to the next job might be enough, or it could be that we need to make a fresh start and restart the target application(s). More seriously, there could be a problem that is beyond our control (e.g., an application is offline) and we have no choice but to stop completely.
These kinds of problems and errors are known as exceptions, and the logic used to cater for them is known as exception handling.
8.1. Exception Handling
Rather than failing in the event of an exception, Processes and Business Objects can be designed to handle the exception and try to keep going.
Although not every type of exception is recoverable, and sometimes it makes no sense to attempt a recovery, the ability to handle exceptions at least provides us with the opportunity to decide what to do when something goes wrong and the logical flow has strayed from the ideal path.
We have seen that a solution is formed by Processes and Business Objects. Exceptions can potentially occur at any point and we shall see how exceptions are handled in such an arrangement.
Exception handling is done with a set of stages we have not used before.
8.2. Recover and Resume
As the names suggest, Recover and Resume are stages used to attempt to salvage and move on from an exception. The use of these kinds of stages also introduces a new concept to the design of a diagram.
Exercise 8.2.1 Recovering from an Exception
 Create a new Business Object named Exception Exercises Object.
 Add two number Data Items named X and Y with initial values of 1 and 0.
 Add a Calculation stage that divides X by Y. Yes, that’s right, divide by zero!
 Save the Business Object and run the page. An exception should occur and the following message should appear:

Figure 104: Divide by Zero Message
 Now add a Recover stage, a Resume stage, and another End stage and link them up as shown below. Run again to see the effect.

Figure 105: Recover and Resume Stages
Rather than fail at the Calculation stage, the exception has been recovered. Critically, the flow of the page has jumped between two stages (Calc1 and Recover1) that are not connected by a physical link.
The Recover stage attracts, or catches the exception, giving the designer (i.e., you) the opportunity to create some sort of recovery sequence. In this basic example, the recovery sequence is simply to take the diagram to a different end point.
When an exception is caught, the Business Object (or Process) is said to be in Recovery Mode, meaning the exception is “live”. Passing through the Resume stage diffuses the exception and enables the diagram to come out of Recovery Mode and continue a normal flow. Importantly, the Resume stage does not fix anything - that is the responsibility of the designer.
Key Points
 A Recover stage acts like a magnet – exceptions are drawn to it and the diagram flow will jump from the exception point to the Recover stage.
 When Blue Prism is on the path between a Recover and a Resume it is said to be in Recovery Mode.
 A Resume stage neutralizes the exception but does not fix the problem.
 Once past the Resume stage, the exception is effectively “gone” and the diagram can continue its normal flow.
 By default a page only uses one Recover stage and any others will be redundant.
As well as handling unexpected exceptions like this, we can also create them on purpose. This is known as throwing an exception.
8.3. Throwing Exceptions
In some circumstances it can be to our advantage to generate exceptions deliberately. If a “divide by zero” error was the reason a real-life case could not be worked, we might prefer to mark the case with a friendlier, more humane message to assist any manual rework that may be required.
Exercise 8.3.1 Throwing an Exception
 Add a Decision stage above the Calculation and set its expression to check if Y is zero.
 Connect the negative link to the Calculation and the positive link to a new Exception stage.
Figure 106: Exception Toolbar Button
Figure 107: Exception Stage
 Rerun and see how the Exception stage is used to throw an exception

Figure 108: Throwing an Exception
Exercise 8.3.2 Exception Type
When we throw an exception, we can give the exception meaning by embedding information with it.
 Open the properties of the Exception stage and populate the Exception Type and Exception Detail fields with something like “Invalid data found” and “Y is zero”. (You can type in a new exception type if there are none available in the drop-down list.)

Figure 109: Exception Properties
Key Points
 The Exception Type value in an Exception Stage is not an expression and does not need quotes.
 The Exception Detail value is an expression and does need quotes.
 Add a Calculation stage between the Recover and the Resume. Step through and stop on the new Calculation.
 Open the Calculation properties and look at the “Exception” functions in the bottom left corner.

 Drag ExceptionDetail up into the expression editor to create the function ExceptionDetail().
 Type ED into the “Store In” field and press the auto-generate button to create a new Data Item.

Figure 111: The Auto-generate Button
 Your diagram should look something like this:

 Run your page to see that the exception detail is captured in the Data Item.
At this point, the significance of this feature may not be apparent but we will see how the source of the exception and the recovery logic can exist in separate diagrams.
Key Point
Exception functions like ExceptionDetail() and ExceptionType() cannot be used anywhere other than in between a Recover and a Resume, i.e., in Recovery Mode.
Exercise 8.3.3 An Unhandled Exception from an Action
 Cut the recovery logic – Recover1, Resume1, Calc2, ED, and the second End.
 Publish the page, then save and close the Business Object.
 Create a new Process named Exception Exercises Process and add an Action stage that uses the Business Object we have just saved.
 Save the Process once to commit it into the Blue Prism database.
 Run the process and you should see a familiar exception message. What do you think has happened?
The answer is that the exception has traveled upwards from the Business Object and into the Process.
Exercise 8.3.4 Handling an Exception from an Action
 Paste the recovery logic cut from the Business Object into the Process so it looks like this:
 Exception functions like ExceptionDetail() and ExceptionType() cannot be used anywhere other than in between a Recover and

 Reset and run the page again. What is happening now?
We have deliberately chosen not to deal with the exception in the Business Object and in doing so we have allowed the exception to escape upwards into the Process. Fortunately, the Process contains some recovery logic to handle the exception. Admittedly the handling here is minimal, but the intention is to illustrate the concept.
Exercise 8.3.5 An Unhandled Exception from a Page
 Add a new page (keeping the default name) to the Process.
 Cut everything from the Main page and paste it onto a new page.
 Go back to Main Page and add a Page Reference where Action1 used to be.

Figure 113: Page Reference Stage
 Add a new End stage and link it with the Start and Page Reference stage.
 Reset and run the Process. What has happened?
As before, the Business Object did not handle the exception and it escaped upwards into the Process, where it was handled on Page1.
Exercise 8.3.6 Handling an Exception from a Page
 Move the recovery logic back on to Main Page and rerun the Process. What has happened now?

Figure 114: Recovering from a Page
Again, the exception has gone unhandled in the Business Object and moved upwards to Page1 in the Process. However, since we have now moved the recovery stages, Page1 also leaves the exception unhandled. The exception moves upwards from Page1 on to Main Page, where it is eventually handled.
Exercise 8.3.7 Re-throwing an Exception
 Copy the recovery logic on Main Page and paste a copy on to Page1.
 Add a new Decision stage between the Recover and the Calculation.
 Link the Decision with a new Exception stage so the page looks like this:

Figure 115: Re-throwing
 Make the Decision expression check whether the recovered exception is a “divide by zero” exception. There are a number of ways to do this, and the expression InStr(ExceptionDetail(), “Y is zero”)>0 is an example.
 Open the Exception stage properties and check the Preserve the type and details of the current exception checkbox.

Figure 116: Preserve the Type and Detail of the Current Exception
 Re-run the Process. What has happened?
As before, the exception has gone unhandled in the Business Object and moved up to Page1 in the Process. It is caught on Page1 but, importantly, it is re-thrown so that it remains unhandled and continues to move upwards.
Effectively Page1 has decided to exempt itself from dealing with any “divide by zero” problems and simply allows that type of exception to keep moving upwards. Fortunately, in this scenario, the Main page is able to handle the exception.
8.4. Preserving the Current Exception
When using the Exception stage, it is important to understand the “Preserve” checkbox and when to use it.
When the checkbox is checked, you will have noticed the Exception Type and Exception Details fields are disabled. Checking the checkbox indicates that the current exception is to be re-released or thrown again and no new details are necessary.
For this reason, the “Preserve” check box must only be used in Recovery Mode, i.e., somewhere between a Recover stage and a Resume stage. Using the checkbox outside Recovery mode will in itself generate an exception.
The following diagram illustrates correct use of the “Preserve” checkbox. The right-hand exception is thrown in Recovery Mode, so the checkbox is checked. The other exception is a new exception thrown outside Recovery Mode, so the checkbox is not (and must not be) checked and exception details are supplied.

Figure 117: Exceptions and the Correct Use of the "Preserve" Checkbox
Misuse of the “Preserve” check box is illustrated below. The right-hand Exception stage will generate a new exception in addition to the current exception. Any subsequent exception handling will deal with the first exception but will not handle the other, potentially resulting in undesired effects.
118: Exceptions and the Incorrect Use of the "Preserve" Checkbox
Key Points
 The “Preserve” checkbox is only applicable when in Recovery Mode.
 Re-throwing an exception will generate a second exception unless the “Preserve” checkbox is checked.
 To throw a new exception, make sure it is thrown after a Resume stage, thereby neutralizing the current exception before the new one is created.
Exercise 8.4.1 An Unhandled Exception
 Delete the recovery logic on the Main page and see what happens when you run the Process again.
The exception has gone unhandled all the way up from the Business Object up through the Process pages. The Main page was unable to recover and so the Process has failed.
8.5. Exception Bubbling
The way in which an exception moves upward through the layers of a solution is known as bubbling. An exception will bubble upwards until it is handled, and if it is not handled, it will eventually bubble up to the Main page of the Process and cause it to fail.
We can use bubbling to our advantage, as we do not have to catch an exception straight away; we can let it bubble up and handle it at a higher level in the hierarchy.
Even when we do catch an exception, we have the option to throw it upwards again. Deciding where and when to handle exceptions is a key part of solution design that we shall return to.

The other Exception stage will itself generate an error because it is wrongly using the checkbox – there is no current exception to preserve once past the Resume stage.

Figure 119: Exception Bubbling
Key Points
 Exceptions travel upwards towards the Main page of the Process.
 Exception handling can be on the same layer as the source of the exception or above it.
 Unless the exception is intercepted it will terminate the process
8.6. Exception Blocks
We can add a greater degree of control to exception handling with the use of Exception Blocks. A Block is used to isolate an area of a diagram that a Recover stage is responsible for.
Without a Block, a Recover stage will handle any exception on that page. When a Recover stage sits inside a Block it will only catch exceptions in that Block and ignore all others.
Blocks enable us to use more than one Recover stage on the same page.
Figure 120: Block Toolbar Button
Figure 121: Block Element
Exercise 8.6.1 Using Blocks (Part I)
 Close the Process and reopen Exception Exercises Object.
 Add new Recover, Resume, and End stages to Action1, placing them some distance to the right of the diagram.
 Draw a Block around the Exception stage to make the diagram something like this:
Figure 122: Recover Stage outside a Block
 Run to see the exception handled as normal; the Block has made no difference.
Blocks only work if they contain a Recover stage - without a Recover, a Block has no effect.
Exercise 8.6.2 Using Blocks (Part II)
 Now stretch the Block to the right and add another Recover, Resume, and End as shown below.
Figure 123: Recover Stage inside a Block
 Rerun to see how the exception is now handled by the new recovery section.
Because Recover2 is inside the Block, it assumes responsibility for any exceptions occurring in that Block.
Exercise 8.6.3 Using Blocks (Part III)
 Resize the Block again so that the Exception stage is no longer contained and the diagram looks like this:

Figure 124: Exception Stage outside a Block
 Rerun to see that the exception is again handled by the first recovery section and the second recovery section has become redundant.
Key Points
 One Recover stage will handle all exceptions on a page.
 Without Blocks, any extra Recover stages on a page will be superfluous.
 Blocks are a way of using multiple Recover stages on the same page.
 An exception generated inside a Block will be handled by the Recover inside that Block.
 If a Block does not contain a Recover stage, the Block will have no effect.
 One Recover stage will handle all exceptions generated inside its Block.
 Any extra Recover stages in a Block will be superfluous.
 Blocks should not overlap and Blocks cannot be nested (i.e., Blocks within Blocks).
Figure 125: Exception Handling Example - Main Page
In the example above, we can see two main types of exception handling, one where we will allow the process to terminate because we cannot continue, and one where we will handle an exception and resume processing.
Consider the first block, Block1. Any exception bubbled up from the Start Up page will be caught by the Recover1 stage. But, because we’ve been unable to start the target application, the process cannot continue and we will simply release the exception which, because we are throwing it on the Main Page, will cause the process to terminate.
The Start Up page logic is as shown below:

Commercial in Confidence Page 102 of 158
Figure 126: Exception Handling - Start-up Page
The exception handling in Block3 enables multiple attempts to launch the application, and a count is kept to limit the number of attempts. Once the maximum number of attempts is reached, the exception is not handled and allowed to bubble up to the parent page. And, because Main Page will not handle any exceptions coming from the Start Up page, the process will terminate.
The exception in Block4 is more basic – only one attempt to log in is possible, and if an exception occurs (say because the password has expired), the exception is simply allowed to bubble up and kill the process.
Returning to Main Page, consider the logic around Block2 below.

Figure 127: Exception Handling - Block2
Ideally every work queue item will be worked to completion and the process will keep to the happy path. However, the process makes provision for the possibility an exception bubbling up from either the Check Account Status and
8.7. Exception Handling in Practice
We’ve seen how Blue Prism can detect and handle exceptions but how is this used in practice. Let’s look at an example, consider the following Main Page of a process:
Apply Credit pages with Recover2. This unhappy path logic enables the process to record the exception detail in the queue item and, critically, to resume the normal flow, ready to get the next item from the queue.
8.8. Review
 Problems are inevitable in a real-world environment.
 Exceptions can be handled to make a robust solution.
 The nature of an exception can be interpreted to determine how or if the situation can be resolved.
 An exception will bubble up towards the Main Page of a Process until it is handled.
 Exceptions can be handled anywhere in Business Objects and Processes.
 An exception handling policy is part of the solution design.
 Recover, Resume, and Exception stages are used to create exception handling logic.
 Like a Start stage, the Recover stage cannot receive inbound links from other stages; instead the flow jumps to it when an exception occurs.
 Similarly, an Exception stage does not link to another stage because the flow jumps from it.
 A page can only use one Recover stage unless Blocks are used.
 A Block is used to isolate an area of a page and provide it with its own recovery logic.
 A page can have multiple Blocks, as long as they do not overlap.
Blue Prism Keywords
Exception, Recover, Resume, Throw, Bubble, Block.