The SAP HANA Application Accelerator for SAP ERP

FAQ
27 Jul 2012 ABAP, Agile Methodology, Development, ERP, HANA, In-Memory

One of the most popular SAP HANA scenarios that I am seeing customers interested in today is
what is known as the "Application Accelerator" or "Suite Accelerator" and there is relatively little
information about it out there. My team has been implementing this in a number of locations and I
thought that my - and their - experience of it might be useful to share.
I will describe the three main scenarios: Built-In Application Accelerator, Custom Application
Accelerator and Secondary Database Connection (2DBC).

What is the Application Accelerator and what are the benefits?

The Application Accelerator, or Suite Accelerator, is an application using existing SAP
technologies. It combines SAP R/3 or ERP (or indeed any NetWeaver-based system) and
replicates database tables within it to SAP HANA using SAP's trigger-based replication system,
SLT and the SWT2DB Add-On. Then, existing database functions are pointed away from the
regular RDBMS and towards SAP HANA.
The effect of this is that long-running SQL statements run much faster: 100-1000 times faster in
most cases.
The benefits of this I will largely leave to the reader because it is very situation-specific. But for
example you could allow sales or finance reports to be run against real-time data, allowing better
visibility of pipeline or faster month-end close. You could achieve stock replenishment functions
far faster, meaning you have fewer out of stock items. The potential benefits are endless.

What are the built-in examples?

There are a bunch of built-in scenarios that SAP has built for you that you can activate - here are
the ones that I found at the time of writing, you can search SAP's Support Site (OSS) for a list.

Financial Accounting

Overhead costing/accrual calculation

Financial Statements (Period Accounting)

Material Ledger - Period End Closing, BW Extraction, Price Analysis & Virtual
InfoProvider

Interface material ledger

Enhancements in ML drilldown reporting

FI-AA interface - SAPLABRA, SAPDBADA, Reconciliation & Enhancements

Hierarchy processing

Overhead rates

Percentage method

FI Line Item Browsers

Materials management

BI reporting via DataSource

But you don't need to let this limit you - you can build your own accelerator in no time at all based
on your specific business needs!

What if I want to do my own Application Accelerator scenario?

Well I hope by now you are thinking of your own scenarios where the Application Accelerator
would add value! If you want to do this then that is just fine. All you need to do is to setup SLT
replication for the database tables that you need replicated and then use ABAP report
RDA_MAINTAIN to maintain database tables and programs to be accelerated. SAP does the rest
for you automatically! It automatically changes the code and SQL to point to SAP HANA for the
programs and tables that you defined.
There is a nice blog on it - SAP HANA Application Accelerator Scenario Editor
Do note that if you do want to write your own scenario, you need to be mindful of whether it is a
useful scenario to be accelerated with SAP HANA (see below for more information).

What version of SAP ERP do I need to be on to run the Application

Accelerator?
Because the Application Accelerator is highly integrated with SAP ERP, you need to be on a
specific set of releases which are outlined in SAP Note 1620213. In most cases these
requirements are not onerous, especially if you have a regular patching schedule.
You do however require a SAP ERP 6.0 Unicode system at a minimum. Depending on the
Enhancement Package or Support Package Stack you are on, you may already have the code for
the AA you want, or you may need to apply the code manually. Check the specific SAP Note for
your AA.
If you aren't able to patch or aren't Unicode then you can't use AA but you can still use the
Secondary Database connection - see below!

What additions do you need for Application Accelerator?

Application Accelerator requires 5 main additions:
1.
2.
3.
4.
5.

Kernel 7.21 (similar to 7.20 but also supports Application Accelerator)

SWT2DB as per SAP Note 1696402
System Lanscape Transformation (SLT)
DMIS_2010_XXX in the source system and DMIS_2010_700 in the SLT system
SAP HANA Database Client on both SLT and source system

What does the SAP System Landscape look like?

SLT can either be installed on the same system as ERP, or on a sidecar system depending on
your landscape. To install SLT on the same system as ERP you require SAP ERP 6.0 EhP5 with

some extensions, or SAP ERP 6.0 EhP6. Note that if you want to use the Application Accelerator,
you must be on a Unicode system regardless of if it is a sidecar.
In all scenarios, according to SAP Note 1597627 you must be on a 64-bit system and the latest
7.20 Kernel and DBSL - which you can run against any ERP 6.0 system. AIX, HP-UX, Linux x64,
Windows x64, Solaris SPARC & x64 are all supported platforms and any database which runs on
those is fine. I've also used AS/400 and official support for that is coming soon.

What if I am not on a Unicode version of SAP or an earlier release of R/3?

If this is the case then you cannot use the Application Accelerator because it is tightly linked to
Unicode ERP but there are options! You can install a separate SLT system which is Unicode to
replicate your data to HANA: SLT does not require the source database to be Unicode. This
scenario is called "Secondary Database Connection" or 2DBC.
If you have a platform listed above and you have a single codepage 1100 (Latin1 or ISO-8859-1)
then you can also use the SAP HANA DBSL driver to connect to SAP HANA from your system as
per SAP Note 1700052. This will not work if you have MDMP or a blended codepage!
Note that you still need to update your Kernel to 7.20 Patch 100 or 7.21 on your main ERP . This
means that ERP 6.0 is still a requirement for any of these scenarios although it is not a
requirement if you want to use SLT alone (e.g. For analytic scenarios).

How does the Secondary Database Connection work?

2DBC is the basis for what the Application Accelerator technology uses. It allows you rewrite your
ABAP using OpenSQL, Native HANA SQL or ADBC Native HANA SQL statements so they run
against SAP HANA. You can use this regardless of whether you use Application Accelerator but
you can only use 2DBC if you have a non-Unicode ERP.
Thomas Jung describes how to make this work so much better than I ever could in his
blog Developer's Journal: ABAP/HANA Connectivity via Secondary Database Connection

What is important to know to optimise custom scenarios for AA or 2DBC?

The most important thing is that SAP HANA accelerates complex database questions massively.
If your scenario has a small number of very complex SQL statements (like all the SAP built-in
examples described above) then SAP HANA custom AA or 2DBC will massively improve
performance.
If however you have a very large number of small SQL statements then SAP HANA will not
accelerate this because there is some overhead of the 2DBC connection - you will have to
refactor the code. Take the following example:
SELECT * INTO CORRESPONDING FIELDS OF TABLE lt_vbak
FROM vbak CONNECTION ('HAN')
WHERE auart IN s_auart
AND erdat IN s_erdat.
LOOP AT lt_vbak INTO ls_vbak.
SELECT * FROM vbap CONNECTION ('HAN')
INTO CORRESPONDING FIELDS OF ls_vbap
WHERE vbeln = ls_vbak-vbeln.

WRITE: / ls_vbak-vbeln, ls_vbak-auart, ls_vbak-erdat,

ls_vbap-posnr, ls_vbap-matnr, ls_vbap-zmeng.
ENDSELECT.
ENDLOOP.
Note that for a potentially huge selection in table VBAK (the Sales Document Header), we then
read table VBAP (Sales Document Item) for each document. This is very expensive using the
2DBC compared to what can happen if we push a bigger question down into SAP HANA as
follows:
SELECT vbak~vbeln vbak~auart vbak~erdat
vbap~posnr vbap~matnr vbap~zmeng
CONNECTION ('HAN')
INTO TABLE lt_vbak_vbap
FROM vbak
INNER JOIN vbap ON vbak~vbeln = vbap~vbeln
WHERE vbak~auart IN s_auart
AND vbak~erdat IN s_erdat.
LOOP AT lt_vbak_vbap INTO ls_vbak_vbap.
WRITE: / ls_vbak_vbap-vbeln, ls_vbak_vbap-auart, ls_vbak_vbap-erdat,
ls_vbak_vbap-posnr, ls_vbak_vbap-matnr, ls_vbak_vbap-zmeng.
ENDLOOP.
Note that in this case, we push more logic into SAP HANA and also only return the columns that
we need, which means that the SQL executed in SAP HANA will be much more efficient. It's
important to note that you should also avoid transferring large volumes of records over 2DBC the fetch times are more expensive than for a traditional database.
It's also worth noting that the SQL needs to be expensive in the first place and therefore you may
get much smaller benefits in a Development environment with a few thousand records compared
to a massive benefit in Production with a few hundred million records. You can model this by
testing SQL statements in SAP HANA Studio to compare response times.

What about write-back scenarios?

The SAP SLT technology synchronises database tables using time stamps in both directions so it
is technically possible to write back to ERP from SAP HANA.
In scenarios where you are making some updates to a transactional table e.g. Sales Orders then
I would highly recommend that you do not do this, because SLT does not handle locking as well
as your regular database will, and anyhow you will get far less benefit here than you will on the
writes because of the overhead of writing to HANA, transferring the change and committing it to
ERP.
There are scenarios where you might like to do write-backs especially during batch loads, where
you want to update large volumes of records with a complex SQL statement. If this is at a time
when the table isn't being processed transactionally by ERP then it's definitely valid to execute
UPDATE statements against SAP HANA. If you are considering doing this then please take
advice from SAP or your System Integrator.

How does licensing work?

This is the great thing: you only need to license SAP HANA for the compressed database tables
that you are transferring and not for the whole ERP size. So if you have a 500GB database table,
and it compresses 5:1 then you only need 100GB of HANA data (pl

Conclusions
The SAP Application Accelerator and Secondary Database Connection are great technologies to
get the most out of your existing

Credits
More than ever, this blog needs thanks to three people. Lloyd Palfrey from Bluefin Solutions for
correcting the technical facts that I messed up when I wrote it, Thomas Jung from SAP for bailing
me out on a couple of complex scenarios and explaining how the optimisation process works
and Tau Ming from Bluefin Solutions for giving some great examples.