Modules

The modules section of the deployment descriptor lists the deployable parts contained in the MTA deployment archive.

The following elements are mandatory:

name - must be unique within the MTA it identifies
type - defines which deployment mechanism to be used for this module

Optional module attributes include:

path - the file-system path relative to the root of the MTA directory. The content of the file is used to create or update the CF app or content, depending on the module target. The path is used only during MTA build. In an already built MTA archive (MTAR), path is ignored and only corresponding entry in MANIFEST.MF for the module is processed.

The path is applicable only when MTA is assembled based on deployment descriptor (mtad.yaml), and not on development descriptor (mta.yaml)
description - non-translatable, free-text string; the string is not meant to be presented on application user interfaces (UI)
properties - a structured set of name-value pairs; if a module, which requires the resource, represents a CF application, the resource properties are injected into the environment of the application
parameters - reserved variables that affect the behavior of the MTA-aware tools, such as the deployer
deployed-after - the attribute is used to specify the order in which modules should be processed. Its value is a list comprised of the names of other modules within the same MTA. When this attribute is assigned to a module, it indicates that the module should be processed after the listed modules have been processed.
Note:

When using the deployed-after parameter in Blue-Green Deployment of Multitarget Applications, keep in mind that it cannot be used to alter the deployment order of the modules even though its name suggests otherwise. Instead, it can be used to specify the following:
- In the first phase of the blue-green deployment, the deployed-after attribute is used to determine the order in which all idle applications are created.
- In the final phase of the blue-green deployment, the deployed-after attribute is used to determine the order in which all idle applications are restarted.
- It does not affect the testing phase, where both the live and idle versions of the applications are running in parallel.
Note:

When bg-dependency-aware-stop-order is enabled, the deployed-after attribute is used to determine the order in which all idle applications are restarted, helping prevent transient failures caused by dependencies being temporarily unavailable. For more information on bg-dependency-aware-stop-order, see the Top-Level Parameters table in Parameters and Properties.
requires - specifies the names of requires sections provided in resource that have been declared for the same MTA. Tools check if all required names are provided within the MTA.
provides - specifies the names of provides sections, each containing configuration data; the data provided can be required by other modules in the same MTA

Tip:

Modules can be deployed in parallel. See Parallel Module Deployment.

MTA Module Types

Modify the following MTA module types by providing specific properties or parameters in the MTA deployment descriptor (mtad.yaml).

MTA Default Modules Types

Module Type	Default Parameter Values and Description	Module Properties	Result
`javascript.nodejs`	No default parameter. Note: We strongly recommend that you specify the appropriate buildpack for your application.modules: parameters: buildpack: binary_buildpack To do so, use the `buildpack` - name: my-binary-app module parameter.	None	CF application with automatic buildpack detection
`nodejs`	`buildpack`(`nodejs_buildpack`)	None	CF application with Node.js runtime
`custom`	No default parameter. Note: We strongly recommend that you specify the appropriate buildpack for your application. To do so, use the `buildpack` module parameter.	None	CF application with automatic buildpack detection
`application`	No default parameter. Note: We strongly recommend that you specify the appropriate buildpack for your application. To do so, use the `buildpack` module parameter.	None	CF application with automatic buildpack detection
`java`	`buildpack` (`sap_java_buildpack_jakarta`)	None	CF application with Automatic runtime detection by `sap_java_buildpack_jakarta`
`java.tomcat`	`buildpack` (`sap_java_buildpack_jakarta`)	None	CF application with Tomcat runtime of `sap_java_buildpack_jakarta`
`java.tomee`	`buildpack` (`sap_java_buildpack_jakarta`)	None	CF application with Automatic runtime detection by `sap_java_buildpack_jakarta`
`com.sap.xs.hdi`	`no-route` (`true`) Do not assign a route to the application. `memory` (`256MB`) `health-check-type` - (`none`) `no-start (true)` `cf-task` `command (npm start)` `memory (256MB)` `name (deploy)` `dependency-type` (`hard`) In circular module-dependencies, deploy modules with dependency type “hard” first buildpack``(nodejs_buildpack)	`EXIT (1)`	CF application with HDI content activation
`com.sap.xs.hdi-dynamic`	`buildpack`(`nodejs_buildpack`)	None	CF application with Node.js runtime
`com.sap.portal.content`	Note: Before using this module type, update the content deployer applications to their latest version. `no-route` (`true`). Defines if a route should be assigned to the application. `no-start` - (`true`). Only the one-off tasks will be executed, that is, without triggering the start of the application. `memory` (`256M`). Defines the memory allocated to the application. `tasks` (`name:deploy, memory:256M, command:npm start)` For more information, see Tasks. `dependency-type`(`hard`). Defines if this module should be deployed first, if it takes part in circular module dependency cycles. If `hard` means that this module is deployed first. buildpack``(nodejs_buildpack)	None	CF application with SAP Fiori launchpad content
`com.sap.portal.site-content`	Note: This module type is deprecated. You have to use `com.sap.portal.content` instead.	None	CF application with SAP Fiori launchpad content
`com.sap.application.content`	Required dependency parameters: `content-target(false)` Specify that the resource would be used as a target for the module content deployment.	None	Direct content deployment to backing services
`com.sap.html5.application-content`	Note: This module type is deprecated. Please use `com.sap.html5.application.content` instead. Note: Keep the dependency to `@sap/html5-app-deployer` updated to the latest version. If you are using an older version, you might encounter some issues. `no-route` (`true`). Defines if a route should be assigned to the application. `memory` (`256M`). Defines the memory allocated to the application. `execute-app` - (`true`). Defines whether the application is executed. If yes, the application performs certain amount of work and upon completion sets a `success-marker` or `failure-marker` by means of a log message. `success-marker` (`STDOUT:The deployment of html5 application content done.)` `failure-marker`(`STDERR:The deployment of html5 application content failed.`) `stop-app` (`true`). Defines if the application should be stopped after execution. `check-deploy-id` (`true`) - Defines if the deployment (process) ID should also be checked when checking the application execution status. `dependency-type`(`hard`). Defines if this module should be deployed first, if it takes part in circular module dependency cycles. If `hard` means that this module is deployed first. `health-check-type`(none). Defines if the module should be monitored for availability. buildpack``(nodejs_buildpack)	None	Deploys a content deployment application, and creates a task that performs the content deployment.
`com.sap.html5.application.content`	Note: Keep the dependency to `@sap/html5-app-deployer` updated to the latest version. If you are using an older version, you might encounter some issues. `no-route` (`true`). Defines if a route should be assigned to the application. `no-start` - (`true`). Only the one-off tasks will be executed, that is, without triggering the start of the application. `memory` (`256M`). Defines the memory allocated to the application. `tasks` (`name:deploy, memory:256M, command:npm start)` For more information, see Tasks. `dependency-type`(`hard`). Defines if this module should be deployed first, if it takes part in circular module dependency cycles. If `hard` means that this module is deployed first. buildpack``(nodejs_buildpack)	`EXIT (1)`	CF application with SAP HTML5 content
`staticfile`	`buildpack` (`staticfile_buildpack`)	None	CF application with static file runtime
`go`	`buildpack`(`go_buildpack`)	None	CF application with Go runtime
`python`	`buildpack`(`python_buildpack`)	None	CF application with Python runtime
`php`	`buildpack`(`php_buildpack`)	None	CF application with PHP runtime
`binary`	`buildpack`(`binary_buildpack`)	None	CF application with Binary runtime

To choose a binary_buildpack, define it by using the following:

Sample Code:

modules:
  - name: my-binary-app
    type: custom
    parameters:
      buildpack: binary_buildpack

Module-Specific Parameters

Module parameters have platform-specific semantics. To reference a parameter value, use the placeholder notation ${<parameter>}, for example, ${default-host}.

Tip:

It is also possible to declare metadata for parameters and properties defined in the MTA deployment descriptor. The mapping is based on the parameter or property keys. For example, you can specify if a parameter is required (optional: false) or can be modified overwritable: true. See Metadata for Properties and Parameters.

The following parameters are supported:

Note:

If you can't find a specific parameter from the native Cloud Foundry manifest here, refer to Prerequisites and Restrictions to see which Cloud Foundry features are currently not supported.

MTA Development and Deployment Module Parameters

Parameter	Scope	Read-Only / Write	Description	Default Value	Example
`app-features`	Module	Write	Allows enabling, disabling, and querying specific features for individual applications. These features typically control behaviors or capabilities related to application execution. The parameter accepts a map as a value. All parameters in the map are passed directly to the CF API. This mechanism ensures that all future app features will be automatically supported through MTA deployment. The parameter is especially useful when many services are bound to an application, and all credentials inside the `VCAP_SERVICES` environment variable exceed the maximum size of 130 KB (see Cloud Foundry environment variables). In this case, the application cannot be staged successfully. To solve that issue, you can switch to the "file-based VCAP services" method by enabling the respective app feature, and adapt your application coding accordingly to use a file instead of the `VCAP_SERVICES` environment variable. See Delivering service credentials to an app. For more information about the supported features, see Supported app features. Note: If you want to configure SSH enablement, use this parameter instead of the deprecated `enable-ssh` parameter.	n/a	`modules: - name: foo type: application parameters: app-features: file-based-vcap-services: true ssh: true`
`app-name`	Module	Write	The name of the application in the Cloud Foundry environment to be deployed for this module, based on the module name	`${default-app-name}`	`node-hello-world` `com.sap.xs2.samples.xsjshelloworld.node-hello-world`
`apply-namespace`	Module	Write	Applies namespace to the application name. When you set `apply-namespace` to the application name and do not specify `apply-namespace` for its route, the namespace is applied to both the application name and its route. If the `namespace` value is not provided in the CLI options, it is not applied. For more information, see Fine-Grained Configuration.		`modules: - name: java ... parameters: apply-namespace: true`
`buildpack`	Module	Write	The name or the URL of a custom buildpack required by the application	Empty, or as specified in the deploy service configuration	`buildpack: git://github.acme.com/xs2-java/xs2javabuildpack`
`buildpacks`	Module	Write	An array of buildpacks. If a buildpack parameter already exists, it will be overwritten by the buildpacks listed in the buildpacks parameter, so that you have to include it in the array.	Empty, or as specified in the deploy service configuration	`buildpacks: [java_buildpack, nodejs_buildpack, staticfile_buildpack]`
`command`	Module	Write	A custom command required to start the application	Empty, or as specified in the deploy service configuration	`command: node index.js`
`create-service-broker`	Module	Write	Specifies whether [true\|false] a service broker should be registered for the application module	`false`	`create-service-broker: true`
`default-app-name`	Module	Read-Only	The name of the application in the Cloud Foundry environment to be deployed for this module, based on the module name	The module name with or without a namespace prefix	`node-hello-world` `com.sap.xs2.samples.xsjshelloworld.node-hello-world`
`default-host`	Module	Read-Only	The default host name, which is composed based on the module name to ensure uniqueness. Used with host-based routing to compose the default URI, see below. It follows the convention `${org}-${space}-<module_name>`. Tip: We recommend you explicitly use the `routes` parameter. See Routes. Note: Host names that do not comply with the Cloud Foundry naming limitations are automatically corrected: Any characters that are not within the allowed `a-z` and `0-9` ranges are replaced by dashes (-) to prevent deployment issues. If the host name length exceeds 63 symbols, the name is shortened and its end is replaced with a hash code. Note: When used in blue-green deployment the value is resolved depending on the phase. During the testing phase the "idle" suffix will be appended to the host. If you want to use the live version only, refer to `${default-live-host}`.	Generated as described in the description	`trial-a007007-node-hello-world`
`default-instances`	Module	Read-Only	The number of application instances that are started during the deployment	1	`default-instances: 1`
`default-live-app-name`	Module	Read-Only	Valid for blue-green deployment. Specify this parameter if you want the name of the Cloud Foundry application that is to be deployed with this module to be based on the name of the module. For standard deployment the parameter will be the same as `default-app-name` regardless the phase.	The module name with or without a namespace prefix	`node-hello-world`
`default-live-domain`	Module	Read-Only	Valid for blue-green deployment. The value of this parameter is the default domain for the current organization.
`default-live-host`	Module	Read-Only	Valid for blue-green deployment. Specify this parameter if you want to use `${default-host}` without the “idle” suffix during the testing phase of the blue-green deployment.	Generated as described in the description	`trial-a007007-node-hello-world`
`default-live-uri`	Module	Read-Only	Valid for blue-green deployment. Specify this parameter if you want to use `${default-uri}` without the “idle” suffix during the testing phase of the blue-green deployment.	Generated as described in the description	`trial-a007007-node-hello-world.cfapps.acme.ondemand.com`
`default-live-url`	Module	Read-Only	Valid for blue-green deployment. Specify this parameter if you want to use `${default-url}` without the “idle” suffix during the testing phase of the blue-green deployment.	Generated as described in the description	`${protocol}://${default-live-uri}`
`default-uri`	Module	Read-Only	The default URI, composed as `${host}.${domain}` (host-based routing). Note that `${host}` will be the same as `${default-host}`, unless specified explicitly as a parameter. Similarly, `${domain}` would be the same as `${default-domain}`, unless specified explicitly. Note: When used in blue-green deployment the value is resolved depending on the phase. During the testing phase the "idle" suffix will be appended to the host of the URI. If you want to use the live version only, refer to `${default-live-uri}`.	Generated as described in the description.	`trial-a007007-node-hello-world.cfapps.acme.ondemand.com`
`default-url`	Module	Read-Only	The default URL, composed as `${protocol}://${default-uri}`. Note that the `${default-uri}` placeholder is resolved as `${host}.${domain}` (host-based routing) Note: When used in blue-green deployment the value is resolved depending on the phase. During the testing phase the "idle" suffix will be appended to the host of the URL. If you want to use the live version only, refer to `${default-live-url}`.	Generated as described in the description.	`${protocol}://${default-uri}`
`dependency-type`	Module	Write	Deployment order of modules with circular dependencies	soft	`dependency-type: hard` `dependency-type: soft`
`disk-quota`	Module	Write	The disk space that will be available to the application. This parameter requires a unit of measurement M, MB, G, or GB in upper or lower case.	1, or as specified in module-type	`disk-quota: 1G`
`docker`	Module	Write	Creates a module from a docker image. When using a docker image parameter, we do not need to specify the module in the `MANIFEST.mf` file. An image parameter is a docker image from the Docker Hub or somewhere else. The username and the password are optional, but if a Docker image from a private repository is uploaded, then they are mandatory. When uploading a docker image, the content of a module is not needed.	n/a	Sample Code: `modules: name: foo type: application parameters: docker: image: cloudfoundry/test-app username: <optional username> password: <optional password>`
`domain`	Module	Write	The domain on which the application is available later	`${default-domain}`	`domain: ${default-domain}.acme.com`
`domains`	Module	Write	The domains on which the application is available later. The resulting application routes are the Cartesian product of the domains and hosts. That is, a separate route for each host is constructed on each domain.	`domains: - ${default}`	`domains: - ${default-domain}.acme.com - test-${default-domain}.acme.com`
`enable-ssh`	Module	Write	Enables use of SSH within an application. Supported for the Diego container runtime environment only. Note: This parameter is deprecated. To enable SSH within an application, use the `app-features` parameter instead.	n/a	`"enable-ssh": true` `"enable-ssh": false`
`enable-parallel-service-bindings`	Module	Write	Enables or disables the parallel binding or unbinding of services during deployment. If disabled, the services are bound and unbound sequentially in the order provided in the deployment descriptor.	`true`	Sample Code: `- name: <module name> type: <module type> parameters: enable-parallel-service-bindings: false`
`health-check-http-endpoint`	Module	Write	If the `health-check-type` parameter is set to `http`, the controller will do a `GET` request to this endpoint. The application will be considered as healthy if the response is 200 OK.	If `health-check-type` is set to `http`, the default value is `/`, otherwise there is no default value.	`health-check-type: http` `health-check-http-endpoint: /health`
`health-check-timeout`	Module	Write	The application health check timeout in seconds	n/a	`health-check-timeout:120`
`health-check-invocation-timeout`	Module	Write	The time period in seconds, within which the application health check should be automatically started. If the health check does not start within the defined time period, it is omitted, and the deployment process continues.	n/a	`health-check-invocation-timeout:16`
`health-check-type`	Module	Write	The application health check type	`port`	`health-check-type: port` `health-check-type: http` `health-check-type: process`
`host`	Module	Write	The hostname or subdomain where an application is available later. If you want to create a wildcard hostname, use an asterisk in quotes ("*").	`${default-host}`	`host: ${space}-node-hello-world` `host: "*"`
`hosts`	Module	Write	The hostnames or subdomain where an application is available later. If you want to create a wildcard hostname, use an asterisk in quotes ("*").	`hosts: - ${host}`	`modules: - name: my-app type: application parameters: hosts: - ${space}-node-hello-world - "*"`
`idle-domain`	Module	Write	Valid for a blue-green deployment when a new application version is started on a temporary route. Specify this parameter if you want to use another domain for temporary routes.	`${default-domain}`	`modules: - name: app type: nodejs parameters: idle-domain: "<some.domain>"`
`idle-domains`	Module	Write	Valid for a blue-green deployment when a new application version is started on several temporary routes. Specify this parameter if you want to use other domains for temporary routes by listing them in an array.	`${default-domain}`	`modules: - name: app type: nodejs parameters: idle-domains: ["<some.domain>", "<some.other.domain>"]`
`idle-host`	Module	Write	Valid for a blue-green deployment when a new application version is started on a temporary route. Specify this parameter if you want to use another host for a temporary route. Note: The new application will start on a route comprised of the specified host and the default domain.	`${default-host}-idle`	`modules: - name: app type: nodejs parameters: idle-host: "<some-hostname>"`
`idle-hosts`	Module	Write	Valid for a blue-green deployment when a new application version is started on temporary routes. Specify this parameter if you want to use other hosts for temporary routes by listing them in an array. Note: The new application will start on routes comprised of the specified hosts and default domain.	`${default-host}-idle`	`modules: - name: app type: nodejs parameters: idle-hosts: ["<some-hostname>", "<some-other-hostname>"]`
`idle-routes`	Module	Write	Valid for a blue-green deployment when a new application version is started on temporary routes. Specify this parameter if you want to use other routes for the application.	`${default-uri}-idle`	`modules: - name: app parameters: idle-routes: - idle-route: "<your-first-idle-hostname.your.first.idle.domain>" - idle-route: "<your-second-idle-hostname.your.second.idle.domain>"`
`instances`	Module	Write	The number of application instances that will be started during the deployment	`${default-instances}`	`instances: 2`
`keep-existing`	Module	Write	Defines the application attributes which will be kept after the deployment or blue-green deployment has finished. The supported attributes which could be kept are application environment, application bindings and application routes. If not specified, the default values are false, which indicates that each application attribute will be updated with the new values presented in the deployment descriptor.	`false`	Sample Code: `keep-existing: env: true service-bindings: true routes: false`
`keep-existing-routes`	Module	Write	When specified on module level, it indicates if the existing routes of the module's corresponding application should be kept even if they are not defined within the deployment and/or extension descriptors. When specified on top level, under the `parameters` section of the descriptor, it indicates if the existing routes of all applications within that MTA should be kept. Note: The module-level variant of the parameter has priority over the top-level parameter. This parameter is typically used when users want to keep the routes they have mapped manually by using the `cf map-route` command. We discourage this approach, as manual operations could lead to inconsistent deployment results and difficult troubleshooting. We recommend you to define all routes in the deployment and/or extension descriptors, which allows for their automatic management.	`false`	Sample Code: `parameters: keep-existing-routes: true modules: - name: foo type: nodejs parameters: keep-existing-routes: false - name: bar type: nodejs - name: baz type: nodejs`
`memory`	Module	Write	The memory limit for all instances of an application. This parameter requires a unit of measurement M, MB, G, or GB in upper or lower case.	256M, or as specified in module-type	`memory: 128M`
`no-route`	Module	Write	Configures the deployer to create or skip the creation of a route for the application described by the module	false	`no-route: true`
`no-start`	Module	Write	Start/do not start the application during deployment. Tip: This parameter setting overrides the command-line option `--no-start`. If you explicitly set the `no-start` to `false` for the module `foo` in the example provided, then the module `foo` is started on deployment, even if you also specify the command-line option `--no-start` with the `cf deploy` command.	Depends on the command line option `--no-start`	`no-start: true`
`readiness-health-check-http-endpoint`	Module	Write	The endpoint called to determine if the app is ready. The parameter can be applied if the `readiness-health-check-http-endpoint` parameter is set to `http`. The controller will make a `GET` request to this endpoint, and the application will be considered healthy if the response is 200 OK.	n/a	Sample Code: `readiness-health-check-type: http readiness-health-check-http-endpoint: /health`
`readiness-health-check-type`	Module	Write	The type of health check to be performed on the module: `http`, `port`, or `process`	`process`	`readiness-health-check-type: port` `readiness-health-check-type: http` `readiness-health-check-type: process`
`readiness-health-check-invocation-timeout`	Module	Write	The timeout in seconds for individual readiness health check requests. The parameter can be used for the `http` and `port` health check types.	n/a	`readiness-health-check-invocation-timeout: 20`
`readiness-health-check-interval`	Module	Write	The amount of time in seconds between individual readiness health check requests	n/a	`readiness-health-check-interval: 20`
`restart-on-env-change`	Module	Write	Specifies whether an application should be restarted if an environment variable has been changed in one of the following categories: vcap-application vcap-services user-provided Note: If you set these parameters to `false`, the changes in environment are not consumable by a running instances of the application. If your application depends on the latest environment, it might become outdated.	Sample Code: `restart-on-env-change: vcap-application: true vcap-services: true user-provided: true`	Sample Code: `restart-on-env-change: vcap-application: false vcap-services: true user-provided: true`
`routes`	Module	Write	A parameter that lists multiple HTTP routes. For more information, see Routes.	`${default-uri}`	Sample Code: `modules: - name: my-app type: application parameters: routes: - route: "*foo.my.custom.domain/path" - route: foo.my.custom.domain/path - route: foo.${default-domain}/path`
`route-path`	Module	Write	The context “route-path” which is part of the application default URI. Context path routing is routing based not only on domain names (host header) but also the path specified in the URL.	n/a	`route-path: /myapp`
`service-broker-name`	Module	Write	The name of the service broker in the Cloud Foundry environment to be created and registered for the specified application module	`${app-name}`	`service-broker-name: jobscheduler` `service-broker-name: ${app-name}`
`service-broker-password`	Module	Write	The password used for authentication by the XS controller at the service broker when performing service-related requests. The parameter is mandatory if `create-service-broker: true`.		`service-broker-password: ${generated-password}`
`service-broker-space-scoped`	Module	Write	Makes the service plans of the broker visible only within the targeted space.	`false`	`service-broker-space-scoped: true`
`service-broker-url`	Module	Write	Specifies the value of the service broker universal resource locator (URL) to register; service requests are sent to this URL. The parameter is mandatory if `create-service-broker: true`.		`service-broker-url: ${default-url}`
`service-broker-user`	Module	Write	The name of the user required for authentication by the XS controller at the service broker when performing service-related requests. The parameter is mandatory if `create-service-broker: true`.		`service-broker-user: ${generated-user}`
`skip-deploy`	Module	Write	Use this parameter to skip the deployment of a specified module even if it is present in the descriptor. If you add this parameter for an already deployed module, this module will be deleted in the next operation.	`false`	Sample Code: `modules: - name: foo type: application parameters: skip-deploy: true`
`stack`	Module	Write	Use this parameter to define which prebuilt root file system (`rootfs`) you want to use.	n/a	Sample Code: `modules: - name: foo type: application parameters: stack: cflinuxfs3`
`stage-timeout`	Module	Write	Defines how long, in seconds, your application can take during staging before the MTA operation times out. See Application-Specific Timeouts.	1h	`modules: - name: java …………….. parameters: stage-timeout: 100`
`start-timeout`	Module	Write	Defines how long, in seconds, your application can take to start before the MTA operation times out. See Application-Specific Timeouts.	1h	`modules: - name: java …………….. parameters: start-timeout: 100`
`task-execution-timeout`	Module	Write	Defines how long, in seconds, your application can take to execute a task before the MTA operation times out. See Application-Specific Timeouts.	12h	`modules: - name: java …………….. parameters: task-execution-timeout: 100`
`tasks`	Module	Write	Specify tasks, which are available for execution in the current droplet of the application. Also provide use of environment variables which are specified with the `env` scope.	n/a	`tasks: - name: task-1 command: some-script.sh env: env1: value1 env2: value2`
`upload-timeout`	Module	Write	Defines how long, in seconds, you can upload your application binary before the MTA operation times out. See Application-Specific Timeouts .	1h	`modules: - name: java .......... parameters: upload-timeout: 100`
`timestamp`	Module	Read-Only	Current timestamp in milliseconds	Generated as described in the description.

Module-Specific Properties

The following properties are supported:

MTA Development and Deployment Module Properties

Property	Description	Default Value	Example
`MTA_WAIT_AFTER_APP_STOP`	Adds configurable delay in seconds, after stopping the application. Note: Reserved environment variable for subsequent MTA operations, which is used in blue-green deployment and undeployment. Tip: Can be used to introduce a faux delay between stopping an application and unbinding its services, in order to avoid errors when unbinding from an application that is still in the process of stopping.	n/a	Sample Code: `modules: - name: my-app type: application properties: MTA_WAIT_AFTER_APP_STOP: 30`

Property

Description

Default Value

Example

MTA_WAIT_AFTER_APP_STOP

Adds configurable delay in seconds, after stopping the application.

Note:

Reserved environment variable for subsequent MTA operations, which is used in blue-green deployment and undeployment.

Tip:

Can be used to introduce a faux delay between stopping an application and unbinding its services, in order to avoid errors when unbinding from an application that is still in the process of stopping.

n/a

Sample Code:

modules:
- name: my-app
  type: application
  properties:
     MTA_WAIT_AFTER_APP_STOP: 30

Shared Module Binaries

By default every module has its own binary that is uploaded and deployed in specific manner. It is possible for multiple MTA modules to reference a single deployable binary, for example, an application archive. This means that during deployment, the same application archive is executed separately in multiple applications or application instances, but with different parameters and properties. This results in multiple running applications based on the same source code, which have different configurations and setup. A development project can have one source folder, which is referenced by multiple module entries in the MTA deployment descriptor mtad.yaml, as illustrated in the following example:

Sample Code:

Multiple MTA Module Entries in the Deployment Descriptor (mtad.yaml)


_schema-version: "3.1.0"
ID: hello
version: 0.1.0

modules:
   - name: hello-router
     type: java.tomee
     path: web/router.war
     requires:
     - name: backend
       properties:
         backend: ~{url}/content
         name: backend
         url: ~{url}
        
   - name: hello-backend
     type: java.tomee
     path: web/router.war
     provides:
       - name: backend
         properties:
           url: "${default-url}"

If deployment is based on an MTA archive, it is not necessary to duplicate the code to have two different deployable modules; the specification for the MTA-module entry in MANIFEST.MF is extended, instead. The following (incomplete) example of a MANIFEST.MF shows how to use a comma-separated list of module names to associate one set of deployment artifacts with all listed modules:

Code Syntax:

Multiple MTA Modules Listed in the MANIFEST.MF Deployment Manifest
Name: web/router.war
MTA-Module: hello-router,hello-backend
Content-Type: application/zip

Related Information

Managing Service Brokers

Parameters and Properties

Metadata for Properties and Parameters

FilesExpand file tree

modules-177d34d.md

Latest commit

History

modules-177d34d.md

File metadata and controls

Modules

Note:

Note:

Tip:

MTA Module Types

Note:

Note:

Note:

Note:

Note:

Note:

Note:

Note:

Sample Code:

Module-Specific Parameters

Tip:

Note:

Note:

Tip:

Note:

Note:

Note:

Note:

Sample Code:

Note:

Sample Code:

Note:

Note:

Sample Code:

Note:

Sample Code:

Tip:

Sample Code:

Note:

Sample Code:

Sample Code:

Sample Code:

Sample Code:

Sample Code:

Module-Specific Properties

Note:

Tip:

Sample Code:

Shared Module Binaries

Sample Code:

Code Syntax: