Wait shape issue in Split-For-Each flow - Assignment getting Corrupted

General
, ,
1

Hi All,

Facing an issue with wait shape - where the assignment is getting corrupted and case does not move forward.

This issue happens when there is a wait shape in Split for each flow. Detailed scenario below:

  • When the flow is executing on pyWorkPage, there is no issue and wait shape assignment resumes automatically after specified time (eg 1 minute).

  • BUT, when the flow (having wait shape) is inside split-for-each, then flow executes on pyWorkPage.PagelistProperty(). In this scenario when wait assignment is trying to resume, it is getting corrupted.

  • Timing in wait shape is 1 minute.

  • In Tracer - I can see that assignment is getting corrupted in Pega OOTB Activity which is performFlowAction in java step which validates the assignment

  • Broken Queue Message: it just says below

  • <pxErrorList REPEATINGTYPE="PropertyList">
<rowdata REPEATINGINDEX="1">Caused by This assignment has been corrupted and processing cannot proceed.
</rowdata>
</pxErrorList>

<pxWarnings REPEATINGTYPE="PageList"/>
<pxQueueErrorDetails REPEATINGTYPE="PageList">
<rowdata REPEATINGINDEX="1">
<pxObjClass>Embed-QueueErrorDetails</pxObjClass>
<pxErrorMessage>Caused by This assignment has been corrupted and processing cannot proceed.
</pxErrorMessage>
<pxErrorDateTime>20220715T065016.449 GMT</pxErrorDateTime>
<pyAttempt>1</pyAttempt>
<pxTraceList>[]</pxTraceList>

  • Pega Log Message:

  • 2022-07-15 03:06:58,524 [ PegaRULES-Batch-4] [ STANDARD] [ ] [ WCMRisk:01.01.01] ( internal.mgmt.Executable) ERROR - Exception
com.pega.pegarules.pub.PRAppRuntimeException: Caused by This assignment has been corrupted and processing cannot proceed.

at com.pegarules.generated.activity.ra_action_resumeflow_4154b677be76e3554ae85ac7caada594.step7_circum0(ra_action_resumeflow_4154b677be76e3554ae85ac7caada594.java:647) ~[?:?]
at com.pegarules.generated.activity.ra_action_resumeflow_4154b677be76e3554ae85ac7caada594.perform(ra_action_resumeflow_4154b677be76e3554ae85ac7caada594.java:176) ~[?:?]
at com.pega.pegarules.session.internal.mgmt.Executable.doActivity(Executable.java:2722) ~[prprivate-session.jar:?]
at com.pegarules.generated.callActivity_080101_2223927609556540475.callActivity08_01_01(callActivity_080101_2223927609556540475.java:133) ~[?:?]
at com.pegarules.generated.callActivity_080101_2223927609556540475.invoke(callActivity_080101_2223927609556540475.java:80) ~[?:?]
at com.pega.pegarules.generation.internal.library.LibraryRuntime.resolveAndinvokeFunctionViaReflection(LibraryRuntime.java:230) ~[prprivate-generation.jar:?]
at com.pega.pegarules.generation.internal.library.LibraryRuntime.invokeLibraryRuntime(LibraryRuntime.java:121) ~[prprivate-generation.jar:?]
at com.pega.pegarules.session.internal.mgmt.Executable.invokeLibraryRuntime(Executable.java:9476) ~[prprivate-session.jar:?]
at com.pega.pegarules.priv.generator.LibrarySupport.resolveAndInvokeFunctionViaReflectionWithException(LibrarySupport.java:275) ~[prpublic.jar:?]
at com.pegarules.generated.activity.ra_action_executesla_464350f6cf89e0b6dd36c2aed60a7659.step19_circum0(ra_action_executesla_464350f6cf89e0b6dd36c2aed60a7659.java:2129) ~[?:?]
at com.pegarules.generated.activity.ra_action_executesla_464350f6cf89e0b6dd36c2aed60a7659.perform(ra_action_executesla_464350f6cf89e0b6dd36c2aed60a7659.java:437) ~[?:?]
at com.pega.pegarules.session.internal.mgmt.Executable.doActivity(Executable.java:2722) ~[prprivate-session.jar:?]
at com.pega.pegarules.session.internal.mgmt.Executable.invokeActivity(Executable.java:11108) ~[prprivate-session.jar:?]
at com.pegarules.generated.activity.ra_action_processevent_a0fe4cb35cf43f7f04680f577d97ebfe.step7_circum0(ra_action_processevent_a0fe4cb35cf43f7f04680f577d97ebfe.java:706) ~[?:?]
at com.pegarules.generated.activity.ra_action_processevent_a0fe4cb35cf43f7f04680f577d97ebfe.perform(ra_action_processevent_a0fe4cb35cf43f7f04680f577d97ebfe.java:201) ~[?:?]
at com.pega.pegarules.session.internal.mgmt.Executable.doActivity(Executable.java:2722) ~[prprivate-session.jar:?]
at com.pega.pegarules.session.internal.async.agent.QueueProcessor.runActivity(QueueProcessor.java:833) ~[prprivate-session.jar:?]
at com.pega.pegarules.session.internal.async.agent.QueueProcessor.execute(QueueProcessor.java:627) ~[prprivate-session.jar:?]
at com.pega.pegarules.session.internal.async.BatchRequestorTask.run(BatchRequestorTask.java:1157) ~[prprivate-session.jar:?]
at com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1382) ~[prprivate-session.jar:?]
at com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1125) ~[prprivate-session.jar:?]
at com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1006) ~[prprivate-session.jar:?]
at com.pega.pegarules.session.internal.async.BatchRequestorTask.run(BatchRequestorTask.java:817) ~[prprivate-session.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_332]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java) ~[?:1.8.0_332]
at java.lang.Thread.run(Thread.java:750) [?:1.8.0_332]

Please suggest a solution if you have faced similar issue.

NOTE: This issue is reproducible in Pega 8.3.3 & Pega 8.6.1 environment just by creating a main Flow which has split-For-Each shape and flow called in split-for-each should have a wait shape ( 1 minute time).

2

@PIYUSHSINHA

Wait shape timer can be used in case primary page context (pyWorkPage). Because when case is getting routed to wait shape an entry will be getting added in Assign-Workbasket and SLA table. And when SLA agent trying to resume the case from wait shape it will try to acquire the case lock, but in your scenario SLA agent will not be able to acquire case lock also.

In back-end Assign-Workbasket and SLA table, pega will not be able to populate needed information. pzInsKey of case will not be found in both table and proper link cannot be established between these two tables. This should be the reason assignment is getting corrupted.

3

@PIYUSHSINHA this issue is a valid Support Case and I can see that you logged this issue with our support team when you posted the question on the forum.

A quick check shows that our support team provided the following update:

". During our investigation into this problem we’ve come across this support article that gives a solution/work-around to this issue.

The following are the steps that you should follow instead of using a wait shape in the split for each.

Perform the following local-change:

  • Use the Assignment shape instead of the Wait shape.
  • Route it to [email protected] that is similar to the Wait shape so that no one can access the assignment.
  • Define a Service Level Agreement (SLA) on the assignment with the Goal as 30 minutes or as per the requirement.
  • Write an escalation activity which invokes ResumeFlow, passes the appropriate flow action and sets the Step page to pyWorkPage when invoking ResumeFlow.

https://community.pega.com/support/support-articles/wait-shape-used-split-each-flow-behaves-incorrectly"

Could you confirm whether the above work-around helped you progress?

(Note that the support ticket investigation is still ongoing as there is still talk of this being a product enhancement/ bug that needs further explanation from our SME)

Please can you keep us posted once you receive a definitive answer from our support team?

4

Hi @MarijeSchillern,

Thanks for the update. We are using few common/reusable flows which are used in multiple applications (and the reusable flow has wait shape).

At this moment we don’t want to ignore the reusable flows and create our own flow (with assignment & SLA) as it will put extra effort/maintenance in future.

Would be great if I can get a workaround which will help to use wait shape in split for each flows.

I have updated the ticket as well. Will keep this thread updated as I get more info/workaround.

Thanks!

5

@PIYUSH SINHA I have checked the support ticket and this was resolved.

I believe the support team informed you that Bug items have been created for this issue. Hopefully this answers your question here on the forum.

*** Update **********

Please see the following Support Document for the latest details about this Known Product limitation:

SLA failures in Split-for-Each flow due to assignments incorrectly marked as corrupt

6

Hi @MarijeSchillern

This thread can be closed.

Although the options provided by support team is not reasonable.

As this is not an enhancement/new feature but a defect in the product, it does not sounds good to say that we have a solution but we will not give you and you have to spend extra cost and time to upgrade first.

We have just now migrated to cloud version 8.5 after a year of migration planning & effort and now immediately asking to spend more to upgrade for a product bug sounds unreasonable.

It becomes difficult for us to convince business that just for a small bug in product, the support team is asking to upgrade even they have fix for it.

7

Hi @PIYUSHSINHA,

Were you able to apply the workaround that was provided in your ticket with our support team?

8

@PIYUSHSINHA I understand your frustration. I have gone through the support ticket and I believe we followed the correct processes.

In July you were informed of the following workaround to implement instead of using a wait shape in the split for each.

Perform the following local-change:

  • Use the Assignment shape instead of the Wait shape.
  • Route it to [email protected] that is similar to the Wait shape so that no one can access the assignment.
  • Define a Service Level Agreement (SLA) on the assignment with the Goal as 30 minutes or as per the requirement.
  • Write an escalation activity which invokes ResumeFlow, passes the appropriate flow action and sets the Step page to pyWorkPage when invoking ResumeFlow.

https://community.pega.com/support/support-articles/wait-shape-used-split-each-flow-behaves-incorrectly

On September 15th the support engineer asked you whether you agreed with this functionality with a split for each over the shared work around. Our policy for patch releases is we only go back 2 versions from the current version of Pega. (8.8, 8.7, 8.6). Pega 8.5 was released October 2020 so it is in Extended Support as documented here .

As they did not hear back from you the issue was deemed closed. I have let the team know you want further discussion but hopefully the above explanation helps some way to explain the chronology of events.

9

@PIYUSHSINHA Did the work around work for you as I am also facing the same issue with Wait Shape.