Robot Resource delay between VM and Control

[Walter.Koller]

I already know there is some significant delay until a Runtime Resource shows up as online in Control after the login procedure is finished,

Just now I was remotely connect to one Runtime Resource when login was initiated and I compared when this VM would be available.
The VM finished the log on procedure, started the BP Agent and the log windows showed it is successfully connected to the app server. I wonder why it takes an additional minute to say logging is set to external. 
This VM is shown as offline in Control... I repeatedly clicked on refresh and tried to drag a process on this resource, just in case there is a delay until the status is visually updated in BP.
In the end it took more than three minutes from when BP Agent on resource was ready and until I can use them in Control,

Is there any possibility to make this delay shorter?
BP client and BP agent can communicate directly, so why there is the need to wait for status update of app sever?

------------------------------
Walter Koller
Solution Manager
Erste Group IT International GmbH
Europe/Vienna
------------------------------

[JohnCowell]

Hi Walter,

when a RTR first starts up it updates a flag in the database (BPAResource statusid) to indicate this - 1 meaning ready. The control room view of a resource is dependent on the connectivity between the control room machine and the RTR. The 'State' column will report the database interpretation from BPAResource but the 'Connection' and 'Last Connection Message' are purely the view point from that control room machine. In other words, if someone logged onto another machine and opened control room they could see that RTR report different values for 'Connection'. It may be worth checking during these tests what the same view is from an IC->Control Room when logged onto an App Server to see if it differs. There is also difference between versions of the frequency of 'healthcheck' ping/pong messaging that takes place between the App Server/Control Room and the RTR. There is no way to adjust this, however.

------------------------------
John Cowell
Senior Software Support Analyst
Blue Prism
------------------------------

[Walter.Koller]

Thanks for your reply.

I was observing the Windows logon procedure on RTR until everything was started up and ready. So I would assume the runtime BP process already updated its status at application server. I tried to drag a process on this runtime resource in Control but it was rejected saying it is not available yet. It took about 1-2 minutes until process request were accepted. I didn't check on database level but for me it seems BP server needs up to 2 minutes to notice the status update of RTR, although the status would have been updated by BP server itself and there is no way to enforce reading the new status.
Another reason might be, the BP process on runtime resource started but did not finish initialization. Then I am wondering what would take up to 2 minutes in the start-up phase to be completed?

------------------------------
Walter Koller
Solution Manager
Erste Group IT International GmbH
Europe/Vienna
------------------------------

[JohnCowell]

It may be worth logging a ticket for this so we can gather more information for investigations. Does this happen even when using Control Room when logged onto the App Server and dragging a process over the resource there? What sequence of events do you see in the listener window on startup and do you see a connection event from your Control Room machine appear there?

------------------------------
John Cowell
Senior Software Support Analyst
Blue Prism
------------------------------

[Walter.Koller]

Thanks for your reply. 
Maybe I already confused myself 🙂 I will try to put things chronologically.

1. send Login process in Control to runtime resource (VM)
2. VM initiates login and all related start up activities coming with Windows and user profile, including bat file to start BP as resource
3. BP resource is started and log window shows connection with app server was established > this should be the point when app server considers VM as online
4. BP resource connects to various clients currently logged on to Blue Prism
5. 1-2 minutes passes while Control shows VM as 'online - connected' but it does not accept execution requests. When looking at VM directly no reason for possible delay can be identified. Windows User profile, Start up App, BP Resource, ... all are started and idle
6. VM now accepts processes

Since BP resource log window says it is connected to App Server and is also shown as 'online', the status update to App Server and DB should have been done successfully.

Since BP resource log windows show connected clients and it is also shown as 'connected', direct connections to / from resource are already working. If this would not be the case Control should show 'online - not connected'.
We have one case where resource and client are in different network segment and are blocked for direct connections but both can communicate with app server. This resource is shown as 'online - not connected'. Drag & drop of processes to this resource don't work but it is possible to schedule jobs since those are initiated by app server and not the client. 
We also experience the 1-2 minute delay of not being able to execute processes when initiating an existing schedule with run now. I am assuming 'run now' is sent to app server to process the whole schedule and no direct connection is needed.

------------------------------
Walter Koller
Solution Manager
Erste Group IT International GmbH
Europe/Vienna
------------------------------