Reference Variables and Referenced Objects

Anonymous data objects and instances of classes (objects) are addressed in ABAP exclusively by means of references in reference variables. The corresponding asXML format is made up of subelements of values for named reference variables and, as standard, subelements of heap for the referenced objects (this can be set up using the OPTIONS DATA_REFS addition to the statement CALL TRANSFORMATION). The link between the reference elements and the object elements is set up by means of an XML reference mechanism, whereby a referenced object in the same XML document is identified with a key. The dynamic type of the reference variables for the object elements under heap is specified when serialization takes place, so that deserialization is unambiguous.

Named Reference Variables

A named reference variable is the only attribute of the corresponding subelement of values that is displayed without textual content. An attribute of a reference variable has the name href and the content "#key", where key is the unique key of an object in the element heap. An element of an initial reference does not have a href attribute or any other content. During serialization, the ABAP runtime environment sets the key key; any key is possible for deserialization.

Anonymous Data Objects

An anonymous data object that is a subelement of heap is displayed as follows:

  <asx:heap xmlns:nspace ...>
    <type id = "key" attr="...">...</type>
  </asx:heap>

The value of a subelement of this kind is displayed in the asXML display for named data objects or reference variables. If the anonymous data object itself is a non-initial reference variable, it references a further element of heap, according to the above rules. The element name type is the data type of the data object (or the dynamic type of the reference variables) specified as the XML schema type name from the name range nspace (see the table below). Attributes attr may define technical characteristics of the type. The mandatory attribute id contains the unique key key of the element, which is used to reference it from the display of the corresponding reference variables in values or heap.

The XML schema type name is constructed according to the following hierarchy:

1. If the data type of the data object is defined in the ABAP Dictionary, the XML schema type name is the name of the data type from the ABAP Dictionary in the corresponding name range (see table below).
2. If the data type is an elementary ABAP type, the XML schema type name is specified in the table below.
3. If the data type is defined as a component of a global or local class or interface, the XML schema type name comprises the name of the class or interface and the name of the data type, separated by a period (.). The corresponding name range (see table below) indicates whether the data type is a component of a global or local class or of an interface.
4. If the data type is a generic reference type defined with REF TO data or REF TO object, the XML schema type name is refData or refObject. Both of these have the name range http://www.sap.com/abapxml/types/built-in.
5. Otherwise, the XML schema type name is the name of a data type defined with TYPES and the corresponding name range (see table below) indicates where the data type is defined.

Before an XML schema type name can be constructed, the data type of the data object must have a name that can be used statically. If the data type only exists as a property of a data object and therefore only has a technical name, a treatable exception takes place during serialization.

The following table indicates the name ranges for the XML schema type names; types in the first column stands for http://www.sap.com/abapxml/types. The name ranges indicate where a data type is defined. Characters other than "a" through "z", "A" through "Z", "0" through "9", "_" or "-" are displayed as "!hex(c)" in the upper-case names PRG, ,CPOOL, FPOOL, TPOOL, METH, FUNC, FORM und CLASS, where hex(c) is the two-character hexadecimal display of the ASCII code for the character "c".

The following table lists the XML schema type names for elementary ABAP types. These are slightly different from the canonical XML schema data types, since the data type of anonymous data objects must be specified in full. The name ranges nspace for the elementary ABAP types for anonymous data objects are either xsd="http://www.w3.org/2001/XMLSchema" for general schema types or abap="http://www.sap.com/abapxml/types/built-in" for special ABAP schema types, for which some technical attributes must be specified.

The attribute maxLength defines the length for ABAP types with a generic length. The XML schema type abap:digits restricts the value range for an element to digits. The XML schema type abap:decimal specifies the length and fractional portions in the attributes totalDigits and fractionDigits. The length specification totalDigits defines the number of places between 1 and 31. In ABAP programs, the length of data objects of the type p is specified in bytes and the number of decimal places is calculated from 2×len-1. This means that the value of totalDigits is always odd in serialization. During serialization, an even value of totalDigits is implicitly increased by one.

Instances of Classes

The instance of a class (object) as a subelement of heap is displayed as follows:

  <asx:heap xmlns:nspace ...>
    <class id = "key">
      <part classVersion = "...">
        <name>...</name>
      </part>
      ...
    </class>
  </asx:heap>

The element name class is the XML schema type name of the class for the object (or the dynamic type of the reference variables) from the name range nspace (see table below) in block capitals. The mandatory attribute id contains the unique key key of the element, which is used to reference it when the corresponding reference variables are displayed in values. The subelements <part>...</part> contain the values of the instance attributes for individual object parts as subelements <name>...</name>. The individual object parts are defined by the serializable classes in the current inheritance hierarchy (see below).

The name range for the class name indicates how the class is defined. The following table lists the possible name ranges; classes in the first column stands for http://www.sap.com/apapxml/classes. The substitution rule for the name ranges for anonymous data objects (see above) also applies to the names >PRG, CPOOL and FPOOL.

The serializable values of a class instance (instance attributes or output parameters for a special method, see below) are displayed as the content or an attribute of <name>...</name> in the asXML display for named data objects or for reference variables, whereby name is the name of an instance attribute or an output parameter in block capitals. If the object is an interface attribute, the name is preceded by the name of the interface, separated by a period (.) so as to distinguish it from another class attribute of the same name. The same substitution rules that apply to all elements apply to the names.

The serializable values of a class instance are defined by implementing the system interface IF_SERIALIZABLE_OBJECT in the class. The system interface IF_SERIALIZABLE_OBJECT is a Tag-Interface. Its implementation indicates to the runtime environment whether or not a class can be serialized and allows it to declare certain other components in the class according to fixed syntax rules.

If the class does not implement the interface IF_SERIALIZABLE_OBJECT, the element class does not contain any subelements. All the instance attributes of a class in which the interface IF_SERIALIZABLE_OBJECT is implemented are serialized and deserialized to the interface by default. You can change this behavior by declaring special utility methods (see below). Static attributes are not taken into account during serialization or during deserialization (with the exception of the special constant SERIALIZABLE_CLASS_VERSION, see below).

Standard Behavior

If the class implements the interface IF_SERIALIZABLE_OBJECT, the element <class>...</class> contains at least one subelement <part>...</part></class>. These subelements correspond to individual serializable object parts and contain the presentations of the instance attributes for the corresponding object part in asXML format. An object part is defined by the class in which instance attributes are declared or an interface containing instance attributes is integrated. A serializable object class contains an object part for itself as well as object parts for all superclasses in the current path in the inheritance tree, up to and including the class that implements the interface IF_SERIALIZABLE_OBJECT. The name part is the name of the class in question. If it is a local class, its name is preceded by the prefix local, separated by a period (.) to distinguish it from a global class of the same name. Object parts of superclasses in which the interface IF_SERIALIZABLE_OBJECT is not implemented cannot be serialized and do not have a subobject part. This means that a class in which the interface IF_SERIALIZABLE_OBJECT is not implemented (either in the class itself or in a superclass) creates a blank XML element class during serialization.

During serialization, the XML elements part of the object parts are created from the superclasses to the subclasses and the XML elements of the instance attributes are created as standard in the order in which they are declared in the class.

Deserialization creates an object in the corresponding class but the instance constructor is not executed. All instance attributes have their initial value or the start value specified with the VALUE addition for the DATA statement after object creation. The values of the corresponding XML elements are entered in the instance attributes; the order of the object parts and attributes is irrelevant. Instance attributes without a corresponding XML element retain their value. Excess XML elements are ignored if they do not belong to a name range; otherwise, they create a treatable exception. When an element without part subelements is deserialized, the system does not create an object but initializes the target reference variable.

If a class implements the interface IF_SERIALIZABLE_OBJECT, you can declare the private constant SERIALIZABLE_CLASS_VERSION of the type i in each object part; that is to say, in each class involved in the inheritance tree. During serialization, the value of the constant is assigned to the attribute classVersion of the XML element part. A treatable exception is created during deserialization if the value of the attribute does not match the value of the constant in the class specified. An object can only be deserialized if the values match or if there is neither an attribute nor a constant. You can change this system behavior by declaring special utility methods.

Modified Behavior

All the instance attributes for an object part are serialized as standard regardless of their visibility, and the version of the class is checked. To change this behavior, you can declare and implement the instance methods SERIALIZE_HELPER and DESERIALIZE_HELPER in the relevant class for each object part. These methods can only be declared as private instance methods in classes that implement the interface IF_SERIALIZABLE_OBJECT. If you declare one of the methods, you must also declare the other and the interface must be defined as follows for the syntax check:

• The method SERIALIZE_HELPER can only have output parameters and the method DESERIALIZE_HELPER can only have input parameters with generic typing.

• There must be an input parameter for the method DESERIALIZE_HELPER with the same name for each output parameter for the method SERIALIZE_HELPER with the same typing. Additional input parameters for the method DESERIALIZE_HELPER must be optional.

• The method SERIALIZE_HELPER cannot have an output parameter with the name SERIALIZABLE_CLASS_VERSION, and the method DESERIALIZE_HELPER can have an optional input parameter of this name that is of type i. This parameter is supplied with the value of the attribute classVersion for the element part during deserialization, and the standard check on the version (see above) is skipped.

If the methods SERIALIZE_HELPER and DESERIALIZE_HELPER are declared in an object part, the instance attributes of the object part are not serialized and deserialized. Instead, the method SERIALIZE_HELPER is executed during serialization and the values of all the output parameters are written in asXML format as subelements to the corresponding element part in the specified order. Here, the name of a subelement is the name of the corresponding output parameter in block capitals. The method DESERIALIZE_HELPER is called during deserialization and the values of the subelements for the corresponding element part are transferred to the input parameters of the method with the same names. The order in which they appear is irrelevant and excess XML elements are ignored.