SAP BW - DataStore Objects & Types
In this chapter, we will discuss the various DataStore Objects and it sub-modules.
What is a DataStore Object?
A DSO (DataStore Object) is known as the storage place to keep cleansed and consolidated transaction or master data at the lowest granularity level and this data can be analyzed using the BEx query.
A DataStore Object contains key figures and the characteristic fields and data from a DSO can be updated using Delta update or other DataStore objects or even from the master data. These DataStore Objects are commonly stored in two dimensional transparent database tables.
DSO Architecture
The DSO component consists of the following three tables −
Activation Queue − This is used to store the data before it is activated. The key contains request id, package id and record number. Once the activation is done, the request is deleted from the activation queue.
Active Data Table − This table is used to store the current active data and this table contains the semantic key defined for data modeling.
Change Log − When you activate the object, changes done to the active data are re-stored in this change log. A change log is a PSA table and is maintained in Administration Workbench under the PSA tree.
When you load the new data in to a DSO and the technical key is added to records. A request is then added to the Activation queue. It can be triggered manually or automatically.
Types of DataStore Objects
You can define the DataStore Objects into the following types −
- Standard DSO
- Direct Update DSO
- Write-Optimized DSO
| Type |
Structure |
Data Supply |
SID Generation |
| Standard DataStore Object |
Consists of three tables: activation queue, table of active data, change log |
From data transfer process |
Yes |
| Write-Optimized Data Store Objects |
Consists of the table of Active data only |
From data transfer process |
No |
| DataStore Objects for Direct Update |
Consists of the table of Active data only |
From APIs |
No |
Standard DataStore Objects
To create a standard DSO, go to the RSA Workbench.
Use T-Code: RSA1
Go to Modeling tab → InfoProvider → Select InfoArea → Right click and click on create DataStore Object.
Enter the technical name and description of the DataStore object.
Type of DataStore Object → This is used to select the DSO type. It takes a standard DSO by default.
Click the Create (F5) button.
To change the DSO type, go to the settings tab as shown in the following screenshot. Click on the Edit icon and in a new window which opens, you can change the DataStore Object and also Select the Type.
SID Generation
SID is generated for each master data value. Click on Edit to change the settings for SID generation.
Create a SID
You can select from the following options −
- During Reporting
- During Activation or
- Never Create SIDs
Unique Data Records − This option is used to ensure the DSO holds unique values.
Set Quality Status to OK − This allows you to set the quality status after the data loading has been completed.
Key Fields and Data Fields − Key fields are used to add unique records. To add key filed, right click on Key fields and select InfoObject Direct Input.
In a new window, enter the technical names on the InfoObjects and click Continue. You can see that the InfoObject is added under the key fields section.
Following is the key filed InfoObject in the DSO. Once this DSO structure is complete, you can activate that DSO.
Direct Update DataStore Objects
DataStore Object for direct update allows you to access data for reporting and analysis immediately after it is loaded. It is different from standard DSOs owing to the way how it processes the data. This data is stored in the same format in which it was loaded in to the DataStore Object for any direct update by the application.
The Structure of Direct Update DSOs
These datastores contain one table for active data and no change log area exists. The data is retrieved from external systems using APIs.
The following API’s exist −
RSDRI_ODSO_INSERT − These are used to insert new data.
RSDRI_ODSO_INSERT_RFC − It is similar to RSDRI_ODSO_INSERT and can be called up remotely.
RSDRI_ODSO_MODIFY − This is used to insert data having new keys. For data with keys already in the system, the data is changed.
RSDRI_ODSO_MODIFY_RFC − This is similar to RSDRI_ODSO_MODIFY and can be called up remotely.
RSDRI_ODSO_UPDATE − This API is used to update the existing data.
RSDRI_ODSO_UPDATE_RFC − This is similar to RSDRI_ODSO_UPDATE and can be called up remotely.
RSDRI_ODSO_DELETE_RFC − This API is used to delete the data.
Benefits
In direct update DSO’s, the data is easily accessible. You can access data for reporting and analysis immediately after it is loaded.
Drawbacks
As the structure of this DSO contains one table for active data and no change log, so this doesn’t allow delta update to InfoProviders.
As the data loading process is not supported by BI system, so DSOs are not displayed in the administration section or in the monitor.
To create a direct update DataStore, go to administration workbench. Use T-Code: RSA1
Go to Modeling tab → InfoProvider → Select InfoArea → Right click and click on create DataStore Object.
Enter the technical name and description of the DataStore object.
Type of DataStore Object − This is used to select the DSO type. It takes a standard DSO by default.
Click on the Create (F5) button.
To change the DSO type, go to the settings tab as shown in the following screenshot. Click on the Edit icon and in a new window which opens, you can change the DataStore Object and also select its Type. Select the Direct Update DataStore and then click Continue.
Once the DataStore is defined, click on Activate button to activate DSO.
