Getting Started Newsletters Store

Products Services & Support About SCN Downloads

Industries Training & Education Partnership Developer Center
Lines of Business University Alliances Events & Webinars Innovation
Log On Join Us Hi, Guest Search the Community
Activity Communications Actions
Browse
Average User Rating
(0 ratings)
0 Tweet 0
Process Integration (PI) & SOA Middleware
Previous
post
Next
post
0 Tweet 0
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
5135 Views Tags: sap_process_integration_(pi)
Distribution of full master data objects from change
pointers
Posted by Michal Krawczyk in Process Integration (PI) & SOA Middleware on Jun 4, 2009 1:15:41 PM
Share 0 Like
Share 0 Like
16 Comments
Artem Osukhovsky Jun 4, 2009 1:50 PM
Like (0)
Hello Michal! Thanks for your very interesting blogs and let me ask a little question...
Do you know - is it possible to use this trick in user exits for IDOCs other than MATMAS (for ex
CREMAS/DEBMAS)? As i understand - i have to look into source code of corresponding
changepointer evaluation modules to find out...
Like (0)
Michal Krawczyk Jun 4, 2009 2:46 PM (in response to Artem Osukhovsky)
hi,
>>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
Like (0)
Robert Kuhn Nov 23, 2009 7:39 AM (in response to 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/>
Like (0)
Gustavo Balboa Villaf ae May 28, 2010 11:58 AM (in response to Robert Kuhn)
Hi, I have exactly the same problem but I'm trying to use the HRMD_A
Message type.
Did you solve the problem? can you share with me the solution please?
Gustavo Balboa
Like (0)
Vinoth Kumar Jun 9, 2010 8:33 AM (in response to Gustavo Balboa
Villaf ae)
Hi Michal & Gustavo
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
Like (0)
Hussain Shaik Jun 19, 2009 4:08 AM (in response to Artem Osukhovsky)
Hello Artem,
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
Like (0)
Dries Guth Jun 4, 2009 3:06 PM
Micheal,
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
Like (0)
Michal Krawczyk Jun 4, 2009 9:28 PM (in response to Dries Guth)
Hi,
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
Like (0)
Sajay Abraham Jun 8, 2009 2:21 AM
To achieve this functionality I have written all sorts of code in many exits, I think this is a wonderful
contribution. Many thanks!
Like (0)
Michal Krawczyk Jun 8, 2009 2:52 AM (in response to Sajay Abraham)
hi,
>>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
Like (0)
Pooja Pandey Jun 12, 2009 12:03 PM
One more wonderful contribution.
Like (0)
Michal Krawczyk Jun 12, 2009 12:09 PM (in response to Pooja Pandey)
hi Pooja,
thank you:)
Regards,
Michal Krawczyk
Like (0)
Anilkumar Kondur Jun 2, 2010 1:06 AM
I have one question about this trick, is this only for the standard message types or can we use this
one for the Custom Message type.
Ricky Orea Jul 14, 2011 2:15 PM
Hi there,
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.
Like (0)
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
Like (0)
L. Hoeneveld Sep 16, 2011 6:18 AM
In the implementation of BADI BDCP_BEFORE_WRITE (SE18) you can add the following code to
send more than the infotype that is changed:
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.
Sougata Chatterjee Jul 29, 2012 7:01 AM (in response to L. Hoeneveld)
Follow SCN
Site Index Contact Us SAP Help Portal
Privacy Terms of Use Legal Disclosure Copyright
Like (0)
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.