Considerations for Using JSON Document Types
Consider the following behaviors and limitations of JSON document types before using them.
General Considerations
JSON document type cannot be created or edited manually.
JSON document type can be created only from a JSON schema that has a JSON object at its root.
Integration Server currently supports the JSON schema specification, draft 04, draft 06, and draft 07, with some exceptions, as described in this section.
Draft 04 of the JSON schema specification is used as the default, if the
$schema keyword is not present.
The fields in the JSON document type that is generated may not appear in the same order as in the JSON schema.
Any validation property or field in the JSON schema that has a trailing comma will generate an error and the document will not be created.
JSON schema keywords that have leading or trailing spaces are ignored. This is applicable only to JSON schema keywords. Any user-defined field with leading or trailing spaces is included with the extra spaces as specified in the JSON schema.
When importing a JSON schema, if you do not specify the types correctly then
Integration Server automatically considers the types as object.
While parsing the JSON schema, erroneous data type properties (such as
max instead of
maximum for the
number data type) are ignored by the parser.
In the case of duplicate property values, the JSON schema parser uses only the last property value and ignores preceding ones as the property value is overwritten each time an instance of the property is found.
If duplicate
$ids exist in a JSON document, the parser uses the last
$id that it encounters.
Any
if-
then-
else construct that is enclosed within a null or a boolean is ignored.
Multi-dimensional and heterogeneous arrays are represented by an
Integration Server Object list in the JSON document type. Due to this, some details about the original data structures are abstracted in the generated JSON document type. However, you can view the corresponding content of the JSON schema for these fields under the
Validations property in Designer. The original content for such fields is not available for direct mapping during runtime.
Example of a two-dimensional array:
“properties”: {
"client": {
"type": "array",
"items": {
"type": "object",
"properties": {
"account": {
"type": "array",
"items": {
"type": "number"
}
}
}
}
}
}
Example of a heterogeneous array:
"properties": {
"MyArray": {
"type": "array",
"items": [{
"type": "array",
"items": [{
"type": "number"
}]
},
{
"type": "array",
"items": [{
"type": "number"
},
{
"type": "number"
}]
}]
}
}
Anonymous sub-schemas have no representations in the JSON document type. However, they are available for validation purposes.
Referenced JSON objects are created with the following naming convention:
doctypeRef_<<nameOftheField>>Limitations
Integration Server does not support the following formats:
contentEncoding
idn-email
idn-hostname
iri
iri-reference
contentMediaType
Integration Server does not support the following keywords:
examples
comments
default
JSON document types cannot be made publishable. That is, a JSON document type cannot become a publishable document type.