Initialization / Delta update is what we do everyday and the update method for most data targets.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 itself but also correct the related records in subsequent data targets. Unfortunately such kind of data can't be avoided in daily extraction. In some situations the data to ODS is correct but reports error 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 inputted with 'x' while the right one should be 'X'. This line time stays cool in my ODS Z1CCWO01 but encounters error while loaded into several Cubes during process chain's running. 
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 delta again, it won't reach your expectation because the delta is broken! If we want to fix both 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.
2, Open table RSDMDELTA via SE16.Here stores the successful DataMarted request. Delete the request contains the bad data (25344 in my case)
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)
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 still mark the QM status in 'Requests' tab to red (not in Monitor). 5, Modify data in PSA.
6, Re-construct bad request (25344) in ODS and activate it.
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 right delta after PSA change and reconstruction for all data targets in the data flow. It's somewhat complicated but I still didn't find any better solution instead of redo the whole initialization (which may contain several millions of records and affect all the data targets!) Regards, Aaron Wang
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 delta again, it won't reach your expectation because the delta is broken! If we want to fix both 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. 2, Open table RSDMDELTA via SE16.Here stores the successful DataMarted request. Delete the request contains the bad data (25344 in my case) 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) 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 still mark the QM status in 'Requests' tab to red (not in Monitor). 5, Modify data in PSA. 6, Re-construct bad request (25344) in ODS and activate it. 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 right delta after PSA change and reconstruction for all data targets in the data flow. It's somewhat complicated but I still didn't find any better solution instead of redo the whole initialization (which may contain several millions of records and affect all the data targets!) Regards, Aaron Wang
8 Comments
