Question
Last activity: 19 Oct 2015 7:59 EDT
Unable to open assignee's Data-Admin-Operator-ID record System.
Hi ,
The following exception is being occurred in logs .
( internal.mgmt.Executable) ERROR - Exception;com.pega.pegarules.pub.PRAppRuntimeException: The flow customerinfo had a problem on step Assignment1 of: Unable to open assignee's Data-Admin-Operator-ID record System.
I understood the trigger point of the exception is like when agent is trying to create an assignment ,and route it to "Current Operator". Hence we've overwritten the Data-Party.CurrentOperator Data transform by updating the source value for pyWorkPartyUri as @if(@isBatchRequestor(tools), "[email protected]", pxRequestor.pyUserIdentifier).,but still issue is persist.
Please let me know if anybody have idea on this.
PRPC version:7.1.6
Thanks,
Brahmesh.
Pegasystems Inc.
IN
the error is expected with Agent in combination of assignment configured with Current Operator. would it make sense to route to a workbasket?
Nope, we can't route it to work basket,as same assignment can be created by user as well. Below is the implementation around .
In our flow, we kept an assignment with SLA for auto submit action,so once deadline is breached ,immediately auto submit action gets processed automatically, and then SLA agent is trying to creating further assignment which is causing the exception.
or
user can process the Autosumbit assignment (if SLA not breached) and then create the further assignment .
Pegasystems Inc.
IN
would it make sense to configure a custom route activity checking if the assignment is processed by agent or back officer assigning the step appropriately?
When the condition is satisfied Param.AssignTo will be workbasket otherwise it will be current operator.
Yes Phani..The when rule would help .
we made the same logic in Data-Party.CurrentOperator Data transform as mentioned below ,but still issue is persist.Any idea ?
pyWorkPartyUri = @if(@isBatchRequestor(tools), "[email protected]", pxRequestor.pyUserIdentifier).
Pegasystems Inc.
IN
>>> pyWorkPartyUri = @if(@isBatchRequestor(tools), "[email protected]", pxRequestor.pyUserIdentifier).
not sure on the above line of code. when it is agent user identifier will be system.
but again, if not wrong - either a custom route activity or a decision shape with two assignments (one leading to workbasket and the other to work list) should help.
Please share your thoughts, Thank you!
psahukaru
Yes Phani.. I can keep either decision shape or custom route activity .but application has many flows,which are having many assignments,hence efforts would be increased .
what would be the reference for "Current Operator" routing? Is it being referred from pxRequestor page (or ) owner work party details?.
Updated: 16 Oct 2015 16:18 EDT
Pegasystems Inc.
IN
As mentioned this is expected behavior if any agent (ex. SLA) tries to move/resume the flow and next assignment is routed to current operator.
You can overcome this situation from below steps
- Use Custom router activity ToCurrentOperator instead of "Current Operator" routing option
- Customize this activity in your application to check for pxRequestor.pyUserIdentifier
- If "System" route to admin@YourOrg
You can also create a new routing activity instead of specializing ToCurrentOperator in your application. Let us know if this helps
Thanks Pankaj,
we can keep custom routing activity to avoid this issue,but I just want to understand problem with "Current Operator" routing option.
In our App, Route To is configured as "Current Operator" for most of the assignments.