Is it not interesting to observe the data source behavior which is having delta capability on how it sends the data to BW?
If you say yes....Here is the blog which has captured the entire movie on how a data source communicates the delta with BW.
What is Delta?
It is a feature of the extractor which refers to the changes(new/modified entries)occured in the sourcesytem.
How to identify?
In ROOSOURCE table, key in the data source name and check the field "DELTA".
If the field is left blank,it implies that the datasource is not delta capable.
The field 0RECORDMODE in BW determines how a record is updated in the delta process.
Now the question is how this delta will be brought to BW?
Using one of the following ways:
ABR: After before and Reverse image
AIE: After image
ADD: Additive image
ABR: After before and Reverse image
Example: Logistics
What is it?
Once a new entry was posted or an exiting posting was changed at R/3 side, an after image shows the status after the change, a before image shows the status before the change with a negative sign and the reverse image also shows the negative sign next to the record while indicating it for deletion. This serializes the delta packets.
What update type ( for key figures) it supports?
- Addition
- Overwrite
Does it support loading to both infocube and ODS (DSO)?
YES
Technical name of the delta process:ABR
Brief overview:
You will find two types of ABR delta processes in RODELTAM table depending on serialization.
- ABR with serialization "2" means serialization is required between requests while sending data but not necessarily at data package level.
- ABR1 with serialization "1" means no serialization.
Since it can be used for both infocube and ODS, let's consider a scenario where in the loading happens directly to ODS (Advantage: we can track the record changes in change log table)
For ODS/DSO, the field ROCANCEL which is part of the data source holds the changes from R/3 side. ROCANCEL serves the same purpose at R/3 side which its counterpart 0RECORDMODE does at BW side. This field for the Data Source is assigned to the Info Object 0RECORDMODE in the BW system.
Check the mapping in Transfer rules(applicable to BW 3.5):
Note:0STORNO AND 0ROCANCEL both are one and same.
In our case, ODS is set to additive mode so that the data source sends both before and after image
Incase if it is set to overwrite, it sends only after image
How it works?
Let's check the new entry in ODS.
Note:I have taken an example of ODS which contains CRM data.
Now in the source sytem, the value of CRM gross weight (CRM_GWEIGH) has been changed to 5360
In order to reflect this change, data source will send two entries to BW:
One is before image with negative sign to nullify the initial value
And the other one is after image entry (modified value)
Upon activation , the after image goes to active table.
After image delta process:
Example: FI-AP/AR
What update type (for key figures) it supports?
Overwrite Only
Does it support loading to both infocube and ODS (DSO)?
No, only ODS/DSO
Technical name of the delta process: AIE
Brief overview:
We have after images with (AIM/AIMD) or without delta queue (AIE/AIED) .
Here, serialization is required between requests, because the same key can be transferred a number of times within a request.
How it works?
Initially the target (ODS) was loaded as shown:
The value of CRM gross weight (CRM_GWEIGH) has been changed to 5360 in the source sytem.
This time,data source sends only one entry i.e. after image which will hold the change.
The final entry after activation in the active table:
Additive delta process:
Example: LIS datasources
What update type( for key figures) it supports?
Addition Only
Does it support loading to both infocube and ODS (DSO)?
YES
Technical name of the delta process: ADD
Brief overview:
In RODELTAM table,we have two types of additive delta processes:
- ADD without delta queue and
- ADDD with delta queue
The extractor provides additive deltas that are serialized on a request basis.
This serialization is necessary since the extractor provides each key once in a request, and changes to the non-key fields would otherwise not be transferred correctly.
How it works?
Check the initial entry in ODS.
The value of CRM gross weight (CRM_GWEIGH) has changed to 5360
Here, the data source sends an entry with value 1,267 with + sign.
Upon activation, check the final entry in active table which is the result of (4093+1267=5360) KG
37 Comments
