15-05-24 06:29 PM
Hi - I want to store some values from previous automation run so that I can use them as a starting point for the next automation run. Is it a better option to create a csv/json file to store those values or can those values be stored anywhere in BluePrism DB? Is it a good approach to create a custom table within the BP DB environment and store the values there? Would that interfere with BP in anyway?
Thanks in advance!
15-05-24 07:59 PM - edited 15-05-24 08:00 PM
I think there are several good answers. I will have opted for a queue in which we will find a single item which will be constantly updated over time. Why the queue? Because the interaction is fast and because I know that no one could modify the data inside it. But you can also store it in an Excel config file or other file (the disadvantage is the interaction each time with Excel and also the possibility of modifications being made).
Best regards
15-05-24 09:22 PM
Dear @maneesh.vemula1
I would suggest to follow with the @Mohamad_747 approach.
16-05-24 09:13 AM
I also agree with Mohamad working with the queue is more secured because it is diffucult to modify data in it.
But I can see right now one limit working with the queue : when you have a lot of data stored in queues.
Indeed when you get data in queue you get first a collection of item ID and to get the data from it you have to loop to the collection of item ID and then call the action Get item Data.
So when you have a few data for example 100 or 200 item in queue it's ok to work with queue because it will fast to execute. But if you have more it might be slower.
Working with the database is easier because you need one request to get all data you need. You can for example restrict the access of the database to ensure that the data can't be modify. You can also backup you database.
17-05-24 05:24 PM
Thanks everyone for the responses. I like the idea of using work queue and understand the pros and cons like some others mentioned here. But would using a Config File (json/csv format) be a better option when considering the bigger picture and the ability to use that config file for storing various values, env variables, etc.?
What are some of the negatives of using a config file?
22-05-24 08:32 AM
Hello,
For information variable like :
- constants
- url,
- file or folder path
- credential name,
- etc,
You can stored it in a onfig file in json and csv.
According to me :
- pros : all information are stored in the same place, easy to change the information in the config file... without going to BP...
-cons : someone else can have access to the file, it can be deleted or altered by accident, you are depending of the network where the file is saved...
But all of my clients are using a config file to store general variable. So it is still a good approach to use it.
22-05-24 03:18 PM
Dear @maneesh.vemula1
Pros:
Easier Updates: You can manage all your configuration data from a single file, making updates easier and less errors.
Environment-Specific Configurations: Different configuration files can be used for different environments, enabling easy switching without altering the Blue Prism process itself.
Dynamic Changes: Configuration files can be updated without modifying the actual process, allowing for dynamic changes in behavior.
Reusable: Configuration data can be reused across multiple processes, reducing redundancy and maintenance effort.
Cons:
Errors: Errors in the configuration file (e.g., incorrect syntax) can cause the process to fail, necessitating robust error handling.
Dependencies: The process becomes dependent on the configuration file's availability and accuracy. If the file is missing or corrupted, the process may fail.
23-05-24 01:43 AM
Config file is only advisable only if you and client agree that any data used in the process will not be changed unless developer is informed. But there are instances wherein the client will update the config file without notifying you.
Pros:
Cons:
23-05-24 06:15 AM
Config is always an easy option and easy to maintain. Now a days clients are also ready to do the same.
Other way as you mentioned creating custom table in data base is an alternate option but not easy to maintain. You need further access to modify the table. Also everyone from the team can not able to alter the table as well.
23-05-24 06:02 PM - edited 23-05-24 06:19 PM
Hi @maneesh.vemula1 ,
From my perspective, I would also opt-out the queue part as Mohamad did. The reason behind it is, that you'll be relying on Blueprism infra itself and as you get individual records of data, this gets memory issues down. If you feel DB is burdened with data you can have a maintenance done once a week or fortnightly which clears the queue items which are processed.
Having a config file separately and reading it for each run has a potential danger of crashing due to memory leaks for example an Excel with large data. In addition to that, maintenance issues like files being moved or deleted might be another disadvantage. Another key point is that config files are used to store constant values not rather for dynamic updates for the parameters we use