Explaining SAP HANA XS Advanced and SAP HANA Deployment Infrastructure

SAP HANA XS Classic is a web application server with a server-side JavaScript engine embedded in the database.

SAP HANA XS Advanced (and Cloud Foundry) is a platform for microservices-based polyglot web applications on premise (and in the cloud).

SAP HANA Deployment Infrastructure (HDI) provides a service that enables you to deploy database development artifacts to containers.

An SAP HANA HDI container consists of a design-time container and a corresponding run-time container.

SAP HANA Extended Application Services (SAP HANA XS) provides applications and application developers with access to the SAP HANA database using a consumption model that is exposed via HTTP.

SAP HANA functions as a comprehensive platform for the development and execution of native data-intensive applications that run efficiently in SAP HANA, taking advantage of its in-memory architecture and parallel execution capabilities.

Structured accordingly, applications can profit from the increased performance provided by SAP HANA due to the integration with the data source.

SAP HANA extended application services advanced is a polyglot application platform that supports several programming languages and execution environments; for example, Java and Node.js.

In comparison, the classic XS JavaScript (XSJS) is supported by a framework running in the Node.js run time. It uses the old SAP HANA repository in the SAP HANA database.

In simple terms, XS Advanced is basically the Cloud Foundry open-source Platform-as-a-Service (PaaS) with many tweaks and extensions provided by SAP. These SAP enhancements include among other things:

• Integration with the SAP HANA database

• OData support

• Compatibility with the XS Classic model

• Improved application security

SAP HANA XS Advanced also provides support for business applications that are composed of multiple micro-services, which are implemented as separate Cloud Foundry applications, and when combined are also known as multi-target applications (MTA). A multi-target application includes multiple so-called "modules" which are the equivalent of Cloud Foundry applications.

The SAP HANA Deployment Infrastructure (HDI) provides a service that enables you to deploy database development artifacts to so-called containers. This service includes a family of consistent design-time artifacts for all key SAP HANA platform database features which describe the target (runtime) state of SAP HANA database artifacts, for example, tables, views, or procedures. These artifacts are modeled, staged (uploaded), built, and deployed into SAP HANA.

An SAP HANA HDI container consists of a design-time container and a corresponding runtime container.

SAP HANA HDI uses containers to store design-time artifacts and the corresponding deployed runtime (catalog) objects. The SAP HANA HDI strictly separates design-time and runtime objects by introducing the following distinct container types:

• Design-time container – An isolated environment for design-time files.

• Runtime container – Stores the deployed objects built according to the specification stored in the corresponding design-time artifacts.

SAP HANA XS Classic model enables you to create database schema, tables, views, and sequences as design-time files in the SAP HANA repository. Repository files can be read by applications that you develop.

In SAP HANA XS Advanced, application development takes place in the context of a project. The project brings together individual applications in a so-called Multi-Target Application (MTA), which includes a module in which you define and store the database objects required by your data model.

Basically, your project allows you to do the following:

• Define the data model as a design-time object.

• Configure the SAP HANA Deployment Infrastructure.

• Deploy and generate the run time objects (active objects) in the database catalog.

• Consume the model.

HDI containers are a special type of database schemata that manage their contained database objects. These objects are described in design-time artifacts that are deployed by the HDI deployer application. HDI takes care of dependency management and determines the order of activation. HDI also provides support for upgrading existing runtime artifacts when their corresponding design-time artifacts are modified.

Synonyms in XS Advanced enable access to objects that are not in the same schema or application container. Synonyms are most commonly used to hide the real object names from consumers or to give a database object a more convenient name.

Synonyms play a more important role in XS Advanced and HDI than they do in the schemas used in XS Classic. In XS Advanced, using synonyms is the designated method to enable access to objects in other schemas, for example, a schema owned by another XS Advanced application container, provided the access is granted by the other container.

Backing services provide the technology on which XS Advanced application are built, for example:

• Persistence services (databases, key-value stores, and so on)

• Communication services (message queues, e-mail gateways, and so on)

• Authentication services (User Account and Authentication service (UAA))

During application deployment, the build pack ensures that this run time is provided to the application and that the appropriate data sources for the SAP HANA HDI container are bound to the corresponding application container.

The application router is the single-entry point for the (business) application and receives all the requests. It serves static content, propagates and authenticates users, rewrites URLs, and routes proxy requests to other microservices, as well as propagating user information.

SQLScript is relevant for both the XS Classic / Repository approach (essentially SAP HANA 1.0) and also XS Advanced / HDI approach (essentially SAP HANA 2.0).

You should not mix development across both approaches. SAP recommends using XS Advanced / HDI, as the XS Classic / Repository approach is officially deprecated and will eventually disappear from the software.

When using containers, you do not explicitly reference a schema name when referring to database object in your SQLScript. As long as the development objects are in the same container, they will find each other. Only when you need to reference database objects in other external containers or catalog schemas will you need to take action. In that case, you first need to build synonyms in your container that point to the external database object you need access to.