Architecture Alternatives for Transactional HANA A...

former_member182046 · ‎10-25-2012

Few technological areas are as rapidly changing as HANA, where the momentum originates not only from the evolving platform itself, but also from neighboring components such as the ABAP application server as their integration with HANA improves and new options arise. With SAP TechEd 2012 Las Vegas just behind us and HANA positioning itself more and more as a platform that is suited not purely for analytical applications but also for transactional apps, it is time to take a pulse check and get an overview of the different architectures currently available for such applications.

1. AS ABAP with HANA Side-by-side

This is a classic architecture that has been around since the first days of HANA. Depending on your ABAP release, the integration is more or less comfortable and well-supported by an unbroken tool chain.

In this scenario, your ABAP server still uses its classical database as its primary persistence, but it is also connected to a HANA database which serves as its secondary persistence. It uses a replication service (usually SAP Landscape Transformation) to replicate a subset of the application tables into HANA's column store.

While most write and read database operations will be against the classical system database, a careful selection of queries will be against the mirror tables in the remote HANA database. These will be queries that are performed immensely faster in HANA, such as calculations involving large numbers of records.

Depending on the ABAP release (AS ABAP >= 7.0 with Kernel 7.20, AS ABAP 7.40), accessing the HANA remote (often but not necessarily mirror tables) will be more or less difficult and/or different from accessing local tables.

Previously existing (>= 7.0) features to access HANA via a secondary database connection:

Native SQL access via EXEC SQL
Object-based and dynamic SQL access via ADBC (documented since 7.02)
OpenSQL if a table of the same name and structure exists in the local system
Call HANA stored procedures via Native SQL or ADBC
Application Accelerator that allows you to switch database access in particular reports from the primary to the secondary persistence by configuration - without making changes to the code

It is dubious if side-by-side scenarios make sense in 7.40 and beyond, where HANA doesn’t have to be accessed via secondary database connection. Therefore, it is currently not clear whether the following 7.40 features, which were developed for access to the local HANA, are also available with respect to a remote HANA:

transport management system integration of artifacts in a remote HANA (?)
call stored procedures via native CALL DATABASE PROCEDURE command (?)

The side-by-side architecture is best

if upgrading your Business Suite systems or migrating them to HANA is currently not an option
if you can't wait for Business Suite on HANA to become available
If you architect your sidecar-based solutions carefully, you will later be able to migrate them to an "ABAP on HANA" architecture with none or few code changes.

If you develop for more than one deployment, I recommend making any part of your solution that depends on HANA optional. Use the Switch and Enhancement Framework to make the parts that call out to the HANA database switchable Business Functions. This way, you do not lose the potential customers who are not (yet) on HANA but offer added value to those who are.

2. AS ABAP with HANA as its primary persistence

This is the scenario that is already in use as "BW on HANA" (technically available since 7.30, but we’ll ignore that as we’ll be good girls and boys and refrain from building transactional applications in BW system) and that will be used in "Business Suite on HANA" on AS ABAP 7.40.

HANA is no longer a sidecar but replaces the system database of the ABAP system. As the primary persistence, all the write and read database accesses go directly against the HANA database.

SAP has announced in early 2012 that the first customers will receive shipments of Business Suite of HANA before the end of the year, but it won't be generally available then.

Personally, I expect a formal ramp-up in Q1 or Q2 of 2013 and General Availability four to six months later, or perhaps another stage with increased but still controlled availability in-between (?).

The reason I expect this prolonged period of making the solution available step by step is that SAP will try hard to avoid bad press for Business Suite on HANA, as the product quality and stability at the very point of convergence of their two most important products will have a huge impact on the reputation of either, and bears the danger of either or both suffering a serious reputation damage if the combination turns out to be unstable or immature at the moment of General Availability.

However, while I expect SAP to play it safe when it comes to releasing the software for productive use, they can play out their speed when it comes to allowing the developers community to get their feet wet and build their skills. Therefore, a cloud-based trial system auf AS ABAP 7.40 optimized for HANA has been announced for Q1/2013.

We have heard the disclaimers a thousand times: Features are never definite before the release is really out, but based on presentations from TechEd 2011, 2012, and DSAG Annual Conference 2012, we can expect with ABAP 7.40:

OpenSQL optimized for HANA
Data Dictionary integration for HANA artifacts (tables, Attribute Views, Analytic Views, Calculation Views)
"CALL DATABASE PROCEDURE" ABAP command to call Stored Procedures
ABAP in Eclipse to integrate with HANA Studio
Transport Management System integration with HANA-specific artifacts

(Side note: It’s still unclear which of these features will be available for an AS ABAP 7.40 with HANA side-by-side scenario. The scenario is admittedly a little exotic because getting rid of a secondary persistence is the main reason for upgrading to AS ABAP 7.40, but exotic situations always occur sooner than hoped for, so I look forward to finding out more about this soon.)

HANA as the primary persistence is the go-to architecture for all transactional applications written in ABAP. It’s best for the following cases:

to build new stand-alone or loosely integrated applications if your company has great ABAP skills and the Business Suite is pretty much at the center of your application landscape
to accelerate existing ABAP applications (such as the SAP Business Suite)
if a very high degree of customizability, configurability, and extensibility is required
you want to leverage the existing ABAP skills in your company

Similarly to my architecture recommendation in the Sidecar section, I recommend to encapsulate all dependencies from HANA by using switchable Business Functions built with the Switch and Enhancement Framework. This way, your solution will be compatible with your customer's landscape regardless of whether or not they use HANA but offer added value if they do.

3. Java Server with HANA Side-by-side

This scenario is the least likely in the list, but I know of cases where it is being discussed as an option. It is similar to the "AS ABAP with HANA Side-by-side" scenario except that

instead of an ABAP server, a Java server (Java EE server or more lightweight Web Container) is used
you have to solve the question of data replication from the primary, non-HANA database into HANA with some other mechanism because SLT Replication Services are not available for non-ABAP source systems (?)

4. Java Server with HANA as its primary persistence

This is the architecture SAP uses in "NetWeaver Cloud" a.k.a. Neo: Applications perform all database write and read accesses directly against the HANA database and use stored procedures written in SQLscript to push calculations and transformations down to the database. No replication is necessary.

If you want to use this architecture for a custom-built, on-premise solution, please bear in mind that

AS Java (e.g. in NetWeaver Composition Environment) still requires a classical non-HANA database as its system database so this will be a sidecar scenario from a system landscape perspective, although not from an application perspective, and the TCO will be accordingly high (?)
there are JDBC drivers to send SQL to a HANA database but you'll have to check how good the support for calling SQLscript based Stored Procedures is
As michael.bechauf points out in his excellent blog about types of HANA apps (http://scn.sap.com/community/hana-in-memory/blog/2012/10/25/native-hana-apps-language-containers-and...), you may run into problems because Hibernate is currently not compatible with HANA
when I last checked, you were not supposed to install additional non-SAP software such as a Java EE server directly on the HANA appliance, resulting in the need for an additional server node for the application server and causing database connections to physically go over the network

Use this option for on-premise solutions if

you're primarily a Java shop
you’re porting previously existing Java applications to HANA
the Business Suite plays no or no major role in your system landscape but Java and HANA do
you're a risk taker

5. HANA Application Services (XS)

This architecture option is new with SAP TechEd 2012 and we don't know many details about it yet. However, this is what I've been able to pick up: HANA Application Services (XS) comes with HANA as of the latest release (SP 5, Customer and Partner pilots only until HANA 1.0 SP6 ) and is a lightweight application server built into the HANA appliance that can contain server-side JavaScript business logic.

You implement calculations and transformations in SQLscript at the database level, higher-level and process (“control flow”) business logic at the XS engine level, and expose that via OData services to the UI level, which is supposed to be built using SAP UI5 but may of course be built with any user interface technology capable of consuming REST-style OData services.

On the infrastructure side, the server contains a HANA repository which offers features familiar to those who use the AS ABAP: object management, versioning, transport, and so on.

Use this architecture option

to build standalone applications with few or no dependencies to the SAP Business Suite
if you have good JavaScript skills (other languages may become available for server-side execution in the future)
to keep TCO low by avoiding an additional application server outside the HANA appliance

Showdown: ABAP on HANA vs. HANA Application Services

I believe that in the near future, most customers and partners, when building transactional application on top of HANA for on-premise use, will choose between the "ABAP on HANA, primary persistence" and "HANA Application Services", depending on how tightly the new application or extension is coupled with the Business Suite and whether the existence of ABAP on HANA servers can be assumed. Let me add another criterion that will tip the scales in the case of a close call between the two architectures: Extensibility.

As you probably know very well, the ABAP server is pretty much singular in offering enterprise-level extensibility and application lifecycle management tools. It possesses an unbroken tool chain for extending enterprise applications in a modification-free way that includes features such as

ABAP applications being source-open
the possibility to merge customer-owned enhancement code with SAP code at runtime
a modification assistant helping with the management of modifications
support and management tools for explicit and implicit enhancement points
delta handling and version conflict handling tools
integration into the transport management system
in fact, even the existence of a revision-proof transport management system for configuration changes
integration of the customizing tools and transport system with a project management system for complex configuration projects
a switch framework for consistent handling of configuration-dependent system states and enhancements,

to name just a few.

Whenever a custom-built solution on top of HANA needs to be heavily configurable and requires modification-free extensibility of data structures and business logic (e.g. when Independent Software Vendors build standard software targeted at multiple customers), it is safe to assume that for the time being, the ABAP server will have an edge over the HANA Application Serves (XS). It seems that they are building a good and comprehensive tool chain, but it would take a long time and a tremendous effort on SAP's part to replicate those features outside the ABAP system, and I don't believe they will try to even replicate the first 80%. (Otherwise, the lightweight, speedboat character of the platform would be very much as risk.)

On the other hand, the HANA Application Services have an edge over ABAP for lightweight, standalone or loosely integrated applications and when you want to use the skills of your strongly web-oriented, "long-haired", non-SAP developers.

Conclusion

Architect for the future and for rapidly changing boundary conditions. You can achieve this by architecting clearly, anticipating refactoring, investing early into preventing architectural decay, and separating concerns well (collapsing the layers or not).

I recommend that you stay in touch with the HANA and general SAP community to be informed about new and changing options and to keep reducing TCO for your custom-built HANA-based solutions as new options become available.

Finally, when you build or refactor your own applications on top of HANA and gain expert knowledge in the process, share your expertise with the community. It's a win-win situation - you can recognition and everybody else learns from you. The Force is strong in you.

SAP TechEd Las Vegas 2012 sessions

CD100 – SAP HANA – Application Services
CD162 – Accelerating ABAP Applications Using the Best Features in SAP HANA
CD163 – SAP HANA – Application Services Hands-On
CD202 – ABAP for SAP HANA: Building Business Applications Optimized for In-Memory
TEC105 – SAP HANA Database for SAP Business Suite
TEC106 – SAP NetWeaver AS ABAP for SAP HANA – The Future of the ABAP Platform