Exception handling for integration object called as a rule

Normally when integration fails, response sends status as error/fail instead of success. So for handling such events, wherever data from response is used should be checked for null values, so that UI errors are prevented.

Also, if response is error, additionally a user friendly message can be displayed on UI so that user is aware of the issue and can retry the connection.

To add to the other responder, the best way to do this is to use an if statement with the integration response. So you could do something like this:

a!localVariables(
  /* Call the integration to query the external system */
  local!externalQuery: rule!GetUnsettledTransactionList(),
  
  /* Handle the response depending on the outcome */
  if(
    local!externalQuery.success,
    /* If true, display a grid field with the response details */
    a!gridField(
        data: local!externalQuery.result
    ),
    a!textField(
        readOnly: true,
        value: "Error returning a response. Error details: " & local!externalQuery.error
    )
)

Depending on the actual error code from the other system, you could also make your error handling a bit more specific. For example, if a 504 Gateway Timeout is returned (you can get the HTTP Status Code using <variable>.result.statusCode), then you could include a separate if() statement that specifically says something like "Response timed out, please try again later" and display it in a different text box instead of the grid.

To take this one step further, you need to think about the overall context in which the Integration is being invoked. If a User is effectively waiting for the response (e.g. you're calling it directly from within a SAIL interface) then you need to let the User know that there's been a problem. Peter's response starts to help you with this. But you also need to let the Support Team know that there's been a problem, otherwise you're relying in the User to raise a ticket manually. You could extend the pattern that Peter has proposed by also invoking a Process Model to raise a Task with the Support Team. And this then leads you to start thinking about how to actively prevent the transaction attempts in the first place if it's already been established that there is, for example, a connectivity problem. Otherwise you'll end up flooding the Support Team with what are effectively duplicate tasks related to the same problem.