Use of config files

Hi,

Could anyone please let me know what are the advantages of using config files over environment variables?

Background :
We have 30+ processes running in the PROD env. and there are more to come. The list of env. variables is really long and is going to grow longer. Hence, thought of using a config file. I've stored all the variables/constants in an xml file to be used as Config file in Blue Prism, read the xml and then stored those values in data items. But, have started thinking about the real advantages of using config files (either xml or .csv files) over environment variables. Please shed your thoughts on this.
 

Pete_L

Active Member
There are very real advantages to using this config file method (discussed below). Your config file idea could allow us to have zero EV's in the BP database. I love it! In fact, I like the idea so much that I'm going to bring it up as an idea to my team. The only disadvantages I can think of are 1) the config file is not stored in the Blue Prism database and would be subject to the risk of deletion from wherever it is stored (likely on a network share), and 2) the data in the config file is not encrypted (which would likely be an issue if the EV's contained confidential data).

The primary issue with Environment Variables is that they take up a lot of space in the Blue Prism database. We currently have about 150 automations, and this number is growing every month. These automations relied on thousands of EV's. When we were at about 100 automations, we decided to try to reduce the number of EV's to save space. We thought of some ideas that allowed us to delete hundreds of EV's:
* Use static data items.
This one was the biggest data saver for us, and it's easy to do. Simply change the Exposure setting on each EV in the process to None. That makes it a plain data item, and the EV name becomes the data item name and the data type is retained. There is no need to find each reference to the (old) EV, as the name doesn't change. We put these static data items on the Main Page in their own block so that they are readily visible. Don't forget to set each one to be Global (i.e., Untick "Hide from other pages".) If we ever do need to change one, we can easily find them in the new block on the Main Page in which they reside. We will need to do a release for the changes, but these are things that will likely rarely (if ever) need to be changed so it really isn't that much of an issue.
* Hardcode some values.
There were a lot of EV's for things that never change, like timeouts, queue names, file paths, our Admin email address, etc. Hardcode them and delete the EV's. If you name the Data Items with the same name as the EV's, then that's all you need to do (refer to the item above).
* Create a single EV for each application URL.
Previously, each process had its own EV for the URL or the path to the application's executable. We have a lot of automations that use the same applications, so having more than 1 EV for each application was wasteful. With this change, you are going to have to track down all the references to the old EV and replace them with the new EV.

We did a similar thing for Credentials. Previously, each application we automate had a separate credential name in an EV for each applicable process AND for each runtime resource (bot) that the process ran on. We eventually realized that, for example, if you have 50 processes that automate something on the mainframe, you only need 1 EV for the mainframe, not 50! We created an EV called "Mainframe Credential" to refer to the "base" credential name format, and gave it the value "_Mainframe". When we use it in a process we call GetResourceName()&[Mainframe Credential], which resolves to <bot name>_Mainframe. You will need to create a Credential for each bot called <bot name>_Mainframe and set each one up with the appropriate user ID and password. This reduced the number of mainframe credentials by half. The same thing can be done for other applications besides mainframe as well.

Remember to update any Release Packages that reference the deleted EV's and Credentials to remove them.

Before you start any of these changes, plan thoroughly. You can ask your database admin for a list of the EV's, Credentials, etc directly from the database tables. Use this data for your planning and execution tracking. We made the changes in our DEV environment, tested, then in QA, and tested again before doing it in PROD. Plan for ad hoc fixing of any PROD automations if they break due to the changes.

Good luck, and thank you for one of the most useful ideas I've come across in a very long time.
 
Last edited:
Hi @Pete_L,

That's a very nice analytical and details explanation. These tips definitely help people who is looking to build processes in Blueprism or improvise processes.

We actually have already taken the above into consideration to improve our methodologies. In addition to those, I was thinking about storing all the process constants in an XML file/Excel file and retrieving them when the process starts. But, that's a good point that you have mentioned that we'll not have control over someone deleting the file who has access to the network drive.

One more question -
Is there any limit on Inputs/outputs that I can send/receive in a page?

I have data items that I need to pass from one page to another - Is it better input/output or to just make them global? Thought the global variables consume more memory? Passing the variables/data items from page to page is bit more extra work, but I like the approach that I can split the process stages into smaller and group them in separate pages instead of combining different calculations/actions in a single page. This would enable the easier management of the process even if someone else is going to take over. My question here is - are there any implications on the performance of the process by this method or any sort of issues?

Thanks
 

Pete_L

Active Member
I don't know if there is a limit to the number of data items you can have. If you really want to know, ask BP Support.

Whenever I need to reference a data item on multiple pages, I make them global. These may consume more memory than local variables, but I would expect the difference to be negligible and I never give it a thought. I have never seen any issue that could be traced back to global vs. local variables. I do like to keep all global and EV data items on the Main page for convenience. If I had to choose between using global variables or passing them from page to page, I will always choose global. That's what they're for!
 
Top