Loading Transactional Data

Suppose a Data Mart DataStore Object has been defined to store order postings. Corresponding data from the sources should not be inconsistent. Therefore, as a next step, you load transactional data to SAP BW bridge with consistency checks.

After you have loaded master data, you will load transactional data in a similar way. Like for master data, you need a data transfer process (DTP). There are two differences in comparison with the master data scenario.

• The target object is a DataStore object (advanced) also known as ADSO.
• The data is loaded to an inbound table first and therefore, there is a quality assignment step.

Launch a video to see how loaded data is activated in the management of a DataStore object (advanced).

During the upload of data, a request is always inserted into the inbound table (new data). Each request gets its own request ID (time stamp). This feature enables you, for example, to delete a request from the inbound table after the upload.

Suppose you have frequently loaded transactional data to the ADSO inbound table. As an example, suppose you have created a DataStore object (advanced) with semantic key field document number. Then, you first load value 10 for document number 4711, and finally you load value 20 for the same document number.

This typically leads to different entries in the inbound table with the same semantic key. However, they are kept separately because the load request ID (called request transaction sequence number, in short REQTSN) is a different timestamp for each load request. Different records in the same load request have different values for package id (DATAPAKID) or record id (RECORD). The three fields REQTSN, DATAPAKID, and RECORD combined form a technical key in the inbound table. This technical key is used to distinguish and sort the different records.

This distinction results in a larger inbound table and slightly suboptimal data access performance. If you use a DataStore object (advanced) of type Data Mart, data could already be used in this situation. But if you use a different type of DataStore object (advanced) called Standard ADSO, an additional step is required to make the data available for the consumption in SAP Datasphere. This step is called data activation. During data activation, request ID (REQTSN), package id (DATAPAKID) and record numbers (RECORD) are removed, and data is aggregated using the semantic key of the ADSO and the specific aggregation method for each key figure. For example, if aggregation method SUM is applied, the values 10 and 20 add up to 30. If the semantic key is new, the new value is written to the active data table and to the Change Log table with RECORDMODE 'N' and the corresponding data records are deleted from the inbound table.

The aggregation method depends on the settings in the transformation and key figure definition. In this example, if the key figure aggregates as MIN, the value 10 is stored (in the active data table and in the Change Log). With the aggregation method MOVE in the transformation, the value of the most recent record is used (for example, 20).

Suppose you have set the aggregation method for Value to MOVE (overwrite) and load a correction for the existing semantic key with a value of 10 instead of 30.

Then, after activating the new request, the value in the active data table will be updated. The following changes are added to the Change Log.

1. A storno record for the original value is generated with RECORDMODE 'X' and a reversed +/- sign.
2. The value after the change is added with RECORDMODE ' '. This is called the "after image" record.

Storing the two changes separately has the following advantages:

• You can update values to another target in delta mode if the aggregation method is SUM in the target. Note that adding up the records for a change request yields the total value change.
• But, you can also update values to another target in delta mode if the aggregation method is MOVE in the target. Note that the most recent entry is the finally valid value.
• In the ADSO type Standard with changelog, you can reverse the activation process as long as the Change Log table is filled because it contains all changes. The restoration of the situation before the data activation is called rollback. Rollback is triggered if you delete operation for the latest request or requests.

Launch a video to see how loaded data is activated in the management of a DataStore object (advanced).