topic Hi, Please let me know the… in Product Forum

Login Agent with Resource Pools

TomCirone — Wed, 16 May 2018 20:38:00 GMT

According to BP documentation, you need to have separate schedules to use the login agent. Does this mean that you can't use resource pools with the login agent? How can you guarantee both the login agent schedule and process schedule run on the same machine if they're separate schedules?

I've never tried to run Log…

John__Carter — Wed, 16 May 2018 23:27:00 GMT

I've never tried to run Log In against a pool but I guess it might work. But you're right, if it did work then the pool would dynamically choose a resource to log in, but the next schedule would not 'know' which resource that was. As an experiment you could consider having your 'logged out' resources use a non-standard port, and create a 'Logged Out' pool of those resources. Then create a 'Logged In' pool of resources that use the default port. From Control Room (and to the Scheduler) these would appear as two sets of different resource PCs. The first pool would provide the next available logged out resource, and the second pool would provide the next available logged in resource. It would be interesting to know if that would be workable.

Hello all. Please point me…

bjwestwo — Sat, 02 Jun 2018 22:57:00 GMT

Hello all. Please point me to any documentation on how one would use the Login agent with Resource Pools. I have found no information on these two things together. A resource pool is supposed to work like an individual resource but I cannot get the Login process to run against a pool. My expectation is that the Login process would run on all resources in the pool that are available. Or that is what I need to be able to do -- get all resources logged in then have another schedule run a process on any of the available resources in a pool. After that, the Logout process would need to run on all of the resources. Is there some expectation that all resources will always be in a logged in state when using resource pools? If so, then there should be a way to have resources in a pool and not in a pool. The Login and Logout processes need to be able to run against the resources outside of a call to a pool like the idea by John.

bjwestwo - FYI when using a…

John__Carter — Mon, 04 Jun 2018 13:54:00 GMT

bjwestwo - FYI when using a pool, BP doesn't start the process on every machine in the pool, it will start 1 instance if one of the resources in the pool is free. Think of a pool as a team of workers, and the foreman says 'I need someone who is available to do a job for me'. The idea of a pool is that you'll use any available machine rather than fixate on a specific one.

Hi, Please let me know the…

Anonymous — Fri, 08 Jun 2018 13:15:00 GMT

Hi, Please let me know the steps how can i implement the Resource pool concept. Thanks

Hi Let's say a resource pool…

Mei_YingLim — Thu, 14 Jun 2018 12:00:00 GMT

Hi Let's say a resource pool is made up of 3 computers. How can we get all 3 computers logged in using Login Agent? If I schedule the Login Agent against the pool, only 1 computer will get the instructions. That first computer gets connected and is logged in. Subsequently, if I run the Login Agent against the pool again, that 1 active computer will start the session. The remaining 2 computers will never be logged in. What is the best way to get the remaining 2 computers logged in? Thanks!

Pools aren't really intended…

John__Carter — Thu, 14 Jun 2018 14:47:00 GMT

Pools aren't really intended to be used with Login Agent. As mentioned above, pools enable you to say 'I want to run a process but I don't care which of these resources it runs on, any will do'. The conundrum with Login Agent is that a resource PC can exist either in the 'logged out' space or in the 'logged in' space, depending on whether the user is logged into Windows. You'll need to read up on Login Agent if this is confusing. One possible workaround is to force the 'logged out' resource PC to use a non-standard port number (ie not 8181), so that it can be differentiated from the resource PC that runs after log in. For example LoggedOutPool PC100001:8182 PC100002:8182 PC100003:8182 LoggedInPool PC100001 PC100002 PC100003 I've never tried this arrangement, but I suspect it could work. That said, it probably over complicates things and it would be easier to just schedule the login process on each individual machine.

How about if we had separate…

IshaSingh — Fri, 15 Jun 2018 07:43:00 GMT

How about if we had separate tasks in the schedule, that would run an individual login on successful/unsuccessful completion of one login? I say both successful and unsuccessful because we need to ensure the logins occur, regardless of whether one login fails (which would not trigger the others if we only keep the condition of 'on complete'). What do you guys think?

Dear all, My team too has…

LorenzLachenmei — Wed, 10 Oct 2018 14:51:00 GMT

Dear all, My team too has created a ticket about if it is possible to make sure that a login and a subsequent process will run on the same resource and so far got this answer: https://help.blueprism.com/Installation-Platform/Configuration/Resource-Pools/1168521882/Can-I-use-Resource-Pools-with-Login-Agent.htm So we came up with the following solution that could allow us to include Login Manager tasks in the a schedule and still address individual resources in a Resource Pool. 1. All idle resources are logged out. 2. When a schedule is due, Login Agent logs in on a machine. (An Is-Logged-In check or unconditional wait stage is added afterwards, because the resource needs longer to launch automate.exe than the agent allows until it reports success for the login.) 3. The subsequent process gets allocated to the same resource because all other members of the pool are unavailable. So far, this sounds feasible, but the solution is confronted with a racing condition if multiple logins are scheduled for the same time. In this scenario it could happen that the scheduler has more than one resource to chose for the subsequent process. To amend this, the Environment Locking feature could be added to the Login Agent's login: 2.a) There will be 1 lock for each Resource Pool. The Login Agent attempts to acquire the lock and stores the token. If it can't acquire the lock, it will retry later until a set timeout. This will avoid a situation where more than one login is happening in a Resource Pool. 2.b) The Login Agent performs the login as described in Step #2. 2.c) The Login Agent releases the lock using the stored token and will end immediately. Any feedback about this idea would be highly appreciated, as it is not easily tested. Our concerns are in particular: - Can the Environment Locking feature be used inside the Login Agent? - I feel a bit queasy about using environment locking, because unlocking requires the token. If the token gets lost because Login Agent crashes, this impacts the whole Resource Group. In this case, only an operator can release the lock in Control Room, as we understand it. Cheers, Lorenz

We currently use Login Agent…

AmiBarrett — Mon, 15 Oct 2018 22:43:00 GMT

We currently use Login Agent as part of a pool. If you use the process ""Login"" supplied as part of the VBO release, it will dynamically reference a credential by machine name. The name for these credentials has to follow the following format: ""Windows Login: MACHINENAME"". So if for example, your pool contained DWVM1, DWVM2, DWVM3, you would need to create credentials named: ""Windows Login: DWVM1"", ""Windows Login: DWVM2"", ""Windows Login: DWVM3"".

RE: We currently use Login Agent…

RPAWizard — Thu, 10 Aug 2023 14:15:00 GMT

@AmiBarrett: Thank you for the hint! The Login works for me. However, how does your Schedule look like? My schedule ist Login-process-logout (running time > 2 min) and runs every minute. I have 2 ressources in my pool. The scheduler always starts only on one of the machines. The next schedule doesnt start after a minute but waits until previous schedule has finished.

Do I need 2 Logins,processes,logouts for 2 Resources in the scheduler?

------------------------------
Lukas Maier
------------------------------

RE: We currently use Login Agent…

AmiBarrett — Thu, 10 Aug 2023 14:25:00 GMT

It's been a few years since then, and I've since changed employers. In that particular deployment, my team had actually written our own controller in C# to replace the one provided by Blue Prism, which got around some of the limitations of the 5.x platform that were present at the time (this being one of them).

Your order of tasks within a schedule looks correct, and the scheduler shouldn't be aware of which account is being supplied to Login Agent on that level. In theory, as long as it's a pool, it should allow you to execute the same process/schedule twice. If it's still causing problems, you might try experimenting with an active queue against your pool.

------------------------------
Ami Barrett
Solution Architect
Karsun Solutions
Plano TX
------------------------------

RE: We currently use Login Agent…

RPAWizard — Fri, 11 Aug 2023 09:02:00 GMT

Thank you for the reply Ami!!

Active queues doesnt fit our use case. However, I am playing around with environment locks so that the pool is able to check if a resource is available. I plan to run two separate schedules on the pool with a little time in between.

Will keep you updated 🙂

------------------------------
Lukas Maier
------------------------------

Re: Login Agent with Resource Pools

chris.strong — Mon, 06 Oct 2025 14:25:14 GMT

Hello @TomCirone

I believe we have solved your original request with Automation Orchestrator (powered by Next Gen) and the recent additions of Dynamic Worker allocation with process chaining.

I appreciate this question was raised a long time ago. It is one of the multiple customer points of feedback which led us to deliver Automation Orchestrator (powered by Next Gen). Our latest enhancements include Automation Flows, Dynamic Worker allocation, Process Chaining, Digital Worker Groups, and Triggers, which provide flexibility, efficiency, and control over automation processes. These capabilities are available to our Blue Prism Enterprise customers with Automation Orchestrator (powered by Next Gen).

Our Automation Flows (which supersede schedules) allows you to create sequences of automations that can be executed in a specific order, and separately define multiple triggers, including Work Queue triggers and time-based triggers. We have clash detection built-in, so that if a digital worker is busy, the next session (process run) would be queued, ready for when a worker becomes available, giving you greater resilience and utilization.

Our Digital Worker Capability Groups (which supersede Resource Pools) enables customers to define and manage groups of digital workers with specific capabilities, ensuring that automations are executed by the most suitable workers.

A digital worker group is a collection of digital workers with a shared set of capabilities, defined within an environment.
Within an automation flow, when defining a step (task) that contains an RPA process run, you can choose a digital worker group to run the process instead of selecting an individual digital worker, and the next available online digital worker in the selected group then runs the process.

In addition, our Process Chaining capability enables customers to create sequences of automations that can be executed in a specific order, including login and logout steps.

A Process Chain allows you to chain together multiple 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.

Tip: Even if the first or second process in the chain fails, the third process will always run to ensure that the machine is correctly cleaned up, logged out, and returned to a state where it is available to be used again.

For processes in a process chain, the digital worker is reserved by the Automation Orchestrator 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.

This allows for more efficient and streamlined automation workflows because a chain can be assigned to any worker within a customized capability group.

To learn more about Automation Orchestrator (powered by Next Gen) and how it can help your organization streamline and optimize your automation workflows, please visit our online documentation portal at https://docs.blueprism.com/en-US/bundle/next-generation/page/automation-orchestrator.htm.

Related ideas where I've shared the same update:

I am really excited to see the impact that these capabilities will have on our customers' automation initiatives and look forward to continuing to innovate and deliver value to our community.

Kind regards

Chris Strong

SS&C Blue Prism – Senior Product Manager (Next Gen RPA)