【学习转载】One more ABAP to JSON Serializer and Deserializer

深碍√TFBOYSˉ_ 2022-10-06 11:54 25阅读 0赞

## Why ##

There are a lot of other implementations of the **ABAP to JSON Serializer and Deserializer** in SDN, but for different reasons, all implementations I have found were not suitable for my needs. From SAP\_BASIS 7.40 there is also **a simple transformation** available for converting **ABAP to JSON** and **JSON to ABAP**. It is the best choice if you need maximal performance and does not care about **serialization format**, but for proper handling of ABAP types and name **pretty-printing**, it fits badly.

So, I have written my own **ABAP JSON serializer and ABAP JSON deserializer** which has some key differentiates from other implementations.

Below you can find a snippet of the ABAP JSON class I wrote, that you can use as a local class or global renamed.

An original and actual version of the source can be found in class /UI2/CL\_JSON delivered with UI2 Add-on (can be applied to SAP\_BASIS 700 – 76X). So, you can use this ABAP JSON parser in your standard code mostly on any system.

## What it can ##

### ABAP to JSON ###

*  Serialize classes, structures, internal tables, class and data references, any kind of elementary types. Complex types, as a table of structures/classes, classes with complex attributes, etc. are also supported and recursively processed.
 *  **ABAP to JavaScript** adopted way of data type serializations:
    
     *  strings, character types to JavaScript string format (no length limitation),
     *  ABAP\_BOOL / BOOLEAN / XFELD / BOOLE\_D to JavaScript Boolean,
     *  Built-in TRIBOOL (TRUE/FALSE/UNDEFINED = 'X'/'-'/'') support, for better control of initial values when serializing into JavaScript  Boolean
     *  int/floats/numeric/packed to JavaScript Integers/floats,
     *  date/time to JavaScript date/time string representation as "2015-03-24" or "15:30:48",
     *  timestamp to JavaScript  integer or [ISO8601][] string
     *  structures to JavaScript objects (include types are also supported; aliases => AS are ignored)
     *  **convert ABAP internal table to JSON**, e.g JavaScript arrays or associative arrays (objects)
 *  Support of conversion exits on ABAP data serialization
 *  Pretty Printing of JavaScript property names: *MY\_DATA* -> *myData*, */SAPAPO/MY\_DATA* -> *sapapoMyData*.
 *  Condensing of default values: initial values are not rendered into the resulting **JSON** string
 *  Performance is optimized for processing big internal tables with structures

### JSON to ABAP ###

*  Deserialize JSON objects, arrays, and any elementary types into corresponding ABAP structures. Complex objects, with embedded arrays and objects with any level of nesting, are also supported.
 *  **Convert JSON to an internal table**
 *  Generic deserialization of JSON objects into reference data types: 
    
     *  as simple data types (integer, boolean, or string into generic data reference (REF TO DATA) -> ABAP type is selected based on JSON type.
     *  as dynamically generated complex object (structures, tables, mixed) for initial REF TO DATA fields
     *  as typed references for prefilled REF TO DATA fields (you assign a reference to typed empty data object to REF TO DATA field in execution time)
 *  Deserialization of unknown JSON structures possible using method GENERATE into on the fly created data types
 *  On **JSON** to **ABAP** transformation following rules are used:
    
     *  objects parsed into corresponding ABAP structures, classes (only classes with constructors with no obligatory parameters are supported), or internal hash/sorted tables
     *  arrays converted to internal tables (complex tables are also supported). 
     *  Boolean converted as ABAP\_BOOL (‘’ or ‘X’)
     *  Date/Time/Timestamps from JSON converted based on the type of corresponding ABAP element
     *  integers/floats/strings moved to corresponding fields using ABAP move semantic (strings are un-escaped). There is no limit on the size of deserialized strings, the only restriction is the constraints of receiving data type. Escaped Unicode symbols (\\u001F) ins strings are decoded.
     *  elementary data types are converted if do not match: JavaScript integer can come into ABAP string or JavaScript string into ABAP integer, etc.
     *  Transformation takes into account property naming guidelines for **JSON** and **ABAP** so that camelCase names will be copied into the corresponding CAMEL\_CASE field if the CAMELCASE field is not found in the ABAP structure. Do not forget to use the same PRETTY\_MODE for deserialization, as you have used for serialization.
     *  Default field values, specified in reference ABAP variable are preserved, and not overwritten if not found in the JSON object
     *  Transformation of **JSON** structures into ABAP class instances is NOT supported.
 *  Support of conversion exits on deserialization

Parser for serialize/deserialize uses single-pass parsing and optimized to provide the best possible performance in ABAP in release independent way. But for time-critical applications, which have kernel version 7.20 and higher, it is recommended to use built-in **JSON** to **ABAP** transformations (CALL TRANSFORMATION). If transformation for some reason does not work, please assist the following notes: [1650141][] and [1648418][1650141].

## Usage example ##

**ABAP to JSON usage example**

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 </td> 
 <td> <code>DATA: lt_flight TYPE STANDARD TABLE OF sflight,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>lrf_descr TYPE REF TO cl_abap_typedescr,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>lv_json&nbsp;&nbsp; TYPE string.</code> &nbsp; <code>&nbsp;</code>&nbsp; <code>SELECT * FROM sflight INTO TABLE lt_flight.</code> <code>&nbsp;</code>&nbsp; <code>* serialize table lt_flight into JSON, skipping initial fields and converting ABAP field names into camelCase</code> <code>lv_json = /ui2/cl_json=&gt;serialize( data = lt_flight compress = abap_true pretty_name = /ui2/cl_json=&gt;pretty_mode-camel_case ).</code> <code>WRITE / lv_json.</code> &nbsp; <code>CLEAR lt_flight.</code> <code>&nbsp;</code>&nbsp; <code>* deserialize JSON string json into internal table lt_flight doing camelCase to ABAP like field name mapping</code> <code>/ui2/cl_json=&gt;deserialize( EXPORTING json = lv_json pretty_name = /ui2/cl_json=&gt;pretty_mode-camel_case CHANGING data = lt_flight ).</code> &nbsp; <code>* serialize ABAP object into JSON string</code> <code>lrf_descr = cl_abap_typedescr=&gt;describe_by_data( lt_flight ).</code> <code>lv_json = /ui2/cl_json=&gt;serialize( lrf_descr ).</code> <code>WRITE / lv_json.</code> </td> 
 </tr> 
 </tbody> 
</table>

### Output ###

[{"mandt":"000","carrid":"AA","connid":0017,"fldate":20130515,"price":422.94,"currency":"USD","planetype":"747-400","seatsmax":385,
    "seatsocc":375,"paymentsum":192683.30,"seatsmaxB":31,"seatsoccB":31,"seatsmaxF":21,"seatsoccF":19},{"mandt":"000","carrid":"AA",
    "connid....
    {"ABSOLUTE_NAME":"\\TYPE=%_T00004S00000000O0000012480","ADMIN_TAB":"\\TYPE=%_T00004S00000000O0000012480",
    "ADMIN_TAB_LINE":"\\TYPE=%_T00004S00000000O0000012480","DECIMALS":0,"HAS_UNIQUE_KEY":false,"INITIAL_SIZE":0,
    "KEY":[{"NAME":"MANDT"},{"NAME":"CARRID"},{"NAME":"CO....

## API description ##

Two static methods are of most interest in common cases: SERIALIZE and DESERIALIZE. The rest of the public methods are done public only for reuse purposes if you would like to build/extend your own serialization/deserialization code.

**SERIALIZE****: Serialize ABAP object into JSON**

* **> DATA **(any) - any ABAP object/structure/table/element to be serialized
 * **> COMPRESS **(bool, default=false) - tells serializer to skip empty elements/objects during serialization. So, all for which IS INITIAL = TRUE. 
 * **> NAME **(string, optional) -** **optional name of the serialized object. Will '"name" : \{...\}' instead of ' \{...\} ' if supplied. 
 * **> PRETTY\_NAME (enum, optional)  **\- mode, controlling how ABAP field names transformed in JSON attribute names. See the description below.  
 * **> TYPE\_DESCR** (ref to CL\_ABAP\_TYPEDESCR, optional) - if you know object type already - pass it to improve performance. 
 * **> ASSOC\_ARRAYS** (bool, default = false) - controls how to serialize hash or sorted tables with unique keys. See below for details.
 * **> ASSOC\_ARRAYS\_OPT** (bool, default = false) - when set, serializer will optimize rendering of name-value associated arrays (hash maps) in JSON
 * **> TS\_AS\_ISO8601** (bool, default = false) - says serializer to output timestamps using [ISO8601][] format.
 * **> NUMC\_AS\_STRING** (bool, default = false) - Controls the way how NUMC fields are serialized. If set to ABAP\_TRUE, NUMC fields serialized not as integers, but as strings, with all leading zeros. Deserialization works compatible with both ways of NUMC serialized data.
 * **> CONVERSION\_EXITS** (bool, default = false) - use DDIC conversion exits on serialize of values (performance lost!)
 * **< R\_JSON** - output JSON string.

**DESERIALIZE****: Deserialize ABAP object from JSON string**

* **> JSON **(string) - input JSON object string to deserialize
 * **> PRETTY\_NAME **(enum, optional) - mode, controlling how JSON field names mapped to ABAP component names. See the description below.  
 * **> ASSOC\_ARRAYS **(bool, default = false) -  controls how to deserialize JSON objects into hash or sorted tables with unique keys. See below for details.
 * **> ASSOC\_ARRAYS\_OPT** (bool, default = false) - when set, the deserializer will take into account the optimized rendering of associated arrays (properties) in JSON. 
 * **> TS\_AS\_ISO8601 **(bool, default = false) - says deserializer to read timestamps from strings into timestamps fields using [ISO 8601][ISO8601] format.
 * **> CONVERSION\_EXITS** (bool, default = false) - use DDIC conversion exits on deserialize of values (performance lost!)
 * **<> DATA **(any) - ABAP object/structure/table/element to be filled from JSON string. If the ABAP structure contains more fields than in the JSON object, the content of unmatched fields is preserved.

**GENERATE****: Generates ABAP object from JSON**

In addition to the explained methods, there are two options, that need a wider explanation:

**PRETTY\_NAME**: enumeration of modes, defined as constant /UI2/CL\_JSON=>pretty\_name.

*  **NONE** - ABAP component names serialized as is (UPPERCASE).
 *  **LOW\_CASE** - ABAP component names serialized in low case 
 *  **CAMEL\_CASE** - ABAP component types serialized in CamelCase where symbol "\_" is treated as word separator (and removed from the resulting name). 
 *  **EXTENDED** - works the same way as CAMEL\_CASE but also, has extended logic for encoding special characters, as: ".", "@", "~", etc. Shall be used if you need JSON names with characters not allowed for ABAP data component names. Do not use it, if you do not have special characters in JSON names - the performance would be slower in comparison with CAMEL\_CASE mode. Example: ABAP name '\_\_A\_\_SCHEMA' translates in JSON name '@schema'  
    Encoding rules (ABAP name → JSON name):
    
     *  '\_\_E\_\_' → '!'
     *  '\_\_N\_\_' → '\#'
     *  '\_\_D\_\_' → '$'
     *  '\_\_P\_\_' → '%'
     *  '\_\_M\_\_' → '&'
     *  '\_\_S\_\_' → '\*'
     *  '\_\_H\_\_' → '-'
     *  '\_\_T\_\_' → '~'
     *  '\_\_L\_\_' → '/'
     *  '\_\_C\_\_' → ':'
     *  '\_\_V\_\_' → '|'
     *  '\_\_A\_\_' → '@'
     *  '\_\_O\_\_' or '\_\_\_' → '.'

**NONE** and **LOW\_CASE** work the same way for DESERIALIZE.

**ASSOC\_ARRAYS** :

This option controls the way how hashed or sorted tables with unique keys serialized/deserialized. Normally, ABAP internal tables are serialized into JSON arrays, but in some cases, you will like to serialize them as associative arrays (JSON object) where every row of the table shall be reflected as a separated property of JSON object. This can be achieved by setting *the ASSOC\_ARRAYS* parameter to TRUE. If set, the serializer checks for sorted/hashed tables with a UNIQUE key(s) and serialize them as an object. The JSON property name, reflecting row, constructed from values of fields, used in key separated by constant *MC\_KEY\_SEPARATOR* = '-'. If the table has only one field marked as key, the value of this single field becomes a property name and REMOVED from the associated object (to eliminate redundancy). If TABLE\_LINE is used as a unique key, all values of all fields construct key property names (separated by *MC\_KEY\_SEPARATOR*). During deserialization, logic works vice versa: if *ASSOC\_ARRAYS* set to TRUE, and JSON object matches internal hash or sorted table with the unique key, the object is transformed into the table, where every object property reflected in a separated table row. If the ABAP table has only one key field, the property name is transformed into a value of this key field.

**ASSOC\_ARRAYS\_OPT:**

By default, when dumping hash/sorted tables with a unique key into JSON, the serializer will write key field as the property name, and the rest of the fields will write object value of properties:

**Dumping of hash tables from ABAP to JSON**

<table> 
 <tbody> 
 <tr> 
 <td> <code>TYPES: BEGIN OF ts_record,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>key TYPE string,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>value TYPE string,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>END OF ts_record.</code> <code>&nbsp;</code>&nbsp; <code>DATA: lt_act TYPE SORTED TABLE OF ts_record WITH UNIQUE KEY key.</code> <code>lv_json = /ui2/cl_json=&gt;serialize( data = lt_exp assoc_arrays = abap_true ).</code> </td> 
 </tr> 
 </tbody> 
</table>

**Output JSON**

<table> 
 <tbody> 
 <tr> 
 <td> <code>{ </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>"KEY1"</code><code>: { </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>"value"</code><code>:&nbsp;</code><code>"VALUE1"</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>},</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>"KEY2"</code><code>: { </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>"value"</code><code>:&nbsp;</code><code>"VALUE2"</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>}</code> <code>}</code> </td> 
 </tr> 
 </tbody> 
</table>

But if you will use the assoc\_arrays\_opt flag during serialization, the serializer will try to omit unnecessary object nesting on dumping of simple, name/value tables, containing only one key field and one value field:

**Dumping of hash tables from ABAP to JSON**

<table> 
 <tbody> 
 <tr> 
 <td> <code>lv_json = /ui2/cl_json=&gt;serialize( data = lt_exp assoc_arrays = abap_true assoc_arrays_opt = abap_true ).</code> </td> 
 </tr> 
 </tbody> 
</table>

**Output JSON**

<table> 
 <tbody> 
 <tr> 
 <td> <code>{ </code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>"KEY1"</code><code>:&nbsp;</code><code>"VALUE1"</code><code>,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>"KEY2"</code><code>:&nbsp;</code><code>"VALUE2"</code> <code>}</code> </td> 
 </tr> 
 </tbody> 
</table>

For deserialization, the flag is used to tell the deserializer that value shall be placed in a non-key field of the structure.

## Supported SAP\_BASIS releases ##

The code was tested from SAP\_BASIS 7.00 and higher, but I do not see the reasons why it cannot be downported on lower releases too. But if you plan to use it on SAP\_BASIS 7.02 and higher (and do not need property name pretty-printing) better consider the standard solution for **ABAP**, using CALL TRANSFORMATION. It shall be definitely faster, while implemented in the kernel. See [the blog of Horst Keller][] for details. Maybe the best will be, if you need support in lower SAP\_BASIS releases as well as in 7.02 and higher, to modified provided a class in a way to generate the same **JSON** format as standard ABAP CALL TRANSFORMATION for JSON does and redirect flow to home-made code or built-in **ABAP** transformation depending on SAP\_BASIS release.

## Further optimizations ##

*  Be aware, that usage of flag conversion\_exits may significantly decrease performance - use only in cases, when you are sure that you need it.
 *  Escaping property values can be expensive. To optimize performance, in this case, you can replace escapement code with some kernel implemented function (from *cl\_http\_utility* class for example), instead of explicit *REPLACE ALL OCCURRENCES* calls.
 *  Unescaping can influence deserialization performance even worse, depending on the fact if your JSON has encoded \\n\\r\\t\\f\\b\\x. So, avoid the usage of them if you can. 
 *  It is possible to significantly increase performance for serialization/deserialization by dropping the support of releases below 7.40. That can be realized by moving base parsing from ABAP to kernel implemented classes cl\_sxml\_string\_writer and cl\_sxml\_string\_reader.

## Remarks ##

Due to optimization reasons, some methods were converted to macros, to reduce overhead for calling methods for data type serialization. If performance in your case is not critical, and you prefer clean/debuggable code you can replace macro calls with corresponding methods.

## Related pages ##

*  [Does /UI2/CL\_JSON work in ABAP Cloud?][Does _UI2_CL_JSON work in ABAP Cloud]
 *  [Return generic result via SAP RFC (performance)][Return generic result via SAP RFC _performance]
 *  [RFC7159 - The JavaScript Object Notation (JSON) Data Interchange Format][RFC7159 -_The JavaScript Object Notation _JSON_ Data Interchange Format]
 *  [OData JSON Deserialize][]

## The /UI2/CL\_JSON code ##

Below you can find the code itself, which you can use (corresponds to the state of PL14).

If you want to use the class globally, I suggest creating a proxy class, in your own namespace, with a reduced interface (serialize/deserialize only) and call local copy (local class of it) of /UI2/CL\_JSON. Then you can easily update to the new version of /UI2/CL\_JSON from SDN or call UI Addon implementation if it is installed.

**ZCL\_JSON code** 展开源码

## Custom ABAP to JSON, JSON to ABAP name mapping ##

By default, you control the way JSON names are formatted/mapped to ABAP names by selecting proper pretty\_mode as a parameter for SERIALIZE/DESERIALIZE/GENERATE method. But in some cases, the standard, hard-coded formatting, is not enough. For example, if you need special rules for name formatting (for using special characters) or because JSON attribute name is too long and you can not map it to ABAP name (which has 30 characters length limit).

The recommended way for custom mapping was an extension of the /UI2/CL\_JSON class and redefining methods PRETTY\_NAME or PRETTY\_NAME\_EX, but since note [2526405][] there is an easier way, without the need in own class. If you have a static list of field mappings from ABAP to JSON you can pass the name mapping table as a parameter for the constructor/serialize/deserialize and control the way JSON names are formatted/mapped to ABAP names.

**ABAP to JSON name mapping**

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 </td> 
 <td> <code>TYPES:</code> <code>&nbsp;&nbsp;</code><code>BEGIN OF tp_s_data,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>sschema&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE string,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>odatacontext&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE string,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>shortened_abap_name TYPE string,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>standard&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE string,</code> <code>&nbsp;&nbsp;</code><code>END OF tp_s_data.</code> &nbsp; <code>DATA: ls_exp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE tp_s_data,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>lt_mapping&nbsp; TYPE /ui2/cl_json=&gt;name_mappings,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>lv_json&nbsp;&nbsp;&nbsp;&nbsp; TYPE /ui2/cl_json=&gt;json.</code> &nbsp; <code>lt_mapping = VALUE #( ( abap = `SSCHEMA` json = `$schema` )</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>( abap = `ODATACONTEXT` json = `@odata.context` )</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>( abap = `SHORTENED_ABAP_NAME` json = `VeeeeryyyyyLooooongJSONAttrbuuuuuuuuuteeeeeeeeeee` ) ).</code> &nbsp; <code>lv_json = /ui2/cl_json=&gt;serialize( data = ls_exp name_mappings = lt_mapping ).</code> </td> 
 </tr> 
 </tbody> 
</table>

## Custom formatting of values for serialization of ABAP into JSON ##

In some cases, you need to have custom formatting for your ABAP data, when serializing it into JSON. Or another use case, you have some custom, DDIC defined data types, that are not automatically recognized by standard code, and therefore no appropriate formatting is applied (for example custom boolean or timestamp type).

In this case, you have the following options:

1.  Extend the class and overwrite the method DUMP\_TYPE. See an example in section "/UI2/CL\_JSON extension".
2.  Add conversion exits for your custom type and apply formatting as part of the conversion exit.
3.  Create an alternative structure, with your custom types replaced by supported types, only for serialization, and do the move of data before the serialization.

## Serialization/deserialization of hierarchical/recursive data ##

Handling the recursive data structure in ABAP is not very trivial. And it is not very trivial to serialize and deserialize it either.  
If you would like to model your hierarchical data (tree-like) as ABAP structures, the only allowed way will be to do it like in the example below, where you use references to generic data:

**Modeling of recursive data types in ABAP**

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 </td> 
 <td> <code>TYPES:</code> <code>&nbsp;&nbsp;</code><code>BEGIN OF ts_node,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE i,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>children&nbsp; TYPE STANDARD TABLE OF REF TO data WITH DEFAULT KEY,</code> <code>&nbsp;&nbsp;</code><code>END OF ts_node.</code> &nbsp; <code>DATA: lv_exp&nbsp;&nbsp;&nbsp; TYPE string,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>lv_act&nbsp;&nbsp;&nbsp; TYPE string,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>ls_data&nbsp;&nbsp; TYPE ts_node,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>lr_data&nbsp;&nbsp; LIKE REF TO ls_data.</code> &nbsp; <code>ls_data-id = 1.</code> &nbsp; <code>CREATE DATA lr_data.</code> <code>lr_data-&gt;id = 2.</code> <code>APPEND lr_data TO ls_data-children.</code> </td> 
 </tr> 
 </tbody> 
</table>

Such a way more or less straightforward and will work, but leads to losing type information for data persisted in children table. That will mean that you will need to cast data when you access it. In addition to that, it blocks you from being able to deserialize such data from JSON, while the parser will not be able to deduce the type of data that needs to be created in the children's table. But serialization will work fine:

**Serialization of recursive ABAP structures**

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 </td> 
 <td> <code>lv_exp = '{"ID":1,"CHILDREN":[{"ID":2,"CHILDREN":[]}]}'.</code> <code>lv_act = /ui2/cl_json=&gt;serialize( data = ls_data ).</code> <code>cl_aunit_assert=&gt;assert_equals( act = lv_act exp = lv_exp msg = 'Serialization of recursive data structure fails' ).</code> </td> 
 </tr> 
 </tbody> 
</table>

The better way to model hierarchical data in ABAP is with help of objects, while objects are always processed as references and ABAP allow you to create nested data structures, referring to objects of the same type:

**Modeling of recursive data in ABAP using objects**

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 </td> 
 <td> <code>CLASS lcl_test DEFINITION FINAL.</code> <code>&nbsp;&nbsp;</code><code>PUBLIC SECTION.</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>DATA: id TYPE i.</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>DATA: children TYPE STANDARD TABLE OF REF TO lcl_test.</code> <code>ENDCLASS.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "lcl_test DEFINITION</code> </td> 
 </tr> 
 </tbody> 
</table>

In that manner, you can process data in the same way as with ABAP structures but using typed access and serialization/deserialization of data in JSON works fine while types can be deduced on

**Serialization/deserialization of recursive objects in ABAP**

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 </td> 
 <td> <code>DATA: lo_act&nbsp;&nbsp;&nbsp; TYPE REF TO lcl_test,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>lo_exp&nbsp;&nbsp;&nbsp; TYPE REF TO lcl_test,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>lv_json&nbsp;&nbsp; TYPE string,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>lo_child&nbsp; TYPE REF TO lcl_test.</code> &nbsp; <code>CREATE OBJECT lo_exp.</code> &nbsp; <code>lo_exp -&gt;id = 1.</code> &nbsp; <code>CREATE OBJECT lo_child.</code> <code>lo_child-&gt;id = 2.</code> <code>APPEND lo_child TO lo_exp-&gt;children.</code> &nbsp; <code>lv_json = /ui2/cl_json=&gt;serialize( data = lo_exp ).</code> <code>ui2/cl_json=&gt;deserialize( EXPORTING json = lv_json CHANGING data =&nbsp; lo_act ).</code> </td> 
 </tr> 
 </tbody> 
</table>

Remark: There are some constraints for data design that exist regarding the deserialization of objects:

*  You cannot use constructors with obligatory parameters
 *  References to interfaces will be not deserialized

### Serializing of protected and private attributes ###

If you do the serialization from outside of your class, you can access only the public attributes of that class. To serialize all types of attributes (private+protected) you need to allow /ui2/cl\_json access to them. This can be done by defining /ui2/cl\_json as a friend of your class. In this way, you do not disrupt your encapsulation for other classes but enable /ui2/cl\_json to access all data of your class.

If you do not own a class you want to serialize, you probably can inherit it from your class and add friends there. In this case, you can access at least protected attributes.

## Partial serialization/deserialization ##

When it is needed:

*  You deserialize JSON to ABAP but would like some known parts to be deserialized as JSON string, while you do not know nesting JSON structure.
 *  You deserialize a collection (array/associative array) which has objects with heterogeneous structure (for example the same field has different type depending on object type). Using partial deserialization, you can restore such a type as JSON string in ABAP and apply later additional deserialization based on the object type.  
 *  You serialize ABAP to JSON and have some ready JSON pieces (strings) which you would like to mix in.

The solution /UI2/CL\_JSON has for this type /UI2/CL\_JSON=>JSON (alias for built-in type string). ABAP fields using declared with this type will be serialized/deserialized as JSON pieces. Be aware that during serialization from ABAP to JSON, the content of such JSON piece is not validated for correctness, so if you pass an invalid JSON block, it may destroy the whole resulting JSON string at the end.

Below you can find examples for partial serialization/deserialization.

Serialization:

**Partial serialization of ABAP to JSON** 展开源码

Results in:

**JSON Output** 展开源码

Deserialization:

**Partial deserialization of JSON into ABAP** 展开源码

Results in the following ABAP data:

**ABAP Output (variant 1)** 展开源码

**ABAP Output (variant 2)** 展开源码

## /UI2/CL\_JSON extension ##

If standard class functionality does not fit your requirements there are two ways of how you can adapt it to your needs:

*  Use a local copy of the class /UI2/CL\_JSON and modify logic directly, by the change of original code.
 *  Inherit from class /UI2/CL\_JSON and override methods where another logic is required.

The advantage of the first approach that you are completely free in what you may change and have full control of the class lifecycle. The disadvantage, you will probably need to merge your changes with /UI2/CL\_JSON updates.

For the second approach you can use /UI2/CL\_JSON directly (prerequisite is the latest version of note [2330592][]), do not need to care about the merge, but can override only some methods. The methods are:

**IS\_COMPRESSIBLE **– called to check, if the given type output may be suppressed during ABAP to JSON serialization when a value is initial.

* **> TYPE\_DESCR** (ref to CL\_ABAP\_TYPEDESCR) – value type
 * **< RV\_COMPRESS** (bool) – compress initial value

The default implementation of the method allows compressing any initial value.

**PRETTY\_NAME** – called to format ABAP field name written to **JSON** or deserialized from **JSON** to **ABAP** field, when the pretty\_name parameter of *SERIALIZE/DESERIALIZE* method equal to *PRETTY\_MODE-CAMEL\_CASE*.

* **> IN** (CSEQUENCE) – Field name to pretty print.
 * **< OUT** (STRING) – Pretty printed field name

The default implementation applies camelCase formatting, based on usage of the “\_” symbol. To output, the “\_” symbol, use the double “\_\_” symbol in the field name.

**PRETTY\_NAME\_EX** – called to format ABAP field name written to JSON or deserialized from JSON to ABAP field, when the pretty\_name parameter of *SERIALIZE/DESERIALIZE* method equal to *PRETTY\_MODE-EXTENDED*.

* **> IN** (CSEQUENCE) – Field name to pretty print.
 * **< OUT** (STRING) – Pretty printed field name

The default implementation does the same as *PRETTY\_NAME*, plus converting special characters "!\#$%&\*-~/:|@.".

**DUMP\_INT** \- called for recursive serialization of complex ABAP data objects (structure, class, table) into JSON string

* **> DATA** (DATA) – Any data to serialize.
 * **> TYPE\_DESCR** (ref to CL\_ABAP\_TYPEDESCR, optional) – Type of data provided
 * **< R\_JSON** (JSON) – serialized JSON value

**DUMP\_TYPE** \- called for serialization of elementary ABAP data type (string, boolean, timestamp, etc) into the JSON attribute value. Overwrite it if you, for example, want to apply data output data conversion of currency rounding

* **> DATA** (DATA) – Any data to serialize
 * **> TYPE\_DESCR** (ref to CL\_ABAP\_TYPEDESCR) – Type of data provided
 * **< R\_JSON** (JSON) – serialized JSON value

**RESTORE** \- called for deserializing JSON objects into ABAP structures

* **> JSON** (JSON) – JSON string to deserialize
 * **> ** **LENGTH** (I) – Length of the JSON string
 * **> TYPE\_DESCR** (ref to CL\_ABAP\_TYPEDESCR, optional) – Type of changing data provided
 * **> FIELD\_CACHE** (type T\_T\_FIELD\_CACHE, optional) – Cache of ABAP data fields with type information
 * **<> DATA** (type DATA, optional) – ABAP data object to fill
 * **<> OFFSET** (I) – parsing start point in JSON string

**RESTORE\_TYPE** \- called to deserializing simple JSON attributes and JSON arrays

**CLASS\_CONSTRUCTOR** \- used to initialize static variables. You can not overwrite it, but you can implement your own class constructor that adapts default globals. For example, adds the additional boolean types to be recognized during serialization/deserialization.

**SERIALIZE/DESERIALIZE** \- these methods are static therefore cannot be redefined. Methods are helpers for a consumption code, hiding the construction of the class instance and further \*\_INT calls. So, if you would like to use something similar, in your custom class, you need to copy mentioned methods to new ones e,g \*\_EX, and overwrite there /UI2/CL\_JSON type to your custom class name. And use these methods instead of standard.

Extension using inheritance:

**Extension of /UI2/CL\_JSON** 展开源码

Results in the following JSON:

**Serialization with custom /UI2/CL\_JSON** 展开源码

## Deserialization of an untyped (unknown) JSON object ##

If you need to deserialize a JSON object with an unknown structure, or you do not have a passing data type on the ABAP side or the data type of the resulting object may vary, you can generate an ABAP object on the fly, using the corresponding GENERATE method. The method has some limitations comparing to standard deserialization like:

*  all fields are generated as a reference (even elementary types)
 *  you can not control how deserialized arrays or timestamps
 *  you can not access components of generated structure statically (while the structure is unknown at compile time) and need to use dynamic access

The simplest example, with straightforward access:

**Generating of ABAP Data using /UI2/CL\_JSON**

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 </td> 
 <td> <code>DATA: lv_json TYPE /ui2/cl_json=&gt;json,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>lr_data TYPE REF TO data.</code> &nbsp; <code>FIELD-SYMBOLS:</code> <code>&nbsp;&nbsp;</code><code>&lt;data&gt;&nbsp;&nbsp; TYPE data,</code> <code>&nbsp;&nbsp;</code><code>&lt;struct&gt; TYPE any,</code> <code>&nbsp;&nbsp;</code><code>&lt;field&gt;&nbsp; TYPE any.</code> &nbsp; <code>lv_json = `{"name":"Key1","properties":{"field1":"Value1","field2":"Value2"}}`.</code> <code>lr_data = /ui2/cl_json=&gt;generate( json = lv_json ).</code> &nbsp; <code>" OK, generated, now let us access somete field :(</code> <code>IF lr_data IS BOUND.</code> <code>&nbsp;&nbsp;</code><code>ASSIGN lr_data-&gt;* TO &lt;data&gt;.</code> <code>&nbsp;&nbsp;</code><code>ASSIGN COMPONENT `PROPERTIES` OF STRUCTURE &lt;data&gt; TO &lt;field&gt;.</code> <code>&nbsp;&nbsp;</code><code>IF &lt;field&gt; IS ASSIGNED.</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>lr_data = &lt;field&gt;.</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>ASSIGN lr_data-&gt;* TO &lt;data&gt;.</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>ASSIGN COMPONENT `FIELD1` OF STRUCTURE &lt;data&gt; TO &lt;field&gt;.</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>IF &lt;field&gt; IS ASSIGNED.</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>lr_data = &lt;field&gt;.</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>ASSIGN lr_data-&gt;* TO &lt;data&gt;.</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>WRITE: &lt;data&gt;. " We got it -&gt; Value1</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>ENDIF.</code> <code>&nbsp;&nbsp;</code><code>ENDIF.</code> <code>ENDIF.</code> </td> 
 </tr> 
 </tbody> 
</table>

A nice alternative, using [dynamic data accessor helper class][]:

**Access generated ABAP data object using dynamic data accessor helper**

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 </td> 
 <td> <code>DATA: lv_json TYPE /ui2/cl_json=&gt;json,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>lr_data TYPE REF TO data,</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>lv_val&nbsp; TYPE string.</code> &nbsp; <code>lv_json = `{"name":"Key1","properties":{"field1":"Value1","field2":"Value2"}}`.</code> <code>lr_data = /ui2/cl_json=&gt;generate( json = lv_json ).</code> &nbsp; <code>/ui2/cl_data_access=&gt;create( ir_data = lr_data iv_component = `properties-field1`)-&gt;value( IMPORTING ev_data = lv_val ).</code> <code>WRITE: lv_val.</code> </td> 
 </tr> 
 </tbody> 
</table>

## Implicit generation of ABAP objects on deserialization ##

In addition to the explicit generation of the ABAP data objects from JSON string, the deserializer supports an implicit way of generation, during DESERIALIZE(INT) call. To trigger generation, your output data structure shall contain a field with the type REF TO DATA, and the name of the field shall match the JSON attribute (pretty name rules are considered). Depending on the value of the field, the behavior may differ:

*  The value is not bound (initial): deserialize will use generation rules when creating corresponding data types of the referenced value
 *  The value is bound (but may be empty): the deserializer will create a new referenced value based on the referenced type.

**Example of implicit generation of ABAP data from JSON string** 展开源码

## JSON/ABAP serialization/deserialization with runtime type information ##

Automatic deserialization of the JSON into appropriate ABAP structure is not supported. The default implementation assumes that you need to know the target data structure (or at least partial structure, it will also work) to deserialize JSON in ABAP and then work with typed data.

But if for some reason one needs the ability to deserialize JSON in source ABAP structure in a generic way, he can extend both serialize/deserialize methods and wrap outputs/inputs of /UI2/CL\_JSON data by technical metadata describing source ABAP structure and use this information during deserialization (or use GENERATE method). Of course, you need to ensure that the source ABAP data type is known in the deserialization scope (global and local types are "visible").

See the example below:

**Serialization and deserialization with runtime type information** 展开源码

## Exception Handling in /UI2/CL\_JSON ##

By default, /UI2/CL\_JSON tries to hide from consumer thrown exceptions (that may happen during deserialization) catching them at all levels. In some cases, it will result in missing attributes, in other cases, when an error was critical and the parser can not restore, you will get an empty object back. The main TRY/CATCH block, not letting exceptions out is in DESERIALIZE method.

If you want to get a reporting in case of error, you shall use instance method DESERIALIZE\_INT which may fire CX\_SY\_MOVE\_CAST\_ERROR. The reporting is rather limited - all errors translated into CX\_SY\_MOVE\_CAST\_ERROR and no additional information available.

## JSON to ABAP transformation with the use of CALL TRANSFORMATION ##

Below is a small example of CALL TRANSFORMATION usage to produce JSON from ABAP structures. Do not ask me for details - I do not know them.   Was just a small test of me.

**CALL TRANSFORMATION for JSON** 展开源码

# Version History #

## Note [2944398][] - PL15 ##

**/UI2/CL\_JSON**

* Fixed. Generating of ABAP structures for JSON attributes which include special characters like "/\\:;~.,-+=><|()\[\]\{\}@+\*?!&$\#%^'§\`" fails.
 * Fixed. Edm.Guid with the mixed or lower case is not recognized.
 * Fixed. Iterating and data assignments for the generated data object (REF TO DATA), produced by GENERATE and DESERIALIZE methods fail in ABAP Cloud.

**/UI2/CL\_DATA\_ACCESS**

*  Fixed. Index access to generated tables in LOOP construction fails.

## Note [2904870][] - PL14 ##

**/UI2/CL\_JSON**

*  Fixed. Unescaping of strings with a single Unicode entity (e.g "\\uXXXX") does not work 
 *  New. More robust logic for handling invalid JSON (e.g cases with extra "," without further element  \{ "a": 1, \} )

## Note [2870163][] - PL13 ##

**/UI2/CL\_JSON**

*  Fixed. Conversion exists does not work when data located inside of internal tables.
 *  Fixed. TIMESTAMPL subsecond values are truncated when deserializing from Edm.DateTime.

## Note [2798102][] - PL12 ##

**/UI2/CL\_JSON**

* New. DESERIALIZE and GENERATE methods supporting decoding of Unicode symbols (\\u001F) 
 * Fixed. Invalid JSON causing <STING\_OFFSET\_TOO\_LARGE> exception and dump.

**/UI2/CL\_DATA\_ACCESS**

*  Fixed. Access to fields with special characters in the name (e.g "/BIC/YEAR") fails.

## Note [2786259][] - PL11 ##

**/UI2/CL\_JSON**

* Optimized. Performance lost, introduced in PL10 (note 2763854) when unescaping special characters (\\r\\n\\t\\")
 * Fixed. Short dump, with <STRING\_OFFSET\_TOO\_LARGE> when running GENERATE method with empty or invalid input

**/UI2/CL\_DATA\_ACCESS**

*  Fixed. Short dump, when accessing elements of null array

## Note [2763854][] - PL10 ##

*  **Fixed**: Deserialization and generation of the ABAP data from JSON strings with Unicode characters fail
 *  **Fixed**: Unescaping of \\\\t and \\\\n char combinations in strings handled incorrectly
 *  **Fixed**: GENERATE method fails on JSON attribute names containing spaces

## Note [2650040][] ##

*  **New**: Support for deserialization of OData *Edm.Guid* 
 *  **New**: Support of Enum data types in ABAP. From SAP\_BASIS 7.51, below - enums are ignored.
 *  **New**: Support of conversion exits for serializing and deserializing.
 *  **Fixed**: SERIALIZE method delivers an invalid JSON string, when NUMC type, filled with spaces is used.

## Note [2629179][] ##

*  **New**: JSON timestamp fields, serialized in OData *Edm.DateTime* format (e.g. "\\/Date(1467981296000)\\/") are supported, and properly deserialized in ABAP date, time or timestamp fields
 *  **New**: JSON timestamp fields, serialized in OData *Edm.Time* format (e.g. "PT10H34M55S") are supported, and properly deserialized in ABAP date, time, or timestamp fields
 *  **Fixed**: content is scrambled, when using GENERATE method for JSON objects with a name containing special characters (for example "\_\_metadata")
 *  **Fixed**: GENERATE method does not consider custom name mapping pairs passed as a parameter for CONSTRUCTOR or GENERATE methods
 *  **Fixed**: generation of very long integers (serialized numeric date) fails, due to I type overflow (you get 0 instead of an expected number)

## Note [2526405][] ##

*  **Fixed**: Deserialization of the inconsistent data (JSON string into ABAP table) leads to a short dump if the JSON string is empty.
 *  **Fixed**: Serialization of data with includes with defined suffix (RENAME WITH SUFFIX) dumps
 *  **Fixed**: GENERATE method fails, if the JSON object contains duplicate attributes and PRETTY\_MODE-CAMEL\_CASE is not used.
 *  **Fixed**: GENERATE method fails, if JSON object contains attribute names longer than 30 characters (allowed ABAP field length). Can also occur in case the name is shorter than 30 characters, but PRETTY\_MODE-CAMEL\_CASE is used.
 *  **New**: methods DUMP\_INT, DUMP\_TYPE, RESTORE\_TYPE, and RESTORE can be overridden now. So, you can introduce your own data type conversion on serialization and deserialization.
 *  **New**: now it is possible to pass the name mapping table as a parameter for the constructor/serialize/deserialize and control the way JSON names are formatted/mapped to ABAP names. This may help if you need special rules for name formattings (for special characters or two long JSON attributes) and standard pretty printing modes cannot help. With this feature, you may eliminate the need for the class extension and redefine PRETTY\_NAME and PRETTY\_NAME\_EX methods. 
 *  **New**: PRETTY\_NAME\_EX method extended to support the encoding of more special characters (characters needed in JSON names but that can not be used as part of ABAP name). The supported characters are: "!\#$%&\*-~/:|@.". Used with pretty\_mode-extended.
 *  **New**: [/UI2/CL\_DATA\_ACCESS][dynamic data accessor helper class] class for working with dynamic ABAP data object (generated with method /UI2/CL\_JSON=>GENERATE). The class can be used as a replacement for multiple ASSIGN COMPONENT language constructions.

## Note [2292558][] ##

*  **Fixed:** Empty JSON objects, serialized as entries of the table, are not deserialized into corresponding ABAP structures and further parsing of the JSON string after an empty object is skipped.
 *  **Fixed:** JSON fields containing stringified timestamp representation in ISO 8601 format are not deserialized properly in the corresponding ABAP timestamp field.

## Note [2300508][] ##

*  **Fixed:** Recursive (hierarchical) JSON objects cannot be deserialized.

## Note [2330592][] ##

*  **Fixed:** Partial serialization/deserialization of the JSON is not supported
 *  **New:** Extending of the class is supported
 *  **New:** Added support for serializing named include structures from ABAP as embedded sub-objects in JSON

## Note [2368774][1650141] ##

*  **Fixed:** /UI2/CL\_JSON creates unnecessary wrapping JSON object around value for name/value (table with 2 fields) tables with 1 unique key
 *  **Fixed:** Performance of serialization/deserialization of big tables into/from JSON associative arrays (maps) is slow
 *  **Fixed:** When trying to deserialize invalid (not matching) structure from JSON to ABAP dump OBJECTS\_MOVE\_NOT\_SUPPORTED occurs

## Note [2382783][] ##

*  **Fixed:** Unescape of symbol '\\' on JSON deserialization does not work
 *  **Fixed:** Short dump on serialization of classes with protected/private attributes
 *  **Fixed:** Short dump when serializing dynamic, not existing, types

## Note [2429758][] ##

*  **Fixed:** Short Dump on deserialization of classes with read-only attributes
 *  **New:** Serialization parameter added *NUMC\_AS\_STRING*, controlling the way how NUMC fields are serialized. The default is FALSE. If set to TRUE, NUMC fields serialized not as numbers, but as strings, with all leading zeroes. Deserialization works compatibly with both ways of NUMC serialized data.
 *  **New:** GENERATE and GENERATE\_INT methods are added for on the fly creation of ABAP data objects from JSON, without the need to have a predefined ABAP structure. Supports automatic creation of ABAP structures, tables, and elementary types, concerning JSON types. Supports structure/table nesting.
 *  **New:** DESERIALIZE\_INT method throws an exception CX\_SY\_MOVE\_CAST\_ERROR and stops further processing in case of malformed data found and STRICT\_MODE parameter in constructor set to TRUE.
 *  **New:** Added support of XSTRING as input for deserialization.

## Note [2480119][] ##

*  **New:** GENERATE method creates local custom class for deserialization (lc\_json\_custom), instead of standard /ui2/cl\_json
 *  **Fixed:** Internal tables are not initialized when deserializing JSON with empty arrays
 *  **New:** Deserialization into a field with REF TO data type, if the field is bound, using a referenced data type
 *  **New:** Deserialization uses automatic generation of the data if the field has "REF TO DATA" type and bound data is initial

[ISO8601]: https://wikipedia.org/wiki/ISO_8601
[1650141]: http://service.sap.com/sap/support/notes/2368774
[the blog of Horst Keller]: http://scn.sap.com/community/abap/blog/2013/07/04/abap-news-for-release-740--abap-and-json
[Does _UI2_CL_JSON work in ABAP Cloud]: https://answers.sap.com/questions/12699592/does-ui2cl-json-work-in-abap-cloud.html
[Return generic result via SAP RFC _performance]: https://stackoverflow.com/questions/54037544/abap-return-generic-result-via-sap-rfc-json
[RFC7159 -_The JavaScript Object Notation _JSON_ Data Interchange Format]: https://tools.ietf.org/html/rfc7159
[OData JSON Deserialize]: https://answers.sap.com/questions/12998367/odata-simple-json-deserialize.html?childToView=13007205
[2526405]: https://launchpad.support.sap.com/#/notes/2526405
[2330592]: http://service.sap.com/sap/support/notes/2330592
[dynamic data accessor helper class]: https://wiki.scn.sap.com/wiki/display/Snippets/Dynamic+Data+Accessor+Helper+Class+for+ABAP
[2944398]: https://launchpad.support.sap.com/#/notes/2944398
[2904870]: https://launchpad.support.sap.com/#/notes/2904870
[2870163]: https://launchpad.support.sap.com/#/notes/2870163
[2798102]: https://launchpad.support.sap.com/#/notes/2798102
[2786259]: https://launchpad.support.sap.com/#/notes/2786259
[2763854]: https://launchpad.support.sap.com/#/notes/2763854
[2650040]: https://launchpad.support.sap.com/#/notes/2650040
[2629179]: https://launchpad.support.sap.com/#/notes/2629179
[2292558]: http://service.sap.com/sap/support/notes/2292558
[2300508]: http://service.sap.com/sap/support/notes/2300508
[2382783]: http://service.sap.com/sap/support/notes/2382783
[2429758]: http://service.sap.com/sap/support/notes/2429758
[2480119]: http://service.sap.com/sap/support/notes/2480119