Software Development At SAP: Building Hana Applications

Due to certain decisions and their unintended consequences, there is hardly anything left of the Hana platform idea, unfortunately. The Hana database itself is fine, but the development side of the platform is essentially non-existing. All applications I have seen, including recent SAP solutions, use only the database. This is highly unfortunate and completely unnecessary because a platform does make sense – with Hana Cloud Service, one might even say it especially makes sense today. Worse, there could have been technical solutions avoiding all drawbacks of XSC.

XS Classic

Looking back, the XSC server was designed to be simple. One part that made it so easy to use was its deep integration with the Hana server. There were two downsides, however:

1. Database and application server are together, hence running on the same hardware.
2. All code activation happened by a single technical user.

The first point limits scalability. Just like in R/3, it’s a three-layer client/server architecture: Database, Application Server, Frontend. The technologies are different, with Hana database, JavaScript as the programming language of the application server, the browser as front end. If the JavaScript code of the application server gets more complex, it would make sense to put that layer to another server or multiple servers even.

The second point about code activation is a design flaw. The developer creates a design time file, e.g. a hdbtable file containing the rules how to create a table, and a database process has to read (“activate”) this file. Whoever runs it needs the permission to create the table in the designated schema. By using a single technical user, the _SYS_BIC user, only a single database user needs the permission. As consequence, the _SYS_BIC user gets all permissions on all database objects and schemas, which is a huge security flaw.

Unintended consequences

To solve that, XS Advanced (“XSA”) was developed as the opposite of XSC. Instead of being integrated with the database, it is separate with its own security subsystem. Instead of a single user activating all code, each project creates three individual database users under the covers. Instead of Javascript as application server language, it supports Node.js and Java. Instead of building applications, it requires to build microservices with all the inherent complexities.

Because of the many permissions and two places to control them, XSA requires a grantor service – which is just another kind of security flaw.

The obvious consequence: What started as a simple-to-use application server turned into a difficult-to-use product with XSA. The adoption of XSA at customers is close to zero and customers stick to XSC, even though it is marked as deprecated. (Deprecated means the product remains supported but will not get any new features.)

From what I have seen, if anything, customers install XSA to run the Hana Cockpit for database administration or to use the XSA WebIDE to develop CalcViews. Apart from that, however, they usually stay away as much as possible. Many customers are using Hana Studio, most stick to XSC – all still supported in the latest Hana 2.0 SP5.

Future

To make things worse, XSA itself hasn’t been getting much attention by SAP either lately, as can be seen by the low number of bug fixes and new features. As a funny side note, in one of the presentations on the latest Hana 2.0 SP5, some features were made available in XSC but not in the XSA stack. When asked why, the response was that the “vast majority of customers use XSC, and adding it [the feature] to XSA would not help them”.

My initial hope was the cloud may come to the rescue. For Hana application development in the cloud, SAP switched to Visual Code as the UI foundation and added some interesting concepts. The two root causes why XSA is so hard to use are inherent in this new Cloud Application Programming Model (“CAPM”) as well. The one is how objects are created in the database via the Hana Deployment Infrastructure (“HDI”) and the other is the microservice orientation. My prediction is that this will not convince customers either.

Do not get me wrong, a microservices architecture does make sense for many cloud applications. But not for all applications. Using an architecture designed for unlimited scaling – a microservices architecture – to build an application for a single database instance with a few thousand end users is counterproductive.

There are alternatives, though. For example, the SAP community liked the proposal of an HanaAppContainer, which is integrated with the Hana database and is using GIT as the repository. This would combine the simplicity we got with XSC without its downsides.

Until there is a reliable roadmap in that area, I will not promote XSA in fear of getting blamed later for introducing the high costs of moving to XSA, and then XSA gets deprecated shortly after. I keep hearing the same concerns from other Hana experts as well.

I would appreciate it if you could comment your own point of view below!