DATA-INTO vs. YAJL Procedures

[mmayer4]

I prefer DATA-INTO over YAJL procedures simply because it seems like much less code and looks cleaner. Once the data structures are mapped, one line of code to parse it sure is nice.

Before I begin writing plenty of code, I figured I’d try to get some insight on if I should even try to use DATA-INTO in the case presented below.

I’m not sure if DATA-INTO can handle the JSON I might be presented with. It seems I will need to use both allowmissing=yes and allowextra=yes at the same time. I haven’t tried this yet. Also, it is possible I may receive empty objects in a response and other times it’s populated.

A portion of the JSON response looks like the following:

Code: Select all

	"surchargeOptions": {
            "surchargeOption": [
              {
                "label": {
                  "enUsLabel": "string",
                  "frCaLabel": "string"
                },
                "value": "string",
                "key": "key",
                "type": "type",
                "description": "desc",
                "surchargeAmount": 0,
                "editable": false,
                "mandatory": false
              }
            ]
          },
	"coverageOptions": {
            "coverageOption": [
              {}
            ]
          },
	etc, etc, etc

Notice the coverage option array contains an empty object. But, it may not always be empty. Will DATA-INTO choke on such a situation?

I’m pretty sure YAJL procedures will handle all of this, but that sure is plenty hardcoding of field names versus simple maintenance to a data structure to accommodate any vendor changes in the future.

Hoping I could get some insight here before I begin. Thoughts anyone?

[jonboy49]

Empty objects shouldn't present a problem. It is when the json represents an empty object by assigning it a null value that DATA-INTO has a problem.

As to allowmissing you really shouldn't need it. Use countprefix for the DS representing the object (or indeed for any item that can be omitted) and you don't need it. It is only required if you don't tell RPG how to notify you of the actual count of an element.

You'll find several examples of using this in my JSON articles https://authory.com/JonParisAndSusanGan ... ction=JSON

[mmayer4]

Jon, thanks so much for the input. Yes, I am familiar with the articles as your writings were a great help in getting me started with this project and being successful. Thanks so much for what you do! Please don’t stop doing it..lol..

What prompted my discussion is that DATA-INTO kept failing and I could never figure out why. I was certain my data structures matched. How I managed a work around was to first read the response section of the JSON using YAJL before I tried DATA-INTO. If the response status was not successful, I did not run the DATA-INTO (because the data requested wasn’t going to be there). If the response was successful the DATA-INTO worked like a champ.

You have just told me why it kept failing! On a not successful response, the rest of the JSON fields did contain a value of null. Is there a way to handle null? I haven't been successful finding anything on the topic yet.

Here’s a sample of the JSON that caused my issues.

Code: Select all

{
  "requestorDealer": null,
  "vin": null,
  "vehicleMake": null,
  "vehicleModel": null,
  "vehicleYear": null,
  "contractList": null,
  "standardResponse": {
    "status": false,
    "responseCode": "404",
    "responseDescription": "contract not found"
  }
}

[jonboy49]

Today may be your lucky day!

In response to a similar issue Scott has _literally_ just added a new %PARSER option called "skip_nulls". When enabled it will simply cause any element with a null value to not be reported to RPG. You can read about it in this thread viewtopic.php?t=170

If you implement this then you can use countprefix against the element and test for > 0 to see if it was present. You will of course also have to take this change in behaviour into account if you have any elements for which null is actually a valid response.

[mmayer4]

OMG Awesome! If it were not for Scott and other IBM Champions like yourself, this ole dinosaur who cut his teeth on the IBM System 3 Model 10 on up through to the Power i (along with many other dinosaurs) would surely be extinct. I appreciate all y'all do!!!

[Scott Klement]

Please let us know how it works out for you, mmayer4!

The skip_nulls feature is brand new, so any feedback would be helpful.

[mmayer4]

skip_nulls worked liked magic on the first try! You da man! Thanks Scott!!!

[mjhaston]

Empty objects shouldn't present a problem. It is when the json represents an empty object by assigning it a null value that DATA-INTO has a problem.

As to allowmissing you really shouldn't need it. Use countprefix for the DS representing the object (or indeed for any item that can be omitted) and you don't need it. It is only required if you don't tell RPG how to notify you of the actual count of an element.

You'll find several examples of using this in my JSON articles https://authory.com/JonParisAndSusanGan ... ction=JSON

I'm receiving JSON responses from UPS which don't include any number of objects or arrays depending on the shipment. Is there something other than allowmissing to handle those situations?

[jonboy49]

Yes there is - it is in my text that you quoted!

Use countprefix for the DS representing the object (or indeed for any item that can be omitted) and you don't need it. It is only required if you don't tell RPG how to notify you of the actual count of an element.

You'll find several examples of using this in my JSON articles https://authory.com/JonParisAndSusanGan ... ction=JSON

[Scott Klement]

If you have like 500 optional elements, coding a "countprefix" field for all of them is tedious, to put it mildly. I often use allowmissing or allowextra to avoid that.

Different methods have pros and cons -- just consider them carefully before choosing a method.