0RECORDMODE & Delta Type Concepts:
What is Delta Management?
It implies the ability to extract only new or changed data records to the BI system in a separate data request. Whenever we activate the Data source which can serve Delta Records in R/3 system, the system
Automatically generates the extraction structure for Data source. This extraction structure sends the delta records to BI based on the Update mode we mention in LBWE.
Let’s take an example that we have chosen update mode as “Queued delta”. So first delta record will be
Collected into delta queue (RSA7) before it posted to BI.
The delta queue is an S-API (Service API) function. This is the central interface technology used to extract data from SAP source systems to a BI system. Consequently, the delta queue is only used in SAP or BI source systems.
The delta queue is a data store for new or changed data records for a Data Source (that has occurred since the last data request). The new or changed data records are either written to the delta queue automatically using an update process in the source system, or by means of the Data Source extractor when a data
Request is received from the BI system. You can check this in below screen
Go to RSA7 either in R/3 or BI you will find the below screen
How to Identify Delta capable Data Source?
You can check whether Data source can provide delta or not by going through SBIW or RSA6
Go to RSA6, then locate your data source by drill down the SAP R/3 data source folder and then double click on the data source. You will get the below screen
Properties of the delta process are determined in the table RODELTAM (in BI or in the source system)
Delta Types:
It describes how the new and changed records enter the delta queue. The delta type is Property of Delta process, it defers from one delta process to other.
To check the delta type of a particular delta process, go to SE16 and give table RODELTAM execute you will get the below screen.
'D': The SAP application writes delta data records directly to the delta queue(.PUSH.) for the DataSource. Each data record is either a) stored in the delta queue individually on saving / updating the corresponding transactions in the application (for example, FI-AR/AP or direct delta in the LO Cockpit),or b) written in groups of delta data records (after updating the transaction) to the delta queue by means of application-specific jobs.
'E': The DataSource determines the delta through the extractor on request. This means that the extractor must be capable of providing the delta records for the DataSource on request (.PULL.).
'F': The delta data records are loaded by flat file. This delta type is only used for DataSources for flat file source systems
ROCANCEL and 0RECORDMODE:
ROCANCEL which is automatically part of DataSource saves the record mode in R/3 side based on the type of delta process of DataSource.
This field for the DataSource is assigned to Info object 0RECORDMODE in BI system.
Mapping between Delta indicators:
To check how this fields are mapped just double click on transfer structure of Data Source to get the below screen.
In BI you can use 0RECORDMODE or 0STORNO to map the ROCANCEL field.
From the above screen we can easily say it is direct mapping.
ROCANCEL Values:
We can analyze what are all the values by going through the data in delta queue.
Goto RSA7 Select any Delta queue then click on Display data records button. Then you will get the below screen
„X‟ Before Image(This is missed in screen shot)
„R‟ Reverse Image(after image with reversed signs)
Apart from the above three you can find some more values for ROCANCEL field in some specific situation
If it is SD transaction data then you will find the below values in ROCANCEL field.
'U' becomes an after image with a minus key figure in BI.
'V' becomes a remove (deletion record) with a plus key figures in BI.
'W' becomes a before image with a plus key figures in BI.
These three values are only required for the internal conversion of keyfigures.This conversion occurs during
extraction to BI, so you won’t find this values in BI. This will be available only in RSA7 at R/3 system.
0RECORDMODE Values:
Go to change log table of DSO, in content screen press F4 on the selections provided for reocordmode field, you will get the below list.
' ': The record provides an after image. The status of the record is transferred after it has been changed, or after data has been added.
'X': The record provides a before image. The status of the record is transferred before it has been changed or deleted. All attributes for the record that can be aggregated (key figures) must be transferred with a reversed plus/minus sign. These records are ignored in a non-additive (overwriting) update of a DataStore object. The before image complements the after image.
'A': The record provides an additive image. This provides the record with differences for all the numeric values are available. The record can be updated to an InfoCube without restrictions, but requires an additive update to be made to a DataStore object.
'D': The record must be deleted. Only the key is transferred. This record (and therefore the DataSource too)
Can only be updated to a DataStore object.
'R': The record provides a reverse image. The content of this record is equivalent to a before image. The only difference occurs when updating a DataStore object: An existing record with the same key is deleted.
'N': The record provides a new image. The content of this record is equivalent to an after image without a before image. A new image should be transferred instead of an after image when a record is created. The new image complements the reverse image.
Possible Scenarios to update Delta Records into Data Targets
Here we will have a look at the most used delta process types and how a particular record looks
The following are the most used delta process types
ABR Which Provides After Before and Reverse Images
AIE/AIM Which Provides After Image
ADD which provides additive Image
Now let’s take an example of simple sales order as below
Case2: If the data that fills the BI system is an additive image, the data can be written to an InfoCube or a DataStore object. With a DataStore object, the update type for key figures must be set to add and not overwrite, however.
Case3: If the DataSource only sends the after image, this must first be updated to a DataStore object that is in overwrite mode
Case4: Reverse images can be processed by all targets.
Case5: Delete images can only be processed by a DataStore object. InfoCubes cannot process deletions.
What is Delta Management?
It implies the ability to extract only new or changed data records to the BI system in a separate data request. Whenever we activate the Data source which can serve Delta Records in R/3 system, the system
Automatically generates the extraction structure for Data source. This extraction structure sends the delta records to BI based on the Update mode we mention in LBWE.
Let’s take an example that we have chosen update mode as “Queued delta”. So first delta record will be
Collected into delta queue (RSA7) before it posted to BI.
The delta queue is an S-API (Service API) function. This is the central interface technology used to extract data from SAP source systems to a BI system. Consequently, the delta queue is only used in SAP or BI source systems.
The delta queue is a data store for new or changed data records for a Data Source (that has occurred since the last data request). The new or changed data records are either written to the delta queue automatically using an update process in the source system, or by means of the Data Source extractor when a data
Request is received from the BI system. You can check this in below screen
Go to RSA7 either in R/3 or BI you will find the below screen
How to Identify Delta capable Data Source?
You can check whether Data source can provide delta or not by going through SBIW or RSA6
Go to RSA6, then locate your data source by drill down the SAP R/3 data source folder and then double click on the data source. You will get the below screen
If Delta Update is checked then this Data Source is delta capable.
Now once the data source is delta capable we have to check the type of delta process. We can find this in table the table ROOSOURCE (in the source system) or in the table RSOLTPSOURCE (in BI for DataSources 3.x) or in the table RSDS (in BI for DataSources) respectively
Properties of the delta process are determined in the table RODELTAM (in BI or in the source system)
Delta Types:
It describes how the new and changed records enter the delta queue. The delta type is Property of Delta process, it defers from one delta process to other.
To check the delta type of a particular delta process, go to SE16 and give table RODELTAM execute you will get the below screen.
Form the above screen the different delta types are as follows
„ „ : The delta type is not defined
'A': The DataSource determines the delta with ALE update pointers. This method is used in the main in connection with DataSources for attributes and texts from SAP source systems.'D': The SAP application writes delta data records directly to the delta queue(.PUSH.) for the DataSource. Each data record is either a) stored in the delta queue individually on saving / updating the corresponding transactions in the application (for example, FI-AR/AP or direct delta in the LO Cockpit),or b) written in groups of delta data records (after updating the transaction) to the delta queue by means of application-specific jobs.
'E': The DataSource determines the delta through the extractor on request. This means that the extractor must be capable of providing the delta records for the DataSource on request (.PULL.).
'F': The delta data records are loaded by flat file. This delta type is only used for DataSources for flat file source systems
ROCANCEL and 0RECORDMODE:
ROCANCEL which is automatically part of DataSource saves the record mode in R/3 side based on the type of delta process of DataSource.
This field for the DataSource is assigned to Info object 0RECORDMODE in BI system.
Mapping between Delta indicators:
To check how this fields are mapped just double click on transfer structure of Data Source to get the below screen.
In BI you can use 0RECORDMODE or 0STORNO to map the ROCANCEL field.
From the above screen we can easily say it is direct mapping.
ROCANCEL Values:
We can analyze what are all the values by going through the data in delta queue.
Goto RSA7 Select any Delta queue then click on Display data records button. Then you will get the below screen
If you want more records to display then change 1000 to 99999 then click on execute. You will get data as mentioned in below screen.
In the above screen first field indicates the ROCANCEL, from this screen we can see the different values are
„ „ after Image„X‟ Before Image(This is missed in screen shot)
„R‟ Reverse Image(after image with reversed signs)
Apart from the above three you can find some more values for ROCANCEL field in some specific situation
If it is SD transaction data then you will find the below values in ROCANCEL field.
'U' becomes an after image with a minus key figure in BI.
'V' becomes a remove (deletion record) with a plus key figures in BI.
'W' becomes a before image with a plus key figures in BI.
These three values are only required for the internal conversion of keyfigures.This conversion occurs during
extraction to BI, so you won’t find this values in BI. This will be available only in RSA7 at R/3 system.
0RECORDMODE Values:
Go to change log table of DSO, in content screen press F4 on the selections provided for reocordmode field, you will get the below list.
' ': The record provides an after image. The status of the record is transferred after it has been changed, or after data has been added.
'X': The record provides a before image. The status of the record is transferred before it has been changed or deleted. All attributes for the record that can be aggregated (key figures) must be transferred with a reversed plus/minus sign. These records are ignored in a non-additive (overwriting) update of a DataStore object. The before image complements the after image.
'A': The record provides an additive image. This provides the record with differences for all the numeric values are available. The record can be updated to an InfoCube without restrictions, but requires an additive update to be made to a DataStore object.
'D': The record must be deleted. Only the key is transferred. This record (and therefore the DataSource too)
Can only be updated to a DataStore object.
'R': The record provides a reverse image. The content of this record is equivalent to a before image. The only difference occurs when updating a DataStore object: An existing record with the same key is deleted.
'N': The record provides a new image. The content of this record is equivalent to an after image without a before image. A new image should be transferred instead of an after image when a record is created. The new image complements the reverse image.
Possible Scenarios to update Delta Records into Data Targets
Here we will have a look at the most used delta process types and how a particular record looks
The following are the most used delta process types
ABR Which Provides After Before and Reverse Images
AIE/AIM Which Provides After Image
ADD which provides additive Image
Now let’s take an example of simple sales order as below
Based on the properties of Data source we have to design our data flow in our System. The below table illustrates How to use data targets based on Data source delta process
Case1: If the DataSource sends both the before image and the after image, this combination can be loaded to any InfoCube or DataStore object. If the overwrite data setting was made for DataStore objects, only the after image (the last image) arrives in the activation queue table of the DataStore object. If settings are made in the DataStore object so that data is added, both the before and the after image are necessary to load the data correctly to the target.
Case2: If the data that fills the BI system is an additive image, the data can be written to an InfoCube or a DataStore object. With a DataStore object, the update type for key figures must be set to add and not overwrite, however.
Case3: If the DataSource only sends the after image, this must first be updated to a DataStore object that is in overwrite mode
Case4: Reverse images can be processed by all targets.
Case5: Delete images can only be processed by a DataStore object. InfoCubes cannot process deletions.
very nice document...thnx a lot....!
ReplyDelete