For many master data objects’ distribution SAP provides two level approach:
a) at first you send a whole master data objects
b) send changes (delta info) only using change pointer technology
This approach works for most of the “typical” master data like Materials, Vndors, Customers. Once you send a whole object only the delta information will be distributed. As far as the receiver is an another SAP system everything seems to be fine but in reality most of the third party systems cannot handle delta information and they expect the whole master data object even if only one parameter got changed. What are the options with SAP then?
Let me present a short description of a few possibilities on the basis of a most common master data object – Material.
1. Manual transfer – For sending initial Material Master IDoc you use transaction BD10 (after you configure a distribution model and partner profiles). It would be possible to run the same transaction everytime any material gets changed. The main drawback would be manual action which is required in this scenario. If you’d like to schedule BD10 somehow then all materials would be send each time and in cases there are thousands of hundrets of thousands of materials this is not the most efficient way.
2. User exit transfer – usually there are many user exits for master data maintanance transactions but some of them have a user exit during the save event. Such an exit can be used to invoke transaction for sending master data like BD10 with a specific material numer.
3. Change pointer “trick” – in standard change pointer technology allows sending delta information only so if you change one field in any master data object only this particular field will be distributed as an IDoc. Fortunately there are ways this can be changed even without doing any modifications/repairs to the SAP standard. With the introduction of Implicit Enhancement Options in ABAP Source Codes we can now change the part of code which is responsible for master data distribution to force sending only whole master data objects. One of the places in which an Implicit Enhancement can be added is at the end of a function module – check out help.sap.com <br />The module that we need to change is – CHANGE_POINTERS_READ and the code which can be added at the very end of this module is shown below: <br /> </p><table border=”0″><tbody><tr><td>FIELD-SYMBOLS <fs_bdcp> TYPE bdcp.<br />checking for correct IDoc message type as we only <br />want to distribute material master data in this way
>>Do you know - is it possible to use this trick in user exits for IDOCs other than MATMAS (for ex CREMAS/DEBMAS)?
if the IDoc uses change pointer technology
then it's probably possible but you need to check if the module in which I do this change it used
but I guess it should work 🙂
Regards,
Michal Krawczyk
Hi Michael,<br/><br/>I just tried this for CREMAS and entered the code as decribed. I also put a breakpoint in the enhancement to make sure the code gets executed and it did.<br/><br/>However, the IDOC was only partial. It did not contain all the data for the vendor.<br/><br/>Any idea?<br/><br/>This is my code:<br/>"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""$"$\SE:(2 ) Function Module CHANGE_POINTERS_READ, End D<br/>$$-Start: (2 )--
$$<br/>ENHANCEMENT 1 ZSEND_COMPLETE_CREMAS_IDOC. "active version<br/><br/> Need to send complete IDOC everytime a Vendor is changed otherwise XI mappings will fail.<br/>FIELD-SYMBOLS <fs_bdcp> TYPE bdcp.<br/>checking for correct IDoc message type as we only<br/>want to distribute vendor master data in this way<br/>if MESSAGE_TYPE = 'CREMAS'.<br/><br/>loop at change_pointers assigning <fs_bdcp>.<br/><br/> <fs_bdcp>-FLDNAME = 'ALELISTING'.<br/><br/>endloop.<br/><br/>endif.<br/><br/>ENDENHANCEMENT.<br/>$$-End: (2 )--
$$<br/>ENDFUNCTION.<br/>
Did you solve the problem? can you share with me the solution please?
Gustavo Balboa
I am using DEBMAS and for change pointer, i need to populate all segments, but after implemeting the code at the end of FM- change_pointers_read, i am not getting all segments.
Please help in this regard
Vinoth
awesome blog and thanks for this trick. We both know that this is (now was 😉 ) a main problem while distributing Master Data to NON SAP Systems.
BTW: The "MDM Extractor" can be customized like the "change pointer trick" 😉
Kind Regards,
Dries
thanks:)
my article about MDM extractors is here:)
https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/6062fba1-5a83-2b10-229f-d35d4ab09484
Regards,
Michal Krawczyk
>>To achieve this functionality I have written all sorts of code in many exits,
that's the point to have it all in once place
and not in many exits:)
thank you for reading 🙂
Regards,
Michal Krawczyk
thank you:)
Regards,
Michal Krawczyk
Did you check the possibility of this for other IDocs. Because, we need to do it for CLFMAS, but it seems it's not working. Can you confirm whether it had worked for you for other IDocs?
Thanks,
Hussain
We're implementing HRMD_A using change pointer, but I would like to know how we can enhance the change pointer to just send those changes in the infotype that are current and not send the ones that are future dated.
For example:
A user created a change in Infotype 1 that is going to be effective 1 week later. When BD21 is run we dont want the IDoc to be created until the system date is the same as the date in the actual data saved in the change pointer.
Is this possible.
Thanks,
Ricky
data sytabix type sytabix.
data r_infty type range of infotyp.
append 'IEQ0000' to r_infty.
append 'IEQ0001' to r_infty.
append 'IEQ0002' to r_infty.
append 'IEQ0105' to r_infty.
* the infotypes you want to send
loop at change_pointers into wa_bdcpv where mestype = 'ZIAM_HRMD_A'.
sytabix = sy-tabix.
if wa_bdcpv-tabkey+12(4) = '0000' or wa_bdcpv-tabkey+12(4) = '0001' or wa_bdcpv-tabkey+12(4) = '0002' or wa_bdcpv-tabkey+12(4) = '0105'."changepointers van deze infotypes wel verzamelen
submit rhaleini
with pchplvar = wa_bdcpv-tabkey+0(2)
with pchotype = wa_bdcpv-tabkey+2(2)
with infty in r_infty
with insert = space
with mestyp = 'ZIAM_HRMD_A'
* with pchactiv ...
* with pchbegda ...
* with pchcuttr ...
* with pchdepth ...
* with pchdymod ...
* with pchendda ...
* with pchistat ...
* with pchobeg ...
with pchobjid-low = wa_bdcpv-tabkey+4(8)
* with pchoend ...
* with pchopera ...
* with pchostat ...
* with pchotype ...
* with pchplvar ...
* with pchseark ...
* with pchsetgd ...
* with pchsobid ...
* with pchsvect ...
* with pchtimed ...
* with pchwegid ...
with pchztr_a = 'X'
with pchztr_d = space
with pchztr_f = space
with pchztr_m = space
with pchztr_p = space
with pchztr_y = space
with pchztr_z = space
* with proof ...
* with psize ...
* with rcvprn ...
* with rfcgr ...
* with snd_orig ...
* with subty ...
with update = 'X'
and return.
delete change_pointers index sytabix.
else.
delete change_pointers index sytabix.
endif.
endloop.
Heoneveld,
Your solution does not address Ricky's issue. It will not restrict the future dated changes. The question is how would you restrict BD21 to skip a particular change pointer whose BEGDA is greater than sy-datum? I don't think BAdI BDCP_BEFORE_WRITE can be used to do this. Any ideas?
Regards,
Sougata.
Hi,
I have the same problem described in the previous comments (distribute the whole idoc, even after changes, for both materials and BP).
The article linked by Michal Krawczyk is no more available.
Can you please help me to understand the best solution to provide?
Thank you