SAP BW Back-End Usage Standards and Guidelines

 

Write ­Optimized DataStore Objects

Consider the following important facts in mind before you choose to use a Write Optimized DataStore Object:

1. The primary unique key to a WODS Object consists of Request ID, Data Packet ID, and Record Number. The system does not use the semantic key as the primary, unique key to the data. This means that each time you load a particular semantic key into a WODS Object, you get a new, unique record.
2. Write ­Optimized DataStore Objects do not aggregate data. If you extract and load two records with the same logical key (or extract and load the same record twice,) both records appear in the WODS Object.
3. No delta detection or extraction function exists for WODS Objects. When forwarding data to subsequent data targets, the system will forward the requests (loads) that have not yet moved to those targets. Note, however, that this can result in duplicate rows going to the subsequent target.

 

Use as the Enterprise Data Warehouse Layer – First Level Data Acquisition DSO:

You can use a WODS Object as the enterprise data warehouse (“EDW”) layer in your application architecture if your application has the following traits:

1. You have true delta extraction from your source system – only new and changed records come in from the source system. AND
2. Either:
   • The changed records delivered by the source system contain deltas in the key figures, rather than new after ­images. For example, if a key figure has changed from 510 to 720 in the source system, the extractor should deliver a value of +210 in the key figure.
   • The extractor delivers changed records, but puts after images (based amounts) in the key figures, and the number of changed rows delivered by the source system represents less than one percent of the total (i.e., ninety ­nine percent of the extracted volume contains new rows.)

 

Data Transformation

1. Do not create new update rules in the BW system, unless you have a 3.x DataSource that you cannot migrate to BW 7.x. Always use transformations between targets within the BW system (DataStore to Cube, for example.)
2. If necessary you can use an InfoSource as the intermediate data structure between two data transformations. Some important and useful features, such as referential integrity and master data attribute lookups, become available only if you use an InfoSource.
3. The recommended design pattern for data transformations appears below
4. If you do not require referential integrity checking or master data lookups, you can place a data transformation directly between a DataSource and a data target (or between two data targets, such as a level 2 DSO and an InfoCube.)

 

DataSource	Data Transformation 1	InfoSource	Data Transformation 2	Data Target
	[straight one-to-­one mapping]	check referential integrity	data mapping, master data attribute lookups, calculations, etc.

 

Data Transfer Process

1. As a guideline, you should set the Data Update Type on the Update tab to No Update without Master Data.
2. Do not build applications that require adhoc execution of Data Transfer Processes via the Execute button on the Execute tab. Production applications should always invoke Data Transfer Processes via a Process Chain.

InfoProvider Remodeling

1. The 2004s release on wards of SAP BW provides a workbench tool for remodeling InfoProviders without the need to unload and reload the data. Currently, this tool does not support transport of its configuration, runs slowly, consumes a lot of resources, and provides no fallback in the event of a failure. For these reasons, recommend not use this tool in your environment.

Courtesy: SAP help and Project Documents