Saturday, December 31, 2016

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

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.

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.

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

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.

Friday, December 30, 2016

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.

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

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.

About Me

Working as a Business Intelligence consultant (at percept ltd.) in SAP area specializing on SAP NetWeaver (BW, BI). Certified as SAP NetWeaver Business Intelligence consultant. From Bratislava, Slovakia.
More information