Signaling cases using declarative processing
A is the parent case.. B and C are child cases.. D is the grand child.. The process flow in B has to launch D and B should be notified whenever D reaches a specific milestone in D's process..(for example when pystatuswork on D changes)
While this can be achieved through both declare on change and declare trigger rules, declare trigger rules ensure that there is no performance impact, However we may have to open and resume the flow on B based on the status change in D. Is it recommended to resume a flow(B in our case) within the trigger activity?? Because launching the flow within the trigger activity will cause commit to be executed as part of the flow execution and doing a commit inside the trigger is generally not recommended as this impact the transaction boundary.
We shall use declare on change too however I am slightly skeptical about the performance.
A
B
C
D
Pegasystems Inc.
IN
Hi Sankar, Good morning!
- could we learn the process of B should be doing on receiving the notification from D...
- could we attempt running the notification event on pyWorkCover as the context page on reaching the desired status for case D?
- a declare onChange with a WHEN rule [on pyStatusWork] might not impact adversely
- or would considering a declare onChange on application property [NotifyStatus] works?
- When pyStatusWork="Notify" then Set .NotifyStatus="Notify"
- we will have to expose the column for NotifyStatus for better performance.
- When pyStatusWork="Notify" then Set .NotifyStatus="Notify"
- or leveraging from calculations tab ...
- on Change of aggregated property - the notification event will be invoked.
- this would cause TWO declarative's to fire which doesn't make sense.
- on Change of aggregated property - the notification event will be invoked.
- or would considering a declare onChange on application property [NotifyStatus] works?
Please share your thoughts/comments, Thank you!
psahukaru
Manheim
US
Phani,
Thanks for the update.The processing we want to do on B could be anything based on the notification status.. We may resolve B or resume the B process and route it to a separate workbasket...etc.. The requirements aren't comprehensive yet, however we want to either resolve or resume the flow on B based on the notification status.
My question was primarily around whether it is recommended to do a resumeflow from the declare trigger. I know that in general it is not good to do commits within triggers as it would impact the txn boundary(if we resumeflow from the trigger activity, this flow resumption does some auto commits and it might impact the txn boundary).. Hence, declare on change may be the rightway to do this.(based on pystatuswork change).. We have to just ensure that this doesn't have any adverse effect(bad performance)
Pegasystems Inc.
IN
Hi Sethu, Good morning!
>>> The processing we want to do on B could be anything based on the notification status. We may resolve B or resume the B process and route it to a separate workbasket...etc
-
we could leverage wait smart shape
-
configured with wait type
-
as case dependency
- to reach to status to perform.
-
as case dependency
-
configured with wait type
- or a ticket raised on parent context page (Obj-Open-By-Handle - Parent case)
>>> whether it is recommended to do a resumeflow from the declare trigger. I know that in general it is not good to do commits within triggers as it would impact the txn boundary(if we resumeflow from the trigger activity, this flow resumption does some auto commits and it might impact the txn boundary)
- I too agree with your analysis...
>>> Hence, declare on change may be the rightway to do this.(based on pystatuswork change).. We have to just ensure that this doesn't have any adverse effect(bad performance)
Hi Sethu, Good morning!
>>> The processing we want to do on B could be anything based on the notification status. We may resolve B or resume the B process and route it to a separate workbasket...etc
-
we could leverage wait smart shape
-
configured with wait type
-
as case dependency
- to reach to status to perform.
-
as case dependency
-
configured with wait type
- or a ticket raised on parent context page (Obj-Open-By-Handle - Parent case)
>>> whether it is recommended to do a resumeflow from the declare trigger. I know that in general it is not good to do commits within triggers as it would impact the txn boundary(if we resumeflow from the trigger activity, this flow resumption does some auto commits and it might impact the txn boundary)
- I too agree with your analysis...
>>> Hence, declare on change may be the rightway to do this.(based on pystatuswork change).. We have to just ensure that this doesn't have any adverse effect(bad performance)
-
declare on change suites better... but again,
-
if the processing is light [sending correspondence/adding note - pxAttachNote]
- we could implement using declare onChange rule watching our application property instead of OOTB property [pyStatusWork]
-
if the processing is light [sending correspondence/adding note - pxAttachNote]
Please share your thoughts/comments, Thank you!
psahukaru
Manheim
US
Phani,
Thanks for the update.. Declare OnChange is more likely to have a performance problem and hence we are inclining more towards using a trigger and updating the caller using a service oriented approach.
The connector can be invoked from the trigger activity and this connector can be configured to run asynchronously for optimal performance.
Thanks
Sethu