An important thing to note about Blue Prism is that the automations do not run on the Application Server machine. The App Server sends commands to various machines called Runtime Resources to log in as a particular user. Once that machine is logged in, more instructions are sent from the App Server to tell the Runtime Resource what Blue Prism Process to run. The code executes locally on the Runtime Resource machine where that user is logged in, not on the App Server. It can be a little confusing because you view the logs from Control Room which you receive by connecting to the App Server, but the user that is applicable for what you're doing is definitely the one that is logged into the Runtime Resource, not the user that is running the Blue Prism Application Server.
The way you can check what user will be used is by looking in the Blue Prism Environment's Credential Manager (System tab > Credentials) and see what Usernames are in the Windows login: credential for the Runtime Resources (the machines).
I'm not sure I agree that using the same resource is a bad idea. It takes very little time to log out of a machine and if the process doesn't need to run all day, then I see no problem with running on the same resource. But, to Vivek's point, it's not really a scalable way of doing things, especially if you need to constantly log in and out. In that case I'd say you should run both resources simultaneously using a Work Queue for interaction between the two, so that the 'hand off' is just work queue items rather than handing off between tasks.
Here are two ways you could set it up. The first is less scalable than the second but is an easier implementation and works just fine for an automation that can do the first half of the work for all the cases at once and then can do the second half all the cases when logged in as the second user.
- Task 1 logs into Resource1 using Username1 and has a 120 second post completion delay.
- Task 2 runs Process1/Job1 using Username1 since it's auto SSO, and it should do the First Half of the work for every single one of the work cases/work queue items.
- Task 3 logs out of Resource1 and has a 60 second post completion delay.
- Task 4 logs into Resource2 using Username2 and has a 120 second post completion delay.
- Task 5 runs Process2/Job2 using Username 2 since it's auto SSO, and it should do the Second Half of the work for every single work queue item.
- Task 6 logs out of Resource2.
The other way that would be necessary for a large volume of work cases:
- Task 1 logs into Resource1 using Username1, and logs into Resource2 using Username2. (120 post completion delay)
- Task 2 runs Process1/Job1 on Resource1, and runs Process2/Job2 on Resource2.
- Task 3 logs out of Resource1 and Resource2.
In the second way above in Task 2, there would need to be some serious consideration and design for handling the work queue(s) and work queue items with proper updating of statuses and tagging to ensure that items are worked first by Process1 and then second by Process2.
I swear I meant to just type a paragraph or so. What happened to me.
------------------------------
Dave Morris
3Ci @ Southern Company
Atlanta, GA
------------------------------
Dave Morris, 3Ci at Southern Company
