Start of Content Area

Object documentation Write-Optimized DataStore Objects  Locate the document in its SAP Library structure

Definition

A DataStore object that consists of just one table of active data. The data is only added, and not changed (no UPDATE). Values are assigned to the data in the data transfer process.

Use

Data that is loaded into write-optimized DataStore objects is available immediately for further processing.

They can be used in the following scenarios:

      You are using a write-optimized DataStore object as a temporary storage area for large sets of data that you are executing complex transformations on before it is written to the DataStore object. The data can then be updated to further (smaller) InfoProviders. You only have to create the complex transformations once for all data.

      You are using write-optimized DataStore objects as the EDW layer for saving data. Business rules are only applied when the data is updated to additional InfoProviders.

The system does not generate SIDs for write-optimized DataStore objects, and they do not need to be activated. This means that you can save and further process data quickly. Reporting can be carried out based on these DataStore objects. However, we recommend that you use them as a consolidation layer and update the data to additional InfoProviders, standard DataStore objects or InfoCubes.

Structure

Since the write-optimized DataStore object only consists of the table of active data, you do not have to activate the data, as is necessary with the standard DataStore object. This means that you can process data more quickly.

The loaded data is not aggregated, meaning that the data history is kept. If two data records with the same logical key are extracted from the source, both records are saved in the DataStore object. The record mode responsible for aggregation does not change though, meaning that the data can be aggregated later in standard DataStore objects.

Technical Key

The system generates a unique technical key for the write-optimized DataStore object. The standard key fields are not necessary with this type of DataStore object. If there are standard key fields anyway, they are called semantic keys so that they can be distinguished from the technical keys. The technical key consists of the Request GUID field (0REQUEST), the Data Package field (0DATAPAKID) and the Data Record Number field (0RECORD). Only new data records are loaded to this key.

Duplicate Data Records

You can specify that you do not want to run a check to ensure that the data is unique. If you do not check the uniqueness of the data, the DataStore object table may contain several records with the same key. If you do not set this indicator, and you do check the uniqueness of the data, the system generates a unique index in the semantic key of the InfoObject. This index has the technical name "KEY". Since write-optimized DataStore objects do not have a change log, the system does not create a delta (in the sense of a before-image and an after-image). When updating data to the connected InfoProviders, the system only updates requests that have not yet been posted.

Delta Consistency Check

A write-optimized DataStore object is often used like a PSA. Data that is loaded into the DataStore object and then retrieved from the Data Warehouse layer should be deleted after a reasonable period of time.

If you are using the DataStore object as part of the consistency layer though, data that has already been updated cannot be deleted. The delta consistency check in DTP delta management prevents a request that has been retrieved with a delta from being deleted. The Delta Consistency Check indicator in the settings for the write-optimized DataStore object is normally deactivated. If you are using the DataStore object as part of the consistency layer, it is advisable to activate the consistency check. When a request is being deleted, the system checks if the data has already been updated by a delta for this DataStore object. If this is the case, the request cannot be deleted.

Use in BEx Queries

For performance reasons, SID values are not created for the characteristics that are loaded. However, the data is still available for BEx queries. You can expect slightly worse performance than with standard DataStore objects; however, as the SID values have to be created during reporting.

If you want to use write-optimized DataStore objects in BEx queries, we recommend that they have a semantic key and that you run a check to ensure that the data is unique. In this case, the write-optimized DataStore object behaves like a standard DataStore object. If the DataStore object does not have these properties, you may experience unexpected results when the data is aggregated in the query.

DataStore Data and External Applications

The BAPI, BAPI_ODSO_READ_DATA_UC, for reading data, enables you to make DataStore data available to external systems.

 

Caution

In the previous release, BAPI BAPI_ODSO_READ_DATA was used for this. It is now obsolete.

 

End of Content Area