A connect rest is trying to connect to an ext system but is unable to do so,how to handle this

General
1

A connect rest is trying to connect to an ext system but is unable to do so,how to handle this

2

Hi @TanyaS58

When a Connect‑REST fails to reach an external system, it should be handled using proper exception handling and resiliency design to avoid system or user impact. To trace out the exact issue, please try these:

  • Handle the Connect‑REST call using exception handling in the response data transform to capture the connection failures.

  • Validate the HTTP response status , pyStatusValue and branch the flow for non‑successful responses.

  • Avoid synchronous retries in user flows to prevent delays and timeouts.

  • For integration or backend processing, move the call to a Queue Processor and implement controlled retry logic.

  • Configure appropriate timeouts and retry counts in the Connect‑REST rule.

  • Check the Log messages for the failure details and update the case/status for monitoring and troubleshooting.

Let me know if this works or if any additional details are needed

Thanks,

Roshan Raj A K

3

Hi @RoshanRajAK say if the connect rest is fine but external system itself is down so in that case also these approach will work or do we need something else?so that we already know before hand that the external system is unavailable or down and we can somehow skip calling the connector

4

Hi @TanyaS58 ,

To skip calling the connector entirely when you know the external system is down, you can use conditional data sources within a Data Page.

Here is how you can implement this approach:

1. Leverage Multiple Sources in a Data Page

Instead of pointing your Data Page directly to the Connect-REST rule as its sole source, you can configure multiple data sources arranged in a fallback sequence.

2. Configure “When” Conditions

  • For your primary source (the Connect-REST call), add a When condition (e.g., IsSystemAvailable).

  • This condition checks a global flag, a dynamic system setting, a toggle or a cached status that tracks whether the external system is active.

  • If the system is up, Pega executes the connector. If it returns false, Pega automatically skips it and moves to the next configured source.

3. Implement Remedy Logic as a Fallback

Beneath the connector source, configure an alternative source (like a Data Transform or Look up) to serve as your remedy logic. This fallback can:

  • Return simulated/mock data.

  • Pull stale but cached data from a local database.

  • Return a clean, user-friendly error structure directly to the application without risking a connection timeout.

5

When external system is down, then you will get http response code as 5XX. Based on this you can create a Retry assignment which systematically retries after a preconfigured time

6

Hey @TanyaS58

The solutions suggested provide a solid foundation and align well with recommended Pega design practices for handling external system unavailability. However, their effectiveness largely depends on how the IsSystemAvailable flag is maintained and whether as a fallback you need to show mock data or cache data from a previous execution.

If this flag is implemented as a static value (for example, using a DSS or manual toggle), it will not accurately reflect real-time system outages. In such scenarios:

  • The connector may still be invoked initially even when the external system is already down

  • The system will only be marked as unavailable after failures have occurred

To make this approach more robust for real-world usage, it is recommended to enhance it with a dynamic availability mechanism, such as a simple circuit breaker pattern.

This can be implemented by:

  • Tracking consecutive failures (eg. HTTP Request 5xx)

  • Maintaining the timestamp of the last failure

  • Defining a failure threshold

Once the threshold is exceeded:

  • Temporarily mark the system as unavailable

  • Skip connector invocation for a defined cooldown period

  • Automatically allow retries after the cooldown period expires

This approach helps in:

  • Reducing unnecessary calls to an already failing system

  • Improving recovery handling without requiring manual intervention

As an additional improvement, check if the external system exposes a health check API:

  • It can be invoked through a lightweight Data Page

  • The response can be used to dynamically control the IsSystemAvailable flag

This reduces reliance on failure-based detection alone.

From a best practices perspective:

  • Runtime error handling should still be implemented, as systems can fail unexpectedly even with pre-checks in place

  • Queue Processors are preferred over Retry Assignments for better scalability and asynchronous retry handling

  • Fallback behavior should be clearly defined, such as returning cached data, a default response, or a user-friendly message

Overall, the proposed approach is valid, but incorporating dynamic availability tracking and structured retry handling makes it significantly more reliable for production scenarios. Let me know if this answers your query

Thanks,

Roshan Raj A K