Advanced Work Queues

[SamLima]

Could anyone please deconstruct these?they are from Advanced Work Queues course

------------------------------
Sam Lima
------------------------------

[devneetmohanty07 · Accepted solution]

Hi Sam,

The mentioned points hold applicable to any real time use case revolving around the usage of work queues. Let me try to elaborate and explain each points one by one.

1) Separate Work Request Confirmation From Work:

Here it has been basically said that whenever we are working on queue items they basically are treated as individual transactions and each transaction is going to take some time while being processed now and then.

Imagine, you have a process where you get around 100 cases a day and you need to process each of these cases through 2-3 steps where each step takes 2 min. Now, if let's say we need to calculate the Average Handling Time of each case, it would be around 6 min (3 * 2 min) in total. Which means the bot is going to take 600 min (100 * 6 min) to process all the cases for a single day.

Now, with this being said as soon as the first case is being worked, we know that there is approximately 594 min (600-6 min) left before the last item would be worked and similarly there would be approximately 588 min (600 - 6 -6 min) left before the second last time in the queue would be worked.

Now, if such a scenario is present then business won't essentially know what happened to these two queue items before 588 min actually passes which is like 9.8 hours! Hence, a better way can be once the items have been added if we can notify the business that the items have been added and are currently being sent out for processing. If it's a web api request, we immediately can send a response back with a success message so that user can know the recent status in real time before even the actual work begins!


2) Allocate Enough Digital Workers:

Most of the processes that we automate is always going to have some Service Level Agreement (SLA) to it which indicates the minimum acceptable time within which the entirety of the process or it's related transactions need to be processed. Automation solutions are developed mostly thinking how well we can produce efficient results within the define SLA's for any given process.

Suppose let say we have a process where we get tickets from customers and based on those tickets we create quotes on a backend system. Now for this entire process of the SLA has been defined to be 2 hours and suppose our bot is taking 2.4 hours because of a peak volume of data coming into the picture. Then probably one way to reduce the overall processing time would be to increase the number of bots.

Suppose if 1 bot takes 2.4 hours to complete a process then we can say that assuming if equal amount of the workload can be distributed among 4 bots then each both can parallelly execute the process within a timeframe of .6 hours (2.4/4 hours) or 36 min. Which means the overall process that was initially completed within 2.4 hours by 1 bot can now be completed within just a matter of 36 min by 4 bots. Hence, more the digital workers more time reduction one can see.

With that being said, the automation design should also include other considerations such as costs of license, application access at multiple service account level and many more things which can pose as a variable factor affecting our solution at times.


3) Have A Robust Contingency Plan:

In an ideal world, all our automation solutions can work flawlessly without any interruptions or environmental issues taking place at any point of time.

However, this is not a case in a real time scenario. There always can be any kind of expected or unexpected interruptions, failures, downtimes which may or may not be under anyone's control.

So every solution must adhere the best practices where we can incorporate the usage of tags, statuses and other queue concepts to effectively log errors, update tags and statuses so that both the support team and business side can be notified of the exact failures.

Also, our automation workflows must be designed in such a manner that if let's say a rerun is required then we should be easily able to do so.

For example, let say we have a process which is dependent on a back end database and due to some reason the back end database connection got lost because of which an error started popping up around 5 PM. Our automation solution in such a case should be able to ideally handle the error popups, log the error, retry connecting with database for a set number of times and check of consecutive exceptions for each cases and stop if the threshold has been breached notifying the business. Also, let's say if the database is up and running at some time later that day after 5 PM and if we want to rerun the failed cases again.

In such cases, we should be able to do so by incorporating some logic the duplicating all those cases in failure in another queue during the failure run itself before terminating the process and this process which has been triggered at a later time should start processing those failed items first by checking the failure queue before going over the pending items in the original queue. The reason is if we those cases are not handled then the overall SLA of such cases can be missed.

If such cases need not be rerun as a part of automation then the business should be accordingly notified so that they can separately process such failed items. The approach needs to be discussed and decided with both the business stakeholders and the technical teams from the application side and the RPA platform side as well.

------------------------------
----------------------------------
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

----------------------------------
------------------------------