White Paper

Accelerate your existing SAP ERP Processes using Application Accelerators

Milind Mungaji

Monday, September 26, 2016

Table of Contents

Abstract

1. The SAP HANA Application Accelerator for SAP ERP

2. Case Study/ Demo Scenarios

3. References

Abstract

This white paper intents to improve the performance of the existing SAP applications running on ECC systems using SAP Application Accelerator Addon without the need to install the SAP High-Performance Analytic Appliance(HANA). The Application Accelerator, or Suite Accelerator, is an application which 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.

Here are some of the scenarios where Application Accelerator would add value!

Ø 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

What if I want to speed up my own application scenario?

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.

1. The SAP HANA Application Accelerator for SAP ERP

1.1 Minimum System requirements:

1. SAP ERP 6.0 Unicode system.

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

3. SWT2DB as per SAP Note 1696402

4. SAP Lanscape Transformation Replicator (SLT)

5. DMIS_2010_XXX in the source system and DMIS_2010_700 in the SLT system

6. SAP HANA Database Client on both SLT and source system.

1.2 Configuration Steps:

a. Customizing:

Ø Activate Redirect Database Access (RDA)

Ø Define Scenarios(table, main program, job name)

Ø Maintain Secondary database connection

Ø Upload and activate scenario XML

Ø Set Secondary Database Connection per Scenario

b. Additional Steps:

Ø Replicate identified tables using SLT

Ø Run your program

Ø Verify selects are executed against HANA(ST05)

Ø Check replicated tables in HANA using transaction SE16H

Benefits of Accelerators:

Ø Speed up SAP ERP Processes by reading the mass data (time consuming selects) from SAP HANA.

Ø Keep existing reports

Ø Protect investment

Ø Limited changes to existing coding

Ø User Acceptance as there are no UI changes.

Ø Preserve Authorizations

Ø Easy Implementation-> Easy to switch ON and OFF.

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. This may be in the context of a much larger ERP environment!

2. Case Study/ Demo Scenarios

2.1 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.

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.

4.2 Scenario Accelerators

Ex. SAP CO-PA Accelerators