Skip to main content

Table of Contents

Handling connector exceptions

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.

A tested connector interface may fail or time out, causing work item processing in the flow rule to stop. To detect and analyze or solve such issues, you can create 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.

To use this functionality, 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:

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 (Work queue 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.

  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 work queue 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 work queue named 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.
Suggest Edit
Did you find this content helpful?

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

Ready to crush complexity?

Experience the benefits of Pega Community when you log in.

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us