Code push-down in ABAP Development

S/4 HANA presents a new opportunity for code

optimization.

If you are into ABAP Development then by now

you must already be familiar with the code to data
paradigm. In simple terms this means pushing
much of the data processing down to where the
data resides i.e. the database.

Historically SAP ABAP supports 2 kinds of

languages to interact with the database system.

1. Open SQL – SAP’s own way of performing SQL data interaction

2. Native SQL – Using the underlying database’s native SQL supported features.

Let me remind you that SAP as a software largely

supports most of the common relational
databases, MS-SQL, and Oracle being the most
common that I have encountered. As an
 established rule, for a database to be called
relational, it should support the structured query
language, SQL. However in addition to supporting
standard SQL, database makers add their own
unique constructs which makes it stronger than
other databases for some purpose.

SAP therefore supports Native SQL which means

if you know the uderlying database, you can
exploit its potential by using statements
specifically supported by that database using
Native SQL. In contrast to this, OpenSQL allows
SAP developers to code in a database agnostic
way. In other words OpenSQL statements will be
always be understood and executed by the
underlying database ( because they are driven off
of industry standard SQL ) while NativeSQL may
or may not be understood by the DB. For this
reason NativeSQL statements are considered a
big no-no within the ABAP Development
community. In my programming career I may have
hardly used NativeSQL may be like 5 times and
that too mostly %_HINTS statement to optimize
program SQL performance.

Check out this blog for some examples to

understand %_HINTS in MSSQL.

Find more on HINT in sap help here.

So what is Code to Data Paradigm and why should I be concerned of

it ?
With S/4 HANA – SAP now uses HANA as its
native database to store data. But HANA is much
more than just a database. Among other
advantages and features, like

 Row and Column Data store,

 Data Compression,
 Supporting both : OLTP and OLAP patterns within one application,

It has capabilities of In-memory computing.

One of the imperatives of In-memory computing is
that you have to

1. Avoid (unnecessary) movement of large data volume

2. Perform data-intensive calculations in the database.
 One of the key differences for developing
applications in ABAP for HANA is that you can
push down data intense computations and
calculations to the HANA DB layer instead of
bringing all the data to the ABAP layer and then
processing the data to do computations. This is
what is termed as Code-to-Data paradigm in the
context of developing ABAP applications
optimized for HANA.

The Code to Data Paradigm is experienced in

three levels or stages in SAP HANA each with
increasing levels of complexity and performance
improvements

1. Transparent Optimizations : Fast Data Access, Table Buffer enhancements.

2. Advanced SQL in ABAP : Open SQL Enhancements, CDS Views
3. SAP HANA Native Features : AMDP, Native SQL

Most of the times one would be satisfied with

advances achieved with level 2 itself and Level 3
is really squeezing out the final bit of optimization,
but each of them are interesting in their own
applications.

Top-Down Approach for Development

The Code to Data paradigm means that data

intensive operations be pushed down to the
database. The obvious implementation of this
would be the Bottom – Up approach in which we
would program stored procedures and views
directly into the HANA database and then
consume them in the application server as
needed. Since the procedures are coded at the
 database level itself, they would run faster.
Correct ?

Yes. True and Even SAP thought the same way

prior to NW 7.4 SP2. But later on realized that the
issue with this approach for general consumption
is that

1. As a developer you would have to work in two environments, HANA DB to

create the DB artifacts and ABAP to consume those artifacts as remote
proxies. So far we have been transparent to the Database layer. In fact I have
never ever directly logged in into the database layer ever.
2. You will have to bear the responsibility of keeping your HANA and ABAP
artifacts in sync and take care of the life cycle management.

So with NW 7.5 Sp5 onwards a change in

methodology , the Top – Down approach was
adopted. The Top – Down approach is our usual
way of working with ABAP development objects.
Meaning you would develop HANA based ABAP
artifacts in the ABAP Application Server itself and
deploy(activate) them on the HANA Database. Its
just like our usual ABAP Report development,
where in we develop the report at the application
server level and the report is then activated and a
transport request is generated which can be
released in order to move the object across
systems.

Currently Top-Down approach is used in the CDS

views and ABAP Managed Database Procedures
(AMDP).
 There are already a number of blogs on this topic.
I am planning to post a few topics on CDS
views. What are your findings on S/4 HANA ?
Have you already started working on it ? or are
you interested to learn more on these topics ? Let
me know your views on this topic.

Shares

15 Comments

1. Anbu

February 2, 2018 at 3:40 am

I haven’t worked on S4H yet. But seems to be more interesting.

Thanks for the post.

Reply

 Linkin Pereira

February 2, 2018 at 11:47 pm

Thanks for your feedback. S/4H is considerably new and recently SAP added
their 1000 customer on s/4 HANA. Stay tuned as more will come in the future
blog.

Reply

2. Ahmed Ali Khan

February 2, 2018 at 7:26 am

Awesome blog Linkin

Reply

 Linkin Pereira

February 2, 2018 at 11:47 pm

Thank you Ahmed

 Reply

3. Kajal khetiya

February 4, 2018 at 6:51 pm

I want to learn many things in sap and I m beginner in sap thank u sir for motivation.

Reply

4. Kripa Rangachari

February 6, 2018 at 3:02 pm

Very interesting post.

I started following your blogs and & youtube videos. Thanks for sharing the knowledge..

Regards,
Kripa Rangachari.

Reply

5. Michael

February 9, 2018 at 8:34 pm

It seems to be a bad idea to use this paradigms even if they seem to be technically
appealing. You explained yourself why it is not a good idea to push down.

1. As a developer you would have to work in two environments, HANA DB to create the
DB artifacts and ABAP to consume those artifacts as remote proxies.

To keep maintainablity of your code over long years or even generations of programmers
you would normally try to avoid to distribute your program logic into two layers: The
ABAP code and some logic located the database layer and possibly bound to a database
vendor or database release. I.e. do no use of any predefined procedure on the database
level even if this will give you some performance advantage.

2. You will have to bear the responsibility of keeping your HANA and ABAP artifacts in
sync and take care of the life cycle management.

Keeping the database and application layer artefacts (manually) in sync is a risk for your
productive environment.

Overall the new paradigm is bad form the viewpoint of maintainability, service stability
and thus for total cost of ownership.
 Reply

6. Raj

February 12, 2018 at 8:26 pm

We head about the proverb. old wine in new bottle. In the initial days i remember
client/server programming like VB/SQL server or VB/oracle. we use to develop stored
procedure in backend and consume them in front end like VB or some other tool.

The performance of those applications is great inspite of other challenges. Now we are
getting there again but in different flavors.

The only one thing i am always confused in SAP world the concept is more or less is
simple but the terminology or woding or branding the SAP use confuses me a lot.

Good article Linkin. keep it up.

Reply

 Linkin Pereira

February 14, 2018 at 11:43 pm

Yes Raj, I echo your thoughts. Old wine in New bottle. Good way to put it.
Initially it was a great idea when data processing was pushed to the database
layer, but later there were considerable challenges to this approach. Hence later
software moved towards a solid 3 tier architecture and kept data processing to
the middle layer.

But HANA and in-memory database are challenging this thought once again.
The advantages are clearly visible until off course we hit another snag. But for
now, it seems this is the direction SAP is focusing on.

Thanks for the comment and for being a subscriber.

Reply

7. Manoj Priyadarshi

February 13, 2018 at 7:20 am

It’s great Article in simple words explaining SAP HANA for technical guys. Even I have
worked on one S/4 implementation project but it seems I need to learn a lot on S/4
HANA. Keep me updated.

Reply
  Linkin Pereira

February 14, 2018 at 11:44 pm

Hey Glad you liked this article Manoj. Happy to share what I have learnt so far.
Will keep posting more. Keep reading and commenting.

Cheers

Reply

8. Harshit Jain

February 14, 2018 at 11:06 am

Hi Linkin
Can you please explain OLTP and OLAP?

Reply

 Linkin Pereira

February 14, 2018 at 11:37 pm

Hey Harshit, good you asked that – I totally forgot to elaborate on it.

Softwares are broadly classified into 2 types OLTP and OLAP.

OLTP stands for Online Transaction Processing. Softwares which are used to
record daily transactions and computations come under this category. For a
typical OLTP software to function well, the underlying database needs to be in a
normalized form. Usually this means Real Time Transactional Data.

OLAP on the other hand stands for Online Analytical Processing. Such
software, as the name suggests, are used for reporting and data analysis
purposes. Such systems usually run on historic data which is not update daily.
In such softwares the database needs to be in a denormalized form to support
faster data access and reporting.

—
Because of the nature of these systems and the constraints they lay on the
underlying database design, they could either support OLTP or OLAP not both.
HANA thru if its Column store, Row store data storage principle breaks this
constraint and can therefore allow the same system to support both, OLTP as
well as OLAP architecture at the same time based on the application
requirement.
smartScale for HANA will consists of the appropriate components with newly added HANA Code

Optimization Ruleset.

• smartAnalyze o SaaS Analysis • smartUpgrade o Unicode Enablement o Change Impact Analysis •

smartDevelop o On-going ABAP Code Remediation

© 2013 smartShift Technologies. All rights reserved

smartScale for HANA Offering

8/13/2013 8

Presenter

8/13/2013 9 © 2013 smartShift Technologies. All rights reserved

Albrecht Gass Chief Architect smartShift Technologies

www.smartShiftTech.com

SAP HANA Overview 2

• Column and Row Store • Dictionary based (compression) • ACID RDBMS • Stand-alone or SAP Business

Suite/BW • JBDC, ODBC, ADBC, MDX • Unstructured Data Support • Full Text Searchable • HW

Appliance or Cloud Deployment • Advanced Calculation Engine • Historic Data

© 2013 smartShift Technologies. All rights reserved

SAP HANA Overview

8/13/2013 11

• Unicode Only • Integration with ‘R’ • Large Tables • Dynamic Tables • ABAP Code Must be Optimized •

Eclipse based IDE (ADT) • Optimization for Star Queries • Signification Performance Improvements •

ALV paging for large results

© 2013 smartShift Technologies. All rights reserved

SAP HANA Overview

8/13/2013 12

• Does not impact transaction processing • Enables “reporting without fear” by increasing reporting

speeds dramatically • Eliminates SAP as Access Loader • Keeps processing within SAP and not Excel •

Avoid using old and/or partial data • Convert batch processes to real-time operations • Enable new

big data processes

© 2013 smartShift Technologies. All rights reserved

HANA “Objectives”

8/13/2013 13
© 2013 smartShift Technologies. All rights reserved

Attribute View

8/13/2013 14

• Can join multiple tables • Perform simple calculations • Only SQL Functions can be used

© 2013 smartShift Technologies. All rights reserved

Analytical View

8/13/2013 15

• Replaces cubes in traditional BW • Joins attribute views and fact tables • Perform calculations and

aggregations • Only SQL Functions can be used

© 2013 smartShift Technologies. All rights reserved

Calculated View

8/13/2013 16

• Full SQLScript • Must define output record type • Supports measures and hierarchies • Callable via

standard OPENSQL

© 2013 smartShift Technologies. All rights reserved

DB Procedure

8/13/2013 17
• Full SQLScript • Can define a output record type • Callable via CALL DATABASE PROCEDURE • Creates

table types for input and output arguments

© 2013 smartShift Technologies. All rights reserved

DB Procedure (cont.)

8/13/2013 18

© 2013 smartShift Technologies. All rights reserved

Externalizing a HANA view to be used in ABAP

8/13/2013 19

• View defined in HANA • Externalized so that it can be referenced by ABAP code • Can be used in

OpenSQL statements

© 2013 smartShift Technologies. All rights reserved

Externalizing a view on MARA to be used by ABAP

8/13/2013 20

The view is now visible in DDIC and can be used in ABAP programming, e.g. for declarations, selections,

etc.

www.smartShiftTech.com

Performance Guidelines and Rules 3

8/13/2013 21

• Reduce result set • Reduce amount of data transfer • Reduce number of DB round trips • Index/Query

optimization • Text search for F4 help and type-ahead search • Avoid native SQL • Consider changes

in the order in the result • Use buffering on application server • Existing best practices still apply •

Don’t overload HANA server

© 2013 smartShift Technologies. All rights reserved

HANA Optimization Guidelines

8/13/2013 22

• Side-car vs. Primary DB • Instance Size o Memory o CPU • Table Partitioning • Consider Changes in

Query Result Ordering • Incompatible Native SQL Code • Unicode Requirement

© 2013 smartShift Technologies. All rights reserved

HANA Implementation Considerations

8/13/2013 23

These patterns focus on the push-down paradigm as well as on restrictions that HANA is imposing.

Locate joins on transactional table Locate “SELECT … FOR ALL ENTRIES” statements Locate SQL
 on SAP “index” tables (i.e. VAPMA) Clusters of related table SQL (i.e. VBAK, VBUK, VBAP) Custom

read cluster tables Sort of internal tables sourced from SQL Processing of internal tables sourced

from SQL Perform unit conversion ALV Optimization DB Migration rules

© 2013 smartShift Technologies. All rights reserved

New HANA Performance Rules

8/13/2013 24

www.smartShiftTech.com

Optimized ABAP Code Examples 4

8/13/2013 25

• Originally using nested SELECT FOR ALL ENTRIES

© 2013 smartShift Technologies. All rights reserved

Example 1 – Using an external view

8/13/2013 26

• Model a view based on a join of LIKP and LIPS

© 2013 smartShift Technologies. All rights reserved

Example 1 – Using an external view (2)

8/13/2013 27

• Make the new view visible to app layer: define a dictionary view

© 2013 smartShift Technologies. All rights reserved

Example 1 – Using an external view (2)

8/13/2013 28

© 2013 smartShift Technologies. All rights reserved

Example 1 – Using an external view (3)

13.08.2013 29

Replacing SELECT ... FOR ALL ENTRIES: • Required data is provides by View ZV_ERROR_DOCS, based on

VBUK, VBFS, VBSK, • Join of ZV_ERROR_DOCS with ZV_DELIVERY_DATA, • Integration of pre-

requisite conditions, selection criteria and type

• Original code as in example 1

© 2013 smartShift Technologies. All rights reserved

Example 2 – Pushing code to DB layer

8/13/2013 30

• Define procedure parameters

© 2013 smartShift Technologies. All rights reserved

Example 2 – Pushing code to DB layer (2)

8/13/2013 31

• Generated interface object, to be used in application logic

© 2013 smartShift Technologies. All rights reserved

Example 2 – Pushing code to DB layer (3)

8/13/2013 32

• SQL script that implements reading from relevant tables

© 2013 smartShift Technologies. All rights reserved

Example 2 – Pushing code to DB layer (4)

8/13/2013 33

• Modify code to use interface / call procedure

© 2013 smartShift Technologies. All rights reserved

Example 2 – Pushing code to DB layer (5)

8/13/2013 34

• Example 2 demonstrated a new ABAP language feature: o CALL PROCEDURE • ABAP for HANA

introduces a new usage pattern for a well known and commonly used programming feature: o ALV

Grids • True to the motto “push code down to db layer”, the new ALV grid model, also called IDA-

ALV (inegrated data access list viewer), implements much of the processing in the DB layer •
 Example from NW 7.4 SP0 follows. Note that SP2 adds some features not available in SP0: o Setting

field header texts o Fuzzy text search

© 2013 smartShift Technologies. All rights reserved

NetWeaver 7.4 ABAP Enhancements

8/13/2013 35

• Internal Tables with Empty Keys • New Internal Table Functions • ABAP Objects (Exporting, Importing

and Changing, Partially Implemented Interfaces for Testing) • Table Expressions • Conditional

Operators • Lossless Operator EXACT • Conversion Operators • Reference Operator • Value

Operator • Constructor Operator • Inline Declarations • Expressions

© 2013 smartShift Technologies. All rights reserved

NetWeaver 7.4 ABAP Enhancements (cont.)

8/13/2013 36

© 2013 smartShift Technologies. All rights reserved

Use of Integrated Data Access List Grid (IDA-ALV)

8/13/2013 37

smartScale for HANA will consists of the appropriate components with newly added HANA Code

Optimization Ruleset.
• smartAnalyze o SaaS Analysis • smartUpgrade o Unicode Enablement o Change Impact Analysis •

smartDevelop o On-going ABAP Code Remediation

1.

2.

3.

4. SAP HANA

5. SAP HANA and In-Memory Computing

6. SAP HANA and In-Memory Computing Troubleshooting Guide

Analysing Performance problems on HANA

Skip to end of metadata
 Created by Des Gallagher, last modified on Dec
08, 2017
Go to start of metadata
Is the Performance issue system wide or does the
problem only impact one transaction or report? It is
important to know this at the start of your analysis
as this will determine the steps you take to analyse
the issue.
Performance problem is System Wide:
A good starting point that often finds the root
cause of the problem is to execute the HANA Mini
check report (HANA_Configuration_MiniChecks)
from the KBA 1969700 , with the Mini check you
get an overview of the overall health of the system
in terms of Memory, CPU, I/O, locks etc and other
potential issues that may cause performance
problem on the system. In the output of the report
potentially critical issues that require further
investigation are marked with an 'X' in column 'C.
In the last Column (SAP_NOTE) you find the the
relevant SAP note that you need to follow to
analyse the issue in more detail. Example partial
screenshot of the report output in HTML format is
shown below:
Performance problem is specific to a SAP
transaction or Program on Application Server:
To analyse a performance problem for a SAP
Transaction or Program you can use an ST12
trace as described in the KBA 2436955 - Step by
step instructions on how to use ST12 trace for
analysis. From HANA Database point of view in
the ABAP performance trace we are interested in
% of trace that is ABAP, DB etc and the ABAP
Calls(s) that take the most time sorted descending
by Net(%). In general if most of the time is ABAP
then it is often not a database problem but there is
an issue with the standard ABAP coding or the
custom code:

If most of the time is ABAP in standard SAP code

do a KBA and note search for the call(s) and
programs(s) that use most of the Net time. From
the trace on the above screenshot we would be
searching for Read Table INT_BSEG. If most of
time is ABAP and it is standard code then it should
be possible to find a SAP note or KBA that
describes the problem. If you don't find a
solution and if it is standard and not custom code
create a SAP incident on the relevant application
component based on the searches you have done.

If most of the time is ABAP but in custom program

or transaction then you need to optimize the code
using code inspector tool and SQL monitor, see
the note 1912445 - ABAP custom code migration
for SAP HANA - recommendations and Code
Inspector variants for SAP HANA migration in this
note reference "Best Practice Guide -
Considerations for Custom ABAP Code During
a Migration to SAP HANA”
http://scn.sap.com/docs/DOC-46714 and
"Optimizing Custom ABAP Code for SAP HANA –
The New ABAP SQL Monitor.pdf"
http://scn.sap.com/docs/DOC-47444
The following blog post also have useful
information for analysis and code optimization
especially the part on The Golden Rules : ABAP
on HANA – from analysis to optimization/
If the ST12 trace shows high HANA Database time
it should be possible to find the SQL statement(s)
that take a long time from the 'Performance traces'
and 'SQL summary' tabs of the ST12 trace, see
the 'Resolution' section of the ST12 KBA 2436955
- Step by step instructions on how to use ST12
trace for for further information on this. For further
information on tuning individual SQL statements
please see the information in the KBA 2000002 -
FAQ: SAP HANA SQL Optimization, question 13.
Are there standard recommendations for
specific SQL statements available? from the
KBA has performance tuning information for
standard SQL statements.
Common Known Performance issues and
Solutions:
1: System is slow in general due to problem with
CPU, MEMORY. I/O or table locks, use HANA
SQL script HANA_Configuration_MiniChecks from
KBA 1969700 to check and follow recommended
notes depending on issue found with Mini check.
2: After migration to HANA DB for ECC or Suite
on HANA system reports and transactions are
slow, check that you are using HANA optimized
transactions and application switches are enabled
as per the PDF called
SoH_Optimizations_2014_10_24.pdf attached to
the note 1761546 - SAP ERP powered by SAP
HANA - Optimizations.
3: After migration to HANA DB custom
transactions or ABAP custom programs are slow,
see the section above called 'Performance
problem is specific to a SAP transaction or
Program on Application Server' for information on
ABAP code optimization for HANA.
4: SELECT TOP X type statements cause
performance problem on HANA (symptom :
system is slow with alot of these statements
running), see the note 2238679 - SAP HANA DB:
High CPU consumption caused by
UnifiedTable::MVCCObject::generateOLAPBitm
apMVCC
5: Poor performance of calculation view(s) after
HANA Upgrade, see the following notes:
2441054 - High query compilation times and
absence of plan cache entries for queries
against calculation views
2291812 - SAP HANA DB: Disable/Enable
CalculationEngine Feature - CalcView Unfolding
6: Poor performance of queries due to FDA (Fast
data access), see question 6 from the KBA
2399993 - FAQ: SAP HANA Fast Data Access
(FDA).
7: High preparation/parsing/compilation time for
SQL statement, if issue is that bind variables are
not used see the KBA 2375200 - How bind
variables can reduce parsing or query compilation
time on SAP HANA.

TOP Notes/KBA's for Performance analysis on

HANA:
2000000 - FAQ: SAP HANA Performance
Optimization
2000002 - FAQ: SAP HANA SQL Optimization
2222217 - How-To: Troubleshooting SAP HANA
Startup Times