Blue Prism 6.9/6.10 issue: Tagging in a business object

[StefanFriele]

Hallo all,

we have a business object that can write and delete tags for an item where the process that calls this object has locked this item by Get Next Item. This worked fine with Blue Prism 6.6. Since the upgrade to 6.9 (and still in 6.10), we get an internal error "This work queue item is locked by another process."

When we call the actions for manipulating the tags (e. g. Work Queues – Tag Item) directly in the process, everything works fine. Also, if we do the Get Next Item within the object, which is obviously not an option. However, we use the object within many processes, and eliminating it would generate very high effort. Searching the release notes yielded no result. Any ideas how to deal with this breaking change?

Thanks

Stefan

------------------------------
Stefan Friele
RPA Developer
ERGO Group AG
Europe/Berlin
------------------------------

[robert.nicklin]

Hello Stefan,

I believe the change in behaviour that you are seeing is a result of BG-4494 which was applied in Blue Prism 6.8. The release note for this change reads as follows:

If an Action stage attempts to add or remove work queue item tags for a queue that is currently locked by another process, the action is now prevented and an exception occurs. Previously, Action stages were not prevented from adding item tags to locked work queue items.

I find this an interesting use case, as it's not one I've come across before. Would it be possible to provide me with a little more context as to why your business object has a requirement to add or remove tags from an item that is being actively worked by another process? Does the tag that is added (or removed) somehow result in a change in the possible outcomes of the process that is actively working the item?

Regards,
Rob

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

[StefanFriele]

Hallo Rob,

Thanks for your quick answer. We have a business object "Tag Helper" which takes care of things like the maximum tag length (255 chars) and removes the semicolons. It also has some functionality for replacing a tag "key: value" with a tag "key: othervalue". All of these actions get the Item ID as input param.

Just for clarification: The process that calls the Tag Helper actions has locked the work item from the queue via Get Next Item, so there is no other process involved. It is just that the process owning the item delegates the tagging stuff to the Tag Helper. This is also the reason why we did not bring the release note you mentioned in context with our problem.

I can understand that you should not work on an work item within two processes in parallel, but delegating some of the tagging stuff to a business object still sounds quite handy for me - and in fact was until the upgrade of the BP version 😉 Do you have any ideas of how to work around this issue?

Thanks again for your help!

Regards,

Stefan

------------------------------
Stefan Friele
RPA Developer
ERGO Group AG
Europe/Berlin
------------------------------

[robert.nicklin · Accepted solution]

Hi Stefan,

The objective of this change, from what I understood, was to stop a second process amending an item that was being worked by a process, which could inadvertently change the behaviour of the process working the item because of the presence of a tag that wasn't there (or likewise a tag that was there) when the item was "got" from the queue.

If we're talking about only one process in this example which uses an action stage to call on the "Tag Helper" business object I wouldn't have expected to see this error message, as the session ID associated with the case lock on the work queue item should be the same as the session ID that the business object would also be running under.

Unfortunately without more information I don't think I'd be able to help progress this much more and I don't think sharing more details about your process and object on this forum would be the right way to go. As this is unexpected behaviour I think it would be best to raise a support ticket so a member of the support team can take a look over your process and object in more detail and investigate this further.

Regards,
Rob

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

[StefanFriele]

Hi Rob,

Thanks again for your help. We have created a ticket and keep our fingers crossed 🙂

Have a nice day,

Stefan

------------------------------
Stefan Friele
RPA Developer
ERGO Group AG
Europe/Berlin
------------------------------

[MartinaKrausova]

Hello Stefan,

can you please share the result of the ticket you have raised. We face the same issue as you have described above.

I made an object for removing all tags on queue item (which is locked in process by Get Next Item action) and it doesn't work in 6.10 with the same error: "This work queue item is locked by another process."

Thanks a lot

------------------------------
Martina Krausova
Robotic & Process Analyst
------------------------------

[StefanFriele]

Hi Martina

BluePrism has confirmed this to be a bug "to be fixed in a future release of Blue Prism via BG-276". So hopefully in one of the next release notes there will be a note that BG-276 is fixed. Until then, the only solution we have found is to duplicate the code from the business object and call it directly within the process 😞

Hope this helps you,

Stefan

------------------------------
Stefan Friele
RPA Developer
ERGO Group AG
Europe/Berlin
------------------------------

[MartinaKrausova]

Hi,

I suggested the same temporarily solution (put the code from object directly to the process) as you.

Thanks a lot for your answer - hope it will be fixed in some future release.


------------------------------
Martina Krausova
Robotic & Process Analyst
------------------------------

[JamesWoods1]

Just wanted to add another use case that seems to have been missed. I have an item locked in a main process but I'm trying to tag an item in a sub process. Moving the tag action out of the sub-process and into the main process doesn't make sense in this case and I'm sure many others.

------------------------------
James Woods
Automation
CUNA Mutual
America/Chicago
------------------------------