multiple automation queued in a single VM instance
Hi, I read through some of the existing posts, but not sure it answers my specific question...so here it goes.
I want to setup a single VM. Within that VM I would like to be able to setup a few automations that can be run. They will not run in parallel since Pega is not able to support. However, I am ok if they are "queued" meaning if one comes in first, it runs and if another is triggered it waits until the first one is done and then runs he second automation.
I'm asking specifically because we have some RPA setups where the majority of the work is done on Mon-Tues and then the VM sits idle rest of the week. Why can't I have a secondary automation on same VM using same bot to fullfill the rest of the week.
This allows me to effectively use VMs and bots.
thanks for any heads up
***Edited by Moderator Marissa to update categories***
Sure you can do that. Activities are a great tool for this. Activities execute sequentially and are queued when they are started.
http://help.openspan.com/80/Interaction_Framework/Understanding_Activities.htm
Hi, We are using robot manager and can assign multiple bots to workbaskets wihtin a workgroup. That part is clear...what I was trying to convey (not likely well) is.
The bot has a VM where it runs the automation during RPA. How do I load up multiple automation scripts on a single bot VM in such a way that a single bot who is not fully utilized from a single script can run on the same VM.
I'm trying to cut down the need to have a separate VM for every RPA robot when it's not needed. We have automations that just run for 2 days and sit idle on that VM until the next week.
perhaps, I'm not explaining too well...but if you can provide some more guidance that would be great.
the concept of activities seems to relate to the same automation script calling different parts to run.
I would be talking about 2 completely separate automations (one for finance and one for engineering) that can be on the same RPA VM to be triggered.
This sounds then that you are asking is for one bot to work multiple workgroups. That is currently not possible; at least automatically. You would need to manually restart each bot to point it at a different workgroup. You can start runtime with the /wg="MyWorkGroupName" parameter to get it to start pointed to a different workgroup than the one assigned in the CommonConfig. Activites do not work with the RM currently as it triggers the automation via an activity (and since they are queued, it alone needs to run through completion before any others could start).
thanks for the quick answer. I guess I'm doing a terrible job of explaining. Let me try one more time :)
We are running bot manager and have a Supply Chain workgroup setup. It also has a workbasket setup. All good on the bot manager side. I'm trying to focus on the virtual machine where the bot is actually running.
Scenario would be:
Automation 1 is triggered automatically by a scheduled timeframe built into the code. It runs for some time on Monday and then just waits and listens for a new very short activity the rest of the week. so the bot is then idle on the VM.
I'm now looking to have the same robot & same VM have Automation 2 (can be in same workgroup). When the bot sees the trigger for this one (different trigger), it will pick it up and run .... only if it is not currently running automation 1.
Both automations would run from same VM (just not at the same time) FIFO rule for whatever trigger comes in first starts the automation and then if it sees the 2nd trigger, it queues up to run it when first one is done.
Hope that explained it better.
If using Robot Manager (RM), a bot must be able to support all workbaskets (WB) within a workgroup (WG). You could have as many workbaskets in a workgroup as you like (there's probably an upper limit, but I know that tens of them is fine). This would allow one bot to work through one workbasket and then move on to another.
If you are not using Robot Manager, then you can queue up the work for the RPA as you'd like. You would have to ask your PL about any licensing implications, but technically it can be coded to work from multiple queues at a time. Without RM, keep in-mind that you are responsible for providing the work and queue mechanism to the automation, so that can be built as you see fit.