Tip

Repair bad SAP data and subsequent data targets with delta update

Initialization / delta updates are what we do everyday, and the update method for most data targets. The delta mechanism ensures the consistency of transactional data. So if some data is wrong in the early stage of data flow, we have to not only correct the data but also correct the related records in subsequent data targets. Unfortunately such data can't be avoided in daily extraction. In some situations, the data to ODS is correct but reports errors while loading from ODS to Cubes.

Initialization / delta updates are what we do every day, and it is usually the update method of choice for most data targets. The delta mechanism ensures the consistency of transactional data. So if some data is wrong in the early stage of data flow, we have to not only correct the data itself but also the related records in subsequent data targets.

Unfortunately, such data can't be avoided in daily extractions. In some situations, the data to ODS is correct but reports errors while loading from ODS to Cubes.

Here is one example:
Some FI documents transferred in R/3 with LSMW's background mode and one of the line items 'Negative posting signal' was inserted with 'x' while the right one should be 'X'.

This line time stays cool in my ODS Z1CCWO01, but encounters errors while loaded into several Cubes when the process chain's running.

image
Request 25344 is bad

It's easy to modify the data in PSA of ODS and then re-construct it, but please don't do that immediately - if we simply delete the delta requests in Cubes afterwards and then re-load the delta again, it won't reach your expectation -- because the delta is broken!

If we want to fix the data in ODS / Cubes and keep the right delta, just take the following steps:


1. Set the request's QM status in all your data targets (in my case, 4 cubes and 1 ODS) to red and then delete all of them. This will cause a repeat delta load in the following steps.

image



2. Open table RSDMDELTA via SE16. Here is where you will find the successful DataMarted request. Delete the request that contains the bad data (25344 in my case).

image



3. Open table RSBODSLOGSTATE and change fields 'Max. delta slice that was extracted by all receivers' and 'Max. delta slice extracted until now' to the latest right request number. ( 25344 to 24860 in my case)

image



4. Since the Data Mart Status of the bad request has been cleared, we can thus delete the request and modify data in PSA. But be sure to still mark the QM status in 'Requests' tab to red (not in Monitor).


5. Modify data in PSA.

image



6. Re-construct the bad request (25344) in ODS and activate it.

image



7. Load the delta package in Data Mart from ODS to subsequent data targets. A warning of 'repeat delta' will populate and choose 'request again'.


The above steps could ensure the right delta after a PSA change and reconstruction for all data targets in the data flow. It's somewhat complicated, but I didn't find any better solution except to re-do the whole initialization (which may contain several millions of records and affect all the data targets!)


Aaron Wang is a SAP/BI Consultant for IDS Scheer China.



This content is reposted from the SAP Developer Network.
Copyright 2007, SAP Developer Network

SAP Developer Network (SDN) is an active online community where ABAP, Java, .NET, and other cutting-edge technologies converge to form a resource and collaboration channel for SAP developers, consultants, integrators, and business analysts. SDN hosts a technical library, expert blogs, exclusive downloads and code samples, an extensive eLearning catalog, and active, moderated discussion forums. SDN membership is free.

Want to read more from this author? Click here to read Aaron Wang's Weblog. Click here to read more about Business Intelligence (BI) on the SDN.



Dig Deeper on SAP development and programming languages

ERP
SearchOracle
Data Management
SearchAWS
Business Analytics
Content Management
HRSoftware
Close