Multiple Bots Writing To Single Text File

[PJNI]

Hi 

Is it possible to Append To Text File to write exception cases by multiple bots to a single text file?  This text file is on a shared drive location for the multiple bots to access.

I am getting an append error when the other bot tries to write to this file (the bot that has created the file on the shared drive is able to write to the text file without issues). 

I have created a lock etc, but still getting the append error.

This text file will be used as an input file for manual completion.

Thanks

Using v6.10

[david.l.morris]

Yes, the standard way to do this is to use environment locks so that they wait for each other.

If they tried to concurrently access, it would look like this:
1 - Session A acquires the lock
2 - Session B waits for the lock
3 - Session A writes to the file
4 - Session A releases the lock
5 - Session B acquires the lock
6 - Session B writes to the file
7 - Session B releases the lock

Check for the internal business object "Environment Locking". You'll use the actions Acquire Lock and Release Lock. You don't usually need Query Lock.

You'll want to play around with it to understand how it works and test different scenarios. There's also probably training on the Blue Prism University, and there are YouTube videos about it.

Also note that you can view current Environment Locks in the BP UI in System tab > Workflow > Environment Locks. So, you could do Acquire Lock as a quick test and then go view it in that screen.

[naveed_raza]

you can save text file with bot name like bot1.txt, bot2.txt, and at last you can add environment lock so that you can collate all the individual text files into one (probably different process or add logic to check nothing is in pending or lock item , if any then loop it until all cases cleared , you can add this logic after acquiring lock). 
this will make sure everything is collected properly.

[greggoodrem]

Hello from reading between the lines it looks like you have created a reporting process with a txt file. My recommendation is different and an alternative to solutions provided by Dave and Naveed. Also its a bit progressive:

Solution 1) I would recommend also building a separate process that can work for all your automations using the queue data to populate an excel for the process and have different rules for different worksheets. So you could have a worksheet that just populates with the completed information and include any of the item data you wish, a business exceptions worksheet with all those exceptions and then a tab with the system exceptions. (We use to forward this onto the departments or save to a location that we did the work for which seemed fairly useful for them to pick up any manual processing due to business exceptions). Your situation you may want to just add one worksheet daily to your excel.

Solution 2) Stand up a SQL database in your environment and on the daily update with the results of your processes in a similar way to solution one and then you can extract the information into things like Power BI and have a bit of fanciness to it.

Solution 3) Which is my preference as it is real time reporting! Use the SQL database and update every transaction into the relevant tables for whichever automation you are running. Then use this data in a Power Bi dashboard or build a frontend personalised website dashboard that teams can access(This webpage too could be locally hosted). Ultimately on this option the possibilities are endless however can go a long way to showing the benefit that RPA brings to the organisation when you are showing the cost of operating RPA is outpaced by the x10 savings you are producing through your automations.

[RaVi_APA]

You can write the exception to the Work Queue itself, so you don't have to deal with file locking issues.

The bots will write to the queue. A consolidator process at the end will read these queue items and write it to a text file (since you need a text file).

While doing this mark the queue status as Completed so that they don't get picked up again.