HANA Accelerators - make the side-car your main car

[Former Member]

Making the HANA Side Car your Main Car

Let’s face it.  If you work in the SAP world and haven’t heard about HANA, you’re living under a rock (or maybe still on R2?).  In the past three years, every SAPPHIRE, ASUG and TechEd (sorry, d-Code) event has focused primarily on HANA and its benefits.  SAP is now even rewriting and pushing down their ABAP code to HANA to take advantage of its capabilities.  S4HANA and Simple Finance have the capability of drastically simplifying an organizations data models.  However, a number of customers have purchased HANA as their BI solution, but are not quite ready to take the leap to these solutions. That’s where the HANA Accelerators come in.  The HANA Accelerators (aka, HANA Side Car) allows customers to leverage their HANA investment like never before.  By redirecting the selects from their standard database to HANA, significant performance improvements can be gained with this technology.  And the beauty of this solution is that the implementation time is very fast, saving you money and improving your ROI.

The Why

If you are like most of my customers, your system performance was probably great when you first went live – especially if you did a phased rollout.  However, as time has passed, you’ve likely added additional organizations, new processes and more data to the system.  While the old saying ‘Disk is cheap’ may be true, getting to the data on the disk becomes more expensive the larger the dataset.   At least, that’s the way it’s been with traditional databases.  With the introduction of HANA, SAP has revolutionized the way that data is stored and accessed.  Through the use of the column store database, the data within the database is compressed significantly – in most cases by a factor of 7 or more (by that I mean, 7 terabytes of row store data becomes 1 terabyte of column store data). Once the data is compressed, the amount of RAM needed to put the data into memory is much less.  Accessing data in RAM is an incredibly more efficient method than having to access it via disk – even with Solid State Drives.  But to me, this isn’t even the greatest benefit – at least not from a business perspective.  Since the data is stored in columns, every column essentially becomes an index.  This has two incredible benefits.  First, there is no need to have secondary indexes on your tables.  This alone can save a huge amount of disk space.  Second, it means I can now access my data using any combination of fields I want.  From an end user perspective, this is huge.  I am no longer limited to the indexes someone else chose for me.  And what that really means is that not only can I analyze my data in ways which meet my exact business needs, but I can even design the system in ways that were never possible.

The What

While Suite on HANA is starting to gain traction, many customers would like to see a better return from their HANA investment today.  In order to do this, SAP has delivered two Accelerator products.  The most commonly known product is the ERP Accelerators. The ERP Accelerators are a collection of specific points in SAP’s standard code, whereby a redirect to HANA is performed.  The ERP Accelerators were delivered as part of the standard system with SAP Note 1620213 (and subsequent additional notes).  Below is a list of just a few of the delivered accelerators.

Table 1 - SAP Delivered ERP Accelerators

Accelerator	Transaction
FI Line Item Browsers	New
Report Writer/Painter	Existing
CO Assessments/Distributions	Existing
Asset Accounting Reporting	Existing
Material Ledger – Price Analysis	Existing
Material Document List	Existing
Public Sector – AVC report	New
Federal Government – Payments	Existing

In addition to these, there are a number of other accelerators and SAP continues to add to this list.  The accelerators can be categorized into one of the three areas:

• Reporting – These accelerators are used to select data quickly from the standard line item tables like BSEG, GLFLEXA, PSMGLFLEXA, ANEP, COEP, etc.
• Transactional – These accelerators are used within the processing of transactions like posting an FI document or running CO Allocations
• Interface – These are primarily BW related where a Virtual Infoprovider can be setup from BW

The second Accelerator product is the Business Application Accelerators.  This product allows you to redirect any of your own custom programs. The product is an add-on to the standard system and must be requested via information in SAP Note 1694697.

One additional transaction of note is the General Table Display.  If you’ve been using SAP long enough, you’ve probably used transaction SE16.  SAP has delivered a new transaction – SE16H. This new transaction allows you to select your secondary database connection and query data directly within the ERP system.  Additionally, this transaction allows you to do a left outer join with another table from your standard database or from HANA.

The How

ERP Accelerators

While most customers are unaware, SAP has provided the ability to connect to a secondary database from within the ERP system since the days of R/3 4.0B.  The transaction DBCO allows user to create a connection to another database by providing the IP address of the database server and login credentials. The HANA Accelerators utilize this secondary connection to redirect the selection of data from the standard installed database to HANA.

Figure 1 - DBCO Secondary Connection

Of course, the data first needs to reside in HANA in order to utilize this redirection.  This is where the System Landscape Transformation (SLT) product is essential.  By using the SLT, data can be replicated from the ERP system in near real time.  This provides for the use of the functionality with not only reports, but with transaction processing.  The SLT is a product that creates triggers at the database level which are executed anytime an Insert, Update or Delete occurs on a specified table. The trigger then populates a shadow table with the key of the table to keep a record of which entries need to be transferred.  The SLT system then copies the record from the ERP system to HANA using RFC connections. This entire process usually takes less than a second to go from the update in ECC to the update in HANA.  SLT does allow for more advanced ETL capabilities, but this is the basic concept.  One thing to note – in order to use the accelerators for a specific table, the structure of the table must be the same in both systems.  I’ll even take this one step further – I believe the data should be a mirror of each other (e.g. no transformations).  My reasoning here is simple – If I run a report that is not accelerated and compare it against one that is, there should be no difference in the results.

Once the basic setup is complete for connecting and replicating to HANA, it’s time to view each accelerator. In transaction HDBC (or HDBS), you can view each accelerator to determine the functionality and requirements to activate.  Each accelerator can be activated across your whole system or by user id.  Further, the accelerator can be activated and deactivated very quickly in case you run into issues.

Figure 2 - ERP Accelerator - General Settings

The key to being able to activate an accelerator is the existence of the necessary tables in HANA with the structures identical.  Some accelerators have as few as one table required, while others have a large number. In figure 3 below, the General Ledger Line Item Browser with its new transaction FBL3H requires five tables from the ERP system as well as a new generated view that can be created from this screen. The generated views are created in the ERP system as well as the HANA system – both without data.

Figure 3 - ERP Accelerator - Replication Tables

Business Application Accelerators

The BAA is an add-on product that must be applied via transaction SAINT.  The component name is SWT2DB.  To use this product, an XML file is created which defines the program and table which will be redirected.  Once the XML is uploaded, a database connection (from transaction DBCO or DBACOCKPIT) is assigned to the scenario.  The scenario is then activated and all future selects are redirected.

In my experience, the BAA is just as important (if not more so) than the ERP accelerators.  With this component, we have enabled numerous reports and interfaces to run significantly faster than before.   Let’s face it – SAP developers do a pretty good job of writing efficient code, while other developers do not have the quality assurance and performance mindset of those in Waldorf or Palo Alto.  At most of my clients, the long running programs are typically the ones that start with a Z.  As such, some of the largest gains we’ve seen is through the acceleration of reports, extracts and interfaces via the BAA.

The Results

Now if you’ve made it this far, you must be wondering about the results.  These products have truly transformed some of my client’s experiences. The end users no longer have to wait minutes and hours for reports, the O&M team does not have to stay up all night monitoring jobs, the database administrators are happy that the primary database is not dragging, and the functional team is free to organize the data any way they want.   Some specific examples of what we’ve seen are:

1. One interface was running for over 15 hours.  After acceleration via the BAA, it ran for 9 minutes.
2. The Cost Allocation program was running for over 24 hours at the end of the month – it now runs in 20 minutes.
3. The Vendor Line Item Browser would timeout and never return the data for some vendors – now it runs in less than 1 minute.
4. Depending on how some users ran reports, the system would either timeout (if in foreground) or run for days (in background).  Now the users can select their data however they want and the data is returned in seconds.

The additional speed is nice, but it really comes down to what happens when you attain this level of performance. If a report takes 5 minutes to return the data, the user will hopefully do some other work – but they may just take a short break.  If it takes 3 hours, they’ll definitely do other things, but they’ll also rarely rerun that report based on their findings.  If the report returns the data in 30 seconds, the user can do something actionable with that information (like post a correcting entry, etc.) and rerun the report to analyze the data again.  Providing a system that works for your users, improves their performance, improves the overall system performance and ensures increased satisfaction and acceptance of the system are all possible with the HANA Accelerators.