It is as Walter describes. It's not possible for Blue Prism instructions that are sent to the Login Agent Runtime Resource to survive after it shuts down and the Blue Prism Runtime Resource starts up. I'm referring to the 'hand off' that would have to occur as the machine is logging in. The only way for this to work would be for either (1) an enhancement to the Blue Prism Scheduler or (2) an outside controller app is used as a replacement for Scheduler. The first way I think is unlikely to happen. In the last 3 years, I think the only enhancement I've seen to Scheduler was the post-completion delay. I could be wrong. Maybe there were other things, but it certainly isn't a focus for improvement in the tool. The second way is possible but only if your organization has someone with the technical ability to build a controller app. Ami Barrett has mentioned he's done at his organization and it works well for them. I'm pretty sure eventually I'll do this as well because Scheduler just doesn't offer the flexibility needed for truly build-it-and-forget-about-it back office software robots.
Now, that doesn't mean you can't achieve what you're looking for to some small degree.
Here's how we use Scheduler/Login Agent for most automations...It's very similar to what you and Walter described. Assuming we have only one process for the automation:
- Task 1: Login on the RR
- Post-Completion Delay: 120 seconds
- On Complete: Task 2
- On Exception: Task 2 (sometimes we have it Abort here but if we allow it to run Task 2 then the main process can email us if it fails because it's not logged in --more on this later)
- Task 2: Run the automation's main process
- On Complete: Task 3
- On Exception: Task 3
- Task 3: Logout
Now, if we have an automation that we really need to ensure that it runs right away if possible and we're concerned about the primary RR being offline or busy, then sometimes we'll use extra tasks for use on a different Runtime Resource that will only run if the primary tasks fail. Here's an example:
- Task 1: Login on RR1 (Runtime Resource 1)
- Post-Completion Delay: 120 seconds
- On Complete: Task 2
- On Exception: Task 4
- Task 2: Run the automation's main process on RR1
- On Complete: Task 3
- On Exception: Task 3
- Task 3: Logout on RR1
- On Complete: Stop
- On Exception: Abort
- Task 4: Login on RR2 (Runtime Resource 2)
- Post-Completion Delay: 120 seconds
- On Complete: Task 5
- On Exception: Task 5
- Task 5: Run the automation's main process on RR2
- On Complete: Task 6
- On Exception: Task 6
- Task 6: Logout on RR2
- On Complete: Stop
- On Exception: Abort
I hope that isn't confusing. The main point is that if Runtime Resource 1 is busy or offline then it'll automatically run on Runtime Resource 2 and we're happy. Also, though technically your Login process has to be running as Foreground or Exclusive mode probably for this to work (ours currently runs as background so it wouldn't work), you could use the same concept above but have Task 2 On Exception run Task 4. This might leave Runtime Resource 1 in an logged in state at the end, but it may be more important to ensure the automation tries again than it is to ensure the machine logs out.
What your client is asking for is 'strictly speaking' not possible within Blue Prism. While you can put a Login and Logout call inside the process, you really have to think it through before doing this. In my opinion, it's a terrible idea to put those inside the process, though I have seen this done. The only one that might make sense is the Logout action inside the process. I could see it being useful in certain situations.
For the functionality of the automation being able to restart the machine itself and then continue working after that... That would be pretty cool if it could do that, but again I'd say we're back to needing an enhanced Scheduler or you could make a controller app for this. It's possible that Thoughtonomy has something like this, so maybe what they bring to the table will eventually get implemented in the on-prem version of BP. But I wouldn't hold my breath.
Edit: I forgot to explain the thing about that we let Task 2 run even if login fails. The reason we do this is that we use an internal API service that sends emails, and we also use SMTP as a backup as well. Because neither of these require the machine to be logged in, our automations can send us notifications of failures if they try to run while the machine is logged out. The other way to handle this would be to put a send email action inside the Login process, but we just haven't done that (yet). This of course doesn't help for anyone who isn't allowed to use SMTP and doesn't have any other method of sending emails that doesn't rely on the desktop installation of Outlook (such as MAPIEx and the MS Outlook Email VBO). There are other options such as Agilify's EWS object and GRAPH API (but I haven't tried those from a logged out state).
------------------------------
Dave Morris
3Ci @ Southern Company
Atlanta, GA
------------------------------
Dave Morris, 3Ci at Southern Company
