Skip to Content

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:

  1. Write an ABAP to update BDCPS to X
  2. Do an early initialisation before all the MARA records are created
  3. Clearing up the Change Pointers
To report this post you need to login first.

19 Comments

You must be Logged on to comment or reply to a post.

  1. Kenneth Murray
    This kind of information is greatly appreciated! 

    Although, it is unbelievable that Enterprise would need to go through this kind of process to correct a load.  Is this process documented anywhere by SAP?  It would be nice if we had something from SAP

    (0) 
  2. Sid m
    Hi,
    This is a nice Blog and thank you  for sharing the insights  of  it.

    @Kenneth, There is a  work  around for this problems i.e just to add the PSA  so that we can build the request from PSA. Please correct me if iam wrong.

    Regards,
    Rajesh

    (0) 
  3. Reshoi R
    Hi
    Thanks for the great blog!. But I have a doubt regarding the master data delta for 0MAT_VEND_ATTR datasource. There seems to be no standard message types attached to the above DS (Checked the table ROOSGEN and found the message type field is blank) .Hence the delta extraction seems to be time consuming than the full upload. For eg. Delta extraction of just 2000 records takes more than 5 hours to complete with more than 100 data packages(less number of records in each package),but Full extraction of the same with more than 1 million records takes only 30 to 40 minutes to complete(more than 100 data packages but with more number of records). Is there any standard workaround for this??
    NB: By checking RSO2, found that the extraction happens through a Function Module MEBW_INFORECORD_GET_DATA.

    Thanks in advance

    Reshoi

    (0) 
    1. Simon Turnbull Post author
      That is because it doesn’t use the change pointer functionality at all.
      It does reads of CDHDR and CDPOS instead.
      I would suggest you trace the SQL to see where the time is taken and take remedial aspects to resolve it (ie do a archiving run on CDHDR, CDPOS or do as someothers have done – create a generic datasource with your own change pointers to resolve the issue)
      (0) 
  4. Thomas Goodwin
    This is good information.  It would have saved me several hours of investigation on my own.

    The next question often seen in many forum posts goes along these lines:  “I have enhanced the 0MATERIAL_ATTR datasource with added fields.  These new fields may be standard fields from MARA/MARC, or they may be appended to MARA/MARC.  How can changes in these field values be collected in a delta extraction?”

    The changes to field values are posted in change documents and BDCPV, etc.  So presumably the new fields *just* need to be added to the message type in table TBD62….

    Thanks,
    Tom

    (0) 
    1. Simon Turnbull Post author
      Tom
      Thanks for the comments – I have had a look at the different ways of doin gthis – includingh the fix you mentioned
      But currently I am siggesting for my developers that they use a BTE to write the change pointer manually for field changes – and keep a record of the new fields inside a BW table
      ie a BW version of TVARC that can hold field names – then the BTE in the save document in R3 calls the table and checks the y and x itabs before firing the change document
      In addition if there are LESS fields then I disable the change pointer and fire a BTE to the BW delta queue directly (as per the How to Guides on SDN)..
      Many will ask the reason why… from my point of view it is risk mitigation.. in a upgrade there may be more or less fields added to the T* tables that control the change pointers.. and I have no control over that
      The two ways above – I do have control
      (0) 
  5. Jose Burgman
    Hello

    Since EHP4, SAP have moved away from using BDCPV and BDCPS tables, only BDCP2 is used. So I am not sure whether the delta mechanism fix will work if one is on EHP4.

    Great information otherwise.

    Thanks

    (0) 
  6. VISHNU Pattoor Subhash
    hi simon,
    this is a great article
    here you have explained about MARA,
    how do i find this kind of assosciated delta pointer tables for other datasources,where can we see this two tables for other datasources,
    (0) 
  7. Mayank Jaiswal

    Thanks a lot for sharing such a great piece of work ..

    Can you please tell how to check what all data sources are associated with this functionality or we can just assume that if message type is missing then ALE change pointer mechanism doesn’t hold for that Data source.

    Regards,

    Mayank

    (0) 
  8. Sandy Assum

    Is it possible to enhance the 0CUSTOMER_ATTR with a Z-field not n the KNA1 table and have changes to the Z-Field trigger a delta to this extractor?  In your response to Thomas Goodwin, you mention two solutions.  I like the idea of writing directly to the BW delta queue.  Before I start down this path, can you confirm that this approach will achieve what I want to do.  If not, what would be your recommendation to write a delta record when a Z-Field is changed/

    Thanks.

    (0) 
    1. Mayank Jaiswal

      Hi Sandy,

      I don’t think it is possible to enhance any DS with the custom field and based on custom Z field delta to happen.

      I would say create a custom DS on the table from which you want the Z field and do a daily full load if possible and then directly map the KUNNR and the required field with the Infofobject of 0CUSTOMER.

      So it will be a new flow from the Custom DS to 0Customer in which KUNNR is mapped to 0CUSTOMER and the Zfield will be directly mapped to corresponding infoobject (attribute of 0CUSTOMER).

      Let me know if it works.

      Regards,

      Mayank

      (0) 

Leave a Reply