uwe.schieferstein

XI/PI: Generating EDI Interchange Control Numbers Using ABAP Class Mapping

Uwe Schieferstein — Tue, 19 Oct 2010 12:38:13 GMT

Introduction

Most of the retail customers which are EDI trading partners of Lindt companies demand that EDI INVOIC messages are labelled with a unique and sequential Interchange Control Number (ICN) without gap. As already mentioned in a previous What SAP may have forgotten to integrate we do not use a full-blown EDI Adapter like Seeburger but just an "Add-On" (for more details contact http://www.resource.ch about their rEDI Adapter). This rEDI Adapter is highly versatile and does an excellent job for all kinds of EDI messages we employ but it had one major drawback: the generated ICNs were not part of the XML-EDI message and, therefore, could not be searched for in the XI monitoring.This became a dilemma as soon as INVOIC messages were rejected by customers (see Blog What SAP may have forgotten to integrate).

As a consequence I decided to use SAP standard means for generating document numbers (ICN = document number of an EDI message):

1. Use Number Range Objects (SNRO) to generate numbers.

2. Use ABAP Class mapping to incorporate the numbers as ICN into the EDI messages.

Defining Number Ranges for ICN Generation

As a prerequisite a number range object (SNRO) containing multiple number ranges is created. Each number range may be used for either all outbound messages or a certain message type (e.g. INVOIC) sent to an EDI partner.

The NR object ZEDICH_N06 defines 6-digit number ranges for multiple customers. The first customer (range = 00) has received already 1001 INVOIC messages, the second customer 146, the third one 1750 and so on.

Within the ABAP mapping class the correct NR object and number range are set in the CONSTRUCTOR method.

Implementation of Interface IF_MAPPING

In order to create an ABAP mapping class we need to implement method IF_MAPPING~EXECUTE as described e.g. in Michal Krawczyk's blog (The specified item was not found. and the SAP Online Help (ABAP Mappings).For maintenance reasons I split the sample coding of the Online Help into distinct methods (e.g. INIT_INPUT_STREAM, PARSE_DOCUMENT, INIT_OUTPUT_STREAM).

Methods PREPROCESSING and POSTPROCESSING enable the developer to do a pre-processing e.g. of the XML-IDoc stream and a post-processing of the XML-EDI stream. Here I will focus on the POSTPROCESSING method because our target is to add the new Interchange Control Number (ICN) into the XML-EDI stream.

Post-Processing of the XML-EDI Stream (Adding the ICN)

Method POSTPROCESSING is protected and needs to be re-defined to match the requirements of the customer. Method MAP_ICN is responsible for adding the ICN into the XML-EDI stream.

NOTE: Adding LOG-POINTs throughout the mapping class is quite useful when it comes to troubleshooting.

The coding of method MAP_ICN is split among the following 2 textareas corresponding to the 2 major functions being executed:

1. Get a new number (fm NUMBER_GET_NEXT) and generate the ICN according to the customer's requirements.

2. Insert the ICN into the XML-EDI stream.

First we get a new number from the number range followed by a MODULO calculation (depending on the size of the number range object -> here: 6-digits). Then we use this number to generate the ICN.

The ICN may be identical to the NR number. However, some customers demand mnemonics for both supplier and customer as prefix. And others may have even more complicated "formulas" to generate the ICN.

NOTE: In case of TRADACOMS messages we would map the File Generation Number (FLGN) into the XML-EDI stream.

As you can see from the data elements (D_0020) we are mapping the ICN into an EDIFACT/EANCOM message. Instance attribute ME->MO_DOCUMENT (IF_IXML_DOCUMENT) is our handle to the XML-EDI stream. This instance attribute was created within method IF_MAPPING~EXECUTE.

Using method GET_ELEMENTS_BY_TAG_NAME (of IF_IXML_DOCUMENT) we specifically fetch the D_0020 data elements in the UNB and UNZ segment and overwrite their values with the generated ICN.

The ICN has now become an integral part of the XI message.

METHOD MAP_ICN.  " 2nd part * define local data   DATA: lo_node      TYPE REF TO if_ixml_node,         ld_name      TYPE string,         ld_value     TYPE string,         ld_rc        TYPE i,         ld_error_code TYPE mpg_errcode,         ld_msg        TYPE string.  " bapi_msg.    DATA: ld_tag_name   TYPE string.   DATA: incode TYPE REF TO if_ixml_node_collection. ...    DO 2 TIMES.     CASE syst-index.       WHEN '1'. ld_tag_name = mc_d_0020.       WHEN '2'. ld_tag_name = mc_d_0020_2.       WHEN OTHERS.     ENDCASE.      CLEAR: incode,            lo_node.     incode  = me->mo_document->get_elements_by_tag_name( ld_tag_name ).     lo_node = incode->get_item( index = 0 ).      CALL METHOD lo_node->set_value       EXPORTING         value = ld_value       RECEIVING         rval  = ld_rc.     IF ( ld_rc NE 0 ).       CONCATENATE 'Error [' ld_tag_name                   ']: Method SET_VALUE (IF_IXML_NODE)'                   INTO ld_msg.       CONDENSE ld_msg.        me->mif_trace->trace2( message = ld_msg ).       RAISE EXCEPTION TYPE cx_mapping_fault         EXPORTING *          textid = *          previous =           error_code = ld_error_code           error_text = ld_msg.     ENDIF.   ENDDO.   * define local data   DATA: ls_record       TYPE mpp_dynamic.    CLEAR: ls_record.   ls_record-namespace = mc_dynamic_namespace.   ls_record-name      = mc_icn.   ls_record-value     = ld_value.    mif_dynamic->add_record( ls_record ).  ENDMETHOD.

And by What SAP may have forgotten to integrate a little bit the ICN (and the XI-GUID) can be displayed within SAP R/3.

Summary

In this blog I wanted to demonstrate you how you can utilize SAP standard number ranges on SAP-PI in combination with ABAP class mapping in order to sequentially number your outbound EDI messages.

However, even more important I wanted to show you the simplicity and elegance of ABAP class mapping on SAP-PI which will be lost on a Java-only stack.

Visualizing Any Kind of XML Data Using Class CL_XML_DOCUMENT

Uwe Schieferstein — Sun, 17 Oct 2010 10:18:16 GMT

Introduction

When dealing with the manipulation of XML data (e.g. XSLT transformation, ABAP class mapping) we often face the problem to visualize the changed XML data in an easy way. As a consequence we usually need more iterations to adjust our program logic in order to get the required results.

Another challenge is when we receive XML data as xstring input. If errors occur how can we exclude (or confirm) that the XML was erroneous? Example: The input of the eBPP Customer component are base64-encoded DocumentSets. During the processing of these records XML INVOIC-IDocs are generated.

Finally, another trigger to write this blog was a comment to Michal Krawczyk's blog (The specified item was not found. requesting for a better output of the XML data.

Further Readings:

Upload XML file to internal table

Class CL_XML_DOCUMENT - The jack-of-all-trades

The following piece of coding shows that as soon as you have created an instance of CL_XML_DOCUMENT you are just 2 simple steps away from displaying XML data received as xstring:

(1) Parse the XML Stream (XString) to DOM

(2) Display document

The XML document is displayed in a HTML viewer. In order to search through the XML simply use CTRL+F.

Irrespective of whether the XML input is provided as file, internal itab, string, or xstring class CL_XML_DOCUMENT provides the appropriate methods for loading (file) or parsing the XML input (not shown; see Appendix: report ZUS_SDN_XML_DISPLAY).

Use Cases for XML Visualization

Currently I have 2 Use Cases in which I apply the versatility of class CL_XML_DOCUMENT:

(1) All ABAP class mapping on SAP-PI have a static TEST method in which I can display the XML before and after the mapping.

(2) eBPP Customer (Troubleshooting): As soon as I execute processing of DocumentSets in Debugging mode I can display the intermediate XML-IDocs in the HTML viewer for visual inspection.

Summary

Whenever you need to quickly visualize XML data take advantage of the versatile methods of class CL_XML_DOCUMENT.

Appendix

Coding of sample report ZUS_SDN_XML_DISPLAY.

*&---------------------------------------------------------------------**& Report  ZUS_SDN_XML_DISPLAY*&*&---------------------------------------------------------------------**& Report to display any kind of XML data (File, itab, string, xstring)*&*&---------------------------------------------------------------------*REPORT  zus_sdn_xml_display.DATA: gd_stream         TYPE string,      gd_xstream        TYPE xstring,      gt_xml_data       TYPE tttext255. " line type = TEXT255PARAMETERS:  p_file     TYPE localfile   DEFAULT 'C:     empEDI_xxx_ORDERS.xml'.START-OF-SELECTION.* (1) Import XML file and display  PERFORM import_from_file                       USING p_file                    CHANGING gd_stream.* (2) Display XML string  PERFORM import_from_string                       USING gd_stream                    CHANGING gd_xstream.* (3) Display XML xstring  PERFORM import_from_xstring                       USING gd_xstream                    CHANGING gt_xml_data.* (4) Display from XML itab  PERFORM import_from_itab USING gt_xml_data.END-OF-SELECTION.*&---------------------------------------------------------------------**&      Form  IMPORT_FROM_FILE*&---------------------------------------------------------------------**       text*----------------------------------------------------------------------**  -->  p1        text*  <--  p2        text*----------------------------------------------------------------------*FORM import_from_file                  USING ud_file     TYPE localfile               CHANGING cd_stream   TYPE string.* define local data  DATA: ld_filename       type localfile,        lo_xml_doc        TYPE REF TO cl_xml_document,        ld_rc             TYPE i.  MESSAGE i208(00) WITH '(1) Import from XML File'.  CLEAR: cd_stream.* Create instance  CREATE OBJECT lo_xml_doc.* (1) Import from file and display  CALL METHOD lo_xml_doc->import_from_file    EXPORTING      filename = ud_file    RECEIVING      retcode  = ld_rc.  lo_xml_doc->display( ).* Export XML to file  ld_filename = ud_file.  replace '.' with '_out.' into ld_filename.  ld_rc = lo_xml_doc->export_to_file( filename = ld_filename ).* Export XML string as output  CALL METHOD lo_xml_doc->render_2_string*    EXPORTING*      pretty_print = 'X'    IMPORTING      retcode      = ld_rc      stream       = cd_stream*      size         =      .ENDFORM.                    " IMPORT_FROM_FILE*&---------------------------------------------------------------------**&      Form  IMPORT_FROM_STRING*&---------------------------------------------------------------------*FORM import_from_string                    USING ud_stream   TYPE string                 CHANGING cd_xstream  TYPE xstring.* define local data  DATA: lo_xml_doc        TYPE REF TO cl_xml_document,        ld_rc             TYPE i.  MESSAGE i208(00) WITH '(2) Import from XML String'.  CLEAR: cd_xstream.* Create instance  CREATE OBJECT lo_xml_doc.* (1) Import from XML string and display  ld_rc = lo_xml_doc->parse_string( stream = ud_stream ).  lo_xml_doc->display( ).* Export XML string as output  CALL METHOD lo_xml_doc->render_2_xstring*    EXPORTING*      pretty_print = 'X'    IMPORTING      retcode      = ld_rc      stream       = cd_xstream*      size         =      .ENDFORM.                    " IMPORT_FROM_STRING*&---------------------------------------------------------------------**&      Form  IMPORT_FROM_XSTRING*&---------------------------------------------------------------------*FORM import_from_xstring                    USING ud_xstream   TYPE xstring                 CHANGING ct_xml_data  TYPE tttext255.* define local data  DATA: lo_xml_doc        TYPE REF TO cl_xml_document,        ld_rc             TYPE i.  MESSAGE i208(00) WITH '(3) Import from XML xstring'.  REFRESH: ct_xml_data.* Create instance  CREATE OBJECT lo_xml_doc.* (1) Import from XML xstring and display  ld_rc = lo_xml_doc->parse_xstring( stream = ud_xstream ).  lo_xml_doc->display( ).* Export XML string table as output  CALL METHOD lo_xml_doc->render_2_table*    EXPORTING*      pretty_print = 'X'    IMPORTING      retcode      = ld_rc      table        = ct_xml_data*      size         =      .ENDFORM.                    " IMPORT_FROM_XSTRING*&---------------------------------------------------------------------**&      Form  IMPORT_FROM_ITAB*&---------------------------------------------------------------------*FORM import_from_itab  USING ut_xml_data  TYPE tttext255.* define local data  DATA: lo_xml_doc        TYPE REF TO cl_xml_document,        ld_rc             TYPE i.  MESSAGE i208(00) WITH '(4) Import from XML itab'.* Create instance  CREATE OBJECT lo_xml_doc.  ld_rc = lo_xml_doc->parse_table( table = ut_xml_data ).  lo_xml_doc->display( ).ENDFORM.                    " IMPORT_FROM_ITAB

Against All Odds - Programming of Communicating (S)ALV Grid Controls

Uwe Schieferstein — Tue, 12 Oct 2010 12:13:02 GMT

Introduction

Quite often developers struggle with the communication between ALV grid instances. As soon as a record is selected in the "main" ALV list the details for this records should be displayed in the "detail" ALV list (e.g. Customer -> SalesAreas). Whereas the first double-click event works as expected quite frequently the second event fails, e.g. threads:

CALL METHOD ob_grid1->set_table_for_first_display does not change display

Problem with Custom container ->cl_gui_custom_container/cl_gui_alv_grid

Text edioter in Pop up window

Can I use Docking container in Subscreen

In the past I answered such questions several times but even I have problems to recover my own sample reports from SDN. Therefore, I document this solution a last time in this blog and I show that there is almost no difference whether the two communicating (S)ALV grids are displayed on the same screen, on 2 different main screens or even in a popup.

(1) Example: Both ALV Lists Displayed in Same Main Screen

Below you see the (single) main screen showing the ALV list containing customer records.

As soon as the user double-clicks on a record the details (Salesareas of the customer) are displayed in the second ALV list. For displaying the two ALV grids together on the same screen a splitter container is used.

Double-clicking on a different customer row automatically refreshes the the second ALV grid.

(2) Each ALV List Displayed on Different Main Screen (not shown)

In this case each grid instance is displayed using a separate docking container.

(3) Detailed ALV List Displayed on Popup Screen

As soon as the user double-clicks on a record the details (Salesareas of the customer) are displayed in a popup.

Screens - Keep It Simple and Stupid

Provided that the ALV lists are the only elements displayed on the screens we can keep them quite simple: basic flow logic and NO elements (not even a custom control because it is not required)!

NOTE: The sample report ZUS_SDN_TWO_ALV_GRIDS contains 3 screens (0100, 0200, 0205). The flow logic of all 3 (empty) screens is described in the documenation header of the report (see Appendix: report ZUS_SDN_TWO_ALV_GRIDS).

Initialize & Display Controls Before Calling any Screen

Even though virtually all sample reports (BCALV_...) of SAP show the creation and display of controls (container, grid, tree) within the flow logic of the displaying this is not mandatory. On the contrary, I prefer to do the entire control initialization BEFORE calling any screen. Below you see the START-OF-SELECTION section of my sample report. Within routine INIT_CONTROLS all container and grid instances are created. In addition, I even call method SET_TABLE_FOR_FIRST_DISPLAY within this routine.

As next step I link the main ALV list (parent container = GO_DOCKING) to the target screen '0100'. Eventually, the main screen is called.

What is the advantage of this approach? Well, if you want to display the ALV list on another screen of your application then just do it - by calling again the LINK method of the container.

MODULE user_command_0100 INPUT....* User has pushed button "Display Details"    WHEN 'DETAIL'.      PERFORM entry_show_details.*     Display both ALV grids on same main screen      IF ( p_main  = abap_true ).        *     Display details ALV grid on second main screen              ELSEIF ( p_2ndscr = abap_true ).        CALL METHOD go_docking2->link           EXPORTING            repid                       = gd_repid            dynnr                       = '0200'*          container                   =          EXCEPTIONS            cntl_error                  = 1            cntl_system_error           = 2            lifetime_dynpro_dynpro_link = 3            OTHERS                      = 4.        IF sy-subrc <> 0.*       MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*                  WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.        ENDIF.        LEAVE TO SCREEN 200.*     Display details ALV grid within popup      ELSE.        CALL METHOD go_docking2->link           EXPORTING            repid                       = gd_repid            dynnr                       = '0205'*          container                   =          EXCEPTIONS            cntl_error                  = 1            cntl_system_error           = 2            lifetime_dynpro_dynpro_link = 3            OTHERS                      = 4.        IF sy-subrc <> 0.*       MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*                  WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.        ENDIF.        CALL SCREEN '0205' STARTING AT 5 5                           ENDING AT   100 20.      ENDIF.    WHEN OTHERS.  ENDCASE.  CLEAR: gd_okcode.ENDMODULE. " USER_COMMAND_0100 INPUT

Displaying ALV Grid in Main Screen vs. Popup - So What?

The only difference is the dynpro level:

Leave the Event Handler and Trigger PAI

The advantage of this approach is that you always end up with a clearly defined status. After handling the user-command at PAI the flow moves on to PBO at which flushing of the controls occurs by default.

Classic vs. New ALV Object Model - Nothing Special

Regarding the different modes of displaying ALV lists there is no difference whether you are using class CL_GUI_ALV_GRID or CL_SALV_TABLE because the LINK method belongs to the container controls and not to the grid controls (see Appendix: report ZUS_SDN_TWO_SALV_GRIDS).

Summary

Communicating ALV grids is a standard ABAP development task which is not complicated by different modes of displaying the ALV lists.

The approach described here can be adapted for any kind of communicating controls (e.g. tree & grid).

Appendix

(A) Report ZUS_SDN_TWO_ALV_GRIDS

*&---------------------------------------------------------------------**& Report ZUS_SDN_TWO_ALV_GRIDS *&*&---------------------------------------------------------------------**& Documentation: This reports demonstrates how to communicate between*&                2 ALV grids. The first ALV list display customers,*& the second ALV grid display sales areas for a selected customer.*&*& NOTE: This logic works for any number of communicating grid instances,*&       whether they are displayed on the same screen, on 2 separate*& main screen or in a main screen & popup.*&---------------------------------------------------------------------**& Screen '0100' contains no elements.*& ok_code -> assigned to GD_OKCODE*&*& Flow logic:* PROCESS BEFORE OUTPUT.* MODULE STATUS_0100.* PROCESS AFTER INPUT.* MODULE USER_COMMAND_0100.*&*& Screen '0200' contains no elements.*& ok_code -> assigned to GD_OKCODE*&*& Flow logic:*  PROCESS BEFORE OUTPUT.*   MODULE STATUS_0100.***  PROCESS AFTER INPUT.*   MODULE USER_COMMAND_0100.*& Screen '0205' (popup) contains no elements.*& ok_code -> assigned to GD_OKCODE*&*& Flow logic:*  PROCESS BEFORE OUTPUT.*   MODULE STATUS_0205.***  PROCESS AFTER INPUT.*   MODULE USER_COMMAND_0100.*&---------------------------------------------------------------------*REPORT zus_sdn_two_alv_grids.TYPE-POOLS: abap.DATA: gd_okcode       TYPE ui_func,      gd_repid        TYPE syrepid,       go_docking     TYPE REF TO cl_gui_docking_container,       go_docking2    TYPE REF TO cl_gui_docking_container,       go_splitter    TYPE REF TO cl_gui_splitter_container,       go_cell_top    TYPE REF TO cl_gui_container,       go_cell_bottom TYPE REF TO cl_gui_container,       go_grid1       TYPE REF TO cl_gui_alv_grid,       go_grid2       TYPE REF TO cl_gui_alv_grid,*       gs_variant     TYPE disvariant,       gs_layout      TYPE lvc_s_layo.DATA: gs_knb1 TYPE knb1,      gt_knb1 TYPE STANDARD TABLE OF knb1,      gt_knvv TYPE STANDARD TABLE OF knvv.PARAMETERS:  p_main    RADIOBUTTON GROUP radi  DEFAULT 'X',  p_2ndscr  RADIOBUTTON GROUP radi,  p_popup   RADIOBUTTON GROUP radi.*---------------------------------------------------------------------** CLASS lcl_eventhandler DEFINITION*---------------------------------------------------------------------*CLASS lcl_eventhandler DEFINITION.  PUBLIC SECTION.    CLASS-METHODS:      handle_double_click        FOR EVENT double_click OF cl_gui_alv_grid        IMPORTING          e_row          e_column          es_row_no          sender. " grid instance that has triggered the event    CLASS-DATA:      ms_row    TYPE lvc_s_row  READ-ONLY. " stores selected rowENDCLASS. "lcl_eventhandler DEFINITION*---------------------------------------------------------------------**   CLASS lcl_eventhandler IMPLEMENTATION*---------------------------------------------------------------------*CLASS lcl_eventhandler IMPLEMENTATION.  METHOD handle_double_click.* define local data    DATA: ls_knb1 TYPE knb1.    CHECK ( sender = go_grid1 ).    READ TABLE gt_knb1 INTO ls_knb1 INDEX e_row-index.    CHECK ( ls_knb1-kunnr IS NOT INITIAL ).    lcl_eventhandler=>ms_row = e_row. " save selected row for REFRESH* Triggers PAI of the dynpro with the specified ok-code    CALL METHOD cl_gui_cfw=>set_new_ok_code( 'DETAIL' ).  ENDMETHOD. "handle_double_clickENDCLASS.  "lcl_eventhandler IMPLEMENTATIONSTART-OF-SELECTION.* initialization  REFRESH: gt_knb1,           gt_knvv.  SELECT * FROM knb1 INTO TABLE gt_knb1    WHERE bukrs = '0104'.* Create the control and grid instances in advance* before displaying them on any screen  PERFORM init_controls.* Link the docking container to the target dynpro* NOTE: Now we decide where to display the ALV list  gd_repid  = syst-repid.  CALL METHOD go_docking->link  EXPORTING repid = gd_repid    dynnr = '0100'* CONTAINER =EXCEPTIONS OTHERS = 4.* NOTE: dynpro does not contain any elements  CALL SCREEN '0100'.* Flow logic of dynpro (does not contain any dynpro elements):END-OF-SELECTION.*&---------------------------------------------------------------------**& Module STATUS_0100 OUTPUT*&---------------------------------------------------------------------** text*----------------------------------------------------------------------*MODULE status_0100 OUTPUT.  SET PF-STATUS 'STATUS_0100'. " contains push button "DETAIL"* SET TITLEBAR 'xxx'.ENDMODULE. " STATUS_0100 OUTPUT*&---------------------------------------------------------------------**&      Module  STATUS_0205  OUTPUT*&---------------------------------------------------------------------**       text*----------------------------------------------------------------------*MODULE status_0205 OUTPUT.  SET PF-STATUS '0205_POPUP'.*  SET TITLEBAR 'xxx'.ENDMODULE.                 " STATUS_0205  OUTPUT*&---------------------------------------------------------------------**& Module USER_COMMAND_0100 INPUT*&---------------------------------------------------------------------** text*----------------------------------------------------------------------*MODULE user_command_0100 INPUT.  TRANSLATE gd_okcode TO UPPER CASE.  CASE gd_okcode.    WHEN 'BACK' OR         'END'  OR         'CANC'.      CASE syst-dynnr.        WHEN '0100'.          SET SCREEN 0. LEAVE SCREEN.        WHEN '0200'.          SET SCREEN 100. LEAVE SCREEN.      ENDCASE.*   Leave popup screen    WHEN 'ENTER'  OR         'CANCEL'.      SET SCREEN 0. LEAVE SCREEN.* User has pushed button "Display Details"    WHEN 'DETAIL'.      PERFORM entry_show_details.      IF ( p_main  = abap_true ).      ELSEIF ( p_2ndscr = abap_true ).        CALL METHOD go_docking2->link           EXPORTING            repid                       = gd_repid            dynnr                       = '0200'*          container                   =          EXCEPTIONS            cntl_error                  = 1            cntl_system_error           = 2            lifetime_dynpro_dynpro_link = 3            OTHERS                      = 4.        IF sy-subrc <> 0.*       MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*                  WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.        ENDIF.        LEAVE TO SCREEN 200.      ELSE.        CALL METHOD go_docking2->link           EXPORTING            repid                       = gd_repid            dynnr                       = '0205'*          container                   =          EXCEPTIONS            cntl_error                  = 1            cntl_system_error           = 2            lifetime_dynpro_dynpro_link = 3            OTHERS                      = 4.        IF sy-subrc <> 0.*       MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*                  WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.        ENDIF.        CALL SCREEN '0205' STARTING AT 5 5                           ENDING AT   100 20.      ENDIF.    WHEN OTHERS.  ENDCASE.  CLEAR: gd_okcode.ENDMODULE. " USER_COMMAND_0100 INPUT*&---------------------------------------------------------------------**& Form ENTRY_SHOW_DETAILS*&---------------------------------------------------------------------** text*----------------------------------------------------------------------** --> p1 text* <-- p2 text*----------------------------------------------------------------------*FORM entry_show_details .* define local data  DATA: ld_row TYPE i,        ls_knb1 TYPE knb1,        ls_stable TYPE lvc_s_stbl.  REFRESH: gt_knvv.  READ TABLE gt_knb1 INTO ls_knb1 INDEX lcl_eventhandler=>ms_row-index.  CHECK ( syst-subrc = 0 ).  SELECT * FROM knvv INTO TABLE gt_knvv    WHERE kunnr = ls_knb1-kunnr.* Refresh display of detail ALV list (reuired)  ls_stable-row = abap_true.  ls_stable-col = abap_true.  CALL METHOD go_grid2->refresh_table_display    EXPORTING      is_stable = ls_stable    EXCEPTIONS      OTHERS    = 2.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.ENDFORM. " ENTRY_SHOW_DETAILS*&---------------------------------------------------------------------**&      Form  INIT_CONTROLS*&---------------------------------------------------------------------**       text*----------------------------------------------------------------------**  -->  p1        text*  <--  p2        text*----------------------------------------------------------------------*FORM init_controls .* Display both ALV grids on same main screen (splitter)  IF ( p_main = abap_true ).    PERFORM init_controls_main.* Display detailed ALV list on second main screen  ELSEIF ( p_2ndscr = abap_true ).    PERFORM init_controls_2ndscr.* Display detailed ALV list within popup  ELSE.    PERFORM init_controls_popup.  ENDIF.* Display data (before any screen is called !!!)  gs_layout-grid_title = 'Customers'.  CALL METHOD go_grid1->set_table_for_first_display    EXPORTING      i_structure_name = 'KNB1'      is_layout        = gs_layout    CHANGING      it_outtab        = gt_knb1    EXCEPTIONS      OTHERS           = 4.  IF sy-subrc NE 0.* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.  gs_layout-grid_title = 'Customers Details (Sales Areas)'.  CALL METHOD go_grid2->set_table_for_first_display    EXPORTING      i_structure_name = 'KNVV'      is_layout        = gs_layout    CHANGING      it_outtab        = gt_knvv " empty !!!    EXCEPTIONS      OTHERS           = 4.  IF sy-subrc NE 0.* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.* Set event handler  SET HANDLER: lcl_eventhandler=>handle_double_click FOR go_grid1.ENDFORM.                    " INIT_CONTROLS*&---------------------------------------------------------------------**&      Form  INIT_CONTROLS_MAIN*&---------------------------------------------------------------------**       text*----------------------------------------------------------------------**  -->  p1        text*  <--  p2        text*----------------------------------------------------------------------*FORM init_controls_main .* Create docking container  CREATE OBJECT go_docking    EXPORTING      parent = cl_gui_container=>screen0      ratio  = 90    EXCEPTIONS      OTHERS = 6.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.* Fill entire screen  go_docking->set_extension( 99999 ).* Create splitter container  CREATE OBJECT go_splitter    EXPORTING      parent            = go_docking      rows              = 2      columns           = 1    EXCEPTIONS      cntl_error        = 1      cntl_system_error = 2      OTHERS            = 3.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.* Get cell container  CALL METHOD go_splitter->get_container    EXPORTING      row       = 1      column    = 1    RECEIVING      container = go_cell_top.  CALL METHOD go_splitter->get_container    EXPORTING      row       = 2      column    = 1    RECEIVING      container = go_cell_bottom.* Create ALV grids  CREATE OBJECT go_grid1    EXPORTING      i_parent = go_cell_top    EXCEPTIONS      OTHERS   = 5.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.* Create 2nd grid instance for details of double-clicked* entry in first ALV grid  CREATE OBJECT go_grid2    EXPORTING      i_parent = go_cell_bottom    EXCEPTIONS      OTHERS   = 5.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.ENDFORM.                    " INIT_CONTROLS_MAIN*&---------------------------------------------------------------------**&      Form  INIT_CONTROLS_2NDSCR*&---------------------------------------------------------------------**       text*----------------------------------------------------------------------**  -->  p1        text*  <--  p2        text*----------------------------------------------------------------------*FORM init_controls_2ndscr .* Create docking container  CREATE OBJECT go_docking    EXPORTING      parent = cl_gui_container=>screen0      ratio  = 90    EXCEPTIONS      OTHERS = 6.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.  CREATE OBJECT go_docking2    EXPORTING      parent = cl_gui_container=>screen0      ratio  = 90    EXCEPTIONS      OTHERS = 6.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.* Fill entire screen  go_docking->set_extension( 99999 ).  go_docking2->set_extension( 99999 ).* Create ALV grids  CREATE OBJECT go_grid1    EXPORTING      i_parent = go_docking    EXCEPTIONS      OTHERS   = 5.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.  CREATE OBJECT go_grid2    EXPORTING      i_parent = go_docking2    EXCEPTIONS      OTHERS   = 5.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.ENDFORM.                    " INIT_CONTROLS_2NDSCR*&---------------------------------------------------------------------**&      Form  INIT_CONTROLS_POPUP*&---------------------------------------------------------------------**       text*----------------------------------------------------------------------**  -->  p1        text*  <--  p2        text*----------------------------------------------------------------------*FORM init_controls_popup .* Create docking container  CREATE OBJECT go_docking    EXPORTING      parent = cl_gui_container=>screen0      ratio  = 90    EXCEPTIONS      OTHERS = 6.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.  CREATE OBJECT go_docking2    EXPORTING      parent = cl_gui_container=>screen1  " Popup !!!      ratio  = 90    EXCEPTIONS      OTHERS = 6.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.* Fill entire screen  go_docking->set_extension( 99999 ).  go_docking2->set_extension( 99999 ).* Create ALV grids  CREATE OBJECT go_grid1    EXPORTING      i_parent = go_docking    EXCEPTIONS      OTHERS   = 5.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.  CREATE OBJECT go_grid2    EXPORTING      i_parent = go_docking2    EXCEPTIONS      OTHERS   = 5.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.ENDFORM.                    " INIT_CONTROLS_POPUP

(B) Report ZUS_SDN_TWO_SALV_GRIDS

*&---------------------------------------------------------------------**& Report ZUS_SDN_TWO_SALV_GRIDS *&*&---------------------------------------------------------------------**& Documentation: This reports demonstrates how to communicate between*&                2 ALV grids. The first ALV list display customers,*& the second ALV grid display sales areas for a selected customer.*&*& NOTE: This logic works for any number of communicating grid instances,*&       whether they are displayed on the same screen, on 2 separate*& main screen or in a main screen & popup.*&---------------------------------------------------------------------**& Screen '0100' contains no elements.*& ok_code -> assigned to GD_OKCODE*&*& Flow logic:* PROCESS BEFORE OUTPUT.* MODULE STATUS_0100.* PROCESS AFTER INPUT.* MODULE USER_COMMAND_0100.*&*& Screen '0200' contains no elements.*& ok_code -> assigned to GD_OKCODE*&*& Flow logic:*  PROCESS BEFORE OUTPUT.*   MODULE STATUS_0100.***  PROCESS AFTER INPUT.*   MODULE USER_COMMAND_0100.*& Screen '0205' (popup) contains no elements.*& ok_code -> assigned to GD_OKCODE*&*& Flow logic:*  PROCESS BEFORE OUTPUT.*   MODULE STATUS_0205.***  PROCESS AFTER INPUT.*   MODULE USER_COMMAND_0100.*&---------------------------------------------------------------------*REPORT zus_sdn_two_salv_grids.TYPE-POOLS: abap.*... §5 Definition is laterclass lcl_handle_events definition deferred.DATA: gd_okcode       TYPE ui_func,      gd_repid        TYPE syrepid,       go_docking     TYPE REF TO cl_gui_docking_container,       go_docking2    TYPE REF TO cl_gui_docking_container,       go_splitter    TYPE REF TO cl_gui_splitter_container,       go_cell_top    TYPE REF TO cl_gui_container,       go_cell_bottom TYPE REF TO cl_gui_container,*       go_table1       TYPE REF TO cl_salv_table,       go_table2       TYPE REF TO cl_salv_table,*       gs_variant     TYPE disvariant,       gs_layout      TYPE lvc_s_layo.DATA: gs_knb1 TYPE knb1,      gt_knb1 TYPE STANDARD TABLE OF knb1,      gt_knvv TYPE STANDARD TABLE OF knvv.PARAMETERS:  p_main    RADIOBUTTON GROUP radi  DEFAULT 'X',  p_2ndscr  RADIOBUTTON GROUP radi,  p_popup   RADIOBUTTON GROUP radi.*... §5 object for handling the events of cl_salv_tabledata: go_events type ref to lcl_handle_events.*---------------------------------------------------------------------**       CLASS lcl_handle_events DEFINITION** NOTE: Copied from SALV_DEMO_TABLE_EVENTS*---------------------------------------------------------------------** §5.1 define a local class for handling events of cl_salv_table*---------------------------------------------------------------------*class lcl_handle_events definition.  public section.    data:      md_row      type i  read-only.    methods:      on_user_command for event added_function of cl_salv_events        importing e_salv_function,      on_before_salv_function for event before_salv_function of cl_salv_events        importing e_salv_function,      on_after_salv_function for event after_salv_function of cl_salv_events        importing e_salv_function,      on_double_click for event double_click of cl_salv_events_table        importing row column                  sender,      on_link_click for event link_click of cl_salv_events_table        importing row column.endclass.                    "lcl_handle_events DEFINITION*---------------------------------------------------------------------**       CLASS lcl_handle_events IMPLEMENTATION*---------------------------------------------------------------------** §5.2 implement the events for handling the events of cl_salv_table*---------------------------------------------------------------------*class lcl_handle_events implementation.  method on_user_command.**    perform show_function_info using e_salv_function text-i08.  endmethod.                    "on_user_command  method on_before_salv_function.**    perform show_function_info using e_salv_function text-i09.  endmethod.                    "on_before_salv_function  method on_after_salv_function.**    perform show_function_info using e_salv_function text-i10.  endmethod.                    "on_after_salv_function  method on_double_click.**    CHECK ( sender = go_table1 ).    me->md_row = row. " save selected row for REFRESH* Triggers PAI of the dynpro with the specified ok-code    CALL METHOD cl_gui_cfw=>set_new_ok_code( 'DETAIL' ).  endmethod.                    "on_double_click  method on_link_click.**    perform show_cell_info using row column text-i06.  endmethod.                    "on_single_clickendclass.                    "lcl_handle_events IMPLEMENTATIONSTART-OF-SELECTION.* initialization  REFRESH: gt_knb1,           gt_knvv.  gd_repid = syst-repid.  SELECT * FROM knb1 INTO TABLE gt_knb1    WHERE bukrs = '0104'.* Create the control and grid instances in advance* before displaying them on any screen  PERFORM init_controls.* Link the docking container to the target dynpro* NOTE: Now we decide where to display the ALV list  gd_repid  = syst-repid.  CALL METHOD go_docking->link  EXPORTING repid = gd_repid    dynnr = '0100'* CONTAINER =EXCEPTIONS OTHERS = 4.* NOTE: dynpro does not contain any elements  CALL SCREEN '0100'.* Flow logic of dynpro (does not contain any dynpro elements):END-OF-SELECTION.*&---------------------------------------------------------------------**& Module STATUS_0100 OUTPUT*&---------------------------------------------------------------------** text*----------------------------------------------------------------------*MODULE status_0100 OUTPUT.  SET PF-STATUS 'STATUS_0100'. " contains push button "DETAIL"* SET TITLEBAR 'xxx'.ENDMODULE. " STATUS_0100 OUTPUT*&---------------------------------------------------------------------**&      Module  STATUS_0205  OUTPUT*&---------------------------------------------------------------------**       text*----------------------------------------------------------------------*MODULE status_0205 OUTPUT.  SET PF-STATUS '0205_POPUP'.*  SET TITLEBAR 'xxx'.ENDMODULE.                 " STATUS_0205  OUTPUT*&---------------------------------------------------------------------**& Module USER_COMMAND_0100 INPUT*&---------------------------------------------------------------------** text*----------------------------------------------------------------------*MODULE user_command_0100 INPUT.  TRANSLATE gd_okcode TO UPPER CASE.  CASE gd_okcode.    WHEN 'BACK' OR         'END'  OR         'CANC'.      CASE syst-dynnr.        WHEN '0100'.          SET SCREEN 0. LEAVE SCREEN.        WHEN '0200'.          SET SCREEN 100. LEAVE SCREEN.      ENDCASE.*   Leave popup screen    WHEN 'ENTER'  OR         'CANCEL'.      SET SCREEN 0. LEAVE SCREEN.* User has pushed button "Display Details"    WHEN 'DETAIL'.      PERFORM entry_show_details.      IF ( p_main  = abap_true ).      ELSEIF ( p_2ndscr = abap_true ).        CALL METHOD go_docking2->link           EXPORTING            repid                       = gd_repid            dynnr                       = '0200'*          container                   =          EXCEPTIONS            cntl_error                  = 1            cntl_system_error           = 2            lifetime_dynpro_dynpro_link = 3            OTHERS                      = 4.        IF sy-subrc <> 0.*       MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*                  WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.        ENDIF.        LEAVE TO SCREEN 200.      ELSE.        CALL METHOD go_docking2->link           EXPORTING            repid                       = gd_repid            dynnr                       = '0205'*          container                   =          EXCEPTIONS            cntl_error                  = 1            cntl_system_error           = 2            lifetime_dynpro_dynpro_link = 3            OTHERS                      = 4.        IF sy-subrc <> 0.*       MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*                  WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.        ENDIF.        CALL SCREEN '0205' STARTING AT 5 5                           ENDING AT   100 20.      ENDIF.    WHEN OTHERS.  ENDCASE.  CLEAR: gd_okcode.ENDMODULE. " USER_COMMAND_0100 INPUT*&---------------------------------------------------------------------**& Form ENTRY_SHOW_DETAILS*&---------------------------------------------------------------------** text*----------------------------------------------------------------------** --> p1 text* <-- p2 text*----------------------------------------------------------------------*FORM entry_show_details .* define local data  DATA: ld_row TYPE i,        ls_knb1 TYPE knb1,        ls_stable TYPE lvc_s_stbl.  REFRESH: gt_knvv.  READ TABLE gt_knb1 INTO ls_knb1 INDEX go_events->md_row.  CHECK ( syst-subrc = 0 ).  SELECT * FROM knvv INTO TABLE gt_knvv    WHERE kunnr = ls_knb1-kunnr.* Refresh display of detail ALV list (reuired)  ls_stable-row = abap_true.  ls_stable-col = abap_true.  CALL METHOD go_table2->refresh    EXPORTING      s_stable     = ls_stable.ENDFORM. " ENTRY_SHOW_DETAILS*&---------------------------------------------------------------------**&      Form  INIT_CONTROLS*&---------------------------------------------------------------------**       text*----------------------------------------------------------------------**  -->  p1        text*  <--  p2        text*----------------------------------------------------------------------*FORM init_controls .* Display both ALV grids on same main screen (splitter)  IF ( p_main = abap_true ).    PERFORM init_controls_main.* Display detailed ALV list on second main screen  ELSEIF ( p_2ndscr = abap_true ).    PERFORM init_controls_2ndscr.* Display detailed ALV list within popup  ELSE.    PERFORM init_controls_popup.  ENDIF.*... §3 Functions*... §3.1 activate ALV generic Functions*... §3.2 include own functions by setting own status**  go_table1->set_screen_status(**    pfstatus      =  'SALV_STANDARD'**    report        =  gd_repid**    set_functions = go_table1->c_functions_all ).*... §6 register to the events of cl_salv_table  data: lr_events type ref to cl_salv_events_table.  lr_events = go_table1->get_event( ).  create object go_events.*... §6.1 register to the event USER_COMMAND  set handler go_events->on_user_command for lr_events.*... §6.2 register to the event BEFORE_SALV_FUNCTION  set handler go_events->on_before_salv_function for lr_events.*... §6.3 register to the event AFTER_SALV_FUNCTION  set handler go_events->on_after_salv_function for lr_events.*... §6.4 register to the event DOUBLE_CLICK  set handler go_events->on_double_click for lr_events.*... §6.5 register to the event LINK_CLICK  set handler go_events->on_link_click for lr_events.ENDFORM.                    " INIT_CONTROLS*&---------------------------------------------------------------------**&      Form  INIT_CONTROLS_MAIN*&---------------------------------------------------------------------**       text*----------------------------------------------------------------------**  -->  p1        text*  <--  p2        text*----------------------------------------------------------------------*FORM init_controls_main .* Create docking container  CREATE OBJECT go_docking    EXPORTING      parent = cl_gui_container=>screen0      ratio  = 90    EXCEPTIONS      OTHERS = 6.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.* Fill entire screen  go_docking->set_extension( 99999 ).* Create splitter container  CREATE OBJECT go_splitter    EXPORTING      parent            = go_docking      rows              = 2      columns           = 1    EXCEPTIONS      cntl_error        = 1      cntl_system_error = 2      OTHERS            = 3.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.* Get cell container  CALL METHOD go_splitter->get_container    EXPORTING      row       = 1      column    = 1    RECEIVING      container = go_cell_top.  CALL METHOD go_splitter->get_container    EXPORTING      row       = 2      column    = 1    RECEIVING      container = go_cell_bottom.* Create ALV grids  TRY.      CALL METHOD cl_salv_table=>factory        EXPORTING          r_container  = go_cell_top        IMPORTING          r_salv_table = go_table1        CHANGING          t_table      = gt_knb1.      go_table1->display( ).    CATCH cx_salv_msg .  ENDTRY.  TRY.      CALL METHOD cl_salv_table=>factory        EXPORTING          r_container  = go_cell_bottom        IMPORTING          r_salv_table = go_table2        CHANGING          t_table      = gt_knvv.      go_table2->display( ).    CATCH cx_salv_msg .  ENDTRY.ENDFORM.                    " INIT_CONTROLS_MAIN*&---------------------------------------------------------------------**&      Form  INIT_CONTROLS_2NDSCR*&---------------------------------------------------------------------**       text*----------------------------------------------------------------------**  -->  p1        text*  <--  p2        text*----------------------------------------------------------------------*FORM init_controls_2ndscr .* Create docking container  CREATE OBJECT go_docking    EXPORTING      parent = cl_gui_container=>screen0      ratio  = 90    EXCEPTIONS      OTHERS = 6.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.  CREATE OBJECT go_docking2    EXPORTING      parent = cl_gui_container=>screen0      ratio  = 90    EXCEPTIONS      OTHERS = 6.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.* Fill entire screen  go_docking->set_extension( 99999 ).  go_docking2->set_extension( 99999 ).* Create ALV grids  TRY.      CALL METHOD cl_salv_table=>factory        EXPORTING          r_container  = go_docking        IMPORTING          r_salv_table = go_table1        CHANGING          t_table      = gt_knb1.      go_table1->display( ).    CATCH cx_salv_msg .  ENDTRY.  TRY.      CALL METHOD cl_salv_table=>factory        EXPORTING          r_container  = go_docking2        IMPORTING          r_salv_table = go_table2        CHANGING          t_table      = gt_knvv.      go_table2->display( ).    CATCH cx_salv_msg .  ENDTRY.ENDFORM.                    " INIT_CONTROLS_2NDSCR*&---------------------------------------------------------------------**&      Form  INIT_CONTROLS_POPUP*&---------------------------------------------------------------------**       text*----------------------------------------------------------------------**  -->  p1        text*  <--  p2        text*----------------------------------------------------------------------*FORM init_controls_popup .* Create docking container  CREATE OBJECT go_docking    EXPORTING      parent = cl_gui_container=>screen0      ratio  = 90    EXCEPTIONS      OTHERS = 6.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.  CREATE OBJECT go_docking2    EXPORTING      parent = cl_gui_container=>screen1  " Popup !!!      ratio  = 90    EXCEPTIONS      OTHERS = 6.  IF sy-subrc NE 0.*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO*   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.  ENDIF.* Fill entire screen  go_docking->set_extension( 99999 ).  go_docking2->set_extension( 99999 ).* Create ALV grids  TRY.      CALL METHOD cl_salv_table=>factory        EXPORTING          r_container  = go_docking        IMPORTING          r_salv_table = go_table1        CHANGING          t_table      = gt_knb1.      go_table1->display( ).    CATCH cx_salv_msg .  ENDTRY.  TRY.      CALL METHOD cl_salv_table=>factory        EXPORTING          r_container  = go_docking2        IMPORTING          r_salv_table = go_table2        CHANGING          t_table      = gt_knvv.      go_table2->display( ).    CATCH cx_salv_msg .  ENDTRY.ENDFORM.                    " INIT_CONTROLS_POPUP

What SAP may have forgotten to integrate

Uwe Schieferstein — Wed, 23 Sep 2009 10:53:08 GMT

*Introduction*

One major implicit agreement in the EDI business is that +"No News is Good News."+. A customer ordering via EDI assumes that its purchase orders will be fulfilled completely as long as the customer is not informed otherwise by the supplier. A supplier assumes that its EDI invoices have been accepted and will be paid unless they are rejected by the customer. Given the fact that we do not use a full-blown EDI Adapter like Seeburger at Lindt (CH) but just an "Add-On" (for more details contact http://www.resource.ch (http://www.resource.ch) about their *rEDI Adapter*) which does the conversion XML to Flat and vice versa we do not (yet) have and End-to-End Monitoring of our EDI processes. How do we cope with this situation in case of EDI incidents? *The Challenge* If EDI invoices are rejected by the customer we are informed by their EDI support team. Many customers tells us not only that a transmission failed but also which invoice (i.e. the invoice no.) was affected. However, some customer just let us know that +"Transmission (LNDSMUMU004392) failed"+ (see below). The cryptic number LNDSMUMU004392 is the +sequential +*transmission number* (or ICN = *interchange control number*) as defined in the customer's EDIFACT EDI guidelines (LNDS = Supplier prefix; MUMU = Customer prefix; 004392 = sequential number). In case of TRADACOMS messages (UK-specific standard) the FIL segment is used for the numbering (field FLGN = File Generation Number). The EDI error described in the e-mail is that we sent a wrong invoicee party (NAD+IV) due to a wrong assignment of partner roles in the customer master data. Now how do we find out the affected invoice by just knowing its transmission number, sent date and value? Using standard means (e.g. *WE02*) may become tedious if many invoices were sent to this customer at the same day (which actually is the case for this particular customer). Another option would be to check table *VBRK *for the specific net value. Or searching through the XML messages on SAP-XI (*SXMB_MONI*) in the possible period of time. However, none of these ways is really efficient and all of them are too time-consuming. And what about multiple incidents happen within a short period of time?

*eXtended IDoc Monitoring at Lindt* As an answer to tackle this acute support problem I developed an "eXtended IDoc Monitor" for Lindt UK (our EDI "pacemaker" among the Lindt group). The three main features of this extended monitor are: 1. Display the *business object* (e.g. invoice, delivery, etc.) on the IDoc list 2. Display the SAP-XI message ID (*GUID*) on the IDoc list 3. Display the *ICN *(or transmission number) of outbound IDocs on the IDoc list

In the standard IDoc monitor (WE02) you need 3-4 mouse-clicks in order to navigate from the IDoc on the list to the business document. Since the link between IDoc and business document can be retrieved by +standard +means I just removed this unnecessary navigation and brought the business document to the surface (i.e. on the IDoc list).

On SAP-XI we can see the link between IDocs and XI-message ID (*GUID*) using transaction *IDX5*. Provided a suitable RFC connection is available we can jump from SAP-XI into the business system and display the IDoc. Thus, we have again +standard+ means to retrieve this link (IDoc - GUID). | | In summary: All I have done is *to grab the Lego bricks that SAP has built already and merged what obviously belongs together.* The result is shown below: As soon as the selection is started the message displayed in the status bar shows the additional selection of business object data. The business document related columns are coloured in dark green. As soon as we restrict the Idoc list to a particular message type (e.g. *INVOIC*) additional data specific for this business document type can be displayed (e.g. net value and payer in case of invoices). By simply sorting the IDoc list by column ICN (= Interchange Control number) we have found out that the rejected transmission LNDSMUMU004392 belonged to invoice 90081069. By right-clicking on the affected IDoc we can quickly call the appropriate function (e.g. "Maintain Store (code) mapping") in order to solve this incident. Needless to say that a double-click on either the business document number or the GUID forwards the user to the corresponding display +business transaction+ (e.g VF03 for invoices) or the list "XML Messages in Adapter (IDX5) on SAP-XI, respectively. *Business Activity Monitoring* You may have noticed that the selection-screen of the eXtended IDoc Monitor (ZWE02) has an additional tabstrip *"Bus.Object"* as compared to the standard.Wouldn't it be nice to follow the business activities of a document based on the sent and received IDocs? The selection for a specific outbound delivery gives the following result: * The warehouse sent the picking confirmation (WHSCON) back. * The inbound WHSCON triggererd an outbound SHPORD as ASN (= Advance Shipping Notice) to the customer (by means of a VOFM condition). * Finally the warehouse sent a proof of delivery (STPPOD) which allows billing of the delivery. Or in other words: We can see the all business activities of the outbound delivery in the eXtended IDoc Monitoring.

Nomen est Omen - ABAP Naming Conventions

Uwe Schieferstein — Sun, 30 Aug 2009 22:33:06 GMT

Introduction

My comment about the importance of ABAP naming conventions to Thorsten Franz' blog Great Programmers will their Code to the new Guy triggered an interesting discussion about naming conventions for ABAP. The opinions range from "...is important" to "...We do not advise you on naming conventions, do whatever you want".

The latter statement sounds like a capitulation. This resignation might be due to the following questions:

Are there useful naming conventions for ABAP? Apparently not even SAP has them.
Do naming conventions really improve ABAP coding and how?
How can we check the compliance of ABAP program objects with the naming conventions?

ABAP Naming Conventions: "Yes, we exist"
I started my SAP career more than 10 years ago at Cirrus Consulting. The very first thing I got there was a comprehensive documentation about ABAP naming and programming conventions which they had created for one of their biggest customers. And at the Zürcher Kantonalbank they had such a document, too.

Admittedly there were deviations from these conventions in particular because many external developers worked at these customers and the Code Inspector (SCI) was not yet available at that time. Nevertheless these conventions facilitated the readability of the coding and the handing over (for maintenance) to other developers. And if you look carefully around you will realize that even SAP (or at least a subset of its developers) uses naming conventions.

Now let us imagine a "...do whatever you want" customer where a developer creates a report (containing a constant for the speed of light) which in the subsequent years has been maintained by three other developers. Three of them use their own naming conventions and the forth one uses none at all so we may end up with the following representations of a single constant:

GC_LIGHTSPEED or LC_LIGHTSPEED
CO_LIGHTSPEED
C_LIGHTSPEED

The forth developer may replace all previous representations with his own SPEED_OF_LIGHT without any prefix because everybody "knows" that this is a (pyhsical) constant. This medley of naming conventions will definitely confuse every developer. And this is just a simple example considered with the mixing up the naming of global and local variables.

In the following section I will present my own naming conventions which are a "best-of-breed" blend of SAP naming conventions and those of my previous employers.

Call a Spade a Spade

Naming conventions must be concise, short and distinct. Any ambiguity is a burden for maintenance in the future. Using three categories of criteria it is possible to unambigously name virtually all variables and most signature parameters:

Visibility: Global / Local / Class Context
Type: Field / Structure / Table Type / Reference / Constants
Structural Context: FORM routines / Function Modules / Methods

There are two general naming conventions:

Variables and Class Attributes: <Visibility>_<Type>_<Description>
Signature Parameters: <Structural Context>_<Type>_<Description>

Visibility & Type

We have three kinds of visibility: Global, Local and Class Context (which includes Interfaces as well) and seven different types (see below).

Visibility	Prefix	Type	Prefix	Example	Coding
Global	G	Field	D	GD_MATNR	DATA: gd_matnr TYPE matnr.
		Structure	S	GS_KNB1	DATA: gs_knb1 TYPE knb1.
		Table Type	T	GT_VBAK	DATA: gt_vbak TYPE TABLE OF vbak.
		Class Interface	O	GO_GRID GO_MSGLIST	DATA: go_grid TYPE REF TO cl_gui_alv_grid. DATA: go_msglist TYPE REF TO if_reca_message_list.
		Data Object	DO	GDO_DATA	DATA: gdo_data TYPE REF TO data.
		Constant	C	GC_LIGHTSPEED	CONSTANTS: gc_lightspeed TYPE i VALUE '300000'.

Local	L	Field	D	LD_MATNR	DATA: ld_matnr TYPE matnr.
		Structure	S	LS_KNB1	DATA: ls_knb1 TYPE knb1.
		Table Type	T	LT_VBAK	DATA: lt_vbak TYPE TABLE OF vbak.
		Class Interface	O	LO_GRID LO_MSGLIST	DATA: lo_grid TYPE REF TO cl_gui_alv_grid. DATA: lo_msglist TYPE REF TO if_reca_message_list.
		Data Object	DO	LDO_DATA	DATA: ldo_data TYPE REF TO data.
		Constant	C	LC_LIGHTSPEED	CONSTANTS: lc_lightspeed TYPE i VALUE '300000'.

Class Context	M	Field	D	MD_MATNR	DATA: md_matnr TYPE matnr.
		Structure	S	MS_KNB1	DATA: ms_knb1 TYPE knb1.
		Table Type	T	MT_VBAK	DATA: mt_vbak TYPE TABLE OF vbak.
		Class Interface	O	MO_GRID MO_MSGLIST	DATA: mo_grid TYPE REF TO cl_gui_alv_grid. DATA: mo_msglist TYPE REF TO if_reca_message_list.
		Data Object	DO	MDO_DATA	DATA: mdo_data TYPE REF TO data.
		Constant	C	MC_LIGHTSPEED	CONSTANTS: mc_lightspeed TYPE i VALUE '300000'.

The vast majority of variables within program objects are either global or local. And in the future there will be a remarkably shift towards class attributes (ABAP-OO). Thus, assigning a unique prefix to each group makes their visibility unambigous for every developer.

Class attributes (instance and static) are special because they are global within the class/instance whereas they appear local from outside the class/instance. Without referring to a class(name) or instance these attributes are "hidden" (i.e. local).

Question: Does the type prefix offer any benefit?

In ABAP forum posts you may find the following definitions for ALV grid instances:

GRID: global (?), local (?), class context (?); class reference (?)
G_ALV_GRID: global (!?), local (?), class context (?); class reference (!?)
GO_GRID: global class reference OUTSIDE any class context (my naming convention)

Answer: Yes, because we meet the developer's expectation and anticipation.

You may argue: What a big fuss about such a little subtlety. My answer to this is: Every SAP developer who comes across a GO_GRID variable in any of my programs knows in advance(!) the meaning and scope of it.

Structural Context (1): FORM routine Signature

The SAP system does not care about which kind of formal parameters (USING or CHANGING) are used in FORM routine signatures. Both kinds of formal parameters can be changed within the routine and the modified contents transferred back to the calling program. This is ambiguity at its worst.

In order to make the signature of a FORM routine clear as crystal we define every Input = USING parameter and every Output = CHANGING parameter. Within the FORM routine all USING parameters should be regarded as "constants" meaning that they are not changed nor is any change transferred back to the calling program.

Parameter	Prefix	Type	Prefix	Example
USING	U	Field	D	UD_MATNR
		Structure	S	US_KNB1
		Table Type	T	UT_VBAK
		Class Interface	O	UO_GRID UO_MSGLIST
		Data Object	DO	UDO_DATA

CHANGING	C	Field	D	CD_MATNR
		Structure	S	CS_KNB1
		Table Type	T	CT_VBAK
		Class Interface	O	CO_GRID CO_MSGLIST
		Data Object	DO	CDO_DATA

Again, by defining Input = USING (prefix 'U') and Output = CHANGING (prefix 'C') we meet the developer's expectation and alleviate understanding of the FORM routine.

Structural Context (2): Function Module Signature

The same logic applies to function modules parameters. In addition, we can facilitate the understanding of TABLES parameters (Yes, I know they are obsolete yet some still like to use 'em) by the semantics of their Input/Output behaviour:

IT_ITAB = Input only
ET_ITAB = Output only
XT_ITAB = Input & Output

Parameter	Prefix	Type	Prefix	Example
IMPORTING	I	Field	D	ID_MATNR
		Structure	S	IS_KNB1
		Table Type	T	IT_VBAK
		Class Interface	O	IO_GRID IO_MSGLIST
		Data Object	DO	IDO_DATA

EXPORTING	E	Field	D	ED_MATNR
		Structure	S	ES_KNB1
		Table Type	T	ET_VBAK
		Class Interface	O	EO_GRID EO_MSGLIST
		Data Object	DO	EDO_DATA

CHANGING	C	Field	D	CD_MATNR
		Structure	S	CS_KNB1
		Table Type	T	CT_VBAK
		Class Interface	O	CO_GRID CO_MSGLIST
		Data Object	DO	CDO_DATA

TABLES		"Importing"	IT	IT_VBAK
		"Exporting"	ET	ET_VBAK
		"Changing"	XT	XT_VBAK

Of course there is no technical difference whatsoever between "Importing", "Exporting" and "Changing" TABLES parameters. Yet the different naming gives the developer already an idea about the function of this module without looking into the coding. Or in other words: Try to "express" the function of the module already in its signature.

Structural Context (3a): Method Signature

The logic explained above is just applied to method parameters as well and extended to the additional RETURNING parameters of methods.

Parameter	Prefix	Type	Prefix	Example
IMPORTING	I	Field	D	ID_MATNR
		Structure	S	IS_KNB1
		Table Type	T	IT_VBAK
		Class Interface	O	IO_GRID IO_MSGLIST
		Data Object	DO	IDO_DATA

EXPORTING	E	Field	D	ED_MATNR
		Structure	S	ES_KNB1
		Table Type	T	ET_VBAK
		Class Interface	O	EO_GRID EO_MSGLIST
		Data Object	DO	EDO_DATA

CHANGING	C	Field	D	CD_MATNR
		Structure	S	CS_KNB1
		Table Type	T	CT_VBAK
		Class Interface	O	CO_GRID CO_MSGLIST
		Data Object	DO	CDO_DATA

RETURNING	R	Field	D	RD_MATNR
		Structure	S	RS_KNB1
		Table Type	T	RT_VBAK
		Class Interface	O	RO_GRID RO_MSGLIST
		Data Object	DO	RDO_DATA

Structural Context (3b): Static vs. Instance Attributes

Static attributes are special because they exist only once for all instances of this class. Modifying a static attribute within a given instance makes this change visible to all other instances. Both types of attributes have the prefix 'M' (class context) in my naming convention. In order to distinguish between static and instance attributes I apply the following convention:

Instance Attribute: with self-reference me-> (e.g. me->md_key)
Static Attribute: without self-reference (.e.g. ms_row)

You can find an example of this naming convention in the coding of INCLUDE ZRSWBOSDR_C01 in my blog Multi-Purpose ALV Programming.

Another unambigous convention is to drop the self-reference prefix and use the full qualified name for static attributes:

Instance Attribute: md_key (with or with self-reference prefix)
Static Attribute: lcl_eventhandler=>ms_row

Field-Symbols

We can apply the same naming conventions even to field-symbols which makes them much more readable and understandable for every developer. This is particularly important because the contents of field-symbols cannot be analyzed statically but is only determined at runtime.

Visibility	Prefix	Type	Prefix	Example
Global	G	Field	D	<GD_MATNR>
		Structure	S	<GS_KNB1>
		Table Type	T	<GT_VBAK>
		Class Interface	O	<GO_GRID> <GO_MSGLIST>
		Data Object	DO	<GDO_DATA>

Local	L	Field	D	<LD_MATNR>
		Structure	S	<LS_KNB1>
		Table Type	T	<LT_VBAK>
		Class Interface	O	<LO_GRID> <LO_MSGLIST>
		Data Object	DO	<LDO_DATA>

SAP and Lego

Why has Lego become one of the world's most famous toys? Part of the answer can be found here:

"Lego pieces of all varieties are a part of a universal system. \ Despite variation in the design and purpose of individual pieces over \ the years, each remains compatible in some way with existing pieces. \ Lego bricks from 1958 still interlock with those made in 2009, and Lego \ sets for young children are compatible with those made for teenagers.

\ Bricks, beams, axles, mini figures, and all other parts in the Lego \ system are manufactured to an exacting degree of precision. When \ snapped together, pieces must have just the right amount of strength \ and flexibility mixed together to stick together. They must stay \ together until pulled apart. They cannot be too easy to pull apart, or \ the resulting constructions would be unstable; they also cannot be too \ difficult to pull apart, since the disassembly of one creation in order \ to build another is part of the Lego appeal. In order for pieces to \ have just the right "clutch power", Lego elements are manufactured \ within a tolerance of 2 µm."

QUESTION: "Have you ever seen a child which sits in front of a pile of Lego bricks claiming it can't build anything because all bricks have the same size???"

For me SAP is just an incredibly huge pile of Lego bricks (for grown-ups). Consistent naming conventions are an indispensable standard which enables us to manufacture long-lasting developments that are easy to understand and maintain (pull apart and reassemble).

Code Inspector: Check Compliance with your Naming Conventions

The Code Inspector (transaction SCI) provides you with all means to check compliance with your naming conventions. Within the check variant you an explicit check Programming Conventions.

Looking at the check Naming Conventions a popup appears where you can define your conventions for data variables and signatures (FORM routine, function module, classes).

Since I have not yet mentioned macros (DEFINE) yet here is my convention:

MAC_<description>: e.g. mac_suppress_toolbar_btn

Another set of frequently used global variables are (select-)parameters and select-options:

SELECT-OPTIONS:

S_MATNR FOR mara-matnr.

PARAMETERS:

P_MATKL TYPE matkl.

Looking at the check Extended Naming Conventions for Programs you will find my 7 types (Field, Structure, Table Type, Class, Interface, Data Object, Constant) grouped into 5 prefixes:

Elementary Type includes Field and Constant
Object Reference includes Class and Interface

The prefixes shown above are the default values when opening the check with which I do not agree. For example, the prefix "R" indicates a global range according to my conventions:

DATA: rt_matnr TYPE RANGE OF matnr.

Summary

It is possible to define useful naming conventions for ABAP. Naming conventions significantly help in understanding a program and navigating around it. Both the new and the senior guy will benefit in particular when it comes to maintenance because they can focus their analysis on the program logic and not the "logic" of the previous developer.

Conclusions

Naming conventions are not impositions for creative developers but, on the contrary, side rails for long-lasting development.

Addendum

I no longer think it makes sense to explicitly distinguish between classes and interfaces because at the end of the day you always work with an interface implementing class (even if the static type is that of an interface). Therefore, the two separate rows for "Class" and "Interface" have been merged.

Further Readings

Great Programmers will their Code to the New Guy

The Little SE80 of Horrors

Random Ramblings of an obsolete programmer

Distribution of full master data objects from change pointers - Revisited

Uwe Schieferstein — Thu, 06 Aug 2009 21:46:14 GMT

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.

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.

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:                                                          **& The specified item was not found.         **&                                                                     **& 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

Facilitating EDI Mapping by Pre-Transformation of IDocs on SAP-XI

Uwe Schieferstein — Thu, 25 Jun 2009 20:40:53 GMT

*Introduction*

Currently more and more Lindt companies are on their way to integrate more tightly with their customers and suppliers by means of *EDI *(= Electronic Data Interchange).

EDI Ordering is the process where the customer sends its purchase orders e.g. as EDIFACT ORDERS messages. With respect to EDI Ordering we can distinguish between:

*Static *EDI Ordering: the customer does not get any response about the reception of the EDI order but only a functional acknowledgement from the receiving EDI system (in our system landscape we use ODEX Enterprise )

*Dynamic *EDI Ordering: the customer does not only require to receive a *CONTRL *message as immediate response but, in addition, an *ORDRSP* message that must be sent within a defined time frame after having received the ORDERS message.

The *CONTRL *message is an Acknowlegement/Rejection Advice Message:

"Based on the United Nations Electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT) format, CONTRL is a message that syntactically acknowledges or rejects an interchange. Within the interchange it might also be used to notify the trading partners of an acknowledgement or rejection of any of its functional groups or messages. Explanations for the rejection are also clarified and communicated within the message."

The *ORDRSP *message is a Purchase order response message :

"A message from the seller to the buyer, responding to a purchase order message or a purchase order change request message."

Whereas the CONTRL message is still an acknowledgement on the functional (syntactical) level the ORDRSP message is a full-blown +business +response. At the beginning of the stylesheet I defined variables for the Message Function and the Response Type (see Business Rules section above).Summary

Obviously it would have been possible to do the entire XSLT transformation ORDRSP IDoc -> ORDRSP EDIFACT within a single stylesheet. However, splitting the transformation into a pre-processing of the XML-IDoc and a main processing (XML-IDoc -> XML-EDI) clearly reduced the complexity of the stylesheet. In addition, the stylesheets are easier to read and understand which facilitates maintenance in case of new or changed business rules (or modified IDoc contents) in the future.

*Conclusion One of the fundamental principles of Systems Engineering is to split a large project into smaller ones in order to reduce complexity and increase manageability. The same principle can be applied to complex XSLT transformations required for EDI. Further Readings*

For more details about the EDIFACT message types you may refer to:

Syntax and service report message for batch EDI (message type-CONTRL)

[UN/EDIFACT ORDRSP | http://www.unece.org/trade/untdid/d01b/trmd/ordrsp_c.htm]

[Edifactory: ORDRSP | http://www.edifactory.de/msginfo.php?s=D01A&m=ORDRSP]

Dangerous Liaisons in User-Exits - Revisited

Uwe Schieferstein — Mon, 15 Jun 2009 22:31:56 GMT

Introduction

It seems that my first blog about organizing Function Module-Exits (CMOD / SMOD) touched a sore point looking at the lively discussion that followed after its publication. Whereas I suggest to organize the exits in independent function groups others proposed to use BAdI like technologies (e.g. Implementing a BAdI in an enhancement Project (CMOD)). My major objections against this proposal are:

Using interfaces does not really increase transparency in case of the Multiple-Use exits
We should not mix two different kinds of Exit-technologies

The latter point does not imply that we should refrain from using ABAP-OO within Function Module-Exits as you will see below.

Lindt UK: EDI vs. Retail Orders

Customers of Lindt UK sending their purchase orders via EDI are obliged to order our delicious chocolate products in so-called cases (= traded units, e.g. a box of chocolate bars) instead of consumer units (e.g. a single chocolate bar).

Example: 1 Case = 20 Consumer Units, i.e. a box of chocolate bar contains 20 bars.

If nevertheless a customer orders in consumer units the ordered quantity is calculated in cases within a user-exit (using fm MATERIAL_UNIT_CONVERSION).

Recently Lindt UK opened up a couple of LindtShops where the products are sold in consumer units. The shop sales are sent via EDI to the R/3 system where it creates (Retail) sales orders containing the quantities in consumer units. EDI orders and Retail orders can be distinguished based on the order type (AUART).

Below you see the package ZCMOD in the R/3 system of Lindt UK. Already at a glance we see that

a User-Exit has been implemented for SD-EDI
two different requirements have been implemented (EDI vs. Retail)

The implementation of this User-Exit is simple and straightforward:

The Frame User-Exit ZEXIT_SAPLVEDA_011 is called within include ZXVEDU13 (not shown)
If the order type belongs to Retail we call fm ZEXIT_SAPLVEDA_011_RETAIL
ELSE we call fm ZEXIT_SAPLVEDA_011_EDI

A few months after implementing this User-Exit Lindt UK came up with a new Retail order type. A quick look at the TOP-include of the User-Exit function group revealed that I just had to add a single line of coding in order to take this new Retail order type into account.

Lindt Italy (IT): Default vs. EDI Invoices

Lindt IT sends its outbound invoices to two destinations:

3rd party sales system
EDI customers (as EDIFACT messages)

Below you see the package ZCMOD in the R/3 system of Lindt IT. Already at a glance we see that

a User-Exit has been implemented for Billing Document Output
two different requirements have been implemented (Default vs. EDI)

All outbound INVOIC IDocs are enhanced by default, irrespective of their destination.

Again, the implementation of this User-Exit is simple and straightforward:

The Frame User-Exit ZEXIT_SAPLVEDF_002 is called within include ZXEDFU02 (not shown)
All outbound invoices pass fm ZEXIT_SAPLVEDF_002_DEFAULT
In addition, invoices for EDI customers pass fm ZEXIT_SAPLVEDF_002_EDI

Outbound invoices for EDI customers are well defined by their output attributes. The User-Exit service class ZCL_EXIT_SAPLVEDF_002_SERVICES (nomen est omen!) provides two methods:

ADD_CONSUMER_UNITS_PER_TU: The base unit of the sold products is cases (= traded units). The ratio Traded Unit : Consumer Units (CU) is missing in the standard INVOIC02 Idoc yet required by the EDI customers.
ADD_CONSUMER_UNITS_EAN: The base unit of the sold products is cases (= traded units) and, therefore, the TU-EAN (European Article Number) appears in the INVOIC02 IDoc. However, the EDI customers require to receive the CU-EAN as well

These two methods are called within User-Exit ZEXIT_SAPLVEDF_002_EDI. Mapping of these enhanced INVOIC02 IDocs to EDIFACT D.96A INVOIC messages happens on SAP-XI where the additional data show up in the LIN, PIA and PRI segments.

Lindt Poland (PL): EDI Invoicing without β-blockers

Lindt PL is about to catch up with other Lindt companies in terms of EDI trading. Namely, they want to start EDI invoicing with several customers.

Below you see the package ZCMOD in the R/3 system of Lindt PL. Already at a glance we see that

many more User-Exits are implemented on this system
the same User-Exits are used by different Lindt companies (Switzerland, Spain, Poland, and - not yet implemented - Sweden)

And here is the implementation of this Multiple-Use User-Exit:

The Frame User-Exit ZEXIT_SAPLVEDF_002 is called within include ZXEDFU02 (not shown)
Depending on the client the company-specifc User-Exit is called (e.g. ZEXIT_SAPLVEDF_002_ES for Spain and ZEXIT_SAPLVEDF_002_PL for Poland)

The implementation of the EDI requirements in User-Exit ZEXIT_SAPLVEDF_002_PL is done by an external consultant mandated by Lindt PL. The User-Exit Framework ensures structural independence among the different Lindt companies on the same R/3 system. Despite the fact that external consultants are currently working on a business-critical User-Exit in our R/3 system I can sleep well without the need for any β-blockers (see my previous Dangerous Liaisons in User-Exits and How to Avoid Them).

Lindt Australia (AU): ToBeDone...

Lindt AU does not yet use any User-Exits (or to be more precise: I have not yet done the refactoring of existing User-Exits). However, you need little imagination to guess

what package you will find on the R/3 system of Lindt AU,
the naming convention of the User-Exits and
how they will be organized

Summary

In this Weblog I have presented you the current benefits of the User-Exit Framework we are reaping among the Lindt companies. These benefits include:

High transparency of implemented User-Exits
High transparency of implemented requirements
Reusability of implementations due to recurring requirements among different Lindt companies
Structural independent implementation (resulting in a significant drop of sleepless nights...)

The User-Exit Framework consists of "old" technology (function groups and modules). However, this technology is highly sufficient for the structural organization of different requirements and Multiple-Use implementations of User-Exits. Yet as soon as the structural purpose is served I prefer to switch to ABAP-OO means, i.e. to implement the required services within methods.

Conclusion

In the long-term my User-Exit Framework, based on function groups, is likely to be superseded by the Enhancement Framework. However, what remains is that a smart organization of Exits / Enhancements is a prerequisite for high transparency and reusability. Both factors will speed up your implementations and eventually will reduce the development costs.

Multi-Purpose ALV List Programming

Uwe Schieferstein — Wed, 07 Jan 2009 06:44:12 GMT

*Introduction* Approved change requests (CR) initiate the creation of transport requests within our SAP systems. Each change request has a unique identifying number. In order to link change requests and transport requests we have defined a mandatory transport attribute Z_CR where the users have to maintain the change request number. Using the expanded selection screen of transaction SE03 (Option +Find Requests+) we can search for attribute Z_CR and change request numbers. The internal control system at Lindt (LICS) demands that a request must not be imported into the productive system by the owner of the request. Admittedly this is not the most sophisticated transport control yet in the context of Lindt (size and complexity of the SAP system landscape) it makes sense - and it works efficiently. In SAP terminology the importing user is the so-called *Admin *user. But where can we find the Admin user? Neither the +standard +list nor the +detailed +list of the import queue (transaction STMS) reveals the Admin user.

*Exploiting the SAP Standard* Looking under the hood of transaction STMS you will find that the function module behind the import history is *TMS_TM_IMPORT_HISTORY* (alternative: TMS_TU_IMPORT_HISTORY). Having the main functionality at our disposal we just need an appropriate selection screen and then build the ALV list around the collected data. Regarding the selection screen we can resort back to another SAP standard function module: *TRINT_SELECT_REQUESTS* This function module offers us the same selection screen like we have for transaction SE03 (Option +Find Requests+ => report RSWBOSDR) and this is exactly what we want. The user who is already familiar with this standard function can use the same selection screen yet gets a different output (see below). *Utility Class ZCL_REQUEST* Instead of using the standard function modules directly I created the utility class ZCL_REQUEST in order to collect all required data of a selected transport request. Within the CLASS_CONSTRUCTOR of this class I determine the transport configuration using function module *TMS_CI_READ_DOMAINCONFIG*. Here I have made the following assumption (which is correct in case of our system landscape but may be wrong in a different environment): 0.1. The first system of the configuration list is the development system (DEV) 0.2. The last system of the configuration list is the productive system (PRD) At Lindt we have 3-systems landscapes (DEV -> TST -> PRD). Thus, for each selected transport request we will generate three rows in the ALV list, one for each system (DEV, TST, PRD). The data for the ALV list are built from three different sources: * Transport History (fm TMS_TM_IMPORT_HISTORY) * Transport Log (fm TR_READ_GLOBAL_INFO_OF_REQUEST) *The Art of ALV Programming* The three different data sources are reflected by different column colours on the ALV list: 1. Transport Request: light and dark blue 2. Transport History: yellow 3. Transport Log: green In addition, I added three status columns: 0.1. +Status=RC+: LED showing the last return code (0=green, 4=yellow, ELSE=red)0.1. +Status:Admin+: Admin=Owner => EQUAL icon; Admin<>Owner => NOT EQUAL icon0.1. +S=Attribut+: Attribute Z_CR maintained => ATTRIBUTE icon; ELSE empty In case of Admin=Owner the status icon depends on the target system: 0.1. DEV, TST: normal EQUAL icon because here the owner is allowed to release or import his or her request 0.2. PRD: _red_ EQUAL icon because here the owner violated the internal control rules Sorting of the list: 1. Request number 2. Counter for systems (1=DEV; 2=TST; 3=PRD) NOTE: A MUST read for all ALV programmers is the excellent tutorial {code:html}An Easy Reference For ALV Grid Control{code} *The Power of ALV Lists* The initial purpose of this report was to reveal violations of the internal control rule that the owner must not import his transport request himself into the productive system. All we have to do is to define a new +layout +with the following filtering options: 0.1. Status:Admin = red EQUAL icon 0.2. Target System = LP0 (productive system) (optional) And here we have the "bad guys" caught in the act: the SAP user USCHIEFERST imported his own requests into the productive system! *Single ALV List - Multiple Purposes * Going back to the full ALV list you will notice the following: the *Admin *user is empty

when the request is not yet released on DEV (pseudo-RC = NREL)
when the request is not yet imported into TST or PRD (pseudo-RC = NIMP)

A request which is released but not yet imported into the PRD system may cause a problem after a system-copy (PRD -> TST) because these changes are lost and need to be re-imported into TST. Thus, we define a new +layout +with the following filtering options:

Status:Admin = TRANSPORT icon
Target System = LP0 (productive system)

And now the ALV displays a list of transport requests that we should import prior to the next system-copy.

A Christmas Collection of Useful Classes

Uwe Schieferstein — Thu, 11 Dec 2008 01:06:23 GMT

CL_RECA_MESSAGE_LIST - The ultimate message handler

This class (interface IF_RECA_MESSAGE_LIST) is the ultimate message handler (collector) in ABAP at least for me.

About two years ago I used this class very successfully in a data migration project (purchase orders including entire history; total volume ca. 800 Mio. CHF; Message Handling - Finding the Needle in the Haystack). I created a custom validation class and used CL_RECA_MESSAGE_LIST to collect and display the error messages in a tree view. Initially we started with about 150 thousands(!) error messages in the tree (no joke. Approx. 30% of the messages were overhead due to the hierarchical structuring of the messages. And we had a multiplication of errors, e.g. 5000 purchase orders had 4 vendos assigned in the history all of which contained some error => 5000 x 4 = 20'000 error messages).

Surprisingly, the tree display had no problems with this huge numbers of nodes. The message handler helped us tremendously to find out the errors in the migration data. Within a single day we were able to reduce the number or error messages from 150'000 (morning) to about 12'000 (lunch time) to about 500 (tea-time).

Do not miss to check out the sample reports in package SZAL, e.g. SBAL_DEMO_04_DETLEVEL.

CL_RECA_GUI_SERVICES

Still using function module TH_CREATE_MODE to open a transaction within a new GUI mode? If you have this class available on your SAP system then have a look at its static method CALL_TRANSACTION. Using parameter IF_NEW_EXTERNAL_MODE you can decide whether you want to open a new window or not.

I have not yet used any of the other available methods yet they may be useful as well:

GET_GUI_FUNC_OF_GUI_STATUS	Gets All Functions of a GUI Status
GET_ICON_FOR_BUSOBJ	Gets Icon with Quick Info for Business Object
GET_QUICKINFO_FOR_ICON	Gets the Quick Info for an Icon
MSGLIST_RAISE_AND_FREE	Exception of Message List with FREE

CL_RECA_DATE

I believe all of us have already encounter the problem to check whether two periods overlap or not. Two periods are overlapping if the beginning or the end of one period lies with the other period or if one period lies completely within the other period. In case of overlapping periods the static method CHECK_INTERSECTION will raise exception PERIODS_HAVE_INTERSECTION.

CL_RECA_GUID - Making object identifiers unique

If you need to get a unique identifier for your objects then get your GUID using the static method GET_NEW_GUID.

There are many more interesting classes in package RE_CA_BC e.g. like CL_RECA_COMM_SERVICES (Sending E-Mail) or CL_RECA_STRING_SERVICES (String: Utilities) which may be worth being investigated.

CL_REEXC_COMPANY_CODE & CL_REEXC_CONTROLLING_AREA

If you need data related to company codes (BUKRS) and controlling Areas (KOKRS) these two classes provide many useful methods.

CL_PT_EMPLOYEE - The Infotype Broker

You require access to all kinds of PAnnnn infotype data? Use this class (interface IF_PT_EMPLOYEE). It is as simply as that (Unified Access to All HR Infotypes).

CL_ABAP_CONTAINER_UTILITES - Being Unicode-Compatible

If you need to shuffle data between structured and unstructured variables and you do not want to run into any problems on Unicode systems then this is the right class to use.

FILL_CONTAINER_C	Fill Container of Type C or STRING with Content	structured -> unstructured
READ_CONTAINER_C	Read Container of Type C or STRING	unstructured -> structured

unicode -program giving dump unicode -program giving dump

Unicode - Transfer structure with packed fields (type p, x) into c-field Unicode - Transfer structure with packed fields (type p, x) into c-field

CL_GUI_CFW - Mastering Control Event Handling

Controls (like ALV grid, ALV tree, etc.) are very powerful and user-friendly development tools which should be used whenever appropriate.

However, there are stumbling blocks when working with controls which can be circumvented if you keep a few basic principles in mind:

Refreshing or Updating the control occurs automatically when passing PBO
Control events usually do NOT trigger PAI (and therefore there is no succeeding PBO - see (1.)).
Control events can be handled as system events (done by the control framework) or application events.
Using controls we have a frontend (= control) and a backend (e.g. the itab used for data display in an ALV grid).
For editable controls the data displayed at the frontend can differ from the data in the backend. Special control-specific methods are required to ensure synchronization between frontend and backend.

The effect of such a "sychronization" method is demonstrated in put X into checkbox of alv when button select all entries.put X into checkbox of alv when button select all entries. (CHECK_DATA_CHANGED of CL_GUI_ALV_GRID) and ALV Tree not getting refreshed (UPDATE_CALCULATIONS and FRONTEND_UPDATE of CL_GUI_ALV_TREE).

In almost all cases I use the control events as system events. Below you see what the SAP online documentation says:

You construct the tables using a special ABAP Objects Control Framework method (control->set_registered_events). When you register the event, you must specify whether the event is to be processed as a system event or as an application event.

System eventsare is triggered before any automatic field checks (for example, required fields) have taken place on the screen, and before any field transport. The PAI and PBO events are not triggered. Consequently, you cannot access any values that the user has just changed on the screen. Furthermore, there is no field transport back to the screen after the event, so values that you have changed in the event handling are not updated on the screen.

The handler method that you defined for the event is called automatically by the system. However, you can use the method set_new_ok_codeto set a new value for the OK_CODE field. This then triggers the PAI and PBO modules, and you can evaluate the contents of the OK_CODE field as normal in a PAI module.

Application eventsare triggered automatically at the end of the PAI event. Consequently, all field checks and field transport has taken place. If you want the event handler method to be called at a particular point during PAI processing, you must trigger the event handler using the static method

CL_GUI_CFW=>DISPATCH

Not using application events means no automatic field transport, no triggering of PAI (followed by PBO) and a potential discrepancy between frontend and backend.

So why I am still in favour of system events? Because they give me the freedom of choice.

If the control event is just used to display additional data (e.g. double-click on user name in ALV list -> call transaction SU01 for this user) there is no additonal effort required and I explicitly do not want to trigger PAI.

However, if the control event is used to change data (Hotspot-clicking (Insert function) plus ALV Sorting Hotspot-clicking (Insert function) plus ALV Sorting) then I call method CL_GUI_CFW=>SET_NEW_OK_CODE to trigger PAI. Thus, the system event has become an application event. All required updating of the ABAP backend (i.e. itab) is done here at PAI (and not within the event handler method). The succeeding PBO takes care of refreshing/updating the control (automatic flushing).

Conclusion

SAP provides many valuable and powerful classes and it is worth spending some time to search and find them. And, of course, adopt them.

Dangerous Liaisons in User-Exits and How to Avoid Them

Uwe Schieferstein — Tue, 11 Nov 2008 08:14:12 GMT

Introduction

"The R/3 enhancement concept allows you to add your own functionality to SAP's standard business applications without having to modify the original applications." (Introduction to the Enhancement Concept).

This blog is about a specific type of exit, namely Function Module Exits. Assuming that you are familiar with transactions CMOD and SMOD I will show you how User-Exits can be organized in order to achieve four major goals:

Easy Maintenance
High Transparency
Process-Independent Testing
Avoidance of Dangerous Liaisons

The Problem

User-Exits are normally implemented "On-Demand". Having found out that a specific behaviour of a standard application cannot be realized by means of customizing the next step is to look for appropriate User-Exits. An enhancement project (CMOD) is created and the required enhancements assigned. Now it is time to create the implementation of the User-Exit which occurs in a ZX-include predefined by SAP.

These ZX-includes have to be assigned to customer packages. Depending on who implements the ZX-includes and for which purposes they are implemented these User-Exit includes are likely to be scattered around many packages.

On one of our ERP systems the situation looks like this:

98 implemented ZX-includes are assigned to 15 different packages

The ZX-includes of User-Exit XLTO (User Exits for TO Processing) have been assigned to four(!) different packages demonstrating the historical evolution of this User-Exit.

Considering the fact that these User-Exits are shared by three different companies residing on three different clients this is already a bad situation regarding maintenance and transparency of the User-Exits.

From Bad to Worse

Being responsible for SAP-XI & EDI support at our company I sooner or later had to modify existing User-Exits for Billing-Doc-Output (XEDF). However, I almost got a heart attack when I saw the implementation of include ZXEDFU02 (EXIT_SAPLVEDF_002) for the first time (see below).

*----------------------------------------------------------------------** INCLUDE ZXEDFU02 **----------------------------------------------------------------------*DATA: L_TABIX LIKE SY-TABIX,      L_INDEX LIKE SY-INDEX.TABLES: VBAK. " JSC 080805L_TABIX = SY-TABIX.L_INDEX = SY-INDEX.*----------------------------------------------------------------------** INI MANDT = 200      SPAIN*----------------------------------------------------------------------*IF SY-MANDT = '200'. "España  DATA: LSP_LINES TYPE I,        LSP_EDIDD   LIKE EDIDD,        LSP_EDIDD2  LIKE EDIDD,        LSP_E1EDK02 LIKE E1EDK02,        LSP_E1EDK05 LIKE E1EDK05,        LSP_E1EDP05 LIKE E1EDP05,        LSP_E1EDP26 LIKE E1EDP26,        LSP_E1EDKA1 LIKE E1EDKA1,        LSP_Z1EDKA1 LIKE Z1EDKA1,        LSP_NRART   LIKE TPAR-NRART.* Inicio modificacion GGC 09/07/2004  DATA: L_CONT TYPE I,        L_EANWE LIKE LSP_E1EDKA1-LIFNR.  DATA: BEGIN OF I_EAN OCCURS 0,          VBELN LIKE VBDKR-VBELN,        "Nº factura          PARVW LIKE EDPAR-PARVW,        "Función interlocutor          EAN   LIKE EDPAR-EXPNR,        END OF I_EAN.  DATA: BEGIN OF I_EAN2 OCCURS 0.          INCLUDE STRUCTURE I_EAN.  DATA: END OF I_EAN2.  DATA: L_ERDAT LIKE LIKP-ERDAT.* Final modificacion GGC 09/07/2004  DESCRIBE TABLE INT_EDIDD LINES LSP_LINES.  READ TABLE INT_EDIDD INTO LSP_EDIDD INDEX LSP_LINES.  IF CONTROL_RECORD_OUT-MESTYP = 'INVOIC'.******************************************************************   Fecha de CABECERA*****************************************************************    IF INT_EDIDD-SEGNAM = 'E1EDK02' AND INT_EDIDD-SDATA(3) = '012'.      LSP_E1EDK02 = INT_EDIDD-SDATA.      SELECT SINGLE ERDAT INTO L_ERDAT        FROM LIKP WHERE VBELN = LSP_E1EDK02-BELNR.      LSP_E1EDK02-DATUM = L_ERDAT.      INT_EDIDD-SDATA = LSP_E1EDK02.      MODIFY INT_EDIDD INDEX SY-TABIX.    ENDIF.******************************************************************   Inicio añadir Nivel de condiciones.  CABECERA*****************************************************************    IF INT_EDIDD-SEGNAM = 'E1EDK05'.      LSP_E1EDK05 = INT_EDIDD-SDATA.      DATA: LSP_Z1EDK05 LIKE Z1EDK05.      SELECT SINGLE ZAEHK INTO LSP_Z1EDK05-ZCONT         FROM T683S WHERE KVEWE = 'A'                      AND KAPPL = 'V'                      AND KALSM = 'ZECLI1'                      AND KSCHL = LSP_E1EDK05-KSCHL.      IF SY-SUBRC = 0.        CLEAR LSP_EDIDD.        LSP_EDIDD-SEGNAM = 'Z1EDK05'.        LSP_EDIDD-SDATA = LSP_Z1EDK05.        APPEND LSP_EDIDD TO INT_EDIDD.      ENDIF.    ENDIF.                   "IF int_edidd-segnam = 'E1EDK05'.******************************************************************   Fin añadir Nivel de condiciones.  CABECERA***********************************************************************************************************************************   Inicio añadir Nivel de condiciones.  POSICIONES*****************************************************************    IF INT_EDIDD-SEGNAM = 'E1EDP05'.      LSP_E1EDP05 = INT_EDIDD-SDATA.      DATA: LSP_Z1EDP05 LIKE Z1EDP05.      SELECT SINGLE ZAEHK INTO LSP_Z1EDP05-ZCONT         FROM T683S WHERE KVEWE = 'A'                      AND KAPPL = 'V'                      AND KALSM = 'ZECLI1'                      AND KSCHL = LSP_E1EDP05-KSCHL.      IF SY-SUBRC = 0.        CLEAR LSP_EDIDD.        LSP_EDIDD-SEGNAM = 'Z1EDP05'.        LSP_EDIDD-SDATA = LSP_Z1EDP05.        APPEND LSP_EDIDD TO INT_EDIDD.      ENDIF.    ENDIF.                   "IF int_edidd-segnam = 'E1EDP05'.******************************************************************   Fin añadir Nivel de condiciones.  POSICIONES***********************************************************************************************************************************   Inicio determinacion del EAN EDI*****************************************************************    IF INT_EDIDD-SEGNAM = 'E1EDKA1'.      LSP_E1EDKA1 = INT_EDIDD-SDATA.      SELECT SINGLE NRART INTO LSP_NRART FROM TPAR       WHERE PARVW = LSP_E1EDKA1-PARVW.      IF LSP_NRART = 'KU'.* Inicio modificacion GGC 09/07/2004*       Comprobamos si la funcion esta repetida        CLEAR L_CONT.        SELECT EXPNR INTO LSP_E1EDKA1-LIFNR          FROM EDPAR WHERE KUNNR = XVBDKR-KUNAG                       AND PARVW = LSP_E1EDKA1-PARVW                       AND INPNR = LSP_E1EDKA1-PARTN.          L_CONT = L_CONT + 1.          IF L_CONT > 1.            EXIT.          ENDIF.        ENDSELECT.        IF L_CONT = 1.*         Si no esta repetida la funcion          INT_EDIDD-SDATA = LSP_E1EDKA1.          MODIFY INT_EDIDD INDEX LSP_LINES.        ENDIF.*       Comprobamos si el documento que estamos tratando es el mismo que*       el anterior        IMPORT I_EAN FROM MEMORY ID 'ZEANWE'.        READ TABLE I_EAN INDEX 1.        IF SY-SUBRC = 0.          IF I_EAN-VBELN <> XVBDKR-VBELN.*           Si no es el mismo borramos la tabla i_ean            REFRESH I_EAN.            EXPORT I_EAN TO MEMORY ID 'ZEANWE'.          ENDIF.        ENDIF.        CLEAR I_EAN.        IF L_CONT > 1.*         Si la funcion esta repetida la añadimos a i_ean          I_EAN-VBELN = XVBDKR-VBELN.          I_EAN-PARVW = LSP_E1EDKA1-PARVW.          APPEND I_EAN.          EXPORT I_EAN TO MEMORY ID 'ZEANWE'.        ENDIF.*       Modificamos EAN de los documentos que tenga funcion repetida        IF LSP_E1EDKA1-PARVW = 'WE' AND NOT I_EAN[] IS INITIAL.          LOOP AT INT_EDIDD WHERE SEGNAM = 'E1EDKA1'.            READ TABLE I_EAN WITH KEY PARVW = INT_EDIDD-SDATA(2).            IF SY-SUBRC = 0.*           Modificamos ean con ean de WE              L_EANWE = LSP_E1EDKA1-LIFNR.              LSP_E1EDKA1 = INT_EDIDD-SDATA.              LSP_E1EDKA1-LIFNR = L_EANWE.              INT_EDIDD-SDATA = LSP_E1EDKA1.              MODIFY INT_EDIDD.            ENDIF.          ENDLOOP.          REFRESH I_EAN.          CLEAR I_EAN.          EXPORT I_EAN TO MEMORY ID 'ZEANWE'.        ENDIF.* Final modificacion GGC 09/07/2004      ELSEIF LSP_NRART = 'LI'.        LSP_E1EDKA1-PARTN = LSP_E1EDKA1-LIFNR.        SELECT SINGLE EXPNR INTO LSP_E1EDKA1-LIFNR          FROM EDPAR WHERE KUNNR = XVBDKR-KUNAG                       AND PARVW = LSP_E1EDKA1-PARVW                       AND INPNR = LSP_E1EDKA1-PARTN.        IF SY-SUBRC  = 0.          INT_EDIDD-SDATA = LSP_E1EDKA1.          MODIFY INT_EDIDD INDEX LSP_LINES.        ENDIF.      ENDIF.    ENDIF.                   "IF int_edidd-segnam = 'E1EDKA1'.******************************************************************   Fin determinacion del EAN EDI***********************************************************************************************************************************   Modificamos el Valor neto de posición.      nnnn 19.07.04******************************************************************  -> Dejamos como esta lo que propone el sistema nnnn 18.01.06******************************************************************    IF INT_EDIDD-SEGNAM = 'E1EDP26' AND INT_EDIDD-SDATA(3) = '003'.*      LSP_E1EDP26 = INT_EDIDD-SDATA.*      LOOP AT XIKOMV WHERE KPOSN = XTVBDPR-POSNR*                       AND ( KNTYP = '6' OR KNTYP = '7' ).*        LSP_E1EDP26-BETRG = LSP_E1EDP26-BETRG - XIKOMV-KWERT.*      ENDLOOP.*      INT_EDIDD-SDATA = LSP_E1EDP26.*      MODIFY INT_EDIDD INDEX LSP_LINES.*    ENDIF.******************************************************************   Fin Modificamos el Valor neto de posición.  nnnn 19.07.04***********************************************************************************************************************************   Inicio añadimos el precio Neto tras el precio bruto*****************************************************************    IF INT_EDIDD-SEGNAM = 'E1EDP05'.      DATA: LSP_TAR     LIKE VBRP-NETWR,            LSP_NET     LIKE VBRP-NETWR,            LSP_MODIF.      LSP_E1EDP05 = INT_EDIDD-SDATA.      IF LSP_E1EDP05-KSCHL = 'ZTAR'.        LSP_TAR = LSP_E1EDP05-KRATE / LSP_E1EDP05-UPRBS.        CLEAR LSP_MODIF.        LOOP AT INT_EDIDD INTO LSP_EDIDD2.          IF LSP_EDIDD2-SEGNAM = 'E1EDP01'.            IF LSP_EDIDD2-SDATA(6) = XTVBDPR-POSNR.              LSP_MODIF = 'X'.            ENDIF.          ENDIF.          IF LSP_MODIF = 'X'.            IF LSP_EDIDD2-SEGNAM = 'E1EDP26'             AND LSP_EDIDD2-SDATA(3) = '001'.              LSP_E1EDP26 = LSP_EDIDD2-SDATA.              LSP_E1EDP26-BETRG = LSP_TAR.              CONDENSE LSP_E1EDP26-BETRG NO-GAPS.              LSP_EDIDD2-SDATA = LSP_E1EDP26.              MODIFY INT_EDIDD FROM LSP_EDIDD2.              LSP_E1EDP26-QUALF = '006'.              LSP_E1EDP26-BETRG = LSP_NET.              CONDENSE LSP_E1EDP26-BETRG NO-GAPS.              LSP_EDIDD2-SDATA = LSP_E1EDP26.              INSERT LSP_EDIDD2 INTO INT_EDIDD INDEX SY-TABIX.              CLEAR LSP_MODIF.            ENDIF.            IF LSP_EDIDD2-SEGNAM = 'E1EDP26'               AND LSP_EDIDD2-SDATA(3) = '003'.              LSP_E1EDP26 = LSP_EDIDD2-SDATA.              LSP_NET = LSP_E1EDP26-BETRG / XTVBDPR-FKLMG.            ENDIF.          ENDIF.        ENDLOOP.      ENDIF.    ENDIF.                   "IF int_edidd-segnam = 'E1EDP05'.******************************************************************   Fin añadimos el precio Neto tras el precio bruto***********************************************************************************************************************************   Inicio añadimos segmento NIF*****************************************************************    IF INT_EDIDD-SEGNAM = 'E1EDKA1'.      CLEAR LSP_EDIDD2.      LSP_EDIDD2-SEGNAM = 'Z1EDKA1'.      CLEAR LSP_Z1EDKA1.      SELECT SINGLE NRART INTO LSP_NRART FROM TPAR       WHERE PARVW = LSP_E1EDKA1-PARVW.      IF LSP_NRART = 'KU'.        SELECT SINGLE STCD1 STCEG          INTO (LSP_Z1EDKA1-STCD1,LSP_Z1EDKA1-STCEG)          FROM KNA1 WHERE KUNNR = LSP_E1EDKA1-PARTN.        LSP_EDIDD2-SDATA = LSP_Z1EDKA1.        APPEND LSP_EDIDD2 TO INT_EDIDD.      ELSEIF LSP_NRART = 'LI'.        SELECT SINGLE STCD1 STCEG          INTO (LSP_Z1EDKA1-STCD1,LSP_Z1EDKA1-STCEG)          FROM KNA1 WHERE LIFNR = LSP_E1EDKA1-PARTN.        LSP_EDIDD2-SDATA = LSP_Z1EDKA1.        APPEND LSP_EDIDD2 TO INT_EDIDD.      ENDIF.    ENDIF.                   "IF int_edidd-segnam = 'E1EDKA1'.******************************************************************   Inicio añadimos segmento NIF***********************************************************************************************************************************   Inicio cantidad en unidades*****************************************************************    IF INT_EDIDD-SEGNAM = 'E1EDP01'.      DATA: LSP_E1EDP01 LIKE E1EDP01,            LSP_MEINH  LIKE MARA-MEINS,            LSP_MEINS  LIKE MARA-MEINS,            LSP_MATNR  LIKE MARA-MATNR,            LSP_MENGE  LIKE EKPO-MENGE,            LSP_MENGE2 LIKE EKPO-MENGE.      LSP_E1EDP01 = INT_EDIDD-SDATA.      IF LSP_E1EDP01-MENEE <> 'PCE'.        SELECT SINGLE MSEHI INTO LSP_MEINH          FROM T006 WHERE ISOCODE = LSP_E1EDP01-MENEE.        SELECT SINGLE MSEH3 INTO LSP_MEINS          FROM T006A WHERE SPRAS = SY-LANGU                       AND MSEHI = LSP_MEINH.        LSP_MATNR = XTVBDPR-MATNR.        LSP_MENGE = LSP_E1EDP01-MENGE.        CALL FUNCTION 'MD_CONVERT_MATERIAL_UNIT'             EXPORTING                  I_MATNR              = LSP_MATNR                  I_IN_ME              = LSP_MEINH                  I_OUT_ME             = 'ST'                  I_MENGE              = LSP_MENGE             IMPORTING                  E_MENGE              = LSP_MENGE2             EXCEPTIONS                  ERROR_IN_APPLICATION = 1                  ERROR                = 2                  OTHERS               = 3.        IF SY-SUBRC  = 0.          LSP_E1EDP01-MENEE = 'PCE'.          LSP_E1EDP01-MENGE = LSP_MENGE2.          CONDENSE LSP_E1EDP01-MENGE NO-GAPS.          INT_EDIDD-SDATA = LSP_E1EDP01.          MODIFY INT_EDIDD INDEX LSP_LINES.        ENDIF.      ENDIF.    ENDIF.                   "IF int_edidd-segnam = 'E1EDP01'.******************************************************************   Fin cantidad en unidades***********************************************************************************************************************************   Inicio fecha de vencimiento*****************************************************************    IF INT_EDIDD-SEGNAM = 'E1EDK18'.      DATA: LSP_E1EDK18 LIKE E1EDK18.      DATA: LSP_LONG TYPE I,            LSP_CONT TYPE I,            LSP_FECHA(8).      LSP_E1EDK18 = INT_EDIDD-SDATA.      DO.        IF LSP_E1EDK18-ZTERM_TXT IS INITIAL.          EXIT.        ENDIF.        IF LSP_E1EDK18-ZTERM_TXT(1) CA '1234567890'.          CONCATENATE LSP_E1EDK18-ZTERM_TXT+6(4)                      LSP_E1EDK18-ZTERM_TXT+3(2)                      LSP_E1EDK18-ZTERM_TXT(2)          INTO LSP_FECHA.          EXIT.        ELSE.          SHIFT LSP_E1EDK18-ZTERM_TXT LEFT.        ENDIF.      ENDDO.      LSP_E1EDK18-ZTERM_TXT = LSP_FECHA.      INT_EDIDD-SDATA = LSP_E1EDK18.      MODIFY INT_EDIDD INDEX LSP_LINES.    ENDIF.          "IF int_edidd-segnam = 'E1EDK18'.******************************************************************   Fin fecha de vencimiento*****************************************************************  ENDIF.            "IF control_record_out-mestyp = 'INVOIC'ENDIF.              "IF sy-mandt = '200'. "España*----------------------------------------------------------------------** FIN MANDT = 200      SPAIN*----------------------------------------------------------------------**----------------------------------------------------------------------** Start MANDT = 100      Switzerland*----------------------------------------------------------------------*IF SY-MANDT = '100'.    "Switzerland*----------------------------------------------------------------------* Wenn der Summenrecord geschrieben wird, muss der WE von der Position* auf die Kopfeben geschrieben werden  DATA: %INT_EDIDD_ZW LIKE EDIDD.                           "ATA02  DATA: %E1EDK01      LIKE E1EDK01.                         "ATA03  DATA: %KUNNR        LIKE KNA1-KUNNR.                      "ATA04  DATA: %STCEG        LIKE KNA1-STCEG.                      "ATA04  DATA: %E1EDP19      LIKE E1EDP19.                         "ATA04  DATA: %THEAD        LIKE THEAD.                           "ATA04  DATA: %INLINES LIKE TLINE OCCURS 0 WITH HEADER LINE.      "ATA04  DATA: %LINES   LIKE TLINE OCCURS 0 WITH HEADER LINE.      "ATA04  DATA: %TABIX LIKE SY-TABIX.                               "ATA04  DATA: %E1EDP26      LIKE E1EDP26.                         "ATA07  IF INT_EDIDD-SEGNAM EQ 'E1EDS01' AND                      "ATA02    INT_EDIDD-SDATA(3) EQ '010'.                            "ATA02    %INT_EDIDD_ZW = INT_EDIDD.                              "ATA02    PERFORM WE_KOPF TABLES INT_EDIDD.                       "ATA02    INT_EDIDD = %INT_EDIDD_ZW.                              "ATA02  ENDIF.                                                    "ATA02  IF INT_EDIDD-SEGNAM EQ 'E1EDP26' AND                      "ATA07    INT_EDIDD-SDATA(3) EQ '003'.                            "ATA07*/  IF XTVBDPR-NETWR = '0.02' AND                           "ATA07*/    XTVBDPR-KZWI1 GT '0.02' AND                           "ATA07*/    XTVBDPR-KZWI3 EQ '0.00'.                              "ATA07    IF ( XTVBDPR-NETWR = '0.02' AND                         "ATA07      XTVBDPR-KZWI1 GT '0.02' AND                           "ATA07      XTVBDPR-KZWI3 EQ '0.00' ) or                          "ATA07       ( XTVBDPR-NETWR = '0.01' AND                         "ATA07      XTVBDPR-KZWI1 lt '0.03' AND                           "ATA07      XTVBDPR-KZWI3 lt '0.03' ).                            "ATA07* positionieren auf Positionsdaten                          "ATA07      READ TABLE INT_EDIDD WITH                             "ATA07        KEY SEGNAM = 'E1EDP01'                              "ATA07            SDATA(6) = XTVBDPR-POSNR.                       "ATA07* auf nächtem Eintrag positionieren                         "ATA07      if sy-subrc eq 0.                                     "ATA07        &TABIX = SY-TABIX + 1.                              "ATA07* lesen Positionssegment                                    "ATA07        LOOP AT INT_EDIDD FROM &TABIX                       "ATA07*/      LOOP AT INT_EDIDD                                   "ATA03          WHERE SEGNAM EQ 'E1EDP26'.                        "ATA03          IF INT_EDIDD-SDATA(3) EQ '003'.                   "ATA07            %E1EDP26 = INT_EDIDD-SDATA.                     "ATA07* Betrag auf Null setzen                                    "ATA07            CLEAR &P_BETRG_T.                               "ATA07            %E1EDP26-BETRG = &P_BETRG_T. "Num > Char        "ATA07            CONDENSE %E1EDP26-BETRG.     "Num > Char        "ATA07            INT_EDIDD-SDATA = %E1EDP26.                     "ATA07            MODIFY INT_EDIDD INDEX SY-TABIX.                "ATA07          ENDIF.                                            "ATA07        ENDLOOP.                                            "ATA07      ENDIF.                                                "ATA07    ENDIF.  ENDIF.                                                    "ATA07  CLEAR: CH_AG_KUNNR, CH_RE_KUNNR, CH_WE_KUNNR, CH_RG_KUNNR.  CH_AG_KUNNR = XVBDKR-KUNAG.  CH_RE_KUNNR = XVBDKR-KUNRE.  CH_WE_KUNNR = XVBDKR-KUNWE.  CH_RG_KUNNR = XVBDKR-KUNRG.* Lesen Steuertabelle  SELECT SINGLE * FROM VBAK WHERE VBELN = XVBDKR-VBELN_VAUF.  REFRESH CH_DATALIST.  SELECT * FROM ZZEDIAUART           INTO CORRESPONDING FIELDS OF TABLE CH_DATALIST           WHERE DATUV LE SY-DATUM AND                 DATBI GE SY-DATUM AND                 BELEGART = VBAK-AUART AND                 VKORG    = VBAK-VKORG AND                 ( AG_KUNNR = CH_AG_KUNNR OR                 RG_KUNNR = CH_RG_KUNNR OR                 RE_KUNNR = CH_RE_KUNNR OR                 WE_KUNNR = CH_WE_KUNNR ).  IF SY-SUBRC = 0.                                          "ATA01    IF CH_AG_KUNNR IS INITIAL.      CLEAR CH_AG_KUNNRC.      DELETE CH_DATALIST WHERE NOT AG_KUNNR IS INITIAL.    ELSE.      CH_AG_KUNNRC = CH_AG_KUNNR.      DELETE CH_DATALIST WHERE AG_KUNNR NE CH_AG_KUNNR AND                          NOT  AG_KUNNR IS INITIAL.    ENDIF.    IF CH_RE_KUNNR IS INITIAL.      CLEAR CH_RE_KUNNRC.      DELETE CH_DATALIST WHERE NOT RE_KUNNR IS INITIAL.    ELSE.      CH_RE_KUNNRC = CH_RE_KUNNR.      DELETE CH_DATALIST WHERE RE_KUNNR NE CH_RE_KUNNR AND                          NOT  RE_KUNNR IS INITIAL.    ENDIF.    IF CH_WE_KUNNR IS INITIAL.      CLEAR CH_WE_KUNNRC.      DELETE CH_DATALIST WHERE NOT WE_KUNNR IS INITIAL.    ELSE.      CH_WE_KUNNRC = CH_WE_KUNNR.      DELETE CH_DATALIST WHERE WE_KUNNR NE CH_WE_KUNNR AND                          NOT  WE_KUNNR IS INITIAL.    ENDIF.    IF CH_RG_KUNNR IS INITIAL.      CLEAR CH_RG_KUNNRC.      DELETE CH_DATALIST WHERE NOT RG_KUNNR IS INITIAL.    ELSE.      CH_RG_KUNNRC = CH_RG_KUNNR.      DELETE CH_DATALIST WHERE RG_KUNNR NE CH_RG_KUNNR AND                          NOT  RG_KUNNR IS INITIAL.    ENDIF.    READ TABLE CH_DATALIST INDEX 1.* Wurde ein Eintrag gefunden ?    IF SY-SUBRC EQ 0.                                       "ATA01* wird das Kopfsegment EIEDK01 verarbeitet.                 "ATA03      IF INT_EDIDD-SEGNAM EQ 'E1EDK01'.                     "ATA03        LOOP AT INT_EDIDD                                   "ATA03          WHERE SEGNAM EQ 'E1EDK01'.                        "ATA03          %E1EDK01 = INT_EDIDD-SDATA.                       "ATA03          IF %E1EDK01-BSART EQ 'CRME' OR                    "ATA03            %E1EDK01-BSART EQ 'INVO'.                       "ATA03            IF %E1EDK01-FKART_RL(1) EQ 'Z'.                 "ATA03              %E1EDK01-FKART_RL =  %E1EDK01-FKART_RL+1.     "ATA03              INT_EDIDD-SDATA = %E1EDK01.                   "ATA03              MODIFY INT_EDIDD INDEX SY-TABIX.              "ATA03            ENDIF.                                          "ATA03* Für Stornogutschriften soll die BSART auf CRME geändert werden.ATA05* und Fakturaart auf LR                                          ATA05            IF XVBDKR-VBTYP EQ 'S'.                         "ATA05              IF %E1EDK01-BSART EQ 'INVO'.                  "ATA05                %E1EDK01-BSART = 'CRME'.                    "ATA05                INT_EDIDD-SDATA = %E1EDK01.                 "ATA05                MODIFY INT_EDIDD INDEX SY-TABIX.            "ATA05              ENDIF.                                        "ATA05              IF %E1EDK01-FKART_RL NE 'LR'.                 "ATA05                %E1EDK01-FKART_RL = 'LR'.                   "ATA05                INT_EDIDD-SDATA = %E1EDK01.                 "ATA05                MODIFY INT_EDIDD INDEX SY-TABIX.            "ATA05              ENDIF.                                        "ATA05            ENDIF.                                          "ATA05          ENDIF.                                            "ATA03        ENDLOOP.                                            "ATA03      ENDIF.                                                "ATA03      CASE CH_DATALIST-UEPOS_CASE.        WHEN 01.                              "nnnn* Im Kopfsegment muss die Kunden-MwSt geprüft werden          IF INT_EDIDD-SEGNAM EQ 'E1EDK01'.                 "ATA04            LOOP AT INT_EDIDD                               "ATA04              WHERE SEGNAM EQ 'E1EDK01'.                    "ATA04              %E1EDK01 = INT_EDIDD-SDATA.                   "ATA04              IF CH_DATALIST-PARVW_MWSTID IS INITIAL.       "ATA04                CLEAR %E1EDK01-KUNDEUINR.                   "ATA04                INT_EDIDD-SDATA = %E1EDK01.                 "ATA04                MODIFY INT_EDIDD INDEX SY-TABIX.            "ATA04              ELSE.                                         "ATA04* lesen Kundeninformation zu Partnerrolle                   "ATA04                CLEAR %KUNNR.                               "ATA04                CASE CH_DATALIST-PARVW_MWSTID.              "ATA04                  WHEN 'AG'.                                "ATA04                    %KUNNR = XVBDKR-KUNAG.                  "ATA04                  WHEN 'RE'.                                "ATA04                    %KUNNR = XVBDKR-KUNRE.                  "ATA04                  WHEN 'RG'.                                "ATA04                    %KUNNR = XVBDKR-KUNRG.                  "ATA04                ENDCASE.                                    "ATA04                SELECT SINGLE STCEG  FROM KNA1              "ATA04                 INTO %STCEG                                "ATA04                 WHERE KUNNR EQ %KUNNR.                     "ATA04                IF SY-SUBRC EQ 0.                           "ATA04                  %E1EDK01-KUNDEUINR = %STCEG.              "ATA04                  INT_EDIDD-SDATA = %E1EDK01.               "ATA04                  MODIFY INT_EDIDD INDEX SY-TABIX.          "ATA04                ENDIF.                                      "ATA04              ENDIF.                                        "ATA04            ENDLOOP.                                        "ATA04          ENDIF.                                            "ATA04* In den Positionen soll der Positionstext mit der ersten   "ATA04* Zeile des Vertriebstext ersetzt werdeneprüft werden       "ATA04          IF INT_EDIDD-SEGNAM EQ 'E1EDP19' AND              "ATA04            INT_EDIDD-SDATA(3) = '002'.                     "ATA04* lesen letzter Eintrag der Tabelle                         "ATA04            LOOP AT INT_EDIDD                               "ATA04              WHERE SEGNAM EQ 'E1EDP19'                     "ATA04              AND   SDATA(3) EQ INT_EDIDD-SDATA(3).         "ATA04              %TABIX = SY-TABIX.                            "ATA04            ENDLOOP.                                        "ATA04            %E1EDP19 = INT_EDIDD-SDATA.                     "ATA04* lesen Vertriebstext des Materialstams                     "ATA04            CLEAR %THEAD.                                   "ATA04            %THEAD-TDNAME       = XTVBDPR-MATNR.            "ATA04            %THEAD-TDNAME+18(4) = XVBDKR-VKORG.             "ATA04            %THEAD-TDNAME+22(2) = XVBDKR-VTWEG.             "ATA04            %THEAD-TDID         = '0001'.                   "ATA04            %THEAD-TDOBJECT     = 'MVKE'.                   "ATA04            %THEAD-TDSPRAS      = DOBJECT-SPRAS.            "ATA04            CALL FUNCTION 'READ_TEXT_INLINE'                "ATA04              EXPORTING                                     "ATA04                ID                    = %THEAD-TDID         "ATA04                INLINE_COUNT          = 1                   "ATA04                LANGUAGE              = %THEAD-TDSPRAS      "ATA04                NAME                  = %THEAD-TDNAME       "ATA04                OBJECT                = %THEAD-TDOBJECT     "ATA04              TABLES                                        "ATA04                INLINES               = %INLINES            "ATA04                LINES                 = %LINES              "ATA04             EXCEPTIONS                                     "ATA04               ID                    = 1                    "ATA04               LANGUAGE              = 2                    "ATA04               NAME                  = 3                    "ATA04               NOT_FOUND             = 4                    "ATA04               OBJECT                = 5                    "ATA04               REFERENCE_CHECK       = 6                    "ATA04               OTHERS                = 7.                   "ATA04            IF SY-SUBRC EQ 0.                               "ATA04              %E1EDP19-KTEXT = %INLINES-TDLINE.             "ATA04              INT_EDIDD-SDATA = %E1EDP19.                   "ATA04              MODIFY INT_EDIDD INDEX %TABIX.                "ATA04            ENDIF.                                          "ATA04          ENDIF.                                            "ATA04* nur Paynet-Rechnungen verarbeiten          IF NOT CH_DATALIST-PFLAG IS INITIAL.            PERFORM PARNERROLLE_PDF TABLES INT_EDIDD                                    USING  XVBDKR                                           CH_DATALIST.          ENDIF.* prüfen, ob Verarbeitung bei Summen angelangt ist, erst danach* dürfen die Positionen verarbeitet werden          CLEAR &LSUMME.          LOOP AT INT_EDIDD            WHERE SEGNAM EQ 'E1EDS01'.            IF INT_EDIDD-SDATA(3) EQ '010'.              &LSUMME = 'X'.            ENDIF.          ENDLOOP.          IF &LSUMME EQ 'X'.                                "ATA01* Die unterpositionen werden auf die Hauptposition summiert            PERFORM POS_SUMMIEREN TABLES INT_EDIDD                                         XTVBDPR                                  USING  XVBDKR.* Durch den Chargensplitt entstehen zusätzliche Positionen welche wieder* gelöscht werden sollen.            PERFORM POS_LOESCHEN  TABLES INT_EDIDD                                         XTVBDPR                                  USING  XVBDKR.          ENDIF.      ENDCASE.    ENDIF.                                                  "ATA01  ENDIF.                                                    "ATA01**---------------------------------------------------- Begin ho20070410**----------------------------------------------------------------------** User Exit for EDI CH begin ----------------------------**----------------------------------------------------------------------  IF CONTROL_RECORD_OUT-RCVPRT EQ 'KU' AND     CONTROL_RECORD_OUT-IDOCTP EQ 'INVOIC02'.    CALL FUNCTION 'ZEDI_INVOIC_CH_UMSCHL'         EXPORTING              XVBDKR                        = XVBDKR              DOBJECT                       = DOBJECT              CONTROL_RECORD_OUT            = CONTROL_RECORD_OUT         TABLES              INT_EDIDD                     = INT_EDIDD              XTVBDPR                       = XTVBDPR              XIKOMV                        = XIKOMV              XIKOMVD                       = XIKOMVD         EXCEPTIONS              ERROR_MESSAGE_RECEIVED        = 1              DATA_NOT_RELEVANT_FOR_SENDING = 2              OTHERS                        = 3.    IF SY-SUBRC <> 0.      CASE SY-SUBRC.        WHEN 1.          MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO                  WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4                       RAISING ERROR_MESSAGE_RECEIVED.        WHEN 2.          MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO                  WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4                       RAISING DATA_NOT_RELEVANT_FOR_SENDING.      ENDCASE.    ENDIF.  ENDIF.**----------------------------------------------------------------------** User Exit for EDI CH end   ----------------------------**----------------------------------------------------------------------**---------------------------------------------------- End   ho20070410ENDIF.*----------------------------------------------------------------------** End MANDT = 100      Switzerland*----------------------------------------------------------------------*

While it is easy to spot the two companies (Spain & Switzerland) that have used this User-Exits it is less obvious to identify and understand the manifold requirements that have been implemented.

Step 1 - Organizing the Mess

In order to organize the existing and new User-Exits in a more meaningful way I created a new package ZCMOD. This package is intended to contain all User-Exit related repository objects.

The next step was to clearly separate the company specific coding. This was achieved by a generic Five-Step approach:

Create a Z-exit function group (if not already existing)
Copy the Exit-Function Module to a Z-Exit Function Module
Create company specific Z-Exit Function Modules
Replace coding in ZX-include with function module call
Reassign ZX-includes to the new package ZCMOD

The result of the first three steps is shown below:

A new function group ZXEDF was created and assigned to the package ZCMOD. The Exit-Function module EXIT_SAPLVEDF_002 was copied to ZEXIT_SAPLVEDF_002 in function group ZXEDF. This function module was again copied twice to yield ZEXIT_SAPLVEDF_002_CH and ZEXIT_SAPLVEDF_002_ES. The main point is that all Z-exit function modules have the same interface like the SAP Standard Function Module-Exit.

Implementing User-Exits: Once and for All

If we need to touch SAP standard objects we should always try to do it once and for all. In case of Function Module-Exits this can be done quite easily:

The ZX-include contains nothing but a call to the frame Z-exit function module (see below).

Using this approach we obviously never ever have to touch this ZX-include again.

The Frame Z-Exit Function Module

The frame function module ZEXIT_SAPLVEDF_002 has the function to separate the coding logic at the highest hierarchical level which in our case are the companies:

FUNCTION zexit_saplvedf_002.*"----------------------------------------------------------------------*"*"Globale Schnittstelle:*"       IMPORTING*"             VALUE(XVBDKR) LIKE  VBDKR STRUCTURE  VBDKR*"             VALUE(DOBJECT) LIKE  NAST STRUCTURE  NAST OPTIONAL*"             VALUE(CONTROL_RECORD_OUT) LIKE  EDIDC STRUCTURE  EDIDC*"         OPTIONAL*"       TABLES*"              INT_EDIDD STRUCTURE  EDIDD*"              XTVBDPR STRUCTURE  VBDPR*"              XIKOMV STRUCTURE  KOMV OPTIONAL*"              XIKOMVD STRUCTURE  KOMVD OPTIONAL*"       EXCEPTIONS*"              ERROR_MESSAGE_RECEIVED*"              DATA_NOT_RELEVANT_FOR_SENDING*"----------------------------------------------------------------------  CASE syst-mandt.*   User-Exit: Lindt Switzerland (CH)    WHEN gc_client_lindt_ch.      CALL FUNCTION 'ZEXIT_SAPLVEDF_002_CH'           EXPORTING                xvbdkr                        = xvbdkr                dobject                       = dobject                control_record_out            = control_record_out           TABLES                int_edidd                     = int_edidd                xtvbdpr                       = xtvbdpr                xikomv                        = xikomv                xikomvd                       = xikomvd           EXCEPTIONS                error_message_received        = 1                data_not_relevant_for_sending = 2                OTHERS                        = 3.*   User-Exit: Lindt Spain (ES)    WHEN gc_client_lindt_es.      CALL FUNCTION 'ZEXIT_SAPLVEDF_002_ES'           EXPORTING                xvbdkr                        = xvbdkr                dobject                       = dobject                control_record_out            = control_record_out           TABLES                int_edidd                     = int_edidd                xtvbdpr                       = xtvbdpr                xikomv                        = xikomv                xikomvd                       = xikomvd           EXCEPTIONS                error_message_received        = 1                data_not_relevant_for_sending = 2                OTHERS                        = 3.    WHEN OTHERS.  ENDCASE.  CASE syst-subrc.    when '0'.    WHEN '1'.      MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno              WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4              RAISING error_message_received.    WHEN OTHERS.      MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno              WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4              RAISING data_not_relevant_for_sending.  ENDCASE.ENDFUNCTION.

The company specific function modules contain the company specific coding:

FUNCTION zexit_saplvedf_002_ch.*"----------------------------------------------------------------------*"*"Globale Schnittstelle:*"  IMPORTING*"     VALUE(XVBDKR) LIKE  VBDKR STRUCTURE  VBDKR*"     VALUE(DOBJECT) LIKE  NAST STRUCTURE  NAST OPTIONAL*"     VALUE(CONTROL_RECORD_OUT) LIKE  EDIDC STRUCTURE  EDIDC OPTIONAL*"  TABLES*"      INT_EDIDD STRUCTURE  EDIDD*"      XTVBDPR STRUCTURE  VBDPR*"      XIKOMV STRUCTURE  KOMV OPTIONAL*"      XIKOMVD STRUCTURE  KOMVD OPTIONAL*"  EXCEPTIONS*"      ERROR_MESSAGE_RECEIVED*"      DATA_NOT_RELEVANT_FOR_SENDING*"----------------------------------------------------------------------* User-Exit: Lindt Switzerland (CH)  CHECK ( syst-mandt = gc_client_lindt_ch ).*----------------------------------------------------------------------** Start MANDT = 100      Switzerland*----------------------------------------------------------------------** Wenn der Summenrecord geschrieben wird, muss der WE von der Position* auf die Kopfeben geschrieben werden  DATA: %int_edidd_zw LIKE edidd.                           "ATA02  DATA: %e1edk01      LIKE e1edk01.                         "ATA03  DATA: %kunnr        LIKE kna1-kunnr.                      "ATA04  DATA: %stceg        LIKE kna1-stceg.                      "ATA04  DATA: %e1edp19      LIKE e1edp19.                         "ATA04  DATA: %thead        LIKE thead.                           "ATA04  DATA: %inlines LIKE tline OCCURS 0 WITH HEADER LINE.      "ATA04  DATA: %lines   LIKE tline OCCURS 0 WITH HEADER LINE.      "ATA04  DATA: %tabix LIKE sy-tabix.                               "ATA04  DATA: %e1edp26      LIKE e1edp26.                         "ATA07  IF int_edidd-segnam EQ 'E1EDS01' AND                      "ATA02...

FUNCTION ZEXIT_SAPLVEDF_002_ES.*"----------------------------------------------------------------------*"*"Globale Schnittstelle:*"       IMPORTING*"             VALUE(XVBDKR) LIKE  VBDKR STRUCTURE  VBDKR*"             VALUE(DOBJECT) LIKE  NAST STRUCTURE  NAST OPTIONAL*"             VALUE(CONTROL_RECORD_OUT) LIKE  EDIDC STRUCTURE  EDIDC*"         OPTIONAL*"       TABLES*"              INT_EDIDD STRUCTURE  EDIDD*"              XTVBDPR STRUCTURE  VBDPR*"              XIKOMV STRUCTURE  KOMV OPTIONAL*"              XIKOMVD STRUCTURE  KOMVD OPTIONAL*"       EXCEPTIONS*"              ERROR_MESSAGE_RECEIVED*"              DATA_NOT_RELEVANT_FOR_SENDING*"----------------------------------------------------------------------* User-Exit: Lindt Spain (ES)  CHECK ( syst-mandt = gc_client_lindt_es ).*----------------------------------------------------------------------** INCLUDE ZXEDFU02 **----------------------------------------------------------------------*DATA: L_TABIX LIKE SY-TABIX,      L_INDEX LIKE SY-INDEX....

Step 2 - Complete Structural Separation of Concerns

Even though we have now separated the company specific coding the function modules are still linked together into a single function group. Thus, if developers need to change the User-Exit for different companies at the same time they might interfere with each others. Therefore the next level of organizing User-Exits is required: the complete structural separation of concerns.

For each company a specific Z-Exit function group is created:

ZXMGV - Frame Z-Exit function group
ZXMGV_CH - specific for Lindt Switzerland
ZXMGV_ES - specific for Lindt Spain
ZXMGV_ES - specific for Lindt Poland

Within the frame function module ZEXIT_SAPMV01_002 we determine the name of the company specific function module and dynamically call it.

FUNCTION zexit_saplmv01_002.*"----------------------------------------------------------------------*"*"Lokale Schnittstelle:*"  IMPORTING*"     VALUE(MESSAGE_TYPE) LIKE  EDMSG-MSGTYP*"     VALUE(SEGMENT_NAME) LIKE  EDIDD-SEGNAM*"     VALUE(F_MARA) LIKE  MARA STRUCTURE  MARA OPTIONAL*"     VALUE(F_MAKT) LIKE  MAKT STRUCTURE  MAKT OPTIONAL*"     VALUE(F_MARC) LIKE  MARC STRUCTURE  MARC OPTIONAL*"     VALUE(F_MARD) LIKE  MARD STRUCTURE  MARD OPTIONAL*"     VALUE(F_MFHM) LIKE  MFHM STRUCTURE  MFHM OPTIONAL*"     VALUE(F_MPGD) LIKE  MPGD STRUCTURE  MPGD OPTIONAL*"     VALUE(F_MPOP) LIKE  MPOP STRUCTURE  MPOP OPTIONAL*"     VALUE(F_MPRW) LIKE  MPRW STRUCTURE  MPRW OPTIONAL*"     VALUE(F_MVEG) LIKE  MVEG STRUCTURE  MVEG OPTIONAL*"     VALUE(F_MVEU) LIKE  MVEU STRUCTURE  MVEU OPTIONAL*"     VALUE(F_MKAL) LIKE  MKAL STRUCTURE  MKAL OPTIONAL*"     VALUE(F_MARM) LIKE  MARM STRUCTURE  MARM OPTIONAL*"     VALUE(F_MEAN) LIKE  MEAN STRUCTURE  MEAN OPTIONAL*"     VALUE(F_MBEW) LIKE  MBEW STRUCTURE  MBEW OPTIONAL*"     VALUE(F_MLGN) LIKE  MLGN STRUCTURE  MLGN OPTIONAL*"     VALUE(F_MVKE) LIKE  MVKE STRUCTURE  MVKE OPTIONAL*"     VALUE(F_MLAN) LIKE  MLAN STRUCTURE  MLAN OPTIONAL*"     VALUE(F_MLGT) LIKE  MLGT STRUCTURE  MLGT OPTIONAL*"  EXPORTING*"     VALUE(IDOC_CIMTYPE) LIKE  EDIDC-CIMTYP*"  TABLES*"      IDOC_DATA STRUCTURE  EDIDD*"----------------------------------------------------------------------  CONSTANTS:    lc_funcname       TYPE funcname  VALUE 'ZEXIT_SAPLMV01_002',*    lc_country_ch(2)  TYPE c         VALUE 'CH',    lc_country_es(2)  TYPE c         VALUE 'ES',    lc_country_pl(2)  TYPE c         VALUE 'PL'.  DATA:    ld_func          TYPE funcname,    ld_suffix        TYPE funcname.  CASE syst-mandt.    WHEN '100'.  ld_suffix = lc_country_ch.  " Lindt CH    WHEN '200'.  ld_suffix = lc_country_es.  " Lindt ES    WHEN '320'.  ld_suffix = lc_country_pl.  " Lindt PL    WHEN OTHERS.      EXIT.  ENDCASE.  CONCATENATE lc_funcname ld_suffix    INTO ld_func    SEPARATED BY '_'.  CONDENSE ld_func  NO-GAPS.  TRANSLATE ld_func TO UPPER CASE.  CALL FUNCTION ld_func       EXPORTING            message_type = message_type            segment_name = segment_name            f_mara       = f_mara            f_makt       = f_makt            f_marc       = f_marc            f_mard       = f_mard            f_mfhm       = f_mfhm            f_mpgd       = f_mpgd            f_mpop       = f_mpop            f_mprw       = f_mprw            f_mveg       = f_mveg            f_mveu       = f_mveu            f_mkal       = f_mkal            f_marm       = f_marm            f_mean       = f_mean            f_mbew       = f_mbew            f_mlgn       = f_mlgn            f_mvke       = f_mvke            f_mlan       = f_mlan            f_mlgt       = f_mlgt       IMPORTING            idoc_cimtype = idoc_cimtype       TABLES            idoc_data    = idoc_data.ENDFUNCTION.

There are two obvious advantages of this structural organization of User-Exits:

Errors accidentially introduced into a User-Exit will not affect any other company.
Different companies can modify the same User-Exit at the same time without interfering with each other.

Summary

In this weblog I presented a possible strategy how to organize User-Exits (CMOD / SMOD). The major steps of this approach are:

Create a specific package (e.g. ZCMOD) containing all User-Exit related repository objects
Copy the Exit-Function module to a Z-Exit function module having the very same interface. Only the frame function module is called in the ZX-include.
Implement the ZX-include once and for all.
Create Z-Exit function groups for the highest hierarchical level that employs the User-Exit

An example for a hierarchy of Z-Exit function modules is given below:

Frame: ZEXIT_SAPLVEDA_001
Country specific: ZEXIT_SAPLVEDA_001_CH
Country & Customer specific: ZEXIT_SAPLVEDA_001_CH_SHOP

If I need to change the User-Exit for inbound ORDERS IDocs intended for our Lindt Shops I immediately know that I have to change function module ZEXIT_SAPLVEDA_001_CH_SHOP. Thus, based on the requirements (SD-EDI User-Exit & Lindt Shops) I can deduce the affected Z-Exit function module.

Is there another advantage of replacing the coding in the ZX-includes with the call to the frame Z-Exit function module?

Yes, there is.

The Z-Exit function modules enable you to test the User-Exit independent of the entire process / transaction !!!

If you are already working on SAP releases >= 6.20 you can define ABAP Unit Tests for each Z-Exit function module. Having assigned all User-Exit related repository objects (ZX-includes and Z-Exit function groups) into a single package you can then use the Code Inspector (transaction SCI) to easily test all your User-Exits at once:

Define an object set containing this package
Define a check variant executing all dynamic tests (ABAP Unit)
Run an inspection with object set and check variant created before

Finally, if you intend to get rid of obsolete User-Exits and revert back to the SAP standard processes a package like ZCMOD will give you a headstart for your project.

Conclusion

Function Module-Exits (CMOD / SMOD) can be organized by simple means into a useful structure thereby achieving major goals like

Easy Maintenance
High Transparency
Process-Independent Testing

and at the same time avoiding dangerous liaisons by separating concerns into completely independent structural components.

Addendum

The topic of this blog has been continued in:

Dangerous Liaisons in User-Exits - Revisited

Anatomy of Finding an Hitherto Unknown Solution

Uwe Schieferstein — Wed, 22 Oct 2008 01:37:00 GMT

Introduction

In thread deactivate 'APPROVE' button in the ALV in RCATS_APPROVE_ACTIVITIES. it has been asked how to inactivate an ALV toolbar function within a CATS approval transaction. Having done little work on CATS and none on CATS approval I nevertheless was able to provide the specific solution.

In the following sections I describe my strategy how I found this solution based on my experience and combined with some Learning-By-Doing. Perhaps these insights may be useful for others to improve their solution finding strategies as well.

Background

About three years ago I developed a report for a customer where CATS data needed to be collected, evaluated and aggregated and then used to update cost objects in assessment cycles (transaction KSU2). During this development I became acquainted quite well with class CL_DBSEL_CATS and its BAdI enhancement (see CONSTRUCTOR method):

Following this customer report development I worked for about six months in a localization project for an Add-On of RE-FX (which was one of the best ABAP-OO training I ever had experienced; see Understanding ABAP Objects). In this project I came across an ALV based approval report for rental contracts which I assumed should be somehow similar to the CATS approval report. (see below).

Finally, about half a year ago I answered a question related to BAdI CATS_REPORTING (see Select-options in CATS_DA using BAdI).

The Problem

Below you see the ALV list with the approval toolbar function that should be inactivated (report RCATS_APPROVE_ACTIVITIES).

Thus, the problem can be split into two parts:

Trivial aspect: Inactivate toolbar function of ALV grid
Non-trivial aspect: How to achieve this in the context of CATS approval?

My Suspicion

My first idea was that the non-trivial aspect of this problem might be solved by using BAdI CATS_REPORTING (interface IF_EX_CATS_REPORTING).

The solution for the trivial aspect has been described in detail already many times, e.g.:

BCALV_GRID_05
Disable Button

The Solution

I created an implementation for BAdI CATS_REPORTING with the implementing class ZCL_IM_US_SDN_CATS_REPORTING. In order to manipulate the ALV toolbar I added the event handler method HANDLE_TOOLBAR which handles event TOOLBAR of CL_GUI_ALV_GRID.

(1) Searching for a Suitable Interface Method
Looking at the interface IF_EX_CATS_REPORTING its method IF_EX_CATS_REPORTING~BEFORE_DISPLAY_APPR immediately caught my attention. Based on its description (Arbeitszeit & Reise Genehmigung vor der Anzeige am Schirm = Working Times & Trip Approval before display on screen) I was convinced having found the right method. The IMPORTING parameter IM_ALV_GRID granted me access to the grid instance used for the approval list.

(2.a) Method Implementation: 1st Try

The first try-out was based on the assumption that I was responsible for both making the toolbar interactive and setting an event handler.

Below you see the first implementation I tried...

...which resulted in a short-dump when I executed the report. Apparently the ALV toolbar instance had not been instantiated yet when I called method SET_TOOLBAR_INTERACTIVE of the grid instance.

(2.b) Method Implementation: 2nd Try

In a silly attempt I tried to catch the exception which - of course - failed because CL_GUI_ALV_GRID does not raise class-based exceptions at its public interface.

(I also tried to replace method BEFORE_DISPLAY_APPR with BEFORE_DISPLAY yet the report never stopped at the break-point meaning that this method was not called during report execution.)

Thus, my assumption on which this coding was based on appeared to be wrong and needed to be refined.

(2.c) Method Implementation: 3rd Try

I modified my assumption that perhaps the standard report would take care of making the toolbar interactive. In this case I would only need to set the event handler method.

Below you see the third implementation I tried...

...and it worked!

The report execution stopped at the break-point in the event handler method. Looking through the entries in E_OBJECT->MT_TOOLBAR it was obvious that function 'CX_APPROVE' was the one that should be deactivated.

A quick look at the data definitions of report RCATS_APPROVE_ACTIVITIES showed that the grid instance was based on class CL_GRID_APPROVAL_ACTEXP which contains the function codes as public constants. The final version of the HANDLE_TOOLBAR implementation is shown below.

And that is how the final result looks like.

Summary

In this weblog I have tried to explain one of the strategies that I apply to find a hitherto unknown solution to a new problem. This scientific approach consists of combining experience with formulating working hypotheses. These hypotheses are tested in a systematic manner.

My first hypothesis that BAdI CATS_REPORTING is involved in the solution proved to be correct whereas the second hypothesis (ALV event handling) required a few cycles of refinement.

Conclusion

The more you know about the domain of the problem the more systematic will be your approach towards the problem. At a certain level of experience this proceeding will lead you almost inevitably to the solution.