With SAP HANA XSA, SAP has set its strategic course for SAP HANA and put 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 packets 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 part of multi-part series we go into the basic principles of HANA XSA and point out differences with XSC.
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 change in development 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.
However, the type of development has changed fundamentally in XSA. Instead of developing objects in packets 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, the HANA also had to meet the requirements of the isolated services and applications.
SAP HANA XSA can run in both an On-Prem system and with 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 an on-prem or cloud scenario where the IDE used is somewhat variable:
- On-Prem -> SAP Web IDE for SAP HANA
- Cloud -> Business Application Studio (BAS)
In this blog series we will use 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 of these use BAS. The BAS is directly based on Visual Studio Code and runs with plugins that can be installed and activated as desired.
Unlike XSC, the focus is not direct development in packets 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 for example, are added. Then, all of 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 packets. These artifacts are design time objects for which the relevant runtime objects Often the artefacts “.hdbdd” are used for the modeling of persistent data are used in tables and “.calculationview” for the virtual data formatting.
The executable database objects all belong to the user _SYS_REPO and are located in the schema _SYS_BIC. In this scenario, it is very easy to access tables or Calculation Views from other packets/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 (.hdbcds) and virtual (.hdbcalculationview) modeling.
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 statuses 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), in which only the changes are added. When conflicts arise with other modifications, these are viewed and cleaned up centrally.
HANA XSA advantages
So does XSA complicate everything? It may be true that the new approaches in XSA at first appear 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 completed 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 aforementioned 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.
