Skip to content

Latest commit

 

History

History

cross-mta-configurations

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 

Cross MTA configurations

Cross MTA configurations is a feature, allowing for consumption of external string values in the mta(d).yaml during deployment time. The values are usually provided by other MTAs during their deployments and most often contain alocated routes mapped to apps in those MTAs. Thus a 'service discovery' is achieved at deployment time.

Since the SAP Cloud Deployment service persists those configurations until the providing MTA is undeployed, they can be used to also hold arbitrary configuration data like org/space specific settings which don’t fit an extension descriptor.

Official documentation

Try it out

Deploy provider MTA

To deploy the MTA providing the configurations, run the following command from the current directory:

$ cf deploy provider/ -f ;
Note
See provider/mtad.yaml for details on the provided configuration values/names/scopes.

Deploy consumer MTA

To consume the config values, run the following command from the current directory:

$ cd consumer ;
$ cf deploy -f ;
Note
See how configurations are applied in mtad.yaml in the current directory.

Examine the result

Check how the configuration value was consumed:

$ cf services:
name                        service            plan       bound apps   last operation     broker            upgrade available
myDevService                application-logs   lite       staticapp    create succeeded   sleeve-broker
Note
The service name came as configuration.
$ cf env staticapp
...
System-Provided:
{ "VCAP_SERVICES": {"application-logs": [{
    "name": **"myDevService"**,
    "tags": [
      **"myDevService.customized_tag"**
    ]   }  ] }}
...
UserProvided:
property-directly-referencing-the-config: myDevService.directly
property-referencing-config-in-requires: myDevService.inRequiresProperty
via-module-parameter-value: myDevService.inModuleParameter
via-param-in-requires: myDevService.inRequiresParam.inRequiresProperty
...
Note
those env variable values can as configuraiton

Consume a different configuration value by using an ext.descriptor

$ cd consumer;
$ cf deploy -f -e ci.mtaext ;
Note
See how the provided configuration was selected with provider/ci.mtaext.

Result:

name                        service            plan       bound apps   last operation     broker            upgrade available
myCIService                 application-logs   lite       staticapp    create succeeded   sleeve-broker
...
    "tags": [
     "myCIService.customized_tag"
    ],
...
property-directly-referencing-the-config: myCIService.directly
property-referencing-config-in-requires: myCIService.inRequiresProperty
via-module-parameter-value: myCIService.inModuleParameter
via-param-in-requires: myCIService.inRequiresParam.inRequiresProperty
Note
Provided configurations can also target a specific org & space. This could avoid the need of using an extension descriptor if the configurations are space specific and apply to all MTAs consuming them in that space.

Clean up resources

It is recommended to stop or undeploy your MTAs when they are no longer needed. In order to do so, run the following command:

$ cf undeploy <mta-id> -f --delete-services