externalize-services-configurations

Externalize service parameters to file

Table of Contents

• Modelling
  • Service instances
• Related examples
  • Requirements
  • Oficial documemtation in Help SAP Portal
• Try 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

This example shows how to maintain service instance configuration in dedicated json files, apart 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

Modelling

Service instances

Service instances are modelled 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 the config parametr’s are merged. In case of conflict during merging, the config parameter content is overwriting the other.

Related examples

• Service instance and binding creation with MTAs

Requirements

• access to a CF space with quota for creation of service instances

Oficial documemtation in Help SAP Portal

• Resources

• Service creation parameters

Try out

Deploy the MTA

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

Deploy with a deployment descriptor (mtad.yaml)

That approach uses deployment descritpr mtad.yaml and ready application binaries appBits.zip:

cf deploy ./ -f ;

Alternatively first assemble an MTA archive using the mtad.yaml and then deploy the archive:

mbt assemble -t ./ ;
cf deploy my-mta_0.0.0.mtar ;

Note	See mtad.yaml for the modelling

Build and Deploy

The approach is using development descriptor mta.yaml and application binaries appBits.zip to build MTAR. Then the MTAR is deployed.

mbt build -p cf -t . ;
cf deploy a.cf.app_0.0.0.mtar -f ;

Note	See mta.yaml for the concrete modelling

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.