Question
Capgemini
MX
Last activity: 22 Aug 2022 11:05 EDT
Cancel a case after "n" minutes
Hello, I am a newbie in PEGA,
we have a requirement that a case must be canceled after one day or three days if the user does not respond to it.
I tried with an SLA rule and a test value of one minute, after that the PEGA pxForceCaseClose activity is run. But I notice that the case is not canceled after a minute, but several minutes later, maybe 10, 20 or 30 minutes later. Does anyone know what is causing this behavior?
Capgemini
GB
Updated: 21 Aug 2022 7:35 EDT
Eclantiqx
AU
Hi @EdgarIvanV
You could try tracing the agent ServiceLevelEvents, which is responsible for processing Service Level requests.
Lloyds Banking Group
IN
In the Screenshot that you have mentioned I can see the goal and deadline both were specified for the case. Can try only defining with goal and see the use case works fine.
Capgemini
MX
@TummalapalliNarayana It is mandatory to establish a deadline greater than the goal date.
Infomatics Corp
US
@EdgarIvanV Check wehther SLA is running when the User is still viewing the case, if there are lock issues then it will not execute immediately. If will fail and retry.
Pegasystems Inc.
GB
@EdgarIvanV if you still need further help could I alert you to the fact that we have an Open "Ask the Expert" thread this week, specifically for Case Management issues?
Please post your question here.
@EdgarIvanV
SLA Escalation actions are processed by the Pega ProCom standard agent ServiceLevelEvents
https://docs-previous.pega.com/system-administration/86/pega-procom-agents
This will pick up SLA entries from the queue (class System-Queue-ServiceLevel) every few seconds depending on the Agent Schedule (and runs on each node in your system). Since it is based on periodically picking entries from a queue, it will never process in real time. There will always be a slight delay because of the agent schedule.
If it is taking longer to process than you have given in the SLA rule, this can happen for a few reasons:
1. Agent Schedule config has been modified (maybe somebody has been changing it to pick records every 30 minutes instead of every few seconds? Maybe they switched off the agent in Admin Studio?)
@EdgarIvanV
SLA Escalation actions are processed by the Pega ProCom standard agent ServiceLevelEvents
https://docs-previous.pega.com/system-administration/86/pega-procom-agents
This will pick up SLA entries from the queue (class System-Queue-ServiceLevel) every few seconds depending on the Agent Schedule (and runs on each node in your system). Since it is based on periodically picking entries from a queue, it will never process in real time. There will always be a slight delay because of the agent schedule.
If it is taking longer to process than you have given in the SLA rule, this can happen for a few reasons:
1. Agent Schedule config has been modified (maybe somebody has been changing it to pick records every 30 minutes instead of every few seconds? Maybe they switched off the agent in Admin Studio?)
2. High Load on the SLA agent.The SLA queue System-Queue-Service level either has a very high number of entries in it and the agent is taking a long time to process these records, so your case is getting delayed due to high volume of cases. Or there could be particular processes that are being executed by the SLA mechanism which are very intensive and are taking up resources and slowing the processing down (like generating giant batch files for example). If it's a test system you can try clearing the SLA queue table. If it is production you will need to investigate why the volume is so high.
3. The case to be cancelled is locked. If you or another user has the case open on an assignment then the lock is held. The SLA cannot process entries when the lock is held by another requestor. It will automatically retry later. I believe the default lock timeout is 30 minutes, so if somebody locked the case, then forgot about it, the SLA wouldn't be able to process for at least 30 minutes. You can see in the logs if the SLA fails to execute due to lock issues.