Let’s say I have a process with a very demanding SLA: each transaction should be run as soon as it is created and no later then 1-2 minutes? And I might have up to 100 transactions at a time, each transaction should end in 3-4 minutes, or even less?
The question is how to make sure each transaction starts asap with the least number of unattended licenses?
How do I design my infrastructure to accommodate this scenario?
Can I have scheduled executions on the same tenant where I have queue triggered based transactions and still meet the SLA at any time, or do I need to have a separate tenant only for queue triggered based transactions?
If the transactions can be run in background - if I use background processes to spare virtual machines, can each background automation process its own queue transaction? Does this mean that each background automation will use a license from the pool (here I am 99% the answer is yes - but I hope someone will propose attended automations, because on attended licenses you can have as many background processes as you need and use only one license - problem is though that you have to manually start the automation when the robot fails… ).
I don’t have a clear answer since it is of course very use-case specific.
It would depend on the speed at which transactions can be created and completed.
First and foremost: the reaction time of the robot.
If 100 transactions are created ‘instantly’, considering a classic dispatcher - performer model, it’s easy to make a queue trigger based performer, which can be run in parallel on multiple instances to process within SLA. The exact number of required licenses would depend on the processing speed versus the potential peak load generated by your dispatcher.
And yes, you are correct, as a background process you’ll drastically improve processing speed, running multiple sessions at once each consuming separate items from the same queue, but you’d need to have guarantees that it can run in the background (so no UI interactions etc.) You can then calculate the amount of licenses versus the average or max workload depending on the wiggle-room in the SLA.
More on the critical path would be the dispatcher process itself. How is this triggered? If an API feeds the orchestrator you get near real time responses, but if the dispatcher is a bot itself you either need a persistent running bot continuously polling for input, or run at a very high frequency, consuming a full license all on its own.
Another thought I have, is that if ‘all’ your operations in this process can run in the background, if RPA is a proper solution. Maybe products like integration service (or competitors equivalents) can provide a better near real time response and processing speed than you would reach with RPA only.
Thank you for your answer - this is exactly my thought also - is UiPath Suitable for these type of scenarios, where you need to answer asap(e.g. : a client is waiting in the shop and the robot needs to provision a service)?
My main problem is how do I streamline (or make more efficient) the use of licenses? I will be feeding the performer through orchestrator api calls to populate the queue.
To optimize license costs I’d rather dive in the prospects of using an attended license, with numerous background processes started on this license to consume from the queues. What happens in this case if the main process hangs or crashes, what happens with the background processes? Each background process is independent from one another?
Is it ok to use an attended license in this way?