Architecture Alternatives for Transactional HANA Applications – An Overview
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-hana-cloud-part-1-of-2), 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
Hi Thorsten
Thank you for this great and insightful blog post. Your last section on extensibility is the real crunch point in my view, because that's where from an enterprise perspective the real benefit lies: stable core processes, allowing easy future upgrades, yet still customisable. As you point out, ABAP on HANA has the edge in this respect.
With ERP for HANA on the horizon, there will be a lot of time spent on making past custom changes work in this new column-based database world. If customers disregard this point and simply run their ERP "as-is", then they will never reap all the HANA benefits. It will be interesting to see how ERP for HANA will deal with existing enhancements and what kind of enhancement framework integration we will see (maybe with the existing, tried-and-tested Enhancement Framework?). The amount of consulting work to be done in this area will have a big impact on buying decisions for HANA.
The near future is looking very exciting and promising indeed!
Thanks again for this!
M
Michael,
Thanks for your feedback, and I agree completely.
In my view, the
for handling existing and future enhancements to handle a coexistence or smooth succession of non-HANA and HANA deployments of the same business software are perhaps the biggest challenge for the adoption of HANA. This is something I'm focusing on and I'll continue to collaborate with SAP on this topic to bring in the customer and ISV perspective... just like you always bring in the consultant perspective. 🙂
Cheers,
Thorsten
Hi Thorsten
Excellent post with comprehensive coverage of various architectural options. It would be more fun if we add mobility to all these architecture discussions 🙂 Does any of the architectural options or recommendations change?
- Pankaj
Pankaj,
Thanks a lot for your feedback and encouragement! Yes, I agree I had to leave mobility out and it hurt me a bit to have to define the scope of my blog so narrowly. There are many other interesting types of HANA-based applications I had to omit for various reasons:
I expect to see many interesting blogs, and I hope some of them will be from you, as you told me you've been quite busy working with NetWeaver Cloud lately. 🙂
Cheers,
Thorsten
Hi Thorsten,
great comprehensive blog. I think between what you, Dick Hirsch and I have blogged about, plus the comments from Matthias the whole HANA platform & cloud topic area is now well covered on SDN.
The only thing that gave me pause was this:
The part I didn't understand was why you prefaced this paragraph with "near future". Strategically, I think it's clear where SAP is going, which is HANA as a primary persistence for the Business Suite. Technically, we'll get this done, and will overcome the natural performance disadvantage of using Column Store tables in an OLTP scenario.
But when you say "near future", I look at the next 12 months. With ERP on HANA not even released, people will be busy with migrating Business Suite to HANA as a database, and using new applications from ERP on HANA within the Business Suite. I'm not sure whether on top of that, developers will have the opportunity to build custom transactional HANA applications in the Business Suite system.
The other part I don't understand is why you say "ABAP on HANA, primary persistence" vs. "HANA Application Services". This is not an "either/or". On the contrary: You will see that a lot of Business Suite applications with HANA as a primary database will in fact by built with HANA Application Services. The question that I can't answer, and for which Thomas Jung may have a clearer line of sight is whether HANA XS is a good use as a transactional framework vs mostly read-only analytical applications, and here is why:
When you say "transactional" it means two things for me:
1 - All the fancy user interface tools like input validation, seach help etc, which XS will get for free from SAPUI5, so that should be covered.
2 - The fact that you need to maintain state in a transactional application.The reality is that each transaction keeps the many fields that are being enterered in main memory until it is committed to the database.
XS, however, is completely stateless. It doesn't mean that XS can't do INSERTs and UPDATEs on the database at all, but I don't see how it can provide the typical transactional application behavior of SAP transactions.
In addition, transactional use of XS in the Business Suite will bring up the interesting question to me how XS can integrate with the rest of the ABAP-based Update Task ("Verbucher"). XS would commit database transactions on the HANA level, whereas ABAP transactions commit through the Update Task. That would likely require some smart thinking, that I'm sure somebody has alread done, but that I just don't know about.
So, in summary, if you were to propose how to build HANA based transaction applications on a Busines Suite in the near terms (next 12 months), I think the only options is ABAP AS with HANA side-by-side.
Cheers,
Michael
>may have a clearer line of sight is whether HANA XS is a good use as a transactional framework vs mostly read-only analytical applications
I agree with the points you made about transactional. At the core, of course you can execute SQL INSERTS and UPDATES from XS. You can even wrap blocks of such operations into SQLScript Procedures for better encapsulation and referential checks. Some of the first examples of XS applications actually combine the Analytical and Transactions worlds into one application. We sometimes call it the Insight to Action pattern.
However, that said I wouldn't say that we yet have the level of transactional supporting services that the Business Suite has. XS (in the current release at least) lacks a higher level entity model, foreign key enforcement, central lock management, etc. These are things we intend to add over the near future in order to make creating transactional applications more friendly to the application developer.
Now XS performing transactional updates on ABAP based systems: I think there simliar rules would apply to any environement interacting with the ABAP Database (even ABAP itself) is that you want to avoid direct database updates to SAP tables. There you would want to consume the ABAP logic that already exists. This is where XS will in the future have the ability to also make outbound HTTP requests and consume RFC - both planned enhanements for a future HANA Support Package.
Excellent conversations from Thorsten, Thomas & Michael.
Great post!
Is there an update on last years poistion that has been published? It would be interesting to know your view on where we are now and the direction for the coming year.
Derek,
Thanks a lot for your feedback. Good idea to revisit this blog post with a view on what is still accurate and what needs to be changed or added one more year down the road to HANA. I've just hosted an interesting HANA strategy workshop and might have something to add in January, time allowing. Another item on that big old scary to-do list. 😉
Best,
Thorsten
Another seminal piece. This should be required reading for all HANA developers. Have you considered approaching openSAP about doing a course? I'd sign up for it in a heartbeat. Thanks for taking the time to lay this all out so well.
Moya,
Thanks a lot your flattering words - very happy you enjoyed the post. Doing a course for openSAP would be neat, excellent idea. 🙂 I might actually approach them with this suggestion in January!
Cheers,
Thorsten