Asynchronous Service SOAP doesn't work properly in Pega 7.2.1
An asynchronous Service SOAP has been set up with a request processor which is defined as max attempts = 5.
Whenever Service has been called and work object is being locked the queue item is being created. It attempts first time and we are getting a proper error message. But for the next attempts, it throws some exception. Detailed xml has been attached. Could someone please provide any solution regarding this?
***Moderator Edit: Vidyaranjan | Updated SR details and tagged SRcreated***
EPAM Systems, Inc.
ES
Hi Sayan,
In the logs shared, I have observed that the "Database rollback caused queue item rollback".
Any entry retrieved from the agent queue is locked while the entry is being processed until a commit or rollback occurs at the end of the process. If a rollback occurs, and AQM(Agent Queue Management) is enabled. It puts the queue entry into failure status and stores it into the “Broken-Process” Queue or “Broken” Queue. From there, someone with access to the broken queue, can view it, fix the issue and re-queue the entry for processing again.
When the AQM is disabled, the agent gets only one chance to process the entry as the entry is removed from the queue rather than being locked. In the case of process failure, the queue entry is not kept anywhere for another possible attempt. Detailed explanation regarding queue :- https://docs-previous.pega.com/system-administration/how-agent-queues-work
AQM need to be enabled, such that the entry is retained in the broken queue in case of failure.
User can requeue failed agent items as well. Refer :- https://docs-previous.pega.com/system-administration/how-requeue-failed-agent-items-broken-queue-items-report
Hi Sayan,
In the logs shared, I have observed that the "Database rollback caused queue item rollback".
Any entry retrieved from the agent queue is locked while the entry is being processed until a commit or rollback occurs at the end of the process. If a rollback occurs, and AQM(Agent Queue Management) is enabled. It puts the queue entry into failure status and stores it into the “Broken-Process” Queue or “Broken” Queue. From there, someone with access to the broken queue, can view it, fix the issue and re-queue the entry for processing again.
When the AQM is disabled, the agent gets only one chance to process the entry as the entry is removed from the queue rather than being locked. In the case of process failure, the queue entry is not kept anywhere for another possible attempt. Detailed explanation regarding queue :- https://docs-previous.pega.com/system-administration/how-agent-queues-work
AQM need to be enabled, such that the entry is retained in the broken queue in case of failure.
User can requeue failed agent items as well. Refer :- https://docs-previous.pega.com/system-administration/how-requeue-failed-agent-items-broken-queue-items-report
Broken Queue entries can be accessed by below path(To check if there is any entry for the above agent or not?) 1.DesignerStudio -> Systems -> Operations -> SystemManagementApplication
Under Agent Managent Section ->SystemQueueManagement -> Broken Process
2. DesignerStudio -> Process & Rule -> Work Admin -> Broken Queue Items.
Refer video tutorial to understand the broken queue in details :-
https://community.pega.com/video-library/support-guide-how-troubleshoot-sla-broken-queue-entries
Kindly notify, if it helps.
Regards,
Asif
Capgemini
IN
Hi Asif,
Thanks for your reply.
1. AQM is already enabled here.
2. My actual confusion is why this exception occured here which causes the rollback?
Regards,
Sayan
EPAM Systems, Inc.
ES
Hi Sayan,
Could you share tracer capturing this event? I want to see the execution steps and stack trace.
Also share Pega rules and Pega Alerts files. Attached file is ..?
Regards,
Asif
Pegasystems Inc.
IN
Based on your Pega platform version number, you may want to try searching for maxlockattempts in your prconfig.xml to make sure you only have it in there once, or add it if it's not present, and set it specifically with this syntax :
<env name="database/maxlockattempts" value="1"/>
Once we have the requested log, we can analyse the same and give you more inputs on this.
Pegasystems Inc.
IN
Hi Sayan,
You have updated us in the private message that you went ahead and raised an SR with the support team for further investigation. You have also shared the SR number details. I have tagged the SR number details in the related support case number section for tracking .
Thank you!
~Vidyaranjan A V | Community Moderator | PegaProductSupport | Pegasystems Inc.
Accepted Solution
Pegasystems Inc.
IN
Hello!
On reviewing the SR, we see that it is closed. An enhancement was created. The enhancement request ID is noted under the Related Support Case Number field. Please refer this number to your Pega Account Executive if you need any updates on this enhancement.
Thank you