Denodo needs a fixed JSON schema in order to generate a base view. However, it does allow parts of the schema to be optional.
In your scenario, if the payloads are such that the variable elements can be treated as optional ones, then at design time you can create a base view using an example JSON document that includes all the optional elements, then at run-time any elements that are not present in a JSON response will be left as NULL values in Denodo.
When creating the base view using the JSON connector, you can specify a Data Route that can be a local JSON file, which has been edited to include all the optional elements. This local example JSON file would then be introspected by Denodo to create the base view's structure. Once the JSON base view is created, the Data Route can be changed to point to the 'live' JSON end-point e.g. an HTTP URL.
In your example if you defined the JSON base view using a simple JSON document as follows in which the variable-key1, 2 and 3 structures are all optional:
{
"fixed-key1" : "value1"
"fixed-key2" : {
"variable-key1" : {
"fixed-key1.1" : "value1.1",
"fixed-key1.2" : "value1.2"
},
"variable-key2" : {
"fixed-key2.1" : "value2.1",
"fixed-key2.2" : "value2.2"
}
"variable-key3" : {
"fixed-key3.1" : "value3.1",
"fixed-key3.2" : "value3.2"
}
}
}
At run-time, if the JSON response does not include variable-key3 for example, then these elements would just be represented as null values in Denodo.
If however, the payload is completely dynamic depending on the request, and returns payloads that represent completely different entities with different structures that can't be represented using optional elements as described above, then Denodo wouldn't be able to be handle this in a single view. In this case I would create a base view for each specific entity.