STANDARD DATASTORE OBJECT

See more in our hbites Advanced DSO

A Standard DataStore Object is used to store consolidated and cleansed data on a document level (highest granularity).

They can be used to support reporting with more granularity, or can be part of the warehouse, where they can be used to hold historical data.

A Standard DataStore Object is designed in the same way as a table, it contains key fields (for example, sales order number and item number) and data fields. Data fields for example, order status, customer, quantity, or time.

Overwrite functionality: – Characteristics that are not part of the record identifier (Key) always overwrite (for example, Order Status). – Key Figures (for example, amount) can be set to overwrite, add, or no update.

Standard DataStore Objects consist of the following 3 tables:

● Active Data table

In this table, the current status of the data is stored. The modeler must define the key correctly because data gets aggregated based on keys. Activation process also depends on keys defined. This table is used for reporting.

● Change Log table

changes to data are stored in the change log during activation. The change log has a technical key consisting of a request, data package, and data record number. It can be used to load data to connected targets using delta method.

● Inbound table

During DTP execution, records are written first to this table. During the activation process, the data records are then written to the Active Data table and the Change Log table.

Data is first sorted according to the keys defined in ADSO by the modeler (semantic). Next, the data is sorted according to the technical key of the activation queue.

The sort sequence guarantees that activation can run in parallel.

The number of data records to be activated determines how many activation processes are started. You can set whether the processes are to run in parallel or in series.

A change log request identifies when the records were activated and moved into the change log from the activation queue.

You can activate request by request or activate many requests together.
After activation the request is deleted in the inbound table.

SAP BW/4HANA distinguishes between three DataStore Object types:

Standard, Staging, and Direct Update.

Write Change Log: If you choose this option, the delta (new, deleted, and changed records) is saved in the change log. The change log is used to extract the delta.

Only if the DataStore object has a change log can requests be rolled back from the DataStore object, that is, the status before the activation of the request can be restored.

Snapshot Support: If your DataSource only delivers the current dataset as a FULL, by setting this indicator, deleted data records can be identified and updated. Upon activation, the system recognizes records that are in the table of active data but not in the load request. These are written to the change log as reverse images.

Unique Data Records: If you only load unique data records (data records with different key combinations) into the DataStore object, you can select this property. If the indicator is selected, during activation the system checks whether unique records exist. If a record already exists, the activation fails.

The Standard DataStore Object is completely integrated in the staging process. This situation means that data can be loaded into and out of the DataStore Objects during the staging process. Using a change log means that all changes are also written and are available as delta uploads for connected data targets.

The Staging DataStore Object can be used for Corporate Memory in different ways by selecting its properties:

Inbound Queue: No data is saved in the change log. The extraction process always reads the data in the inbound table again – for delta extraction or full extraction. This object is not suitable for reporting and analysis.

Compress data: In general, the data is always written to the inbound table. If you choose Compress Data, the data is written to the table for active data (during the compression process) once it arrives in the inbound table. During activation, the data is aggregated in accordance with the semantic key and is written to the active data table.

In the query, you will then only see the data that has been activated.

To save memory space, the change log is not filled. Therefore, you cannot perform request-based deletion of data from the DataStore object. You can only delete data selectively.

Reporting-Enabled: Data is written to the active data table but is also kept in the inbound table.

Since the data is stored redundantly in the inbound table, the data can be deleted from the active table and rebuilt from the inbound table. The data is only extracted from the inbound table. When a query is executed, the active table is accessed.

DataStore Object for direct update: In a DataStore object for direct update, you can load the data directly into the table for active data. With this DataStore object type, the data is directly written to the table of active data.

The data is written either using a DTP or an API. Activation is not possible with this type. Only full extraction is possible. The data is read from the table of active data. All data of the active data table is visible in reporting immediately after the data is loaded for direct update dso.

Summary of Key Feature of Standard DataStore Objects

✓ Standard DataStore Objects serve as the central persistence model for transactional data in your EDW based on BW/4HANA.

✓ They support field-based modeling and InfoObject-based modeling.

✓ They support high-frequency data loads.

✓ They can contain up to 120 key fields (InfoObjects as well as fields).

✓ They are modeled in the Eclipse-based SAP BW Modeling Tools.

✓ Standard DataStore Objects serve as persistence for Open ODS Views.

✓ Standard DataStore Objects offer custom partitions and indexes for performance-critical access.

The activation run is usually triggered by a process chain or can be started manually in some test cases.

See more in our hbites Advanced DSO