Apps and Services of DB module in XSA MTA Project - Part 1

[ssurampally]

When I started working on XS advanced developments in Web IDE for HANA, it took some time to understand  how Applications and services  getting created in a space for Data base artifacts also. Because, it is much different from how we used to do in XS classic HANA repository. Also, it is very similar working on HANA as a service on Cloud foundry environment, because they both share same design principles of cloud foundry.

In this blog, I would like to take a very simple of DB module creation and explain how the services and apps are created during build and deployment of it. Of course, there is official SAP documentation, also developer tutorials on this topic. So I am not explaining the steps to create, build and deploy the  applications, you can find this information from developer tutorials. Here, my objective is to explain how services and apps are being created/modified based on mta.yaml file configurations. It applies to HANA as a service on CF environment on cloud as well for the most part.

I will start with creating a basic DB module in MTA project in Web IDE for HANA.,  from context menu of the MTA project, create a DB module, it does not hold any design time artifacts at this time. Then, tool generates following code in mta.yaml file, we will understand it in detailed.

Picture 1:



Resources and modules:

As shown in the above picture, a resource for hdi container is created and it is assigned to DB module as required object. Resource is a service with hdi-shared plan which will be used to hold the DB artifacts. DB module is an application which requires the hdi container service.

Properties of a resource: properties are useful to expose the resource in other parts of MTA application, you can have dynamic parameter to hold the resource name. In this example it is ${service-name}. so the service name goes into it.

Let us build DB module in Web IDE, we can call this as private build, because it is specific to developer 1, the service generated with this, is going to be my user name prefixed and some technical GUID, you can find that in xs cl tools command,

  xs services



Note: With private build by developer, DB module does not build the application in space, so you don't have that yet. But you will have di-builder application attached as part of the local build, It all gets deployed by the single di-builder instance in each space.

Let us deploy the MTA application now, first generate the .mtar file and then run xs deploy command, CL tools to deploy in space.

After deployment, run xs apps command,



We can see that module name DB is created as application, it will be in a stopped state most of the time, it is used only during deployment for HDB modules.

also run xs services command,



now, a service will be created in that space with out my user name prefix. That is the cleaner name hdi_DB_services which is the resource name in mta.yaml file and  it is bound to the app (DB) created just now.  

So, now let us navigate to Picture 1 and put all these pieces together,  we get a basic understanding  of how the private build and actual deployment works in Web IDE for HANA.

--------------------------------

TARGET_CONTAINER

-----------------------------

When there are 2 or more HDI services defined in the project, HDI container of DB module wouldn't know which HDI service instance needs to be assigned to the db module. So we will need to specify the required HDI instance as the primary one with TARGET_CONTAINER environment variable, so that Container DB objects will get created in that resource.



---------------------------

SCHEMA parameter

----------------------------

If the SCHEMA parameter is not defined during DB module creation, then it generated the schema with project name + module name _1 for Developer 1 and it will be _2 for Developer 2 during the private build, this is to isolate the containers and keep them separate for each developer with no overwriting each others.

Private build:



Actual Deployment: SCHEMA name is generated with some GUID.



In the case of SCHEMA is provided, which is going to be the case in most of the times, Private build will have <SCHEMA_NAME given in yaml file>_1, for developer 2, <SCHEMA_NAME given in yaml file>_2 etc..,  the real deployment will have just the <SCHEMA_NAME given in yaml file>.

when schema value is given, mta.yaml file looks like below.



so in this case private build hdi container will have,  REPORTING_1, REPORTING_2 for each developers,  clear actual deployment will have REPORTING as the SCHEMA name.

----------------------------------------

Package.json:

----------------------------------------

It is an important file in MTA configuration, all the required npm packages are installed via this file. This file is available for every module created/added to the MTA project. like db, node or ui etc..

sample for a db module:

{

  "name": "deploy",

  "dependencies": {

    "@sap/hdi-deploy": "4.5.0"

  },

  "scripts": {

    "start": "node node_modules/@sap/hdi-deploy/"

  }

}

Note: we get MTA build errors when the npm versions are not compatible in pakage.json files. It is important to update the same. 

if you are not sure about the correct compatible version, then just create a new MTA project from a template, add the db or node module then package.json file gets generated with the latest version. So you can pick that up and update the existing MTA files.

Summary: 

In this blog 1, tried to cover the basics of services and apps created during build and deployment, In my next technical article, I will explain what happens during deployment of cross schema services, service_replacements here Part 2 in Web IDE for HANA.

Complete documentation on the services and environment variables can be found in npm module explanation here https://www.npmjs.com/package/@sap/hdi-deploy

 

Thank you.

Sreekanth