Login Agent with Resource Pools

[TomCirone]

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?

[John__Carter]

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.

[BrentonWestwood]

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.   

[John__Carter]

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.

[Anonymous]

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

[Mei_YingLim]

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!  

[John__Carter]

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.

[IshaSingh]

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?

[LorenzLachenmei]

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

[AmiBarrett]

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"".