Skip to Content

Abstract


This Weblog presents a technique that allows serialization and deserialization of arbitrary data i.e. data which comes without a concrete type and therefore can’t be stored in a relational database.

Contents


    • Prerequisites
    • Introduction
    • Technical Details
    • The Solution
    • Conclusion


Prerequisites


Average knowledge of general ABAP programming, ABAP Types,  ABAP Objects and ABAP runtime-type-identification (RTTI) is helpful. Basic understanding of the serialization technique is required – the Weblog ABAP Serialization – Part I: Quick-n-easy gives an introduction to this topic.

Introduction


The general advantages of serialization are easy to achieve persistence and – if your programming is purely object oriented – no need to change the paradigm. This change is necessary when it comes to saving object oriented data in a relational database.

Two downsides (too bad that useful things never seem to come without these…) are that you can’t search for specific parts of the saved data like you could in a database and the fact that ‘partial loading’ is impossible – i.e. you can only restore everything or nothing which can in certain situations be critical when it comes to main memory consumption.

But in this Weblog I will present a solution to the problem of persistence for arbitrary/generic data. It should be quite obvious that it is impossible to save anything you know nothing about in a relational database. You always need some kind of structure to save something in a rdbms. The solution to this problem is based on the serialization technique.

Before I start with the technical details I want to give you an example in which the solution can be useful – even life-saving.

Dynamic method (or function module) calls in ABAP support parameter tables which are needed when the parameters should be passed dynamically too. Imagine you built a class that represents a general (method/function module) parameter. Obviously you need a generic datatype to store the actual value of your parameter. Next we want to save some instances of the generic parameter class persistently. How can we save the value of the parameter when it’s type is generic ? This question will be answered soon.


Technical Details


The only generic datatype which can be used everywhere in ABAP (including ABAP Objects) is ‘REF TO DATA’. So it’s not really a surprise to see that the parameter tables in ABAP dynamic method (or function module) calls also use this generic datatype.

In the solution we will start with a simple integer and then store it in a variable of type ‘REF TO DATA’. This variable could represent the value of a generic parameter like the one discussed in the introduction. Next we will serialize the generic variable to XML restore it afterwards and retrieve the integer value again. For the last step to function properly we need field symbols and runtime-type-identification.


The Solution


One remark before I start on the details of the implementation: to keep the code readable I will leave out nothing but I won’t structure it (in form of different classes or function modules) either.

Serialization


We start by declaring some data first:

The integer could be the dynamic parameter for a dynamic function call. The reference could be used in a generic parameter class to hold the actual value of the parameter.

Next we have to get a reference to the integer into the reference:


At this point it’s important to note that you can get a reference of everything including internal tables and every DDIC structure.
Second you might ask why we dereference the data into a field symbol if we have just retrieved and stored the reference to the data. The answer is that the interface to the generic data serialization component is probably just the ‘REF TO DATA’ which was initialized with a valid reference much earlier.

Deserialization


Deserialization processes almost the same but the other way round of course. First we need to declare and initialize a new data reference to hold the transformed data. We will also need a field symbol again because the transformation yields concrete data and not a reference.
That’s it ! The reference we got from the serialization component must be dereferenced (again) to assign the concrete data to the int but this technique should be clear by now.

Conclusion


In this Weblog I have described a component which can write any kind of data (in form of a ‘REF TO DATA’) to disk and restore it completely. The only thing one has to store is the absolute typename of the data. But this is not a problem since the absolute typename is well defined and can therefore be easily stored in a relational database.

To come back to the entry example again it is now possible to program completely generic function calls with generic parameters.

I understand that the applications for this technique are limited but in every situation where it is not possible to store some kind of data in a relational database this approach can be the solution.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

    1. Patrick Baer Post author
      Thomas,

      thanks for sharing this trick.

      So far I thought this only works for ABAP Objects references ?
      It’s somehow not even intuitive because it assigns a reference to a concrete object whereas for ABAP Objects it only ‘converts’ (casts) one reference into another.

      Don’t get me wrong: I don’t want to criticise you.  It’s a nice shortcut but a little inconcistent in my opinion.

      Best regards,
      Patrick Baer

      (0) 
      1. Thomas Jung
        I thought similar to the way that you did the first time I saw this.  However think about it in a little different way.  If you open your definition of what an ABAP Object is, could not any variable be considered an object?  Their object definition thereby becomes their data type.

        In this example we are casting from any untyped data object to a typed one.  This is a basic concept of OO – the ability to cast from generic to specific. 

        I use this concept all the time in ABAP BSP programming.  You cast from the generic definition of Model and Application classes into your specific inheritence of those same classes.  Why not apply the same concept to simple and complex variables?

        (0) 
        1. Patrick Baer Post author
          Thomas,

          on this level of abstraction you are right.
          Maybe I have seen this too technically.

          [Technically casting one reference to another is still a different thing compared to casting a reference to an instance (of int in this case).
          The latter type of casting involves dereferencing the first one doesn’t.]

          Best regards,
          Patrick Baer

          (0) 
  1. Anjan Chaudhuri
    Great weblog, Patrick! This weblog certainly describes a great way to perform object persistence in ABAP. One could simply expand on this technique to store a memory dump. Lots of possibilities!
    (0) 
  2. Taryck Bensiali

    Sorry, but for me something is missing.

    Serialization do not works on reference.

    If you use table with line like this :

    name char

    type char

    value ref to data

    and serialize using (everything) including CALL TRANFORM ID you won’t get the value that is in the “ref to data”.

    I do not understand : “Second you might ask why we dereference the data into a field symbol if we have just retrieved and stored the reference to the data.”

    Is the ABAP code full ?? :

    DATA the_int TYPE i VALUE 3.

    DATA data_ref TYPE REF TO DATA.

    GET REFERENCE OF the_int INTO data_ref.

    (0) 

Leave a Reply