Next Generation Hana Development Model

I would like to introduce you to the next generation development model for Hana, the HanaAppContainer project. It should be

◉ easy to use
◉ powerful
◉ simple to setup
◉ run-everywhere, from a laptop to on-prem to a large cluster with load balancers in the cloud

Installation

To start with development all you need is to run a provided docker image.

To get hold of the image, run the command

    docker pull rtdi/hanaappcontainer:latest

and start the image with

    docker run -d -p 80:8080 \
      -e HANAJDBCURL=jdbc:sap://hana.rtdi.io:39015/HXE \
      rtdi/hanaappcontainer

where HANAJDBCURL is the connection string for your Hana database. In this case the Hana database runs on host hana.rtdi.io at port 39015 and should connect with the database named HXE.

Usage

A few seconds after executing the docker run command, the image is active and can be accessed via the browser

    http://localhost/HanaAppContainer/

It presents you with the Application Directory, which at the moment looks like this:

What can be done with it?

UI5 applications

First of all, it makes Hana application development trivial. Upload the application files like *.html, *.view, *.controller.js etc plus the database design time objects like a *.hdbtable file and the application is ready to run.

No need to write deployment descriptors, yaml files etc.

No need for any security setups, it is using the Hana users and security.

Thanks to that I was able to whip together the UI above within minutes.

 oData services

The second huge advantage is that all Hana objects are exposed to the application automatically. How long does it take to write a UI5 application that shows a drop down list of all database tables? Minutes, because a oData service on all accessible database tables and views, including the system objects and any created by you, are available out of the box. (v4.oDataModel)

No need to write xsodata files.

Simply put the <schema>/<objectname> into the URL and you get the oData metadata document of that table/view and hence can use it with any oData consumer.

Stored procedures

Need to call a stored procedure from the application? Same approach as above. Add the procedure name to the URL and every accessible procedure for the current use can be called via the RestFul protocol (JsonModel).

Lookup a record via RestFul

For applications it is often neccessary to lookup a single row. oData would do the trick but is expensive on the UI5 side, hence a default RestFul endpoint exists.

Here the (first) record of the SYS.OBJECTS view for the where clause OBJECT_NAME = ‘TABLES’ is returned.

Swagger

Like for every good citizen these days, a Swagger documentation is generated out of the box as well.

Development UIs

To simplify the development task, a first set of UIs have been created, using above functionality.

Design Time Browser

Allows to browse through your personal repository and links to the file editor.

File Editor

Here the normal Hana design time artifacts can be edited.

Note, this editor is more than it looks. It is a full blown text editor with syntax highlighting, autocomplete and more.

Nevertheless, the plan is to have graphical editors as well in future.

Importer

Another app is the importer, where existing Hana objects can be reverse engineered into their design time object. Any schema can be selected and the importer will retrofit the package structure and the design time objects. Above screenshots come from a SAP S/4Hana database, where the ABAP tables have been converted into hdbtable files.

What is the difference to XSC?

Hana XSC was praised for its logical consistency. You have a hdbtable file? It creates a Hana table. You have a html file? It can be served by XSC to the browser.

The main problem of XSC was that it did not scale beyond a single server and it had severe security flaws by design.

This new solution builds on the simplicity of XSC, simplifies it even further, gets rid of the annoying habits of XSC and has none of the XSC limitations. Multiple of these images can be started in parallel, autoscale to the current workload. The image is tiny compared to XSC. Most important, it is actively maintained. Please add you requests as github issues and we will look into them. 

What is the difference to XSA?

Way more simple to use, way smaller footprint, cheaper to operate, supports XSA and XSC file types, developer friendly, scales better and automatically.

What is the difference to SAP’s Cloud Application Model?

More powerful than Cloud Foundry, easier, cheaper, runs everywhere, supports Hana native development.

Guiding principles

◉ Never the same information twice. Example: The name of a hdbprocedure is the file location itself and the first line of the procedure definition. As a result XSC keeps raising errors when the two do not match, e.g. after a copy or move.

◉ Activation should provide detailed feedback: It shows all the SQL statements it executed, which it did not and why. With XSC/XSA the activation process is a black box. Which is okay if it works but a nightmare in difficult cases.