BPM, Workflow, and Case

BPM, Workflow, and Case

Come for answers. Stay for best practices. All we’re missing is you.

 View Only
  • 1.  Design Approach :Lock on Parallel Task IBM BPM

    Posted Fri December 25, 2020 02:51 AM

    I have a scenario where I have to put a lock on parallel tasks. So that if anyone has claimed a task. I should not allow other person to work on it.

    Scenario- I start my process and then divide then create 3 parallel task for different teams. If Team 1 has started working on a task then i would to put a lock on the task so that other teams cannot work.

    Reason- Team 1 can update some data while working. and I don't want the other team to work on old data.(If they pick the task at the same time).

    My Approach- Whenever a user claim the task. I will put a lock and store it in the Database. And whenever he completes i will release the lock.

    Problem- If a user didn't complete the task and directly closes the browser or due to power failure system shuts down. In this case I an not able to release the lock. 

    Looking for suggestions if someone has come across a similar scenario and how to handle the problem stated above.

    Thanks



    ------------------------------
    Akash Gupta
    ------------------------------


  • 2.  RE: Design Approach :Lock on Parallel Task IBM BPM

    Posted Fri December 25, 2020 05:00 PM

    I will start by saying "This way lies madness" only because you will get into increasingly annoying corner cases. Things like - Team 2 started working their task, then Team 1 decides to edit, so what happens to what Team 2 is doing? Or Team 1 started editing, but didn't finish the task. They expected their updates to be used, but they weren't because they didn't submit. 

    Before we try and solve all that, lets solve the problem you asked. I'll assume you have the lock out working already. What I would do is just modify that a bit. The lock should have, in addition to the locked state a "Last Updated" column. When Team 1 is working their task I would have a ajax call from the client every X minutes (lets say 5) that is simply updating that time window. When Team 2 tries to run the task we are checking 2 things , "Is it locked" and "How long since last update?" If it is locked but the update is out of date, you log that, unlock, and proceed, because the client must no longer be communicating with the server, so we will assume an unclean close.

    To solve more of the use cases what you really need is a version ID on the data we are working with, where the update from a given user will only be accepted if the version in the DB is the one they are editing. If it isn't then you have 2 choices - a) say "Sorry you have to redo your work" b) write a reconcile screen that preserves their changes but shows them the data that changed while they were working so that they can try and rework. The 2nd option is going to be way easier if you are discerning with your data structures and separate the data (Business Object) that Team 1 can edit from the data that Teams 2 and 3 are editing, so that it is far easier to load Team 1's update and preserve what was done by Team 2.

    Also note - you really need to write your coach so that it is using an AJAX call to populate the data on load from the source of truth. If you don't do this then the values used for the user will be the ones that existed when the task started (unless you are using Shared Business Objects). If you don't do this and the following steps happen -

    1. Team 2 opens the task but does not complete. (Postpones or closes browser)
    2. Team 1 opens their task, modifies data. Saves and closes.
    3. Team 2 opens up their task again and continues their work, completing the task.

    If you didn't use an AJAX service in an onload event to populate the data (or a SBO I think), the data Team 2 would see in step 3 would be the values they saw when they loaded the task the first time, even though the underlying data changed in the Source of truth.



    ------------------------------
    Andrew Paier
    ------------------------------



  • 3.  RE: Design Approach :Lock on Parallel Task IBM BPM

    Posted Sat January 02, 2021 11:22 PM
    Thanks for the quick response.
    In my case there is approx 90% of the time teams will work on different set of data. Mostly they will not be dependent on each other. But yes there will be a possibility that some cases will be there where the primary data can change. Hence wanted to cater to those specific requirement.
    I liked your suggestion of having LastUpdate column and I am planning to implement the same which will solve majority of my cases. There would still be some edge cases but I think that I would take care on case by case basis.
    Thanks again for the detailed analysis this actually helped me lot to understand more about the design.

    ------------------------------
    Akash Gupta
    ------------------------------



  • 4.  RE: Design Approach :Lock on Parallel Task IBM BPM

    Posted Tue December 29, 2020 01:17 AM

    Maybe you can try shared BO. Put the data which will be modified by three teams as shared BO. Every time a team start to work, it will retrieve the latest value of the shared BO. Will that meet your scenario?



    ------------------------------
    JING JING WEI
    ------------------------------



  • 5.  RE: Design Approach :Lock on Parallel Task IBM BPM

    Posted Sat January 02, 2021 11:14 PM
    Thanks for the response. But i guess using shared bo will be expensive for the process.

    ------------------------------
    Akash Gupta
    ------------------------------



  • 6.  RE: Design Approach :Lock on Parallel Task IBM BPM

    Posted Mon January 04, 2021 01:16 AM
    Hi Akash,

    To be honest, I don't see the reason for having to go through all these hassles. The path you're going will create unmaintainable solution that does no good in the long run. Rather, it's better to take a step back and redesign the process properly. 

    I'd recommend you to share the business problem that you're trying to solve. Try to stick with what and how the product is designed to do rather than trying to be 'too smart'. 

    Regards,
    Thong

    ------------------------------
    Thong Huynh
    Sydney NSW
    ------------------------------