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.

What is SAP HANA XSA?

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.

Outlook

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.

Summary

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.