Exception Handling Training Guide
Exception%20Handling%20Training%20Guide
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 50
| Download | |
| Open PDF In Browser | View PDF |
The Operational Agility Software Company Blue Prism Learning Exception Handling Training Guide info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence The Operational Agility Software Company Revision History Date Revision Author Description 09/01/2014 0.1 JC Draft document created 20/02/2014 1.0 JC Revision following peer review 04/04/2014 1.1 JC Revision following peer review 08/07/2014 1.2 CS Updated Legal Terms Aligned with the Foundation Course, info that used to be in the Config Guidelines, and our Process Templates. 22/01/2015 1.3 DD Removed all mention of Components – as they are a separate advanced topic. The training materials and other documentation (“Training Materials”) provided by Blue Prism as part of the training course are Blue Prism’s Intellectual Property and Confidential Information. They are to be used only in conjunction with the Blue Prism Software which is licensed to your company, and the Training Materials are subject to the terms of that license. In addition, Blue Prism hereby grants to you a personal, revocable, non-transferable and nonexclusive license to use the Training Materials in a non-production and non-commercial capacity solely for the purpose of training. You can modify or adapt the Training Materials for your internal use to the extent required to comply with your operational methods, provided that you shall (a) ensure that each copy shall include all copyright and proprietary notices included in the Training Materials; (b) keep a written record of the location and use of each such copy; and (c) provide a copy of such record to Blue Prism on request and allow Blue Prism to verify the same from time to time on request. For the avoidance of doubt, except as permitted by the license or these terms, you cannot (a) copy, translate, reverse engineer, reverse assemble, modify, adapt, create derivative works of, decompile, merge, separate, disassemble, determine the source code of or otherwise reduce to binary code or any other human-perceivable form, the whole or any part of the Training Materials; (b) sublease, lease, assign, sell, sub-license, rent, export, reexport, encumber, permit concurrent use of or otherwise transfer or grant other rights in the whole or any part of the Training Materials; or (c) provide or otherwise make available the Training Materials in whole or in part in any form to any person, without prior written consent from Blue Prism. Published by: Blue Prism Limited Centrix House Crow Lane East Newton-le-Willows WA12 9UY, UK Registered in England; Reg. No. 4260035 www.blueprism.com Tel: 0870 879 3000 info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 2 of 50 The Operational Agility Software Company Contents 1 Introduction .................................................................................................. 5 1.1 Exception Cases ...................................................................................................... 5 1.2 Visualising Exception Cases .................................................................................... 5 1.3 Application Problems ............................................................................................... 6 Exercise 1.3.1 Exercise 1.3.2 Exercise 1.3.3 Exercise 1.3.4 Exercise 1.3.5 Inducing an Exception ............................................................................... 6 Handling an Exception ............................................................................... 7 Exception Loop .......................................................................................... 8 Isolating Exception Handling ..................................................................... 8 Avoiding an Exception ............................................................................. 10 1.4 Business Rules ...................................................................................................... 10 1.5 Types of Exception................................................................................................. 12 Exercise 1.5.1 Exercise 1.5.2 Exercise 1.5.3 Exercise 1.5.4 Handling a Business Rule ........................................................................ 15 Recovery Mode ........................................................................................ 18 Accessing Exception Detail ..................................................................... 18 Misusing Exception Functions ................................................................. 20 2 Exception Handling Strategies.................................................................. 21 2.1 Retrying ................................................................................................................. 22 2.2 Preserve the type and detail of the current exception ............................................. 24 Exercise 2.2.1 Exercise 2.2.2 2.3 Using ‘Preserve the type and detail of the current exception’ ................. 24 Using Resume ......................................................................................... 25 Casting ................................................................................................................... 26 Exercise 2.3.1 Exception handling and casting ............................................................... 26 2.4 Business Objects ................................................................................................... 28 2.5 Sub-Pages ............................................................................................................. 33 2.6 Processes .............................................................................................................. 35 2.7 Queue Item Results ............................................................................................... 37 3 Exception Handling Pitfalls ....................................................................... 42 3.1 Infinite Re-throw Loop ............................................................................................ 42 3.2 Infinite Retry Loop .................................................................................................. 42 3.3 Nested Retries ....................................................................................................... 42 3.4 Nesting Exception Handling ................................................................................... 42 3.5 Generating another exception without resuming..................................................... 43 3.6 Stepping Past the Resume Stage .......................................................................... 44 3.7 Misleading Exception Detail ................................................................................... 44 info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 3 of 50 The Operational Agility Software Company 3.8 Missing Exception Detail ........................................................................................ 45 4 Human Intervention .................................................................................... 46 4.1 Diagram ................................................................................................................. 47 5 Process Templates..................................................................................... 50 info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 4 of 50 The Operational Agility Software Company 1 Introduction This module is intended to supplement the Blue Prism Foundation Training course and is aimed at students who have completed the course and are beginning to put their education into practice. 1.1 Exception Cases You will recall from the Foundation Training course that Blue Prism uses work queues to manage its workload. A work queue is a list of cases to be worked by a process. A process will iterate through the queue working cases in sequence. After working a case a process will update the queue with a result. Queue data is used to measure process performance and for generating MI (Management Information). A process is unlikely to be able to complete every single case and some will be identified as exception cases. 1.2 Visualising Exception Cases It may help to visualise exception cases by thinking of a Blue Prism process simply as a machine – a machine used to do a specific job over and over again. Without concerning ourselves how this machine works, we can see that cases are fed into one end of the machine and results come out at the other end. And in an ideal world this machine would be able to do all its work without encountering any difficulties – every case fed into the machine would be completed. Unfortunately the reality is that the machine will occasionally encounter problems and some cases will not make it all the way through to completion. These unfinished cases will require the attention of a human being. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 5 of 50 The Operational Agility Software Company 1.3 Application Problems You will recall from the Foundation Training that rather than failing in the event of an exception, Blue Prism can be configured to cope with, or handle the exception and try to keep going. Exception handling is a critical part of any Blue Prism solution and should be designed with the same level of care afforded to the other parts of a solution. Focusing only on the ‘happy path’ is not sufficient – the ‘unhappy path’ must also be considered. 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 processing does not perform as expected and the logical flow has strayed from the ideal path. Most exception handling should be done at process (or component) level. Business objects can contain exception handling but in general they should be kept as simple, reusable pieces of logic. In the following exercises we will look at a scenario where exception handling is commonly used at business object level - when we launch or attach to an application. Exercise 1.3.1 Inducing an Exception In this exercise we’ll create a business object that cannot handle a problem with an application. Create a new object based on the Notepad application. Create a new page called Attach (or Launch) Add a Navigate stage to attach to notepad.exe Without launching Notepad, run the page and confirm that the following exception message appears. Figure 1 Target application could not be identified info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 6 of 50 The Operational Agility Software Company ‘Target application could not be identified’ is the business object telling you that it can’t find the application to attach to. And in most cases we can assume this is because the application is not running. Exercise 1.3.2 Handling an Exception In its current state the business object generates an exception when it tries to attach to a nonexistent Notepad. Remember that if left unchecked, an exception will bubble upwards towards the main page of the parent process, ultimately bringing the process to a stop. Figure 2 Exception bubbling In this next exercise we’ll handle the exception to prevent this from happening. And because we know (or at least can reasonably assume) that the exception can be interpreted as ‘Notepad is not launched’, we can add additional logic to remedy the situation. Add Recover and Resume stages to handle the exception, with your diagram looking like this (NB the note stage isn’t necessary). info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 7 of 50 The Operational Agility Software Company Run the page again to confirm the exception handling prevents the message from appearing. This puts the object back on the ‘happy path’ but does not do anything to improve the situation. Add another Navigate to launch Notepad after the Resume stage, like this. Run the page and confirm that Notepad is launched. Press the Detach button and run the page again. Now because Notepad is already launched the attach will work. Exercise 1.3.3 Exception Loop Run the page again (slowly) to see that although the exception handling works at first, the diagram falls into a loop when it tries to launch Notepad. What do you think is happening? The attach failed initially because the business object was already attached, and a business object cannot attach more than once. This exception was handled but then the launch failed because Notepad was already running, and once attached, a business object cannot launch again. Key Points Launching an application attaches the business object automatically. Once a business object has launched an application, any attempt to launch again will cause an exception. Once a business object has become attached to an application, any attempt to attach again will cause an exception. Exercise 1.3.4 Isolating Exception Handling The exception handling itself is now causing a problem, in that the Recover stage is attracting exceptions from the launch point and sending the diagram into a tailspin. A way to remedy this problem is to isolate the source of the exception using a Block. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 8 of 50 The Operational Agility Software Company Add a Block around the first Navigate stage and the Recover, making the diagram look like this. Run the page again to confirm that the infinite loop does not occur. The launch exception is no longer handled because the Recover stage is now only concerned with exceptions occurring inside the Block. You should now see an exception message at the launch stage. Figure 3 Application already launched Key Points Although very useful, exception handling can itself cause problems if not well laid out. By default a Recover stage will attract any exception occurring on its page, and this can sometimes lead to an infinite loop. A Block is a mechanism for isolating exception handling to a specific area and is a good way to prevent an infinite loop. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 9 of 50 The Operational Agility Software Company Exercise 1.3.5 Avoiding an Exception Sometimes we can make checks to avoid scenarios where an exception might occur. In this example we know we can’t attach or launch more than once, so to finish off our page we shall add in some logic to see if we are already attached. Add in a Read stage, a Decision and an End stage before the first Navigate so that the page looks like this. Use the Read stage to set a Data Item called Attached, and edit the Decision expression to use the Data Item to divert the flow away from the Navigate stage. Tip: Use the root (top) element in the application model and select the ‘Is Connected’ read operation. 1.4 Business Rules The previous section looked at handling an exception caused by the behaviour of an application, namely when Notepad is not in an ideal state for attaching and launching. This is an example of how Blue Prism can be made to react to the situation it finds itself in and take corrective measures, i.e. ‘the attach failed, so assume Notepad isn’t running and proceed to launch’. Blue Prism can also be made to react to the data it is provided with. For example, if the first step in a procedure was to find a customer record using an 8 digit ID, it would make no sense for Blue Prism to attempt the procedure if it has (mistakenly) been given only 6 digits. It would be better if Blue Prism contained a rule that said ‘check the ID is 8 digits before attempting to find the customer’. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 10 of 50 The Operational Agility Software Company This is an example of validation logic that can be used to filter out ‘bad’ cases – ones that Blue Prism should not attempt to complete. Similarly, if the ID was 8 digits but the customer system displayed a ‘record does not exist’ message, Blue Prism would be unable to complete the case. These types of exception, based on ‘business rules’, should be seen as different from a technical error. When a case is not completed due to such logic it should not been seen as a problem – Blue Prism is behaving according to the rules. However, a case that did not flout any business logic but could not be completed should be seen as an error. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 11 of 50 The Operational Agility Software Company 1.5 Types of Exception So the term ‘exception’ is used to describe a problem Blue Prism encounters while it is running, but not every exception should be thought of as ‘bad’. Blue Prism enables us to invent as many types of exception we want and normally we use at least two. System Exception We know that Blue Prism is used to automate other applications, and as such is dependent on the behaviour of these applications. Again, in a perfect world these applications would always work faultlessly, never crashing, freezing, stalling, running slowly or doing anything they weren’t supposed to do. If this was the case, then in theory a faultless Blue Prism process could be constructed. But sadly this theory isn’t reality, and we can and should expect some issues with the applications we will be automating. A term we use in Blue Prism for this kind of application-based problem is system exception. Business Exception As well as technical issues with our applications, it is not impossible that the cases fed into Blue Prism contain some sort of problem that makes it impossible for the case to be worked. Similarly, a process may be set up to deliberately disregard certain types of case. For example, if a process was designed to only work the cases of adult patients, it may contain a rule to check the date of birth and deem juvenile cases as ‘out of scope’. A broad term we use for this kind of rules-based rejection is business exception. Key Points Exceptions can have different types. Not all exceptions are bad; some can represent ‘out of scope’ cases. Other Types of Exception There is no restriction on how you choose to classify exceptions and you may want to use terms other than ‘System’ and ‘Business’. However, Blue Prism recommends that the number of exception types used is kept to a minimum to ensure ease of understanding and support. Blue Prism recommends the other potential exception types: Exception Type Description Validation Exception The data input into the process has been validated and failed (i.e. sort code 5 digits instead of 6). info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 12 of 50 The Operational Agility Software Company System Exception Try Once The same as any other system exception but marked as one that should not be retried. If an exception occurs on an update stage in an action, i.e. a Click Confirm Button stage, Blue Prism may have no way of knowing if the update was done or not (i.e. the system becomes unresponsive) and should therefore not retry the update. Such an exception must be reported to be manually investigated and not re-attempted. Login System Exception Occurs if an exception occurs attempting to log into a system. When a login system exception occurs, no work queue items should be marked with an exception (any current case should be put back into the queue – pending and untagged). Support staff should be notified by email or alert. If logic has been specified in the SDD and Security Policy documents to allow automated password changes, the exception detail should be interrogated for the text ‘Password Change Required’ and a Password Change component used. System Unavailable Exception If a System Exception or Internal exception occurs the process should check, if possible, that the required systems are still available. If a system is not available, it is a System Unavailable Exception and no work queue items should be marked with an exception (any current case should be put back into the queue – pending and untagged). Support staff should be notified of this type of exception by email or alert. The process should keep attempting to start/use the system periodically until it is available again. However you decide to label exceptions, it is important to differentiate between exceptions for ‘in scope’ cases and ‘out of scope’ cases. As mentioned above, if a process was designed to ignore cases for juvenile patients, these sorts of exceptions should not be seen as errors. The info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 13 of 50 The Operational Agility Software Company cases are not complete, but they have been worked correctly. If this distinction is overlooked, MI reports may give an overly negative impression of the performance of the process. As mentioned previously, the types of exception used, what they mean and how they will be handled should be considered an integral feature of any Blue Prism solution. Internal Exception ‘Internal’ is the type of exception that isn’t generated by an exception stage, and we have already seen an example in the previous exercise where we first attempted to attach to Notepad. In simple terms, the internal exception is used by Blue Prism to say ‘there is a problem and I can’t do this part’. So the exception from our earlier exercise, ‘target application could not be identified’, is Blue Prism saying ‘I can’t find Notepad’. You may also recall some of these internal exception messages from your training. Internal Exception Message Interpretation Already connected to an application The business object is already attached and cannot be launched or attached again. Not Connected The business object is unattached and must be attached before it can perform any other actions. Unable to match any windows with the query terms The element of the application model can’t be spied anymore. Syntax error An expression containing an error has been found. Missing data A data item is being referred to in an input field or expression incorrectly. Stage xxx does not exist A data item referred to in an output or ‘store in’ field cannot be found. The business object xxx does not support the action yyy A business object page has been renamed (or unpublished or deleted) but the action stage is still using the old name. Failed to find stage linked from stage xxx There is a link missing and dead end was reached. Decision did not result in a yes/no answer The result of an expression in a decision was not a Flag data type (i.e. True or False). info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 14 of 50 The Operational Agility Software Company Cannot perform + operation when the lefthand value is empty A number data item has no current value. This isn’t a complete list of internal exceptions and no doubt you will come across others. The important thing to remember is that the internal type is an exception Blue Prism itself generates, and all other types are generated by you using the exception stage. Exercise 1.5.1 Handling a Business Rule In this exercise we’ll create a process that can handle ‘dirty data’, i.e. cases that cannot be completed because they contain incomplete or invalid information. Create a new work queue with Patient ID as the key field. In a new process create a collection containing the fields Patient ID (data type text) and Date of Birth (data type date). Populate about 10 rows with data. Use 8 digits for most Patient IDs but also use 6 and 7 digit numbers on some rows too. For Date of Birth use mainly dates for an adult but also use some ‘under 18’ dates on some rows. Use the Internal – Work Queues object to add new items to the queue. Re-run the process a few times so you have plenty of new items in the queue. Modify the process to use the Get Next Item and Mark Completed actions, so it looks like the diagram below. Figure 4 Mark Complete Run the process and then look in Control Room to confirm that one item in the queue has been completed. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 15 of 50 The Operational Agility Software Company Introduce a Decision stage to check the value of Date of Birth. If the patient is an adult, mark the case complete, otherwise throw an exception. Your diagram should look something like this. Open the properties of the exception stage and set Exception Type to Business Exception and Exception Detail to “Juvenile Case” (note the quotes – this is an expression). Add Recover and Resume stages to handle an exception and use the Mark Exception action from the Internal – Work Queues object to update the queue with the expression “My exception reason”. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 16 of 50 The Operational Agility Software Company Re-run the process until you get an exception case. The go back to Control Room to confirm the queue has been updated with the exception reason. Add another decision to check that the Patient ID is valid, i.e. 8 digits. Run the process again but see that the same exception message is generated every time. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 17 of 50 The Operational Agility Software Company This is because we are using a fixed value for the Exception Reason input parameter of the Mark Exception stage - regardless of the nature of the exception we are naively just saying ‘My exception reason’ each time. Obviously this isn’t ideal, and there is a better way to update the queue by using information extracted from the exception during what is known as Recovery Mode. Exercise 1.5.2 Recovery Mode As we have seen, the Recover stage attracts exceptions rather like a magnet. Once the flow of a process (or business object) has reached a Recover stage it is said to be in Recovery Mode. The Resume stage neutralises, or kills off, the exception and moves the process out of Recovery Mode. Once past the Recover stage, the process is back into ‘normal’ running mode. Exercise 1.5.3 Accessing Exception Detail Another way to improve exception handling is to inspect or examine an exception and then make some sort of decision based on its detail. Blue Prism provides functions for use as part of an expression for doing just that. Return to your exception handling diagram from the previous exercise and open the properties of each Exception stage. Make sure they have “Invalid ID” and “Juvenile Case” in their respective Exception Detail fields. Now move the Mark Exception stage in between the Recover and Resume stage, i.e. to a Recovery Mode position. Amend the expression used for the Exception Reason input parameter to be ExceptionDetail(). info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 18 of 50 The Operational Agility Software Company Re-run the process and look at the work queue. You should see that the terms ‘Invalid ID’ and ‘Juvenile Case’ are now being used to update the queue. Change the Exception stage thrown after the ‘8 digit’ decision so that it’s Exception Type is Data Exception Add a new decision with the expression ExceptionType()=”Data Exception” just after the Recover stage. Then make a second copy of the Mark Exception stage and link the decision to each one, like this. Notice how the exception handling flows one way or the other, depending on the type of exception thrown. Although this doesn’t look too impressive at first, you should be able to see the potential of having a Recover/Resume arrangement that can react differently according to the exception it has caught. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 19 of 50 The Operational Agility Software Company Note that the expression functions (found in the properties forms where an expression is required) must only be used during Recovery Mode and will themselves generate exceptions if they are used anywhere else. Exercise 1.5.4 Misusing Exception Functions To confirm how expression functions should not be used, introduce a deliberate error into your diagram by using one of the functions outside recovery mode. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 20 of 50 The Operational Agility Software Company 2 Exception Handling Strategies Anticipating and dealing with problems is crucial to a successful Blue Prism solution and an exception handling strategy should be devised at the design stage. Regarding exception handling as an ‘extra’ to be stuck on just prior to testing is a mistake that can lead to confusing diagrams and a poorly performing solution. As mentioned earlier, exception handling tends to be done above the business object layer. This simplifies the business object design and avoids adding complexity that might hinder the reusability of the object. The top layer of a solution is the main page of the parent process, and often this page will use a block as part of a ‘final’ exception handler that protects lower layers and catches exceptions that bubble up. Key Points Business objects usually contain very little (or no) exception handling. Exception handling and retrying tends to be done on layers above the object layer. The top main page generally uses an exception block to cover the layers beneath it. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 21 of 50 The Operational Agility Software Company 2.1 Retrying Retrying simply means to recover an exception and then steer the flow back into the main part of the diagram in the hope that the problem will be alleviated by another attempt. The decision whether to retry is normally governed by the exception details and the number of retries that have been attempted. To avoid retrying too many times data items are often used to monitor the number of iterations around the exception handling loop. The expression in the Retry? decision in the Blue Prism Process Templates is as follows: [Retry Count]<[Retry Limit] AND (Lower(ExceptionType())="system exception" OR Lower(ExceptionType())="internal") This decision ensures the flow only retries if the Retry Count has not been reach and if the exception type is either a System Exception or an Internal Exception. For example, you would not want to retry for Business or Try Once exceptions. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 22 of 50 The Operational Agility Software Company Finally, below we have a retry loop as it looks in the sub-pages of the best practice Blue Prism Process Templates. After the Resume stage, the flow needs to do something to get the application ready to retry the main flow again. In this instance it is simply calling a page that restarts the application being used. A Block has been added to ensure that an infinite loop cannot occur should an error happen between the Recover and Resume stages. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 23 of 50 The Operational Agility Software Company 2.2 Preserve the type and detail of the current exception When the decision to stop retrying is reached, it is important to understand the role of the ‘Preserve the type and detail of the current exception’ checkbox. When this checkbox is ticked, the exception stage simple ‘re-releases’ the current exception and allows it to bubble upwards as if it had never been recovered in the first place. When this checkbox is not ticked, the exception stage generates a new exception, and importantly, keeps the current exception alive. This means that by misusing the ‘preserve’ checkbox can lead to problems. Exercise 2.2.1 Using ‘Preserve the type and detail of the current exception’ Recreate the ‘divide by zero’ problem from the training course. Add a Recover and an Exception stage, as shown below. Leave the properties of the Exception stage untouched. Run the page and see that this (nearly blank) exception message is displayed. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 24 of 50 The Operational Agility Software Company Now open the Exception stage properties and tick the ‘Preserve..’ checkbox. Re-run the page and see that this exception message is displayed. Without the ‘Preserve…’ setting the Exception stage generates a new exception. We didn’t enter any Exception Type or Exception Detail in the Exception stage properties and that is why the message was (nearly) blank. Critically, the original exception - the one caught by the Recover stage - is still alive. And although this won’t appear to present a problem in this simple example, when this mistake is present in a more complex, multi-layer solution, unhandled ‘zombie’ exceptions like this will cause problems. With ‘Preserve…’ switched on, the exception caught by the recover stage is re-released (or rethrown) by the exception stage, and that is why the message was ‘Division by zero’. Key Points The current exception is released when the ‘Preserve…’ checkbox is ticked. A new exception is generated when the ‘Preserve…’ checkbox is not ticked. Exercise 2.2.2 Using Resume The previous exercise demonstrated the use of the Exception stage as part of Recovery Mode, i.e. between a Recover and Resume. Here we will see what happens when the Exception stage is used outside Recovery Mode. Change your diagram so that the Exception stage is after the Resume stage. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 25 of 50 The Operational Agility Software Company Re-run and see that the page falls into an exception loop. This is because the Resume stage has neutralised the original exception and the Exception stage generates a new one, which in turn is caught by the Recover stage. Add a block as shown below. See that it prevents the infinite loop by isolating the Recover stage so that is only has responsibility for exceptions originating inside the block. 2.3 Casting Recall from the training course that ‘casting’ is a means of using one data type to set a different data type. In Blue Prism terms, this means taking one value and using it to populate a data item of another data type, e.g. using the text expression “1234” to populate a number data item. The problem with casting is that it can go wrong if there is no ‘fit’ between the data types, e.g. “£12.34CR” will not ‘fit into’ a number data item because of the non-digit characters. Blue Prism does provide a number of functions to test values (e.g. IsNumber) but often exception handling is used to test the compatibility of a value. Exercise 2.3.1 Exception handling and casting Create a text data item called My Text with initial value 01/012014 (note the deliberate error). Create date data item called My Date with no initial value. Create a calculation with My Data as the ‘Store In’ and [My Text] as the expression (dismiss any data type complaints the Calculation properties form may present to you). Run the page to see the following exception message. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 26 of 50 The Operational Agility Software Company Add exception handling around the calculation like this. Run the page and see that the failed cast operation is handled with more control. This kind of ‘exploratory’ casting is often a good way to validate data. Yes, there are other ways to check, but because the ‘fit’ required for a cast has to be exact, using exception handling like this is often the safest strategy. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 27 of 50 The Operational Agility Software Company 2.4 Business Objects As mentioned above, business objects tend not to have much in the way of exception handling. This isn’t a rule as such, but in general business object pages are kept simple (and reusable) and the logic dictating what to do in the event of an exception is left to whoever is using the business object. As we saw in the first few exercises, using exception handling around an attaching Navigate stage is often used as a means to detect whether an application is running – if the attach fails, it can be reasonably assumed that the application is not running. Used like this, exception handling can provide the decision whether to attach or launch. Passing Results as Exceptions An exception is naturally associated with a negative outcome and we know that it will bubble upwards through the layers of a solution - as we have been discussing, this is how a problem at the application layer can find its way up to the work queue. Knowing this, it is possible to use exceptions to communicate results as well as problems. Imagine a business object page called ‘Find Customer’ that has an input parameter called ‘Customer ID’. The page will write the ID to a field on the screen, press a button and wait for the customer record to appear. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 28 of 50 The Operational Agility Software Company As you know, effort should be made to have business objects anticipate all scenarios, so what should happen if the customer could not be found? A basic solution would simply be to throw an exception from the end of wait stage, like this. The exception type could be ‘Business Exception’ and the exception message could be ‘Customer Not Found’. But is this correct? The wait stage checks for the existence of the Record element until the time out expires. At that point, logically all we can be sure of is that the element could not be found. However the example above assumes this to mean ‘customer does not exist’, and this may be incorrect. A more robust technique would be to have a wait stage check for more than just the ‘happy path’. For example, imagine that the application might also display the message ‘Record not found’ or ‘Record is currently locked by another user’ when the button was pressed. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 29 of 50 The Operational Agility Software Company See that in this example a System Exception is thrown after the time out. Rather than inferring a time out to mean ‘customer does not exist’, here we are simply (and more accurately) saying ‘none of the above elements could be found’. Critically, the business object is not passing judgement on what that means, it is merely stating a fact. The decision on what to in that scenario - the exception handling - is left to the user of this business object. Output Parameters or Exceptions In the example above there are four outcomes to the Find Customer action. Customer found Customer not found Record locked None of the above The ‘none of the above’ outcome is catered for by the System Exception after the time out. But what of the other outcomes? It is perfectly possible to use more exception stages for the other ‘negative’ outcomes, like this. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 30 of 50 The Operational Agility Software Company Although this idea will work, consideration should be given to the impact is has on the users of the business object - anyone wanting to use this page must be aware of these potential outcomes and make provision for them. This means that users have to either consult the business object documentation (which in turn must be accurate) or study the diagram to find out about these exceptions. And once they have done that, they must construct exception handling appropriate to their needs. To make the outcomes more visible to users, output parameters could be used instead, maybe like this. The outputs are clearly visible to the business object user in the properties of an Action stage. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 31 of 50 The Operational Agility Software Company And because the outputs can only be True or False, the process logic using the Find Customer action is unambiguous. In contrast, using the ‘output-less’ version of Find Customer is not as easy. First the user must know (or remember) that the business object can throw different types of exception. Then they need to open Object Studio, examine the diagram and then create expressions to test for the exception details during a recover sequence. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 32 of 50 The Operational Agility Software Company 2.5 Sub-Pages Sub-Pages Sub-Pages of your process should, If possible, have a single task or function such as retrieving information from one system, or updating another system. Any sub-page that interfaces with a system should have retry logic (as discussed above in section 2.1). An example would be a sub-page called ‘Add Note’ which navigates to the screen in the application where a note is added, adds the note, and finally performs any navigation required to return to the main screen of the application ready for the next task. Sub-processes Retry Loops When using components, sub-processes and objects care must be taken not to compound any retry loops by inadvertently nesting them together. The potential for concentric retrying can be difficult for a novice to spot, particularly when child diagrams are themselves calling yet more children. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 33 of 50 The Operational Agility Software Company A simple way to avoid doing this is to make sure a child capable of retries is not used on the retry path of the parent. A slightly more complex technique could be to use an input parameter to dictate to the child the number of retries it is allowed to perform. Testing Retry Loops It is good practice to test your Processes to ensure that they can cope if something unexpected occurs in application. Whilst your Process sub-page is running, manually interfere with the application it is using. Manually navigate to a different screen or exit the application. If your retry logic is working correctly, your flow should be able to recover from your manual intervention and continue. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 34 of 50 The Operational Agility Software Company 2.6 Processes A process will usually use a queue to manage its workflow – as a place for new work, to control the distribution of cases to Resource PCs and to store results. And regardless of what happens to a queue item while it is being worked, exception handling should be used to make sure the queue is updated with a result. A common arrangement is to use an exception block on the main page of a process covering the part of the path where an item is worked, rather like the diagram below. This is a simple yet powerful design to protect a process against termination and control queue items. Any exception occurring within the main block will be handled by the Recover stage. And because we know that exceptions bubble upwards, we are free to generate exceptions from any of the pages inside the block, safe in the knowledge that they will be caught. Knowing that the main block provides a safety net, we must also consider the path outside the block. An exception occurring in this unprotected area will terminate the process, so care must be taken to assess the whole process for the risk of unhandled exceptions. For example, suppose that in the event of an exception a process was to return the target application to the ‘home’ screen in readiness for the next case. The following arrangement could work, provided there were no problems. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 35 of 50 The Operational Agility Software Company But consider what would happen if the ‘Go back home’ stage failed. The additional exception wouldn’t be handled and would terminate the process before the queue had been updated. This would mean the queue item would be given the default (and rather unhelpful) exception reason ‘automatically set exception at clean up’. A more robust design would be to update the queue and move past the Resume stage before attempting to remedy the situation, maybe like this. Notice that a ‘Go back home’ page has been created. This would enable a separate exception handling sequence to be put on this page specifically for the purpose of controlling the application in between cases. Blocks in Recovery Mode Exceptions occurring during Recovery Mode cannot themselves be recovered. Although the example below may seem logical it will not work - rather like the forgetting to tick the ‘Preserve…’ check box, the second ‘divide by zero’ produces another exception that goes unhandled despite the presence of the second Block. For this reason effort must be made to eliminate the possibility of exceptions occurring during Recovery Mode. Although trivial, the example below demonstrates how. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 36 of 50 The Operational Agility Software Company 2.7 Queue Item Results As we have seen, results are applied to a queue item with the Mark Complete and Mark Exception actions. There are also a number of other ways to update an item before a result is applied. Tag Item – to append a tag to the item Un-tag Item – to remove a tag from the item Set Data – to overwrite the item’s data collection A common use of these actions is change the item’s tags to match the result. The left hand side of the following diagram illustrates the ‘complete’ path; the right hand side is the ‘exception’ path. Tags are a useful way to facilitate MI reporting by labelling items by exception type. The standard Blue Prism Performance Report requires that all exception items are tagged as either ‘System Exception’ or ‘Business Exception’. If you are using any other exception types in your process (i.e. Validation Exception), you must ensure that you only use one of these two tags. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 37 of 50 The Operational Agility Software Company Monitoring Consecutive Exceptions In the event of a serious problem with an application it may be better for a process to stop rather than carry on working. For example, if there are 1000 items in the queue and the target application is down, it makes no sense to work all items and have them all marked as exception ‘application is unavailable’. A better solution would be to count consecutive occurrences of an exception and bring the process to a stop when a sensible limit is reached. In other words, if say 3 cases in a row fail for the same System Exception, then treat this as a sign that something is wrong, notify administrator (maybe via email) and stop. Checking for a System Unavailable Exception You may decide to use a special exception type to signal a terminal problem and have your process look out for any of these exceptions. For example, if you had a System Unavailable Exception exception type your exception handling could contain the expression ExceptionType()=”System Unavailable Exception” to check whether to stop the process. A System Unavailable Exception may be thrown by an action or a sub-page if you are unable to launch your application. If such an exception occurs it is not related to an issue with a Work Queue item that might be currently being worked, you may therefore want to simply unlock the item (i.e. by Refering it) rather than marking it as an exception. Notifications info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 38 of 50 The Operational Agility Software Company Instances of some exceptions may warrant a notification being sent out. In a similar way to the ‘abort’ check described above, you could issue notifications when certain exceptions are recovered. However remember not to bombard people with emails as you develop and test your process. Queue Item Retries Recall from the training course that a Blue Prism work queue can be set up to enable an exception item to be reworked. It does this by creating a clone of the item and injecting it into the queue at the same position as the original. The Mark Exception action has flag inputs called Retry and Keep Locked for controlling this feature. If a new item is created, its ID will be returned in the New Item ID output parameter, and if Keep Locked was set to True, the process will have control of the new item. Consideration should be given as to whether a new item should be worked immediately or whether it should be left unlocked (maybe for another machine to pick up) or even deferred for a while so as to provide a bit of ‘breathing space’ between items. You will usually not require Queue Item Retries unless there is a unique design reason. All exception handling logic is usually done within your process (i.e. with retry loops) rather than using additional attempts on the Work Queue. Updating an Exception Item The following illustration summarises the sort of decisions you may wish to take as the result of an exception. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 39 of 50 The Operational Agility Software Company info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 40 of 50 The Operational Agility Software Company Capturing Exception Details It can be a good tactic to minimise the time spent in Recovery Mode by capturing the details of an exception in data items and then moving directly to the Resume stage. The advantage of doing this is that the risk of another exception occurring during Recovery Mode is eliminated and any activities performed after catching the exception can be protected by a secondary piece of exception handling. In the example below a notification step is performed before updating the queue, but if this step was to fail the second Recover would catch the exception. Then the data items containing details of the first exception would be used to update the queue. Although the secondary exception handling does nothing to improve the situation, it does at least prevent the notification error from terminating the process. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 41 of 50 The Operational Agility Software Company 3 Exception Handling Pitfalls There are a number of common pitfalls with exception handling that can trip up even the most experienced Blue Prism users. An outline of the most common problems, some which we have discussed above, is as follows. 3.1 Infinite Re-throw Loop This is when exception handling logic throws an exception back to itself and falls into a never ending cycle of throw-recover-throw-recover. When this occurs in Control Room the process must be terminated. When the diagram is open, if the pause button does not work (because the loop is too fast) often the only option is to kill Blue Prism using Task Manager. And if you haven’t saved your work, this can be annoying. The main cause of an infinite loop is bad use (or no use) of blocks. By its nature exception handling is not linked together by lines like the rest of the diagram, and this can make these potential loops hard to perceive. 3.2 Infinite Retry Loop This is when exception retry logic does not contain any mechanism to break out of the loop. Normally a counter is used to limit the number of retries that will be performed and without this retrying could go on for ever. 3.3 Nested Retries This is when one sequence of retry logic sits within another and the numbers of retries in each multiply together. Retry logic is often limited to 3 loops but if multiple sequences have been inadvertently nested together there could be 9 (3x3) or even 27 (3x3x3) loops. This is usually because the sequences exist on different pages or in different diagrams. This physical separation often makes the whole arrangement harder to visualise, particularly if you are not familiar with all of the diagrams. 3.4 Nesting Exception Handling As discussed above, problems occur when exceptions occur during Recovery Mode. Blue Prism has no concept of multiple, ‘nested’ Recovery Modes - Recovery Mode is either on or off. Blocks should not be nested together like this. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 42 of 50 The Operational Agility Software Company Nor should they be overlapped, like this. 3.5 Generating another exception without resuming When a Recover stage is followed by an Exception stage, failure to tick the ‘Preserve…’ checkbox will result in a second exception. If the intention is to generate a new exception (perhaps with a more informative message) then the correct method is to use the Resume stage to eliminate the first exception. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 43 of 50 The Operational Agility Software Company 3.6 Stepping Past the Resume Stage When stepping through a diagram it is not uncommon to find an exception has landed you at a Recover stage, and if the Recover stage is located some distance away from your original position it is tempting to go straight back using ‘Set Next Stage’ on the mouse menu. This urge should be resisted because, as we have been discussing, the exception is still ‘alive’ at the Recover stage – we are in Recovery Mode. Simply moving to another position does not stop Recovery Mode and the exception is still active. The safer option is to step past the Resume stage to come out of Recovery Mode before moving to another position. 3.7 Misleading Exception Detail Copy and Paste is a great timesaver in Blue Prism but can result in sloppy detail, particularly in business objects. As you are aware, the time out end of most Wait stages will lead to an Exception stage, probably type ‘System Exception’ with a message such as ‘Failed waiting for something’. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 44 of 50 The Operational Agility Software Company Because Wait stages and Exception stages are so commonly used in a business object, time can be saved by using Copy and Paste. Unfortunately it is very easy to forget to modify the Exception stage and leave the same message in many places. Ideally each exception message should be unique so that the task of retracing the root cause of a problem is made easier. 3.8 Missing Exception Detail If the properties of an Exception stage are left blank then it will generate an exception with no detail. This can have a knock-on effect on any subsequent exception handling or result in a queue item having no exception detail. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 45 of 50 The Operational Agility Software Company 4 Human Intervention When an exception results in an incomplete case, the case must be referred to a human being. The SDD (Solution Design Document) may stipulate that referrals are communicated automatically as part of the process, or a simpler, manual procedure may be specified. Either way, cases that Blue Prism did not complete, for whatever reason, should not go undeclared. If the exception indicates an out-of-scope case (e.g. a business exception) then Blue Prism is working normally and the referral should be carried out as agreed in the solution design. This will involve passing the case detail on to a team in the Business for manual reworking, perhaps as part of a daily report. Some types of exception may warrant special (or rapid) attention in the form of an individual notification to alert key individuals. Exceptions indicating a fault (e.g. system or internal exceptions) should also be brought to the attention of the local Blue Prism team. Subsequent investigation into the nature and frequency of these errors may prompt changes or repairs to a solution. It is unlikely that such problems will be completely eliminated, but regular monitoring of exception levels should be done to maintain steady performance. The work queue will normally be the main source of performance information and session logs will also provide micro-detail of the steps taken when working a case. Similarly, the logs should provide detail of more serious problems like process terminations. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 46 of 50 The Operational Agility Software Company 4.1 Diagram The following diagram illustrates a typical exception referral procedure. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 47 of 50 The Operational Agility Software Company Problem occurred mid-case? If the problem occurred while working a case then that case will need attention. Unexpected Termination? Normally a process will be configured with logic such as a ‘stop time’ to bring it to a natural completion. If a process terminates unexpectedly then there has been a problem which the Blue Prism system administrator should investigate. Out-of-scope case? If an exception case has been deemed out-of-scope in accordance with the solution design, then Blue Prism is working normally. Special attention required for out-of-scope case? The solution design may stipulate that some types of out-of-scope case require non-standard attention, perhaps because of an SLA (Service Level Agreement) or the unusual nature of the case. The normal notification procedure should be applied to all other out-of-scope cases. Notify special out-of-scope case Special cases may be announced in a different way to others, perhaps by sending an email to a particular mail box. Notify normal out-of-scope case The standard notification procedure for out-of-scope cases may simply be a report produced at the end of each day. High frequency of out-of-scope cases? The solution design should indicate the anticipated frequency of out-of-scope cases. If these cases appear more often than expected, then the BP system administrator should liaise with the Business to investigate the root cause. Special attention required for in-scope case? Some technical failures may be deemed more serious than others and necessitate particular interest. Notify special in-scope case If, for example, a target application hangs and consecutive system exceptions occur, the Blue Prism system administrators should be alerted. Notify normal in-scope case As with normal out-of-scope cases, in-scope case may simply be announced via a report distributed to the stakeholders agreed in the design. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 48 of 50 The Operational Agility Software Company High frequency of in-scope cases? Achieving a steady performance should be the goal of any Blue Prism solution. Exception levels are unlikely to be zero but they should at least be stable. Any jump in the failure rate is indicative of some sort of change that requires scrutiny from the Blue Prism system administrator. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 49 of 50 The Operational Agility Software Company 5 Process Templates The Blue Prism Process Templates available on the Blue Prism Portal are intended as a base for starting any new process. Using the templates helps to ensure that you create processes that adhere to best practices you have been taught during your training. The Blue Prism Process Templates include the following features that have been outlined in this guide: Retry loops on sub-pages A Block and Recover stage on the Main Page to ensure the Work Queue is updated with a result if there is an exception thrown up from a sub-page A Mark Item as Exception page which evaluates exceptions that occur to take the appropriate action (such as adding the correct tag and monitoring concurrent exceptions). The Process Templates are distributed with Instructions to assist you in their use. info@blueprism.com • +44 (0)870 879 3000 • Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY Commercial In Confidence Page 50 of 50
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.4 Linearized : No Page Count : 50 Language : en-GB Tagged PDF : Yes XMP Toolkit : 3.1-701 Producer : Microsoft® Word 2013 Creator : Andrea Dutton Creator Tool : Microsoft® Word 2013 Create Date : 2015:07:08 18:54:39+01:00 Modify Date : 2015:07:08 18:54:39+01:00 Document ID : uuid:7AE3502C-CD87-4BA4-9F78-B649066DB0C6 Instance ID : uuid:7AE3502C-CD87-4BA4-9F78-B649066DB0C6 Part : 1 Conformance : A Author : Andrea DuttonEXIF Metadata provided by EXIF.tools