Generation limits of ABAP programs

While ABAP programmers do coding of report in ABAP before it runs it needs to be activated and generated. The activation basically means that all syntax checks takes place and active version of the report is stored. Then during generating phase a load version is created. The load version is actually the one which is executed when the report runs.

You may have already observed generating phase e.g. in case if you run new t-code which wasn’t run by anyone in the system yet there is a Compiling … message shown in system bar of SAP GUI. This happens usually after upgrades when some part of SAP standard code was overwritten by upgrade. Then ABAP code that was upgraded needs to be re-generated. To speed up this process and prevent users to see this message a job can be scheduled via t-code SGEN.

However there are some limits into which the ABAP report can run into during the generation. There are limits with regards to no of global variables, generic global field symbols, Components (of structures etc.), literals, classes, interfaces, events, methods, local Data and many more. Usually no custom ABAP reports are that big that could reach these limits. However really “large” ABAPs like generated ones e.g. from SAP BW transformations which may have even 10k lines and more these may run into these limits.

To evaluate whether some report doesn’t reach into the limits you can use standard ABAP report called BC_ABAP_GEN_LIMITS.

Pushing DTP execution to HANA DB

After migration to HANA DB one can observe a new setting on DTP screen. To be precise it is on header part of the DTP and it is called “SAP HANA execution” What it means is that in case it is checked then the DTP is executed directly in HANA DB. If it is NOT checked then the DTP is executed on ABAP AS and not directly in HANA DB. That means that the execution is not pushed to DB and there is no potential performance gains. So it simple runs like in BW on any other DB.

Naturally there are some conditions that must be met to enable this. Transformation associated with the DTP must not have any with ABAP routines because these can’t be executed by HANA but just by ABAP AS. Therefore if you have any ABAP routines that jus manipulates with the result of field like below one:

RESULT = SOURCE_FIELDS-/BIC/S_SJDRF5J+3.

Just replace it with Rule Type Formula like:

SHIFT_LEFT( 3, /BIC/S_SJDRF5J )

Now imagine we got rid of all ABAP routines in the transformation and we would like to enable the “SAP HANA execution” flag. However attempt to do so gets us an error messages like:

HANA Execution: "No extraction using API" not supported

HANA Execution: Error handling not supported

To solve 1^st error we need to enable another flag on the DTP. It is located at Extraction tab of the DTP and it is called “No Extraction Using API” (TREX_EXT_AGGREGATE). What it means is that even the DTP execution can be pushed to HANA it would be a case and it still will be executed at ABAP AS level. Obliviously we would like to push the DTP to HANA. So in case we switch to EDIT mode of the DTP and we attempt to thick off the settings. 

The second error message is related to error handling. This setting is available on Update tab of the DTP. And we need to set it to position “Cancel request, Do not Track records, No update”.

Once we hit “Check availability” button located next to first flag “SAP HANA Execution” (see 1st picture above) then finally the DTP will be executed by HANA as we got info message “DTP compatible with 'SAP HANA Execution'. You may notice I briefly touched this topic at my other post called “Changes in BW system after HANA migration”.

BEx QD: Hide Repeated Key Values

One of global settings valid for all BEx query is related to repeated values. It determines whether identical key values are to be displayed more than once in the query. The setting is called and it is located on Query properties (accessible on right pane of Query Designer):

The settings usually always worked. Reason why I’m saying “usually always” is that some of new front end tools like Analysis for Office (AfO) do not consider the settings. I came to know this by trying it out in AfO. I was wondering why it doesn’t work in AfO whereas it worked while running the same query in BEx Query Analyzer. Then I ran into following SAP Note: 2299020 - Analysis Office does not evaluate Hide Repeated Key Values from Query definition.

It clearly states that “the design rule for newer clients like Analysis Office has been that visualization settings for the table (UI) should not be part of the BEx Query definition.” It is also documented on hep.sap.com:

Query Analyzer: Hide Repeated Key Values -> You can specify whether identical key values are to be displayed more than once in the query. The Hide Repeated Key Values setting is active by default, so that only the first key value is displayed for each characteristic and additional, identical key values are hidden.

Analysis for Office: Repeat Members -> The setting made in BEx Query Designer to hide/show repeated key values is not evaluated in Analysis. To define the display for repeated members only this setting in the design panel is evaluated.

To employ the setting in case of AfO there is a checkbox called “Repeat Members” on tab Components -> select particular DataSource -> Crosstab x. 

SAP BW/4HANA (B4H) – what is it?

Soon after SAP introduced their HANA optimized ERP system (S/4HANA – 4^th generation ERP system, 18 months back) another main product of SAP is emerging on HANA platform. It is SAP BW/4HANA (or B4H, BW4 or just B4) launched on Sep 7^th 2016. Important information is that it is a new products and it is not successor of SAP BW at all. It is based on code fork (unlike BWonHANA (BoH) which code line is still shared with rest of supported DBs) of Any DB SAP BW and it will become primary development platform at SAP. This can indicate that in future there will only be new versions of B4H delivered. All other Any DB SAP BW will not follow current BW 7.5 version and these versions will not be maintenance mode.

According SAP there is following 4 corner stones of the new product:

1. Simplicity – only 4 basic types of objects (advanced DSO, Composite Provider, IO, Open ODS view) enhancement to already introduced “Field based modeling instead of InfoObjects based one”.

2. Openness – B4H can consume data from any source and data can be visualized by any major BI front end tool. Moreover any HANA table/view can be incorporated into B4H data model w/o data replication. SQL or native SQL data approach known in classic SAP BW scenarios is still possible.

3. Modern UIs – it shifts more towards Eclipse based tool – HANA Studio from all major use case perspectives like modeling/administration/user. Use of SAP GUI shall be more less obsolete for B4H. More parts of monitoring functions are SAP Fiori / UI5 based.

4. Performance – Calculations in newly developed data warehouse models shall be pushed down to database. This will bring speed to classic BW models that are being calculated on level of ABAP AS. Push down approach shall ensure enough “horse power” to deal with big data (e.g. via SAP VORA a bridge between classic RDBMS and distributed processing on a file system (hadoop).

More information:

Online docu SAP BW/4HANA 1.0

What is B4HANA – saphana.com

What is B4HANA - SCN

What is B4HANA - Thomas Zurek blog

Why B4HANA - Thomas Zurek blog

BW/4HANA FAQ - John Appleby blog

Making the leap to SAP BW/4HANA - John Appleby blog

Road to bw4hana part 1

SCN article

SAP Influence page for B4H

SAP Support system component: BW-B4H

Impact assessment of B4H

BoH: Obsolete processes in process chains

While running SAP BW on HANA database there are couple of processes within process chains that were used before and are not needed anymore. Reason is that HANA has some of these functions already build on DB level and BW doesn’t need to be worry about them. A list of these obsolete processes is here:

Index related:

Build Index

Delete Index

Aggregate or BWA related:

Initial Filling of New Aggregates

Adjust Time-Dependent Aggregates

Rolling Up Filled Aggregates/BWA Indexes

DB statistics related:

Construct Database Statistics

Other:

Update Explorer Properties of BW Objects

So what actually the SAP BW system does when it runs into the process that is obsolete for HANA? There is simple check if the HANA is the DB of particular system. The check itself is very similar to the checks that I introduced in my other blog: How to check whether your ABAP NetWeaver is HANA DB based? It is just a check of attribute n_is_hdb_system which is initialized in constructor of class CL_RS_UTILITIES (cl_rs_utilities=>n_is_hdb_system = rs_c_true). While the check return value true then messages like below are displayed:

·         Variant &1 skipped (not required for SAP HANA database)

·         Deleting the index is not necessary/useful for HANA DB systems

·         Building an index is not necessary/useful for HANA DB systems

·         No roll-up required for HANA DB systems

Then finally what we see in process chain monitor is nice log like following:

Useful links:

Online docu