Skip to Content
Technical Articles
Author's profile photo Mathias Klare-Dobberkow

XSA Blog Series – Basic Principles of SAP HANA XSA

With SAP HANA XSA, SAP has set its strategic course for SAP HANA and puts a clear focus on a modern development with isolated applications. With this step it is clear that XSC and with it the developments in the HANA Studio with packages and schemas are a thing of the past.

But what does this new XSA world look like? What’s changed? What are the new capabilities?

In this first part of my multi-part series, we go into the basic principles of HANA XSA and point out differences with XSC. In the second part, we investigate XSA’s capabilities for persisting data, HDI and CAP. The third part covers the apsect of data loading.


First, one important piece of information: XSC i.e., the native developments of SAP HANA artefacts in the HANA Studio, is obsolete. It is no longer being developed and new features will not be added. The future is XSA and that is where SAP’s entire focus will be regarding HANA.

SAP HANA XSA is a paradigm shift in developing with SAP HANA. This statement may at first seem extreme, because at first glance, compared to XSC, the application has just gotten new components such as NodeJS or HTML5.

Fig.1 Architecture SAP HANA XSA


However, the type of development has changed fundamentally in XSA. Instead of developing objects in packages or schemas close to the database, with XSA SAP is betting on isolated applications and SAP HANA Deployment Infrastructure (HDI) Container. This step was necessary for the cloud capability of the system. With the strategic focus on Cloud Foundry, HANA also had to meet the requirements of the isolated services and applications.

SAP HANA XSA can run on On-Prem systems and in the SAP HANA Cloud. The functional scope is almost identical, and the main difference is the two different development environments.

Business Application Studio

As is common with new technologies, there is also a new development environment with XSA. Here SAP has closed the book on the old tool HANA Studio and is taking a step in a modern direction towards web-based IDEs. With this move there will be no more rolling out of new or updated IDE software, since the development environment is centrally managed and directly accessible from the browser.

As mentioned, XSA can be used with in an On-Prem or Cloud scenario where the used IDE is somewhat different:

  • On-Prem -> SAP Web IDE for SAP HANA
  • Cloud -> Business Application Studio (BAS)

In this blog series we will use a HANA Cloud scenario so that we can engage with BAS more closely.

BAS is a component of the Business Technology Platform (BTP) which features a wide range of views and development options. Whether databases modeling with SQLScript and Calculation Views or applications with NodeJS: All use BAS. The BAS is directly based on Visual Studio Code and runs with extension that can be installed and activated as desired.

Fig. 2: Business Application Studio (BAS)

Unlike XSC, the focus is not direct development in packages and database schemas, but user-defined Multi Target Application (MTA) projects using HDI containers. These HDI containers work like an isolated application inside the database.

At first, using BAS is very intuitive: First a new project is created, in which individual modules such as database or NodeJS, are added. Then, all the required design time objects (Calculation Views, tables, Table Functions) are created in a directory structure. Next, (unlike XSC) these artifacts are not activated but are deployed, through which the relevant database objects are created.

HANA XSC vs. HANA XSA: What are the differences?

XSC resides in the SAP HANA Studio and works with artifacts in packages. These artifacts are design time objects for which the relevant runtime objects are created on activation. Often the artefacts “.hdbdd” are used for the modeling of persistent data in tables and “.calculationview” for the virtual data modeling.

Fig. 3: XSC Calculation View

The executable database objects all belong to the user _SYS_REPO and are in the schema _SYS_BIC. In this scenario, it is very easy to access tables or Calculation Views from other packages/schemas because everything is centrally managed and is thus visible for other users.

With SAP HANA XSA there is also the separation between design-time and runtime objects. Here also artifacts are used for persistent e.g., “.hdbtable” and virtual e.g., “.hdbcalculationview” modeling.

Fig.4: XSA Calculation View

But here the similarities between the two approaches end, because XSA entirely deepens the separation of objects. There is no longer a single “ultimate truth” in the system schema as was the case previously in _SYS_BIC. Every developer sees their (local) version of the design time objects and can make independent changes and deploy them in their own database schema.

But then how exactly can the developments with different versions and developers remain consistent? The answer lies in the source code management with Git, which plays a central role in development with XSA. The relevant repository with its branches and commits makes sure that all the developments remain consistent.

In simple terms, with Git repositories there is a main branch (master) in which the current development is stored. For new features, bug fixes and extensions, developers create appropriate branches and work with local copies there. If these developments are completed, they are inserted in the main thread (commit, merge), in which only the changes are added. When conflicts arise with other modifications, these are checked and cleaned up centrally.

HANA XSA advantages

So does XSA complicate everything? It may be true that the new approaches in XSA at first appears radical and unusual. But there is also a great deal of new potential capabilities that were not possible in the old approach. On the one hand, in terms of data modeling and architecture there is a wide range of new functions for Calculation Views.

  • New node types (Intersect, Minus, Non-Equi Join, Window Function)
  • Debug Mode
  • Performance Analysis Mode
  • Outline

On the other hand, there is a series of new artefacts for modeling that include standard functionalities. One prominent example are the completely reworked flow graphs, which along with data load processes also have nodes for data cleansing and predictive analytics. For data provisioning, there are also the Replication Tasks which are realtime-capable.

There is also the option through the integrated NodeJS to build new SAP Fiori Reports directly on the defined objects with SAP UI5. These applications can then be deployed on different systems and scaled as needed.


In the next part of this blog series, we will look at how to create database objects using an example project. We will look at new virtual modeling capabilities with Calculation Views. An additional focus is on the HDI Container with best practices and how these can be realized in the project.


So what is XSA? XSA is far more than a simple extension of the familiar objects and methods. It is a whole new world, with entirely new opportunities but also rules. Modern applications with database objects, procedures, OData Services and NodeJS applications are now possible in one system and pave the way to a new future with modern concepts and approaches.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Mustafa Bensan
      Mustafa Bensan

      Hi @Mathias,

      Under which circumstances would you choose to develop applications natively using XSA versus the more abstracted approach of CAP (Cloud Application Programming Model)?



      Author's profile photo Mathias Klare-Dobberkow
      Mathias Klare-Dobberkow
      Blog Post Author

      Hi Mustafa Bensan ,

      thanks for your question.

      I will touch on the subject of CAP in my next blog, where we will create a new project and model persistent structures that hold our data.

      In general: when looking at CAP and database objects like tables and views, you write your model in the corresponding .cds file(s). The generated files from .cds are of type .hdbtable and .hdbview. In the most recent update of CAP (cds 7), they sad "goodbye" to the old format of .hdbcds.

      I think there are 2 main aspects when deciding if you want to go with "native" XSA or CAP:

      First, you should consider what the goal of the application is. If you are mainly focused on database development like creating tables, using flowgraphs and procedures, XSA might be sufficient. With native XSA, you can create very dedicated and custom database models and change all aspects of your tables if you want to. On the other hand, if you plan to expose your data via OData or offer services to trigger functions on your database, you need CAP to define the logic.

      Second, it kind of depends on your personal preferences and style. There are developers who very much like the creation of tables and views "directly" via the SQL syntax. CAP often is a new approach and it takes some time getting used to it. It offers quite a lot of handy functionality like reusing aspects and using standard definitions for countries or currencies. But again, some just want to create tables directly and don't want to manage any cds functionality.

      Personally, I try to stick to CAP, as it offers the possiblity to enhance my database models with meaningfuly semantics. I am a big fan of the associations, that are build on database level and act like joins, that are only executed when you select the columns from the connected tables. Again, you can model all this directly by creating the corresponding .hdbtable artifact, but why write more code, if the system does it for you ;).

      Best regards,