Having worked with all the various SAP offerings around Hana development, the speed and ease of development were never satisfying. Therefore I am promoting a slightly different approach here.
My customers wanted to create a Hana application. So they needed the table definitions, deploy that table, load it with initial data and then wrap an UI5 application around. Finally maintain the user authentication, specify authorizations down to the row level security and move all to production.
As speed is not everything, the solution should support all modern development requirements like git, CI/CD, no-code development, dev/test/prod and the such, also.
We all know how this is done in XSC, Hana Studio, XSA, CloudFoundry, CAPM, hence the important differences are highlighted.
At the end the customer wanted to have this screen. It took me just five minutes to build, from the table definition, sample data, setting up security, odata services to writing the UI5 code.
The installation is as easy as it was at XSC times. Any computer capable of running a docker image can get the application with the command
and the application is started by providing a single parameter pointing to your Hana instance. No further configuration needed.
Using containerization not only makes the installation very simple, it also overcomes the deployment issues XSC had and one of the core reasons XSA was invented in first place: Scaling the application server independent from the Hana database.
In addition the docker image can be executed everywhere, from a local laptop to any onPrem server or in cloud environments, in Kubernetes clusters or the cloud vendor's own container solutions. It has zero lock in, the full flexibility and yet all the cloud native features like autoscaling are available for onPrem and cloud, both. That is the beauty of ever properly built container based solution.
In short, it is as powerful as any cloud native solution and as simple to install as XSC was.
After the deployment the home page of the application can be opened:
The Hana design time objects like hdbtable are fully supported. All I had to do was copying the designtime object the customer already had created in his Hana environment and activate it via this solution.
The application to do that is the "Design Time Browser" from above home screen.
Currently the Hana user RTDI is logged in but the tables should be deployed in the schema SALESDB. Hence the designtime object is created within this folder.
The contents of the file are taken 1:1 from the existing Hana development and upon clicking on the "activate" button, it gets created in the database.
Note: The first line "table.schemaName" can be omitted and if present is ignored.
The result is a runtime object of type table in Hana, just like with the SAP dev tools. One important difference is the activation process as such though: It tries to be much more resilient.
For example, renaming the table, creating the new version and then copying the data content is simple to implement but has side effects. The table security grants are lost, triggers, partitioning and everything else related to administration. Thus the activation supports different modes, from "assume a fresh install" to "migrate from a previous version" to a "reconcile with minimal changes".
NOTE: Via aliases on schema level one application can be deployed multiple times within the same database. It can be but does not have to. As a result, the developers have the full flexibility ranging from a complete isolation to working on the same objects. Synonyms on tables as required by XSA are not needed either.
Importing table data is as simple as providing a CSV file of the correct name and activating that.
For better organization a sub directory called tableimport was created with a file matching the table name.
Activating the CSV file itself imports the table contents.
Unlike XSC all data types, including date/datetime, are supported. Not even a hdbti file has to be created as the import program was designed with maximum flexibility in mind.
The final step is writing all code required to display the data in a UI5 Fiori table.
The core of every UI5 application is a XMLView. So we created another subfolder "app" and created a new (empty) file with the extension ".view.xml" in there. Because of this extension, a graphical editor is available as link as well. Clicking on that lets us design the screen.
For this simple example, all we want is a table control with the data, so dragging and dropping the control from the palette into the workspace is what needs to be done.
This is, of course, just one of the UI5 controls out of many available.
The result is a table control with the title "New Table" and no data.
One of the tool palette's group are the Models, where all Hana objects are available. Here I have selected the database schema and searched for all Hana objects containing the text "SALE". A single object was found, the object SALESDB.SALES_DATA.
Dragging that object over the empty table control binds this data with the control and displays the contents. Now the properties of the table, the columns, the controls within the table and their settings,... all can be configured via the properties.
In this example the table control's title was changed to "Sales Data Details", fixed layout turned off, growing limit set to 10 rows, alternate row coloring turned on.
The last step is to save the XMLView and from now on it can be opened by any user having the permissions on the Hana object (shortcut is by clicking on the "test" button next to the save in the graphical view editor.
What we actually did is writing a .xml.view definition. It is a normal XMLView file like any other UI5 developer would have create including controls, properties, model bindings etc. As such it can be further modified manually, complex control logic added etc. Again, no lock in whatsoever.
In comparison to the SAP tools this obviously asks for a couple of clarifications. In the SAP tools you would need to spend a few more hours to setup everything. So what did happen under the covers?
In short the answer is simple: Whenever something is not user provided, the container creates it on the fly without user intervention.
As we have not created a file SalesDetails.html next to the SalesDetails.xml.view file, the application created one on the fly for us, thus rendering the view.
Guess what, as we did not place a file named SalesDetails.controller.js in the app folder, the application created a default for us on the fly (see above).
The xsodata files are needed for the SAP web servers. This container rather exposes all Hana objects as oData service by default. More services can be added but do not have to.
Under the main URL http://..../HanaAppContainer/protected/odata/ each Hana object has one endpoint, e.g. /protected/odata/SALESDB/SALES_DATA is the oData endpoint exposing the SALESDB.SALES_DATA Hana object.
In XSC the Hana database security was used. A user has read access to a table, hence he can read it. He has access to certain rows only, hence he can see his data only. The Hana database has all the capabilities for fine grained control.
This solution does the same thing. When requesting a protected page for the first time, the user logs in with the database credentials. Depending on the assigned roles and permissions, he can do certain things with whatever tool he is using to connect to the database. It could be Hana Studio, it could be another SQL based admin tool, the command line hdbsql, a Business Intelligence tool like WebI or PowerBI. They all use the database credentials and database security and Hana provides everything one might ever ask for. Hence no need to re-implement another security layer outside of Hana, agreed?
All files are actually files in the file system of the image. By linking the directory with git, the full git functionality is supported. Checkin, merge, checkout, branching everything.
To move code to production, the docker image connected with the production Hana database pulls the latest version from git and the activation of all objects is triggered. Any other file transport mechanism is possible also, e.g. SAP transports.
Thanks to git the source code version controlling is covered. The activation logic can be triggered via restful calls. Thus building a full CI/CD pipeline, even covering continuous deployment is an easy task. For software development the requirements of CI/CD are even higher. The activation needs to be tested for fresh installs at customers, customer upgrades to the new version and normal development. Thanks to the different activation options, this can be done.
Goal
My customers wanted to create a Hana application. So they needed the table definitions, deploy that table, load it with initial data and then wrap an UI5 application around. Finally maintain the user authentication, specify authorizations down to the row level security and move all to production.
As speed is not everything, the solution should support all modern development requirements like git, CI/CD, no-code development, dev/test/prod and the such, also.
We all know how this is done in XSC, Hana Studio, XSA, CloudFoundry, CAPM, hence the important differences are highlighted.
At the end the customer wanted to have this screen. It took me just five minutes to build, from the table definition, sample data, setting up security, odata services to writing the UI5 code.
Step 1 - Installation
The installation is as easy as it was at XSC times. Any computer capable of running a docker image can get the application with the command
docker pull rtdi/appcontainer:latest-hanaand the application is started by providing a single parameter pointing to your Hana instance. No further configuration needed.
docker run -d -p 80:8080 \
-e HANAJDBCURL=jdbc:sap://hana.rtdi.io:39015/HXE \
rtdi/appcontainerUsing containerization not only makes the installation very simple, it also overcomes the deployment issues XSC had and one of the core reasons XSA was invented in first place: Scaling the application server independent from the Hana database.
In addition the docker image can be executed everywhere, from a local laptop to any onPrem server or in cloud environments, in Kubernetes clusters or the cloud vendor's own container solutions. It has zero lock in, the full flexibility and yet all the cloud native features like autoscaling are available for onPrem and cloud, both. That is the beauty of ever properly built container based solution.
In short, it is as powerful as any cloud native solution and as simple to install as XSC was.
After the deployment the home page of the application can be opened:
Step 2 - Create the tables
The Hana design time objects like hdbtable are fully supported. All I had to do was copying the designtime object the customer already had created in his Hana environment and activate it via this solution.
The application to do that is the "Design Time Browser" from above home screen.
Currently the Hana user RTDI is logged in but the tables should be deployed in the schema SALESDB. Hence the designtime object is created within this folder.
The contents of the file are taken 1:1 from the existing Hana development and upon clicking on the "activate" button, it gets created in the database.
Note: The first line "table.schemaName" can be omitted and if present is ignored.
The result is a runtime object of type table in Hana, just like with the SAP dev tools. One important difference is the activation process as such though: It tries to be much more resilient.
For example, renaming the table, creating the new version and then copying the data content is simple to implement but has side effects. The table security grants are lost, triggers, partitioning and everything else related to administration. Thus the activation supports different modes, from "assume a fresh install" to "migrate from a previous version" to a "reconcile with minimal changes".
NOTE: Via aliases on schema level one application can be deployed multiple times within the same database. It can be but does not have to. As a result, the developers have the full flexibility ranging from a complete isolation to working on the same objects. Synonyms on tables as required by XSA are not needed either.
Step 3 - Loading data contents
Importing table data is as simple as providing a CSV file of the correct name and activating that.
For better organization a sub directory called tableimport was created with a file matching the table name.
Activating the CSV file itself imports the table contents.
Unlike XSC all data types, including date/datetime, are supported. Not even a hdbti file has to be created as the import program was designed with maximum flexibility in mind.
Step 4 - Building a UI5 application
The final step is writing all code required to display the data in a UI5 Fiori table.
The core of every UI5 application is a XMLView. So we created another subfolder "app" and created a new (empty) file with the extension ".view.xml" in there. Because of this extension, a graphical editor is available as link as well. Clicking on that lets us design the screen.
For this simple example, all we want is a table control with the data, so dragging and dropping the control from the palette into the workspace is what needs to be done.
This is, of course, just one of the UI5 controls out of many available.
The result is a table control with the title "New Table" and no data.
One of the tool palette's group are the Models, where all Hana objects are available. Here I have selected the database schema and searched for all Hana objects containing the text "SALE". A single object was found, the object SALESDB.SALES_DATA.
Dragging that object over the empty table control binds this data with the control and displays the contents. Now the properties of the table, the columns, the controls within the table and their settings,... all can be configured via the properties.
In this example the table control's title was changed to "Sales Data Details", fixed layout turned off, growing limit set to 10 rows, alternate row coloring turned on.
The last step is to save the XMLView and from now on it can be opened by any user having the permissions on the Hana object (shortcut is by clicking on the "test" button next to the save in the graphical view editor.
What we actually did is writing a .xml.view definition. It is a normal XMLView file like any other UI5 developer would have create including controls, properties, model bindings etc. As such it can be further modified manually, complex control logic added etc. Again, no lock in whatsoever.
In comparison to the SAP tools this obviously asks for a couple of clarifications. In the SAP tools you would need to spend a few more hours to setup everything. So what did happen under the covers?
In short the answer is simple: Whenever something is not user provided, the container creates it on the fly without user intervention.
Where is the html file needed for this UI5 application?
As we have not created a file SalesDetails.html next to the SalesDetails.xml.view file, the application created one on the fly for us, thus rendering the view.
Where is the UI5 controller code loading the oDataModel?
Guess what, as we did not place a file named SalesDetails.controller.js in the app folder, the application created a default for us on the fly (see above).
Who created the .xsodata file required for exposing objects as oData service?
The xsodata files are needed for the SAP web servers. This container rather exposes all Hana objects as oData service by default. More services can be added but do not have to.
Under the main URL http://..../HanaAppContainer/protected/odata/ each Hana object has one endpoint, e.g. /protected/odata/SALESDB/SALES_DATA is the oData endpoint exposing the SALESDB.SALES_DATA Hana object.
What about security?
In XSC the Hana database security was used. A user has read access to a table, hence he can read it. He has access to certain rows only, hence he can see his data only. The Hana database has all the capabilities for fine grained control.
This solution does the same thing. When requesting a protected page for the first time, the user logs in with the database credentials. Depending on the assigned roles and permissions, he can do certain things with whatever tool he is using to connect to the database. It could be Hana Studio, it could be another SQL based admin tool, the command line hdbsql, a Business Intelligence tool like WebI or PowerBI. They all use the database credentials and database security and Hana provides everything one might ever ask for. Hence no need to re-implement another security layer outside of Hana, agreed?
How to move to production?
All files are actually files in the file system of the image. By linking the directory with git, the full git functionality is supported. Checkin, merge, checkout, branching everything.
To move code to production, the docker image connected with the production Hana database pulls the latest version from git and the activation of all objects is triggered. Any other file transport mechanism is possible also, e.g. SAP transports.
Is CI/CD supported?
Thanks to git the source code version controlling is covered. The activation logic can be triggered via restful calls. Thus building a full CI/CD pipeline, even covering continuous deployment is an easy task. For software development the requirements of CI/CD are even higher. The activation needs to be tested for fresh installs at customers, customer upgrades to the new version and normal development. Thanks to the different activation options, this can be done.
- SAP Managed Tags:
10 Comments
