Exception handling in Pega Connect-REST

Outbound calls fail. The network drops, the partner's server is down, a token expires, or the answer is not what you expected. A Connect-REST integration that handles none of this shows users a raw error, or worse, carries on with missing data. Good exception handling has three parts: detect the failure, decide what it means, and respond in a way the user can understand.

Kinds of failure

Failure	Example	Sensible response
Connection or timeout	Service unreachable, no reply in time	Retry a limited number of times, then show a friendly message
Client error (4xx)	400 bad request, 401 unauthorised, 404 not found	Do not retry. Fix the request or credentials, or tell the user the record does not exist
Server error (5xx)	500 or 503 from the partner	Retry with a delay, then escalate
Bad response body	Missing field, wrong format	Log it, and use a default or stop the process

Where to handle it in Pega

On the Connect-REST rule: set connection and read timeouts, and map the response for each HTTP status so a 404 can be treated differently from a 200. The rule also records the status code and message so your logic can test them.
In the activity that calls the connector: after the Connect-REST step, use the step's transition settings to branch when the step fails, and go to an error-handling step.
In a data page: use the response data transform to read the status and set a safe default, for example "Balance unavailable".
In the case: route the case to a work queue for manual handling if the integration keeps failing.

A worked example

A loan case calls a credit bureau.

The Connect-REST rule has a five second read timeout.
The activity's transition on the connector step says: if the step fails, go to the step HandleBureauError.
HandleBureauError checks the status. For a 503 or a timeout, it queues a retry for 10 minutes later, up to three times. For a 401, it writes a log entry and creates an alert, because the credentials need fixing.
After three failed retries, the case moves to the "Manual credit check" workbasket, with a note saying why.

Good practice

Never show raw exception text to end users. Use a message rule with plain wording.
Retry only errors that could pass on a second try, and cap the retries.
Log the request ID and status so support can trace the call.
Test failures deliberately: wrong URL, expired token, a very slow mock.

Interview tip

Describe the three steps, detect, decide, respond, and give the retry-then-manual-queue example. Related: Authentication in Pega Connect-REST and HTTP methods in Pega integration.