Skip to Content
Author's profile photo Richard Hirsch

HANA Native Developer experience in the HANA Cloud Platform: A problem solved

During the Sapphire in Orlando, there was an exchange of tweets between Fred Verheul and Aiaz Kazi regarding developer experiences.

Note: There is a no-agreed upon definition of “developer experience” – so in this blog, I’ll be using a very broad interpretation.


I totally agree that there are three different dev experiences (Native, Integrated and Open) but where I disagreed was the restriction of the dev experiences to particular parts of the HANA Cloud Platform (HCP).

In a comment to Aiaz’s Platform blog, I stated my dilemma:

I think it is also interesting that you distinguish between the HANA DB and HANA Native development.  For me, the two are inseparable; therefore, I find the current inability to use native development in the Java PaaS such a major problem.

Here is how Aiaz’s responded to my comment:

HANA provides database and application server capabilities that can be accessed through native application development.   No separation was implied – so you are right – they are inseparable.  Now about the Open dev experence through Java – by its very nature you are using a JVM /Java App Server/ run-time – so the app development is not native at the outset.   As part of the product evolution I know the team is looking at supporting access to more of HANA’s underlying data management, predictive, text search etc. capabilities.   I’d like to see more use cases that require this

I considered this reply a challenge, so I decided to blog about such scenarios.


Before we begin, let’s define a few topics that will be relevant for our upcoming discussion.

What is the HANA Cloud Platform?

Here is Aiaz’s definition:

SAP HANA Cloud Platform is SAP’s in-memory cloud platform, our Platform-as-a-Service offering enabling developers to build, extend, and run applications in the cloud. It provides developers a set of application and database services and features native, integrated and open developer experiences [SOURCE].

Here is his diagram of the HANA Cloud Platform:


[SOURCE] (I’ve added RDL to this diagram)

What is the HANA Platform?

Here is the marketing description:

SAP HANA is an in-memory data platform that is deployable as an on-premise appliance, or in the cloud.  It is a revolutionary platform that’s best suited for performing real-time analytics, and developing and deploying real-time applications. At the core of this real-time data platform is the SAP HANA database which is fundamentally different than any other database engine in the market today


Here is the diagram of the HANA Platform.



Although not explicitly shown in the diagram, HANA XS is also part of the HANA Platform in that it can also be used in a variety of environments including OnPremise HANA deployments.  


Note: As usual, I’m starting with relatively simple diagrams and building on them – so bear with me.

We now have two platforms that are related to one another.


The HANA Cloud Platform (HCP) includes the HANA Platform. I’m purposely describing the additional functionality vaguely as “Cloud Stuff” – but I’m assuming it is the Extended and Application services layers.

Now let’s add the developer experiences:


Now, let’s take a closer look at the Hana Cloud Platform – at least in current form.  What we are going to do is associate the developer experiences described by Aiaz and associate them with concrete parts of the HCP.  

Note: RDL is a special case. It is currently not publicly available and will just be part of the SPO7 release planned for December 2013 – yet since it is a design time tool that generates native code, I’m going to associated it with the Native development experience.

Now let’s zoom into the HANA Cloud Platform.  We are going to split up the two main groups– HANA Platform and the Cloud Stuff. The HANA Platform is manifested in the form of the HANA One offerings and to some degree the HANA Enterprise Cloud.   The “Cloud Stuff” is the PaaS offering with a HANA DB hidden under the covers.


Why is a change necessary?

The power of HANA requires a shift in how developers look at the database.

Here is a slide that shows the impact on ABAP developers


Developers working with the HANA Cloud Platform should also be provided with similar possibilities and this functionality requires access to the native developer experience. Being able to exploit HANA usually requires the creation of procedures in SQLScript, etc.

If we consider larger developer teams where different roles (UI developer, HANA native developer, Java developer, etc) are involved, then each role has their own accustomed developer environment / toolset which optimized for the task in question. A Java developer can use a text editor to create his code but he won’t be as efficient as if he was using Eclipse.  This means that someone working natively in HANA requires the HANA Studio.

I’m not alone

Lately, I have watching the HANA Cloud Platform forums on SCN and have seen an increasing number of developers who have similar needs:

Also, is there any way we can view the database for the HANA Cloud DB? I found a way for that only for MaxDB, not for HANA DB. [SOURCE]

I have deployed my server artifact and deployed on hanatrial space. I would like to access the database (Hana Database) in the studio.Is it possible to access the database? Can you please share the username and password to access the database? [SOURCE]

We have been developing an application natively using HANA XS using AWS instance using Javascript.

Just wondering can we deploy this application on HANA Cloud Platform anyhow, as it also acts as the application server. [SOURCE]

Please let me know how can we use HANA DB on HANA cloud from with in our Java application for Analytic’s.

We are already using HANA for persistence but now want to leverage the PAL capabilities are well.

From HANA documentation its clear that there are some steps that need to be followed in order to achieve this such as: creating AFL_WRAPPER_GENERATOR and generating a PAL Procedure etc.

On HANA Cloud how do we proceed to do this. Or is this available via JNDI or through some other stored procedure that cloud already provides and application can call. HANA Cloud documentation points nothing in this direction so I am clueless. Please help. [SOURCE]

An initial solution

While exploring the SAP guthub repo, I found an interesting project called “cloud-hana-scriptview-demo” which has the following description:

This is a sample web application showing how one could use SAP HANA Scripted Views in SAP HANA Cloud Platform. The application also aims to show the benefit of using “Remote Database Access” tools provided by “SAP HANA Cloud SDK 2.x. #cloud-sample

The same developer Dimitar Tenev had created a similar project called cloud-hana-search-demo that I also been watching. In this project, Dimitar was working with what looked like HANA-specific code (I wasn’t sure based on the syntax of the procedure that he used in this project). 

As I was looking in the newer project, I finally found what I was looking for.  Here is the procedure that was being loaded:

CREATE PROCEDURE "manager/SCRIPTVIEW/proc" ( OUT var_out "manager/SCRIPTVIEW/proc/tabletype/VAR_OUT" ) language sqlscript sql security definer reads sql data AS   
result = SELECT * FROM "MANAGERS";  
var_out = SELECT  
       A."BUDGET"*100/(select sum("BUDGET") from "MANAGERS") as "BUDGET_PERCENTAGE_SHARE"  
FROM :result A;   

This was indeed HANA-specific code (sqlscript) that was being loaded directly into the HANA DB via a java-loader.

Finally, I had found proof that it was really possible to work with the underlying HANA DB with native code.

In a comment on his HANA-search blog, Dimitar describes how they created their native code.

We used HANA Studio (connected to our local HANA server) to create/test the SQL code for the search demo application. We wrote procedure by hand in HANA SQL editor.

The associated native developer experience for HCP devs was complicated and involved two different two toolsets – not ideal but it worked.

Ask and you shall receive

I’ve been busy lately and this blog has been in progress for too long.

I was reading today’s HANA Cloud Platform release notes and saw this new feature:

The Remote Database Access Tool (beta) now provides a SAP HANA studio integration feature that allows you to remotely access the SAP HANA database.

Here finally was the functionality to bring the HANA-native development experience into the HANA Cloud Platform.

This functionality is based on Remote Database Access Servlet and is directly embedded into the SAP HANA Studio.

This feature was just released today, so I haven’t had time to play with it but it looks like your HANA Cloud Platform DB can be used as a normal HANA System which should provide developers with the expected feature set.

This means that we now have this diagram:


I’m now much happier but – and there is always a “but” – I’d like to see two entities merge even more.   For example, can you use the HANA code repository to check in non-HANA Code (java code, etc), what about using more XS-related functionality (OData, etc). It is only when there is one single entity that the HANA Cloud Platform will be able to achieve its true potential.  

In the past, the HANA Cloud Platform was a platform for JVM-based development with the HANA DB playing a secondary role in the architecture – the presence of the HANA DB really wasn’t noticed – it was just another DB. The new feature for native HANA development released today should transform the platform into a true HANA development platform in which developers can exploit the best of JVM-based and HANA native possibilities.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Matthias Steiner
      Matthias Steiner

      Hi Dick,

      thanks for touching upon a very important topic and as such giving me the opportunity to share my thoughts and provide some insight into our vision regarding the SAP HANA Cloud Platform.

      There's a few things I do not agree with, yet all in all we are not too far of each other's opinion.

      As the close observers will have noticed SAP sees the need to bring SAP HANA into the cloud to provide an additional deployment option and usage scenario. That's not too surprising looking at our past outbound communication and broader vision for SAP's future technology mix. The recent evolution (shining through some of the rebranding that took place) indicate that SAP HANA will be a 1st class citizen in the cloud and powering all sorts of application - regardless of the programming model (developer experience) being used.

      For quite a while now Java developers have been able to leverage some of the SAP HANA capabilities such as defining column-store tables and executies SQLscript. The corresponding online help chapters are here:

      Creating SAP HANA Column-Store Tables

      Persistence Service

      As you pointed out you can also use other capabilities like (fuzzy) text search and creating 'Scripted Views'. The dev team already blogged about the first topic, more are coming very shortly. (See Enhance Your Cloud Application with HANA Search)

      Today we released another importact piece, the capability to remote connect to your dedicated SAP HANA schema within the SAP HANA Cloud Platform. The idea here is to provide full access to all features of SAP HANA including the possibility to create analytical views, use libraries such as PAL etc.

      So, from a developer experience perspective you can now use the SAP HANA Studio as your starting point and simply add the Eclipse WTP features and SAP HANA Cloud Platform functionality via the standard Update Site features of Eclipse.

      All of these topics are high priority for the team at the moment and we even got a few aces up our sleeves, which will be published in due time. So stay tuned!

      Now off to some of the topics I'd like to set straight. Conceptually I think the line between the Native, Integrated and Open developer experience is blurry. For one, you can already leverage 'native capabilities' from outside SAP HANA. For example, IDE Lite is just a web-based developer environment that allows you to develop against SAP HANA w/o requiring any local IDE. You can also execute SQLscript from within the former NEO stack as outlined above. And last, but not least... XS is using a server-side JavaScript engine to develop additional server-side logic, which many would call a pretty 'open' developer experience given the huge adoption of JavaScript.

      Oh, and who knows... maybe there'll be an "integrated developer experience" for the "Cloud Stuff" coming as well? 😉

      To summarize all of the above: enabling all sorts of developers the opportunity to use SAP HANA to develop the next gen of enterprise app via SAP HANA Cloud Platform is our top priority these days!



      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author

      I've actually been working on this blog for a while but I could never finish it. I'd seen indications in the SCN forums that something was coming / available for internal usage. My original intention was going to be a call for action - today's release achieved my goal before I could even verbalize / publicize it.

      All of these topics are high priority for the team at the moment and we even got a few aces up our sleeves, which will be published in due time. So stay tuned!

      This is important to hear, because the ability to use remote connect for HANA should just be the start. Now after the foundation has been created, you have to focus on samples that demonstrate how to best merge the native HANA and JAVA development worlds.  You also have the ability to start making inroads into the HANA developer community and pushing HCP as another possible cloud deployment option - besides HANA One.


      Author's profile photo Harald Mueller
      Harald Mueller

      Nice Blog Dick. You are always the first to notice ... more is coming.

      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author

      Can't wait to see where you all take this.


      Author's profile photo Pankaj Kumar
      Pankaj Kumar

      Very happy to see this blog and especially the comments from Matthias and Harald. So now all channels to access HANA platform are becoming equally powerful and address all types of dev experience. You are a core HANA guy you got XS, ABAP on HANA for ABAPers and the newly released and upcoming capabilities documented here for JVM based languages. Ofcourse you can use any of these to create a REST based access and access HANA from anywhere. 

      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author

      In my opinion - at least in the cloud world - the distinctions between XS and HCP are shrinking - the channels are merging rather than remaining distinct.

      Now we just someone to start hacking this new functionality and see how much (if any) of the XS functionality can be really used in HCP.

      Author's profile photo Matthias Steiner
      Matthias Steiner

      Not sure I fully understand your statements regarding XS. I see XS as sort of an additional runtime to develop business logic you cannot or do not want to push down to the SQL layer. What would be your scenario to call from Java stack into XS?

      Author's profile photo Richard Hirsch
      Richard Hirsch
      Blog Post Author

      Maybe I was jumping ahead of myself.... 😳

      I was thinking about a time when you might use parts of XS (such as its server-side JavaScript code) on HCP. 

      Author's profile photo Emil Aleksandrov
      Emil Aleksandrov

      Following your wish we did one more step towards enabling native HANA development on HANA cloud 🙂