Handling connector exceptions

Basics

Through an Integrator shape on a flow rule, a flow execution can call an external system such as a relational database, Enterprise JavaBean, or Web service. The activity referenced in the Integrator shape references a connector rule (for example, a Connect SOAP rule) that controls the communication and data exchange with the external system.

For various reasons, a tested connector interface may fail or time out, causing work item processing in the flow rule to halt. To facilitate detection and analysis or repair of such events, you can designate in your application a flow rule for connector exceptions. Failure of an Integrator shape causes the designated flow rule to start. The flow rule can send out email correspondence, attempt retries, skip over the integrated step, or send an assignment to someone.

Development

See Using Error Handler Flows for Connectors, a document on the Integration area of the PDN, for detailed development instructions, summarized here.

To use this facility, specify the second key part — Flow Name — of a flow rule in the Error Handler Flow field on a connector rule form. The Applies To key part of the calling flow is used as the first key part when retrieving the exception flow rule.

If you leave the Error Handler Flow field blank, a connector problem causes the flow execution to fail and is reported only as Java exceptions in the Pega log of type: com.pega.pegarules.pub.services.ConnectorException.

The standard flow rule Work-.ConnectionProblem provides a default approach to exception handling.

When you accept the default, a connector exception causes the following processing:

1.               The original flow execution is paused. The ConnectionProblem flow is called with seven parameters:

§  Operator ID of a user to notify (not used)

§  The Applies To and Flow Name key parts of the original flow execution

§  The name of the shape in which the problem arose

§  A ConnectorException type

§  An error message

§  An assignment type (Workbasket or Worklist), indicating where to place a resulting assignment.

2.               For all the exception types other than ResourceUnavailable, processing continues in a FlowProblems flow. Use the Flow Errors gadget in the Processes landing page to address flow errors. See Process and Rules category — Processes.

3.               If the exception type is ResourceUnavailable, up to five retries are attempted, at intervals determined by a service-level agreement.

4.               A developer accessing the workbasket can cancel the assignment (ending both the ConnectionProblem flow and the original flow) or attempt to restart the original flow, perhaps after taking corrective action.

This flow may use a workbasket named IncompleteConnections@org.com. You can override this default with a flow rule (in your application's work classes) of the same name, or override the rules it calls. For example, your exception flow can send email notifications to an appropriate user.