Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

Handling connector exceptions

Updated on August 16, 2022

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 [email protected]. 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.

Have a question? Get answers now.

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

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us