It is necessary that the platform supports this format not only because JSON is an advanced format that 1C:Enterprise applications may independently employ for integration with third-party applications. In fact, JSON is actively used in HTTP interfaces supported by 1C:Enterprise through the REST application interface (that the platform automatically generates) and HTTP services the user can save by themselves.
There are several JSON use cases.
Integration with third-party systems through their HTTP interfaces: Google Calendar, Salesforce.com, 1C:Enterprise REST interface, SharePoint, etc.
Creating an application's native HTTP interface
Exchanging JSON files with third-party systems Generating configuration files Using them in data exchange procedures (e.g. in exchanging data with online stores)
Using JSON files for the data exchange between various 1C:Enterprise applications
The platform has several JSON support layers. The simplest and most flexible ones are low-level stream read/write tools. Less versatile tools of higher levels are tools for serializing primitive types and collections of 1C:Enterprise in JSON. Finally, the third layer comprises tools for serializing/deserializing 1C:Enterprise applied types: links, objects, recordsets, or any other types supporting XDTO serialization.
JSON stream reading and writing
Stream objects successively read JSON data from a file or string or successively write them to a file or string. Thus, data reading or writing goes without generating a whole document in the memory.
Stream JSON writing can be as follows: An array of four items is written. Three of them are of a primitive type, the fourth is an object with two properties:
"TypePropertyString": "Value String",
Serialization of primitive types and collections
A benefit of the second group of JSON handling tools is that it tackles the routine on reading/writing every single value or property. During the reading, JSON documents are displayed in a fixed-sized set of platform types: String, Value, Boolean, Unidentified, Array, Fixed-Sized Array, Structure, Fixed-Sized Structure, Match, Date. Vice versa, a composition of objects of those types helps generate and write a JSON structure to a file. Thus, the user can read and write a small volume of JSON data with just a few code strings.
The main purposes of these tools are exchanging data with third-party systems and reading JSON configuration files.
Example of serializing (writing) to JSON:
"Last Name": "Smith",
"First Name": "John",
"Second Name": "Michael",
"Phone Numbers": [
Serialization of 1C:Enterprise Applied Types
First and foremost, XDTO serialization to JSON is recommended in the data exchange between 1C:Enterprise applications. Also, this mechanism can be used for exchanging data with third-party systems ready to accept 1C:Enterprise data types.
Here's an example of a simple code executing the serialization of a catalog item:
The output will be the following JSON file:
"Description": "Moskhleb OJSC",
"ZIP Code": "456789",
"MoreInfo": "Bread Distribution",
"ContactPerson": "Max Jones",
Transformation and restoration in serialization
Serialization cannot be always fully automatic. In fact, there can be different cases. This is why the platform allows using an automatic-recording function of processing values when reading from and writing to JSON.
When writing to JSON, this function helps transform to JSON those types that are not subject to automatic transformation, or even not serialize them.
When reading from JSON, the restoration function can be used to transform JSON data into 1C types that are not subject to automatic transformation or to manually transform JSON dates into 1C:Enterprise dates.
During the deserialization of 1C:Enterprise applied types, the restoration function can be used in relocating data from one application to another, to replace links with related objects. With such a replacement, after the relocation, the data will refer to objects of the new base. Or, this function can be used to delete information only effective in the initial base.
Using JSON in HTTP Interfaces of Applications
Automatically Generated REST Interface of Applications
A query to the REST interface of an application may have a response in the JSON format. The user can manage the volume of the transmitted data by adjusting the level of detail of the exported metadata. There are three levels: minimum, medium, and maximum. However, the user must keep in mind that reducing the volume of the transmitted information leads to a higher intensity of computation in the client. Conversely, when all the information is transmitted, the computation load in the client is minimal.
Application HTTP Services
HTTP services built into an application can return a JSON-format response. With that, when forming the response body, the user can specify whether BOM (Byte Order Mark) should be used.
Interacting with Third-Party HTTP Services
When interacting with third-party HTTP interfaces, the user can generate the query body in JSON and then embed it into an HTTP query.
Next page: ZIP archives