Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

  Standard DataStore Objects vs. Write Optimized DataStore Objects

  • Tables

  • Standard DSOs have three tables;

  • New Data

New Data Table of a DSO contains data which has been loaded to DSO but didn’t activated yet.

Name of a New Data Table of a DSO is being generated from system according to below  rule.


  • For a user defined DSO: “/BIC/A<technical name of DSO>40.

Ex:  Technical name of New Data Table of DSO ZDS_DS01 is “/BIC/AZDS_DS0140”

  • For a standard DSO: “/BI0/A<technical name of  DSO without 0 begging of it>40.

Ex:  Technical name of New Data Table of DSO 0SD_O06 is “/BI0/ASD_O0640”.

You can also display data of New Data Table of a DSO from the “New Data” button on “Contents” tab of “Manage DSO” screen.


You can see from the below screen shot that for Freight Cost DSO there is one request which hasn’t activated yet.


Data belongs to non-activated request can be displated from New Data Table of DSO.


After activating a request, data at New Data Table is being transferred to the Active Data Table by the system.


As you can see from the below screen shot no data exists at New Data Table after activating all requests.




  • Active Data

Active Data Table of a DSO contains active data of DSO. In other words Active Data Table of a DSO contains data which has been loaded to DSO and already activated.


Name of an Activate Data Table of a DSO is being generated from system according to below rule.


  • For a user defined DSO: “/BIC/A<technical name of DSO>00.

Ex:  Technical name of New Data Table of DSO ZDS_DS01 is “/BIC/AZDS_DS0100”.

  • For a standard DSO: “/BI0/A<technical name of  DSO without 0 begging of it>00.

Ex:  Technical name of New Data Table of DSO 0SD_O06 is “/BI0/ASD_O0600”.

You can also display data of Active Data Table of a DSO from the “Active Data” button on “Contents” tab of “Manage DSO” screen.



You can see from the below screen shot that for Freight Cost DSO there is one request which has already activated.


Data belongs to activated request can be displated from Active Data Table of DSO.


After activating a request of DSO, data at New Data Table is being transferred to the Active Data Table by the system.



  • Change Log


Change Log Table of DSO contains the log data of DSO. It contains the log of changed data within each request. One of the key fields of Change Log Table is “Request number for the data transfer field”.


System updates the data at Change Log Table after activation of request.

You can display data of Change Log Table of a DSO from the “Change Log” button on “Contents” tab of “Manage DSO” screen.


You can see the content of a Change Log Table below.


You can find description of RCORDMODE below.


  • Write Optimized DataStore Objects only have one table which is Active Data Table.


  • SID Generation

  • The system generates SIDs for Standard DataStore Objects and you need to activate requests of Standard DSOs.


  • The system does not generate SIDs for write-optimized DataStore objects and you do not need to activate them. This means that data is available in active version immediately, so you can save and further process data quickly.

  • Key Fields

  • In Standard DSOs records with the same key are aggregated according to key fields.

  • In Write Optimized DSOs system generates technical key fields which are Request GUID field (0REQUEST), the Data Package field (0DATAPAKID) and the Data Record Number field (0RECORD). The standard key fields are not necessary with Write Optimized DSOs but, if there are standard key fields anyway, they are called semantic keys so that they can be distinguished from the technical keys. Records with the same key are not aggregated ,but inserted as new record, as every record has new technical key.


  • Bex Queries

  • You can create a Bex Query from a Write Optimized DSO but, because for performance reasons, SID values are not created for the characteristics that are loaded to Write Optimized DSOs, so in comparison to standard DSOs, you can expect slightly worse performance because the SID values have to be created during reporting.


If you want to use Write Optimized DSOs in BEx queries, SAP recommend that DSOs have a semantic key to ensure that the data  is unique. In this case,  the Write Optimized DSO behaves like a standard DataStore object and records with same key are  aggregated according to sematic key fields. If the  DataStore object does not have these properties, you may experience  unexpected results when the data is aggregated in the query.

Conclusion


In conclusion it is appropriate to use Write Optimized DataStore Objects as consolidation layer. Data can be loaded to Write Optimized DSOs from source system and after harmonization of data  it can be loaded to another InfoProvider like Standard DSO and InfoCube. Reporting from a Write Optimized DSO is not efficent because of the risk of indirect data and performance issues.

8 Comments
Labels in this area