Distribution of full master data objects from change pointers

June 4, 2009 | 739 Views |

Michal Krawczyk

more by this author

SAP Cloud Platform Integration for process services

sap process integration (pi)

Follow RSS

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 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: <table border=”0″><tbody><tr><td>FIELD-SYMBOLS <fs_bdcp> TYPE bdcp. checking for correct IDoc message type as we only want to distribute material master data in this way

To report this post you need to login first.

15 Comments

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

Michal Krawczyk Post authorJune 4, 2009 at 12:46 pm

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)
1. Former Member November 23, 2009 at 6:39 am
 
 Hi Michael, 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. However, the IDOC was only partial. It did not contain all the data for the vendor. Any idea? This is my code: ”””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””$”$\SE:(2 ) Function Module CHANGE_POINTERS_READ, End D $$-Start: (2 )–
 
 $$ ENHANCEMENT 1 ZSEND_COMPLETE_CREMAS_IDOC. “active version   Need to send complete IDOC everytime a Vendor is changed otherwise XI mappings will fail. FIELD-SYMBOLS <fs_bdcp> TYPE bdcp. checking for correct IDoc message type as we only want to distribute vendor master data in this way if MESSAGE_TYPE = ‘CREMAS’. loop at change_pointers assigning <fs_bdcp>. <fs_bdcp>-FLDNAME = ‘ALELISTING’. endloop. endif. ENDENHANCEMENT. $$-End: (2 )—
 
 $$ ENDFUNCTION. 
 
 like (0)
 1. Former Member May 28, 2010 at 9:58 am
 
 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)
 1. Former Member June 9, 2010 at 6:33 am
 
 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)
Former Member June 4, 2009 at 1: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)
1. Michal Krawczyk Post authorJune 4, 2009 at 7:28 pm
  
  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)
Former Member June 8, 2009 at 12: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)
1. Michal Krawczyk Post authorJune 8, 2009 at 12:52 am
  
  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)
Former Member June 12, 2009 at 10:03 am

One more wonderful contribution.

like (0)
1. Michal Krawczyk Post authorJune 12, 2009 at 10:09 am
  
  hi Pooja,
  
  thank you:)
  
  Regards,
  Michal Krawczyk
  
  like (0)
Former Member June 19, 2009 at 2:08 am

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)
Former Member June 1, 2010 at 11:06 pm

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.

like (0)
Ricky Orea July 14, 2011 at 12: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.

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 September 16, 2011 at 4: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.

like (0)
1. Former Member July 29, 2012 at 5:01 am
  
  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.
  
  like (0)