CONNECT REST- Error Handling across the application-Design query
We are in process of designing Business Rule engine to calculate price adjustments in pega. In this process, application needs to carry payload to external systems.To do so, we are using quite a lot of Connect REST rules to achieve the requirement.
Now, in this process our application is encountering various HTTP errors across all the connect rest rules . So decided to implement exception handling across the application.
Following are the options considered
Modify ConnectionProblem OOTB flow rule to handle the connectivity failures
Execute all the connect REST rules through the assignment. This approach will help us to achieve retry mechanism using Service level agreements. After the successful retries, if the issue still persists, route the case to exception workbasket.
Create a new data table to record the exceptions encountered. Create an agent activity to monitor the data table and send an email on timely fashion to the administrator about new entries.
If you are developing a Business Rule Engine (BRE), which implies unattended, fully-automated operation, my suggestion is to avoid being strongly-coupled to the use of cases, flows, assignments, and SLAs at least in terms of a universal REST connector management approach.
Option 1: The ConnectionProblem flow allows someone to manually reissue a connect request at the location in a flow where the connector failed. Since this is flow-related and you are developing a BRE, I would not recommend using it as a universal connector management solution.
Option 2: Use of assignment SLAs to automatically reissue connection requests in the event of failure also involves strong coupling to flows. Plus, the primary purpose of SLAs is to provide data regarding the proficiency of human requestors to complete a task. I would not recommend using this approach as well.
Option 3: IMHO this is the best approach for a BRE, i.e., recording connect attempts in a data table, updating a row in that table every time a connect request fails, etc.. You mentioned creating an activity to monitor the table which sounds like you would implement an Advanced Agent. My suggestion is to instead use a Standard Agent as described below.
A Standard Agent can be queued against any step page class you choose; Standard Agents are not limited to being launched within flows. For example, it is possible to queue a Standard Agent from an Advanced Agent where the Queue-For-Agent step page is some Data- class, for example, Data-Party.
The two requirements when using a Standard Agent are: (1) persisting the step page and (2) persisting the queued System-Queue-DefaultEnty record created by Q-F-A. This means a commit has to be issued after Q-F-A is called. The System-Queue-DefaultEnty EstablishContext activity essentially invokes Obj-Open-By-Handle to restore the step page. Your persisted step page should use a Data- class that ensures a unique pzInsKey. Consider calling a function that returns a GUID such as @pxGetNewGUID() and assigning that value to a singular "Key" property. Also note the Locking tab on the Data class rule.
When the Standard Agent activity encounters a connect failure it can increment a failure count on the primary page, i.e., the original step page, issue Obj-Save, then re-queue itself by invoking another Q-F-A call. If the number of failures has become excessive, an email can be sent to an administrator.
The only remaining problem to solve in terms of a universal solution is capturing all of the information regarding what REST connector to invoke, how to populate the request, and how to process the response. Note that a REST connector-sourced Data Page encapsulates all of this except the "capture" aspect.
Request and response capture would need to take place within your originally persisted step page. It would be very complex for the step page class to know how to persist each unique response within a different embedded page within different cases types. Rather than implementing a solution where the step page class “visits” the case, or whatever "RequestIssuer" had issued the REST connect request, the universal solution would require that the REST connector issuer “visit” the successfully completed, persisted step page.
Note that the above is similar to how an asynchronous service behaves except here the originating RequestIssuer polls a persisted step page populated by a REST connector-invoking standard agent. A second Standard Agent could be spawned against the RequestIssuer step page to perform the polling process.
Thanks for detailing about the options considered. With the nature of the application keeping in mind (BRE), opting for option 3 would be a wise decision. I was in a impression that standard agents can be invoked only within the flows. But , the fact is it can queued against any step page.
I will do the detailed analysis on option 3 and design the functionality around it.