Generic Extraction - FM - delta enabling

[Former Member]

Hi experts,

We have a requirement for a report to develop in BW. The fields required for this transaction data report are from different tables ( all from SD) i.e, some from Standard Tables and few from Customized. Out of 20 fields to derive, each field has different logic (like loops and Read from multiple Tables).

So we have Choose to create generic DS with FM based.  

Now the issue lies while writing the FM code in Enabling the Delta. My Custom tables has a Date Field or Time field but whereas Few Standard tables do not have created or Changed Date Field (eg: VBPA).

Question 1: If i use time stamp delta, i do not have a Time stamp field in any of the SD tables (both Standard & Customized). Can i create a Dummy field like TMSTMP (time stamp) in my structure and use the same to extract Delta records ? will it work ? If so, will it capture data for all the changed fields ?

Question 2: Can we use 0Calday.. Since few of the standard tables do not have Date Field, so if that table gets updated with new/changed records, will this delta Capture those ? Or can u please suggest any way on how to extract data in this case ??

Or any other alternative solution for my requirement within functional Module..

Awaiting for your valuable inputs !!!

Thanks,

Radhika

[pradip_nikam2]

Hi Radhika,

Using dummy field for Time stamp / date won't solve your problem. For delta to trigger, value of those fields must be changed or updated whenever you create or change corresponding document.

Below are few options for your requirement:

1.

Here you need to understand relationship between tables. As you have given example of VBPA table.

VBPA does not have any date or timestamp related field, but it works along with VBAK & VBAP tables as all these tables have common VBELN (Sales Document) as primary key. So you have VBAK & VBAP with delta specific fileds.

So whenever any new document is created or changed in VBAK & VBAP, your delta logic should pick up those records from VBAK & VBAP tables and along with this you need to pick the corresponding records from VBPA table using VBELN field. This is how your delta logic will work. You need not to have separate delta specific field in VBPA.

You can get table relationship information from functional consultant.

On parallel lines you need find relationship between other tables & prepare the logic for delta trigger.

2.

Then also if you need to build delta logic for VBPA table then in that case you can use two tables CDHDR & CDPOS. In these two tables changes in the ECC tables get stored along with change date.

On SDN you can find information about the working of CDHDR & CDPOS tables.

But these table has performance issue as most of the ECC table changes get recorded in these two tables.

Hope this 'll solve your problem.

If you find this answer relevant, please assign points to this answer.

Thanks & Regards,

Pradip Nikam

[Former Member]

Thanks Pradip for your response.

It is a good example that you explained for VBPA. But i have few more such kind of tables. All i need to find the relation will be little complex i believe.

In this case, do i need to use 0Calday or Timestamp ??

I have read one of the document in SDN - (Using Timestamps in Generic Delta Extraction by Function Module -by suhas Karnik). It has been mentioned to use a dummy Time stamp field to enable delta.

I'm not good at ABAP part, but i was thinking that if the dummy time stmp field can be included while Creating the Structure and use the same in the Functional Module to get the delta..( document has the same thing in it).

Any inputs on the 2nd Question ??

Experts, any further inputs ??

[pradip_nikam2]

Hi Radhika,

I gone through the document published by Suhas Karnik. In that document he has used existing date & time fileds of table for generating Timestamp data.

Regarding you 2nd question: Basic requirement for any table on which you want to create datasource based on delta need to have delta specific filed like date, time etc. You have mentioned that your few tables don't have date/time fields then you can not create Delta Datasouce for those tables. Like I mentioned in my earlier message that for those tables you need to find the dependency/relationship between tables so that you can connect those tables with tables having delta specific fields.

Or you can go for below option:

Create separate datasource for each table. For those tables having delta field create delta datasource & for those tables do not have delta specific field you can create datasource without delta means with full load functionality.

This has disadvantage of multiple objects generation & maintainance in BW & increased data volume. Though you can use data deletion functionality in Process chain before triggering full load. And then apply logic in BW.

Hope this helps to clear your doubt.

Regards

Pradip

[former_member185132]

Hi Radhika,

The delta field (whether it is numeric pointer, timestamp or date) needs to be in the table in some form. In the example from my doc, the Date and Time fields were present separately. All the FM did was the split up the delta timestamp into the date and time components and used it to identify the delta records.

So while you are right that the timestamp was not in the table, the date and time fields that constitute the timestamp were present. If date/timestamp/pointer are not present in the table then you cannot perform delta.

I agree with Pradip's answer: create a separate DS for each table.

Alternatively, explore the possibility of enhancing the 2LIS_11* extractors with the fields you need.

Regards,

Suhas

[Former Member]

Thanks Again Pradip.

Appreciate for your possible solutions !!

I think we can't add any Date or time field to the Standard Tables like VBPA but we can add those to the Ztables. So i would follow your option of Delta for the Ztables & Full for those which do not have Date or time. I have enquired about the data with the functional consultants, it is going to be less ( like <10000 records per Delta which will run once per day). So let me try this

Another information i require is, how could the Full load needs to be loaded in to BW.. i know it definitely needs to be to DSO, but with over write options ?? Also the process chain option you mentioned i somehow have a doubt, if the Delta Data source and Full data sources are loaded in to the Same Cube, which option i need to keep to delete the request( for full load).. will this delete the delta records ?? Pls suggest me on this.

Thanks Suhas for your clarification

Regards,

Radhika

[former_member185132]

Hi Radhika,

To answer your question about how to design the data flow: create separate DataSources for each table. Get each DataSource into a separate acquisition DSO. If it is a full load then overwrite mode is essential.

Do not load directly from the acq. DSO to the cube. Instead, create a consolidation DSO, which will contain the required fields. Load from the acq. DSOs to the consolidation DSO. ABAP code might be required depending on the logic that should be used to combine the data.

After that, have a 1:1 transformation (i.e. NO code, logic etc, only direct mappings) between Cons. DSO to the cube. This design will take care of the delta.

Regards,

Suhas