Back Forward Handling connector exceptions

Integration-Connectors category

Basics

Through an Integrator task — represented by the zzz shape in the Visio diagram of 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 object 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 task causes the designated flow rule to start. The flow rule can send out e-mail correspondence, attempt retries, skip over the integrated step, or send an assignment to someone.

Development

See PDNUsing Error Handler Flows for Connectors, a document on the Integration area of the Pega Developer Network, for detailed development instructions, summarized here.

To use this facility, specify the second key part — Flow Type — of a flow rule in the Error Handler Flow field on a connector rule form. Process Commander uses the Applies To key part of the calling flow 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.

Work-.ConnectorException

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 Type 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. See Working with the Flows with Problems report.
  3. If the exception type is ResourceUnavailable, up to five retries are attempted, at intervals determined by a service level rule.
  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.

Up Integration-Connectors category