I would like to introduce you to the next generation development model for Hana, the HanaAppContainer project. It should be
In case you like what you see, please spread the word. The project depends on you! To request a feature, write a github issue here.
To start with development all you need is to run a provided docker image.
To get hold of the image, run the command
and start the image with
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.
Details about this particular image can be found at Docker Hub.
A few seconds after executing the docker run command, the image is active and can be accessed via the browser
It presents you with the Application Directory, which at the moment looks like this:
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.
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.
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).
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.
Like for every good citizen these days, a Swagger documentation is generated out of the box as well.
To simplify the development task, a first set of UIs have been created, using above functionality.
Allows to browse through your personal repository and links to the 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.
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.
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.
Way more simple to use, way smaller footprint, cheaper to operate, supports XSA and XSC file types, developer friendly, scales better and automatically.
More powerful than Cloud Foundry, easier, cheaper, runs everywhere, supports Hana native development.
all posts tagged "HanaAppContainer"
- 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
In case you like what you see, please spread the word. The project depends on you! To request a feature, write a github issue here.
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:latestand start the image with
docker run -d -p 80:8080 \
-e HANAJDBCURL=jdbc:sap://hana.rtdi.io:39015/HXE \
rtdi/hanaappcontainerwhere 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.
Details about this particular image can be found at Docker Hub.
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.
all posts tagged "HanaAppContainer"
- SAP Managed Tags:
1 Comment
