cancel
Showing results for 
Search instead for 
Did you mean: 

What is the purpose of resetting exception variables after processing a queue item?

SeanScudellari
Level 4
I see in one of the best practices templates that they have a "reset global items" page that resets/initializes specific variables before processing the next item in a queue. On this page are variables for the exception type and exception detail. 

I am wondering what is the purpose of resetting these exception variables after processing each queue item? If there is an exception, it will be logged on the queue item/tagged in addition to being stored in the exception variables. Then if another exception occurs for a different queue item, the previous values for the exception variables will be overwritten with the new exception values and the exception will also be logged in the queue item. 

So what is the point of resetting the exception variables if the exception gets logged in the queue and the previous values the exception variables contained will be overwritten if another exception occurs? Is it just a best practice rather than a requirement? 

Thank you.

------------------------------
Sean Scudellari
------------------------------
1 BEST ANSWER

Helpful Answers

Exactly @Sean Scudellari, think of it like this what if you are doing a check at the start of your work step for any kind of exception or doing this check anywhere in between. If let say transaction 1 faced an error and it stayed in the variable for some reason by the time we went for second transaction, this check can produce wrong results as it will think this error belongs to the current transaction whereas in reality it belonged to the earlier transaction.

This not only extends to exceptions but it can be extended to anything ranging from a simple Flag value which can determine a key condition to anything complicated like a collection which is supposed to carry key data from a given transaction item. As a best practice, once you have decided that a work item is marked as either completed or an exception you should always reset key data items and collections so that none of the data for that transaction item can be carry forwarded to the subsequent transaction item that can result in having incorrect data or invalid steps being executed going forward. This is the major purpose of having the 'Reset Global Data' Items page.​

------------------------------
----------------------------------
Hope it helps you out and if my solution resolves your query, then please mark it as the 'Best Answer' so that the others members in the community having similar problem statement can track the answer easily in future

Regards,
Devneet Mohanty
Intelligent Process Automation Consultant | Sr. Consultant - Automation Developer,
WonderBotz India Pvt. Ltd.
Blue Prism Community MVP | Blue Prism 7x Certified Professional
Website: https://devneet.github.io/
Email: devneetmohanty07@gmail.com

----------------------------------
------------------------------
---------------------------------------------------------------------------------------------------------------------------------------
Hope this helps you out and if so, please mark the current thread as the 'Answer', so others can refer to the same for reference in future.
Regards,
Devneet Mohanty,
SS&C Blueprism Community MVP 2024,
Automation Architect,
Wonderbotz India Pvt. Ltd.

View answer in original post

4 REPLIES 4

Hi @Sean Scudellari,

I would say this page is created generally to clean up any error variables that might have occurred in the prior steps. Sometimes there can be exception variables which can hamper the normal processing of the next subsequent action. In such cases, it is always a good practice to first get rid of the current exception that occurs in any case before proceeding onto the subsequent queue item.

This check always ensures that no matter what happens in the next transaction item, we won't carry forward any existing exceptions and continue with the normal flow of data. Moreover, in scenarios where we have consecutive exception checks the reset page will always ensure that the consecutive exceptions are checked properly in the subsequent transaction items if they occur at all.

------------------------------
----------------------------------
Hope it helps you out and if my solution resolves your query, then please mark it as the 'Best Answer' so that the others members in the community having similar problem statement can track the answer easily in future

Regards,
Devneet Mohanty
Intelligent Process Automation Consultant | Sr. Consultant - Automation Developer,
WonderBotz India Pvt. Ltd.
Blue Prism Community MVP | Blue Prism 7x Certified Professional
Website: https://devneet.github.io/
Email: devneetmohanty07@gmail.com

----------------------------------
------------------------------
---------------------------------------------------------------------------------------------------------------------------------------
Hope this helps you out and if so, please mark the current thread as the 'Answer', so others can refer to the same for reference in future.
Regards,
Devneet Mohanty,
SS&C Blueprism Community MVP 2024,
Automation Architect,
Wonderbotz India Pvt. Ltd.

Thank you for the explanation @devneetmohanty07. If I am understanding correctly, are you saying that there may be logic within the main process flow that will prevent the process from executing normally if an exception is currently logged, so that is why the exception variables get reset after processing each queue item?​

------------------------------
Sean Scudellari
------------------------------

Exactly @Sean Scudellari, think of it like this what if you are doing a check at the start of your work step for any kind of exception or doing this check anywhere in between. If let say transaction 1 faced an error and it stayed in the variable for some reason by the time we went for second transaction, this check can produce wrong results as it will think this error belongs to the current transaction whereas in reality it belonged to the earlier transaction.

This not only extends to exceptions but it can be extended to anything ranging from a simple Flag value which can determine a key condition to anything complicated like a collection which is supposed to carry key data from a given transaction item. As a best practice, once you have decided that a work item is marked as either completed or an exception you should always reset key data items and collections so that none of the data for that transaction item can be carry forwarded to the subsequent transaction item that can result in having incorrect data or invalid steps being executed going forward. This is the major purpose of having the 'Reset Global Data' Items page.​

------------------------------
----------------------------------
Hope it helps you out and if my solution resolves your query, then please mark it as the 'Best Answer' so that the others members in the community having similar problem statement can track the answer easily in future

Regards,
Devneet Mohanty
Intelligent Process Automation Consultant | Sr. Consultant - Automation Developer,
WonderBotz India Pvt. Ltd.
Blue Prism Community MVP | Blue Prism 7x Certified Professional
Website: https://devneet.github.io/
Email: devneetmohanty07@gmail.com

----------------------------------
------------------------------
---------------------------------------------------------------------------------------------------------------------------------------
Hope this helps you out and if so, please mark the current thread as the 'Answer', so others can refer to the same for reference in future.
Regards,
Devneet Mohanty,
SS&C Blueprism Community MVP 2024,
Automation Architect,
Wonderbotz India Pvt. Ltd.

Thank you so much for the explanation, @devneetmohanty07! That makes a lot of sense. ​

------------------------------
Sean Scudellari
------------------------------