The PeopleSoftServiceListeningConnector is used to support SOAP. The connector URL is:
https://host:port/PSIGW/PeopleSoftServiceListeningConnectorIf you are NOT using SOAP do not submit messages to this endpoint.
The parameters for the connector as the same as the HttpListeningConnector with the following exception for the name of the service operation.
SOAPAction:<External_alias_name>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.
POST https://ib.cedarhillsgroup.com/PSIGW/PeopleSoftServiceListeningConnector?Operation=getStudent.v1&To=PSFT_CS&From=VENDOR_X_NODE HTTP/1.1
<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>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.
SOAPAction: http://peoplesoft.com/OperationName/RequestingNode/Password/DestinationNodeTo, From, Operation and Password parameters as the HTTPListeningConnectorSo if the listener finds a parameter in one of those it will stop looking. So SOAP Action will win.
http://host/PSIGW/PeopleSoftServiceListeningConnector?Operation=GetSchema&xsd=SERVICE_OPERATION.VERSIONhttp://host/PSIGW/PeopleSoftServiceListeningConnector?Operation=GetWSDL&wsdl=SERVICE_OPERATION.VERSIONhttp://host/PSIGW/PeopleSoftServiceListeningConnector?Operation=GetWSILIf you have a shared integration gateway that serves many PeopleSoft databases each with a unique node name you can use these.
http://host/PSIGW/PeopleSoftServiceListeningConnector/<REMOTENODE>/<OperationName>.<version>.xsdhttp://host/PSIGW/PeopleSoftServiceListeningConnector/<REMOTENODE>/<OperationName>.<version>.wsdlhttp://host/PSIGW/PeopleSoftServiceListeningConnector/<REMOTENODE>/inspection.wsilFor 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. 😕
If you do not have a shared gateway and you don’t have a NODE representing your external client application then this may work.
<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><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.
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.
SOAPAction: #OperationName#RequestingNode#NodePassword#DestinationNodeSOAPAction: http://peoplesoft.com/OperationName/RequestingNode/Password/DestinationNodeBecause 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.
Also see the PeopleSoftServiceListeningConnector for more information on passing values.
Here is an example:
<?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>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>Note: For non-wssecurity implementation the tags should appear as follows:
<Username>PSCR </Username>
<Password>PSCR</Password>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> Response
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 s a PeopleTools® Technical Consultant with over two decades of experience working on PeopleSoft enterprise software projects. He is available for consulting engagements.
Work with ChrisIntroducing 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.