Hi,
Have done some testing with pools and the only way I was able to operate the resource properly was through command line. My thinking is that one resource is "acting" for the complete pool, and if you send a reboot request from a job in BP then the pool go offline for a while. ( Not ideal in my book..) But using AutomateC.exe I could adress a specific resource that is not "primary" in the pool currently.
Maybe I should highlight that we used separate ports for the RunTime and the Login agent. So we would have one resource not in the pool, pointing to the LoginAgent resource ; and the "RunTime" resource beeing a member in the pool.
So, basically I would setup a Login schema, pointing to the LA resource, and when executing it ; the resource would become a active member of the pool. I was planning to have a morning job that would add more resources to the pool during the day, and then in the evening fire a few "logout" schemas just to move those resources to another pool. Then something else go in the way…
But maybe these examples of functions could provide a embryo to something for you.
This functionality is something you want in a resilient and dynamic environment! Hope you get closer to the goal!
Br,
Håkan Engman
Function Login2poolvdi
{
PARAM($vdi,$cred)
$xml = "<inputs><input name='Login Locally' type='flag' value='False'/><input name='Domain' type='Text' value='YourDomain'/><input name='Credential Name' type='Text' value='$($cred)'/></inputs>"
& $AutoC_exe /sso /dbconname $environment /resource $vdi /port 8180 /run "Login v2" /startp "$($xml)"
}
#################################
Function LogoutOfpool
{
PARAM($vdi)
$xml = "<inputs><input name='Force' type='flag' value='True'/><input name='Delay' type='timespan' value='0.00:00:05'/></inputs>"
& $AutoC_exe /sso /dbconname $environment /resource $vdi /port 8181 /run "Logout v2" /startp "$($xml)"
}
------------------------------
Hakan Engman
Automation engineer
Teliacompany.com
Europe/Stockholm
------------------------------
