Connectors - Exception Handling

Integrating with external systems can introduce additional problems. Network errors involving firewalls, incorrect authentication or credentials or system failures with respect the messages being passed are just some examples.  To ensure effective results, we need to have a graceful exception handling approach in place.

Let’s discuss on what are the different exception or errors we expect, how to handle these in various scenarios, finally let’s do a sample implementation and exception handling.

For quick identification and fixing of the errors we need understand different types of errors which can occur while integrating with third party applications. Broadly we can classify them as

·         Transient

·         Permanent

Transient errors typically don’t last very long and correct themselves over time. For example, consider a situation where the remote host of the application or system the connector is accessing is restarted or temporarily unavailable. 

Permanent errors can also occur. These errors are typically due to a configuration error or an error in the remote application logic. For example, consider a situation in which an invalid SOAP request is sent to a SOAP service. In this case, the error persists until the SOAP request message is fixed.

To understand how to handle these exceptions, we need to first understand how connector rules are configured to execute. A connector rule could be called from

·         Flow (Integrator) / Activity

·         Data Pages

For Flow/Activity rules, we can use OOTB ConnectionProblem Flow, which would retry transient errors for 5 times before placing the assignment into IncompleteConnections Work Basket. In case of Permanent errors, another sub flow FlowProblems is initiated, from where an administrator can either Resume the flow from current step, else restart the flow from where error occurred. The ConnectionProblem Flow, can be extended to customize work baskets, SLA rules or other requirements as demanded by the business case.

**Point to remember, do not have transition step configured in the activity rule for the step where we can making Connect-XXX calls. If we have transition step, ConnectionProblem flow configured in connect rule form is not initiated by Pega.

Sample Implementation:
Consider the following Flow

Sample Flow with Integrator

Upon User1, completion of Assignment 1, an Integrator is triggered followed by another assignment, which is routed to a work basket. Now configure connector rule to include ConnectionProblem flow in the Error Handling section of the rule form.

At run time, if any exception occurs while executing the Connect rule, ConnectionProblem flow is initiated

Now Admin or Platform Support team can monitor the work basket IncompleteConnections  and fix the connection issues and restart the flow execution from here. 

In addition, Platform Support team can also fetch a report to quickly identify how many cases are impacted with similar issue. To do so, Pega --> Process and Rules --> Tools-->My work --> Work By WorkBasket

In case of DataPages, we need utilize POST LOAD PROCESSING activity, to verify .pyStatusMessage property for the exception and take appropriate remediation steps. 

As part of remediation steps, we can initiate the same ConnectionProblem Flow and also provide appropriate User Friendly Error Message to the end user.

**ConnectionProblem flow is not initiated by Pega even if it is configured in Connect Rule form.

In summary this design pattern prescribes, exception handling for any errors occurred while fetching data from external systems, should be notified, corrected/fixed, and re executed.

Hope the above article is covers most of the required stuff. Please leave a comment with your practical experiences on how useful this article was and also any thing needs further explanations. 

Feedback's are welcomed in the form of comments.

Vamshi