Exception referral types

[RtyrOM]

Could someone advise on different types or techniques to refer/direct business/system exceptions?

For example, when a business exception is hit, one may want to inform the required business unit of the out-of-scope case. A potential solution may be to send an email to the relevant individual. But what else can be done in a similar case?

 

[Pete_L]

It is a good practice to generate a report in Excel at the end of the automation run. The report should contain all of the cases processed, and the disposition of each (completed, exception). The exception cases are typically then worked manually outside of BP. So, when you generate an exception, mark the item as Exception, and write that item to the report. The exception text will appear on the report if you give it a column to store it in. When you successfully complete a case, mark it as Completed and it will also appear on the report.

If you want to send an email when an exception is raised, then just include steps to generate the appropriate email as part of the exception handling code. Or, at the very least, add steps to generate an email in the Termination exception handler on the Main Page. This will send an email only when a terminating / unhandled exception occurs.

 

[RtyrOM]

It is a good practice to generate a report in Excel at the end of the automation run. The report should contain all of the cases processed, and the disposition of each (completed, exception). The exception cases are typically then worked manually outside of BP. So, when you generate an exception, mark the item as Exception, and write that item to the report. The exception text will appear on the report if you give it a column to store it in. When you successfully complete a case, mark it as Completed and it will also appear on the report.

If you want to send an email when an exception is raised, then just include steps to generate the appropriate email as part of the exception handling code. Or, at the very least, add steps to generate an email in the Termination exception handler on the Main Page. This will send an email only when a terminating / unhandled exception occurs.

Thanks Pete_L. I like the idea of recording each outcome in the Excel file.

 

[Pete_L]

When generating the output file in Excel, I recommend that you include all of the data from the input record in the beginning columns, add any columns that contain useful data from the processing, as well as 2 exception columns at the end: Exception Type and Exception Detail. This will allow the Business Line to see all of the data that was used/created by the process to get the result (exception or success). It will help them when they need to research issues and questions.

I run in a multi-bot environment, so I also add a column for the Resource Name. You get the value for this column by using GetResourceName() in the Process, and saving it to a field that you output to the Excel file. This information will not be useful to the Business LIne, but it will be useful to you when you have to track down problems. You will know from the output report which Runtime Resource that case was run on, and it will avoid having to search through multiple session logs to find the one containing the issue.

 

[RtyrOM]

When generating the output file in Excel, I recommend that you include all of the data from the input record in the beginning columns, add any columns that contain useful data from the processing, as well as 2 exception columns at the end: Exception Type and Exception Detail. This will allow the Business Line to see all of the data that was used/created by the process to get the result (exception or success). It will help them when they need to research issues and questions.

I run in a multi-bot environment, so I also add a column for the Resource Name. You get the value for this column by using GetResourceName() in the Process, and saving it to a field that you output to the Excel file. This information will not be useful to the Business LIne, but it will be useful to you when you have to track down problems. You will know from the output report which Runtime Resource that case was run on, and it will avoid having to search through multiple session logs to find the one containing the issue.

Would you recommend updating an Excel file after every queue item is executed or load data for all queue items in the collection and update the Excel file at the end of the process?

 

[Pete_L]

It depends on the number of work items you are going to report on and on how you want to design your automation. If the number of work items is small, it may make sense to write each item to Excel and save the file as you process each case. However, if the number of cases is large, you should write them all to Excel in one go after the main process is finished. I work with very large data sets, so this latter design is how I normally do it. In my main process, after a case is dispositioned (marked as Completed or as Exception) I add the case to a separate Work Queue called Report Queue. Then, when the main process is finished, I create a separate Write Report process that gets each item from the Report Queue, writes it to Excel, and marks it as Complete. The basic design is Get Next Item, write it to Excel, and repeat until there are no more items in the queue. Then, I save the Excel file at the end. I find this method is most efficient, especially since I usually work with a very large number of work items.

Unfortunately, I learned this the hard way since when I was a new developer, I designed a process that wrote each individual work item to the Excel file, and saved the file every time. (I was required to save the file after each case in order to minimize the risk of data loss in case the network went down while the Excel file was saving, thereby causing loss of the Excel file.) Since every save is done on a slightly larger file (i.e., larger by one record), it takes longer to save the Excel each time and this small increase in time adds up as the number of records written increases. This particular process took more than 1 entire day to run, primarily due to the excessive time it took to save the Excel each time. I eventually changed the design to add a report queue like I described above and writing the Excel file only once at the end of the process, and I was able to shave 20+ hours off the run time. I have always used a separate report queue since.

Hope this helps.

 

[RtyrOM]

It depends on the number of work items you are going to report on and on how you want to design your automation. If the number of work items is small, it may make sense to write each item to Excel and save the file as you process each case. However, if the number of cases is large, you should write them all to Excel in one go after the main process is finished. I work with very large data sets, so this latter design is how I normally do it. In my main process, after a case is dispositioned (marked as Completed or as Exception) I add the case to a separate Work Queue called Report Queue. Then, when the main process is finished, I create a separate Write Report process that gets each item from the Report Queue, writes it to Excel, and marks it as Complete. The basic design is Get Next Item, write it to Excel, and repeat until there are no more items in the queue. Then, I save the Excel file at the end. I find this method is most efficient, especially since I usually work with a very large number of work items.

Unfortunately, I learned this the hard way since when I was a new developer, I designed a process that wrote each individual work item to the Excel file, and saved the file every time. (I was required to save the file after each case in order to minimize the risk of data loss in case the network went down while the Excel file was saving, thereby causing loss of the Excel file.) Since every save is done on a slightly larger file (i.e., larger by one record), it takes longer to save the Excel each time and this small increase in time adds up as the number of records written increases. This particular process took more than 1 entire day to run, primarily due to the excessive time it took to save the Excel each time. I eventually changed the design to add a report queue like I described above and writing the Excel file only once at the end of the process, and I was able to shave 20+ hours off the run time. I have always used a separate report queue since.

Hope this helps.

Thanks a lot Pete_L. This is a really good solution. I have been saving the report after every item. Luckily the process has low volumes. I will definitely use your method in future processes.