Types of Exception in blue prism
We have 3 types of exceptions in Blue Prism. An exception (or exceptional event) is a problem that arises during the execution of a program. When an Exception occurs the normal flow of the program is disrupted and the program/Application terminates abnormally, which is not recommended, therefore, these exceptions are to be handled. Some of these exceptions are caused by user error, others by programmer error, and others by physical resources that have failed in some manner.
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 exceptions we want and normally we use at least two.
There are 3 types of exceptions in Blue Prism
- Internal Exceptions
- System Exceptions
- Business Exceptions
We know that Blue Prism is used to automate other applications, and as such is dependent on the behavior 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.
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 the business exception.
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:
|System Exception Try
|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.
|This 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). The 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.
|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 tagged). 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
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’ 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 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.|
|The 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).|