Skip to Content

SAP HANA SPS 11: New Developer Features; XS Advanced

This blog is part of the larger series on all new developer features in SAP HANA SPS 11: SAP HANA SPS 11: New Developer Features


The History and Value Proposition of XS

From the very beginning, SAP HANA was always intended to be more than just a database.  SAP has long referred to SAP HANA as the SAP HANA Platform.  And with good reason.  HANA has all the traditional capabilities of a relational and analytical database, but also has many extra features like full text search, spatial processing, and predictive analytics.


Figure 1: SAP HANA Platform

These features have been designed to be deeply intertwined and embedded in the core HANA processing. This way they also benefit from the In-Memory and massive parallel processing capabilities of HANA.

As SAP was building the first set of applications that leveraged all of these extended capabilities of SAP HANA, we began to see the possibility to build complete applications where almost all the processing took place within the database. Therefore it seemed disappointing in these cases to have to add to the infrastructure footprint of such applications by requiring an additional application/web server if that part was only providing minimal functionality.

We saw an opportunity to embed a small footprint application and web server within SAP HANA itself. And so SAP HANA extended application services (or XS for short) was first introduced with SAP HANA SPS 05.  This enabled SAP, customers, and partners to develop applications which ran completely within the single SAP HANA “box”. We could reduce architectural layers and by doing so delivery applications with a lower total cost of ownership.

This simplified architecture meant that a single process was used to install, patch and administer both the database and the application server layers within SAP HANA. It also meant that single application archive could be used to install with one step a complete application composed of everything from the data model, application logic, service enablement, and user interface.

XS Evolves Into XS Advanced

Requirements change over time and so too has XS within SAP HANA. SAP HANA extended application services in SPS 11 represents an evolution of the application server architecture building upon the previous strengths while expanding the technical scope.


Figure 2: XS Architecture as of SAP HANA SPS 11

Cloud Foundry

One of the driving requirements for the new SAP HANA XS Advanced was the desire to better unify the architecture of solutions built in the cloud and on premise. The SAP HANA Cloud Platform was already looking to adopt the open solution of Cloud Foundry as the base of their next generation offerings. Cloud Foundry provided the kinds of scalability options and flexible runtimes that are needed in the cloud environment and therefore makes a perfect match to the functionality HCP wishes to offer.

Today SAP HANA XS and the HANA native development model is offered both in on premise HANA systems and in SAP HCP.  However XS in HCP is rather separated from the rest of the HCP technology architecture. The primary goal for XS Advanced was to unify these two delivery channels on a single base architecture.

Therefore XS Advanced is essentially based upon Cloud Foundry. In the near future it is planned that HCP itself will run based upon Cloud Foundry.  For the on premise delivery of SAP HANA, we felt that delivering the complete Cloud Foundry technical stack was too much. Therefore we have created our own implementation of the Cloud Foundry APIs as XS Advanced in the on premise HANA delivery in SPS 11.

This means that the core concepts of Cloud Foundry will be present in both SAP HANA on premise and in SAP HANA Cloud Platform.  For example Cloud Foundry standard build packs will be utilized for the language support in both environments. A single set of service brokers will be created for things like user authentication and HANA database connectivity and will be made available in both environments.

Runtime Support

By moving to the Cloud Foundry basis, one of the most obvious impacts is that now we have the foundation in SAP HANA XS to support multiple languages/runtimes. We will use standard Cloud Foundry build packs as the basis of the XS language support.

Therefore starting with SAP HANA SPS 11, XS Advanced will be delivered with and fully support both Apache TomEE Java and Google V8 JavaScript/Node.js.  We will also have a C++/FastCGI language runtime, but at least initially this is reserved for SAP internal and perhaps limited partner usage.

In both of these runtimes, you will find a quite pure delivery of the standard runtimes. For the node.js runtime we only create a small variant to add supportability aspects for example. This greatly supports the easier porting of existing applications onto SAP HANA.

SAP’s general approach to the usage of these language runtimes is that most new development will be done in Node.js while the JAVA runtime is primarily utilized for porting of existing libraries and applications. Therefore you will notice that SAP makes a larger investment in custom tooling and libraries/modules for the Node.js runtime. However both are fully supported by SAP and customers/partners and choose whichever works best for them.

Speaking of choice, this overall architecture being so open creates the possibility for the future to have a true bring your own language/runtime scenario.  Customers/partners will have the ability to utilize other Cloud Foundry buildpacks.  There are many such buildpacks for many popular languages such as Ruby, Go, and PHP.  See listing here.


But the benefits of this new architecture aren’t limited to just the choice of runtimes.  The core architecture is designed to operate as Micro-Services.  But what exactly do we mean by Micro-Services?

In today’s XS environment we have a single operating system process called XSEngine.  Within this process we create a pool of JavaScript Virtual Machines. The are clones of a single runtime version. Therefore there are no options to control which version of JavaScript your application runs against. There are some limited configuration parameters that apply to the entire pool of JavaScript VMs, but no way to configure memory or other scaling parameters per application. Finally as all the VMs live within a single operating system process, if anything goes wrong there is the potential to crash the entire XSEngine process.

In the new Cloud Foundry based architecture of XS Advanced, things work very differently. First when you deploy an application or service a copy of the entire Java or Node.js runtime goes with.  This way each service is isolated and locked into their version. Even if you upgrade the entire HANA/XS system, already deployed services continue to run with their existing runtime providing better stability over time. It isn’t until you would deploy the service again that you could pick up a newer version of the specific runtime. This allows single services to target different runtime versions in parallel.

At the operating system level, we also no longer have one monolithic process hosting all the runtimes. Each runtime instance has its own operating system process. This allows for much better process isolation ensuring that a single poorly written or behaving service can’t disrupt other services/applications.


Figure 3: Separate Operating System Processes for Each Service Instance

This also means that you have much better scaling options.  Single services can have different memory limits and can be scaled to multiple instances on a single host or even across multiple hosts.  This will often then lead to different designs where single applications are broken into many different services. Therefore you can mix and match multiple languages/runtime versions within a single application. You can also scale and tune applications accordingly. For instance the service part that serves the static web content probably needs less memory and fewer instances than the transactional REST services within the same overall application.


Figure 4: Applications with Multiple Services and Individual Instance, Memory, and Disk Limits Per Service

Scaling and Deployment Options

The new scaling options don’t end at the individual service level, however. With XS Advanced the overall architecture is a bit less intertwined with SAP HANA in general.  This brings more deployment options.

The default installation/upgrade option will still place XS Advanced directly on the HANA server for the “all in one box” experience. This way we continue the primary business benefits that drove SAP to create SAP HANA XS in the first place.

But now SAP HANA XS advanced can also be installed on a separate host from the SAP HANA database.  This can be done to scale XS independent of the database.  You have many more XS nodes than SAP HANA database nodes.  You can also install XS advanced on a non-HANA certified hardware. This allows for using cheaper hardware to run the less memory intensive XS processing.  We will also allow XS advanced to be installed in a separate network from SAP HANA itself. Therefore you can install XS advanced into a DMZ and have a firewall between the XS and database layers.

Backwards Compatibility

Its important to note these innovations described here are delivered alongside the existing functionality.  We haven’t removed or disabled any of the current architecture.  All of your custom development objects remain exactly where they are today and will continue to function as they do already. The current XS Engine remains a part of the HANA infrastructure, although now renamed XS Classic so as to distinguish it from the new capabilities delivered as part of XS Advanced. Likewise the HANA Repository remains in place even as we move to Git/GitHub as the future design time/source code repository. Eventually these older capabilities will be removed from HANA, but that point hasn’t been decided yet. SAP won’t removed them until we see a critical mass of customers moving their development objects to the new capabilities we describe here.

Therefore customers can upgrade with confidence to SPS 11 without fear that the new innovations will somehow disrupt their existing applications. Customers can decide how and when they want to begin to move applications to the capabilities and only do so once they are comfortable with everything involved.  In the mean time everything they have continues to run exactly as it does today.


All of the architectural changes we’ve described here can be summarized down to one key point: choice. SAP HANA XS advanced offers customers and partners the freedom of choice of technologies, tools and deployment options for high-scale development and operation of native SAP HANA applications.

We also make it easier to choose between on premise and cloud deployment. Because of the shared architecture described here, it will soon be easy to develop a single application that can be deployed on premise, in the cloud or both without any coding changes.

You must be Logged on to comment or reply to a post.
  • /
  • /
  • I really enjoyed reading it and seeing that we move into the direction of "choice". That is fantastic and for me we set the ground for more creativity and innovations. Thanks so much Thomas!

  • Hi Thomas,


    Do we have information on how to uninstall/remove HANA XS Advance Model if not in use from the HANA DB please. It seems to have bug , which doesn't allow to perform successful Backup/Restore.



    Rupali S

    • Not in XSJS.  Nor is anything specifically provided by SAP for statefull sessions.  However both node.js and Java have ways of creating stateful services. In the node.js would this would involve 3rd party modules.  We would still generally advice against the use of stateful services and instead persist state in the HANA DB.

  • Hi Thomas,


    With the SP10 XSODATA we can declativly publish tables and views as OData.


    Will this also be possible with the new architecture? In both Java and JavaScript/Node?


    Will the feature list of XSOdata evolve? Especially I am missing media and delta support!


    What is of this already available with SP11?




    • >Will this also be possible with the new architecture? In both Java and JavaScript/Node?

      It works exactly the same way in Node.js.  The same XSODATA file is interpreted. Just now the generic framework SAP provides to handled the OData requests is written in Node.js.  For Java you would use the Apache Olingo libraries.


      Will the feature list of XSOdata evolve?

      Yes but first we have to reach feature compatibility with what we had in XS Classic.  Then we will work on the backlog of additional features.

        • Correct.  Apache Olingo is a library that allows you to code OData services without starting from scratch but it doesn't provide a declarative approach like XSODATA. Its certainly different approaches each with their own pros and cons.

  • Hi Thomas


    Thanks for the blog. Can I ask, in Figure 2, why Web Dispatcher is there only for XS Classic and has no connection in the XS Advanced architecture? Is it replaced?


    Kind Regards


    *-- Serdar

    • No the XSA does have a Web Dispatcher as well. Its the platform router that is part of the core XSA itself and not explicitly shown in the above diagram as it doesn't really run as a separate service. 

  • Hi Thomas,


    thanks a lot for the excellent introduction. I am using XSA for running classic and node.js applications. I checked the cf build pack list you are refering to. Is it possible to run a ruby application in XSA too? Build pack exists. Theoretically some could specify the ruby runtime in the manifest.yml and provide the sources similar to what is done for running node.js. Will that work and is it supported ?


    Thanks an best regards.



    • >Will that work and is it supported ?

      Two very different things you ask for there.   Will it work?  Yes most likely it will.  The foundation is designed to accept additional CloudFoundry compatible buildpacks over time.  Will you be supported? No, not currently.  This isn't something we are ready yet to document and support. It requires additional testing for one.  But Bring Your Own Language/Runtime is something we plan to support in the future.  SAP would plant to support that CouldFoundry buildpacks install and run correctly; but wouldn't support the inner workings of these additional buildpacks. However our first priority must be to get the node.js and Java runtimes delivered and built out with the most critical features in our product backlog.  Then we can come back and look at additional aspects like Bring Your Own Language/Runtime.

  • thanks a lot for the detailed analysis on Hana.. All these new features seem so interesting and i am really very much excited to try all of them

  • Hi Thomas,


    Does SAP provide any standard native HANA applications that require installation of SAP HANA XS Advanced Runtime?


    Do any of the SAP standard applications such as SAP Business Suite on HANA and S4HANA have native HANA applications that require installation of SAP HANA XS Advanced Runtime?




  • Hi Thomas,

      How can one get info about the C++/FastCGI runtime? and How does integration with R fit into the new SPS 11 architecture. Any change there?



    • C++ container is still under development and only available internally at SAP and to a few select pilot users.


      R Integration isn't impacted by these changes at all.  The R integration was and remains within the HANA core DB engine itself.

      • hello Thomas

        i implemented Hana express edition 2.0 on tablet surface pro 4 and also Eclipse neon. All is running but i don't know how to login to XS advanced.

        Further: hxehost is problem in VM ware and internet access.

        many thanks for your fast help. Nick


  • Hi Thomas,


    great blog. Thanks for making things so clear here.


    What I am still lacking is the understanding of the benefit of having the app server separated. By introducing the xs (classic) engine, it was said the advantage was the tight connection of the xs (classic) engine with the hana database indexserver ("is an instance of"), so that the application would operate "directly" on the data.

    Is there still a difference with respect to being more closely connected to HANA with xs advanced application server and a general app server that runs e.g. Java?


    Best regards,



  • Hi Thomas,


    Since I first learned about HANA XS, I have been waiting for it to evolve into something like this. It makes a case for XS advanced to be used in a productive environment now.


    Two questions here -

    1. Is a lightweight ABAP engine going to be integrated?

    2. HANA is now well on the path to become a parallel application platform to the traditional SAP NW. What's SAP's direction in terms of the future applications and the current Business Suite?




    • >Is a lightweight ABAP engine going to be integrated?

      There are no plans for that at this time.


      >What's SAP's direction in terms of the future applications and the current Business Suite?

      The Business Suite and S/4 already use primarily the ABAP only Application Server.  They will remain mostly ABAP based.  Other applications that are Java-based you will very likely see move towards XSA architecture.

  • I noticed that there was an xs app named xsa-admin  and xsa-admin-backend in your listed xsa apps. I recently deployed SAP HANA 2.0 and subsequent XSA worker on the same host. The xsa-admin application was not deployed with the bundle. Where do you download the xsa-admin .zip file to install it?

  • Hello Thomas!

    THX for this intensive konwhow blog. It is really amazing.
    After reading I still have some question in my mind. Maybe you can give some clarification:

    1. Is XS Adavanced (and so SPS11) one of the main features of HANA 2.0 ?

    2. XS is also used in HCP. Do you have a feeling when HCP will upgrade to XS Adavanced ?

    3.WEBIDE seems to be THE SDK for all development languages in XSA. Will WEBIDE also "replace" Eclipse or will Eclipse still remain the SDK for Java issues in XSA?

    4. Questions to figure 2:


    • 1. XS Advanced is certainly included in HANA 2.0 as well.  There are some usability and feature improvements compared to SPS 12. No major changes however.

      2. You would have to ask someone who covers HCP about their roadmap timelines.  From what I've seen sometime in 2017 is planned.

      3.  Java build and deploy was added to the Web IDE for SAP HANA in HANA 2.0 SPS 0.  Java debugging is planned for SPSs in the first 1/2 of 2017.  No it isn't intended to completely replace Eclipse for JEE development, but does offer a unified development location when building Java and other module types together in one MTA. Most likely you do the bulk of your Java dev in Eclipse and then use Git to share the project with the SAP Web IDE for SAP HANA for final integration and building of the MTA.

  • 4. Questions to figure 2:

    4.1 What does HANA DI stand for?
    4.2 What for is the XSJS component in comparision to XS classic on the right side? Shouldn't it be the same?

    5. Will in a S/4 HANA scenario also be XSA implemented?
    If yes: S/4 HANA is based on 7.5 Netweaver. Can you organise or can you reference to a blog   in which there is a quite similar figure like Figure 2. In my imagination the figure should look the same but with a parallel block to HANA XS Advanced with containing Netweaverstack. The new block is also connected to HANA Database and also up to Browser.

    THX Ralf

    • 4.1 HANA Deployment Infrastructure.
      4.2 No there is a separate, new implementation of XSJS done in Node.js.  Therefore there are currently two XSJS runtimes - one in Node.js and one in XS Classic.
      5. Yes you can.  XSA is currently still optional in S/4. It will likely become mandatory in an S/4 release in 2017.

      If I were to draw Netweaver in that diagram I would put it next to the XSA layer.  You have two Application servers then - One ABAP and another independent App server for XSA.

  • Hi Thomas,

    While migrating my application I’m getting error like insufficient privilege Not authorized.

    The required privileges are also listed in the documentation in section "2.":

    My team tried to assign this roles to me but giving error like below.

    since my application is in HCP system.

    Is a different specific procedure to migrate HANA@HCP -> XSA@OnPremise.?

    if you know please suggest me what I’m missing.

    Thank you,


    • The security requirements are likely different for HCP and the migration guide security is specific to on premise. Perhaps you could consider exporting the DU from HCP and installing it in your on premise system and migrating from there.  Otherwise I'd suggest opening a support ticket to get help with the necessary security setup for HCP.

  • Hi Thomas,

    I learned a lot from your blog.

    I know XSA definitely supports micro-service implemented by NoteJs.

    I want to know if I want to create micro-service implemented by JAVA, this is could be supported or not?

    Appreciate for your reply.





  • Hi Thomas,

    I come back to read this blog again.

    Then found new question is below regarding the XSA framework chat.

    What does "XS Adv. Runtime Platform" mean?

    It means Diego Framework in V3? if it is, what does it mean in V2?

    If above understanding is wrong, what is include in  XS Adv. Runtime Platform?

    Then where put Warden, Docker, Garden,Diego to? (Sorry I know they are not the same level concept, but want to know how to describe them in the chart.)

    Thanks ~~


    • XSA is SAPs own implement of the core Cloud Foundry APIs and concepts.  It includes the ideas of buildpacks, service brokers, and UAA.

  • Hi Thomas,

    Very informative blog.

    I have small question, Is there any way to call ABAP RFCs/BAPIs from XSA?  If yes, It opens many opportunities to develop apps based on very strong SAP engine with state of the art UI of user choice based on React etc...




  • Hello Thomas, am I wrong to believe that the very latest XSA infrastructure does not support one of the latest and most important use cases there is: the ever-growing number of mobile devices with a definite need for offline support?
    You stated in DEV104 "We will primarily look at using Node.js moving forward". So, given the now ancient concept of Network Computing, shouldn’t we exploit telephones and tablets (as well as PCs) as a new generation of local/distributed (mini) Web-Application Servers? It has already been acknowledged that a native Fiori UX Application needs to be installed on each mobile device precisely so that they can be used offline, so wouldn't it make more sense to install SAP-supported Node.js (domain-specific, forced-caching) Web-Application servers locally on each device and each PC, to serve up content (regularly deltaed from GitHub), even when offline? 
    The Node.js binary file for Linux is <11MB, and various ports have already been done to Android, so this doesn't seem so challenging. Such a locally-installed mobile/mini Node.js Server could equally provide native access to all of the mobile device's equipment, such as its camera, making this simply a next generation 'SAP GUI', which has always needed to be installed on local PCs up until now in any case.
    You stated in DEV104, "if something crashes [on XSA] for some reason, that you only take out that individual service", but you obviously lose it FOR ALL USERS! But if one single user's Android/iOS Node.js Server crashes, what happens to all the other PCs and mobile devices connecting to the same HANA DB? Nothing at all. And what of scalability? 
    Just a thought,
    Cameron HUNT