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.
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
FI Line Item Browsers
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
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:
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 use 2DBC even 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.
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
INTO TABLE lt_vbak_vbap
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.
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. This may be in the context of a much larger ERP environment!
The type of HANA license you need will depend, and please always get definitive licensing information from your SAP Account Executive. If you are just using Application Accelerator then you may be able to use the SAP HANA Runtime Edition License. However if you wish to use reporting on HANA alongside Application Accelerator then you will require a SAP HANA Platform Edition or Enterprise Edition license.
The SAP Application Accelerator and Secondary Database Connection are great technologies to get the most out of your existing SAP ERP investment, without worrying about the risks of moving off your existing legacy RDBMS at this time.
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.