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 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.
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.
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/DestinationNode
To
, 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.VERSION
http://host/PSIGW/PeopleSoftServiceListeningConnector?Operation=GetWSDL&wsdl=SERVICE_OPERATION.VERSION
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.
http://host/PSIGW/PeopleSoftServiceListeningConnector/<REMOTENODE>/<OperationName>.<version>.xsd
http://host/PSIGW/PeopleSoftServiceListeningConnector/<REMOTENODE>/<OperationName>.<version>.wsdl
http://host/PSIGW/PeopleSoftServiceListeningConnector/<REMOTENODE>/inspection.wsil
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. 😕
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#DestinationNode
SOAPAction: http://peoplesoft.com/OperationName/RequestingNode/Password/DestinationNode
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.
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>