Show TOC

Write-Optimized DataStore ObjectLocate this document in the navigation structure

Definition

DataStore object that only consists of one table of active data. Data is loaded using the data transfer process.

Use

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

You use write-optimized DataStore objects in the following scenarios:

  • You use a write-optimized DataStore object as a temporary storage area for large sets of data if you are executing complex transformations for this data before it is written to the DataStore object. T the data can then be posted to further (smaller) InfoProviders. You only have to create the complex transformations once for all data.

  • You use write-optimized DataStore objects as the EDW layer for saving data. Business rules are only applied when the data is posted to other InfoProviders.

The system does not generate SIDs for write-optimized DataStore objects, and you do not need to activate them. This means that you can save and further process data quickly. Reporting is possible on the basis of these DataStore objects. We recommend using them as a consolidation layer however, and updating 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; thus retaining the history of the data. 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 remains however, so that the aggregation of data can take place 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 standard key fields exist 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 duplicate data records should be allowed. In this case there is no check whether the data is unique. If you allow duplicate data records, the active table of the DataStore object may contain several records with the same key. If you do not set this flag, but 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 generate deltas in the sense of before image and after images. When you update data into the connected InfoProviders, the system only updates the 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.

Asynchronous Deletion

You delete records from a write-optimized DataStore object asynchronously. When the DataStore object is used in a transformation rule for reading however, note that the deletions are ignored if the records have not been reorganized.

Usage in BEx Queries

For performance reasons, SID values are not created for the characteristics that are loaded. The data is still available for BEx queries. In comparison with standard DataStore objects however, you can expect slightly worse performance because 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, unexpected results might ensue when the data is aggregated in the query.

DataStore Data and External Applications

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

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