If you work with PeopleSoft long enough, you’ll eventually have a vendor or an internal architect ask you to connect to a streaming API, subscribe to a Kafka topic, or open a WebSocket.
The short answer is: don’t try to force Integration Broker to do this natively.
PeopleSoft Integration Broker is highly effective for a specific, narrow class of integrations: synchronous HTTPS request/reply with XML or JSON, plus local-to-local asynchronous queues for staging inbound payloads or propagating data between PeopleSoft databases.
Outside that sweet spot, trying to use IB is either unsupported, extremely awkward, or requires a custom proxy service to bridge the gap.
In this chapter, I want to map out the architectural boundaries of Integration Broker. We’ll examine the four root constraints of its design, catalog what doesn’t work, and discuss how to design clean edge solutions that keep PeopleSoft stable.
Almost every integration failure I’ve had to clean up traces back to a developer trying to fight one of these four design constraints. Instead of memorizing a list of unsupported technologies, it is much more useful to understand these core limits:
When an architect asks if PeopleSoft can support a specific pattern, you can use this table to quickly find the root constraint and the recommended workaround:
| Pattern / Protocol | Root Constraint | Use Instead |
|---|---|---|
| WebSockets (Server or Client) | 1, 3 | Run a small sidecar service (Node.js, Go) to host the socket; have it push data into PeopleSoft via standard REST. |
| Server-Sent Events (SSE) | 1, 3 | Terminate the SSE stream in an external proxy; relay the events into PeopleSoft using standard REST or a staging-table queue. |
| HTTP Long Polling (as Server) | 1 | This pattern burns app server worker threads. Redesign using webhooks or standard client-side polling. |
| Chunked / Streaming Responses | 1, 3 | Integration Broker buffers full responses. If the client requires incremental data, terminate the call in a gateway proxy and stream from there. |
| gRPC (Server or Client) | 2, 3 | Use an API Gateway or Envoy proxy to translate gRPC calls into standard REST/JSON before they hit PeopleSoft. |
| Binary Serialization (Protobuf, Avro) | 2 | Translate to JSON in a sidecar or gateway before sending payload to PeopleSoft. |
| GraphQL (as Server) | 1, 2 (plus model mismatch) | Build a GraphQL gateway externally; let its resolvers make targeted REST/JSON calls to PeopleSoft. |
| Apache Kafka Consumer / Producer | 4 | Write a small bridge service (or use iPaaS) to consume from Kafka and write to PeopleSoft via REST. |
| Enterprise Brokers (RabbitMQ, NATS) | 4 | Same as Kafka: run a broker-side consumer to bridge messages to PeopleSoft REST endpoints. |
| Inbound API Rate Limiting | 1 (plus no throttling controls) | Put an API Gateway (like Kong or Apigee) in front of PeopleSoft to enforce rate limits and quotas. |
| Developer API Portal | 1 (plus no credential manager) | Use an API Gateway to handle authentication, API key issuance, and developer documentation. |
| Real-Time UI Feeds (Chat, Dashboards) | 1, 3 | Let an external service manage the persistent UI connections; query PeopleSoft only when state needs to be saved. |
In design meetings, pay close attention to the language being used. If you hear any of these phrases, it is a warning sign that you are trying to force Integration Broker into the wrong role:
The takeaway is simple: PeopleSoft should own the transactional data, not the protocol terminations. If an integration requires a modern protocol, terminate it at a gateway, sidecar, or broker consumer, and let that component call PeopleSoft over standard REST/JSON.
Lest this seem like a total indictment of the tool, there is a large class of integrations where Integration Broker is absolutely the right choice:
USER_PROFILE and PERSON_BASIC_SYNC are exactly what the internal publish/subscribe queue was designed to do.200 OK, and a separate async process processes the staging table. This is the gold standard for handling long-running work triggered by external HTTP calls.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.