Author: Alexey Arseniev
Submitted: 20.11.2013
Other code samples from me:
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 bad.
So, I have written my own ABAP JSON serializer and ABAP JSON deserializer which has some key differentiates from other implementation.
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 to 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 to 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.
- elementary data types are converted if do not match: JavaScript integer can come into ABAP string or JavaScript string into ABAP integer and etc.
- Transformation takes into account property naming guidelines for JSON and ABAP so that camelCase names will be copied into corresponding CAMEL_CASE field if CAMELCASE field is not found in 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.
Usage example
DATA: lt_flight TYPE STANDARD TABLE OF sflight,
lrf_descr TYPE REF TO cl_abap_typedescr,
lv_json TYPE string.
SELECT * FROM sflight INTO TABLE lt_flight.
* serialize table lt_flight into JSON, skipping initial fields and converting ABAP field names into camelCase
lv_json = /ui2/cl_json=>serialize( data = lt_flight compress = abap_true pretty_name = /ui2/cl_json=>pretty_mode-camel_case ).
WRITE / lv_json.
CLEAR lt_flight.
* deserialize JSON string json into internal table lt_flight doing camelCase to ABAP like field name mapping
/ui2/cl_json=>deserialize( EXPORTING json = lv_json pretty_name = /ui2/cl_json=>pretty_mode-camel_case CHANGING data = lt_flight ).
* serialize ABAP object into JSON string
lrf_descr = cl_abap_typedescr=>describe_by_data( lt_flight ).
lv_json = /ui2/cl_json=>serialize( lrf_descr ).
WRITE / lv_json.
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
There are two static methods that are of most interest in common cases: SERIALIZE and DESERIALIZE. The rest of the public methods are done public only for reuse purpose 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 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 serialzed. If set to ABAP_TRUE, NUMC fields serialized not as integers, but as strings, with all leading zeroes. Deserialization works compatibly 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 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 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 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 ABAP structure contains more fields than in JSON object, a content of unmatched fields is preserved.
GENERATE : Generates ABAP object from JSON
- > JSON (string) - input JSON object string to deserialize
- > PRETTY_NAME (enum, optional) - mode, controlling how JSON field names mapped to ABAP component names. See description below.
- < RR_DATA (REF TO DATA) - reference to ABAP structure/table dynamically generated from JSON string.
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 "_" treated as word separator (and removed from the resulting name).
- EXTENDED - works the same way as CAMEL_CASE but in addition, 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 works 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 serialized into JSON arrays, but in some case, you will like to serialize them as associated 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, 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 become a property name and REMOVED from the associated object (to eliminate redundancy). If TABLE_LINE used as a unique key, all values of all fields construct key property name (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, property name 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 property name and rest of the fields will write object value of properties:
TYPES: BEGIN OF ts_record,
key TYPE string,
value TYPE string,
END OF ts_record.
DATA: lt_act TYPE SORTED TABLE OF ts_record WITH UNIQUE KEY key.
lv_json = /ui2/cl_json=>serialize( data = lt_exp assoc_arrays = abap_true ).
{
"KEY1": {
"value": "VALUE1"
},
"KEY2": {
"value": "VALUE2"
}
}
But if you will use 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:
lv_json = /ui2/cl_json=>serialize( data = lt_exp assoc_arrays = abap_true assoc_arrays_opt = abap_true ).
{
"KEY1": "VALUE1",
"KEY2": "VALUE2"
}
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 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 of property values can be expensive. To optimize performance, in this case, you can replace escapement code by 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 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 by corresponding methods.
Related pages
- Does /UI2/CL_JSON work in ABAP Cloud?
- Return generic result via SAP RFC (performance)
- RFC7159 - The JavaScript Object Notation (JSON) Data Interchange Format
The /UI2/CL_JSON code
Below you can find the code itself, you can use.
If you want to use the class globally, I suggest to create 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 new version of /UI2/CL_JSON from SDN or call UI Addon implementation if it is installed.
Custom ABAP to JSON, JSON to ABAP name mapping
By default, you control the way JSON names 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 name mapping table as a parameter for the constructor/serialize/deserialize and control the way JSON names formatted/mapped to ABAP names.
TYPES:
BEGIN OF tp_s_data,
sschema TYPE string,
odatacontext TYPE string,
shortened_abap_name TYPE string,
standard TYPE string,
END OF tp_s_data.
DATA: ls_exp TYPE tp_s_data,
lt_mapping TYPE /ui2/cl_json=>name_mappings,
lv_json TYPE /ui2/cl_json=>json.
lt_mapping = VALUE #( ( abap = `SSCHEMA` json = `$schema` )
( abap = `ODATACONTEXT` json = `@odata.context` )
( abap = `SHORTENED_ABAP_NAME` json = `VeeeeryyyyyLooooongJSONAttrbuuuuuuuuuteeeeeeeeeee` ) ).
lv_json = /ui2/cl_json=>serialize( data = ls_exp name_mappings = lt_mapping ).
Serialization/deserialization of hierarchical/recursive data
Handling of 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:
TYPES:
BEGIN OF ts_node,
id TYPE i,
children TYPE STANDARD TABLE OF REF TO data WITH DEFAULT KEY,
END OF ts_node.
DATA: lv_exp TYPE string,
lv_act TYPE string,
ls_data TYPE ts_node,
lr_data LIKE REF TO ls_data.
ls_data-id = 1.
CREATE DATA lr_data.
lr_data->id = 2.
APPEND lr_data TO ls_data-children.
Such 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 parser will not be able to deduce the type of the data needs to be created in children table. But serialization will work fine:
lv_exp = '{"ID":1,"CHILDREN":[{"ID":2,"CHILDREN":[]}]}'.
lv_act = /ui2/cl_json=>serialize( data = ls_data ).
cl_aunit_assert=>assert_equals( act = lv_act exp = lv_exp msg = 'Serialization of recursive data structure fails' ).
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:
CLASS lcl_test DEFINITION FINAL.
PUBLIC SECTION.
DATA: id TYPE i.
DATA: children TYPE STANDARD TABLE OF REF TO lcl_test.
ENDCLASS. "lcl_test DEFINITION
In that manner, you are able to 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
DATA: lo_act TYPE REF TO lcl_test,
lo_exp TYPE REF TO lcl_test,
lv_json TYPE string,
lo_child LIKE lo_data.
CREATE OBJECT lo_exp.
lo_exp ->id = 1.
CREATE OBJECT lo_child.
lo_child->id = 2.
APPEND lo_child TO lo_exp->children.
lv_json = /ui2/cl_json=>serialize( data = lo_exp ).
ui2/cl_json=>deserialize( EXPORTING json = lv_json CHANGING data = lo_act ).
Remark: There are some constraints for data design exist in regard to the deserialization of objects:
- You cannot use constructors with obligatory parameters
- References to interfaces will be not deserialized
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 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 invalid JSON block, it may destroy whole resulting JSON string at the end.
Below you can find examples for partial serialization/deserialization.
Serialization:
Results in:
Deserialization:
Results in the following ABAP data:
/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 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 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 “_” symbol. To output “_” symbol, use 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
- > LENGHT (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
- > JSON (JSON) – JSON string to deserialize
- > LENGHT (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
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 additional boolean type 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:
Results in the following JSON:
Deserialization of an untyped (unknown) JSON object
If you need to deserialize a JSON object with unknown structure, or you do not have passing data type on ABAP side or data type of the resulting object may vary, you can generate ABAP object on the fly, using 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:
DATA: lv_json TYPE /ui2/cl_json=>json,
lr_data TYPE REF TO data.
FIELD-SYMBOLS:
<data> TYPE data,
<struct> TYPE any,
<field> TYPE any.
lv_json = `{"name":"Key1","properties":{"field1":"Value1","field2":"Value2"}}`.
lr_data = /ui2/cl_json=>generate( json = lv_json ).
" OK, generated, now let us access somete field :(
IF lr_data IS BOUND.
ASSIGN lr_data->* TO <data>.
ASSIGN COMPONENT `PROPERTIES` OF STRUCTURE <data> TO <field>.
IF <field> IS ASSIGNED.
lr_data = <field>.
ASSIGN lr_data->* TO <data>.
ASSIGN COMPONENT `FIELD1` OF STRUCTURE <data> TO <field>.
IF <field> IS ASSIGNED.
lr_data = <field>.
ASSIGN lr_data->* TO <data>.
WRITE: <data>. " We got it -> Value1
ENDIF.
ENDIF.
ENDIF.
A nice alternative, using dynamic data accessor helper class:
DATA: lv_json TYPE /ui2/cl_json=>json,
lr_data TYPE REF TO data,
lv_val TYPE string.
lv_json = `{"name":"Key1","properties":{"field1":"Value1","field2":"Value2"}}`.
lr_data = /ui2/cl_json=>generate( json = lv_json ).
/ui2/cl_data_access=>create( ir_data = lr_data iv_component = `properties-field1`)->value( IMPORTING ev_data = lv_val ).
WRITE: lv_val.
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 type REF TO DATA and name of the field shall match 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 new referenced value based on the referenced type.
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 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 source ABAP data type is known in deserialization scope (global and local types are "visible").
See example below:
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 details - I do not know them. 
Was just a small test of me.
Version History
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 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 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 name mapping table as a parameter for the constructor/serialize/deserialize and control the way JSON names 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 of 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 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
- 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 predefined ABAP structure. Supports automatic creation of ABAP structures, tables, and elementary types, with respect to 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
55 Comments
Former Member
Alexey - works ok , thanks for sharing. Worth trying.
Alexey Arseniev
Use it with pleasure
Former Member
Thanks for this class... we encountered an issue using it... apparently the JSON in Javascript needs to have the number surrounded by double-quotes also...
I added them in the concatenate in the macro and it works like a charm. Thanks
Sunil Kumar Verma
Hi Gerg,
I'm facing the same problem.
Could you please post how did you overcome the issue. In which macro and how did you add the concatenate statement?
Thanks in advance,
Sunil
Gregory Tutt
Hey mate, sorry my account has been changed... anyway, we made some changes but I think Alexey already provided the same solution.
Alexey Arseniev
Hi Greg,
based on my knowledge, and on JSON RFC numbers shall not be surrounded by quotes.
I assume in your case you need a special handling, while JS on client side expect to have string instead of number. The proper way will be then to change ABAP structure in such way it corresponds expected format (so change base data type of attribute from I based to N based for example).
Can you please post here an example that does not work?
BR, Alexey.
Former Member
Hey,
Unfortunately, we can not change the structure as it is dynamic. We actually use JSON because oData is even less flexible. The issue is indeed in the JavaScript client that does not recognise the object during parsing.
Here is an example:
var test = {
"Data" : [ {
"COL_EMPNO" : 00000001,
"COL_MANM1" : "Roberts, Marcia",
"COL_MADOB" : 19630416,
}]
};
JSON.parse(test) fails... Error: Unexpected number
Alexey Arseniev
Hi Greg,
is this last comma after 19630416, is generated or you just add it in your example? If this come from serializer - it is a bug. But I think JSON parser on JS side shall overcome it.
I think reason for error is: COL_EMPNO" : 00000001 .
Please try example like this if it works:
JSON.parse( {
"Data" : [ {
"COL_EMPNO" : 1,
"COL_MANM1" : "Roberts, Marcia",
"COL_MADOB" : 19630416
}]
}) ;
If this 00000001 is a reason, I will try to fix it and update the parser. The workaround on your side until I update parser will be to use not NUMC type but I for COL_EMPNO.
BR, Alexey.
Former Member
Hello Alexey / Greg,
Accidentally came across this blog; but found the information very helpful. Thank you for the blog and comments.
We had written a custom JSON parser some time ago and I was interested in the standard SAP utility.
But I have encountered 2 issues while testing this;
One: as Greg pointed out, when the output JSON string is parsed with external parsers, they have errors as the numbers need to be in quotes. After reading https://tools.ietf.org/html/rfc7158 I see that JSON numbers need not be in quotes but they cannot have leading zeros. So I guess, the solution could be either to have quotes around the number values or to have SAP's character based number formats without leading zeros.
Two: the standard utility ( /ui2/cl_json=>serialize ) dumps when you have a meta-structure via the include command and without a "group" name. I don't know if this is fixed with a higher component version but you can try with the example below.
The below dumps for me :
types: begin of ty_s_str01,
c01 type c length 1,
c02 type c length 1,
end of ty_s_str01.
types: begin of ty_s_str02,
c03 type c length 1.
include type ty_s_str01 .
types: end of ty_s_str02.
data ls_strc type ty_s_str02.
data lv_json type string.
ls_strc-c01 = 'X'.
ls_strc-c03 = 'X'.
lv_json = /ui2/cl_json=>serialize( data = ls_strc
compress = abap_true
pretty_name = abap_true ).
Now replace the definition of ty_s_str02 as below and it should work.
types: begin of ty_s_str02,
c03 type c length 1.
include type ty_s_str01 as str01.
types: end of ty_s_str02.
The same applies to a DDIC structure having an include without a "group" name.
Hope this helps; just thought that I would point it out.
Thanks.
Alexey Arseniev
Hi John,
the "SAP standard", I think, will be to use CALL TRANSFORMATION with JSON format: I have added the example in the bottom of the article of how to serialize data with it. But, as I have written the code will only work from 7.02 and one does not have too much freedom (easy way) to control output format. But it is faster.
If one would use /UI2/CL_JSON you have nicer consumption + more functionality but less performance (while it is pure ABAP).
Back to problems.
1) output of the leading zeroes it is a bug I will correct.
2) support of INCLUDE is known bug, already fixed in delivered /UI2/CL_JSON but not yet here. I will update code together with fix for leading zeroes soon.
BR, Alexey
Former Member
Hi Alexey,
Thank you for the updates and information on using the transformation.
I was aware of using transformation but it was good to see an example.
About the problems, not a show stopper for me; instead I just thought I would point these out.
Thanks.
Alexey Arseniev
Hi Guys,
I have corrected both erorrs: with leading zeroes and include structures. Try new version.
BR, Alexey.
Alexey Arseniev
Added fix for type conversion overflow on deserializing.
Former Member
Hello,
I have some wish to improvement for /UI2/CL_JSON.
If you want deserialize some character value to numeric datafields than program dump to system error. It is not planed issue, but sometimes consume data are come with bad format.
For example:
try.
data: json type string.
json = '{ "userName": "sap", "password": "123456" }'.
data: begin of user,
username type string,
password type int4,
end of user.
/ui2/cl_json=>deserialize( exporting json = json
changing data = user ).
catch cx_root.
endtry.
Catch cx root is not catched a prohras has been terminaded.
System analysis:
In statement "'REPLACE", only character-type data objects are supported at
argument position "DATA'".
In this case, operand "DATA'" has the non character-type type "I".
Method RESTORE_TYPE:
73 WHEN `"`. " string
74 IF data IS SUPPLIED.
75 eat_string data.
76 " unescape string
>>>> REPLACE ALL OCCURRENCES OF `\"` IN data WITH `"`.
If I consume some JSON data, I can´t reduce any mistake.
Could you please implement some program exception handler or as advance implement JSON schema for validate input.
Thanks.
Alexey Arseniev
Hi Jan,
accepted. Please check new version.
BR, Alexey.
Former Member
You are so quick. It´s function great. Thanks.
Former Member
Agree, I bumped into the similar issue, before I saw Alexey's correction the original in method restore_type() is
WHEN `"`. " string
IF data IS SUPPLIED.
eat_string data.
REPLACE ALL OCCURRENCES OF `\"` IN data WITH `"`. " unescape string
I just changed it to
WHEN `"`. " string
IF data IS SUPPLIED.
eat_string data.
type_descr = cl_abap_typedescr=>describe_by_data( data ).
IF type_descr->type_kind EQ cl_abap_typedescr=>typekind_CHAR
REPLACE ALL OCCURRENCES OF `\"` IN data WITH `"`. " unescape string
...
I had to copy this class to make changes...
George
Alexey Arseniev
Hi George,
wrapping of the the \UI2\CL_JSON class in you own class as local is a preferred way if you want to protect your code from changes, which can happen if standard delivered \UI2\CL_JSON will be modified in a way, that does not fit your purposes. And you can always copy actual version of code from here.
About suggest change by you: please use actual one from the article. It is more robust.
BR, Alexey.
Alexey Arseniev
Former Member
Another item: in /UI2/CL_JSON_SERIALIZER, method GET_VALUES(),
ELSE.
* null
IF mv_case_type = /ui2/if_serialize=>c_case_type-camel_case_s.
IF <lv_field>-descr->type_kind = cl_abap_typedescr=>typekind_struct1
OR <lv_field>-descr->type_kind = cl_abap_typedescr=>typekind_struct2
OR <lv_field>-descr->type_kind = cl_abap_typedescr=>typekind_dref.
DATA lv_u TYPE string.
DATA lv_l TYPE string.
FIND REGEX '([a-z])([a-z]*)' IN lv_field_name SUBMATCHES lv_u lv_l.
TRANSLATE lv_l TO LOWER CASE.
TRANSLATE lv_u TO UPPER CASE.
CONCATENATE lv_u lv_l INTO lv_field_name.
endif.
endif.
CONCATENATE '"' lv_field_name '":null' INTO lv_value.
ENDIF.
here, the situation I got is the interface does not exepct "null". so I make change to
CONCATENATE '"' lv_field_name '":' INTO lv_value.
then there is another issue,
in this line:
ASSIGN COMPONENT sy-tabix OF STRUCTURE <lv_data> TO <lv_value>.
IF <lv_field>-numeric = abap_true.
if this component of structure <lv_data> is a table with no entries, then <lv_value> will be considered initial.
once this <lv_value> is considered initial, it will come to the following code:
ELSEIF <lv_value> IS INITIAL.
IF <lv_field>-descr->type_kind = cl_abap_typedescr=>typekind_char AND
<lv_field>-descr->length = 2 .
* IF <lv_field>-name <> 'NUMBER_FORMAT'.
CONCATENATE '"' lv_field_name '":" "' INTO lv_value.
ELSE.
* null
IF mv_case_type = /ui2/if_serialize=>c_case_type-camel_case_s.
IF <lv_field>-descr->type_kind = cl_abap_typedescr=>typekind_struct1
OR <lv_field>-descr->type_kind = cl_abap_typedescr=>typekind_struct2
OR <lv_field>-descr->type_kind = cl_abap_typedescr=>typekind_dref.
DATA lv_u TYPE string.
DATA lv_l TYPE string.
FIND REGEX '([a-z])([a-z]*)' IN lv_field_name SUBMATCHES lv_u lv_l.
TRANSLATE lv_l TO LOWER CASE.
TRANSLATE lv_u TO UPPER CASE.
CONCATENATE lv_u lv_l INTO lv_field_name.
endif.
endif.
CONCATENATE '"' lv_field_name '":null' INTO lv_value.
ENDIF.
then I will miss the square bracket [ ] from the output. I did a fix here as well, to do something like check
<lv_field>-descr->type_kind = cl_abap_typedescr=>typekind_table.
if it is, then copy your code
GET REFERENCE OF <lv_value> INTO lr_dref.
lo_tabledescr ?= <lv_field>-descr.
lv_value = serialize_table( io_tabledescr = lo_tabledescr ir_data = lr_dref ).
CONCATENATE '"' lv_field_name '":' lv_value INTO lv_value.
so I think when <lv_data> is initial, we need to think it further to make changes.
overall, thank you Alexjey, this is a very good program, runs very fast,easy to debug, thank you very much. it is preferred to transformation as this is dynamic.going forward, I am wondering if we can determine the export abap structure at runtime.
George
Alexey Arseniev
Hi George,
do not use class /UI2/CL_JSON_SERIALIZER - it is deprecated and not supported any more. Just left in because of compatibility reasons.
If you need portable class for JSON serialization/deserialization /UI2/CL_JSON is proper one.
About the: "I am wondering if we can determine the export abap structure at runtime".
This feature is not supported, because I do not see a reason for it. If you deserialize something, you still need to be able to read it in typed way in ABAP. So, the idea that you need to know target data structure (or at least partial structure, it will also work) to deserailize JSON and that work with you typed target.
But if you for some reason need ability to deserilaize JSON in source ABAP structure in generic way, you may extend both serialize/deserilaize methods (you any way have copied the class) and wrap outputs/inputs of /UI2/CL_JSON data by technical meta data describing source ABAP structure and use this information during deserialization. For example:
Error rendering macro 'code': Invalid value specified for parameter 'lang'TYPES: BEGIN OF ts_json_meta, abap_type LIKE cl_abap_typedescr=>absolute_name, data TYPE string, END OF ts_json_meta. DATA: lt_flight TYPE STANDARD TABLE OF sflight, lv_json TYPE string, lo_data TYPE REF TO data, ls_json TYPE ts_json_meta. FIELD-SYMBOLS: <data> TYPE any. SELECT * FROM sflight INTO TABLE lt_flight. " serialize table lt_flight into JSON, skipping initial fields and converting ABAP field names into camelCase ls_json-data = /ui2/cl_json=>serialize( data = lt_flight compress = abap_true pretty_name = /ui2/cl_json=>pretty_mode-camel_case ). ls_json-abap_type = cl_abap_typedescr=>describe_by_data( lt_flight )->absolute_name. lv_json = /ui2/cl_json=>serialize( data = ls_json compress = abap_true pretty_name = /ui2/cl_json=>pretty_mode-camel_case ). WRITE / lv_json. CLEAR: ls_json, lt_flight. " deserialize JSON string json into internal table lt_flight doing camelCase to ABAP like field name mapping TRY. /ui2/cl_json=>deserialize( EXPORTING json = lv_json pretty_name = /ui2/cl_json=>pretty_mode-camel_case CHANGING data = ls_json ). CREATE DATA lo_data TYPE (ls_json-abap_type). ASSIGN lo_data->* TO <data>. /ui2/cl_json=>deserialize( EXPORTING json = ls_json-data pretty_name = /ui2/cl_json=>pretty_mode-camel_case CHANGING data = <data> ). CATCH cx_sy_move_cast_error. CLEAR: lo_data. ENDTRY. IF lo_data IS NOT INITIAL. " check here lo_data BREAK-POINT. ENDIF.Best regards,
Alexey.
Former Member
thank you Alexey! completely agree with you
George
Taryck Bensiali
Hi all,
This serialization do not works with REF TO DATA which are supposed to be objets ==> CX_SY_MOVE_CAST_ERROR.
Do you have any solution that works with "REF TO DATA" ?
Taryck.
Former Member
do you mean the type mismatch? can you give an example of what you expect to be the input parameter, type ref to data?
Alexey Arseniev
Hi Taryck,
as George mentioned: please provide test example and expected result. I will check.
In general serializations of TYPE REF shall also work (as in example above for ref to LT_FLIGHTS) but I have not done extensive tests for such use cases.
Best regards,
Alexey
Taryck Bensiali
OK here it is :
data t_param type abap_parmbind_tab.
data s_param like line of t_param.
Data interger type int4.
Data str type string.
s_param-name = 'INTERGER'.
S_param-kind = 'E'
Interger = 3.
get reference of integer into S_param-value.
insert s_param into table t_param.
str = /ui2/cl_json(data = t_param).
Error is in method dump because when "type_desc->kind = Kind_ref" you assume this is an object. If you looked at type_desc->type_kind you'll see it's dref type kind...
Alexey Arseniev
Hello Taryck,
thanks for example. Yes, I see - will try to extend that soon.
As you know, this is not an official SAP JSON parser, so you can copy and extend it as you like and share your suggestions here. All will appreciate valuable contribution!
BR, Alexey.
Taryck Bensiali
Hi,
OK thanks. How could it be unofficial and been part of SAP's packages ?
I've try to find solutions for serializing and most of all deserializing Ref to Data but I do not find any solution.
I've try CALL TRANSFORMATION ID Options data_ref = 'embedded' ... Which is OK for Serialization but fails on deserialize...
Alexey Arseniev
The /UI2/CL_JSON class is created to solve specific needs of UI2 services and not intended to be generic solution for anyone need JSON serialize/deserialize abilities (see introduction part of the article). For generic solution use CALL TRANSFORMATION or request something from Gateway colleges going official way with messages, dev requests etc. The same you can also try with /UI2/CL_JSON requests.
Here I am presenting local copy anyone can modify and try to help people with their questions & requirements. If I have time and see the need.
How you imagine deserializing of the value from typeless JSON to generic data reference in ABAP (looking back on your example)?
Taryck Bensiali
Well, I imagine that for CALL TRANSFORAMTION because data type is present in the XML.
For JSON I'm not an expert so I expect this could be done. But If only data are stored without any data definition well I understand that it will be almost impossible...
Alexey Arseniev
Hi Taryck,
I have updated the code to support serialization of the data references. Deserialization, as I have already tried to explain is not possible in generic case, while JSON does not include type information + deserialization shall support any JSON but not only one previously serialized with it. But at least code provided will support your example, with deserialization of simple types in similar kind (so it can desterilize string, Boolean and integer, but cannot of course support deserialization in some specific type of original structure).
Please verify.
Best regards,
Alexey
Taryck Bensiali
Hi,
It's OK. Your example :
{"ABSOLUTE_NAME":"\\TYPE=%_T00004S00000000O0000012480","ADMIN_TAB":"\\TYPE=%_T00004S00000000O0000012480", "ADMIN_TAB_LINE":"\\TYPE=%_T00004S00000000O0000012480"
Provide type definition so I tought JSON could handle type definition also.
Thanks.
Alexey Arseniev
Hello Taryck
probably mentioned example is a little bit missleading. It purpose was only to show, that you can serialize ABAP Object also, but it does not serialize JSON type information, it is just dump of CL_ABAP_TYPEDESCR class which was used as easy example.
BR, Alexey
Former Member
Hello Alexey,
I see that my code is livin inside SAP standard code. One question. I checked the usage of /UI2/CL_JSON. It's mainly used in NWBC. Is there any other implementation of this class in SAP Standard? You can write me direct message. I tried to send you via SCN but couldn't since you are not following me.
Kind Regards,
Ümit Coşkun Aydınoğlu
Alexey Arseniev
Hi Coşkun,
/UI2/CL_JSON is part of SAP coding, but not a standard class for serialization/deserialization of the JSON in SAP. We use it in NWBC and in Fiori and it is public class and part of the UI Addon. So any one may use it. Do not know other usages but know they exist. There may be some copies of the class encapsulated as local classes, following guidelines I gave in article, so it may be even more usages.
BR, Alexey.
Former Member
Hi Alexey,
is there any way to set Pretty Printing in UpperCamelCase instead of lowerCamelCase ?
Best regards
Diego
Alexey Arseniev
Hi Diego,
there is no such pretty printing option, but it is easy to built in if you use local copy of the class as suggested:
when pretty_mode-ucamel_case.
&3 = pretty_name( &1 ).
TRANSLATE &1(1) TO UPPER CASE.
But to be honest, you can do it even easier, without any modification. What you need is just start all your fields with "_" and use camel_case as formating option. I assume it will result in formatting you need.
BR, Alexey.
Former Member
Hi Alexey,
I've tried what you've suggested "start fields with '_' " but it does not work, that's the reason of my question. Thanks anyway, great work!!
Best Regards
Diego
Alexey Arseniev
I would say it is a bug, that it does not work. Actually there is dedicated code blocking usage of _ in-front of the names, that I now treat as non needed...
The quick correction would be to replace method PRETTY_NAME by following code:
Error rendering macro 'code': Invalid value specified for parameter 'lang'Former Member
Hi Again,
I've realized that the class produces invalid JSON when DATA parameter has non-printable characters.
You need to add content cleaning something like :
replace all occurrences of regex '[^[:print:]]+(?!$)' in STRING with ` `.
replace all occurrences of regex '[^[:print:]]+$' in STRING with ''.
P.S : It's good to know that my code lives in essentials part of SAP like nwbc and fiori.
Kind Regards,
Coşkun
Alexey Arseniev
Hello Coskun,
thanks for the feedback.
Can you be more concrete and provide an example to check? Do you mean SERILAIZE or DESERIALIZE?
Why not-printable characters is a problem for JSON? Do you mean they are not allowed inside string literals? But for unicode text processing it is not a problem. The only " shall be escaped.
In addition to that, such un-transparent replace will lead to data loss, which is not so obvoious to consumer of the API. If one knows he need to transport some binary or not well formed content, he needs to expose data as XSTRING, which will be then base64 encoded, but this does not lead to any data loss. Or do preliminary excapment by himself, before serialization.
And I have not understood suggested regular expressions:
What does this mean '[^[:print:]]+(?!$)'
And this '[^[:print:]]+$' :
I think something like this will be enough, but I will not build that in, while lead to data loss:
replace all occurrences of regex '[^[:print:]]' in STRING with ` `.
Best regards,
Alexey.
Bilen Cekic
Hi Alexey,
Thank you again i finished several project with this class
. I have a question.
I need to write a data integration layer but will transfer millions of rows sometimes. I testested 100K record is fine but is it possible to remove column duplication like json.hpack ?
https://github.com/WebReflection/json.hpack/wiki
I want to send columns in an array and remaning values as value only without column name.
Another questions is what is the minimum NW version that i can use this class ? (assume i make a zcopy)
Alexey Arseniev
Hello Bilen,
Sorry for the delay with response.
The code is tested from SAP_BASIS 700, but I think it can be used even earlier. There is nothing special, that requires something modern. Maybe from SAP_BASIS version that introduced regular expressions.
About your request. I have checked hpack. The idea looks interesting, but I do not know, how much are the size benefits when once compares hpack and standard gzip compressing over the content. Maybe it not worth it. Have not found benchmarks. The number of stars is OK, but last update 3 years ago. That is also not very convincing.
That was an answer if I would implement that in standard
Maybe if I would get more requests for it.
Also, I did not get, how to recognize real array JS compared to a compressed collection hpack object. Looks like that you can not mix standard content and hpack collections...
But if you would like to implement it by yourself, in your zcopy, it shall be more or less easy, at least for serialization. Depending on compression level you need.
It is method DUMP_INT, line 149 to 169.
The actual column name added in line 160 - so just comment it (that is for your request, compression level 0, just skip column name):
CONCATENATE <symbol>-header lv_itemval INTO lv_itemval.
In addition to that, you would need to add as first line "header" row. By looping over lt_symbols table and collecting "name" components. After inserting it on lv_itemval.
BR, Alexey.
Bilen Cekic
Thanks a lot man! Yes in 7.0.3 i tried and very few fixes are required. Problem is in 7.0.3, REST classes are totally missing :/
Bilen Cekic
Hi Alexey,
Recently i had an issue regarding an internal table created dynamically. Here is the error;
CREATE DATA: The specified type (\TYPE=%_T00011S00000261O0000001280) is not a valid data type.
Do you have any solution for this ?
Bilen Cekic
Oh man sorry my bad. I noticed my class version was old, just updated dump_int method and working fine.
Lucius Allen
Hi Alex.
I have some JSON text that contains a deep structure and table. After executing "lr_data = /ui2/cl_json=>generate( EXPORTING json = lv_json ).", how can I access variables "d":"2018-09-25" and "v":1.29848?
here is the JSON text:
{
"terms": {
"url": "https://www.bankofcanada.ca/terms/"
},
"seriesDetail": {
"FXUSDCAD": {
"label": "USD/CAD",
"description": "US dollar to Canadian dollar daily exchange rate"
}
},
"observations": [
{
"d": "2018-09-25",
"FXUSDCAD": {
"v": 1.2948
}
}
]
}
Alexey Arseniev
Hi Allen
Sorry, I just got a notification letter about your comment :/.
Probably it would be already too late, but nevertheless, I will answer
The answer is: you need to use dynamic programming, accessing data components by name. Traversing structures up-down. With a lot of surrounding checking code, for component existence, assignment result etc. See an example in the chapter "Deserialization of untyped (unknown) JSON object".
That is why it is always better to prefer SERIALIZE method to defined data structure instead of GENERATE.
But as I also mentioned, I have created and published (it same note as /UI2/CL_JSON) class /ui2/cl_data_access that can simplify it in some way. See the same chapter for example or a more detailed article here: Dynamic Data Accessor Helper Class for ABAP.
Particularly for your example, it would be like this:
DATA: lr_data TYPE REF TO data,lv_val TYPE f.lr_data = /ui2/cl_json=>generate( json = lv_json )./ui2/cl_data_access=>create( ir_data = lr_data iv_component = `observations[1]-FXUSDCAD-V`)->value( IMPORTING ev_data = lv_val ).Best regards,
Alexey.
Lucius Allen
Thanks Alex for response. That is exactly the way I would anticipate referencing the data. However, the complex structure was not de-constructed in the expected way. See below for how the routine returned the data. Try it for yourself with the JSON text. I want to use this in my production system so I wanted to run it by you in case you would have a fix for it.
here is the JSON text:
{
"terms": {
"url": "https://www.bankofcanada.ca/terms/"
},
"seriesDetail": {
"FXUSDCAD": {
"label": "USD/CAD",
"description": "US dollar to Canadian dollar daily exchange rate"
}
},
"observations": [
{
"d": "2018-09-25",
"FXUSDCAD": {
"v": 1.2948
}
}
]
}
Alexey Arseniev
Hi Allen,
by me - works. I think it is the old issue I have already fixed for GENERATE method when components were scrambled...
Please apply all related notes (listed in the blog above in Version History section) and retest.
My test code:
lv_json = `{"terms":{"url":"https://www.bankofcanada.ca/terms/"},"seriesDetail":{"FXUSDCAD":{"label":"USD/CAD","description":"US dollar to Canadian dollar daily exchange rate"}},` && '"observations":[{"d":"2018-09-25","FXUSDCAD":{"v":1.2948}}]}'. DATA(lr_data) = /ui2/cl_json=>generate( lv_json ). DATA(lo_data) = /ui2/cl_data_access=>create( ir_data = lr_data ). DATA: l_data TYPE string, exchange_date TYPE d, exchange_rate TYPE f. lo_data->at('observations[1]-d')->value( IMPORTING ev_data = l_data ). REPLACE ALL OCCURRENCES OF '-' IN l_data WITH ''. exchange_date = l_data. lo_data->at('observations[1]-FXUSDCAD-v')->value( IMPORTING ev_data = exchange_rate ).Best regards,
Alexey.
Lucius Allen
I applied the notes. All is well now. Thanks Alexey!!
Dmitrii Sharshatkin
Hi All,
Was looking into a similar topic. I was needing to convert unknown JSON into string table.
I found a way to do just within two lines of code (excluding the data declarations):
data: lv_json type string.
data: lr_node type ref to if_ixml_node.
data: lt_xml_table type table of smum_xmltb.
lr_node ?= cl_fpm_chart_json_generator=>json_to_xml( lv_json ).
perform get_element(lsmumf01) tables lt_xml_table using lr_node.
BR, Dima
Alexey Arseniev
Hello All,
can someone post a comment here? While I got a message that commenting is not working anymore.
If not possible write me a personal message on SDN for @alexey.arseniev.
BR, Alexey.
Wolfgang Röckelein
Hi All,
seems it is possible again to comment here!
For all of you who want to have /UI2/CL_JSON accessible in ABAP Cloud, please vote on https://influence.sap.com/sap/ino/#/idea/234724 for this!
Many Thanks!
Alexey Arseniev
Hi Wolfgang,
thanks for confirming that comments are again working
I have talked with a college from SDN, regarding commenting and he said that it is probably because the page is too long, and I need to split or migrate it. But seems, that such a conversation still helped, indirectly
Also, I appreciate your efforts for collecting votes for enabling class for ABAP Cloud whitelisting. I have checked with Steampunk colleges already possibility for releasing of the class and in general, they are OK with it. But there are now some other formal reasons why the class can not be released and even further developed :/ I hope votes you have collected may help to prove the need for further development of the class.
Would be also nice to know the actual list of class consumers, by customers in on-premise...
BR, Alexey.