Handling Non-200 HTTP Responses in PeopleSoft Integration Broker

 In PeopleSoft, working with Integration Broker (IB) to make REST or SOAP service calls is pretty standard. But here's the thing—you can't just wrap everything in a simple Try-Catch and call it a day.

Why? Because the moment the target system returns a non-200 HTTP status—say a 400 Bad Request—PeopleSoft doesn’t raise an exception you can catch. Instead, the system treats it as a failure at the ResponseStatus level, but still gives you a chance to inspect the response.

So if you don’t handle that explicitly, you’re flying blind.

---

 Problem Statement

Let’s say you make a REST call to an external service that returns a 400 due to some client-side validation issue (e.g., missing field, invalid format).

In Postman, you'd see a well-structured JSON or XML body explaining the error.

But in PeopleCode?

If you don’t handle the response carefully, you'll just see that the SyncRequest() failed and your code crashes or logs a vague failure.

---

Solution: Don’t Just Use Try-Catch. Check ResponseStatus.

Make sure your routing tab User exception checkbox is checked.  ****IMPORTANT****

Here’s a reliable pattern:

Local Message &Response_Msg = %IntBroker.SyncRequest(&Request_Msg);



If &Response_Msg.ResponseStatus = %IB_Status_Success Then
   /* Success - parse the content */
   Local string &content = &Response_Msg.GetContentString();
   MessageBox(0, "", 0, 0, "Raw: " | &content);

Else
   /* Handle structured error */
   Local number &MsgSet = &Response_Msg.IBException.MessageSetNumber;
   Local number &MsgNum = &Response_Msg.IBException.MessageNumber;
   Local string &MsgEx = &Response_Msg.IBException.ToString();

   /* Extract raw fault response (JSON, XML, etc.) */
   Local string &rawFault = &Response_Msg.GetContentString();

   /* Log or display */
   MessageBox(0, "", 0, 0, "Error " | &MsgSet | "-" | &MsgNum | ": " | &MsgEx);
   MessageBox(0, "", 0, 0, "Raw Fault: " | &rawFault);
End-If;

---

Why GetContentString() Matters Even on Failure

The key insight: even when PeopleSoft sees the status as a failure, the response content (body) is still available.

This is critical when calling modern REST APIs. Most services return detailed JSON error bodies like:

{
  "error": {
    "code": "InvalidRequest",
    "message": "The field 'email' is required."
  }
}

Without grabbing GetContentString(), you lose all of this.

---

But Wait—Why Not Just Use Try-Catch?

Here’s the catch (no pun intended): Try-Catch in PeopleCode will not trap the HTTP 400-style errors unless the system throws an internal PeopleSoft exception (like a message catalog error, null pointer, etc.)

In the case of a REST response with a non-2xx status:

• SyncRequest() still returns a valid Message object

• You must inspect ResponseStatus manually

• Try-Catch won’t help unless something else breaks

---

 Suggested Practice

Always wrap your IB call like this:

1. Make the request

2. Check ResponseStatus

3. Use GetContentString() even on failure

4. Log or parse the error for better diagnostics

5. Use IBException to catch IB-side errors

---

 Bonus Tip: Log to a Custom Table

Instead of just using MessageBox, you can log everything to a custom error log table, like so:

SQLExec("INSERT INTO PS_MYLOG_TBL (OPRID, LOGTIME, MSG, RAWFAULT) 
         VALUES (:1, %CurrentDateTimeIn, :2, :3)", 
         %OperatorId, &MsgEx, &rawFault);

---

Final Thoughts

If you're calling external APIs from PeopleSoft, expect failure. Not because your code is bad—but because that’s how real-world APIs work.

So don’t treat 400, 404, 500, etc. as fatal errors. Treat them as data. Read the response, log it, act on it.

And always remember: GetContentString() is your friend—even when the server isn't.

---

Let me know if you want to expand this with JSON parsing, XML fault extraction, or a reusable logging function.