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.
We introduced the Message object in the Terminology Section. Messages are an integral part of a service operation. They hold a pointer to the “payload” of the message for both the request and response. Often this is XML but it can be other encodings. A message is required on every service operation even if you are not using the full depth of functionality available in that object. You can make your messages an integral part of your service operation providing the encoding and decoding of data or have them as nothing but a “shell” and your handler PeopleCode can do all of the work. When integrating with non-PeopleSoft systems, I often just use “shell” (nonrowset) messages and do all the encoding and decoding in PeopleCode.
Messages are defined here:
A message object has a “type” defined when you create it. It cannot be changed later. Each message type has a different use case and different functionality. Additionally, the PeopleCode classes that you use to interact with the message in your handler will changed based on the type chosen. There are pros and cons of each message type and each has it’s own use case.
records and rowset objects.
In the bullets above, I nested the “part” types under the container type. This is because a container is comprised of one or more “parts”. A “part” is not tied directed to a service operation. It is sort of like a building block.
In the sections to come we will look at how we can use these different types to encode and decode data.