GENERIC EXTRACTION
Generic R/3 data extraction allows us to extract from any R/3 source system. Generic data extraction is a function in Business Content that supports the creation of
Datasources based on database views or InfoSet queries. InfoSet is similar to a view but allows outer joins between tables. The new generic delta service supports delta extractors on monotonic ‘delta attributes’ like Timestamp, Calendar day, Numeric pointer (e.g. document number, counter) – must be strictly monotonic increasing with time. Only one attribute can be defined as the delta attribute
→ Reason for Generic Extraction approach: -
1. The approach of generic extraction is followed when the required data source is not available in the Business content. (Or)
2. If the Business content data source is already used and again when we want to simulate the same kind of extractor, we can go for generic extraction.
In the case of business content datasource the datasource is already available in delivered version. In order to use it, we have to install that particular datasource to create a copy of the datasource in active version by using RSA5 t-code.
In case of generic datasource we are creating our own datasources as per the requirement. We prefer business content data sources with specific to performance.
What is a Data Source?
Data Source: Data source can be defined as the combination of extract structure and transfer structure in the source system (like SAP R/3) and transfer structure from BW side.
ES -> It defines the data to be extracted from source system
TS -> It defines the data to be extracted from source system to BW.
→ We can generate generic data source using the following
- Table
- View
- Function module
- Infoset Query
- Domain (for text)
→ TYPES:
We can create 3 types of data sources using generic extraction
- Transaction data
- Master data attribute
- Text
STEPS TO CREATE GENERIC EXTRATION FOR TRANSATION DATA:
- Go to T-Code RSO2.
- Select the radio button TRANSACTION DATA and give the some technical name and click on create button.
- Give APLICATION COMPONENT, TABLE NAME and give Descriptions. Then click on SAVE button.
- Select the fields otherwise click on hide. For transaction data KEY FIGURES and REFERENCE are compulsory. So select some key figures along with the reference values.
→ It shows 4 options like
- SELECTION - What ever the fields we select here those fields can appear at DATA SELECTION tab of INFOPACKAGE.
- HIDE - What ever the fields we select here those fields can’t be appears in BW side.
- INVERSION - This option is available for Key figures. It takes – ve sign to the existing values.
- FIELD ONLY - This option also available for Key figures. If there is any Enhancement for a particular field at that time this is enabled.
So select whatever the fields we want as data selection and also to transfer rules otherwise hide other fields and click on SAVE.
- Now it shows “Data source has been saved successfully”.
Then go to BW side -> Create all the objects required to extract data from R/3 to BW system.
- Now Go to source system as shown below
→ Select R/3 to BW connection
→ Select your application component which we selected while creating the generic datasource and click on Replicate datasource.
- Create Infopackage to the Datasource after replicating the Datasource to BI system.
- Execute the Infopackage, so that the data from R/3 gets loaded to Datasource which is nothing but PSA.
- After loading the data to Datasource, create Transformations required to connect the Datasource and Data target (Infocube/DSO).
- Once the transformation is created and mapped with the source fields and objects create Data Transfer Process (DTP) and execute the DTP to load data from Data source to Data target.
TRANSACTION DATA LOADING USING GENERIC DELTA - Generic Delta approach is followed to enable the generic datasource for Delta update. If there are any changes in transaction data, in order to effect those changes in BW side, we go for Generic delta.
- In order to do this transaction data load using generic delta, first go to the T-CODE VA02 to change the sales orders related to SD (VBAK etc). Select the order by pressing F4 and do some changes that field may be the field, which we extracted already, or the other filed, but the effect can occur on the extracted fields.
- Go to ORDER QUANTITY and change the value. Normally price and quantity gets net value. So change ORDER QUANTITY value and then click on SAVE.
- Go to RSO2 and select your datasource and click on CHANGE. Then select GENERIC DELTA
- There are mainly 3 options available for generic delta.
• Calday – If we setup delta on base of calday we can run delta only once per day that to at the end of the clock to minimize the missing of delta records.
• Numeric pointer – This type of delta is suitable only when we are extracting data from a table which supports only creation of new records, but not change of exiting records
• Time stamp – Using timestamp we can run delta multiple times per day but we need to use the safety lower limit and safety upper limit with minimum of 5 minutes.
- We can setup 2 types of images,
- New status for changed records
- Additive delta
- If the update type is setup to NEW STATUS for changed records then it becomes mandatory for us to load data into ODS and then ODS to CUBE.
- Give the time field in Field Nm and select Time stamp, click on SAVE.
- Click on SAVE and SAVE.
I would like to know data how data reacts for different type of scenarios, if my update method is calendar day.
1) when my upper limit is 1 and lower limit is 2.
2) when my upper limit is 1 and lower limit is 1.
3) when my upper limit is 2 and lower limit is 1.
Here I assume Delta enabled filed is on Creation date.
On 18.12.2015:(assume that last delta was happend on 17.12.2015 i.e which has brought the delta records created upto 16.12.2015)
In case 1) all delta records created up to 17.12.2015(due to UL 1 ) .And also brings again the delta records which were created on 15.12.2015 and 16.12.2015 due to LL 2 (even though those were uploaded by the delta loads on 16.12.2015 and 17.12.2015 respectively)
In case 2) all delta records created upto 17.12.2015(due to UL 1 ) .And also brings again the delta records which were created on 16.12.2015 due to LL 1 (even though those were uploaded by the delta loads on 17.12.2015 )
In case 3) all delta records created upto 16.12.2015(due to UL 2 ) .And also brings again the delta records which were created on 15.12.2015 due to LL 1 (even though those were uploaded by the delta loads on 17.12.2015 )
on 19.12.2015(assume that last delta was happend on 18.12.2015 i.e which has brough the delta records created upto 17.12.2015)
In case 1) all delta records created upto 18.12.2015(due to UL 1 ) .And also brings again the delta records which were created on 16.12.2015 and 17.12.2015 due to LL 2 (even though those were uploaded by the delta loads on 15.12.2015 and 16.12.2015 respectively)
In case 2) all delta records created upto 18.12.2015(due to UL 1 ) .And also brings again the delta records which were created on 17.12.2015 due to LL 1 (even though those were uploaded by the delta loads on 18.12.2015 )
In case 3) all delta records created upto 17.12.2015(due to UL 2 ) .And also brings again the delta records which were created on 16.12.2015 due to LL 1 (even though those were uploaded by the delta loads on 18.12.2015 )
On 18.12.2015:(assume that last delta was happend on 17.12.2015 i.e which has brought the delta records created upto 16.12.2015)
In case 1) all delta records created up to 17.12.2015(due to UL 1 ) .And also brings again the delta records which were created on 15.12.2015 and 16.12.2015 due to LL 2 (even though those were uploaded by the delta loads on 16.12.2015 and 17.12.2015 respectively)
In case 2) all delta records created upto 17.12.2015(due to UL 1 ) .And also brings again the delta records which were created on 16.12.2015 due to LL 1 (even though those were uploaded by the delta loads on 17.12.2015 )
In case 3) all delta records created upto 16.12.2015(due to UL 2 ) .And also brings again the delta records which were created on 15.12.2015 due to LL 1 (even though those were uploaded by the delta loads on 17.12.2015 )
on 19.12.2015(assume that last delta was happend on 18.12.2015 i.e which has brough the delta records created upto 17.12.2015)
In case 1) all delta records created upto 18.12.2015(due to UL 1 ) .And also brings again the delta records which were created on 16.12.2015 and 17.12.2015 due to LL 2 (even though those were uploaded by the delta loads on 15.12.2015 and 16.12.2015 respectively)
In case 2) all delta records created upto 18.12.2015(due to UL 1 ) .And also brings again the delta records which were created on 17.12.2015 due to LL 1 (even though those were uploaded by the delta loads on 18.12.2015 )
In case 3) all delta records created upto 17.12.2015(due to UL 2 ) .And also brings again the delta records which were created on 16.12.2015 due to LL 1 (even though those were uploaded by the delta loads on 18.12.2015 )
- Go to BW side and again replicate the datasource.
- Follow the steps mentioned in the previous Transaction data loading process after replicating the Datasource in the BI system.
********************