MTA Model
An MTA model is a platform-independent description of the different application modules, their interdependencies and configuration data that they expose, and the resources they require to run. This model is specified, using YAML (www.yaml.org), in descriptor files that accompany the development and deployment processes.
An MTA model serves the following purposes:
- Define an application composed of multiple (heterogeneous) sub-components (benefit: tools can establish a unique lifecycle of these sub-components)
- Declare resources the application depends upon at runtime and/or deployment time (benefit: tools can allocate and bind such resources)
- Define configuration variables (and their relation), whose values distinguish different deployments of the application (benefit: tools can bind sub-components, can automate deployment based on default settings, or request missing mandatory values interactively
Watch this video to learn about the Development to Deployment flow.
As seen in the image the application developer uses development tools to create the modules of an MTA and the corresponding MTA descriptor (mta.yaml).
The application can then be distributed in the form of an MTA archive including the MTA deployment descriptor (mtad.yaml). This specification describes an archive format as a convenient distribution file. As indicated by the direct arrow from development tools to deployer,
MTA deployers may also accept the pure contents of this format, namely the directory structure of files with a deployment descriptor (mtad.yaml).
An administrator optionally augments the MTA model in the deployment descriptor with an extension descriptor(mtaext.yaml),and uses the MTA deployer to orchestrate the actual deployment.
We will focus on the Development Descriptor file(mta.yaml).
Note
The MTA development descriptor contains the following parts:
- Global elements
These include the application identifier and version, a description (optional), copyrights, author, and so on.
- Modules
Modules created in the application, such as the SAP HANA database module and the Node.js module, including name, type, path, and requirements on other modules.
- Resources
Dependent services that are not provided by the application, such as XS Advanced User Account and Authentication (XSUAA), XS Advanced HANA Deployment Infrastructure (XSHDI) container, and XSJob-Scheduler.
- Properties
These can be specified when the value has to be determined during the deployment, for example, for generated URLs of other services or API keys.
- Parameters
Reserved variables of a module, which can be accessed by other modules, for example, user, app-name, default-host, or default-uri using the placeholder notation. Parameters can be read-only or read/write enabled.
Global Elements
- _schema-version
Specifies the version of the MTA descriptor in the following schema: <major>.<minor>.<patch> Indicating a major version is enough
- ID
Mandatory string to identify the application
- Description
Optional description text
- Version
Mandatory version of the application: <major>.<minor>.<patch>
- Provider
Optional string to specify the organization providing the application
- Copyright
Optional copyright information
Modules
Within the MTA development descriptor, the modules element declares the source modules of the MTA project.
- Name
Mandatory name of the module. Unique in the descriptor file
- Type
Mandatory content of the module, for example, HDB, Node.js, JAVA, HTML5
- Path
Mandatory file system path starting from the applications root director
- Description
Optional description text
- Requires
Optional section containing required sources of other modules
- Provides
Optional section containing configuration data used by other modules
- Properties
Optional named variable containing application-specific configuration data
- Parameters
Optional named variable to be used by the deployer, for example, the amount of memory for the module.
Here is the list of available Module Types:
Resources
A resource is something that is required by a module of the MTA at runtime, or at deployment time, but not provided inside the MTA. More precisely, an MTA descriptor declares a resource dependency, not the resource itself. Sometimes they are referred to as Backing Services.
- Name
Mandatory name of the module, unique in the descriptor file.
- Type
Mandatory content of the resource, for example, com.sap.xs.uaa or com.sap.xs.hdi-container
- Description
Optional description text
- Properties
Optional named variable containing application-specific configuration data
- Parameters
Optional named variable to be used by the deployer, for example, the amount of memory for the module
Here is the list of available Resource Types:
Parameters
Parameters are reserved variables that influence the behavior during the deployment process and/or during runtime. A parameter can either be read-only, which is the case for most system parameters, read/write, or write-only.
We can specify the memory and disk-quota parameters for the user_ui module, which advises the deployer to grant memory and disk-space to the application as defined in the section.
In addition, we refer to the service-name and default-url parameters that are filled by the system, using the placeholder notation ${<parameter_name>}. During the deployment, the parameter value is determined and the placeholder is replaced with the actual value.
Here is a list of commonly used parameters:
In the figure above you can find some of the available parameters. You can find the full list in the MTA Deployment Descriptor Syntax section of the SAP HANA Developer Guide:
MTA Editor
As an alternative to the code editor for the MTA file, the SAP Business Application Studio also provides the possibility to use the MTA editor to make changes. You can find the form-based editor on the context menu of the mta.yaml file.