Saturday, December 31, 2016

Slovak (and Czech) blogs related to SAP

As starting on next year (just tomorrow) this blog is celebrating its 10 year anniversary I was thinking to see whether there are some other people blogging about same topics I do – SAP. Therefore I took to google collected below list of blogs and web pages created/maintained by people in Slovakia and Czech Republic region and of course related to SAP. Here’s what I found. A list is not so long; even some blogs are not active anymore. However I hope I keep an eye on this from time to time and going forward I will be updating it.

URL                                         Person                       Status              Ladislav Rydzyk        Active                    Miroslav Oprsteny     Active          Stefan Misik             Last activity in 10/2012                            Pavel Jaros              Last activity in 04/2016                         Miloš Volek              Not active since 10/2016                            unknown                 Not active since 08/2011                        Lubos Adamka         Active                 unknown                 Not active since 08/2014                            Juraj Sukupa           parked domain only                     Michal Rehák            Not active since 02/2016           Milan Sedlácek
Tomáš Marný           Not active since 06/2013                        Ludvik Spilka            Not active since 04/2016

abap pre zaciatocnikov        unknown                 ABAP tutorial for beginners in Slovak language                       Peter Jarunek          2 articles on very basic SAP topics

last update: Dec 31th 2016

Friday, December 30, 2016

Can DTP be pushed to HANA DB for execution?

Usually one of very first things that are checked once the BW system is migrated to HANA database is to find out what are data loads that can be pushed to HANA easily without any modification. To do this check SAP offers within the set of tools for migration to BW on HANA tool called SAP BW Transformation Finder (ABAP report ZBW_TRANSFORM_FINDER).

The tool is quite a complex and it offers to identify redundant data layers like "1:1" or "N:1" transformations. Through this tool the transformations that can be pushed to the DB can be found. Although a list of the TRFN is definitely useful I was wondering whether there is a way to identify a list of the DTP for the same – push to the HANA DB. As I blogged in my older post Pushing DTP execution to HANA DB there is a button available in the DTP maintenance screen that allow to find it out. To check this for many DTPs at one shot I developed short program. The program can be found in my github - DTP_TO_BE_PUSHED2HANA.

My tool similarly to SAP one utilizes a call of method CLARIFY_REALIZATION of class CL_RSTRAN_DB_STAT. If DTP particular DTP is compatible with SAP HANA Execution then it is listed out in tool’s output screen. Hope someone will find the tool useful.

More information:

1908367 - SAP BW Transformation Finder

Data load request deletion logs

This is a short post about how to find out a data deletion related logs in SAP BW. Mostly details about data deletion operations that happened can be revealed by t-code SLG1. 

SLG1 ->provide following input on its selection screen:

Object:                   *
SubObject:              *
External ID:            value1:         CHECK_DM    
Value2:         MON:PROTOCOLL_ACTION   
value3:         *DELETE_FROM_PSA
value4:         ERRORSTACK_REQUEST_*
value5:         *-DELET-*
value6:         *req_no*

FB RSM1_CHECK_DM_GOT_REQUEST called from PRG LRSM1F08; row 004240
Request '                                          1259141'; DTA 'RX…'; action 'D'; with dialog 'X'
Leave RSM1_CHECK_DM_GOT_REQUEST in row 70; Req_State ''

Request ID                                           1259141 from data target RX… scheduled for deletion

Request DTPR_7TQYDLHVH8KTJ5A6QDBVV2F3Q deleted from PSA; RSREQICODS entry also deleted
Request DTPR_7TQYDLHVH8KTJ5A6QDBVV2F3Q not found in IC RX…; RSREQICODS also deleted

Delete is running: Data target RX…, from 1259141 to 1259141
P-DIMID 156 deleted from table /BIC/DRX… (InfoCube RX…)
P-dimension index read; number of records: '26'
Number of request entries to be deleted: '1'
'1' records indexed
Prepare optimize and commit optimize executed
Request with P-DIMID 1259141 from InfoCube RX…deleted (27000242 data records)
Delete was successful: Data target RX…, from 1259141 to 1259141
Delete is finished: Data target RX…, from 1259141 to 1259141

Delete is running: Data target RX…, from 1259141 to 1259141
P-DIMID 156 deleted from table /BIC/DRX… (InfoCube RX…)
P-dimension index read; number of records: '26'
Number of request entries to be deleted: '1'
'1' records indexed
Prepare optimize and commit optimize executed
Request with P-DIMID 1259141 from InfoCube RX… deleted (27000242 data records)
Delete was successful: Data target RX…, from 1259141 to 1259141
Delete is finished: Data target RX…, from 1259141 to 1259141

6/ *req_no*

Scalability – scale out/in vs up/down

One of important aspects of computer system is scalability. It is a capability of the system to handle expanding amount of tasks that need to be completed by the system. Prerequisite is that the system must function in same way after scaling as it was before the scaling. The system in this terms can be computer, network etc. Scalability is sometimes referred as extensibility.

There are two basic approaches to scaling of the computer systems. It is horizontal and vertical scaling.

In first case – horizontal scaling it means to add or remove a computing unit (node) to/from the system. This is so called quantitative change. As example a new computer can be added into distributed system. The horizontal scaling is also called as scale out/in.

The latter case – vertical scaling it means to change a property of the existing system by adding or removing resources to/from the computing unit (the node) of the system. This is so called qualitative change. As example it can be about adding more CPUs or memory to existing node. The vertical scaling is also called as scale up/down.

Difference between the two can be noted on following example. There can be a system of having an 8TB of memory in total in one node – a scale up approach. While as scale out example there can be 8 nodes having 1TB of memory each.

In terms of scaling of SAP HANA both approaches can be used as the HANA is designed for scale up and as well for scale out since the beginning.

Tuesday, December 13, 2016

How big a generated ABAP program can be?

In some of ABAP applications that generate pretty heavy volume of ABAP code while generation there can be following ABAP dump observed:


The dump refers to fact that ABAP code is too large to get it generated. Means there are too many lines of code that generated program gets too big and thus cannot be compiled.
Messages observed here can be like following:

"Jump distance is too large and cannot be generated."
"Jump is too great and cannot be generated."

In BW this may happen in very large ABAP includes ZXRSRU01   (FM EXIT_SAPLRRS0_001) where all custom BEx variable are stored. Here is a large CASE/ENDCASE statement where all the BEx variables are stored. Solution is here is to split one big CASE/ENDCASE into several ones e.g. per different projects or inforareas available in the system.

What it is actually means from technical point of is that there are so called jumps within the generated code and in case there is not enough space to store whole content of jump then the ABAP code can’t be generated. The jump represent smallest logical unit of code that must be placed in one generated code (jump). E.g. IF/END or CASE/ENDCASE statement. Code inside of these statement must be exists within same jump. The jump should not be greater than 32768 bytes (32kB) for internal load format. The 32kB roughly corresponds to around 10,000 of ABAP statements.

Thursday, November 3, 2016

Further checking of broken BEx queries 3 – performance

With regards to BEx query performance it is beneficial to know where is a bottleneck during the query execution. This is especially useful while investigating cases where one user is complaining about the query whereas for other it runs okay.

Wihtin t-code RSRT there is a quick way how to display statistics information about date of query runtime. You can switch this on after hitting “Execute + Debug” button.

RSRT -> enter query -> Hit "Execute + Debug" button -> new popup -> check "Display Statistics Data" -> 

After the query output there is a screen called "Statistics Data for Query Performance" displayed with 2-3* tabs (see below) having information on how much time the query execution took at different processing levels. More information about how to read the screen can be found here.

- Front-end/Calculation Layer
- Aggregation Layer
- Aggregation Layer Cluster Info
* - no of tabs may vary depending on BW system release

Intermediate result of APD process

APD or Analysis Process Designer is tool within classic BW used to model analysis processes.  The process itself has a purpose of data calculation and data transformations for an analytic application in the BW. The processes build in the tool can read and merge data from data sources in the BW system, different transformations can be connected, etc. The result data can be stored into the DSO objects in the BW.

Now while I mention saving of the results of the ADP process… Actually one can see the results w/o running whole APD leveraging of functionality of “Intermediate Results”. This is available on right click perfumed on particular process (node). The intermediate results are then stored into temporary transparent table with naming convention like: /BIC/000APR e.g. /BIC/000APR00002. The table can be viewed e.g. in t-code SE11.

Now there is handy icon appearing next to the process (node) indicating that it has the intermediate results data stored. 

In case you do not need to the intermediate results have in the table you can delete it via function called “Clean Up temporary table” available under menu Environment in t-code RSANWB.

Monday, October 31, 2016


Assertion in software development is technique used to detect and track a state in program which should not occur. In computer programming it is so called programming predicate that developer assumes that is always true. The predicate is Boolean valued function which returns a true–false expression.

Information about the predicate can be placed into comment of the program code. However it can be also directly included in the code. While the code is compiled or the compiled program runs there are checks for these predicates. These do not serve as treatment of unexpected or err nous states like user input checks. Instead it is about the detection of the status which is not supposed to happen.

Assertion or so called checkpoints define points in a program, at which the state of the program can be tested during program execution. Checkpoints are either conditional or unconditional. Conditional checkpoints are defined by ASSERT, unconditional checkpoints by BREAK-POINT or LOG-POINT. Needless to say that the checkpoint of all types are non-operational statement used just for test purposes.

Activation/deactivation of checkpoints outside of the program can be done by assigning them to a checkpoint group in t-code SAAB.

How the checkpoints or assertion is supported in ABAP programming language? There are a couple of ABAP statements for this purpose.

ASSERT statement - it is a checkpoint. It is used to verify specific assumptions about the status of a program at a specific point. The ASSERT statement is instantly recognizable for example when analysing ABAP dump.

LOG-POINT statement - is a checkpoint which creates a log entry when an active logpoint is reached. The logpoint must be assigned to a checkpoint group. The statement LOG-POINT was introduces to replace wrong usage of the ASSERT with a condition that is always wrong for simply writing log entries.

BREAK-POINT statement - is placed in the ABAP program. When it is reached in foreground/dialog processing it branches to the ABAP Debugger. If the breakpoint is set by user in ABAP editor it has limited validity - until user logs off. In case the breakpoint is hard-coded with the statement BREAK-POINT it is considered as unconditional checkpoint with an unlimited validity which is either always active or activated by assigning it to a checkpoint group.

More information:

See example of LOG-POINT statement usage:
Below see a simple log entry created by LOG-POINT statement.

Friday, September 23, 2016

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.

Thursday, September 22, 2016

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:


Just replace it with Rule Type Formula like:


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 1st 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”.

Saturday, September 17, 2016

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

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 – 4th 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 7th 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 –
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
SAP Influence page for B4H
SAP Support system component: BW-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
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: