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.
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:
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:
The side-by-side architecture is best
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.
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:
(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:
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.
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
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
Use this option for on-premise solutions if
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
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
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
8 | |
8 | |
7 | |
6 | |
5 | |
4 | |
4 | |
4 | |
3 | |
3 |