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.
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:
- Database and application server are together, hence running on the same hardware.
- All code activation happened by a single technical user.
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.
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.
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!