0UC_SALES_STATS_01 / DBESTA_BWPROT - two independent extractions possible?

[matus_lojan]

Hi all,

I would like to gather some information about the 0UC_SALES_STATS_01 datasource and its extractor:

When already extracting data from this datasource using delta to an infocube, is it safe to start another extraction from this datasource and to load another cube (using gradually full, init and then delta)? Won't it interfere in some way with the current delta?

Some documents that I found on the sap portals mention the DBESTA_BWPROT table which stores the information about the not-yet-closed reconciliation keys. Can you please explain me who fills that table, when it fills it, and when the data is deleted from it?

If I started another independent extraction from this datasource (as hinted above) would the both extractions (current delta and new full/init/delta) use the same DBESTA_BWPROT table?

Many thanks for all your advices/tips on this datasource!

Regards,

Matus

[former_member283363]

Hi Matus,

Whenever you extract the data from datasource, it will not consider the target where you are loading this data. So, when you run a delta infopackage for cube1, the table gets updated with the current timestamp.Again when delta infopackage is run for cube2, the extraction for cube2 will take place from the timestamp that got updated in the table to the current timestamp.

If you are using generic delta for your datasource, updating to the table happens automatically. Else, the extractor should handle the updation.

Regards,

Shailaja

[matus_lojan]

Hi Shailaja,

thanks for your reply. May I ask what table did you mean, the delta table or DBESTA_BWPROT table? (The DBESTA_BWPROT table doesn't have any atributes indicating a timestamp.)

BTW the mentioned datasource didn't allow me to start another initialization. I'll have to cancel the current initialization (for cube1) and only then start a new one (for cube2) - which wouldn't be a problem, I wanted to cancel uploading the cube1 and load only the cube2 anyway, but I worry whether the delta upload going to cube1 doesn't interfere with the full upload going to the cube2 (and vice versa) in regard to open/closed reconciliation keys in the DBESTA_BWPROT table.

I would like to know more about the mechanism of inserting/deleting rows into/from this table and about possible threats to data consistency when doing full upload of similar data sets to cube2 as would the delta upload to cube1 use.

*********************

This is how I understand the mechanism so far : when you run a full upload, it extracts all the documents that fulfill the selection criteria apart from those whose reconciliation key is not yet closed and it writes down the IDs of these not-yet-closed reconciliation keys into the DBESTA_BWPROT table.

Then, when you run an init upload (with the same selection criteria as full has), it looks into the dbesta_bwprot table and checks whether the reconciliation keys in this table weren't closed meanwhile (since the full upload was run). It then extracts only the documents related to those closed reconciliation keys. And it presumably deletes the IDs of those closed reconciliation keys from this table.

But what happens when you then start a delta upload? Does it also look into that dbesta_bwprot table and checks whether the reconciliation keys in this table weren't closed since last upload? Does delta extraction also access this dbesta_bwprot table?

*********************

Many thanks for sharing your experience!

Matus