There should be a "dirty" popup associated with the cancel, asking you if you're sure that you want to close the current work object. Have you suppressed this popup? Do you see it even when the activity is skipped?
If you run with the Tracer, do you see the reloadSection activity firing? Is your activity (which will be in the parameter "preactivity") present but just not firing?
On my Pega 7.2 system, I also created your use case. I even disabled the dirty check (won't let confirm close popup show up). Under this situation, Refresh-This section (with activity) was still run before the Cancel action. Please provide your section and button configuration and let us know if there is anything special in it.
please find the attached screenshots. At run time on click of the button I traced sometimes Activity is triggering and sometimes I see the empty screen in trace open rule of that activity and cancel functionality of closing work object is always happening. (version: Pega 7.2.1)
Are you saying that if you Trace the activity setRevertClaimFromClaim (the preactivity to the refresh), sometimes Tracer shows the activity executing and sometimes it does not? Then you have some other error. The client action list is not waiting for the activity to finish -- it is waiting for the refresh to finish, and the refresh will not even start until the preactivity completes, unless no preactivity name is supplied. The fact that you see no action in the Tracer window looking at the activity indicates that the activity is not successfully firing -- perhaps the parameter is not being received by the server?
I would enable DEBUG logging for the class HTTPApi; this will show all of the parameters which are being received by the server from the client for each command. You might also enable Fiddler on the client. Then you can confirm, in this bad case, if (a) the client is sending a valid preactivity, and (b) if the server is receiving the valid preactivity.
it is working sequentially for simple activities ,but what I Observe is that if an Activity is heavy having DB operations and if it consumes time -the second action "cancel" is getting triggered..but it is not the expected behavior even if the activity is complex
As it is a Flow action(popup) which has a button and on click of that button- DB action should be performed and then the popup(Flow Action) should close...thus need 2 Actions - 1.Running Activity 2.Cancel
Going by what you have said, I assume that you have configured to launch a local action as a modal dialog
and in the local action you have configured the 2 actions which you mentioned above on click event.
I have tried the same and in my case the activity was being called all the time but the only thing which should bother is getting the dirty pop-up. So, inorder to avoid that, use close as the second action instead of cancel as follows:
One more thing, I would like to add is that some times, the activity may not get called if we are mentioning the activity as post-processing activity of the local flow action, then it may not get called. So, to avoid that, we can make use of pzModalButton control instead of normal button in the local action's section and you can give the post-processing activity in the flow action.
Please try this if possible and let me know your observations.
I am also facing the same issue in Pega 7.2.2, i have the local action with button of control pxModalButtonSubmit, first event as run data transform and second as run script that comes with control. when i trace pega is executing run script first followed by data transform it's not working as sequence mentioned.