Calling a REST Connector rule with Queue option, requires explicit Commit
Hello All,
We have a REST Connector rule that we want to invoke asynchronously. So in the Connector rule configuration, we set under Processing options and "Intended For" as "Queuing(response will not be available)". We also created a new Request Processor that referred to "System-Queue-ExecutionRequest-Connect-Default" Queue class. This request processor was referred inside the REST Connector rule under the Processing options --> "Request Processor".
In the activity that invokes this Connector rule, we set the "Execution Mode" to "Queue".
Now the problem here is the requirement of the Commit call after the Connector rule call in the activity. If i dont have a commit, the item is not queued at all.
Is there a way by which it can be auto-committed, without the activity invoking explicit commit.
I went through the following link for setting up the Connector rule as Queued items.
https://pdn.pega.com/integration/how-to-call-web-services-using-queued-execution-in-pega-55
The above article also suggests we need to have an Explicit Commit. But again that was written for 5.5. I am using 7.1.8
The users in our system are very consious on the response time, so we made the Connect rule call as Queued.
But Adding the Commit statement breaks the Guardrail, and triggers a severe Data Integrity warning. I am not sure how i can justify this. Because i was hoping PRPC Engine would internally take care of the Commit part (once a Connector call is made as Queued) , without expecting an explicit Commit call.
Am i missing something here??
Please help
Swami
Virtusa
US
No we haven't yet able to solve this issue. We have to explicitly call commit.
We have also started facing another issue now. if service activity fails throw the error back, still the OOTB agent activity does not considers it at failure and does not re-queue the item to be processed in next run. Also there is no setting for minimumageforprocessing like we have for standard agent.
Suggestions Appreciated.
Thanks
Amit
Pegasystems Inc.
US
Hello Amit,
I'm not intimately familiar with the REST connector and queuing that you are using, but in our transaction model, if there isn't a commit called by the system as part of normal processing somewhere, then you would need to call one explicitly. We give you a warning because a lot of customers cause trouble for themselves by adding them in the middle of a transaction. If you were calling this from a utility shape in a flow I would strongly urge you not to use an explicit commit, but if the transaction starts with something like an incoming REST connection and you defer save the queue item, then it sounds like committing it is the exact right thing to do.
I expect that the new error you are facing is because you queue the service activity, so a separate requestor is actually doing the work and experiencing the failure. So from the perspective of the agent activity, things worked successfully (it would be a different story if saving the queue item failed). You want to put the error trapping/requeuing code in the place where the error occurs.
Thanks,
Mike