Exception handling in STP
When Pega is being used as a headless application (using services mainly) to communicate with external systems, which is the best /ideal way to handle exceptions that may occur in processing within Pega? for e.g. as a part of the headless processing , Pega needs to call a couple of 3rd party systems for data, in case the communication fails (connection problems/ validation errors/ system errors etc) the process flow / processing within pega needs to be smart enough to identify the error and communicate back to the calling system and also have provisioning to continue from the last completed step when the request is tried again by the calling application.
Is there a way to do this other than creating a work item in Pega which proceeds through the flow and on exception calls the FlowProblems/ ConnectionProblem flow?
***Updated by moderator: Lochan to add Categories***
When Pega is being used as a headless application (using services mainly) to communicate with external systems, which is the best /ideal way to handle exceptions that may occur in processing within Pega? for e.g. as a part of the headless processing , Pega needs to call a couple of 3rd party systems for data, in case the communication fails (connection problems/ validation errors/ system errors etc) the process flow / processing within pega needs to be smart enough to identify the error and communicate back to the calling system and also have provisioning to continue from the last completed step when the request is tried again by the calling application.
Is there a way to do this other than creating a work item in Pega which proceeds through the flow and on exception calls the FlowProblems/ ConnectionProblem flow?
***Updated by moderator: Lochan to add Categories***
Pegasystems Inc.
US
Hello Anoojit -
I am moving your question to the Pega Product Support community in the Mesh. This Mesh Help area is for questions about how to use the Mesh itself. You should receive a reply in the product support area.
Thanks!
Amanda
Pegasystems Inc.
US
There are a lot of ways to answer your question. You definitely should follow up all of your communications with external systems with a transition that looks at something like stepStatusFail to capture the failures before processing continues. From there, how you deal with it is gated more by your business needs than Pega's technology. You could retry right away, you could wait and try again, you could queue the object off to an agent to try again, or you could create a work object and stick it into a workbasket for an administrator to review. The good news is that Pega allows you to all of the above, so you can tailor your error response to the external system and even type of error. Our flexibility means there's no "best" way for all cases. It may take a bit of work and creativity, but you should be able to build a headless system with robust error recovery.
I agree with Mike Townsend that, to a large degree, "it depends."
I've personally implemented a workbasket in the flow that has an agent auto-retry a certain number of times at specific intervals, and then only if the service continues to fail, use the ConnectionProblem flow.
But I infer you're asking are there (better) alternatives to a flow? Two adages come to mind: "there's more than one way to skin a cat." There are always alternatives, some better, some worse. Are there space constraints that would vote against a work object with a flow, however complex or simple? "Always use the right tool for the right job." It would seem to me, without knowing more, that a work object is the best way to save the data and/or a flow to save the state of processing, if nothing else.
If your application calls for less "overhead" and you don't now have a work object, what is the form of the existing processing?
Cognizant Technology Solutions
IN
Thanks Mike and Greg for your thoughts. I have had already thought of the options you have highlighted and greatly appreciate your views. However the existing model here is that the Object persistence is not in Pega. There are other systems which persists the entity, whereas Pega acts as only a servicing and decision-ing layer in between with no data persistence and Obj transactions. So if a work entity is being created in Pega, it would violate the current object persistence and transaction model. But I like the thought of handling the errors and exceptions in a flow, maybe through a temporary work object. Once the exception is caught the message is set in the response of the service and the flow is interrupted by a ticket which sends it to the end shape. So the decision of retrying or executing a fresh request lies with the calling application and not Pega.