Change of time zone in BW -> impact on BW system

In case of multinational companies a BW system serves as global system. This means users are using it around a clock depending on their time zones. To support different loading times to satisfy user communities from different systems it makes sense to put the system time zone to UTC (Coordinated Universal Time). This time zone then serves as base time zone from which loads for different user communities can be derived.

Change of time zone in BW, needs to be done by transport which moves following table entry: R3TR TABU TTZCU (Customizing time zones)

However more important is impact on BW system while time zone change. There are multiple places in the BW system that might be impacted by this. Therefore on such an event the BW system as whole must be carefully checked. Also all BW applications (InfoAreas) must be checked as well.

More over below are areas that must be also thoroughly checked:

1. Load schedules – in case some Ipacks/DTPs/Process Chains are scheduled at particular time that will be schifted while the time zone change

2. ABAP Logic in BW transformation/routines/formulas/user exits/DTP(Ipacks) filters - which deals with system field related to time zone (e.g. sy-datlo, sy-tzone, sy-zonlo, etc.)

3. Loads notification delays – in case there is a workflow in place that notifies user about progress of loads. In case email/sms that must arrive on time and that time might change by the time zone shift..

4. BWA/HANA rollups delays – also if particular rollup must be on time makes sure that that time doesn’t change

5. Broadcast runs – similar as in point no 4

Automatically Repeat Red Requests in Process Chains

Similarly to possibility to repeat DTP in case its previous run failed that I described here – it is also possible to enable in similar way repetition of step within process chain. A kind of automatic re-start of failed steps in the PC thing. This helps to improvements running of the PC and overall maintenance effort of SAP BW systems.

Normally in case the process step fails someone must go process chain log via Administration t-codes and manually restart the step. If certain settings are maintained for the process then after it failed depending on the settings automatic repeat of process chain steps happens.

Following is a procedure to maintain the settings for particular process in the PC:

In change mode of the PC and there is an item in right click menu available for the process -> "Automatic Repetition". In next pop-up window following parameters need to be maintained:

Seconds: a time in seconds is specified here how long the process needs to wait before repeating the task.

Number of Repetitions: The maximum number of times this process should be repeated

After maintain the settings the PC must be activated in order to enable this feature.

Technically the settings are implemented in table RSPCCHAIN and its fields AUTO_REPEAT and REPEAT_TRIALS. 

Automatically Repeat Red Requests within DTP

Within DTP there is a new flag available on Execute tab. It is called “Automatically Repeat Red Requests in Process Chains”. This feature helps to speed up administration of BW system. 

Imagine a case if the flag is NOT set and the DTP terminates. Normally an error message appears explaining that no new request can be started until the previous request is either repaired or deleted. 

Now if the flag IS set the previous request that contains errors is automatically deleted and a new one is started.

Technically the flag is implemented in table RSBKDTP and its field AUTORESTART. Data dictionary domain behind is RSBKAUTORESTART - DTP Request: Automatic Repetition of Terminated Request.

How to find in which TRFN particular ABAP INCLUDE is used

In order to decouple of application logic used in BW’s Transformation ABAP code is sometimes not placed into the Transformation’s Start/End Routine directly but instead this an ABAP INCLUDE is used. So custom logic is complete placed into the INCLUDE that is included in the particular routine.

One may wonder how to find out what is/are Transformations where that ABAP INCLUDE is used. To find out this below is procedure:

1. Display INCLUDE in t-code SE38 and perform either Where-Used function (CTR:+SHIFT+F3 or icon on toolbar) or syntax check shows a list of GP* programs where the ABAP INCLUDE is used.

2. Particular GP* program shall be looked up in table RSTRAN in field TRANPROG. Notice that has to be the GP* program ID used but w/o prefix of GP. In field of TRANID field an ID of Transformation is then found.

Or

3. Display the GP* program in t-code SE38.

4. Move up in the ABAP editor into beginning of the GP* program where comment having Tran ID information is display (e.g. at line 31)

5. Take Tran ID information and use Find function of RSA1 to find a particular Transformation.

How to delete process variant of Process Chain

It is an often case that an process variant within process chain is created but later on for whatever reason it is not needed anymore. The process variant should be deleted in such a case. So how to delete an old process variant that is not needed?

Basically within t-code RSPC1 (or via RSA1 -> Modeling -> Process Chain) any PC needs to be displayed in the PC maintenance mode. Then depending on Process Type of process that needs to be deleted such a Process Type needs to be found within the displayed PC.

1. Right Click -> Exchange Variant

2. Select the process variant that needs to be deleted from available pop-up list

3. Double click on selected process variant

4. On next screen of the process variant maintenance - click on change button and Delete the selected process variant via Delete button

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

abapacademy.com              Ladislav Rydzyk        Active

oprsteny.com                    Miroslav Oprsteny     Active

fanores.blogspot.com          Stefan Misik             Last activity in 10/2012       

jaros.in                            Pavel Jaros              Last activity in 04/2016       

mojsap.sk                         Miloš Volek              Not active since 10/2016

abap.cz                            unknown                 Not active since 08/2011

adamka.sk                        Lubos Adamka         Active

sapconsultant.cz                 unknown                 Not active since 08/2014

abap.sk                            Juraj Sukupa           parked domain only

sap-portal.sk                     Michal Rehák            Not active since 02/2016

sap-cz.blogspot.com           Milan Sedlácek

Tomáš Marný           Not active since 06/2013

abapista.cz                        Ludvik Spilka            Not active since 04/2016

abap pre zaciatocnikov        unknown                 ABAP tutorial for beginners in Slovak language

projectik.eu                       Peter Jarunek          2 articles on very basic SAP topics

last update: Dec 31th 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:

github - DTP_TO_BE_PUSHED2HANA.

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*

1/ CHECK_DMRX…:

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 ''

2/ MON:PROTOCOLL_ACTION

Request ID                                           1259141 from data target RX… scheduled for deletion

3/ DTPR_7TQYDLHVH8KTJ5A6QDBVV2F3Q-DELETE_FROM_PSA

Request DTPR_7TQYDLHVH8KTJ5A6QDBVV2F3Q deleted from PSA; RSREQICODS entry also deleted

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

4/ ERRORSTACK_REQUEST_1259141

MON:PROTOCOLL_ACTION-DELET-RX…

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

5/ DTPR_7TQYDLHVH8KTJ5A6QDBVV2F3Q-DELET-RX…

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.

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:

GEN_BRANCHOFFSET_LIMIT_REACHED

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.

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.

ABAP: usage of ASSERTions, LOG-POINTs and BREAK-POINTs

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:

ABAP Test Support – online docu

See example of LOG-POINT statement usage: github.com/softy12/ABAP-LOGPOINT

Below see a simple log entry created by LOG-POINT statement.

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.