In the previous post on Java and PeopleCode, we looked at mapping datatypes between Java and PeopleCode and discovered a fairly nasty bug along the way. This time around, we’ll take a look at using Java to work around PeopleTools issues.
This came up from a call that I was on recently. The customer is using a PeopleTools 8.1x based system and they are current on maintenance (PeopleTools 8.22 is the current release in the 8.1x codeline, and yes, the version should be 8.1.12. Don’t ask). They have been using Business Interlinks to call out to a 3rd party system over HTTP. For some strange reason the interlinks stopped functioning properly a little while ago, but no one has been able to figure out why.
I’ll explain more about Business Interlinks in a future post about the history of PeopleSoft integration technology, but the basic idea was to make it easier for people building integrations to divide the work between lower level code (Java, C++, etc.) and the higher level PeopleCode. Some of the delivered ones included things like integration with Vertex and Taxware, LDAP, and of course HTTP.
Since there had been a lot of time and energy that went into figuring out why the Business Interlinks weren’t working, an alternative was to just use something different to perform the HTTP access. A great java HTTP client library is available for free from the Apache Jakarta project.
Here’s some sample code of how to call this from PeopleCode. This example downloads the RSS feed from the Grey Sparling weblog and displays how many link items there are in the feed. Not very useful, but it gets the point across.
We begin by creating the HttpClient object. There are lots of different ways to configure this object. A common one would be to set a user name and password that a website might require. Here we just set a timeout parameter.
We then create an object that represents the HTTP GET method and tell it to follow re-directs (mainly as an example of something that you might want to do for configuring the method).
Then we execute the method. This is what actually goes out over the network and hits our server. One wrinkle here is that PeopleTools 8.1x does not have the notion of try/catch (this is in PeopleTools 8.4x though), so if there is an exception that the Java library throws, then we don’t have any good error handling in place. A common way of dealing with this is some wrapper code on the Java side that can provide the error status back as a return code instead of an exception.
Next we grab the body text (the RSS data, which is XML-based) and create an XMLDoc object with it. The XMLDoc is a built in PeopleCode object, so it’s convenient for doing XML parsing. Then we display the number of children nodes in the doc (technically we should be grabbing the actual link elements in the document for displaying the number of postings in the feed, but I’m cheating here).
That’s it. Fairly straightforward to do, even if it is a bit low level. To try this out you’ll want the commons-httpclient, commons-logging and commons-codec .jar files in your PSHOMEclass directory. The appserver only reads from this directory when starting up so you’ll need to bounce it in order to use these.
You’ll also want to take a look at the sample code that is provided with the library. They provide lots of examples of how to accomplish common tasks.