Tell us what you think

We want to create the best possible experience for our learners. Your feedback helps us to improve the experience for everyone.

Note

Creating and Managing Projects

Objectives

After completing this lesson, you will be able to:

Define the key settings of a project
Manage the lifecycle of a project

MTA Project

A Multi-Target Application (MTA) project is comprised of one or several modules of different types. You learned about module types in a previous lesson. Here, we focus on the SAP HANA Database (HDB) module type.

However, it is important to understand some key settings of an MTA project. Some of them do not have to do only with HDB modules, but are related to the lifecycle of a project in general.

When you create a new project, you have to define a few parameters. Let’s review these parameters.

Key Settings of an MTA Project

Setting	Description	Example
Project name	The name given to the new project in your workspace	proj1
Schema version	Version of the MTA specification	`_schema-version: "2.1"`
Application ID	The identifier of the multi-target application, used during deployment. It must be unique in the target environment, and uses the reverse-URL dot-notation.	`ID: com.sap.mta.sample`
Application version	A three-level application version number (Major.Minor.Patch), used to handle successive deliveries of the same application to runtime environments.	`version: 1.0.3`
Description	A free text describing the purpose of the MTA.

All these settings are stored in the project descriptor file, which is named mta.yaml. This file can be edited with the code editor. It is also automatically updated based on some configuration you perform on the project, in particular when you add an HDB module or define a connection to an external schema or another HDI container.

HANA Database Module

As you have already seen, a Multi-Target Application can include one or several modules of the type HDB (SAP HANA Database). In the context of modeling, a HDB module can define a local persistence (a persistence layer that is defined and deployed in the application itself). When you build a virtual data model based on calculation views - even if the source data is stored outside of the application - the HDB module contains the database artifacts that define this virtual data model.

When you create a new HDB module, you must provide a number of properties for the module. Most of these properties are stored in the descriptor file of the application: (mta.yaml), except for a few. In particular, the namespace property of the module is not stored in the descriptor file but is materialized by the .hdinamespace file located in the src folder.

Key Settings of an HDB Module

Setting	Description	Example
Name	The name of the module. It should be unique within the entire descriptor file (mta.yaml).	`core-database-module`
Type	`hdb` is the reserved module type for an HDB module.	`hdb`
Path	The relative location of the module root within the file structure of the project.	`db`
Schema Name	A specific name for the HDI container schema used for deployment.	`SAMPLE_SCHEMA`

During HDB module creation, you are also asked for an SAP HANA Database Version. You have the choice between SAP HANA Service (legacy service in SAP BTP) and HANA Cloud.

Default Schema Name of the HDB Module Container

During the creation of a HDB module, specifying a schema name is optional.

If you don't specify a schema name, it is generated during the deployment of a project with the following name structure:

Code snippet

<project_name>_<hdi_service_name_in_MTA>_<numeric_increment>

Copy code

For example: MYPROJECT_HDI_DB_1

To identify the name of the generated database schema, open an SQL console connected to the container and execute the following SQL query:

Code snippet

select CURRENT_SCHEMA from DUMMY;

Copy code

Specifying a Schema Name for the HDI Container

If you prefer not to have the schema name generated and would like to use a specific schema name, this is possible. This is done in the descriptor file mta.yaml of your project, and more specifically in the parameters of the hdi-container service that is defined as a resource used by the HDB module.

The following sample shows the additional parameters section of the mta.yaml file where the schema name is defined:

Code snippet

resources:
 - name: hdi-cont
   parameters:
     config:
       schema: <YOUR_SCHEMA_NAME>
   properties:
      hdi-container-name: ${service-name}
   type: com.sap.xs.hdi-container

Copy code

Then, the schema generated during the first build of the HDB module is named as follows:

Code snippet

<YOUR_SCHEMA_NAME>_<numeric_increment>

Copy code

Caution

Although it is possible to force the schema name to be exactly what you specify in the mta.yaml file, by adding a parameter in the config section, this can generate schema naming conflicts in case several projects use the same schema name, so is usually not recommended and you should allow the schema name to be generates automatically as a unique value.

Create a Project with an HDB Module

DemoWatch Demo

Bind an Existing HDB Module to an HDI Service

DemoWatch Demo

HDI Cockpit

Containers play a key role in database development and provide an efficient method of isolating the database runtime artifacts and encouraging modularization. Containers are a key component of HDI development in SAP HANA Cloud. User and roles are granted privileges on containers so that they can access the resources they contain.

An SAP HANA Cloud database will usually have many containers which have been automatically generated when developers deploy database artifacts to the run-time. Each container will have various combination of users and role privileges assigned. This can soon become difficult to manage and so troubleshooting and monitoring can become difficult.

The HANA Deployment Infrastructure (HDI) Cockpit is a tool that provides visibility of all containers. You can add them into container groups and display the users and roles that have been granted access to them.

Application Deployment

You have already learned how to manage some important stages of a modeling project’s lifecycle.

Create a project and define some key settings.
Import and export modeling content, including an entire project.
Deploy selected objects or an entire HDB module.

Let’s now discuss the deployment of an application. We will only consider the deployment of a Multi-Target Application made up of one or several HDB modules. That is, we will not discuss the other tiers such as the user interface or application logic of a full-stack application.

MTA Deployment vs. DB Objects Deployment

Let’s first make a clear difference between deploying DB objects and deploying an entire MTA (application).

When you work on a project, you deploy modeling content to the HDI container on a regular basis, in order to test it, check dependencies, and so on. This is something you trigger from SAP Business Application Studio. To do that, you need to have a modeler role for the space in which the HDI container bound to your HDB module sits.

When you deploy an HDB module (or some of its design-time content), if the deployment is successful, the corresponding runtime objects are generated in the HDI container, running in the corresponding space.

On the other hand, deploying an application is something you do in a target space at a specific point in time, for example to test the application in a QA environment or set the application to production. Deploying an application can be done outside of SAP Business Application Studio. The user who deploys the application does not need to have a developer role in the target space.

To deploy your modeling content to a target environment, such as QA or PROD, you must do the following:

Build the HDB module(s).
Build the entire Project in order to generate MTA archive file (.mtar).
Export the MTA archive.
Deploy the MTA archive in XS Advanced.

Between steps 3 and 4, you must of course make the MTA archive file "available" to the target landscape, for example by copying the file to a specific folder or using a dedicated transport tool.

Note

As you see from the figure, Deploying Models, SAP Business Application Studio is not involved during the deployment (step 4) on the target landscape. In particular, you do not need to create and build the project in the target landscape. SAP Business Application Studio HAS some deployment capabilities, but -again- it is not mandatory. In particular, there is no need to import the project in SAP Business Application Studio in a classical deployment scenario.

Source Files for Deployment

The key source file for application deployment is generated by a build operation at the project level in SAP Business Application Studio. This creates a .mtar(MTA archive) file, which is technically a .rar compressed file. This file is named <Application ID>_<version>.mtar and can be found in your workspace, in the folder mta_archives. This archive contains the file mtad.yaml, which is an equivalent of the mta.yaml file but specific to application deployment.

Another important (though optional) file used for deployment is the .mtaext file. This is an "extension" file in which the space administrator who deploys the application can specify additions or modifications to the mtad.yaml file in order to pass the relevant parameters for the target environment during deployment. Typical examples of what you can specify in the extension file include the following:

The name you want to give to the HDI container schema
The actual name of a user-provided service in the target environment
The actual name of another HDI container service in the target environment

The name of the HDI container(s) created during the deployment of your application is also an important parameter. This is the name of the HDI container resource declared in the mta.yaml file (by default, when you create the HDB module, hdi-<HDB_module_name>). You probably want to make it specific to your application, in order to identify it more easily among in the XS services.

Save progress to your learning plan by logging in or creating an account

Continue to next lesson