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.Read More & Purchase
HttpListeningConnector has been the work horse for 3rd party integrations with PeopleSoft for years. You can use it to post both asynchronous and synchronous service operations. This is the connector you use if you are NOT using SOAP and NOT using REST.
Then general characteristics of the listener:
HttpListeningConnectoraccepts all data via an
HttpListeningConnectoralmost always returns an HTTP status code of 200 (success) even when there is an error. There will generally always be an XML response on the HTTP body, so it is a good idea to actually log that and also parse it for error messages. This can be confusing as heck so be warned that the HTTP status codes coming from the PSIGW
The high level steps to integrate with this connector are as follows. There is a full example in Synchronous HTTP Post to PeopleSoft Integration Broker
OPRIDthat will have access to only the service operations your client will invoke. I like to use a naming standard of
nodein your PeopleSoft database that will represent your client application. Create a new node for each application. Do not re-use an existing node. Setup a “node password”.
You have to submit different parameters to this connector.
The most use parameters are:
OperationName(required): External Alias. This is the service operation name and it is case-sensitive. If you are using a “from node” make sure the routing for your node matches what you are submitting. This is a common mistake.
From(required): The node defined to represent the client application.
To(required): The PeopleSoft node name that is the target of the message.
Password: If you have defined a node password on the
Fromnode that value is passed here. It is NOT encoded in any way. Do not include this if there is no node password.
ExternalMessageID: This allows you to pass an ID of the external messaging system. This might be better to pass in the payload.
There are some other parameters that are not used very often.
OrigUser: When messages pass across different nodes, the original user who sent the request may need to be passed as meta-data. This can be accessed in the handler using the
OrigNode: When messages pass across different nodes, the original node who sent the request may need to be passed as meta-data. This can be accessed in the handler using the
OrigProcess: When messages pass across different nodes, the original process who send the request may need to be passed as meta-data. This can be accessed in the handler using the
OrigTimeStamp: When messages pass across different nodes, the original time stamp of the request may need to be passed as meta-data. This can be accessed in the handler using the
FinalDestination: When messages pass across different nodes, the final node that this should go to may need to be passed as meta-data. This can be accessed in the handler using the
SubQueue: This applies to asynchronous message. This can be used to set a subqueue if the queue is partitioned.
NonRepudiation: (Y|N) - Allows you to set the non-repudiation flag. Consult Peoplebooks. I have never seen this used.
OperationType: (sync|async|ping) These allow you to tell what type of operation it is. I have never seen this used.
Here is an HTTP example of submitting a service operation passing all the parameters using HTTP Header.
POST https://ib.cedarhillsgroup.com/PSIGW/HttpListeningConnector HTTP/1.1 OperationName: CHG_SYNC_TEST.v1 Content-Type: text/xml From: CHG_TEST_NODE To: PSFT_CS Password: vase-lawless-realty <?xml version="1.0"?> <helloworld/>
You can also pass the parameters using URL query string. That HTTP example would look like this.
POST https://nusmsg.soar.cci.nu.edu/PSIGW/HttpListeningConnector?Operation=CHG_SYNC_TEST.v1&From=CHG_TEST_NODE&To=PSFT_CS&%20Password=vase-lawless-realty HTTP/1.1 Content-Type: text/xml Accept: */* <?xml version="1.0"?> <helloworld/>
You can wrap your message in a special XML message called the
IBRequest. This is very similar to SOAP. If PeopleSoft sees this wrapper it will pull all the parameters out of that wrapper. I don’t recommend doing this but it is possible for strange edge cases.
POST https://ib.cedarhillsgroup.com/PSIGW/HttpListeningConnector HTTP/1.1 Content-Type: text/xml <?xml version="1.0"?> <IBRequest> <From> <RequestingNode>CHG_TEST_NODE</RequestingNode> <Password>vase-lawless-realty</Password> </From> <ExternalOperationName>CHG_SYNC_TEST.v1</ExternalOperationName> <OperationType>sync</OperationType> <To> <DestinationNode>PSFT_CS</DestinationNode> </To> <ContentSections> <ContentSection> <Headers> <version>VERSION_1</version> </Headers> <Data><![CDATA[<?xml version="1.0"?> <helloworld/>]]></Data> </ContentSection> </ContentSections> </IBRequest>
Before you can test any integration with this connector you should check if your integration client can connect. If you know your integration broker server hostname then you would perform a test like this:
Standard HTTP GET
The response you are looking for would look something like the following HTTP Response.
Even though the response says
Integration Gateway failed while processing the message which looks like error it is NOT. If you are just testing connectivity then the message proves you are hitting the PeopleSoft integration broker. Since we did NOT sent a POST request with a body message, the listener stopped the requested and returned an error. However, for just testing connectivity that message means you have connected.
HTTP/1.1 200 OK connection: close content-length: 365 content-type: text/xml; charset=UTF-8 date: Sun, 22 May 2022 13:49:30 GMT strict-transport-security: max-age=31536000; includeSubDomains; preload <?xml version="1.0"?> <IBResponse type="error"> <DefaultTitle>Integration Broker Response</DefaultTitle> <StatusCode>20</StatusCode> <MessageSet>158</MessageSet> <MessageID>10403</MessageID> <DefaultMessage> Integration Gateway failed while processing the message. </DefaultMessage> <MessageParameters> <Parameter>ContentSection</Parameter> </MessageParameters> </IBResponse>