Best practices for URL management



The aplication for automatization has different ulrs for each environment .
What are the best practices for url management for environments (Dev, QA, PRD)?
I was thinking of using the UiRobot.exe.config, what are your opinions?
As a note, my project only uses robots it does not have Orchestrator.



This is my opinion but I think it’s best to manage your global parameters in a text file like a .config or .settings file for example. Also, if you use direct path to that file then you don’t need to republish the process (if you use Orchestrator) each time you make an adjustment (while that may or may not be a good thing)

you could have the urls for each environment set as parameters and a parameter for which environment to use.
Maybe like this:

envir:= prdUrl

And, you can have other settings too. Your robot would read the “envir” parameter in and use that to read in which URL you use.

For example,
Read Text file to config as String
Assign envir = config.Split({“envir:=”},System.StringSplitOptions.RemoveEmptyEntries)(1).Split(vblf(0))(0).Trim
Assign url = config.Split({envir+":="},System.StringSplitOptions.RemoveEmptyEntries)(1).Split(vblf(0))(0).Trim

You can also do this differently using a json file but I’m not as familiar with its syntax.

In any case, I also think your best practice should be consistent among your organization and there’s no real right answer to what best practice to use. You don’t necessarily need to use a config file but it does make it easier when you start having tons of parameters to go through.



Just an opinion, why not use config.csv files for Dev Pilot Prod from shared location, not just urls you could store other essentials which vary in Environments. Since Uipath has read range activity, the lines of code to retrieve these values will be less than reading from text.


We have data disclosure restrictions where the dev team is no given direct access to PROD data.
Thus, having one config file that has all the env values is not a possibility at all.
We, most of the times use assets.
This way the code in all environments uses the same asset name. but the Environments management team handles what value should the asset hold in that environment.
This way the code also stays intact, data is also not disclosed and URL’s are easily managed.

Note: we have different Orchestrator instances for DEV, TEST and PROD.

If there is a case where single orchestrator instance is used across environments, then you can have a naming convention in place like DEV_Assetname, TEST_Assetname, PROD_Assetname


True, but the User does not have an Orchestrator.

Also true in case for 1 config file for all 3 environments since Prod and Pilot environments are isolated in most of the cases.Besides Orchestrator which has just the Config URL, we use 3 different config files for 3 Environments and Prod sharing is limited to few.

Currently we only have Config Loc and Credentials in the Assets, remaining parameters in the Config file. Not sure if its a good practice, but I find multiple asset creation in multiple orchestrators tedious in 2016.2


Missed that, my bad


True, Asset Management among multiple Orchestrator environments can be tedious.

Another method that can be used for @agjj677 or his organization is to create a workflow that returns the URLs as arguments.

So he could use Invoke Workflow and tell it if it’s a Test or Prod so it can return the correct URL for that Process.