“Real-time integration” is a buzzword that gets thrown around in almost every architecture review.
To a modern web developer, it means WebSockets, Server-Sent Events (SSE), or long-lived streaming connections. To a PeopleSoft administrator, it usually means “how quickly can we complete this synchronous request/response transaction?”
PeopleSoft Integration Broker expects a standard, short HTTPS exchange: a request comes in, a response goes out, and the connection closes immediately.
If your design depends on holding connections open, streaming data incrementally, or pushing server-initiated messages to a browser, Integration Broker is the wrong tool.
Two of the four root constraints make real-time streaming impossible in IB:
Let’s examine why these real-time patterns fail in Integration Broker, and how to build clean workarounds at the edge.
WebSockets keep a persistent, bidirectional TCP connection open between the client and the server. This is the industry standard for chat applications, live monitoring dashboards, and real-time collaboration.
The listening connector is designed to terminate the HTTP transaction as soon as the response is written. It has no upgrade handler, no way to retain the TCP socket, and no application thread model that would allow a service operation to stay alive across multiple asynchronous frame exchanges.
The outbound target connector is strictly transactional: it opens an HTTPS connection, sends a request, reads the response, and closes the connection. It does not maintain socket state, and there is no event loop in PeopleCode to listen for and handle inbound WebSocket frames.
Put a lightweight proxy service (written in Go, Node.js, or Python) in front of PeopleSoft:
SSE is a lightweight, one-way streaming protocol. The server keeps an HTTP response open and writes data chunks with a text/event-stream Content-Type as events happen.
An Integration Broker handler must build a response object and return it. The gateway then serializes it and closes the connection. There is no API in PeopleCode to flush a response buffer incrementally or hold a response open.
Even if you attempted to sleep in PeopleCode to delay returning, the web server or application server would hit a transaction timeout long before the client expects.
The outbound target connector reads the response stream to completion before returning. The PeopleCode handler only sees the data as a single, massive string after the connection closes. If the upstream stream runs indefinitely, the PeopleCode call will hang until it times out.
Handle the stream externally. Let an edge service subscribe to the SSE stream, extract the events, and post them individually to PeopleSoft via standard REST.
In long polling, the client requests data, and the server intentionally delays responding until new data is available or a timeout occurs. Once the client receives a response, it immediately opens a new request.
Long polling is a thread-killer for classic application servers. If you have 100 clients long polling, you must hold 100 active handler threads open.
PeopleSoft application servers have a fixed, relatively small pool of handler threads. Holding these threads open waiting for data shifts will quickly exhaust your server capacity, slowing down all other users and integrations.
If you are considering long polling, the actual requirement is usually “notify me when something changes.” Two better options:
Under Transfer-Encoding: chunked, a server can start sending response body chunks before it knows the total payload size. This is common for large reporting datasets or streaming AI responses.
Keep response sizes small by using date-range filters or pagination. If you must process massive streams, let an edge service download, split, and batch the files into PeopleSoft incrementally.
HTTP/2 server push allows a server to send resources to a client cache proactively. WebPush is the standard for pushing notifications to mobile devices and browsers.
Both require server-initiated push over persistent connections. Integration Broker only initiates outbound requests as a client; it cannot push to an unrequested client channel.
Run a dedicated notification service (like Firebase Cloud Messaging) externally, and have PeopleSoft call it via outbound REST when a notification needs to be sent.
When stakeholders insist on a streaming or real-time integration, ask these three questions to find out if you really need the extra infrastructure:
If the answer is still “we need sub-second, server-initiated streaming,” keep Integration Broker out of the hot path. Let a dedicated edge service terminate the connections, and use PeopleSoft solely as the transactional system of record behind it.
Chris Malek is a PeopleTools® Technical Consultant with over two decades of experience. He is available for consulting engagements.
Work with ChrisSWS turns SQL into production REST APIs — ready for AI, modern apps, and partner integrations. One install, unlimited potential.
A powerful PeopleSoft bolt-on that makes REST web services easy. You bring the SQL, SWS handles the rest.
Traditional PeopleSoft web services cost $3,600–$13,000 each to develop. SWS deploys production REST APIs in under 5 minutes through configuration alone.
Turn PeopleSoft data into clean REST APIs for AI integrations, modern applications, and vendor data feeds. Configuration-driven — no PeopleCode required.
Look up any record, field, page, or component, audit security, and monitor Integration Broker across every database — in seconds.
A web console built for the PeopleSoft community — operational monitoring, security auditing, and metadata browsing in one tool.
On-demand security and operational reports for your PeopleSoft environment — no client install required.
Research any PeopleSoft object and monitor system health from a single browser tab — no App Designer, no SQL.