Managing a very large number of robot parameters

Help
1

I’d like to understand my options to manage a very large number of robots configuration parameters.
Please note that I am writing about information like website URLs, email recipients, output folders, that you want to keep outside of the robot to be able to change its behaviour without re-programming it.
I am NOT writing about parameters passed to workflows inside robots (arguments).
I am NOT writing about robots’ general configuration settings like loginToConsole/screen resolution.

We are currently migrating 15+ robots to an Orchestrator environment with a total number of parameters well over 200. Orchestrator has assets, but I can’t imagine having to add 200+ assets one by one (actually, they’re 400+ because we have both Test and Production instances).

We used to lean on XLS files, read by each robot when it starts and copied into a Dictionary. This approach has quite a few cons:

  • you must put the XLS in a location where it can be read by the robot
  • you must put it in a location where you/others can edit it
  • you need a local access to the robot server/environment in order to edit it
  • you need Excel application
  • inside the robot, you must bring the params dictionary along the invocation chain, from the Main to the utmost workflow

I am then asking what other options we have, to minimize point of failures and inconveniences, and possibly centralized.

2

Hi,

As of now, nothing very optimal and configurable with a good separation of concerns.
I have the same feeling that something is missing, that one of the reason I posted this on User voice and it is now as IPlanned, so there is some hope!

Cheers

3

@Florent_Salendres

I had a same opinion about it.

If the below solution is possible, most of the problems are solved.

If we have a chance of adding database (limited size) within a project (DBMS - Database Management System) would be really helpful.
And allowing to run queries on database like SQL - much more easier.

Regards,
Karthik Byggari

4

Hi @KarthikByggari,

The issue I see is that this db file being part of the project would be that it will have to be copied to each package / release later. That would be also the case with a .config file as well but I believe the Orchestrator/Studio would interact better with xml/json than db file.

Overall I think what we are missing is a proper UI to edit those (localy and remotely), the format how is stored is not so important at the end.

1 Like