Author Info
Chris Malek

Chris Malek is a PeopleTools® Technical Consultant with two decades of experience working on PeopleSoft enterprise software projects. He is available for consulting engagements.

About Chris Work with Chris
Looking for pain-free PeopleSoft web services? 😀
PeopleSoft Simple Web Services (SWS)

Introducing a small but powerful PeopleSoft bolt-on that makes web services very easy. If you have a SQL statement, you can turn that into a web service in PeopleSoft in a few minutes.




The PeopleSoftServiceListeningConnector is used to support SOAP. The connector URL is:

  • https://host:port/PSIGW/PeopleSoftServiceListeningConnector

If you are NOT using SOAP do not submit messages to this endpoint.

Discombobulated Notes Follow

Parameters to Listener

The parameters for the connector as the same as the HttpListeningConnector with the following exception for the name of the service operation.

  • For SOAP 1.1:
    • SOAPAction:<External_alias_name>
  • For SOAP 1.2
    • Content-type: application/soap+xml; action=<External_alias_name>

For this listening connector, I found in my testing that passing parameters in the query string seems to be best. Here is an example. You can also pass the node Password in the query string parameter. It does not seem to work with passing as a HTTP header.



Looking through oracle support documents you find vague references to how the parameters can be passed. I found a reference that the parameter processing order is the following.

  1. SOAPAction in this format SOAPAction:
  2. Headers (In my testing headers are ignored)
  3. Query String with the same To, From, Operation and Password parameters as the HTTPListeningConnector
  4. Path (but you can’t seem to pass to and from in the path)

So if the listener finds a parameter in one of those it will stop looking. So SOAP Action will win.

Getting Schemas/WSDL and WSIL

  • To get an XSD schema use this pattern: http://host/PSIGW/PeopleSoftServiceListeningConnector?Operation=GetSchema&xsd=SERVICE_OPERATION.VERSION
  • Use the following query format to get WSDL: http://host/PSIGW/PeopleSoftServiceListeningConnector?Operation=GetWSDL&wsdl=SERVICE_OPERATION.VERSION
  • Use the following query format to get WSIL: http://host/PSIGW/PeopleSoftServiceListeningConnector?Operation=GetWSIL

If you have a shared integration gateway that serves many PeopleSoft databases each with a unique node name you can use these.

  • To get an XSD schema use this pattern: http://host/PSIGW/PeopleSoftServiceListeningConnector/<REMOTENODE>/<OperationName>.<version>.xsd
  • Use the following path format to get WSDL: http://host/PSIGW/PeopleSoftServiceListeningConnector/<REMOTENODE>/<OperationName>.<version>.wsdl
  • Use the following path format to get WSIL: http://host/PSIGW/PeopleSoftServiceListeningConnector/<REMOTENODE>/inspection.wsil

SOAP Authentication

For SOAP based services submitted over https://host:port/PSIGW/PeopleSoftServiceListeningConnector the authentication is different that both REST and a normal HTTP Post.

You can reference the PeopleBooks Section: Understanding WS-Security but it is still not very clear. ­čśĽ

No External Node Involved

If you do not have a shared gateway and you don’t have a NODE representing your external client application then this may work.

  1. Create a PeopleSoft user name with a password and permission to service operation. USER: CLIENT_X_USER, Password: secret123
  2. Add that user name and password to the SOAP HEADER.
<soapenv:Header xmlns:soapenv="">;
    <wsse:Security soap:mustUnderstand="1" xmlns:soap="" xmlns:wsse="">;
        <wsse:Username>CLIENT_X_USER </wsse:Username>
  • In this case the service operation would have a user name and password required in the Service operation option.
  • If the <wsse:Password> element is not provided or is not a valid user then the IB will use the Default User ID on the ANONYMOUS node is used as the security context.
    • RESEARCH: Is this true? What happens if the anonymous node has full security?
    • RESEARCH: What if you do not include a password but the username is a high level account? does it just take it and run under that context? I hope not.

PeopleSoft Node and Password Involved

If there is a NODE in the configuration then you have to pass a SOAPAction HTTP Header that has encoded in it a special format.

  • Prior to tool 8.48:
    • SOAPAction: #OperationName#RequestingNode#NodePassword#DestinationNode
  • After 8.48:
    • SOAPAction:

Notes from Oracle Support

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 name and password set programmatically.
    • If none is found or if the system cannot validate the user ID (OPRID) password that was set programmatically, it uses the Default User ID set on the Node Definitions page on the remote Anonymous node definition.

Also see the PeopleSoftServiceListeningConnector for more information on passing values.

Example SOAP Header

Here is an example:

<?xml version="1.0"?>
    <wsse:Security soap:mustUnderstand="1" 
        <wsse:Username>PSCR </wsse:Username>

Note: For non-wssecurity implementation the tags should appear as follows:

<Username>PSCR </Username>

Additional Reading

Submitting SOAP Requests.

SoapAction: CHG_SYNC_UTEST.v1
Content-Type: text/xml
Password: PASSWORD1

<?xml version="1.0"?>
    <wsse:Security soap:mustUnderstand="1" 
      <wsse:UsernameToken wsu:Id="UsernameToken-1" 


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" ?>
        <IBResponse type="error" 
          <DefaultTitle>Integration Broker Response</DefaultTitle>
            <![CDATA[User PS not authorized to invoke Service Operation CHG_SYNC_UTEST. (158,536)]]>