Data Item to store and update variables across sessions

[ManishRaw]

Is there a way in which we can store and update the Data Items present in BP across sessions? its more like an environment variable but to which we can make updates too.

This will help us in storing variables across sessions like flags, data which requires the value from the other session run that currently has to be stored in externally like in excel, notepads, etc.

------------------------------
Manish Rawat
Project Manager
Mercer
New Delhi
------------------------------

[sumire]

Hello Manish,

I'm not very technical, so the two things I can think of are:

• stored in externally like in excel, text file, etc.
• stored in queue

------------------------------
Mitsuko
Asia/Tokyo
------------------------------

[ritansh.jatwani]

Hi Manish,

In order to make changes to the variables across different sessions, you need to define those variables as "Session Variables". The session variables can be updated during the runtime of the processes for different sessions. You can view the option of making the variables as "Session variables" by setting the exposure of the variable as "Session".

Hope it answers your query !!

------------------------------
Ritansh Jatwani
Consultant
EY
Gurgaon
------------------------------

[ManishRaw]

Hi Ritansh,

"Session variables" will work only till the session is active and is mainly used for controllers to make updates on the fly. For example if we define end time as session variable it can be changed by the controller while the process is running, Also they cannot be shared across sessions but are specific to each session run per BOT.

Here the Idea is to have a variable that stores its value even after the session of first BOT got over. Just as a simple example, steps below:

1. Flag variable Login required was set as "true", now BOT1 checks the status is "true" during its run and then, does the login task and then other tasks and then sets this value to "false".

2. BOT2 checks the status is now "false, so it skips the login task and does the other task only.

And the application could be many more. Its more like of creating a variable in BluePrism database which is shared(both read and write) by all the BOTs running the process in scope. 

------------------------------
Manish Rawat
Project Manager
Mercer
New Delhi
------------------------------

[ManishRaw]

Hi Mitsuko,

You are correct about the two approaches, they are infact the ones that we follow as of now but they have their implications:

1. Storing in excel file, text file etc - Its not implicit to blue prism and needs to be stored at a shared drive location which will be accessible to bot, so the chances of failure increases and environmental locking needs to be applied explicitly.

2. Storing in work queue - Unique item key needs to be created, and every time a BOT has to access that even if that's for reading purpose they have to get next item for the details, which will have their delays in case of Multi-BOT scenarios.

The data item exposure I am talking about gives us the advantage of the two exposure already present:

1. Environment - Read access to all BOTs but no write access, value persistent in BP after run

2. Statistic - Write access to all BOTs but no read access, value persistent in BP after run.

So if we can have a exposure mode which has the below capabilities:

Read and Write access to all BOTs and value present in BP after BOT run.

Another thing to notice is that we need to have an explicit action in order if anyone/any BOT wants to delete that variable when it is not needed so that it won't be using the BP database space.

------------------------------
Manish Rawat
Project Manager
Mercer
New Delhi
------------------------------

[robert.nicklin]

Hi Manish,

Your thread makes for an interesting read, thanks for posting it! A few things from me:

1. I did wonder whether Environment Locks could in some way help resolve your issue, as other resources can actively query whether a lock exists. In your example, BOT1 could obtain an environment lock called "SYSTEM X LOGGED IN" after which other robots (such as BOT2) would find that lock is already held by another process when they query it, implying that the target system was already logged in by another process. This is quite a limited feedback function and is far from ideal for a few reasons (i.e. the lock would be released when the session running on BOT1 ended / if the session running on BOT1 terminated the lock would be orphaned) but it hadn't been mentioned above so I thought it may be worth throwing into the mix.
2. From Blue Prism 6.7 onwards there is now an action in the Work Queues VBO called "Get Item by ID" - this allows a process or object to get a work item from a queue by specifying an ID vs. using tag filters along with the "Get Next Item" action. I wonder if this may mitigate some of the performance concerns that you have when working in a multiple robot scenario as in the second option listed above? I imagine there would still be a delay as BOT1 gets the item, signs into the system and posts an update to the item's data, but I imagine some sort of delay may already exist when writing this information into a file into a shared location anyway?

Finally I had a question for you about this as a potential feature.

Imagining a world where this new feature/capability existed, could this not introduce complexity in troubleshooting if the behaviour of a given process is altered by other processes that may be running simultaneously? If several robots can alter a "shared variable" at any time couldn't it become quite difficult to track down which robot had set a shared value incorrectly and why? Obviously a good audit would help mitigate this, but I wondered if you had any thoughts on what impact this could have on troubleshooting in general.

Hope the additional information helps!

Regards,

Rob

------------------------------
Robert Nicklin
Senior Product Owner
Blue Prism
Warrington, England
------------------------------

[david.l.morris]

Just wanted to toss in my two cents on using Environment Locks to share bits of info across concurrent or non-concurrent sessions. I have done this before in earlier versions of Blue Prism, and it works fine. However, and I don't know when this changed exactly, at least as of 6.10, Environment Locks appear to get automatically deleted rather than just unlocked after they're released. I don't know if this is intended or not, but it would break any automation that expects Environment Locks to persist.

I used to suggest either Work Queues or Environment Locks for this kind of simple info hand off, but now I'd only suggest using Work Queues. Could also use a file with the info inside it along with using Environment Locks on that file, but I imagine it'd be less efficient than Work Queues.

------------------------------
Dave Morris
Cano Ai
Atlanta, GA
------------------------------

[HarshitRawat]

I agree with Robert's last point

Imagine 5-6  processes which are  running and updating that shared variable.  Even if 1 process updates that variable at the wrong time it has potential to break other automations and would be a pain to troubleshoot and fix.
 i believe env locks should be sufficient enough for the use case

------------------------------
Harshit Rawat
------------------------------

[robert.nicklin]

Hi Dave,

The change in behaviour you've seen was an intentional change made in Blue Prism 6.5 under reference US-3540, the release note for which reads:

The Keep Environment Lock parameter has been added to the Release Lock action of [the Environment Locking] VBO. By default, the parameter is set to false so that locks are deleted when released. If this parameter is set to true, released environment locks are not deleted. The parameter only affects locks created during the current session - environment locks are not deleted when they are released.

So existing processes would automatically delete environment locks on release from 6.5 onwards unless the process was updated to say this shouldn't be the case. This was done to mitigate the performance impact seen by some customers who were using environment locks heavily and seeing a backlog of locks build up without them realising this was the case.

Hope this helps!

Regards,
Rob

------------------------------
Robert Nicklin
Senior Product Owner
Blue Prism
Warrington, England
------------------------------

[ManishRaw]

Hi Robert,

Thanks for the response. Please find my comments below: 

1. Environment locks will only work during the session runs as you correctly mentioned.
2. "Get Item by ID" can be used as a work-around, but then it has a few limitations:
1. We have to lock the item every time we need to access the data (even for reading purpose)
2. The Queue has to be shared across BOTs and processes/ We have to create a separate queue for specially this purpose.
3. The overheads will be there as correctly mentioned by you (The same are there in current situation of storing it out of BP)

Actually, It is more about the feature of having sharing variables across sessions and BOTs even after the session has been stopped.

The scenario mentioned earlier was more or less about setting a flag, but the same can be easily extended to reading and storing other type of data Items according to scenarios, just a few as I can thought of:

1. Text: Storing the name of the VDI/BOT which has run a process once, so that the same present in the list will not run it again.  
2. Date: Last date of run/update and taking decision according to that and updating the same after latest run.

We can also think it as a output of one BOT which will become input to other BOTs running in sequential manner or in concurrent manner with the proper usage of environment locking.

I agree to the point that if we have a "shared variable" then there could be challenges in troubleshooting if proper coding standards are not followed as per its functionality.

But that is applicable to any type of "shared data".

Consider the current situation where in case we want to store some data that should accessible across sessions or can become output of another process, we have to store it on the shared drive in an excel, notepad, SharePoint etc. There also we have to apply proper environment locking before making updates.

We have to apply the same concept while making updates to the "shared variable", but the advantage here will be that the data will be stored in Blue Prism only, which can be accessed directly by BOTs without the overhead/failure/latency of using a shared drive and other applications like excel, notepad.

More importantly we have to have a feature to delete such kind of variable/empty memory explicitly through BP action in process or by controller once we know that it is no longer needed to make sure BP database optimization.

Hope this would be helpful.

I had submitted the idea regarding the same too:

https://community.blueprism.com//viewidea/?IdeationKey=c1f9b554-73c0-4091-a18e-fe0b2c28afad

------------------------------
Manish Rawat
Project Manager
Mercer
New Delhi
------------------------------