Scheduler: Execute all tasks of a scheduler on the same resource in a resource pool

[RobertRoginer]

With resource pools, it is not possible to execute all tasks of a scheduler on the same resource.

Example:
We have 3 resources in a resource pool (VM1, VM2, VM3).

When I create a scheduler, I always have 3 tasks (I am sure this is the case for many customers):

- Windows login
- process
- Windows logout

If I now run a scheduler on the resource pool, the following happens:
The login process logs into VM1.
The actual process is trying to run on VM2.
The logout process tries to log out on VM3.

We want all tasks from a scheduler to run on the same resource in the resource pool. This is important because of security reasons. We have set it up in such a way that each process has its own Windows user, which has limited access rights to directories etc.

[PvD_SE]

In our shop we have this already as we always run several processes to set up the environment before running the process. But that said, I'm no longer sure if this is standard BP behavior or designed by our CoE...

Anyways, I think this should be possible in out of the box BP. If not, it should be implemented regardless of the vote count. Alternatively, perhaps a DX object could be published?

[chris.strong]

Hello @RobertRoginer and @PvD_SE, 

We’ve gone and delivered this with a capability we call Process Chaining in WorkHQ.

With Process Chaining, you can chain together up to three processes in a process run to leverage Login Agent to securely log in to an execution machine while also benefiting from dynamic digital worker allocation.

You can create a chain of processes in a process run to dynamically select any appropriate digital worker from a group and ensure that it securely logs in to an execution machine using specific credentials, before then running the required RPA automation. Once the automation is complete, the machine can be cleaned up and logged out, ready for the next automation.

For processes in a process chain, the digital worker is reserved by the allocator until the last process in the chain is complete, regardless of whether it was explicitly selected or was allocated from a digital worker group. This ensures that the same digital worker runs each process in the chain, and cannot be allocated to a different session when it completes one process and is waiting to start running the next one in the chain.

Example process chain

1. Process 1 – Logs in to a machine with named credentials.
2. Process 2 – Runs the processing automation to perform the required work, in the context of the user logged in to the machine.
3. Process 3 – Cleans up and logs out of the machine.

Re-reviewing this idea a few years on, and as it directly fed into the work we took on and delivered in SS&C Blue Prism WorkHQ.  I am now marking as delivered as it's available across Blue Prism Enterprise / Blue Prism Cloud with Automation Orchestrator (powered by WorkHQ) and natively with WorkHQ.

Let us know if there are any questions.

Kind regards

Chris Strong

Group Product Manager

SS&C Blue Prism