Discussion
ITRegtime
RU
Last activity: 16 Oct 2015 4:11 EDT
Flow stuck on wait shape.
Hello, I've got a simple flow that create subcase and then waits untill it reach status "Resolved-Complete". My colleges already used this pattern in project and it worked fine, but when i used it, process always stuck on wait shape despite subprocess reached resolved-complete status. I've looked throw forums and find out that by creating wait shape with case dependancy, PRPC create Declare Trigger in depended class. But in my case when I configure wait shape this rule doesnt appear. What am I doing wong?
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Areteans Technology
IN
check the declare trigger rule in subcase class ?
Thanks,
Ashok
ITRegtime
RU
Theres no declare triger in depended subcase. When I configure wait shape it doesnt create declare triger but i cant understand why it happens.
Areteans Technology
IN
Can you trace when you are configuring the wait shape and saving the process or the case type ?
Areteans Technology
IN
search for pycasedependency rule .
ITRegtime
RU
Sequence | 39413 |
Interaction | 268 |
Timestamp | Sep 03, 115 - 13:43:45 13:45:49 (20150903T104345.405 GMT) |
Event Type | Exception |
Event Name | Exception |
Event Key | RULE-OBJ-ACTIVITY RULE-DECLARE-TRIGGER CHECKFORWARNINGS #20140603T112345.650 GMT |
Thread Name | TABTHREAD9 |
Work Pool | SB_R-BadAssets-Work |
Last Step | RULE-DECLARE-TRIGGER CHECKFORWARNINGS #20140603T112345.650 GMT Step: 2 Circum: 0 |
Sequence | 39413 |
Interaction | 268 |
Timestamp | Sep 03, 115 - 13:43:45 13:45:49 (20150903T104345.405 GMT) |
Event Type | Exception |
Event Name | Exception |
Event Key | RULE-OBJ-ACTIVITY RULE-DECLARE-TRIGGER CHECKFORWARNINGS #20140603T112345.650 GMT |
Thread Name | TABTHREAD9 |
Work Pool | SB_R-BadAssets-Work |
Last Step | RULE-DECLARE-TRIGGER CHECKFORWARNINGS #20140603T112345.650 GMT Step: 2 Circum: 0 |
Input | Activity=ReloadSection |
Ruleset Name | Pega-ProcessArchitect |
Ruleset Version | 07-10-15 |
Standard | |
Activity Name | CHECKFORWARNINGS |
Activity Number | 114 |
Parameter Page Name | =unnamed= |
Primary Page Class | Rule-Declare-Trigger |
Primary Page Name | Trigger |
Step Number | 2 |
Exception Trace | com.pega.pegarules.pub.PRRuntimeException: Unable to validate Property trigger information |
In Primary Page - Trigger there were warnings:
|
||
|
May be thats it but I still dont know how to deal with it. By the way i can manualy create Declare Triger in subclass it confuses me even more =(
Areteans Technology
IN
I would recommend, delete the flow and recreate it once. Thanks.
Pegasystems Inc.
IN
You could create the declare trigger in the activator class(sub case class). The name of the trigger could be anything. Configure "pxCheckFlowDependencies" as the trigger activity when instance is "Saved and" ".pyStatusWork" property is modified. Refer to PegaSample-Investigation. pyNotifyDependents trigger rule.
PegaOne
IN
I am having the same issue in my application.
The above mentioned Declare-Trigger approach didnt help. Could you please let me how to debug this issue?
Any pointers would be highly appreciated.
Thank you.
@IgorKuzmenko, could you please let me know how you generated the above Trigger related data? (the screenshot that you have pasted inline). Thank you.
Sopra
FR
I had a similar issue a few weeks ago. The issue was that the child case did not contain any assignment which caused some locking issue preventing the parent to get the status change to Resolved-Completed. I can say more if needed.
Pegasystems
Hi GrandeJ1,
Were you able to work around this issue?
Sopra
FR
Hi,
Yes. The problem was that the parent case was open on screen (thus locked) when the child tried to do the status change, and since the status change did not occur after any assignment, the locking just failed with no retry.
We had some help from a Pegasystems consultant IRL. He suggested that we use an SLA to do the status change, so it would be executed by the agent which would handle locking properly (with retry). A bit dirty a workaround to my eyes, but he said it was better than just manipulating locking directly. Anyway the app on which we had this issue was only a small experiment so we didn't develop it further.