First Experience with ABAP for HANA – Evolution or Revolution?

ABAP for HANA – Revolution or Evolution?

When taking part at CEI Trailblazer I learned that SAP tried out lots of different approaches to find the best programming model for ABAP applications on top of HANA. So we had to learn about the new toolset ABAP in Eclipse and many new ABAP frameworks and techniques – in fact all represented different approaches and programming paradigms. Some of those frameworks are revolutionary in the sense that they are powerful and sophisticated – but do they allow agile development and “taste” like SAP Business Suite? We tested very conservative techniques like Open SQL with HANA as primary persistence and it worked fine and often brings immediate success. I learned that other approaches fit perfectly to HANA like OData with its filter and paging techniques.

It seems to me that SAP tried many approaches to optimize ABAP for HANA. In the end SAP made a bunch of smart decisions:

• If you want to create HANA optimized applications you need a development environment “near” to HDB studio – and ABAP in Eclipse was an excellent choice.
• If you want to make it possible that ABAP for HANA applications can be ported back SAP Business Suite you have to keep the code lines compatible.

This may sound very conservative but if think this an evolutionary step towards a new business platform. With HANA SAP started a revolution and is now evolving the SAP Business Suite:

• Of course ABAP applications can profit from HANA right now but we need HANA optimized frameworks and techniques to build applications that use the full power of In-Memory technology. I think with ABAP and HANA we have the chance to build business applications that will give us an advantage in competition.
• There is already a lot of code in SAP Business Suite and Partner solutions, so we need a more conservative approach to tackle existing bottlenecks to take full advantage of HANA technology.

SAP knows that the only way to evaluate a new technical framework or programming paradigm is to confront it with reality: can we use it to build business applications? And this is why they worked quite close together with customers. It is absolutely necessary to create a proof of concept and discuss challenges from customer scenario like the following: How do you deploy the solution? How to deal with archived data?

Please let me summarize: ABAP on HANA will bring new features, paradigms, tools and will enable you to develop amazing applications. Be prepared to learn many new things – but please recognize that SAP started an evolutionary process and I will mention the most important aspects:

• The ABAP codeline optimized for HANA (NW 7.4) is compatible with AS ABAP 7.31.
• If you want to build a new application with NW 7.4, you can start with a side-by-side scenario. Later you can also deploy your application on the SAP Business Suite with HANA as primary persistence, since this will also use NW 7.4 (at the moment the SAP Business Suite does not yet support HANA as primary persistence, but SAP is working on this).
• The side-by-side scenario may a little bit painful and the side-by-side scenario has some restrictions but uses mature technology – in fact I blogged about good old SAP Landscape Transformation tool before so I recommend to read it when you want to learn more.

Let me picture three scenarios. The following picture shows the side-by-side approach with accelerators:

The following picture shows a side-by-side scenario with an additional AS ABAP (7.4) as platform for new application. This application server has HANA as primary persistence and can create own business objects and also start processes in SAP Business Suite. The AS ABAP has (readable) access to replicated data of SAP Business Suite (and of course other data stored in HANA).

In the future the big picture will be look much simpler: SAP products will run on HANA as primary persistence (like SAP BW already does) and we don’t need any replication and no AS ABAP 7.4. Our HANA optimized custom applications running on AS ABAP will be deployed and running in SAP Business Suite:

I mentioned above evolution of ABAP is a fast process but it is not disruptive as it could be. During Trailblazer we explored more “disruptive” features. I really like some of them and perhaps they will be available in the future but I’m sure SAP will find a way to introduce them smoothly. Evolution is a very promising strategy because it brings immediate help to existing pain points and allows feedback cycles. Perhaps I can summarize it in a few words: SAP speeds up but allows the Ecosystem to follow.

Let me mention some advantages. If you want to optimize existing programs on NW 7.4 you have both: the new HANA-optimized application and the non-optimized application. The latter is a fallback solution if the new program is not mature as you expected: the SAP user can still use the old transaction if a problem occurs. This is important because you have to learn a lot new concepts starting with administration, new programming paradigms and more. This will take some time and you will make mistakes. So I recommend the following:

• Start developing “simple” HANA-based applications that cure existing pain points. Take you time to learn new features of NW 7.4 and HANA “proprietary” languages. Of course you don’t have to use all new features of NW 7.4 – my recommendation is to start with good old Open SQL and use new features only when necessary.
• Then start to develop more sophisticated HANA optimized applications and integrate non-SAP data and get deeper into the topic operational reporting perhaps with integration of Crystal Report tools.

ABAP for HANA Roadmap

SAP communicated the ABAP for HANA Roadmap on SCN. Please let me sketch the most important features:

1. Some products like BW are already HANA-ready with HANA as primary persistence (BW 7.3 and higher). SAP Business Suite on HANA will use NW 7.4 as platform.
2. As long as HANA is not your primary persistence you can use a side-by-side scenario where operational data is replicated into HANA as secondary persistence. With SAP LT you can define a real time or periodic replication scenario. You can query those data using a secondary database connection using ADBC (or native SQL) from any AS ABAP system.
3. With SAP HANA Application Accelerator you can configure SELECTs to HANA as secondary persistence without any modification. There are some restrictions like Kernel release for this non-invasive accelerator: It is available only for special customers, you need a special kernel release and you have to check carefully whether this is feasible. If an SAP standard program expects that a database update is written to the database so the next LUW can read the changed value then this scenario is not helpful. So SAP will help you to find out whether this scenario is feasible.
4. SAP develops own accelerators (let me call them “programmatic” accelerators) like SAP CO-PA accelerator that pushes down calculations to the database. Those accelerators are deployed by means of Rapid Deployment Solutions (RDS). You can also develop “programmatic” accelerators for customer-specific programs.
5. With AS ABAP 7.4 you can create HANA optimized applications running on an AS ABAP with HANA as primary persistence but working replicated data from a SAP Business Suite System.

So what is the advantage of an HANA optimized application? The development of an application is easier:

1. We have better tool support: you can access HANA views as database views, calls of stored procedures is easy.
2. There are HANA optimized frameworks: there is an HANA optimized ALV grid that allows paging – only visible data is loaded from the database.
3. CTS can transport HANA artifacts together ABAP code.

The most important thing is that we can develop HANA optimized applications and get immediate value for HANA investments. Those investments are safe because we can deploy those apps on SAP Business Suite systems as soon as they have HANA as primary persistence and a side-by-side scenario is not necessary any more.

There is another reason for HANA optimized scenarios in a side-by-side approach: The non-HANA code is still there and working as fallback solution if you have trouble with HANA or the SAP LT replication scenario. To be honest I don’t expect such problems but for customers that don’t have much experience with administration of those tools, this could be a benefit: we can get more experience with administration of those tools, can make administration mistakes and still have high availability.

But the most important reason why you should build HANA optimized applications is, that they have amazing properties because they can benefit from the technology directly: they give you access to data in real time, you can navigate and calculate on huge data sets in real time, and you can visualize them in real time.

Some Rules of Thumb for HANA optimized ABAP code

I learned that SAP is working rapidly on that topic so many things will change but I tell you what I have learned:

1. Many development guidelines stay the same, f.e. avoid selection of too much data (too many columns, too many rows), ARRAY FETCH is better then SELECT … ENDSELECT and so on.
2. Start with Open SQL first and use HANA proprietary features if it is necessary.
3. Learn SQL – and program set theoretic SQL with UNION and use JOINs.
4. Learn HANA specific SQL features and SQL script.
5. Enterprise Data as well as their models are a strategic asset for a successful enterprise IT. Avoid too generic data models for your enterprise data model. Generic data structures that can only be evaluated on the application server layer can’t benefit from HANA. 
6. Push calculations to the database.
7. Get inspired by AJAX-like techniques, develop paging-access to database tables, avoid processing in main memory and load data if it’s necessary.
8. Improve your BI/BO and data visualization skills and enhance your application with dashboards. When working with SAP UI5 don’t fear to use Open Source JavaScript frameworks like D3.

And one last word: Don’t think that you are doing “In-Memory” all the time because as ABAP developer you know how to use internal tables. There are many differences and the most important is that HANA is an optimized platform for multi-core processing. So I recommend you to get familiar with the basic HANA features and programming languages. 

BW on HANA is a topic that would deserve an own blog entry so I won’t cover it here. If you want to know more about our experiences with BW on HANA then you should read the slides of Udo Patzelt in his talk about the in-memory strategy of my company at DSAG Jahreskongress.

Learned Lessons from Trailblazer

A Customer Engagement Initiative is a good way to acquire new skills. But it requires time and good preparation pays off. Sometimes you are working with experimental prototypes so don’t be surprised when they are not stable and robust compared to products from SAP that are general available.

Even if the realization your prototype doesn’t cover all aspects I recommend to ensure that there are concepts for aspects you will be confronted in real life:

• UI integration especially in side-by-side scenarios,
• deployment and
• integration of tool chains especially in advanced scenarios (think of Crystal Reports integration).

During “Trailblazer” I started to think about business intelligence for transactional data and found that there are many interesting approaches to that topic like data science and data visualization tools that are used by so called data scientists. The book Getting Started with D3 shows what data scientists can do just with some lines of JavaScript. But Data Science is more than creating some neat graphics – it means deep insight into business and as application developers we will bring this aspect into SAP Business Suite in the future.

When building the trailblazer prototype one of the reasons I chose D3 was to learn more about SAP UI5 and especially its openness. But in fact I prefer to use SAP’s BI tools instead for creating dashboards for operational data. If you want to learn how to do it you should watch out for VDL – the virtual data layer but this is a topic for another blog.

Challenges

Creating a HANA optimized application with AS ABAP 7.4 is easy, but what about creating more than one? Now it gets interesting:

• What are best practices to guarantee that HANA optimized apps can be ported smoothly to SAP Business Suite when HANA becomes primary persistence?
• We have duplicate code – can we do automatic tests to the results of both against each other?
• How can we build them efficiently and support the new paradigm “code to data” better?

SAP is continuing the Customer Engagement Initiative and I hope many people will work together with SAP to find solutions for these and other challenges.

But the greatest challenge is knowledge transfer. When my talk at DSAG Jahreskongress came to Q&A I learned that people have many questions. Let me give you an example: I was asked whether one has to use ABAP in Eclipse or can still use good old SE80. The answer is simple: you can still use SE80 but I recommend to give ABAP in Eclipse a try (also because new features might only be made available in Eclipse).