Delta for new added fields to 0MAT_PLANT_ATTR

[Former Member]

Hi there,

I have enhanced the Data Source 0MAT_PLANT_ATTR with a few fields from table MBEW (MBEW-BWPRS, MBEW-BWPRH, MBEW-PEINH). I have written the code in Function exit: EXIT_SAPLRSAP_002 in order to populate the newly added fields. I have activated the message type belonging to 0MAT_PLANT_ATTR (transaction BD50). I have maintained the “Change document items for message type” (transaction BD52). I have activated “Change Pointers Generally” with transaction BD61. I have created the ALE change pointers for the newly added fields from table MBEW. On the BW side I have done all the configuration steps in order to bring the newly created fields into BW. So far so good.

The Data Source 0MAT_PLANT_ATTR is Delta capable. On the BW side at the Info Package level I set up the update mode as ‘Delta’ (of course I did the Initialisation first). Now, here comes the problem. When I change one of the fields I have added (MBEW-BWPRS, MBEW-BWPRH, MBEW-PEINH) <u>the Delta does not work</u> (BW does not see the changes made in R/3). But if I change a field belonging to table MARC (for example WEBAZ) the delta works fine. Now I understand that the Data Source 0MAT_PLANT_ATTR is mainly based on table MARC and a change on a field from table MARC is recognized by the system. Why is a change to a field from table MBEW not recognized as a change (delta) by the system? <u>Is this a normal behaviour or I am missing something? If I m missing something what is that?</u>

Thanks,

Dan Grecescu.

P.S. I am pretty much sure that all the changes/configuration I have done on the R/3 and BW sides are OK because when I do a change to the field MARC-WEBAZ in <u>the same time</u> with a change to the field MBEW-BWPRS, everything works fine, the system sees the changes and <u>all fields are nicely updated into 0MAT_PLANT.</u> Of course this is because the system sees the change done to MARC-WEBAZ. If I <u>only</u> do a change to MBEW-BWPRS, the system no longer sees it.

[Former Member]

HI All, 

I know its rather late for me.

However - I am encountering the same issue.

I did an extension to the 0VENDOR_ATTR by adding the EMAIL Address (ADR6-SMTP_ADDR).

However - when I am doing a delta just for the email address changes - it would not load.

Seems like the delta change does not detect Email address as part of the delta change.

If I do a full load then it works fine.

& If I make other field changes - it will bring in the delta - But not the Email Address

(a logic was added in the exit to retrieve email from ADR6 table)

Do I need to add the field into the ALE Change Pointer (BD52)?

I do not have authorization to change - therefore I am not able to test this.

Do I need to change the Datasource as ALE Delta to do this ? (currently it is set as generic delta)

This is strange as i am finding a solution to this issue but seems like no one has the solution....

Any idea?

Thanks in advance

[Former Member]

Hi Dan,

I am not sure here as to how you have enhanced the data source. But I think the information I have might be helpful in getting new ideas.

The way I see the issue is that the fields added to the data structure are not standard fields for that data structure. Hence, the standard delta mechanism might not be able to take care of those fields. Obviously, we would need to supply a logic for the same. Now this logic needs to be very robust, else we might end up in an inaccurate BW.

Me and my colleagues have conducted a study on this topic with the application area of Purchasing (02) and compiled our study in form of Weblogs. Find time to go through them and you might find answers to a lot of your questions and get more ideas

/people/sanyam.kapur/blog/2005/04/30/custom-fields-and-bw-extractors-making-a-mixed-marriage-work-part-ii

/people/ajay.das/blog/2005/03/28/custom-fields-and-bw-extractors-making-a-mixed-marriage-work-part-1-1

May be we can also end up compiling something for handling Master data.

Hope this helps.

Best Regards,

Sanyam

[Former Member]

I now I'm about 5.5 years too late. But anyone looking this thread up should know that there is a better way to get the MBEW field into 0MAT_PLANT and it is much easier and does not require any coding for the basic MBEW data.

Just create a generic datasource attribute datasource in RSO2 and base it on view MBEW. Click on DataSource at the top menu and choose ALE Delta. Then choose Table Name as MBEW and Change doc. object as Material.

Save it and you're done. Then you need to hook up the datasource to 0MAT_PLANT in BW.

I'm assuming the basic steps are known here .. like creating the generic datasource and connecting it to the master data object in BW.

Good Luck!

Brian

[Former Member]

Hi Dan

I know, I come a little bit late, but it would interest me how you solved this issue.

I had the same problematic that I wanted to have more information (such as Reorderpoint or Targetstock which is on table WRPL) and tryed to enhance the "RSxx" Message Type which was used for this DS.

But I saw that the std extractor only looks for Object MAT_FULL in this Message type (BD52).

And I didn't wanted to enhance the MSG type MAT_FULL with table WRPL to get them working.

So I decided myself to define my own Msg type and filled it with the fields I will have a change document with my Z-msg type. This one is working. Now then I wrote my own extractor which is reading the table BDCP and BDCPS for changes of this Msg type. Now I'm very flexible and the delta is working.

Also I included in my msgtype the WLK1 table to get changes on it - so we are able to hand over to BW a flag if the article is listed to a site or does it only have repl. info in and opposite.

The positive affect of all them was as well, that the extractor is now much faster as the std. one.

This is only my solution - and it would be very interested how you did the solution. This brings always new ideas.

Thank you

Roger