ALV Grids, Repors and a common Data Model

I recently had to program a simple monitor doing quality checks on outbound deliveries.

Basically the user should be able to scan a delivery using a Dynpro Input mask. Then an ALV Grid would Show all the LIPS Positions and he could scan Materials by EAN to confirm that the quality of the position is ok.


Basically that is what i came up with:
 


Since I do not program Module Pools every day one tricky part was to have a clean data Model of the delivery we just work with. You can see that there are manipulating Inputs in the Dynpro as well as in the ALV toolbar, which can be used.

The manipulation of ALV Data is very well protected and always problematic. Also I consider using globals problematic whenever a program manipulates more than one data item(e.g. the delivery), since there will be problems with clean reloads of the next item.


I was not able to split the Controller from the view for the ALV composes both in our framework, but I wanted to have a common data model for both the module pool and the ALV Grid. So in he end I came up with this:

Its kind of M(V&C).  All the Data Manipulation is done by Methods of the Model Class itself to minimize  manipulation overwriting. The Model will lock itself once all QS Positions are confirmed, and needs an explicit reset to be opened again.

The only problem is, that the ALV is embedded in the Dynpro. So whenever controls of the ALV are clicked, I can manipulate the Data Model cleanly (by reference). Afterwards I need to render the ALV again. Simple refresh Grid is not enough, since the ALV is inside an Container. So I need to get into the PBO of the report, which I only managed by calling  CALL METHOD CL_GUI_CFW=>SET_NEW_OK_CODE (any better solutions are welcome as comments J ) ALV should refresh itself if you use it right, not like i did it at the start.

ALV Tree Refresh (Delete all Nodes) - The Node Key Problem

Recently i stumbled across a problem in the ALV Tree. When you refresh the Tree you are supposed to delete all nodes

CALL METHOD REF_TREE->DELETE_ALL_NODES.

and add the new Nodes after. The problem here is, that the Tree implementation does not reset the  Node Key Counter. So when you had 248 Elements before the new Tree will start at Key 249(-1?).

The thing is, i wanted to have the same UI after the refresh, meaning all the expanded Nodes should be expanded again. You can read expanded Nodes with REF_TREE->GET_EXPANDED_NODES but it will only give you a list of Keys, which are pretty worthless after the Refresh if you dont want to do complicated calculations, which might fail due to complexity.

You can later Expand the Nodes in the new tree with REF_TREE->EXPAND_NODES. But now we need a connection between the old node keys and the new ones.

Given that you have an itab it_data with unique keys that builds up the tree ist is possible by using that table and an extra itab l_it_expanded with the same structure that holds the expanded data lines instead of only the node keys.

1. First you read all the expanded nodes GET_EXPANDED_NODES 
2. Then you read the lines of your data structure into it_expanded using the node keys
• You need to save the Node Keys of the Tree in the it_data structure when you build it, so you can now find the corresponding line
• The mt_outtab of the tree would also work, but its protected in the class and i dont know how to access it. Comment if you know how
3. You do your refresh now
• Your it_data contains the new data and the new nodekeys now. 
• The l_it_expanded contains the old expanded data with the worthless node keys
4. You can now read the new data itab using the real key tuple of your it_expanded
5. Because you have the node keys saved inside the it_data after the read you kann append to a node key table to add all expanded
• Also you are able to react on changes like missing lines 
6. You can now use EXPAND_NODES with you node key table.

here is a code sample how i worked it out. It might be more difficult to read since we are using a framework between ALV Tree and our code.

      "Tabelle für Expandierte Knoten
      DATA: L_WA_OUTLINEOLD TYPE TP_T_TREE_TAB.

........

Inside a function for e.g. Text updates

   "Speichern der Expandierten Knoten für Refresh
          CLEAR L_WA_OUTLINEOLD.
          PERFORM CUST_TREE_SAVE_EXPANDED CHANGING L_WA_OUTLINEOLD.

          "Texte über Lagernummer ermitteln
          PERFORM CUST_GET_TXTS_FOR_TRANSPORT USING C_WA_TREE_TAB-TKNUM.

          "LayoutRefresh und Laden der Expandierten Knoten
          PERFORM STD_REFRESH_SELECTION.
          PERFORM CUST_TREE_EXPAND_SAVED_NODES USING L_WA_OUTLINEOLD.

The important functions here are:

*&---------------------------------------------------------------------*
*&      Form  CUST_TREE_SAVE_EXPANDED
*&---------------------------------------------------------------------*
*       Ausgeklappte Knoten für den Refresh speichern
*       Das Problem ist, dass ein Refresh alle Knoten löscht und neu
*       anlegt aber die Schlüssel der Knoten einfach fortzählt.
*       Deshalb sind die gespeicherten Schlüssel unbrauchbar und
*       eine Verbindung muss über die Wertetupel des eigentlichen
*       Tabelleninhalte geschaffen werden um die Zeilen nach dem
*       neuaufbau wieder zu finden.
*----------------------------------------------------------------------*
*      <--C_IT_OUTLINEOLD  Tabelle mit den Realen ausgeklappten zeilen
*----------------------------------------------------------------------*
FORM CUST_TREE_SAVE_EXPANDED
          CHANGING C_IT_OUTLINEOLD TYPE TP_T_TREE_TAB.

  DATA:       L_IT_NODES      TYPE LVC_T_NKEY,
              L_WA_NODE       TYPE LVC_NKEY,
              L_WA_OUTLINEOLD TYPE TP_TREE_TAB.

  "Expandierte Knoten lesen
  CALL METHOD REF_TREE->GET_EXPANDED_NODES
    CHANGING
      CT_EXPANDED_NODES = L_IT_NODES
    EXCEPTIONS
      CNTL_SYSTEM_ERROR = 1
      DP_ERROR          = 2
      FAILED            = 3
      OTHERS            = 4.
  IF SY-SUBRC <> 0.
    MESSAGE ID SY-MSGID TYPE 'S' NUMBER SY-MSGNO
                       WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4
                         DISPLAY LIKE SY-MSGTY.
  ENDIF.

  "Knoten in Inbhaltstabelle Übersetzen
  LOOP AT L_IT_NODES INTO L_WA_NODE.
    REF_TREE->GET_OUTTAB_LINE(
      EXPORTING
        I_NODE_KEY     =   L_WA_NODE  " node key
      IMPORTING
        E_OUTTAB_LINE  = L_WA_OUTLINEOLD
      EXCEPTIONS
        NODE_NOT_FOUND = 1
        OTHERS         = 2
    ).

    IF SY-SUBRC <> 0.
      MESSAGE ID SY-MSGID TYPE 'S' NUMBER SY-MSGNO
                 WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4
                 DISPLAY LIKE SY-MSGTY.
    ENDIF.

    "Durch die Inhaltstabelle mit Wertetupeln wird der Bezug zu den
    "neuen Knoten hergestellt
    APPEND L_WA_OUTLINEOLD TO C_IT_OUTLINEOLD.

  ENDLOOP.


ENDFORM.                    " CUST_TREE_SAVE_EXPANDED
*&---------------------------------------------------------------------*
*&      Form  CUST_TREE_EXPAND_SAVED_NODES
*&---------------------------------------------------------------------*
*       Ausklappen der gespeicherten Tree Zeilen. Ausfühliche besch-
*       reibung des Problem unter CUST_TREE_SAVE_EXPANDED.
*----------------------------------------------------------------------*
*      -->F_IT_OUTLINEOLD  Zeilen zum Ausklappen
*----------------------------------------------------------------------*
FORM CUST_TREE_EXPAND_SAVED_NODES
              USING    F_IT_OUTLINEOLD TYPE TP_T_TREE_TAB.


  DATA:       L_IT_NODES      TYPE LVC_T_NKEY,
              L_WA_NODE       TYPE LVC_NKEY,
              L_WA_OUTLINEOLD TYPE TP_TREE_TAB,
              L_WA_TREETABNEW TYPE TP_TREE_TAB.

  "Inhaltstabelle lesen und die neuen entsprechenden Knoten ausklappen
  LOOP AT F_IT_OUTLINEOLD INTO L_WA_OUTLINEOLD.

    READ TABLE  IT_TREE_TAB
                INTO L_WA_TREETABNEW
                WITH KEY  TKNUM = L_WA_OUTLINEOLD-TKNUM
                          VENUM = L_WA_OUTLINEOLD-VENUM
                          EXIDV = L_WA_OUTLINEOLD-EXIDV
                          LINETYPE = L_WA_OUTLINEOLD-LINETYPE.

    IF SY-SUBRC = 0.
      APPEND L_WA_TREETABNEW-NODE_KEY TO L_IT_NODES.
    ENDIF.

  ENDLOOP.

  CALL METHOD REF_TREE->EXPAND_NODES
    EXPORTING
      IT_NODE_KEY             = L_IT_NODES
    EXCEPTIONS
      FAILED                  = 1
      CNTL_SYSTEM_ERROR       = 2
      ERROR_IN_NODE_KEY_TABLE = 3
      DP_ERROR                = 4
      NODE_NOT_FOUND          = 5
      OTHERS                  = 6.
  IF SY-SUBRC <> 0.
    MESSAGE ID SY-MSGID TYPE 'S' NUMBER SY-MSGNO
                   WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4
                         DISPLAY LIKE SY-MSGTY.
  ENDIF.

  "Update der Darstellung
  REF_TREE->FRONTEND_UPDATE( ).

ENDFORM.                    " CUST_TREE_EXPAND_SAVED_NODES

Feel free to comment, especially for better solutions for this problem. I need to add, since the framework is in between, we are not able to use other refresh functions, but i've heard that there is a different solution where you don't use DELETE_ALL_NODES but i think any solutions using the keys might be faulty due to possible changes in the structure resulting in wrong node keys for a line.

Dynamic Method Calls and Parameters Tables

I recently needed to call a method dynamically where the name was stored in a table. The call itself is pretty easy. Define a variable to store the name and just use the value in the call method.

You cant simply add a string lo_objekt->(lv_string_method) cause the compiler does not know what its gonna be at runtime and prevents it.

However a CALL METHOD takes a char format anyway and thus is able to work with it.

DATA: LV_METHOD TYPE STRING,
      LO_OBJECT TYPE REF TO YCL_SYSCPY_AUTOMATION.

CREATE OBJECT LO_OBJECT.

LV_METHOD = 'ENTF_SDRUCK_NACHSCHUB'.

CALL METHOD LO_OBJECT->(LV_METHOD).

If you want to pass parameters dynamically, this is also possible by filling a local parameter table.

DATA: LV_METHOD TYPE STRING,
      LO_OBJECT TYPE REF TO YCL_SYSCPY_AUTOMATION,
      LD_STRING TYPE STRING,
      LS_PARAM TYPE ABAP_PARMBIND,
      LT_PARAMS TYPE ABAP_PARMBIND_TAB.

CREATE OBJECT LO_OBJECT.

LV_METHOD = 'ENTF_SDRUCK_NACHSCHUB'.

LS_PARAM-NAME = 'IV_PATTERN'.
LS_PARAM-KIND = 'E'. "Exporting
LD_STRING = '*'.
GET REFERENCE OF LD_STRING INTO LS_PARAM-VALUE.
INSERT LS_PARAM INTO TABLE LT_PARAMS.

CALL METHOD LO_OBJECT->(LV_METHOD)
  PARAMETER-TABLE
  LT_PARAMS.

See that the parambind takes references to data as value. So you have to get that reference from any given variable.

To consider are the CX_SY_DYN_CALL_ILLEGAL_METHOD and CX_SY_DYN_CALL_PARAM_NOT_FOUND Exceptions when the Methodname or Params do not match.

So you might end up like this:

DATA: LV_METHOD TYPE STRING,
      LO_OBJECT TYPE REF TO YCL_SYSCPY_AUTOMATION,
      LD_STRING TYPE STRING,
      LS_PARAM TYPE ABAP_PARMBIND,
      LT_PARAMS TYPE ABAP_PARMBIND_TAB,
      LO_EX_METH TYPE REF TO CX_SY_DYN_CALL_ILLEGAL_METHOD,
      LO_EX_PARAM TYPE REF TO CX_SY_DYN_CALL_PARAM_NOT_FOUND.

CREATE OBJECT LO_OBJECT.

LV_METHOD = 'YIF_SYSCPY_AUTO_METHODS~ENTF_SDRUCK_NACHSCHUB'.

LS_PARAM-NAME = 'IV_PATTERN'.
LS_PARAM-KIND = 'E'. "Exporting
LD_STRING = '*'.
GET REFERENCE OF LD_STRING INTO LS_PARAM-VALUE.
INSERT LS_PARAM INTO TABLE LT_PARAMS.

TRY.
    CALL METHOD LO_OBJECT->(LV_METHOD)
      PARAMETER-TABLE
      LT_PARAMS.

  CATCH CX_SY_DYN_CALL_ILLEGAL_METHOD  INTO LO_EX_METH.
    MESSAGE E000(YI) WITH TEXT-002
                          LO_EX_METH->METHODNAME .

  CATCH CX_SY_DYN_CALL_PARAM_NOT_FOUND INTO LO_EX_PARAM.
    MESSAGE E000(YI) WITH TEXT-001
                          LO_EX_PARAM->PARAMETER
                          LO_EX_PARAM->METHODNAME .
ENDTRY.