How do you setup different flows on the same WO (different Operators)?
We have requirement where we want to run two different flows on same work item at same time with two different operators. How can we achieve this functionality.And both user should be able to perform their work at same time.
Message was edited by: Kip Jackson Modified the Title and discussion contents.
***Updated by moderator: Lochan to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Wells Fargo
US
Hi Arpit,
From the question i understand that your concern is regarding locking issue (in other case we can use spin off to work simultaneously by multiple users.).
Regarding locking, (which version you are using) from Pega 7 version if you are using case type design then use optimistic locking, which locks when it is required and notifies the other user if working on the same task that a update has been done.
Hopefully this helps!!
Thanks,
Vamshi
Pegasystems Inc.
IN
Hi,
As Vamshi mentioned earlier, you can spin off new assignments and work on that . Refer : https://community.pega.com/sites/default/files/help_v62/procomhelpmain.htm off
Else you can try implementing cover child relationship where in one parent item can have multiple child items and they can be worked upon by different operators simultaneously. Refer : https://community.pega.com/sites/default/files/help_v62/procomhelpmain.htm
Pegasystems Inc.
US
Arpit,
Short of doing some trick like spinning off separate objects instead of working on the same one, you are always going to run into locking issues. Locking is important to ensure data integrity. You don't want two operators pulling the same work object from the database, making changes and then writing those changes back to the database since one of them will overwrite the other. If they are working on separate pages or something, you're probably better off creating different data objects so that you are free to have simultaneity. There are certainly hacks you could do with 6.2sp1 that would let you get around much of the OOTB locking limitations, but you'd be treading into extremely dangerous territory and I would not recommend going down that path.
Thanks,
Mike
Pegasystems Inc.
IN
As Mike suggested, you need to treat both flows as separate sub cases to achieve this. I would not suggest trying any other work around for this problem.
Even with Optimistic locking(7.1 onward), you get ability to open two assignments on same work object at same time but we still ensure data integrity by prompting to refresh the WO data for later submitted assignment.
Pegasystems
US
In order to answer the original question, we need to know what you mean by "work simultaneously". Here's a more specific example.
Let's say the work object contains these properties, and both user1 and user2 start with this in-memory copy of the work object:
NextCustomer: IBM
OnCallPerson: Bob
Suppose user1 updates NextCustomer to Pega. Now user1's the in-memory work object looks like this:
NextCustomer: Pega
OnCallPerson: Bob
While that is going on, user2 updates the OnCallPerson to Judy, so his in-memory work object looks like this:
NextCustomer: IBM
OnCallPerson: Judy
When a user clicks SUBMIT, let's assume that's when the updated work object is written to the db. Let's suppose user1 clicks SUBMIT first. So this gets written to the db:
NextCustomer: Pega
OnCallPerson: Bob
Let's suppose user2 actually clicked SUBMIT almost at the same time but 1 millisecond later. This gets written to the db:
NextCustomer: IBM
OnCallPerson: Judy
User1 will not be happy and will say "hey, I changed the NextCustomer to Pega and it still says IBM !"
In order to answer the original question, we need to know what you mean by "work simultaneously". Here's a more specific example.
Let's say the work object contains these properties, and both user1 and user2 start with this in-memory copy of the work object:
NextCustomer: IBM
OnCallPerson: Bob
Suppose user1 updates NextCustomer to Pega. Now user1's the in-memory work object looks like this:
NextCustomer: Pega
OnCallPerson: Bob
While that is going on, user2 updates the OnCallPerson to Judy, so his in-memory work object looks like this:
NextCustomer: IBM
OnCallPerson: Judy
When a user clicks SUBMIT, let's assume that's when the updated work object is written to the db. Let's suppose user1 clicks SUBMIT first. So this gets written to the db:
NextCustomer: Pega
OnCallPerson: Bob
Let's suppose user2 actually clicked SUBMIT almost at the same time but 1 millisecond later. This gets written to the db:
NextCustomer: IBM
OnCallPerson: Judy
User1 will not be happy and will say "hey, I changed the NextCustomer to Pega and it still says IBM !"
Depending on how you want this to work, I can think of some ways to implement it, and I think google's shared documents may be an example worth studying. What might work is to have each property represented by a lockable object, and avoid the entire concept of SUBMIT ! Instead, as soon as user1 updates NextCustomer to Pega, BOTH users would see the NextCustomer of IBM replaced with Pega on their screen, and then when user updates OnCallPerson to Judy, BOTH users would immediately see that shown on their screen.
Homework: With the above avoid-SUBMIT design, what do you do if both users simultaneously change NextCustomer to DIFFERENT values ? (You might try a google shared doc, and see what happens in that case)
/Eric
The easiest way around this is to reduce the submission of a transaction to its delta and not its entirety. When User1 submits their assignment, only the changed properties (i.e. NextCustomer, pxUpdateDateTime...) would be written to the database. When User2 submits their assignment, only OnCallPerson would be written to the database. Even then, it's an enormous engineering undertaking, and introduces far more problems than solutions. If there is some rule that says Judy shall never be specified as the on call person when the next customer is Pega, then where do we prevent this condition?
If we want something more like real time, on-screen live editing like Google Docs... that's an entirely different conversation. There are a few open source projects that have tried to tackle this problem with varying degrees of success, although they mostly focus on single-document, free-form editing. One of my favorites is Etherpad Lite.