Is there a general best practice guideline covering when it’s best to store your data as an Orchestrator asset and when to store it in a config file?
My process has multiple variable including input and output file paths, allowed email addresses to trigger the automation, trigger keywords, process names to trigger after completion etc. Some are unlikely to change ever, others are more likely to change, and further ones need to be capable of being changed by the business process owner.
I’m struggling to know which ones to put in a config file packaged with the automation, which to put as Orchestrator assets and which to put in an external config file.
Configuration values that require regular modifications, would be placed in the assets and if you have values that remain constant always go for the config file.
It is always good to use orchastrator asset because when you think of scaling your process say from one robot to 10 then it will really so useful and less hectic job for you as all variables are stored in orchastrator.
But problem comes when your process has lots of variable and configurations that case single config file is really helping and making all things sorted
In oreder to achive centralized asset and lots of variable you have one another option that is used hybrid option.
You have to create one config file(most probably json or xml) then store all keys and values in as process variable. Use this same string in orchastrator asset to have centralised access.
Now you have achived both in single go but just remeber one thing you also need to add few activities for json or xml prasing and thats it.
I hope i answered your question …
If you still have some doubts, lets discuss
Regards,
Aditya
I have a project I completed that had over 100 parameters. Most projects should utilize a config file exclusively. They are parameters that help your job run, and they can be from filepaths to status messages to values that set timing properties.
Then, there’s also the opinion of whether or not an end user should have access to a config file to change parameters and which parameters they have access to. What if the file gets accidentally deleted? What about version control - you would need to use the full filepath? What if the end user changes a value incorrectly? and so on… Why couldn’t they just request a developer to change the value then republish? I don’t know if there’s really one right answer, and my opinion is you should allow the end user to be involved in the automated processes to take ownership.
I think if it’s a Global it should be in a config file regardless of how much it changes. And, yeah, Assets I would only use if it’s a value that multiple jobs need to communicate to each other.
I would avoid creating projects that need to communicate to each other though, and rather keep projects as single jobs. If a project contains multiple jobs in Orchestrator, it becomes unorganized and a mess, in my opinion.
A use-case for Assets, which I’m using right now, is that we have an application where you can only log in 1 user account at one time, so if another robot uses that user account it will kick off the other robot that’s using it, and we have 4 different user accounts to use with the application. So, I created something to pick a user account from the pool of user accounts by random that is not being used, and if they are all used then it will choose any but will go into Pending State if it has tried each one too many times. I am using an Asset to store which Asset Credentials are being used as a list (ie “asset1;asset2;asset3”). In this scenario, 4 robots will start using each user account from the list of user accounts, then the 5th one will see that they are all being used and eventually end up in Pending state until one is available to use.
But, I think it’s open for various ideas like that.
sorry, was typing for like an hour cause I was helping my associate with a project.
so those are my thoughts. I don’t really enjoy using Assets for simply storing “Globals”, but I think they do have a use for multiple Robot utilization.
Thanks Clayton, that’s a nice, comprehensive answer.
It’s definitely a subjective subject, but it’s useful to get the opinions of those with more experience than myself. I appreciate the benefit of your experience
In your experience, how have you handled values which shift between environments (Dev/Test/Prod)? Is it just a case of having to update them in the config file as the last action before publishing?
That’s a good question. At the moment, I just kind of change all the values in the config that need to be changed, mainly filepaths to the prod filepaths. There has to be a better way though, but I just haven’t taken the time to explore the better options.
This is why we have an asset to define the filepath of the config. We have seperate dev, test, prod configs. We store the prod config on a shared network drive
I have projects that do use .json configs and I like it; I even have an InitSettings workflow that translates it to a dictionary. However, I moved away from it, because I have found that Excel is a more organized and more user-friendly platform for everyone (end users, non-programmer RPA developers). It allows you to easily see a description of each parameter and you can even have a column for what value type is expected (ie Int or Str, etc). It mostly shines when you have an InitSettings that creates a 2-dimensional dictionary and automatically uses the Sheet name as the first key. Therefore, you can organize 100s of parameters into sheets and not need to change coding project to project since the InitSettings dynamically stores all the values.
I like your concept of having a Dev, UAT, and PROD configs. But, how do you manage it in a way where you don’t have to change parameters in all 3 files when something changes? Like what if you need to change a simple timeout property… now, you need to change it in all 3. Also, documentation is always challenging, but I suppose you could just create documentation for all 3 as 1 file with no issues. I feel like, though, it would be more useful if the Dev, UAT, and PROD settings were all in the same file where the key can be changed.
Let’s suppose you have 2 filenames, one with the key as “TEST_FilenameResults” and “PROD_FilenameResults”. Then, in your project, you could simply use a variable called env where you can store “TEST” or “PROD”. And, when you use the dictionary, you would use the variable in the key, like Config("Settings")(env+"_FilenameResults").ToString.Trim
Cool thinking. I guess it kind of depends on how you have built your RPA project/infrastructure. My thinking would be that I would try to avoid where I have different Config files where one has to be used a certain way compared to another one, and if you use the wrong one it doesn’t work, if that makes sense. In our infrastructure, we are utilizing Azure DevOps to Deploy and manage version control; we should be developing from versions that are uploaded into Azure, so we aren’t working on old versions. Therefore, we don’t have copies of the files (except for backups), but we can change the version number used.
I guess there’s just different ways to think about it.
I don’t really store any values in the Assets, except for Credentials. I believe you need some form of encryption for certain Credentails (maybe not for many web portals, though). So I wouldn’t say the benefit of Orchestrator are assets. But, if you are deploying for an entire department where you will have more processes than one machine/user can handle, then some Management tool (even if it’s not Orchestrator) is worth it. If the client is only going to own/manage their individual set of processes and run them on their own dedicated machine, then you can probably get away without Orchestrator.
So, I guess that part depends on how much you want to automate, how the processes will be managed (ie by IT, internal Devs, or by owner of process) or attended vs unattended, and how you want to get analytics on the job results.
How do you do development/testing on an existing project in production if the dev/test/prod config is all the same file?
We will oftentimes put projects in by increments (e.g. process only happy path & put into prod, then do a handful of BREs and put into production, then a few more BREs, etc.).
Or if you don’t develop incrementally, the same question applies on how you deal with bug fixes, platform upgrades, etc? Do you just not run the robot while you are fixing any bugs discovered, or added features?
We have been developing with 2 shared directories: 1 for Dev/Test and 1 for Prod. So, any time we would perform some debugging or enhancements, we would work from a copy of the files in the Dev/Test folder. Then, publish and copy them back to the Prod; therefore, having a seamless Config file where you don’t need to change many variables is beneficial. And, also, most of the time we aren’t changing the config parameters after the project has been deployed to Prod anyway, so testing has been in the final output directories; this is because it is easier and less tedious. But, like we aren’t running in some critical environment either, and if files get output incorrectly we work to fix it.
However, I don’t particularly like this model. As you can see, there is potential for error and it also requires consistent practice.
We are moving to utilizing Azure DevOps for Dev to Prod deployment. So, I’m hoping there will be some solutions with this.
I think if config files can be added with some validations or rules compatible to the process, that would be good to avoid mistakes and end user would benefit the flexibility.
If members can feedback on following things -
How are you dealing with changes in assets vs config files in terms of processes - ticket or change record or business approval?
How about the versioning of both type of configurations?
When you have multi bot environment how is the excel file behaving?
Thanks
sorry, was typing for like an hour cause I was helping my associate with a project.
Anil_G
yogitagaikwad2206
Pushpendra_kowthavarapu
Shiva_Nikhil