An RPGers First Steps with JSON: Consuming JSON data with YAJL


In our previous article we focused on the use of the YAJL library (and specifically Scott Klement's RPG oriented implementation of it) to create a JSON document. This time we are going to focus on the use of YAJL to consume a JSON document and extract the data for use by an RPG program. The JSON we are going to be processing is a slightly simplified version of the Customer details document that we created in the previous article. The file looks like this:

(1)  { "Customers": [
(2)       { 
             "ID": 12345,
             "Name": "Paris",
             "Street": "Main Street",
             "City": "Jasontown",
             "State": "CA",
             "Zip": "12345"
(3)      { 
             "ID": 23456,
             "Name": "Rich",
           < ... data for multiple customer entries omitted ... >
            "Zip": "98765"
(4) ]

The document starts with an array named Customers. This is followed at (2) by the data for the first customer which begins with an opening "{". The individual elements (ID, Name, etc.) follow and are separated by commas. The final item for the first customer is terminated by a closing "}".

This document highlights an additional difference between XML and JSON that we didn't mention in the first part.  In XML we would be forced to name the repeating element (i.e. the customer data) in order to be able to group the related fields. JSON does not require names for everything, simply grouping items into an object as we have done here is sufficient.

That’s what the document looks like, but how do we process it?

Processing JSON with YAJL

YAJL provides two methods for processing JSON. The first is an event-driven parser that processes individual pieces of data as it encounters them. In this respect it’s somewhat similar to RPG's XML-SAX op-code.

The second method, and the one we use here, is the tree parser. This works on the document as a whole and allows you to basically reference data elements by name. You’ll see that when we look at the code.

The basic methodology that is used is to first load the "tree" with the entire JSON document, and then to obtain a node locator—an identifier or "key" if you want to think of it that way—for each level of the document you want to process. You then use that locator to drill down to the next level. There really is no RPG equivalent, but the effect is similar to if you did a serial READ of a file and then used data from that to CHAIN out to other data.

As you'll see, we'll begin by asking YAJL to supply us with the locator for the Customers element, and then use that to locate the nodes for the individual customer array elements. These will then be used to access the individual fields that make up customer data. It sounds a lot more complicated than it actually is, as you'll see when we look at the code.

As usual we begin by copying in the prototypes for the YAJL routines (A). Next come the definitions for our node locators (B). In order to make the code a little simpler to understand we have defined a separate node locator for each of the elements we will be processing. Each is defined as being like a yajl_val. These are actually pointers, but Scott wisely "masked" this to protect the pointer phobic. At (C) we define the data structure array that will hold the extracted data.

(A)   /copy yajl/qrpglesrc,yajl_h

      // Node locators
(B)    dcl-s  root           Like(yajl_val);
       dcl-s  addressNode    Like(yajl_val);
       dcl-s  customersNode  Like(yajl_val);
       dcl-s  customerNode   Like(yajl_val);

(C)    dcl-ds  customer  Dim(99)  Inz  Qualified;
         id       Zoned(5);
         name     Char(40);
         street   Char(40);
         city     Char(30);
         state    Char(2);
         zip      Char(5);

Jon Paris is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Susan Gantner is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.

comments powered by Disqus



2017 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

New and Improved XML-INTO

Namespace support makes the opcode a viable option

Authenticating on the Web

The finer points of OpenRPGUI, Part 1

The Microphone is Open

Add your voice: Should IBM i include open-source RPG tools?

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters