Extraction to Database Tables 

Use

You can select a database table as an open hub destination.

Functions

Deleting tables before extraction

With an extraction to a database table, you have the option of getting the history of the data or only storing the new data in the table. Choose Delete Table Before Extraction when defining your destination if you want to overwrite the fields. In this case, the table is completely deleted and regenerated before each extraction takes place. We recommend you use this mode when the table is not to contain a history of the data. If you do not select this option the table is only generated once before the first extraction. We recommend you use this mode when the history of the data is to be retained.

Generation of a database table

The generated database table receives the prefix /BIC/OHxxx (xxx is the technical name of the destination).

Generation of the database table differs according to whether you are using a BAdI for the transformation:

...

       1.      If you do not use a BAdI, the table is created with the field list of the extract structure for the InfoSpoke (prefix /BIC/CY).

       2.      If you do use a BAdI, the table is created with the field list of the target structure for the BAdI. If the field list for your database table differs from the generated extract structure, you should create your own target structure by BAdI and then change the field list using dictionary maintenance.

Key fields from the table

With extractions to a database table, you have to note that the generated DB table can have a maximum of 16 key fields. Therefore, check whether your field list includes more key fields. If this is the case, you can set the Technical Key indicator. A key is then added, consisting of the technical fields OHREQUID (open hub request SID), DATAPAKID (data package ID), and RECORD (running number of a data record to be added to the table within a data package).  These fields then display the individual key fields for the table.

Using a target table with a technical key would be useful in the following instances:

...

       1.      Delta extraction from ODS objects: the data is read in the change log, in which several records with different RECORDMODEs can exist for a specific, semantic key (after/before image). In general, extracting to a table with the semantic key from the ODS object otherwise leads to duplicate records and, ultimately, to a short dump.

       2.      Delta extraction from an InfoCube: first records from the fact table (F table) and then records from the table of compressed InfoCube data (e-table) are read. If there are records for a specific characteristic key in both the F table and the E table, there will be a short dump in the open hub target table when the system attempts to insert the record from the E table. To solve this problem, you can either set the indicator Technical Key or, as an alternative, compress all data found in the InfoCube before extraction.

       3.      Extracting in full mode to a table that does not need to be deleted before the extraction. If, for an extracted record, one already exists with the same key, a short dump occurs due to duplicate records.

       4.      If the source has more than 16 key fields, no DB table can be created with these key fields. In this case, therefore, the table has to include a technical key.