Distribution of full master data objects from change pointers - Revisited

[uwe_schieferstein]

Introduction

When I came back from my holidays one of the first issues I had to solve at work was to distribute complete IDocs for material master data generated from change pointers. Fortunately Michal Krawczyk's The specified item was not found. hit the bull's eye and provided the solution.

However, since we are still on SAP release 4.6c enhancement techniques are not yet available. Modifying function module CHANGE_POINTERS_READ was not an option either because we would need to dig deeply into the ALE layers.

Chain of Calls

We have scheduled report RBDMIDOC which generates the MATMAS IDocs using change pointers. This report does not yet generate the IDocs but is responsible for locking table BDCPS (Change pointer: Status) for the selected message type.

The report calls another report RBDMIDOX which makes a call to fm MASTERIDOC_CREATE_SMD_CLSMAS in which the change pointers are read using fm CHANGE_POINTERS_READ. Thus, the chain of calls looks like this:

RBDMIDOC -> RBDMIDOX -> MASTERIDOC_CREATE_SMD_CLSMAS -> CHANGE_POINTERS_READ

I assume you understand my reluctance against any modification better now. 

The Change Pointer Trick

Change pointer records are save in table BDCP. The field BDCP-FLDNAME contains the name of the field that was changed in the master data resulting in a change pointer. 

The quintessence of the trick devised by Michal is: When we change the contents of BDCP-FLDNAME to 'ALELISTING' the master data are transferred in its entirety.

The Solution (available on 4.6c, too)

Instead of changing the change pointer records dynamically at the end of the process my solution modifies the records persistently at the beginning of the process.

1. Copy RBDMIDOC to ZRBDMIDOC

In the selection-screen section of the report I just added a new checkbox parameter used to trigger full distribution.   

*&---------------------------------------------------------------------**& Report  ZRBDMIDOC                                                   **&                                                                     **&---------------------------------------------------------------------**& Description:                                                        **&---------------------------------------------------------------------**& Report copied from:*&        RBDMIDOC (IDocs aus den Änderungszeigern erzeugen)           **&                                                                     **& The standard report generates IDocs having only the                 **& Delta data but not the entire master data.                          **&                                                                     **& This Z-report allows to distribute full master data from            **& change pointers. The required trick has been described by           **& Michal Krawczyk:                                                    **& "Distribution of full master data objects from change pointers "    **& Reference:                                                          **& <span>The specified item was not found.</span>         **&                                                                     **& NOTE: Instead of using implicit enhancement which is not available  **&       on 4.6c we just create a Z-version of the standard report.    **&---------------------------------------------------------------------**& CHANGE LOG                                                          **&---------------------------------------------------------------------**& nn.nn.nnnn  name of developer (emailaddress@domain.com)             **&             >nnn< :                                                 **&---------------------------------------------------------------------**& 05.08.2009  Uwe Schieferstein (uschieferstein@lindt.com)            **&             >000< : Report created                                  **&---------------------------------------------------------------------*REPORT zrbdmidoc MESSAGE-ID b1.* Changes:* XLP 031298: CCMS-Runtime-MonitoringTABLES: tbdme, edimsgt.INCLUDE mbdconst.INCLUDE rbdauthi.INCLUDE rsecccms.                                           "XLP031298DATA: BEGIN OF t_tbdme OCCURS 0.        INCLUDE STRUCTURE tbdme.DATA: END OF t_tbdme.DATA: read_flag TYPE c VALUE space.PARAMETERS: mestyp LIKE tbdme-mestyp OBLIGATORY MATCHCODE OBJECT tbdme.* >000< INSERT: begin ofSELECTION-SCREEN BEGIN OF BLOCK bl1 WITH FRAME TITLE text-bl1.PARAMETERS:  p_full AS CHECKBOX  DEFAULT ' '.  " Default = Delta, 'X' = FullSELECTION-SCREEN END OF BLOCK bl1.* >000< INSERT: end of...

2. Persistently modify change pointer records on demand

In the main section of the report I added the routine for updating the change pointer records. Note that finally the standard report RBDMIDOC is executed.

...* distribute IDOCs for a given message typeSTART-OF-SELECTION.  CALL FUNCTION 'ENQUEUE_E_BDCPS'       EXPORTING            mode_bdcps     = 'E'            mandt          = sy-mandt*           cpident        =            mestype        = mestyp       EXCEPTIONS            foreign_lock   = 1            system_failure = 2            OTHERS         = 3.  IF sy-subrc = 1.    MESSAGE e115 WITH mestyp.  ELSEIF sy-subrc = 2 or sy-subrc = 3.    MESSAGE e156 WITH mestyp.  ENDIF.* >000< INSERT: begin of**  SUBMIT rbdmidox WITH mestyp = mestyp AND RETURN.  IF ( p_full = 'X' ).    PERFORM update_change_pointer_records USING mestyp.* Standard execution  ELSE.  ENDIF.  CALL FUNCTION 'DEQUEUE_ALL'.  SUBMIT rbdmidoc WITH mestyp = mestyp AND RETURN.* >000< INSERT: end ofEND-OF-SELECTION....

This routine does the same as already described by Michal except that the changes are persistent in the DB table.

...*&---------------------------------------------------------------------**&      Form  UPDATE_CHANGE_POINTER_RECORDS*&---------------------------------------------------------------------**       NOTE: Overwriting of the fieldname that actually was changed*             with 'ALELISTING' ensures that the full master data are*             sent.*----------------------------------------------------------------------**      -->UD_MESTYP  Message Type*----------------------------------------------------------------------*FORM update_change_pointer_records                               USING                                  value(ud_mestyp) TYPE edi_mestyp.* define local data  CONSTANTS:    lc_fld_alelisting  TYPE fieldname  VALUE 'ALELISTING'.  DATA:    lt_bdcpv      TYPE STANDARD TABLE OF bdcpv,    ls_bdcp       TYPE bdcp,    lt_bdcp       TYPE STANDARD TABLE OF bdcp.*   Select all not yet processed change pointers  SELECT        * FROM  bdcpv INTO TABLE lt_bdcpv         WHERE  mestype  = ud_mestyp         AND    process  NE 'X'.  CHECK ( syst-subrc = 0 ).  SELECT        * FROM  bdcp INTO TABLE lt_bdcp    FOR ALL ENTRIES IN lt_bdcpv         WHERE  cpident  = lt_bdcpv-cpident.  CHECK ( syst-subrc = 0 ).  CLEAR: ls_bdcp.  ls_bdcp-fldname = lc_fld_alelisting.  MODIFY lt_bdcp FROM ls_bdcp    TRANSPORTING fldname    WHERE ( fldname NE lc_fld_alelisting ).  UPDATE bdcp FROM TABLE lt_bdcp.  COMMIT WORK AND WAIT.ENDFORM.                    " UPDATE_CHANGE_POINTER_RECORDS

The following screenshot shows the different selection-screens of the standard and the Z-report:

Summary

The advantages of the solution described above are:

• The functional difference between standard and Z-report is highly visible to the user by just looking at the selection-screens. If the flag is unmarked the Z-report just executes the standard report.
• There is no need for any user-exit or modification (I subsume "enhancements" under modifications...).
• The solution can be implemented on older SAP releases (e.g. 4.6c). 

Admittedly the direct DB update is "bad" programming but at the end of the day that is how we wanted the change pointer records to look like.

Conclusion

Before rushing towards user-exits or modifications (and enhancements) twist your solution around and see it from a different angle. You may come up with a tiny little "plug-in" that you can put on top (or ahead) of the standard and whose function is obvious to the user.

Appendix

Here the entire coding of ZRBDMIDOC:

*&---------------------------------------------------------------------**& Report  ZRBDMIDOC                                                   **&                                                                     **&---------------------------------------------------------------------**& Description:                                                        **&---------------------------------------------------------------------**& Report copied from:*&        RBDMIDOC (IDocs aus den Änderungszeigern erzeugen)           **&                                                                     **& The standard report generates IDocs having only the                 **& Delta data but not the entire master data.                          **&                                                                     **& This Z-report allows to distribute full master data from            **& change pointers. The required trick has been described by           **& Michal Krawczyk:                                                    **& "Distribution of full master data objects from change pointers "    **& Reference:                                                          **& <span>The specified item was not found.</span>         **&                                                                     **& NOTE: Instead of using implicit enhancement which is not available  **&       on 4.6c we just create a Z-version of the standard report.    **&---------------------------------------------------------------------**& CHANGE LOG                                                          **&---------------------------------------------------------------------**& nn.nn.nnnn  name of developer (emailaddress@domain.com)             **&             >nnn< :                                                 **&---------------------------------------------------------------------**& 05.08.2009  Uwe Schieferstein (uschieferstein@lindt.com)            **&             >000< : Report created                                  **&---------------------------------------------------------------------*REPORT zrbdmidoc MESSAGE-ID b1.* Changes:* XLP 031298: CCMS-Runtime-MonitoringTABLES: tbdme, edimsgt.INCLUDE mbdconst.INCLUDE rbdauthi.INCLUDE rsecccms.                                           "XLP031298DATA: BEGIN OF t_tbdme OCCURS 0.        INCLUDE STRUCTURE tbdme.DATA: END OF t_tbdme.DATA: read_flag TYPE c VALUE space.PARAMETERS: mestyp LIKE tbdme-mestyp OBLIGATORY MATCHCODE OBJECT tbdme.* >000< INSERT: begin ofSELECTION-SCREEN BEGIN OF BLOCK bl1 WITH FRAME TITLE text-bl1.PARAMETERS:  p_full AS CHECKBOX  DEFAULT ' '.  " Default = Delta, 'X' = FullSELECTION-SCREEN END OF BLOCK bl1.* >000< INSERT: end of* authority checkAT SELECTION-SCREEN.  PERFORM authority_check_master_data USING mestyp c_true.* list all message types which have function modules*T SELECTION-SCREEN ON VALUE-REQUEST FOR MESTYP.* IF READ_FLAG = SPACE.*   SELECT * FROM TBDME INTO TABLE T_TBDME WHERE IDOCFBNAME <> SPACE.*   READ_FLAG = 'X'.* ENDIF.* PERFORM F4HELP_FBNAME_CHECK TABLES T_TBDME.* message type checkAT SELECTION-SCREEN ON mestyp.  IF read_flag = space.    SELECT * FROM tbdme INTO TABLE t_tbdme WHERE idocfbname <> space.    read_flag = 'X'.  ENDIF.  LOOP AT t_tbdme WHERE mestyp = mestyp.    EXIT.  ENDLOOP.  IF sy-subrc <> 0.    MESSAGE e157 WITH mestyp.  ENDIF.* distribute IDOCs for a given message typeSTART-OF-SELECTION.  CALL FUNCTION 'ENQUEUE_E_BDCPS'       EXPORTING            mode_bdcps     = 'E'            mandt          = sy-mandt*           cpident        =            mestype        = mestyp       EXCEPTIONS            foreign_lock   = 1            system_failure = 2            OTHERS         = 3.  IF sy-subrc = 1.    MESSAGE e115 WITH mestyp.  ELSEIF sy-subrc = 2 or sy-subrc = 3.    MESSAGE e156 WITH mestyp.  ENDIF.* >000< INSERT: begin of**  SUBMIT rbdmidox WITH mestyp = mestyp AND RETURN.  IF ( p_full = 'X' ).    PERFORM update_change_pointer_records USING mestyp.* Standard execution  ELSE.  ENDIF.  CALL FUNCTION 'DEQUEUE_ALL'.  SUBMIT rbdmidoc WITH mestyp = mestyp AND RETURN.* >000< INSERT: end ofEND-OF-SELECTION.*---------------------------------------------------------------------**       FORM F4HELP_FBNAME_CHECK                                      **---------------------------------------------------------------------*FORM f4help_fbname_check TABLES t_tbdme STRUCTURE tbdme.  DATA: BEGIN OF t_help_value OCCURS 0.          INCLUDE STRUCTURE help_value.  DATA: END OF t_help_value.  DATA: BEGIN OF values OCCURS 0, string(50), END OF values.  t_help_value-tabname = 'EDIMSG'.     " field title EDIMSG-MESTYP  t_help_value-fieldname = 'MESTYP'.  MOVE 'X' TO t_help_value-selectflag.  APPEND t_help_value.  t_help_value-tabname = 'EDIMSGT'.    " field title EDIMSGT-DESCRP  t_help_value-fieldname = 'DESCRP'.  MOVE ' ' TO t_help_value-selectflag.  APPEND t_help_value.  LOOP AT t_tbdme.    MOVE t_tbdme-mestyp TO values.    APPEND values.    CLEAR edimsgt.    SELECT SINGLE * FROM edimsgt         WHERE mestyp = t_tbdme-mestyp AND langua = sy-langu.    MOVE edimsgt-descrp TO values.    APPEND values.  ENDLOOP.  CALL FUNCTION 'HELP_VALUES_GET_WITH_TABLE'       IMPORTING            select_value = mestyp       TABLES            fields       = t_help_value            valuetab     = values.ENDFORM.*&---------------------------------------------------------------------**&      Form  UPDATE_CHANGE_POINTER_RECORDS*&---------------------------------------------------------------------**       NOTE: Overwriting of the fieldname that actually was changed*             with 'ALELISTING' ensures that the full master data are*             sent.*----------------------------------------------------------------------**      -->UD_MESTYP  Message Type*----------------------------------------------------------------------*FORM update_change_pointer_records                               USING                                  value(ud_mestyp) TYPE edi_mestyp.* define local data  CONSTANTS:    lc_fld_alelisting  TYPE fieldname  VALUE 'ALELISTING'.  DATA:    lt_bdcpv      TYPE STANDARD TABLE OF bdcpv,    ls_bdcp       TYPE bdcp,    lt_bdcp       TYPE STANDARD TABLE OF bdcp.*   Select all not yet processed change pointers  SELECT        * FROM  bdcpv INTO TABLE lt_bdcpv         WHERE  mestype  = ud_mestyp         AND    process  NE 'X'.  CHECK ( syst-subrc = 0 ).  SELECT        * FROM  bdcp INTO TABLE lt_bdcp    FOR ALL ENTRIES IN lt_bdcpv         WHERE  cpident  = lt_bdcpv-cpident.  CHECK ( syst-subrc = 0 ).  CLEAR: ls_bdcp.  ls_bdcp-fldname = lc_fld_alelisting.  MODIFY lt_bdcp FROM ls_bdcp    TRANSPORTING fldname    WHERE ( fldname NE lc_fld_alelisting ).  UPDATE bdcp FROM TABLE lt_bdcp.  COMMIT WORK AND WAIT.ENDFORM.                    " UPDATE_CHANGE_POINTER_RECORDS

[MichalKrawczyk]

hi Uwe,

again an excellent blog from you:)
I'm happy my blog gave you some idea
to build your own solution

Regards,
Michal Krawczyk

[Former Member]

Hi Uwe

Excellent blog, but just wanted to point out that changing the fieldname to 'ALELISTING' works just for Material master. It doesnt work for Vendors or Customers.  Also now we can use the new change pointer table BDCP2 for the message types we want, thus the code is not going to be generic.

I will put what we did for Customers/ Vendors  / Articles ( Material ) in a single program to achieve the same functionality without using the direct DB update.

[uwe_schieferstein]

Thank you for pointing out this restriction. Actually I did not test my solution for any other message type because we did not have such a requirement.

I'll keep my fingers crossed that we will be on ERP 6.0 next years as well (like several other Lindt companies) so that we can use the latest available features.

Regards
  Uwe

[Former Member]

Can you tell us how to distribute for other Message Types like DEBMAS, CREMAS etc.

Thanks.

[Former Member]

Hi Michal,

Can you tell us how to distribute for other Message Types like DEBMAS, CREMAS etc.

It didn't work for other Message Types.

Can you give us your inputs or solutions.

Thanks

[Former Member]

Hi Manish

I am currently trying to do something equivalent but for Customers using DEBMAS, and have found (as you pointed out) that this solution does not work.

Have you found an alternative solution?  Can you suggest a way I can force the whole DEBMAS message to be generated?

[Martin-Schmid]

The idea of updating the change pointer table (now BDCP2) is still good. Even though enhancements are very popular nowadays I prefer this transparent solution.

To send full DEBMAS IDOCs my report updates the BDCP2-CDOBJCL from “DEBI” to “DEBITOR”. Afterwards the function module MASTERIDOC_CREATE_SMD_DEBMAS will “resend” complete IDOCs. Read there from line 734.

Unfortunately, we did not find out how to make the system create BDCP2 entries with object class “DEBITOR”. Does anybody know how to achieve this?

Regards,
Martin