Question:
Hi all
I have jumbped into some "brand new " mess and need bit of expert advice .
Scenario :
I have a Z-datasource based on an Z R/3 table .
In R/3 , the dataSource in RSO2 has a date field as a
delta specific field , cal day is selected , lower safety level interval is marked 1 , and NEW STATUS for changed records is Checked .
On BW Side , In the transfer Rule ..there are two fields apart from usual datafields - 0RECORDMODE and ZDELETEFLAG.
However , no mapping for these exists at TR level.
In the Comm Str , I can see both field 0RECORDMODE and ZDELETEFLAG .
In the Update Rules between InfoSrc and ODS , ZDELETEFLAG is mapped to ZDELETEFLAG.
0RECORDMODE field is not present in here . I checked the Start routine and there's no custom code .
In the Update Rules between ODS and CUBE , neither the 0RECORDMODE nor ZDELEEFLAG fields exist .no custom code in start routine .
There is one 8**ODSNAME object , which I believe is the datasrc between the ODS & Cube ,
.This is enabled for "Delta update " . In the lower section , I can see the Delete Flag field checked in the "selection" column .Record mode field is also there , but there are no "ticks" in front of it .
********************************************************************************************
********************************************************************************************
Problem :
The DAILY Process Chain is doing a DAILY Full LOAD to the ODS and then a DELTA to the CUBE .
However , the number of RECS TRANSFERRED into the CUBE via the PC is SAME ,and the number of ADDED RECORDS in CUBE is exactly half the no of transferred records .So, I understand that since oDS is being overwritten DAILY , the CUBE also gets ALL the data daily ...
The Problem I am facing is that , for some specific criteria for past months , the data in the R/3 table ,ODS and CUBE reconciles . However , for the CURRENT month although the data in R/3 and ODS reconciles , but the Data in the CUBE and ODS does not reconcile .
I am not able to make out why the data in ODS and CUBE does not reconcile for CURRENT Month .
On checking the CUBE Contents for current month , I found out that for one particular key figure , cube has same number of +ve and -ve entries so the sum of it adds up to ZERO .
The Rest of the key figures are reconciling with R/3 & ODS data.
I cant make much out of the Requests i see in the Cube-REQUESTS TAB , there are two kind of requests here ,one created by the daily PC and other manual DElta Requests .I can also see many many GReen Requests ( both PC and manual ) in the RECONSTRUCTION Tab .
Can anyone of you help me resolve this problem ??
Your help would be greatly appreciated.
PS : I also checked the ODS Contents , and all the data there has a RECORDMODE as ' '(space). i.e As after image .
Thanks
Ooops
*******************************************************************************************
Answer:
Hmm, there are alot of little issues to address in your problem... Let's start with your data source. The fact that you have NEW STATUS for changed records checked means that you will receive only 1 record from your extractor, that is, the current value in the Z-table. This is unlike standard LIS extractors which send a before and after image. Therefore, you can assume a field like 0RECORDMODE is not going to serve much purpose as it is only useful if you have the before image or the delete image being sent as well. Your delete flag I assume means that no records are ever physically deleted from your Z-table? this is good as it means a delta will work (if not, the extractor would never send your deletion and it would be stuck in your ODS unless you did daily deletions before full loads).
At TR level, there is no need to map 0RECORDMODE because it is not going to be useful with this model. ZDELETEFLAG on the other hand would be very useful, so you need to have an infoobject in your ODS and in your cube (and in your comm structure) to which you can map this field. This is not going to be a magic field which will manage deletions in ODS or reversal of key figures in the cube automatically - you have to use it as a filter in your queries or as an indicator in the start routine to reverse key figures yourself!
8**ODSNAME is indeed the data mart data source for your cube. The checks you see are generated by the system and used for the infopackages, but in your case this is not important. It is normal that 0RECORDMODE is not checked - this is not a field we usually manage.
If you have taken the time to create a generic delta extractor, I don't understand why you are then doing a full load to the ODS? Your extractor will give you the delta, so run deltas! Otherwise, no need for the delta mechanism on your extractor. If you are doing deltas to your ODS, then deltas to the cube should be no problem either. If you are doing a full to the ODs and a delta to the cube, are you first deleting the ODS or not? This makes a difference because in the former, you will be sending the active table to the cube and I don't see how your numbers could be off and in the latter you are sending the change log table to the cube. Normally your numbers should be correct in either case. My biggest concern in your model is the fact that you do full loads with a delta extractor and you do not use the ZDELETEFLAG anywhere in the model to prevent deleted records from showing their key figures. Maybe if you can first comment on my comments we'll have a clearer idea of a solution for you!
_________________
Sandy
Answer:
Of what i understand now is that we were earlier doing a DELTA from the R/3 to ODS ,
However , since the some of the users were changing the Z-table R/3 data directly
in the table maintenance in R/3 , no date/time fields were getting changed and so
for one particular month we did not receive correct DELTA ( since users did manual changes
in that month ) .
Currently , We have a DAILY FULL REPAIR REQUEST to the ODS ( all records from R/3 ) ,
and then a DELTA to the CUBE ...however ,i assume sine the ODS is getting Overwritten
DAILY , the Cube also receives a FULL load ( although technically its a Delta from the
ODS to the CUBE ) ..Correct me iif my understanding is wrong .
Btw , Do i need to delete the ODS if we are doing FULL REPAIR REQUEST daily ? I checked
the process chain and the ODS deletion step is not there .
In thh PC , The full load to ODS is followed by an "update from PSA" button ,an AND node
that waits for all ODS data loads to be complete , then the ODS Activation and then a DELTA
load to the CUBE ,which again is followed by an "Update to PSA " button.
The current problem is that for the same selction criteria , 1 of the key figure totals is not matching in the ODS data and CUBE data . the cube seems to have equal number of +ve and -ve entries for this key figure which adds up to zero . A second key figure matches in both ODS and CUBE . The rest of the key fugures are zero and so i cant comment on them .
Plesae help me resolev the issue .
Answer:
Hi Sandy ,
Since I had to correct data in the CUBE , I deleted all Data ( facts & Dimension), and ran a
"Initialise delta " from the ODS to CUBE . The
DATA in ODS and cube is now matching .
However , I have a PC scheduled to run late tonight that will do a FULL to the ODS followed
by a "technical " Delta to the CUBE . Will that
run fine or do i have to make any changes to the
PC so that all Data is fine and it does not fail .
Thanks
Answer:
Just getting back to your original question because it is a good question and it's important to understand... When you have an ODS with inits and deltas and suddenly realize that your data is not correct, so you switch to full load repairs, you are assuming the responsibility of duplicate records. That is, if your update rules on your key figures are 'addition' and not 'overwrite', you will duplicate all your key figures. The full load repair flag is sort of SAP's disclaimer to key figures not working anymore! To be honest, if my delta stopped working, I would have deleted the ODS and started again with normal full loads (preceded by a full delete, IF you are not handling deletions with a flag, but you are, so that's good!).
Your delta to the cube will be based on the change log of your ODS - this is NOT going to be the equivalent to a full load UNLESS you are deleting your ODS each time. The way you had it set up, you would've only been sending new or changed records - careful of the wording -- the record is not CHANGED just because it got overwritten in the ODS. By change, I mean a real change to a key figure or characteristic. A change will create 2 records in your change log table, thus for each change to a record in R/3 you get a reversal and a new image in the change log table.
Ex. Quantity changes from 3 to 4. My change log will look like this :
Load 1 : KF = 3
Load 2 : KF = -3
Load 2 : KF = 4
My cube, if it's delta will look EXACTLY the same. If it were full loads to the cube, the change log will not be used, instead it will be a copy of the active table which would be sent, i.e. the last value : 4, one single record as opposed to 3.
If you compress a cube, any 0 totals can be physicaly removed from the cube so that you will no have a +3 and -3 record, just a +4 record. This As you can see, your delta to the cube will receive two new records. The reversal will cancel out the old value in the cube and the new record will provide the new total.
You should be fine now that you've done a new init to the cube followed by deltas, but you have to be carefull about messing about with full load repairs - like I said, they are a disclaimer, a temporary solution! If you have doubts about your data, do a new full load and continue with normal full loads, but try not to mix init, deltas and full load repairs as a long term solution.
_________________
Sandy