Exporting data clusters with type version

Question

Hi all,
let's assume we are saving some ABAP data as a cluster to database using the IMPORT TO ... functionality, e.g.
EXPORT VBAK FROM LS_VBAK VBAP FROM LT_VBAP  TO DATABASE INDX(QT) ID 'TEST'
Some days later, the data can be imported
IMPORT VBAK TO LS_VBAK VBAP TO LT_VBAP FROM DATABASE INDX(QT) ID 'TEST'.
Some months or years later, however, the IMPORT may crash: Since it is the most normal thing in the world that ABAP types are extended, some new fields may have been added to the structures VBAP or VBAK in the meantime.
The data are not lost, however: Using method CL_ABAP_EXPIMP_UTILITIES=>DBUF_IMPORT_CREATE_DATA, they can be recovered from an XSTRING. This will create data objects apt to the content of the buffer. But the component names are lost - they get auto-generated names like COMP00001, COMP00002 etc., replacing the original names MANDT, VBELN, etc.
So a natural question is how to save the type info ( = metadata) for the extracted data together with the data themselves:
EXPORT TYPES FROM LT_TYPES VBAK FROM LS_VBAK VBAP FROM LT_VBAP TO DATABASE INDX(QT) ID 'TEST'.
The table LT_TYPES should contain the meta type info for all exported data. For structures, this could be a DDFIELDS-like table containing the component information. For tables, additionally the table kind, key uniqueness and key components should be saved.
Actually, LT_TYPES should contain persistent versions of CL_ABAP_STRUCTDESCR, CL_ABAP_TABLEDESCR, etc. But it seems there is no serialization provided for the RTTI type info classes.
(In an optimized version, the type info could be stored in a separate cluster, and being referenced by a version number only in the data cluster, for efficiency).
In the import step, the LT_TYPES could be imported first, and then instances for these historical data types could be created as containers for the real data import (here, I am inventing a class zcl_abap_expimp_utilities):
IMPORT TYPES TO LT_TYPES FROM DATABASE INDX(QT) ID 'TEST'.
DATA(LO_TYPES) = ZCL_ABAP_EXPIMP_UITLITIES=>CREATE_TYPE_INFOS ( LT_TYPES ).
assign lo_types->data_object('VBAK')->* to <LS_VBAK>.
assign lo_types->data_object('VBAP')->* to <LT_VBAP>.
IMPORT VBAK TO <LS_VBAK> VBAP TO <LT_VBAP> FROM DATABASE INDX(QT) ID 'TEST'.
Now the data can be recovered with their historical types (i.e. the types they had when the export statement was performed) and processed further.
For example, structures and table-lines could be mixed into the current versions using MOVE-CORRESPONDING, and so on.
My question: Is there any support from the standard for this functionality: Exporting data clusters with type version?
Regards,
Rüdiger

Answer 1

The IMPORT statement works fine if target internal table has all fields of source internal table, plus some additional fields at the end, something like append structure of vbak.
Here is the snippet used.
TYPES:
BEGIN OF ty,
  a TYPE i,
END OF ty,
BEGIN OF ty2.
        INCLUDE TYPE ty.
TYPES:
  b TYPE i,
END OF ty2.
DATA: lt1 TYPE TABLE OF ty,
      ls TYPE ty,
      lt2 TYPE TABLE OF ty2.
ls-a = 2. APPEND ls TO lt1.
ls-a = 4. APPEND ls TO lt1.
EXPORT table = lt1 TO MEMORY ID 'ZTEST'.
IMPORT table = lt2 FROM MEMORY ID 'ZTEST'.
I guess IMPORT statement would behave fine if current VBAK has more fields than older VBAK.