externalize-services-configurations

Externalize service parameters to file

Table of Contents

• Modeling
  • Service instances
• Related examples
  • Requirements
  • Official documentation in SAP Help Portal
• Try it out
  • Deploy the MTA
    • Deploy with a deployment descriptor (mtad.yaml)
    • Build and Deploy
  • Examine the result
    • List the created services
    • List the user-provided service instance credentials
  • Clean up resources

This example shows how to maintain service instance configuration in dedicated JSON files, apart from the development/deployment YAML. The content of those files gets merged with the additional configurations defined in the mta(d).yaml and gets used as service instance creation/update parameters.

Modeling

Service instances

Service instances are modeled as MTA resources of type org.cloudfoundry.managed-service. The parameters used for their creation and update can be specified in two places:

• In the config parameter of the resource

• In an external .json file, referenced in the path parameter of the resource

resources:
- name: my-service-instance
  type: org.cloudfoundry.managed-service
  parameters:
    path: config.json      #The content of the JSON will be taken as a base
    config:                #Those configurations will be merged in the config.json content
      xsappname: "appname-with-suffix-${org}${space}"
  #...

Note	The content from the external file and config parameter are merged. In case of conflict during merging, the config parameter content will overwrite the other.

Related examples

• Service instance and binding creation with MTAs

Requirements

• Access to a Cloud Foundry space with quota for creation of service instances

Official documentation in SAP Help Portal

• Resources

• Service creation parameters

Try it out

Deploy the MTA

The example demonstrates 2 different approaches that lead to the same result. NOTE: Please adjust the service label, plan and parameter values to match the ones available in your environment

Deploy with a deployment descriptor (mtad.yaml)

This approach uses deployment descriptor mtad.yaml and ready application binaries appBits.zip:

$ cf deploy ./ -f ;

Alternatively, you can assemble an MTA archive, using the mtad.yaml file first:

$ mbt assemble -t ./ ;

And then deploy the assembled archive:

$ cf deploy my-mta_0.0.0.mtar ;

Note	See mtad.yaml for the modeling.

Build and Deploy

This approach uses development descriptor mta.yaml and application binaries appBits.zip to build an MTAR archive:

$ mbt build -p cf -t . ;

The MTAR archive is then deployed:

$ cf deploy a.cf.app_0.0.0.mtar -f ;

Note	See mta.yaml for the concrete modeling.

Examine the result

List the created services

$ cf services
Getting services in org deploy-service / space ****** as ******...
name                                        service            plan
my-service-instance                         xsuaa              application
my-user-provided-service-instance           user-provided

List the user-provided service instance credentials

$ cf curl /v2/user_provided_service_instances/$(cf service my-user-provided-service-instance --guid)
{
   ...,
   "entity": {
      "name": "my-user-provided-service-instance",
      "credentials": {
         "tenant-mode": "dedicated",
         "xsappname": "appname-with-suffix-deploy-service********"
      },
      ...

Notice that the user-provided service has the properly merged content in the credentials field.

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