Setting DB connection dynamically from Control room

[sridharpp]

Hey guys,

Has anyone worked out a mechanism to dynamically switch the DB connection on a runtime resource from the control room? Any guidance would be very helpful.

Cheers

------------------------------
Sreedhar Panaman Parameswaran
Senior Specialist

------------------------------

[david.l.morris]

Disclaimer: I have only tried what you're suggesting on a small scale and only from my work station.

There are a couple things to be aware of first. You cannot manage this from Control Room because Blue Prism does not have a 'Control Room' that manages multiple environments (multiple databases). Each instance of a Control Room that you might see or interact with is tied to a specific environment. So, you'd have a separate Control Room for each: DEV, SIT, UA/QA, PROD, etc. While it is technically possible to use one Control Room interface to trigger the dynamic switching like you're looking, I imagine this would be very hackish and awkward, so I'm not even going to describe ideas for that.

So, I think this is going to depend on your situation. Are you talking about ad hoc switching that is triggered manually by a person? If so, I'd use CLI commands to do this. It could be as simple as having 2 files on the resource machine that run automate.exe with switches/options each pointing to a different dbconname. Then you can use a batch or PowerShell script from your machine to trigger one of the files to run. The only other thing to deal with is to cause the runtime resource process to end when you want to switch the other. I know there's a task kill command or something like that, but I have no idea if that's the right way to tell the runtime resource task/process to end.

------------------------------
Dave Morris
3Ci @ Southern Company
Atlanta, GA
------------------------------

[sridharpp]

Im trying to connect my app server to 2 different databases so that I can lock the code in one and have all edits to the artifacts go through the second one. And while doing so, be able to do test the codes remotely on the runtime resource. When you have a vastly expanding number of runtime resources, the infra complexity and costs skyrocket. A multi-db approach provides a lot of flexibilty while maintaining production integrity.

I didnt want go the powershell route without checking to see if there was a more graceful way to achieve this.

------------------------------
Sreedhar Panaman Parameswaran
Senior Specialist
Telstra
Australia/Sydney
------------------------------

[david.l.morris]

What you're attempting to do is beyond my competence level, so take my suggestions with a grain of salt and maybe someone more experienced will chime in as well.

I'm not sure what parts of your plan are already working. However, for the part about dynamically choosing a connection for a runtime resource, I suppose you could use two ports on a machine to run 'two' runtime resources on it. That way, your runtime resource can be permanently attached to both of the environments and run processes from either of them. I imagine you could run into processes interfering with each other since Blue Prism would no longer be able to 'lock' the machine using runmodes, but that might be an idea worth pursuing. I mean, you're already trying something that makes me dizzy, so you might as well go all out? =)

------------------------------
Dave Morris
3Ci @ Southern Company
Atlanta, GA
------------------------------

[Walter.Koller]

A runtime resource consists in two stages, one is being logged off but LoginAgent running and the other is when the runtime resource is ready to execute processes in specific user contexts.

For us the LoginAgent just executes/triggers the Windows login process and while loading the Windows profile of this user, a batch file is executed out of the autostart folder.
This batch file defines where the runtime resource is connecting to. It might be possible to change this autoexec batch file to execute another file outside of the user profile that could be altered by LoginAgent process. My first tests looked promising.
​Something similar could be done to change the connection defintion in the LoginAgent config, so after log out the resource would appear in another control room.
The target environments could be then passed as start parameters in the control room.

We are also using several databases because of team and environment separations but we have a more static approach since we want to have clear overview on who uses which resources for what purpose. And to use scheduler, which in your case would add additional complexity because you would not want to move one resource to another database when there is a process waiting to be executed. You could use resource pools to mitigate that of course.

How many runtime resources do you have to manage?

Regards


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

[AndréÁgueda1]

Hi Walter,

I was actually looking up for exactly the same solution as you, i.e. to connect a app  server to several DBs, in order to manage several databases under the same control room, but I didn't manage to find much information about it.

Were you able to progress more on your solution?

Thanks

------------------------------
André Águeda
------------------------------