#BPTechTips #TipOfTheDay - Configuration Files in RPA.

[Tejaskumar_Darji]

Hello Community Members,

Today I want to talk about configuration files which are nothing but simple excel files that makes RPA delivery a lot easier.

One of the main goal of any RPA process (from its inception) is to make the Parameters/Variables externalized as much as possible, and that is where the use of configuration files comes in to picture.

For e.g. Project Folders, Credentials name, Website URLs, Timeouts, Retry attempts, Email IDs for alerts, Defer time, Max attempts, Queue name, Append Fields, Dynamic delay, API Calls, Dynamic Expressions, etc - these are some sets of parameters that are dumped into config files but can be many more as you develop your logic.

Config files are built to keep in mind that business users can update the config parameters at a given time as per the requirement and code changes are not needed.

Blue prism logic should be efficient enough to adapt to config changes and work accordingly.

And as we start using config files in the project we must avoid hard coding of the values inside processes & objects.

What are your thoughts! Feel free to add more insights to this #BPTechTips.

#BPTechTips #TipOfTheDay

------------------------------
Thanks & Regards,
Tejaskumar Darji
Sr. RPA Consultant-Automation Developer
------------------------------

[RaviKumar3]

Thanks for sharing.

------------------------------
Ravi Kumar
Sr Automation Designer
Ericsson
Asia/Kolkata
------------------------------

[xlxu001]

Hello Tejaskumar,

We utilize configuration files, but this perspective is actually pretty cool.  Do you have any examples of how you have structured all variables you mention below?

Lourdes Urena  | Sr. Solutions Engineering (RPA) | W.W. Grainger, Inc.

Ph: 224-724-5080| lourdes.urena@grainger.com |www.grainger.com

[Sam_C]

Hello Tejaskumar,

Thank you for sharing, I do not commonly use configuration files in my work so I have a few questions:

• Is there a reason why the variables you have listed could not be environment variables?
• Do you have any examples of processes that use configurations files that showcases why they would be better than using environmental variables? 
  
  I generally avoid additional external dependencies to reduce risk but I can understand that there may be scenarios where the benefits could be worth the risk. 

------------------------------
Samuel Cole
Automation Analyst
Benchmark Digital
Europe/London
------------------------------

[devneetmohanty07]

Hi Samuel,

One benefit of using a configuration file I can tell you is that maintenance part around it. Consider I have a process which has like 80 configurable values, now creating 80 environment variables for that process might be a time taking approach. Also, since we do not have any search feature or filtering approach in the Environment Variable UI which Blue Prism provides, maintenance is often a headache. Now you imagine if you have such 10 or 20 processes how much of a space it will take up eventually making your UI also hang in between while scrolling down to search values.

In such cases, a simple configuration file can be handy whose file path you can keep as an environment variable. So in practice if I have let say 20 processes this way I will end up with 20 environment variables storing the file path of each configuration file and within these files I can easily store my value as and when required.

------------------------------
----------------------------------
Hope it helps you out and if my solution resolves your query, then please mark it as the 'Best Answer' so that the others members in the community having similar problem statement can track the answer easily in future

Regards,
Devneet Mohanty
Intelligent Process Automation Consultant | Sr. Consultant - Automation Developer,
WonderBotz India Pvt. Ltd.
Blue Prism Community MVP | Blue Prism 7x Certified Professional
Website: https://devneet.github.io/
Email: devneetmohanty07@gmail.com

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

[PvD_SE]

Hi,

While I definitely see advantages in the use of configuration files for a process, I see them more as a flexible method of storing the input parameters used for a process rather than a replacement for Environment Variables (EVs).

In my view, the method to determine if a data item should be implemented as an EV would be that EVs are reusable values that will be used by more than one process and that will not change often over time. As such I find that an EV being used in only one process should be a parameter instead, again in my view.

However, I foresee great use for configurations files to replace large lists of input parameters for a process. Any change in this input parameter list does not only mean a new release of the process to be deployed, but also adjustment, or replacement of the schedules to run the process. Replacing all input parameters for a process with a single one: the path to the configuration file, would allow more flexibility in process development, and the operators (Process Controllers) can cut down on time used for re-scheduling processes after each change involving input parameters.

I do not buy the argument to put EVs in a configuration file because of the limited search capabilities in BP. Indeed, these search capabilities are sub-standards, and yes they should have improved many versions back. But I still insist on folks actively visiting the BP Ideation pages more frequently and vote on the many Search related ideas that have been launched there and the few that, in my view, were only partially implemented at best. Last time I checked the current year is still 2022, and in these times I expect the best industry standards to be implemented in BP rather than basic ones, this goes particularly for Search.

Hard Coding (HC) is another argument mentioned as an argument for configuration files. HC should basically not be done at all. In practice however, we all know HC makes its way into our processes more often that we like to admit. And perhaps being able to put the HC values into a configuration file would result in cleaner processes, which is always a plus in my view.

Conclusions:

• Configuration file: YES
• EVs should be EVs and not be defined in Configuration files
• BP: IMPROVE SEARCHING STUFF IN YOUR PRODUCT

------------------------------
Happy coding!
Paul
Sweden
------------------------------

[Neel1]

i agree with idea of using config file. we are also using this a lot.. Developers and architect will find a newer a quicker way to do task which is ease of life and easy to maintenance to them. issue around EV handling trigger org to think differently in term of config file.
.

------------------------------
Neeraj Kumar
Technical Architect
------------------------------