The PeopleSoftServiceListeningConnector is the integration gateway endpoint that handles SOAP traffic for PeopleSoft Integration Broker. It accepts both SOAP 1.1 and SOAP 1.2 requests, and it is the only PSIGW endpoint that fronts WSDL-published service operations.
If you are NOT using SOAP, do not submit messages to this endpoint — use the HttpListeningConnector or the RestListeningConnector instead.
The URL is:
https://host:port/PSIGW/PeopleSoftServiceListeningConnectorThe endpoint supports two URL styles for parameter passing:
https://host:port/PSIGW/PeopleSoftServiceListeningConnector?Operation=<OperationName>&To=<ReceiverNode>&From=<SenderNode>&OperationType=<sync|async|ping>https://host:port/PSIGW/PeopleSoftServiceListeningConnector/<REMOTENODE>/<OperationName>.<version>.xsdThe parameters are the same as the HttpListeningConnector — read that page for the canonical definitions. For convenience, the parameters this connector understands are:
Operation / OperationName (required) — the service operation external alias, case-sensitive.From (required) — the node defined to represent the client application.To — the PeopleSoft node name that is the target of the message.Password — the node password on the From node, if one is configured.OperationType — sync, async, or ping.ExternalMessageID — duplicate-suppression key. Max 70 characters and must be unique.NonRepudiation — Y or N.OrigUser, OrigNode, OrigProcess, OrigTimeStamp — original-sender metadata when messages cross multiple nodes.FinalDestination — the final node when messages cross multiple nodes.SubQueue — used for asynchronous messages on partitioned queues.MessageName, MessageVersion — present for backward compatibility.Oracle’s documentation is vague on precedence, but in my testing the connector evaluates parameters in this order and stops at the first one it finds:
SOAPAction HTTP header (when in the encoded http://peoplesoft.com/... form — see below).To, From, Operation, Password).In other words, when SOAPAction is populated in the encoded form, IB takes the IBInfo from SOAPAction and ignores HTTP headers and the query string for those values.
I found in my testing that passing parameters in the query string is the most reliable for this connector. You can pass the node Password in the query string. Passing it as an HTTP header does not seem to work here, even though it does for the HttpListeningConnector.
The SOAPAction header has historically been passed in several different forms. Pick the one that matches your PeopleTools version and how much routing metadata you want to pack into it.
SOAPAction: <External_alias_name>SOAPAction: #OperationName#RequestingNode#NodePassword#DestinationNodeSOAPAction: http://peoplesoft.com/OperationName/RequestingNode/Password/DestinationNodeSOAPAction: http://peoplesoft.com/PURCHASE_ORDER/VENDOR_X_NODE/PSFT_PASS/PSFT_NODEaction lives on the Content-Type header, not in a separate SOAPAction header):
Content-Type: application/soap+xml; action=<External_alias_name>If you submit an invalid format you will see a message like:
SOAPAction is of invalid format: SOAPAction should be either rpc/operationName or document/operationName
There are two ways to ask the gateway for service contracts — a query-string form and a path form. The path form is the way to disambiguate when a single gateway fronts multiple PeopleSoft databases, each with its own node name.
Query-string form:
https://host/PSIGW/PeopleSoftServiceListeningConnector?Operation=GetSchema&xsd=SERVICE_OPERATION.VERSIONhttps://host/PSIGW/PeopleSoftServiceListeningConnector?Operation=GetWSDL&wsdl=SERVICE_OPERATION.VERSIONhttps://host/PSIGW/PeopleSoftServiceListeningConnector?Operation=GetWSILPath form (use when a shared gateway serves many PeopleSoft databases, each with a unique node name):
https://host/PSIGW/PeopleSoftServiceListeningConnector/<REMOTENODE>/<OperationName>.<version>.xsdhttps://host/PSIGW/PeopleSoftServiceListeningConnector/<REMOTENODE>/<OperationName>.<version>.wsdlhttps://host/PSIGW/PeopleSoftServiceListeningConnector/<REMOTENODE>/inspection.wsilA bare GET against the endpoint will not deliver a SOAP request, but it will surface the gateway status page and prove that name resolution, TLS, and the web-server path are all healthy.
curl <https://ib.cedarhillsgroup.com/PSIGW/PeopleSoftServiceListeningConnector>You can also pull the inspection document or any published contract directly with curl. These are useful diagnostic steps that don’t require building a full SOAP body.
WSIL (lists every published service operation visible on this gateway):
curl '<https://ib.cedarhillsgroup.com/PSIGW/PeopleSoftServiceListeningConnector?Operation=GetWSIL>'WSDL for a specific service operation:
curl '<https://ib.cedarhillsgroup.com/PSIGW/PeopleSoftServiceListeningConnector?Operation=GetWSDL&wsdl=CHG_SYNC_UTEST.v1>'XSD schema for a specific service operation:
curl '<https://ib.cedarhillsgroup.com/PSIGW/PeopleSoftServiceListeningConnector?Operation=GetSchema&xsd=CHG_SYNC_UTEST.v1>'If WSIL returns an empty document, none of the service operations on the target database are flagged “Provide Web Service” — the gateway is fine, the operations just aren’t published.
For SOAP-based services submitted to https://host:port/PSIGW/PeopleSoftServiceListeningConnector the authentication story is different from both REST and a normal HTTP POST.
You can reference the PeopleBooks section Understanding WS-Security but it is still not very clear.
PeopleSoft Integration Broker supports three variants of the WS-Security UsernameToken on inbound SOAP requests:
XML Signature and XML Encryption are fully functional for the UsernameToken section of the SOAP header, but not necessarily for the rest of the SOAP envelope.
https:// for production.If you do not have a shared gateway and you don’t have a node representing your external client application, then this approach can work:
CLIENT_X_USER, password secret123.<soapenv:Header xmlns:soapenv="<http://schemas.xmlsoap.org/soap/envelope/>">
<wsse:Security soap:mustUnderstand="1"
xmlns:soap="<http://schemas.xmlsoap.org/wsdl/soap/>"
xmlns:wsse="<http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd>">
<wsse:UsernameToken>
<wsse:Username>CLIENT_X_USER</wsse:Username>
<wsse:Password>secret123</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>In this case the service operation itself would specify the user name and password requirement.
If there is a node in the configuration representing the external client, you have to pass a SOAPAction HTTP header in one of the encoded formats described in SOAPAction Header Formats above.
Because third-party systems do not understand the concept of a node as defined and used within the context of PeopleSoft systems, PeopleSoft assigns transactions that have no node specified to a PeopleSoft-delivered ANONYMOUS node.
The PeopleSoft system first checks the SOAP message header for an external user name and password set programmatically.
OPRID) and password, it uses the Default User ID set on the Node Definitions page on the remote ANONYMOUS node definition.<wsse:Password> element is not provided or the username is not a valid user, the IB falls back to the same default user ID on the ANONYMOUS node as the security context.Why you should care: the ANONYMOUS node’s Default User ID becomes the effective identity for unauthenticated requests. If that user has broad permissions, you have effectively published your services to the world. Always:
ANONYMOUS Default User ID to a least-privilege account.ANONYMOUS default user holds.Two open research questions I still have not pinned down:
ANONYMOUS node has full security?A complete WS-Security header looks like this:
<?xml version="1.0"?>
<soapenv:Envelope
xmlns:soapenc="<http://schemas.xmlsoap.org/soap/encoding/>"
xmlns:soapenv="<http://schemas.xmlsoap.org/soap/envelope/>"
xmlns:wsa="<http://schemas.xmlsoap.org/ws/2003/03/addressing/>"
xmlns:xsd="<http://www.w3.org/2001/XMLSchema/>"
xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance/>">
<soapenv:Header xmlns:soapenv="<http://schemas.xmlsoap.org/soap/envelope/>">
<wsse:Security soap:mustUnderstand="1"
xmlns:soap="<http://schemas.xmlsoap.org/wsdl/soap/>"
xmlns:wsse="<http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd>">
<wsse:UsernameToken>
<wsse:Username>PSCR</wsse:Username>
<wsse:Password>PSCR</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
<SOAP-ENV:Body>
<!-- payload -->
</SOAP-ENV:Body>
</soapenv:Envelope>For non-WS-Security implementations the tags appear as follows:
<Username>PSCR</Username>
<Password>PSCR</Password>A full SOAP 1.1 POST with the node password passed in the query string looks like this:
POST <https://ib.cedarhillsgroup.com/PSIGW/PeopleSoftServiceListeningConnector?Operation=getStudent.v1&To=PSFT_CS&From=VENDOR_X_NODE> HTTP/1.1
SOAPAction: getStudent.v1
Content-Type: text/xml
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="<http://schemas.xmlsoap.org/soap/envelope/>"
xmlns:ns1="<http://soap.avowsystems.com/studentcheck/GenericStudentCheck>">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<ns1:getStudent>
<security>
<auth>
<id>CMALKE</id>
<token>buga-boo</token>
</auth>
<timestamp>2018-05-23T12:42:01-07:00</timestamp>
</security>
<studentMatch>
<firstName>John</firstName>
<lastName>Smith</lastName>
</studentMatch>
</ns1:getStudent>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>A more typical POST against a CHG-style test operation with WS-Security in the header:
POST <https://ib.cedarhillgroup.com/PSIGW/PeopleSoftServiceListeningConnector> HTTP/1.1
SoapAction: CHG_SYNC_UTEST.v1
To: PSFT_HR
Content-Type: text/xml
From: CHG_EXTERNAL_CLIENT
Password: PASSWORD1
<?xml version="1.0"?>
<soapenv:Envelope
xmlns:soapenv="<http://schemas.xmlsoap.org/soap/envelope/>"
xmlns:ser="<http://xmlns.oracle.com/Enterprise/HCM/services>">
<soapenv:Header xmlns:soapenv="<http://schemas.xmlsoap.org/soap/envelope/>">
<wsse:Security soap:mustUnderstand="1"
xmlns:soap="<http://schemas.xmlsoap.org/wsdl/soap/>"
xmlns:wsse="<http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd>">
<wsse:UsernameToken wsu:Id="UsernameToken-1"
xmlns:wsu="<http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd>">
<wsse:Username>0522004</wsse:Username>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
<soapenv:Body>
<ser:request>
<ser:inbound1>123</ser:inbound1>
</ser:request>
</soapenv:Body>
</soapenv:Envelope>Errors are always returned as SOAP faults — even when the underlying problem is an authorization or routing issue, not a SOAP-level fault. The body wraps an IBResponse element inside the fault <detail>:
HTTP/1.1 500 Internal Server Error
Connection: close
Date: Sat, 12 Oct 2019 15:53:17 GMT
Content-Length: 627
Content-Type: text/xml; charset=UTF-8
<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="<http://schemas.xmlsoap.org/soap/envelope/>">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>null</faultstring>
<detail>
<IBResponse type="error" xmlns="">
<DefaultTitle>Integration Broker Response</DefaultTitle>
<StatusCode>20</StatusCode>
<MessageID>536</MessageID>
<DefaultMessage>
<![CDATA[User PS not authorized to invoke Service Operation CHG_SYNC_UTEST. (158,536)]]>
</DefaultMessage>
<MessageParameters>
<Parameter><![CDATA[PS]]></Parameter>
<Parameter><![CDATA[CHG_SYNC_UTEST]]></Parameter>
</MessageParameters>
</IBResponse>
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>Chris Malek is a PeopleTools® Technical Consultant with over two decades of experience working on PeopleSoft enterprise software projects. 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.