Hi @essb ,
Please see attached a workspace where I have made some suggested changes to your workflow. The challenge here is that the Published Parameters, Directives, Result and Request data are all stored at different levels (objects/arrays) within the JSON.
Currently, your JSON Fragmenter is querying the Published Parameter array, which means all the other elements in the JSON are disregarded and no longer available to query later downstream in the translation.
Instead, I suggest in the JSONFragmenter you only query to the item level, and then in the attributes to expose you'll need to include the object/array name to read into those nested levels of JSON. In the workspace, I've included a couple of examples, but if there is anything else you'd like to expose, I'd recommend viewing the output of the JSONFragmenter in the Feature Information window. This will guide you on what you need to specify to expose the attribute:
e.g. to expose the status Message you'll need to specify result.statusMessage, or the workspace path would be request.workspacePath.
You can then use the BulkAttributeRenamer to remove the prefixes from the Attribute Names afterwards.
Hi @essb ,
Please see attached a workspace where I have made some suggested changes to your workflow. The challenge here is that the Published Parameters, Directives, Result and Request data are all stored at different levels (objects/arrays) within the JSON.
Currently, your JSON Fragmenter is querying the Published Parameter array, which means all the other elements in the JSON are disregarded and no longer available to query later downstream in the translation.
Instead, I suggest in the JSONFragmenter you only query to the item level, and then in the attributes to expose you'll need to include the object/array name to read into those nested levels of JSON. In the workspace, I've included a couple of examples, but if there is anything else you'd like to expose, I'd recommend viewing the output of the JSONFragmenter in the Feature Information window. This will guide you on what you need to specify to expose the attribute:
e.g. to expose the status Message you'll need to specify result.statusMessage, or the workspace path would be request.workspacePath.
You can then use the BulkAttributeRenamer to remove the prefixes from the Attribute Names afterwards.
Thanks for the help, that works perfectly.
When things are stored at different levels does that mean that we cant parse the response body with only a single fragmenter? What I mean is, is that the correct way to work, to use x fragmenters and list exploders?
Thanks for the help, that works perfectly.
When things are stored at different levels does that mean that we cant parse the response body with only a single fragmenter? What I mean is, is that the correct way to work, to use x fragmenters and list exploders?
@essb ,
Yes, the JSON Query refers to the JSON values which will become new FME features. If you have multiple nested objects/arrays in your JSON then these will all require different queries to fetch each of them. This leaves you with two options:
a) Use multiple JSONFragmenters on the initial JSON string to perform each query, then perform a join to associate the exposed attributes from each object with one another.
b) Use a single JSONFragmenter with a top-level query, and then use additional transformers to complete the request.
I prefer to use option b so that I can avoid the need to join back the output data once I've parsed the JSON.
