SLA Escalation Activity to call Customized flow of SendCorr
Hi,
My project uses PDM to print correspondence of type letter ( Mail ). One of the requirement is to have some letters printed as part of SLA notification. The printing of letters happens in a flow "VerifySendCorr" which we have customized, where we check if its type letter and call PDM agent through AQM. In normal flow when we print letters the activity SendCorr calls our customized Flow "VerifySendCorr" and it gets printed because the requestor AccessGroup takes care of that.
I could not do that through SLA escalation activity because the SLA triggers through different requestor and the SendCorr doesnt trigger our customized flow "VerifySendCorr".
Question : How to make SLA escalation activities SendCorr use our customized rules? How to make the SLA escalation activity run as part of a particular access group?
PS : The SLA agents are part of Pega-Procom (OOB).
Thanks in Advance
Arvind B
***Updated by moderator: Lochan to update Categories***
Accepted Solution
BNYMellon Technology
IN
Hi,
By tracing the SLA agent I was able to determine that the printer selection is based on pxRequestor.pxOrgUnit. And when the agent runs the Requestor is the agent operator Id. So I initialized the pxRequestor.pxOrgUnit property in the agent escalation activity based on value from workpage.
This is working good.
Pegasystems
US
If your issue is that your customized rule is not running, then your issue may have nothing to do with the SendCorr mechanism, but rather a more general sla-context issue.
During sla processing, the system starts by looking at the ruleset of the class of the work object, and if that ruleset is already included in the current access group for the sla context (which, please note, is NOT necessarily the access group referred to by your operator record since sla contexts don't use your operator record to log in!), then no change in access group is made.
I had an issue with this, where I was attempting to define my own flow and sla rule that referred to the PegaSample class, and I couldn't understand why my sla wasn't running properly.
It was because the ruleset of the PegaSample class is specified as Pega-ProCom, so when the sla ran, the system made no attempt to switch access groups, so it ended up attempting to process the sla with an access group that didn't include the private ruleset in which I had defined my flow and sla rule.
A technical reference for the above is the comment in the java step at about step 5 of the System-Queue-Servicelevel.establishContext activity that says:
// Now see if we need to switch access groups for the ruleset of the class of the work object of the assignment (phew!)
This activity is the one that decides whether the access group needs to be changed when running the sla.
If your issue is that your customized rule is not running, then your issue may have nothing to do with the SendCorr mechanism, but rather a more general sla-context issue.
During sla processing, the system starts by looking at the ruleset of the class of the work object, and if that ruleset is already included in the current access group for the sla context (which, please note, is NOT necessarily the access group referred to by your operator record since sla contexts don't use your operator record to log in!), then no change in access group is made.
I had an issue with this, where I was attempting to define my own flow and sla rule that referred to the PegaSample class, and I couldn't understand why my sla wasn't running properly.
It was because the ruleset of the PegaSample class is specified as Pega-ProCom, so when the sla ran, the system made no attempt to switch access groups, so it ended up attempting to process the sla with an access group that didn't include the private ruleset in which I had defined my flow and sla rule.
A technical reference for the above is the comment in the java step at about step 5 of the System-Queue-Servicelevel.establishContext activity that says:
// Now see if we need to switch access groups for the ruleset of the class of the work object of the assignment (phew!)
This activity is the one that decides whether the access group needs to be changed when running the sla.
BNYMellon Technology
IN
Thanks Eric,
What I notice is when ever I call SendCorr in my escalation activity and include Correspondence of type letter, the SLA event goes to broken-process with below error.
| Error message | Goal seek requires missing input property pxRequestor.pxOrgUnit on page (unknown page); details: (unknown) |
When the Same activity is called in a normal flow its working fine with the letter generated. any idea?
Accepted Solution
BNYMellon Technology
IN
Hi,
By tracing the SLA agent I was able to determine that the printer selection is based on pxRequestor.pxOrgUnit. And when the agent runs the Requestor is the agent operator Id. So I initialized the pxRequestor.pxOrgUnit property in the agent escalation activity based on value from workpage.
This is working good.