JSON Parsing Limitations in 8.53

Starting in PeopleTools 8.53, there is some support for JSON data processing via the the Documents Class API. However, it seems rather basic and rudimentary.

I was starting to write some code against some REST APIs on the web and ran into a major limitation with JSON processing in the current functionality as of 8.53.06.

It turns out that the JSON parsing in 8.53 assumes that the JSON has a root node similar to XML. For example, If the JSON returned from a web service looks like this it cannot be handled. There are data elements in the root.

{
    "firstname": "John",
    "lastname": "Doe",
    "number": 3,
    "time": "Fri, 25 Apr 2014 19:00:38 GMT"
}

The Document Class assumes you have something more like this. Note the inclusion of the “return” root node.

{
    "return": {
        "firstname": "John",
        "lastname": "Doe",
        "number": 3,
        "time": "Fri, 25 Apr 2014 19:00:49 GMT"
    }
}

I opened a case with Oracle support and there was some indication that there may be some fix in 8.54 for this. However, at the time of writing this article there was not a release date announced for that yet.

A Work Around

I came up with a prototype solution that I have not used in production yet. You only need to do this if the web service does not return a root object. Here is what the code example below is doing:

1. Call SyncRequest to get JSON back from web service.

   • Do not NOT call getDocument on the response as it will not parse correctly.
   • If the web service returned a root node, then you could use &resp.getDocument() to get access to the parsed document object.

2. Get the raw response data using the GetContentString method

3. Manually append the root element to the document using string concatenation

4. Manually create a document object referencing the Document you are mapping to.

5. Call the ParseJsonString method passing in the JSON string which we added the root node.

Function runRestTest1()
   Local Message &msg, &resp;
   &msg = CreateMessage(Operation.REST_TEST1_GET);
   &msg.URIResourceIndex = 3;

   &resp = %IntBroker.SyncRequest(&msg);


   Local string &jsonString1;
   &jsonString1 = &resp.GetContentString();
   &jsonString1 = "{" | Char(34) | "return" | Char(34) | ": " | &jsonString1 | " }";


   Local Document &docResponse;
   local boolean &b_ret;

   &docResponse = CreateDocument("REST_TEST", "REST_TEST2", "V1");

   &b_ret = &docResponse.ParseJsonString(&jsonString1, False);

   /* do something useful with response */

   &docResponse = Null;

End-Function;

Wish List and Additional Bugs

I would really like to see the ability to parse JSON similar to the XMLDoc Class. With that class, you can parse XML dynamically. With the “Document Class” API, you have to know the data structure up front and configure it in the setup table. This is less than ideal as an API could change or return variable structures depending on different conditions. In these variable cases, the processing code may need to parse and respond in different ways.

Additionally, I am finding that the Document class is very buggy.

• I would change one element and press save and the save would change other elements
• I tried to embed one document in another and did not produce the correct node names when it rendered to JSON.
• I had an “invalid document” message while building a document and the whole document that I spent 30 minutes settting up was completely gone
• I was able to crash the whole application server if you had a node value that collided with a reserve word. The UI did not prevent me from creating node names that were reserved.
• If your element of type string it would not parse correctly. For example, if one of the values returned from the API look like this, "firstname":"John" it would actually parse out like this "firstname":"JJohn" (note the added J) if that element was of type string. What the HECK! I have no idea why.

I am starting to see why the Campus Solutions has a JSON parser written in pure PeopleCode SCC_COMMON:JSON