Posted: 17 Jun 2018 2:45 EDT Last activity: 13 Sep 2018 10:03 EDT
Pega OOTB Edit in Review mode causes Internal Assignment problems
I am using Pega 7.2. I am facing a problem with the internal assignment. Opening an optimistic locking case, in review harness, users open a flow action "pyUpdateCaseDetails" run on top of the case's internal assignment. Then they refresh by the action button -> Refresh. In stead of opening the same flow action section, it opens the internal assignment section, which is expected. However, when users complete the internal assignment, and they try to do flow action "pyUpdateCaseDetails" again, the system throws an error "The assignment is no longer available". I understand that the internal assignment is gone.
My question is how to prevent users completing the internal assignment or how I can repopulate the internal assignment? The user must be able to edit cases in review mode. I think about some solutions but I want to know the best practice way:
Preventing users launch / get into the internal assignment: When they open the flow action A and click refresh, they reopen the whole work object to they will land on review harness. It works but I do not feel it is a right way.
Try a way to repopulate the internal assignment after user complete it: Before launching flow action A, running an activity to manually "Obj-Refresh-And-Lock" and calling "WorkUnlock" activity. The idea comes when I switch the case locking mechanism to default (not optimistic), when I refresh the case, I notice that after it runs "Obj-Refresh-And-Lock" step in "Work- WorkLock" activity, the internal assignment gets populated. With the optimistic lock, the case never gets to that activity so I have to manually call that steps. Calling WorkUnlock to release the key since it can not lock the case.
Manually repopulate the internal assignment: I am looking for an activity or any Pega Java API can repopulate the internal flow. Then I can call it when users reopen the flow action A. This solution will be better than the second solution but I can not find any activity or Pega Java API.
I attach the screenshot to reproduce the error. Everything is OOTB Pega 7.2.1. I appreciate any help you provide,
***Updated by moderator: Lochan to update platform capability***
I tried following the steps outlined in your screenshots in my 7.2.2 system. Is that the same version you're using?
While I can see the same sequence of events (specifically, the stage sla flow action after the refresh), when I click the edit button the second time it brings me back to the pyUpdateCaseDetails flow action. Here are a few things I would suggest checking:
-Are you using a custom or OOTB portal? If you're using a custom portal, check if the issue occurs using the OOTB Case Manager 7 portal.
-Try tracing the submit to see what is removing the internal assignment.
-Check to see if the issue happens if you don't perform the refresh action before the submit. If it doesn't, trace the refresh to see what it's doing.
Thanks for your response. I just wonder if you set your case to optimistic locking? The default locking does not give this error.
-I am using Pega 7.2.1. Everything is OOTB.
-After submitting the internal assignment, the flow is gone. When I click edit, that flow is not populated back. So the system throws exception since the "edit" flow action needs to run on the internal assignment.
-When I refresh it, as an expected behaviour of Pega, it will refresh the current view and show the assignment which the flow action runs on. In this case, it is the internal assignment.
My apologies, I completely missed the mention about optimistic locking in your original post (not to mention your version info). I can see the same behavior when I test with optimistic locking enabled.
Can you elaborate on the need for the refresh in this scenario?
The problem with refreshing case is after refreshing, users get into the internal assignments. If users complete the internal assignments, the cases are broken (missing internalcaseflow). I want to solve this issue (missing internal assignment) and still allow users to edit cases in the review harness.
It seems to me like the refresh should bring you back to the same flow action, even if it's in the context of the edit action, rather than bring you to an internal assignment. You may want to enter an SR to have that looked into.
About refreshing flow action behaviour, the problem is not about internal assignments. Based on normal assignments, when users refresh the page while performing flow actions, the system also brings back the assignment page. It is Pega OOTB behaviour.
When you first open the item, do you have a NewAssign page? I assume yes, and that it contains the "internal assignment" that your users ultimately process. I also assume that the "The assignment is no longer available" error references that assignment. If those assumptions are correct, my guess is that you need to update that page to have the correct assignment after the first one is processed, but before the user calls pyUpdateCaseDetails for the second time. This also expects that the item is open and there is a valid assignment in the database that you could load into that page. If the item is resolved and the pyWorkPage.pxFlow page is empty, then you will never be able to have a valid assignment without getting it reopened and back into a flow.
I just want to clarify something. I assume the mentioned "item" is the work object. When I first open the work object, the "newAssignPage" page is not populated. It only gets populated when I open the flow action which run on the internal assignment.
Also, the problem is not about invalid assignment. The internal assignments do not store in the database. It is referenced as a pyWorkPage.pxFlow(pzInternalCaseFlow). When users completed the internal assignment, the flow got removed. So after completing the internal assignment, they cannot rerun the flow action again because the flow is gone.
Moreover, all related internal assignment rules are blocked by Pega. Also, this is an OOTB behaviour. So I hope someone have the same problem and there is a solution from Pega Community. All of the best we can do right now is hiding the submit button so users are not able to complete it.
There are several things about this scenario that disturb me. One is that although you are in a Review harness, you state that "user must be able to edit cases in review mode". So you have already abandoned best practices.
Then you use optimistic locking. I looked it up, and one meaning of "optimistic" is "hopeful and confident about the future". The problem with being optimistic is that sometimes you're wrong.
Between these two facets of the problem, I think that whatever you eventually build will not be stable, and may break on its own, or sometime down the road as other subtle features of the architecture (your own or Pega's) change. Just looking at some of the suggestions that have already been made to help you implement this only reinforce my opinion.
Can you disable optimistic locking temporarily if that seems to push you back onto a better path?
Thank you for your response but I am looking for constructive responses.
I said "I attach the screenshot to reproduce the error. Everything is OOTB Pega 7.2.1.". I have not created or edited any activity. All I have done are creating a case type, switching to "Optimistic Locking". Based on those configuration, I am able to edit the case in the review mode but there is an error. I do not know that it is "abandoned best practices".
About the "Optimistic", I have copied this from Pega Help:
An action taken on case — Allows multiple users to work on a case at the same time.
This optimistic strategy allows the first user to submit the case to succeed. All other users who are working on the case are notified and must review the changes before they can submit their own updates.
It is not the definition you wrote. Moreover, please focus on the problem, do not focus on me. It is "ad hominem".
I appreciate your last point. It is the business requirement. I have already suggested the option to switch back to default locking strategy. However, I also want more help from the community for technical solution for that business requirement.