Designer 10.7 | webMethods Service Development Help | Working with JSON Document Types | Considerations for Using JSON Document Types
 
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.