Within the BW forum community there are quite a few posts relating to the delta mechanism for Master Data extracts from R3, these posts tend to be of the
"My infopackage has gone red and it says repeat delta is not available"
To which a stock answer is - reinitialise...
Naturally, this is not the correct answer and this short weblog will help explain the background, the processing and more importantly how to request a failed Master Data Delta.
How to identify delta enable Master Data extractors
By running transaction RSA2 for a master data extractor we can identify whether the extractor uses ALE change pointer technology.
We are going to follow the example of 0MATERIAL_ATTR for the rest of the weblog.
In the example above we can see that the delta technology is via change pointers even though the Delta Process may be marked as •E (non specific) or A (ALE).
Process Type E - then utilises a function module (MDEX_CUSTOMER_MD) to read the change pointer tables.
Normally within the function module there will be split of processing dependent on the type of run:
WHEN FULL, WHEN INIT will read the base table MARA
WHEN DELTA - will read the ALE change pointer tables.
How to identify the Message Type
The Message Type is the key to all future delta processing by ALE Change Pointers.
We can find out the generated Message Type by reading the ROOSGEN table in the source system.
The generated Message Type will be different for all source systems within the transport landscape.
How to Ensure The Message Type is Active
Now we have the Message Type for 0MATERIAL_ATTR (RS0045), we can now check to see if it is active in table TBDA2.
How R3 Posts ALE Change Pointer Records for BW
When a user creates or changes a master data record, and that base table has associated with it a BW message type, then the ALE Change Pointer Tables will be updated.
In this example, MM01 is used to create a R3 Material Master Record.
This posts not only to MARA but also to table BDPCV.
The message type, RS0045, identifies it as a 0MATERIAL_ATTR change, and this record is a new record creation. (changeid = I)
In addition a record is posted to table BDCPS.
The important field here is the Process Indic field. This is initially set to blank.
How BW Extracts Master Data
As explained previously, the extractor function module will utilise different methods for reading the data from either the base tables or from the ALE Change Pointer tables.
The difference between FULL and INIT is purely down to set up of the initial entry in RSA7.
RSA7 will have 0 records, even though they may be deltas, this is because data is read at run time and not posted to the BW Delta Queue within the save transaction.
For a INIT or FULL infopackage, the data will originate from the base table MARA.
For a delta infopackage, all blank process indicator records from BDCPS are read for the Message Type associated with the datasource.
BDCPV is then read for those change pointer records, then the data from MARA is read to fill the rest of the extract structure.
Once the tRFC scheduler has sent the packages to BW, the process indicator on BDCPS is then set to X.
How to Request a Failed Delta
If you had read the last sentence on the previous paragraph you will notice the "Oh what if... " scenario start to raise it's head.
Because the process indicators have been set to X, and there is nothing in RSA7, how do you request a failed delta.
The solution is to run program RSA1BDCP in the source system.
The ABAP does not validate the selection screen, as such I strongly advise you to validate and fill in all fields.
If a field is left blank, all data will be reset and thus your next delta will be a bit larger than intended!
This ABAP will reset the process indicator field on BDPCS to blank from a given data forward.
The process therefore to request a failed delta is:
- Set the incorrect infopackage to green
- Run RSA1BDCP for a date greater than the last successful delta
- Rerun the delta infopackage
Clearing Up The Change Pointers
All of those BDCPV and BDCPS records take up an lot of space very quickly.
The normal resolution to this is to delete obsolete and already processed Change Records.
Luckily transaction BD22 will do exactly this - you shoudl set up a ABAP Variant for your Message Type and run this periodically.
In a SAP Retail Environment, you may end up running this every day with a deletion date of 3 days (to ensure a repeat delta is feasible)
Go Live and Reinitialisation Problems
if you have been reading this far, you will have noticed one glaring problem.
If we have 1,000,000 MARA records which we initialised, the data comes straight from MARA.
What then is the size of our first delta?
Answer: 1,000,000 MARA records...
Exactly, all those BDCPS records still have a process indicator of blank - remember INIT and FULL do not touch the ALE Change Pointer tables!
There are a number of ways to address this you could of course, ignore it... but if you have aggregates you will have a bit of pain on your next change rum.
Or we could anticipate the problem and either:
- Write an ABAP to update BDCPS to X
- Do an early initialisation before all the MARA records are created
- Clearing up the Change Pointers
- SAP Managed Tags:
19 Comments
