WRITE OPTIMIZED DSO (WDSO)

• 
  
• 
  

  Write-Optimized DSO

  The concept of Write Optimized DSO was introduced in BI 7.0. Write Optimized DSO unlike Standard DSO has only one relational table, i.e. Active Table and moreover there is no SID generated in Write Optimized DSO, and hence loading the data from Data Source to Write Optimized DSO takes less time and acuires less disk space. Business Case : Require Data storage for storing detailed level of data with immediate reporting or further update facility. No over write functionality required.

  Limitation of Standard DSO

  - A standard DSO allows to store detailed level of information, However, activation process is mandatory. - Reporting or further update is not possible until activation is completed. Write Optimized DSO - Properties

  - Primarily designed for initial staging of source system data - Business rules are only applied when the data is updated to additional Info Providers. - Stored in at most granular form - Can be used for faster upload - Records with the same key are not aggregated ,But inserted as new record, as every record has new technical key - Data is available in active version immediately for further Processing - There is no change log table and activation queue in it. - Data is saved quickly. - Data is stored in it at request level, same as in PSA table. - Every record has a new technical key, only inserts. - It is Partitioned on request ID (automatic). - It allows parallel load, which saves time for data loading. - It can be included in Process chain, and we do not need activation step for it. - It supports archiving.

  Write-Optimized DSO - Semantic Keys

  Semantic Key identifies error in incoming records or Duplicate records . Semantic Keys protects Data Quality such that all subsequent Records with same key are written into error stack along with incorrect Data Records. To Process the error records or duplicate records , Semantic Group is defined in DTP.

  Note : if we are sure there are no incoming duplicate or error records, Semantic Groups need not be defined.

  Write Optimized DSO- Data Flow 1. Construct Data Flow model. 2. Create Data source 3. Create Transformation 4. Create Info Package 5. Create DTP

  Write-Optimized-Settings

  If we do not check the Check Box "Do not Check Uniqueness of Data ", the data coming from source is checked for duplication, i.e, if the same record (semantic keys) already exist in the DSO, then the current load is terminated. If we select the check box , Duplicate records are loaded as a new record. There is no relevance of semantic keys in this case.

  When Write Optimized DSO is Recommended ?

  - For faster data load., DSOs can be configured to be Write optimized - When the access for Source system is for a small duration. - It can be used as a first Staging layer. - In cases where delta in Data Source is not enabled, we first load data into Write Optimized DSO and then delta load can be done to Standard DSO. - When we need to load large volume of data into Info Providers, then WO DSO helps in executing complex transformations. - Write Optimized DSO can be used to fetch history at request level, instead of going to PSA archive.

  Write Optimised DSO - Functionality

  - It contains only one table, i.e. active data table (DSO key: request ID, Packet No, and Record No) - It does not have any change log table and activation queue. - Every record in Wrtite Optimized DSO has a new technical key, and delta in it works record wise. - In Wrtite Optimized DSO data is stored at request level like in PSA table. - In Wrtite Optimized DSO SID is not generated. - In Wrtite Optimized DSO Reporting is possible but it is not a good practice as it will effect the performance of DSO. - In Wrtite Optimized DSO BEx Reporting is switched off. - Wrtite Optimized DSO can be included in Info Set or Multiprovider. - Due to Wrtite Optimized DSO performance is better during data load as there is no Activation step involved. The system generates a unique technical key - The technical key in Wrtite Optimized DSO consists of the Request GUID field (0REQUEST), the Data Package field (0DATAPAKID) and the Data Record Number field (0RECORD).

  Write-Optimized DSO-Points to Remember

  Points to Remember :- - Generally Write Optimized DSO is not prefered for reporting, but If we want to use it for reporting then it is recommended to defina a semantic in order to ensure the uniqueness of the data. - Write-optimized DSOs can force a check of the semantic key for uniqueness when data is stored. - If this option is active and if duplicate records are loaded with regard to semantic key, these are logged in the error stack of the Data Transfer Protocol (DTP) for further evaluation. - If we need to use error stack in our flow then we need to define the semantic key in the DSO level. - Semantic group definition is necessary to do parallel loads.

  Write-Optimized DSO - Reporting

  If we want to use write-optimized DataStore object in BEx queries(not preferred): it is recommended to 1. Have a semantic key and 2. Ensure that the data is unique. Here the Technical key is not visible for reporting, so it looks like any regular DSO

  Write-Optimized DSO-Useful OSS Notes

  - OSS 1077308 : In a write-optimized DSO, 0FISCVARNT is treated as a key, even though it is only a semantic key. - OSS 1007769 : Parallel updating in write-optimized DSO - OSS 966002 : Integration of write-opt DSO in DTP error stack - OSS 1054065 : Archiving supports.