SPS 11 promises a richer, more powerful HANABy Prabadisha Jayaratne on
With the newly released Support Package Stack (SPS) 11, SAP has transformed HANA once again. I had the privilege of attending the SAP Developer's summit in Sydney recently and found the HANA sessions most enlightening.
The following extract sums up some of the technical information I discovered about SPS 11 after attending three sessions by Thomas Jung.
With this SPS, HANA is getting richer, more open source-based and, most importantly, it addresses some of the previous limitations. But, of course, this means it also brings in a lot more complexity too.
Just to emphasise how much of a change this is, the new release – in my opinion – will make all current OpenSAP courses about HANA XS development obsolete. So for someone like myself – a classic SAP developer who is not expert in CloudFoundry, node.js, Express and other technologies – it entails a high degree of upskilling.
Having said that I personally believe that the changes will make HANA XS development more open, and more powerful, in the long term.
The XS Engine we are familiar with will be called XS Classic from SPS 11 onwards and the replacement is called XS Advanced. XS Classic will still be supported for several SPS levels.
HCP is moving to a CloudFoundry, which as I understand it is an open source initiative to standardise PaaS.
On-premise HANA XS (Advanced) is going to implement a subset of CloudFoundry APIs so that it is more or less compatible with HCP.
- Java on Tom EE
- C++ (via Fast CGI)
So when implementing services, you can choose the runtime (and language of course). Also applications written once can be deployed in HCP or on-premise without any changes.
SAP is bringing in Node.js and Node Package Manager (NPM). The following table is a brief comparison between Node and the classic XSJS programming model.
Other new features of XS Advanced
XS Advanced can be deployed/scaled independent of HANA DB (ie. HANA DB in separate system. Traditional 3 tier web/app server, DB server, client model).
Microservices: Each service is run as an individual process and can be allocated its own memory/CPU limits.
It features clear separation of application users and database users. A single technical user will be used by each service to access the HANA DB, while the XS Engine will have its own (application) users, while the details of the application users will be visible to DB layer. (In SQL Current_User = DB user, Session_User = App user)
Changes to HANA repository
The new HANA source code repository will be based on git/GitHub. The old repository will be gradually phased out. As I understood it, the current lifecycle management/transport model will be replaced by branches concept of git. (Each branch to a different system).
HANA Deployment Infrastructure (HDI)
Container (the new "Schema")
All database objects (including calc. views) will be stored under a container. Traditional "Schema" will not be visible to the user.
Changes to information views
Attribute, analytic and script-based calculation views will be phased out. Table functions coupled with graphical calculation views take place of script-based calculation views.
HANA studio will be phased out and a new web IDE will take its place. All functions (deployment, object creation etc.) will be supported by command line tools. External editors (Sublime, Notepad++ etc.) will be required in the latter case.
Migration tools will be provided by SAP for most of the artefacts.
SAP is bringing in a lot of changes and recommends that all current live applications are not migrated into the new architecture until SPS 12. But developers are welcome to try this new and future model of HANA development for new applications.