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.
