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.

Key Concept

One issue with SAP HANA is that unnecessary data is sometimes pulled from the database when using SAP HANA calculation views by using the old-fashioned ABAP approach of referencing the active data DataStore object (DSO) table such as /BIC/A… tables. In the SAP HANA environment, this should not be done to avoid problems with SAP HANA or SAP BW authorizations. SAP recommends using external SAP HANA views that can be activated on a standard DSO via the Administrator Workbench to avoid these problems. Individual activation on several hundred DSOs after migration to SAP HANA is time-consuming. You can implement an automation to the SAP HANA views to cut down time and project costs.

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 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 (bolded) 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 " InfoArea 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

Joerg Boeke

Joerg Boeke is an SAP NetWeaver BW solution architect and senior consultant working with BIAnalyst GmbH & Co.KG, with 19 years experience in SAP NetWeaver BW, having worked on it since SAP BW 1.2A. He offers significant expertise in the SAP NetWeaver BW reporting area, including design, data integration, data visualization, performance optimization, and the cleanup of existing SAP NetWeaver BW systems. He is the author of SAP BW 7.x Reporting - Visualize your data. You may contact the author at Joerg.boeke@bianalyst.de. If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.