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 ChrisPeopleSoft 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.
Contents
Intro to Data Encoding
In this section we will discuss the various ways to encode and decode data in PeopleCode. We will also show how we can use message and document objects to automatically decode and encode data. The encodings we will cover are:
- CSV
- JSON
- XML
There are two main ways to encode and decode data in PeopleSoft.
- Using
Messageobjects backed byRowsetsorDocuments - Using PeopleCode with the aid of a supporting class.
- Even if you go this route you still need a message object but it just acts as a shell that provides no functionality. The PeopleSoft system just needs a messages but you don’t really use the functionality.
There are pros and cons to each method. There is no “correct” answer. It all depends on what you are building and your requirements. Here is a high level hierarchy of the options of encoding and decoding data and the object hierarchy that is involved.
Message Object Encoding
Message objects that are backed by Rowsets, Records or Documents can be used to both encode and decode XML and JSON. Messages backed by Rowsets and Records are useful when you need to encode and decode messages that are based on tables and fields that match exactly the PeopleSoft format. This could be passing data between PeopleSoft systems or when the API client accepts and sends the PeopleSoft formats. If you deviate from this then you may want to use the PeopleCode method. This method produces and parses static messages. If your data changes “shape” based on certain data conditions, this can be a poor choice.
| Format | Decode Using Message Object | Encode Using Message Object |
|---|---|---|
| JSON | Static JSON Supported via Document | Static JSON Supported via Document |
| XML | Static XML Supported via Rowsets or Documents | Static XML Supported via Rowsets or Documents |
| CSV | Not Supported | Not Supported |
Messages Pros/Cons:
- (pro) - It will automatically encode and decode rowset and record objects
- (con) - Cannot mix and match rowset and non-rowset based message parts
- (pro) - If you want to encode all data in the PeopleSoft format then this is a great choice
- (con) - If you need to input or output a data fields that are NOT in the same “shape” as the PeopleSoft values this can be a poor choice.
If you keep reading you will see that I highly recommend staying away from the Document object type.
PeopleCode Encoding and Decoding
You can also use PeopleCode to get the raw input string into a service operation and then parse and decode the message using different PeopleCode classes for XML and JSON. If you need to produce XML or JSON then there are also PeopleCode classes for that. This option is a good fit when you need to accept or send data that is NOT in the PeopleSoft format and the values may not match the table and field values in PeopleSoft. Your PeopleCode can take the input and decode it to PeopleCode variables and update the required data. Alternatively, if you are producing some output you can take the PeopleSoft data and create an acceptable XML or JSON output that the client wants.
The PeopleCode option allows you to parse and create dynamic documents based on logic. Message objects cannot produce or parse dynamic data.
| Format | Decode Using PeopleCode | Encode Using PeopleCode |
|---|---|---|
| JSON | JSON Classes | JSON Classes |
| XML | XML Classes | XML Classes |
| CSV | File Layout object or split | File Layout Object or concatenation |
PeopleCode Pros/Cons
- (pro) - Can encode and decode dynamic content.
- (con) - More up-front development
- (pro) - If you need to accept or send data in a format that is in the format of another system this is a good choice.
- (pro) - Much more flexible. This allows you to respond to changes in requirements with changes in one place (PeopleCode) instead of several places (Fields, Record, Messages, Documents, etc)
- (pro) - If coded correctly, the PeopleCode can be self-documenting and the logic in one place instead of spread out over different PeopleSoft objects.
Here is a high level hierarchy of the PeopleCode classes you have at your disposal.
We will look at these in sections to follow.