Standart DataStore Objects vs. Write Optimized DataStore Objects
- Tables
- Standart 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 standart 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 standart 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 Standart DataStore Objects and you need to activate requests of Standart 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 Standart 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 Standart DSO and InfoCube. Reporting from a Write Optimized DSO is not efficent because of the risk of indirect data and performance issues.