GRC
HR
SCM
CRM
BI
Expand +


Article

 

How to Automate Generation of External SAP HANA Views to Save Time and Costs

by Joerg Boeke

October 2, 2017

Get a detailed guide (including SAP HANA ABAP code snippets) for speeding up your SAP HANA calculation views based on a DataStore object (DSO) by using external SAP HANA views based on classic DSOs. Instead of manually generating the external SAP HANA DSO views via the Administrator Workbench, the program helps you to select groups of DSOs to speed up implementation time.

Running an SAP HANA database underneath your SAP BW system helps a lot in terms of performance. Most users migrated to the SAP HANA database to enjoy the speed for data loads as well as reporting performance. Many users, however, are not aware that besides performance, SAP HANA offers a lot more (for example, working with SAP HANA optimized models via calculation views).

Using that technology suppresses the need for keeping data in persistency layers instead of calculating new key figures and characteristics on the fly. Following this approach in my current project, we save millions of records by not adding more and more Advanced DataStore object (ADSO) layers. On the other hand, you can drop the need for increased SAP HANA licensing.

Within those new SAP HANA models, you can access existing InfoProviders (e.g., DataStore Objects [DSOs]) either by table name or via external SAP HANA views.

SAP HANA views can be generated manually by changing each individual DSO by right-clicking the DSO and selecting the change option. Then check the External SAP HANA view for reporting check box as shown in Figure 1 and reactivate the DSO by selecting the activation icon  from the SAP menu.


Figure 1
External SAP HANA view settings in DSO settings

After activation, you can find the generated SAP HANA view via transaction code RS2HANA_ADMIN (Figure 2) or directly in SAP HANA studio or Eclipse to be used in fast data access via calculation views.


Figure 2
Displaying an external SAP HANA view in transaction RS2HANA_ADMIN

Such views help you to create scenarios using data modeled by SAP BW tools in combination with data models created with the help of SAP HANA studio (which is referred to as a mixed scenario). This view is similar to using the old-fashioned DSO (not an ADSO) that was created before SAP HANA as a data source in SAP HANA calculation views. To feed Eclipse, SAP HANA studio generated data flows using calculation views to provide data for a Composite InfoProvider.

These external views support use of Eclipse or SAP HANA studio instead of accessing the active data table of any DSO object (in my example, a classic DSO named DSO_O22), which is what a lot of SAP HANA users do when selecting tables in Eclipse projections as illustrated in Figure 3.


Figure 3
Eclipse access to DSO table of standard DSO

You access the external SAP HANA view to this DSO that you generated by the above steps via the Administrator Workbench by just adding a projection within Eclipse and using a plain DSO name. As you can see, SAP added the icon of a calculation view (calculator and table) ahead of the DSO name to show that you are using a calculation view instead the regular DSO object (Figure 4).


Figure 4
Eclipse access to an external SAP HANA view of a standard DSO

Another advantage of using external views instead of active data tables is the use of InfoObjects. Using the active data table (Figure 5) unveils the internal field names such as TCTTIMSTMP. You might need to map this technical fieldname to InfoObjects later on.  


Figure 5
Eclipse standard DSO table structure displaying field names

Selecting the external SAP HANA view instead allows you to work directly with the InfoObject names as well as textual information (Figure 6). Using the latter approach cuts down on unwanted and obsolete mapping in Composite Providers as well. Authorization is not bypassed because authorization can be replicated from within the Administrator Workbench to SAP HANA. (Authorization is not in scope for this article.)


Figure 6
Eclipse external SAP HANA view structure of a standard DSO displaying InfoObject names

Using such mixed scenario approaches can help you to speed up loads because data is not pushed to the application server first. SAP HANA handles the calculations directly on the database level.

The following basic objects are supported by external SAP HANA views:

  • CompositeProvider
  • InfoCube
  • DSO (covered in more detail in the section on automation)
  • InfoObject

Figure 7 demonstrates the mixed scenario approach. For the reporting user, the access of historic design via a MultiProvider and the underlying basic provider versus SAP HANA views are completely transparent. With the help of SAP HANA views you can combine new functionality with the old design in an easy way.


Figure 7
Mixed scenario data access by a standard InfoProvider or the newly designed SAP HANA views

During activation within SAP BW, SAP HANA views are published to SAP HANA to directly point to SAP BW tables and data within the SAP HANA database. Because such SAP HANA views are published from SAP BW to SAP HANA, it is not wise to modify views on the SAP HANA side by using Eclipse functionality. Every single change on an SAP BW InfoProvider causes an automated update to SAP HANA and any changes you made will be lost. So keep the advice “never change external SAP HANA views” as development law, even if you could modify views on the SAP HANA side. (I already had that experience with a developer losing his enhancements.)

It is important to know that views generated by SAP BW can be consumed directly in reporting tools such as Design Studio, Analysis Office, and SAP Lumira. Analytical authorization will be aligned with SAP HANA directly during the activation phase. If you delete or transport SAP BW InfoProviders that have this external view enabled, the view will be deleted or transported automatically.

Automated Generation of External SAP HANA Views

As just described, it’s easy to generate views by pure SAP system functionality, changing and reactivating the DSO objects to generate external reusable SAP HANA views. However, think of your actual SAP BW environment. How many classic DSOs do you have?

A simple way to determine the number of DSOs is to use SAP table RSDSODSO and count the object entries where OBJVERS = ‘A’ (active DSOs). At my actual customer site, we have approximately 850 DSOs.

If you like to waste time, you could change and activate each DSO one by one. Let’s do a simple calculation for how long that would take.

Depending on CPU and memory, the actual time for having a DSO activated by SAP system functionality takes (for the current customer) about 25 seconds. Now you have to add the time for spotting the DSO within the Administrator Workbench plus the effort of manually setting the change mode, activating the external SAP HANA flag, and saving the changes. Let’s assume this is two minutes (120 seconds) per DSO. The total time for manual maintenance would be 33 hours (see the calculation table shown in Figure 8) or about three consultant or employee days.


Figure 8
Calculation table for manual work time

So I could decide not to share my code and be assigned as a consultant to your project. As a frequent reader of content published on SAP Experts, however, you know this is not my style. I prefer to share my ideas for cutting down implementation costs.

Using my code snippet, activation of all external views is a matter of approximately two hours for a batch job (depending on memory and CPU performance).

In my actual environment at the customer site, we split the activation into 100 DSO chunks (to keep memory exhaustion at a minimal level). That is because SAP BW seems not to be able to activate 850 DSOs in a row because of the extensive memory load and short time sequence. In normal activation you might activate one DSO, then create the next, activate it, and so on. SAP system memory would be allocated. Running the program does not need that time gap as needed in manual activation because of the fast sequence of activation.

Your involvement to activate all views is just the time for copying and pasting my code and scheduling the job. While the job is running you can have a cup of coffee instead. Just create your report and add my coding that you find later in this article.

Run the report (Figure 9) via transaction code SE38 where you can select whether to create or drop individual SAP HANA views. As I said, the functionality is exactly the same as doing it manually step by step on each individual DSO. The menu (Figure 9) lets you decide whether to create the SAP HANA view on an individual DSO, on multiple DSOs via InfoArea selection, or via a DSO name including wildcards use, such as all DSOs that start with name prefix ZA*.


Figure 9
Input/dialog mask of a provided program

Try to test run it on a few DSOs and avoid stressing the wildcard for DSO names that are like a simple ‘*’.

The Test only option (default setting) does not change or generate any view but only displays the DSO objects selected via the upper options displayed in Figure 9. My experience is that you will get memory exhaustion at above 500 DSOs. The best approach is to specify your chunk of DSOs and do it in chunks of 300 to 400 DSOs by separating the activations via InfoAreas. It all depends on the individual memory of your server. In small systems, the number of DSOs to create SAP HANA views may be smaller. In better (more memory) systems, it might work to schedule 800 DSOs at once.

Figure 10 shows the code. The following code example is separated by comment areas to explain the steps within the program. Feel free to leave the highlighted (yellow) comment lines when copying and pasting the code or just remove them via the copying process. I suggest leaving all other comment lines in place for tiny code explanations.

Report Coding

*&---------------------------------------------------------------------*
*& Report ZBW_GEN_DSO_HANA_VIEW
*&---------------------------------------------------------------------*
*& automated generation for external SAP HANA view settings
*& (c) by Joerg Boeke  www.bianalyst.de

*& free to use for all readers of SAP Experts

*&

*& no legal warranties for this code, run at own risk
*&---------------------------------------------------------------------*
REPORT zbw_gen_dso_hana_view.

" DATA type declaration for the elements used in the report

" such as tables for InfoAreas and DSO intermediate storage (e.g., F4 help)
TYPES:
  BEGIN OF ls_iareas_s,
    infoarea TYPE rsinfoarea,
  END OF ls_iareas_s,

  BEGIN OF ls_dso_s,
    odsobject   TYPE rsdodsobject,
    infoarea    TYPE rsinfoarea,
    hanamodelfl TYPE  rsmhanamodel,
    counter     TYPE i,
  END OF ls_dso_s,

  BEGIN OF ls_msg_s,
    msgtyp    TYPE  symsgty, " Type of message
    infocube  TYPE rsinfocube,
    dimension TYPE  symsgv,  " Cube Dimension
    num_ids   TYPE  i,  " Number of deletable DIM ID'S
  END OF ls_msg_s.

DATA:
  lr_ref_salv    TYPE REF TO cl_salv_table,
  lr_funcs       TYPE REF TO cl_salv_functions_list,
  lr_sort_column TYPE REF TO cl_salv_sort, "column sort
  lr_columns     TYPE REF TO cl_salv_columns_table,
  lr_column      TYPE REF TO cl_salv_column_table,
  lr_sort        TYPE REF TO cl_salv_sorts, "ALV sorts
  lr_aggrs       TYPE REF TO cl_salv_aggregations,
  lr_disp_sett   TYPE REF TO cl_salv_display_settings,
  lv_count       TYPE i, " Counter oif objects
  lv_okcode      TYPE syucomm,
  lv_hana_view   TYPE rs_bool, " Hana Flag set for View Y/N
  lt_return      TYPE STANDARD TABLE OF ddshretval,
  ls_return      TYPE ddshretval,
  lt_message     TYPE STANDARD TABLE OF ls_msg_s,
  lt_iareas      TYPE STANDARD TABLE OF ls_iareas_s,
  lt_dsos        TYPE STANDARD TABLE OF ls_dso_s,
  lt_rsdodso     TYPE STANDARD TABLE OF rsdodso,
  "SAP Objects in Form
  lr_odso        TYPE REF TO cl_rsd_odso,
  lt_msg         TYPE rs_t_msg, " Message table for return messages.
  lv_dummy.
"The next code lines generate the dialog when executing the program

" In the next few lines the dialog (check boxes and radio buttons) are being defined
SELECTION-SCREEN BEGIN OF BLOCK dso WITH FRAME TITLE TEXT-s01.
"Create HANA Views for DSO
PARAMETERS:
  p_crea RADIOBUTTON GROUP rad1 USER-COMMAND com MODIF ID m10 DEFAULT 'X', " Create HANA View
  p_del  RADIOBUTTON GROUP rad1 MODIF ID m20. " Delete HanaView

SELECTION-SCREEN ULINE.
PARAMETERS:
  p_iareas RADIOBUTTON GROUP rad2 USER-COMMAND com MODIF ID m30 DEFAULT 'X', " DSO'S by Application
  p_dsos   RADIOBUTTON GROUP rad2 MODIF ID m40, "  Single DSO
  p_all    RADIOBUTTON GROUP rad2 MODIF ID m50. "  ALL DSO's
SELECTION-SCREEN SKIP.

PARAMETERS:
  p_dso   TYPE rsdodsobject MODIF ID mds, " manual single DSO
  p_iarea TYPE rsinfoarea MODIF ID mia. " restrict to application area
SELECTION-SCREEN ULINE.

SELECTION-SCREEN SKIP.


SELECTION-SCREEN BEGIN OF BLOCK 
test WITH FRAME TITLE TEXT-s02.
PARAMETERS: p_test TYPE rs_bool DEFAULT rs_c_true MODIF ID m99.
SELECTION-SCREEN END OF BLOCK test.

SELECTION-SCREEN END OF BLOCK dso .

" The next initialization is for adding text in dialog.

" Due to the fact that I do not deliver the program as a transport, this is a very convenient way

" to deliver input parameter textual description in dialogs provided by pure SAP ABAP functionality

" Feel free to use this approach in your programs as well because by this approach you save time

" by bouncing between code and text element display in ABAP development

" In case the text for dialog is not appropriate for you, just change the descriptive text below


INITIALIZATION.
  %_p_crea_%_app_%-text   = 'Create HANA View for DSO'.
  %_p_del_%_app_%-text    = 'Delete HANA View for DSO'.
  %_p_iareas_%_app_%-text = 'DSO by Infoarea (Wildcard = *)'.
  %_p_dsos_%_app_%-text   = 'Single DSO (Wildcard = *'.
  %_p_all_%_app_%-text    = 'ALL DSOs'.
  %_p_dso_%_app_%-text    = 'Select DSO'.
  %_p_iarea_%_app_%-text  = 'Select Infoarea'.
  %_p_test_%_app_%-text   = 'Test only (X) NO modifikation'.

*--------------------------------------------------------------*
*Selection-Screen  turn on / off depending fields
*--------------------------------------------------------------*

" From this point on the declaration part of the program is done and the real execution starts

" The case screen-group1 part will toggle the dialog boxes depending whether you are selecting a DSO or InfoArea preselection

AT SELECTION-SCREEN.
  lv_okcode = sy-ucomm.

AT SELECTION-SCREEN OUTPUT.

* User clicks the checkbox 'restriction by Infoarea'
  IF NOT p_iareas IS INITIAL.
* Don't allow input for these fields

" DSO selection will be disabled
    LOOP AT SCREEN.
      CASE screen-group1.
        WHEN 'MDS'.
          screen-input = '0'.
          screen-output = '0'.
          screen-invisible = '1'.
          MODIFY SCREEN.
      ENDCASE.
    ENDLOOP.
  ENDIF.

  IF  NOT p_dsos IS INITIAL.
* Don't allow input for these fields

" InfoAarea selection will be disabled
    LOOP AT SCREEN.
      CASE screen-group1.
        WHEN 'MIA'.
          screen-input = '0'.
          screen-output = '0'.
          screen-invisible = '1'.
          MODIFY SCREEN.
      ENDCASE.
    ENDLOOP.
  ENDIF.

  IF  NOT p_all IS INITIAL.
* Don't allow input for these fields

" All individual selection will be disabled
    LOOP AT SCREEN.
      CASE screen-group1.
        WHEN 'MIA'.
          screen-input = '0'.
          screen-output = '0'.
          screen-invisible = '1'.
          MODIFY SCREEN.
      ENDCASE.
    ENDLOOP.

    LOOP AT SCREEN.
      CASE screen-group1.
        WHEN 'MDS'.
          screen-input = '0'.
          screen-output = '0'.
          screen-invisible = '1'.
          MODIFY SCREEN.
      ENDCASE.
    ENDLOOP.
  ENDIF.

*--------------------------------------------------------------*
*Selection-Screen on Value-Request Infoarea
*--------------------------------------------------------------*

" The next code lines will provide and populate the F4 help (drop-down)

" boxes for DSO selection as well as for InfoArea selection

  " For Infoareas

AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_iarea.
  REFRESH lt_iareas.


  SELECT infoarea FROM rsdarea INTO TABLE lt_iareas
        WHERE objvers = 'A'.

  IF sy-subrc = 0.

    CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'
      EXPORTING
        retfield        = 'MATNR'
        value_org       = 'S'
      TABLES
        value_tab       = lt_iareas
        return_tab      = lt_return
      EXCEPTIONS
        parameter_error = 1
        no_values_found = 2
        OTHERS          = 3.

    READ TABLE lt_return INTO ls_return INDEX 1.
    IF sy-subrc = 0.
      p_iarea = ls_return-fieldval.
    ENDIF.
  ENDIF.

*--------------------------------------------------------------*
*Selection-Screen on Value-Request DSO
*--------------------------------------------------------------*
  " for DSO’s

AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_dso.
  REFRESH lt_dsos.

  SELECT odsobject FROM rsdodso INTO TABLE lt_dsos
        WHERE objvers = 'A'.

  IF sy-subrc = 0.

    CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'
      EXPORTING
        retfield        = 'MATNR'
        value_org       = 'S'
      TABLES
        value_tab       = lt_dsos
        return_tab      lt_return
      EXCEPTIONS
        parameter_error = 1
        no_values_found = 2
        OTHERS          = 3.

    READ TABLE lt_return INTO ls_return INDEX 1.
    IF sy-subrc = 0.
      p_dso = ls_return-fieldval.
    ENDIF.
  ENDIF.


" From this point of the code, the real execution of the program starts

" In case you like to debug the program, a good idea is to put a breakpoint at line code

" (IF  p_crea = rs_c_true.)

******************************************************
**************Start Main Program**********************
******************************************************

START-OF-SELECTION.

  IF  p_crea = rs_c_true.
    lv_hana_view = rs_c_false.
  ELSE.
    lv_hana_view = rs_c_true.
  ENDIF.


  "only change single dso
  IF p_dsos IS NOT INITIAL.
    IF p_dso IS NOT INITIAL.
      REPLACE ALL OCCURRENCES OF '*' IN  p_dso WITH '%'.

      SELECT odsobject infoarea hanamodelfl FROM rsdodso INTO TABLE lt_dsos
          WHERE objvers = 'A'
          AND   odsobject LIKE p_dso
          AND   hanamodelfl = lv_hana_view.

    ELSE.
      CALL FUNCTION 'POPUP_TO_INFORM'
        EXPORTING
          titel = 'HANA Optimization for classic DSO'
          txt1  = 'Please select valid DSO name,'
          txt2  = 'or enter DSO name'.
    ENDIF.
  ENDIF.
  "change DSO's by Application
  IF p_iareas IS NOT INITIAL.
    REPLACE ALL OCCURRENCES OF '*' IN  p_iarea WITH '%'.

    IF p_iarea IS NOT INITIAL.
      SELECT odsobject infoarea hanamodelfl FROM rsdodso INTO TABLE lt_dsos
          WHERE objvers = 'A'
          AND   infoarea LIKE p_iarea
          AND   hanamodelfl = lv_hana_view.
    ELSE.
      CALL FUNCTION 'POPUP_TO_INFORM'
        EXPORTING
          titel = 'HANA Optimization for classic DSO'
          txt1  = 'Please select valid Infoarea name,'
          txt2  = 'or enter area name'.
    ENDIF.
  ENDIF.

  IF p_all IS NOT INITIAL.
    SELECT odsobject infoarea hanamodelfl FROM rsdodso INTO TABLE lt_dsos
    WHERE objvers = 'A'
    AND   hanamodelfl = lv_hana_view.
  ENDIF.

 

" The next perform call displays all found entries for a given selection in program dialog

" (Figure 9) via the ALV Grid table display

" In that display you can (via test mode) check how many and what DSO objects SAP HANA

" views will be generated in NON-test mode. If p_test ist flagged, only display will be provided

" and no modification will be done.

" In case you deselect the test mode, the generation of external SAP HANA views will be

" executed


  "Call Display routine
  IF  p_test IS NOT INITIAL.
    PERFORM me_display.

  ELSE.
    " Start modification

    IF lv_hana_view = rs_c_true.
      lv_hana_view = rs_c_false.
    ELSE.
      lv_hana_view = rs_c_true.
    ENDIF.

    " Modify ...TOGGLE.... all selected entries
    LOOP AT lt_dsos ASSIGNING FIELD-SYMBOL(<ls_dsos>). " Add Counter
      <ls_dsos>-hanamodelfl = lv_hana_view.
    ENDLOOP.

    "Change table settings for A and M version
    SELECT * FROM  rsdodso  INTO TABLE lt_rsdodso
      FOR ALL ENTRIES IN lt_dsos
      WHERE odsobject = lt_dsos-odsobject
      AND  objvers = 'A' or  objvers = 'M' ).

    LOOP AT lt_rsdodso ASSIGNING FIELD-SYMBOL
(<lt_rsdodso>). " Add Counter
      <lt_rsdodso>-hanamodelfl = lv_hana_view.
    ENDLOOP.

" This break point should be commented in a productive program

" In this code I leave it as it is to have the users stop before any changes occur

" In the modify (MODIFY rsdodso FROM TABLE lt_rsdodso.) command the original SAP table " storing the checkbox setting "  (Figure 1) will be modified as in doing it manually

" A activation will start in the next step

BREAK-POINT. " Last Stop before modification


    "modify SAP table
    MODIFY rsdodso FROM TABLE lt_rsdodso.
    COMMIT WORK.

    " Now we dont have a need for double entries for activation loop
    sort lt_rsdodso by odsobject objvers DESCENDING.
    Delete ADJACENT DUPLICATES FROM lt_rsdodso COMPARING odsobject. " only leave M version

" The next perform (PERFORM activate CHANGING lt_msg.) causes the real activation of

" SAP HANA external views by SAP class and method

" This execution depends on the number of selected DSO objects and may run several minutes

" In this step the SAP functionality called in a manual process as well will read the table

" (modified in the previous step) entry, activate the DSO concerning this new setting parameter,  " and generate the view
    "activate DSO concerning new settings
    IF lt_rsdodso IS NOT INITIAL.
      PERFORM activate CHANGING lt_msg.
    ENDIF.
" The display call will display all found entries for given selection in ALV Grid table display

" In that display you can see what DSO external views have been generated by this program

    "Display modified entries in ALV GRID
    PERFORM me_display.
  ENDIF.




*--------------------------Activate View---------

" The following code will (as in manual activation) activate the DSOs selected in the dialog of "  the program

FORM activate CHANGING c_t_msg  TYPE rs_t_msg.

  DATA: l_r_exception  TYPE REF TO cx_root.

  LOOP AT lt_rsdodso  ASSIGNING FIELD-SYMBOL(<lt_rsdodso>).
*   create object
    CALL METHOD cl_rsd_odso=>factory
      EXPORTING
        i_odsobject = <lt_rsdodso>-odsobject
      RECEIVING
        r_r_odso    = lr_odso
      EXCEPTIONS
        OTHERS      = 3.
    IF sy-subrc <> 0.
      MESSAGE e101(rsdodso) WITH <lt_rsdodso>-odsobject INTO lv_dummy.
*     Das ODS-Object &1 is not yet available
      CALL METHOD cl_rso_application_log=>add_message.
    ENDIF.

*   lock
    TRY.
        CALL METHOD lr_odso->prepare
          EXPORTING
            i_with_cto_check = rs_c_false.
      CATCH cx_root INTO l_r_exception.
        CALL METHOD cl_rso_application_log=>add_messages_of_exception(
            i_r_exception = l_r_exception ).
        EXIT.
    ENDTRY.

*   action
    CALL METHOD lr_odso->activate
      EXPORTING
        i_objvers          = rs_c_objvers-modified
        i_force_activation = rs_c_true
        i_with_cto         = rs_c_false.

*     dequeue
    CALL METHOD lr_odso->dequeue.
  ENDLOOP.

* log
  CALL METHOD cl_rso_application_log=>appl_log_save.
  CALL METHOD cl_rso_application_log=>appl_log_msg_read
    IMPORTING
      e_t_msg = c_t_msg.

ENDFORM.


" The display of a found DSO in reference to dialog settings will be prepared and displayed

" in this perform routine. The code used standard SAP functionality to display internal table " content dynamically

" This code snippet can be reused for all purposes (e.g., as method or function)

" Important here is the changing parameter ( CHANGING      t_table      = lt_dsos.)

" because the table sent to the method in my example (lt_dsos.) will force the display of

" whatever column with which the given table has been built

*&---------------------------------------------------------------------*
*&      Form  ME_display
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
FORM me_display.

  IF lt_dsos IS NOT INITIAL.

    LOOP AT lt_dsos ASSIGNING FIELD-SYMBOL(<ls_dsos>). " Add Counter
      <ls_dsos>-counter = 1.
    ENDLOOP.
    " Display internal table with results
    TRY.
        CALL METHOD cl_salv_table=>factory
          IMPORTING
            r_salv_table = lr_ref_salv
          CHANGING
            t_table      = lt_dsos.

        " Now we will aggregate data to total at end of ALV list
        lr_aggrs = lr_ref_salv->get_aggregations( ). "get aggregations
*   Add TOTAL for COLUMN num_ids

        CALL METHOD lr_aggrs->add_aggregation "add aggregation
          EXPORTING
            columnname  = 'COUNTER' "aggregation column name
            aggregation = if_salv_c_aggregation=>total. "aggregation type

*   Bring the total line to top
        CALL METHOD lr_ref_salv->get_sorts "get sorts
          RECEIVING
            value = lr_sort.

        "Functions
        lr_funcs = lr_ref_salv->get_functions( ).
        lr_funcs->set_all( ).

        "Display Settings
        lr_disp_sett = lr_ref_salv->get_display_settings( ).
        lr_disp_sett->set_striped_pattern( abap_true ).

        lr_columns = lr_ref_salv->get_columns( ).
        lr_columns->set_optimize( rs_c_true ).

        "Reformat Header to display own column header instead of field name
        lr_column ?= lr_columns->get_column( 'COUNTER' ).
        lr_column->set_long_text( 'number of DSO' ).


        CALL METHOD lr_sort->add_sort "add column sort
          EXPORTING
            columnname = 'INFOAREA' "sort column always keyfield
            sequence   = if_salv_c_sort=>sort_down
          RECEIVING
            value      = lr_sort_column.

        CALL METHOD lr_sort_column->set_subtotal "add subtotal
          EXPORTING
            value = if_salv_c_bool_sap=>true.

      CATCH cx_salv_msg .
      CATCH cx_salv_not_found .
      CATCH cx_salv_existing .
      CATCH cx_salv_data_error .
    ENDTRY.
    " Now display formatted ALV dta
    lr_ref_salv->display( ).
  ENDIF.
ENDFORM.                    "ME_display
Figure 10
ABAP code for automated generation of external SAP HANA views

An email has been sent to:





 

Joerg Boeke

Joerg Boeke (Joerg.boeke@bianalyst.de) is an SAP NetWeaver BW solution architect and senior consultant working at BIAnalyst GmbH & Co.KG. He has 19 years of experience in SAP NetWeaver BW, having worked on it since SAP BW 1.2A.



More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ