I am curious to know if anyone has tried contents of config file directly from an asset instead of reading contents from Config.json or Config.xlsx file.
I am looking to gather inputs from UiPath community on this before I go ahead with trying this approach.
Is it worth going for this?
Does it offer any more benefit than what Json file usage already offers? I know using Json file does offer few good reasons of its usage over Config.xlsx file.
I have used an approach of reading contents of Json(small input file though) directly from an asset instead of storing it in storage bucket and then reading Json from there. But is it worthwhile to put an effort to read Config(its a big file and may contain different sections) from asset?
You can maintain a json…but think of it like this…if such a big json is given in the value field of asset how difficult it would be to change values if needed…we have to copy and make changes and copy back
When there is some organizational change on the asset naming conventions or so…as noe assets are directly used in process we need to change every where in process rather than in one file where assets are stored atleast for the config assets
Storage bucket offers you both the file flexibility and also can do edits as needed
Yes, that can be a disadvantage of using config file in an asset as its a huge file.
Plus, as you mentioned, everytime there is an addition/deletion in the Config file structure, it would not only require a change in an asset but in the code where we are reading contents from asset and creating datatables/dictionaries from there as it would involve reating regex expressions to read the data that makes sense.
But I was wondering if there is any other approach/activity to parse data from asset like we have from Json file(deserializing json text) etc. Just a thought.
We are currently using this Json approach to ensure we don’t have to republish the project to production everytime if a change is required just in Config file.
We have created a storage bucket on orchestrator
Saved the config.Json file in there
Reading the config file text from storage bucket
Deserializing Json text
5)Then creating Config dictionaries
And this approach is really going well, however recently came across an idea of having it in asset, thus wanted to gather community inputs on this.
It would cause a bunch of unnecessary complexity and hoops to jump through. You can’t store complex data in an Asset. You’d have to store it in JSON, parse the JSON, make sure you don’t foul up the JSON when you try to edit the asset.
Assets are used where you have details that would not effect your logic or code but only changes the value for an underlying data
Config is used where your code is in a way linked or tied to it…example column names in excel,where it stars,what are the exception youa re raising…which directly might effect the code
If we have this bifurcation then we can use both hand in hand
And yes json gives a better way to ahndle…but havinng all the details in json is also not in a way good…because think from the support persons perspective he would be maintaining hundreds or bots and changes need to happen in configs very frequently is difficult…that is where we use asset which is much easier to maintain and faster
How easy is it to edit the config file currently (I have no experience using storage buckets)? In my processes, I currently store a config json in asset(s). Editing it requires copying the asset text to a text editor and pasteing back after the changes, but it’s manageable.
We have found a solution to this. As we are already using Config.Json from storage bucket, we now enabled a switch which will now let us have an ability to either read config from asset or from storage bucket as needed.
We didn’t have to make any changes to the part where we deserialize Json text and filter it further into different dictionaries/datatables.
Only the first part was changed where we can now read from an asset as well.
Few scenarios in which I see reading from an asset would come handy:
During development, we would not have to go to storage bucket, delete, upload Config.Json multiple times(while it is still in prep phase).
We can directly copy paste changed config data into asset and do the test.
Now once development is completed, it is again a choice if we wanna read that from asset or Storage bucket. I would prefer to read from Storage bucket as once development is complete, there would be no frequent changes required to the config so storage bucket would be a better option.
Another benefit that storage bucket already offers still remains the same even while using an asset. Benefit - Post promotion to production, whenever any change is required in config, we don’t have to go through the deployment process again, we can simply change the file in storage bucket(obviously with following a routine of doing any change to production processes). Plus it also removes the possibility of error that we often used to face where Config file is opened/corrupt which used to lead to failure of processes.