At its core, PeopleSoft Integration Broker is built for a simpler time: text-based payloads (XML and JSON) flowing over HTTP/1.1 in a synchronous request/response loop.
If an integration partner or vendor starts asking you to connect via modern binary protocols, HTTP/2, streaming RPC, or GraphQL, you are going to find out quickly that IB is out of its depth.
Let’s look at the specific binary and RPC protocols that Integration Broker cannot handle, and what patterns we can use to bridge them at the network edge.
The relevant root constraints for this page:
GraphQL adds a third issue: even though its transport is HTTP/1.1 and its payloads are JSON, its server-side resolver model does not map cleanly to PeopleSoft’s service operation model.
gRPC is Google’s modern, high-performance RPC framework. It runs exclusively on HTTP/2, uses Protocol Buffers by default, and supports unary (request/reply) calls as well as client-streaming, server-streaming, and bidirectional streaming. It is the default choice in cloud-native and microservices environments where teams want strict contracts and low-latency, service-to-service communication.
We hit two absolute blockers here, either of which is sufficient to kill the idea:
.proto files into Application Packages, and no mechanism to surface a typed message object to PeopleCode.The outbound HTTP target connector emits standard HTTP/1.1 requests and reads plain text response bodies. There is no gRPC client library, no stub generation, and no streaming event loop in PeopleCode.
Instead of trying to force PeopleSoft to speak gRPC, we put a translation adapter in front of it. Common options include:
.proto stub compilation, establishes the gRPC channel, translates JSON to binary, handles stream buffering, and relays responses.In every version of this setup, PeopleSoft is isolated from the gRPC layer and only sees plain JSON over HTTPS.
These are all binary serialization formats. They solve different problems—Protobuf is for structured schemas, MessagePack is a compact binary representation of JSON, Avro is common in Kafka/Hadoop ecosystems, CBOR is for IoT, and Thrift is a legacy RPC framework—but they all fail in PeopleSoft for the same reason: the wire format is raw bytes, not text.
PeopleCode request and response objects are designed around strings. The target and listening connectors decode the body as text using a character encoding (like UTF-8). There is no native decoder for Protobuf integers, MessagePack type tags, Avro schema-driven binary, or Thrift compact data. Even if you bypassed the connector and read the raw bytes into a Java block in PeopleCode, there are no built-in libraries to parse them.
Translate these formats outside PeopleSoft. If an upstream system publishes Avro-encoded records, let a broker consumer or middleware decode it and post JSON to PeopleSoft. If a downstream system expects MessagePack, have PeopleSoft emit JSON and let a proxy re-encode it at the edge.
The translation overhead is real, but for the business transactions PeopleSoft handles (which are measured in thousands per hour, not millions of telemetries per second), the CPU cost is negligible.
GraphQL is a query language for APIs. Instead of hitting different URLs for different resources, clients send a query string—usually via JSON over HTTPS POST to a single endpoint—describing exactly the fields and nested objects they want. The server resolves the query against a typed schema.
The transport itself is fine (it is just JSON over HTTPS POST). The mismatch is at the model level:
Technically, PeopleSoft can use HttpTargetConnector to POST a GraphQL query string as part of a JSON body and receive a JSON response.
This works fine for a handful of simple, static queries. But as queries grow, use fragments, or need dynamic variables, managing query strings in PeopleCode gets messy very quickly. You lose all the benefits of schema validation and type safety.
Build a GraphQL gateway (such as Apollo Server, GraphQL Yoga, or a custom Node/Go gateway) in front of PeopleSoft:
It is reasonable to ask if translating everything to REST/JSON at the edge defeats the purpose of using gRPC or GraphQL in the first place.
In practice, the translation cost is trivial compared to the development and maintenance cost of trying to force these protocols into PeopleCode.
Here is why this separation is the cleanest design:
Let PeopleSoft do what it is good at—acting as a stable database system of record. Let an external gateway Terminate the protocols.
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.