Skip to Content

Ok. I admit, I chose Big Data only for you to click on my blog post… 😉

This article is not really about Big Data in its origin meaning. But the idea I would like to present to you has to do with a lot of data and how to deal with it.

View Maintenance SM30

I bet you know transaction SM30 for maintaining data with the generated maintenance view for a view or table. This technique is used all around the SAP system. Most of the customizing is done this way.

The generated maintenance views have a lot of advantages but also some disadvantages. One of the annoying things is that it is really really hard to have an overview if there are a lot of entries in the view. Of course you can restrict the data but it’s not really user friendly.

Navigation Enhancement

I thought about how to better deal with a large number of table entries without being upset for finding the right data. I remembered that there is one very special GUI tree class where you can display table data in an hierarchic tree: CL_GUI_ALV_TREE_SIMPLE

The idea is to display the data of the view in this control and navigate with the help of the tree structure.

For demonstration I created a sample table with lots of key fields:

You can change the hierarchy:

by dragging and clicking the fields in any order you wish:

Which gives you a different view on the data:

The navigation determines the current hierarchy and fills the “select statement” up to the clicked field (node). The selection will be passed to function module VIEW_MAINTENANCE_CALL to display the data.

Implementation

The navigation addon roughly works like this:

  • create a data reference on base of the given view/ table
  • get the data via function module VIEW_GET_DATA.
  • Call function module VIEW_GET_DDIC_INFO to get technical information about the view which we need later on
  • create a docker
  • create the CL_GUI_ALV_TREE_SIMPLE with the read data
    • define the hierarchy by the key fields of the view/ table
    • define the grouplevel icons which are basically needed to displaying the current hierarchy level
  • call VIEW_MAINTENANCE_CALL to display the data via “SM30”

Conclusion

I like improving old fashioned things. I think this is a good example that it is worth thinking about improvement wherever you are.

The Navigation is not perfect but in my opinion it makes data navigation much easier. Plus: the dynamic cusomtization of the hierarchy offers a solution to lots of different requirements.

The Navigation can be used with a lot of simple maintenance views. There are limitations and there will be errors I think. But it’s a big advantage if you can use an 80% solution to improve many different things with nearly no effort.

Issues

There are some issues to be solved…

What hiarcharchy level is it?

One thing that is not nice with the navigation tree is that it only shows the data of the current level (“1000”) but not the information itself (e. g. “sales organization”). The easiest way to solve this issue is to define the grouplevel layout. It’s a pity that this only allows to define an icon but no additional text… But via the icon definition I can pass a quickinfo text as additional information:

If you set the display of quickinfo to “immediately” in the SAPGUI settings, this is quite handy.

The first try was to copy the complete class to only change the setup of the nodes in private method SET_NODES. I did not find another way to manipulate the tree nodes afterwards.

Calling all stations

A yet unsolved issue is that with every navigation click in the tree the SM30 is called again and again (CALL SCREEN). This has the likeable effect that you can navigate back in the selection. But actually this is not what I want. At least the call stack is limited to about 50 calls.

I did not find a way to just update the data in the view using DBA_SELLIST or something like that.

abapGit

Here is the link to Github: https://github.com/tricktresor/blog

To report this post you need to login first.

2 Comments

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

  1. Enno Wulff Post author

    After some research, a friend of mine found the solution to reset the call stack of CALL FUNCTION ‘VIEW_MAINTENENANCE_CALL’.

    This is how it works:

    I install a foreign handler of the NODE_DOUBLE_CLICK (and ITEM_DOUBLE_CLICK). this external handler does not directly react to the double click but raises an event that will end the VIEW_MAINTENANCE_CALL. In this restart  we are back in the navigation programm and can call the view again.

    Exception Class

    the used exception class inherits from CX_NO_CHECK. This is somehow important. I don’t know why.

    CLASS lcx_restart DEFINITION INHERITING FROM cx_no_check.
      PUBLIC SECTION.
        DATA grouplevel TYPE lvc_fname.
        DATA index_outtab TYPE lvc_index.
        METHODS constructor
          IMPORTING
            grouplevel   TYPE lvc_fname
            index_outtab TYPE lvc_index.
    ENDCLASS.
    
    CLASS lcx_restart IMPLEMENTATION.
      METHOD  constructor.
        CALL METHOD super->constructor
          EXPORTING
            textid   = textid
            previous = previous.
        me->index_outtab = index_outtab .
        me->grouplevel = grouplevel .
      ENDMETHOD.
    ENDCLASS.

    Helper Class

    The external helper class is needed to capture the double click of the tree:

    CLASS lcl_helper IMPLEMENTATION.
      METHOD handle_item_double_click.
        handle_node_double_click(
          grouplevel   = grouplevel
          index_outtab = index_outtab ).
      ENDMETHOD.
    
      METHOD handle_node_double_click.
    
        RAISE EXCEPTION TYPE lcx_restart
          EXPORTING
            grouplevel   = grouplevel
            index_outtab = index_outtab.
      ENDMETHOD.
    
      METHOD install_handler.
        tree = i_tree.
        SET HANDLER handle_node_double_click FOR tree.
        SET HANDLER handle_item_double_click FOR tree.
      ENDMETHOD.
    ENDCLASS.

    Register Events

    The registration of the events still can be done in the navigation program (Method REGISTER_EVENTS). But the handlers need to be installed in the external class:

     METHOD register_events.
    
        lcl_helper=>install_handler( mo_tree ).
    
        mo_tree->set_registered_events( VALUE #(
              "Used here for applying current data selection
              ( eventid = cl_gui_column_tree=>eventid_node_double_click )
              ( eventid = cl_gui_column_tree=>eventid_item_double_click )
              "Important! If not registered nodes will not expand ->No data
              ( eventid = cl_gui_column_tree=>eventid_expand_no_children ) ) ) .
    
      ENDMETHOD.             

    View Maintenenance Call

    At least the main location of the trick ist in the method VIEW_MAINTENANCE_CALL:

      METHOD view_maintenance_call.
        TRY.
            CALL FUNCTION 'VIEW_MAINTENANCE_CALL'
              EXPORTING
                action      = 'S'
                view_name   = ms_tvdir-tabname
              TABLES
                dba_sellist = it_sellist
              EXCEPTIONS
                OTHERS      = 15.
          CATCH lcx_restart INTO DATA(restart).
            handle_selection( EXPORTING
              grouplevel   = restart->grouplevel
              index_outtab = restart->index_outtab ).
        ENDTRY.
      ENDMETHOD.

    I call the maintenance dialog and capture the exception LCX_HELPER which was raised within the dialog with the needed parameters GROUPLEVEL and INDEX_OUTTAB.

    In this case we simply start the maintenance view again with the apropriate navigation index.

    Voila.

    it works.

    Code updated on github.

     

    (0) 

Leave a Reply