SAP HANA Development Environment

SAP HANA Extended Application Services advanced model (XSA) adds an application platform to the SAP HANA in-memory database. It is the connecting piece between the SAP HANA platform and tools that leverage a SAP SQL Data Warehouse, such as SAP Web IDE, SAP PowerDesigner, SAP Smart Data Integration, and Git.

• Supports multiple languages and runtimes (build packs)
• Runtime is decoupled from underlying SAP HANA database
• Controller serves as a central management component; provides REST API

Source code is stored in external Git repository (or local ZIP file in smaller scenarios for single-developer environments)

Browser-based development environment with SAP Web IDE

SAP HANA XS Advanced is an integrated application stack that can be used to develop, deploy and run applications. Applications and database objects run in isolated containers and are delivered as services. XSA lets you scale applications independently from the database services with a new web application server. It supports your choice of programming languages - server-side JavaScript on Node.js, Java on TomEE, Python, Go, and so on. Core Data Services allow developers to create database objects and relationships without SQL. XSA accelerates application development with open source code management tools, such as Git/Gerrit, GitHub, Maven, and so on. It simplifies authentication and authorization with single sign-on support between application and database services. It also allows for scheduled execution of JavaScript and SQLScript programs.

SAP Web IDE is a browser-based tool that simplifies development of native end-to-end applications (Node.js, Java, Python, HTML5, C++) and full-stack application lifecycle management (UI, business logic, database modeling). It runs on the XSA application server and can be used to develop, deploy, compile, expand, and deploy role-based, consumer-oriented applications.

SAP HANA Web IDE comes with:

• A project-based IDE (similar to SAP HANA Studio)
• A database explorer that can be used to run SQL statements and procedures or to debug code
• Full support for graphical data models
• Advanced Git capabilities: Version management, branch viewing, and so on. Better source code management integration into Web IDE.
• Services: Node.js, JAVA, UI5
• Containerized applications → MicroServices

SAP Web IDE is an online development space where an application's development team can work together across time zones and geographic regions to develop project deliverables, using a shared repository. As a Git-enabled development environment, SAP Web IDE allows you to isolate developers and features in order to enable parallel development and testing. This makes projects more manageable, improves workflows, minimizes the overall risk of code failures, and allows for continuous integration and delivery.

Data can be provisioned from almost any source using a wide range of external ETL tools, both SAP and non-SAP. SAP tools such as SAP Data Services are popular with customers who have complex data integration scenarios. However, SAP HANA includes its own powerful, built-in ETL capabilities. These capabilities are brought to you via SAP HANA Enterprise Information Management (EIM). EIM is a component of the SAP HANA platform and is installed once the basic platform has been setup.

SAP HANA EIM enhances, cleanses, and transforms data to make it more accurate and useful. SAP HANA EIM can connect with any source, provision and cleanse data, and load data into SAP HANA on-premise or in the cloud, and for supported systems, it can write back to the original source.

SAP HANA EIM provides the following capabilities:

• A simplified landscape - one environment in which to provision and consume data.
• Access to more data sources.
• In-memory performance, which means increased speed and decreased latency.

SAP HANA EIM consists of two main functionalities; Smart Data Integration and Smart Data Quality.

Smart Data Integration and Smart Data Quality build the data provisioning tier natively within SAP HANA. Smart Data Integration is a set of functionality provided by several components that you can use to retrieve data from an external system, transform it, and persist it in SAP HANA database tables. Smart Data Quality is a set of functionality provided by several components that you can use to cleanse and enrich data before it is persisted in the SAP HANA database. In combination, Smart Data Integration and Smart Data Quality support the following use cases:

• Federation: Sending a query to the SAP HANA database for data that exists in an external system.
• Replication: Copying tables and their contents from an external system into the SAP HANA database with minimal processing.
• Transformation, cleanse, and enrich: Extracting data from an external system, transforming, cleansing, enriching, and persisting the results in the SAP HANA database.
• Virtualization: Viewing data is more accurate after transforming the data.

SAP HANA EIM is integrated in XSA. ETL processes are always based on SDI and SDQ and can be modeled, tested, and executed using the SAP HANA Web IDE.

Developers who work with the SAP PowerDesigner or the SAP Web IDE use Git as a versioning tool. Continuous Integration and Deployment is assured through a Jenkins server. Requirements management is done with Jira throughout the whole process.

The figure shows the core principle behind the reference architecture discussed in this course: DevOps.

For further automation of the agile development process of an SAP SQL Data Warehouse, all phases are supported by tools, or even completely automated by tools. In this exemplary phase of the development process all steps are done (semi-automatically). Thereby Git handles the different versions of definitions for the design-time objects created by several developers. Each developer works in their own sandbox, and constantly interacts with the Git repository. After finishing a definition task, the developed definitions (metadata) are combined with the metadata of other developers, using the Git branch system. For instant feedback to the developers, the CI/CD tool handles the interaction with XSA and the conversion of metadata to runtime objects in an automated process, started automatically by developer actions. After successfully converting the definitions of the developers into runtime objects in a test area, the development is tagged as successful or not.

In these automated tests (depending on the situation) either integration tests, plausibility checks (such as naming conventions and development guidelines), or runtime tests are executed. These automated tests ensure the quality of the development and enable the project owner to always deploy the last successfully tagged developments. Furthermore the developers receive instant and detailed feedback depending on their developments and possible errors (such as naming conventions, fault integration, empty tables, and fault flowgraphs).

Broken builds are an issue in collaborative software development. The solution is an automated, standardized build and test procedure with an automatically running "central build". The build result is the only reference to decide whether the project is broken or clean from a build perspective. Jenkins is a popular CI/CD tool that provides this to enable continuous integration and continuous delivery (CI/CD) throughout the development process. In a nutshell, Jenkins triggers a build for every change made in the source code repository. Once the code is built it is deployed on the test server and/or the production server.

The workspace in the SAP Web IDE is a structure where you can work on one or several projects. Each user of the SAP Web IDE for SAP HANA has their own workspace.

The workspace of a user can contain as many projects as needed, but each project must have a different name.

The source code for your application is stored inside various modules of your project.

When you create a new project, the creation wizard will ask you to choose a project template. The Web IDE for SAP HANA comes with several templates and you choose the one most suitable for the type of application you want to create. Depending on the template you choose, you will be prompted for various settings which are then used to create the very basic project shell.

The first step is to create a module of the type you require and then begin developing the source code in that module. You can create as many modules as you need for your project, for example, you may choose to create two database modules: one for tables and one for views, if that helps with better organization of source code. You should provide a helpful name for the module so that it is easy to identify the module type and what it contains. Do not create empty modules that you will not use.

In this course, we begin by focusing on the database (HDB) module but then introduce other modules later.

Hint

Because all types of modules are represented by a folder icon in your project structure, it is not easy to spot the different module types. You can open the mta.yaml file to list all modules in a project. Each module will be identified with its module type. When you add or remove a new module, the mta.yaml file is automatically adjusted.

In XS Advanced, each runtime object has an object identifier, which is used to reference this object within the container/schema.

A typical structure of a runtime object identifier is as follows:

<Namespace>::<Runtime Object Name>

• The Runtime Object Name is mandatory.

• The Namespace is an optional part of the object identifier, and is mainly used to organize logically the runtime objects within the container.

When you work with XS Advanced projects, the naming of runtime objects is distinct from the way design-time files are organized. The main advantage of this approach is that you can more easily relocate design-time objects from one folder to another without impacting the corresponding runtime object name.

The object identifiers (including the namespace) are always specified in the design-time objects. That is, the design-time objects must define without ambiguity how the runtime objects will be identified.

Let’s take an example of a modeling object, a calculation view CVC_SalesOrders, with its design-time version in the SAP Web IDE workspace, and its runtime version (created during build) in the container schema.

The figure, Runtime Objects Identifiers, explains how folders are used to organize the design-time files in the HDB module of your application, and shows what the runtime object identifier could be. In this scenario, the calculation view identifier has a namespace. Let’s now discuss the main rules and possible options to define the namespace.

The following rules apply to the namespace:

• The namespace is optional. Some objects can be defined with a namespace in their identifier, and others without.

• A HDB module can have no namespace defined at all, or can specify any number of different namespaces.

• The namespace is always identical for all the design-time objects stored in the same folder.

• The namespace must always be explicitly mentioned inside the design-time files and must correspond to the namespace defined explicitly in the containing folder, or implicitly cascaded from a parent folder.

The definition of a namespace is possible in the src folder of an HDB module, and also in any of its subfolders. This is done with a file called .hdinamespace.

When you create an HDB module, a .hdinamespace file is created automatically in the folder <hdbmodulename> → src and contains a default value "<application_name>.<HDB_module_name>". You can modify this file to apply different rules than the default to your project’s namespaces.

The content of any .hdinamespace file is always comprised of two elements, name and subfolder.

To structure your runtime modeling content in a way that suits your needs, you can add a .hdinamespace file to any sub-folder of the src folder. The "subfolder" setting determines whether the sub-folder names should be added "implicitly" to the namespace for objects located in sub-folders (append) or not (ignore).

Caution

When you modify the specifications of the .hdinamespace file (or create a new .hdinamespace file in a folder), the new namespace rules are taken into consideration only after the .hdinamespace file has been built.

As a general recommendation, the namespace rules should be defined before you create modeling content. Indeed, if you modify these rules after creating modeling content, you have to adjust the object identifiers (which includes the namespace) before you can build your models. And this is even more complicated if dependencies exist between models.