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.

HTTP Post to PeopleSoft Integration Broker Asynchronous

This is NOT a REST based service.

In this post, I will lay out a simple example that will show how to use an HTTP client to post to the PeopleSoft Integration Broker HttpListeningConnector. PeopleSoft will process the message Asynchronously. This will be a trivial example that will hopefully help someone jump start an integration project.

In the example laid out below:

We are posting to an asynchronous Service operation in PeopleSoft
We are not actually doing anything with the data in PeopleSoft other than echo it to an email in-box

Pre-Reqs

There are a few pre-reqs that you must have configured for this example to work. Those are documented at Prerequisite Setup

The PeopleTools Setup

First let’s setup the PeopleSoft side.

Create a New PeopleSoft Message Object

Now we need a PeopleSoft message object that will represent the XML that the client program will post.

PeopleTools > Integration Broker > Integration Setup > Messages

Message Attribute	Value
Name	CHG_GENERIC
Version	V1
Type	Nonrowset-based

Create a new Service

In this example, we create a new service.

PeopleTools > Integration Broker > Integration Setup > Service

Service Attribute	Value
Name	CHG_TEST

Create the Handler PeopleCode

Now we need to create some PeopleCode that will run when a new message is posted to the integration broker for this Service Operation.

Create an Application Package and Class with the following : CHG_ASYNC_TEST:asyncTest
Paste in the following code into the Class:

import PS_PT:Integration:INotificationHandler;


class asyncTest implements PS_PT:Integration:INotificationHandler
   method OnNotify(&_MSG As Message);
end-class;

method OnNotify
   /+ &_MSG as Message +/
   /+ Extends/implements PS_PT:Integration:INotificationHandler.OnNotify +/
   /* Variable Declaration */
   
   
   Local XmlDoc &doc;
   &doc = &_MSG.GetXmlDoc();
   
   Local XmlNode &xrootNode;;
   
   &xrootNode = &doc.DocumentElement;
   
   Local integer &ucount;
   SQLExec("SELECT COUNT(*) FROM PSOPRDEFN WHERE ACCTLOCK = 0 ", &ucount);
   

end-method;

This is a really dumb example that does nothing useful. However, what we can see is we can:

Get access to the XML submitted by the client using the &_MSG.GetXmlDoc(); method.
Run arbitrary PeopleCode like SQLExecs or whatever.
Notice that the OnNotify does NOT return anything.

Setup new Service Operation

Now we need to setup the actual Service Operation. There are several steps here.

PeopleTools > Integration Broker > Service Operation Monitor > Administration > Domain Status

Service Operation Attribute	Value
Name	CHG_ASYNC_TEST
Type	Asynchronous - One Way
Version	V1
Active	Checked
Message Version	CHG_GENERIC.V1
Queue Name	IB_EXAMPLES (or create a new queue )

Click on the “Service Operation Security” link and add the permission we created in the pre-req section.

Now we need to hook in the CHG_ASYNC_TEST:asyncTest application class to execute when a service operation is posted. We do this on the Handler tab of the Service Operation.

Service Operation Handler Attribute	Value
Handler Name	Test
Handler Type	On Notify
Implementation	Application Class
Description	Tester
Package Name	CHG_ASYNC_TEST
Path	:
Class ID	asyncTest
Method	OnNotify

Now we need to setup the routing to make this node able to send Service Operations.

Service Operation Routing Attribute	Value
routing name	CHG_ASYNC_TEST
sender node	CHG_TEST_NODE
Receiver Node	PSFT_CS (whatever your default local node is )
External Alias	CHG_ASYNC_TEST.V1
Active	Checked

Now our PeopleTools system should be ready to receive messages from some HTTP client.

Submitting data

Now we can use an HTTP Client to invoke the Service operation. Remember that this is an asynchronous service. This means that the actualy onNotify handler is actually handled at some point in the future. What we get back is a TransactionID in both the response payload and a response HTTP header. This is the ID that can be used to lookup the message determine what the handler did and if it ran.

Here is an example request with some non-important XML payload. We are using HTTP syntax here.

POST https://ib.cedarhilllsgroup.com/PSIGW/HttpListeningConnector HTTP/1.1
OperationName: CHG_ASYNC_TEST.v1
Content-Type: text/xml
From: CHG_TEST_NODE
To: PSFT_CS
Password: vase-lawless-realty
Accept: */*
Host: ib.cedarhilllsgroup.com
accept-encoding: gzip, deflate
content-length: 35

<?xml version="1.0"?>
<helloworld/>

Response:

HTTP/1.1 200 OK
status: 200
Date: Tue, 26 Feb 2019 22:53:39 GMT
Content-Length: 213
Content-Type: text/xml; charset=UTF-8
TransactionID: 5b3efd54-3a19-11e9-bcb4-fb3330b2eab1

<?xml version="1.0"?>
<IBResponse type = "success">
    <DefaultTitle>Integration Broker Response</DefaultTitle>
    <StatusCode>0</StatusCode>
    <TransactionID>5b3efd54-3a19-11e9-bcb4-fb3330b2eab1</TransactionID>
</IBResponse>

Viewing Result in PeopleSoft

You can lookup the transaction ID in the IB monitor to look at the status. You can see in the “subscription contract” grid that the OnNotify handler ran to success. This happened at some later point after the client posted. This could be a matter of seconds or hours or days depending on what is happening in the system.