Here you will learn about the Spring Cloud® Data Flow deployment model and about administering Data Flow service instances and deployed applications, and gain information about the Cloud Foundry Service Broker API.

Tanzu Operations Manager administrators can use Role-Based Access Control (RBAC) to manage which operators can make deployment changes, view credentials, and manage user roles in Tanzu Operations Manager. Therefore, your role permissions might not allow you to perform every procedure in this operator guide. For more information about roles in Tanzu Operations Manager, see Understand Role-Based Access Control (RBAC) in Tanzu Operations Manager.

Service Broker

Spring Cloud Data Flow provides a Spring Cloud Data Flow server as a Managed Service on VMware Tanzu Application Service for VMs (TAS for VMs). It uses the Cloud Foundry Service Broker API to manage this service. See below for information about Spring Cloud Data Flow’s broker implementation.

The Spring Cloud Data Flow service broker’s functionality is contained in the following Spring Boot application instance, which is deployed in the system org to the p-dataflow space.

• p-dataflow-[version]: Implements the Service Broker API to act on provision, deprovision, bind, and unbind requests.

The broker relies on the VMware Tanzu SQL [MySQL] product for the following service instance.

• p-dataflow-db: A MySQL database used as a backing store for the service broker.

You can configure an alternate relational database service for the broker to use. See the Configure Broker Database Service and Plan section of the Tile Configuration topic.

Service Broker upgrades

The Spring Cloud Data Flow product upgrade process checks before redeploying the service broker to see whether the product’s version has changed. If the version has not changed, the upgrade process will continue without redeploying the service broker.

The service broker application is deployed using a blue-green deployment strategy. During an upgrade of the service broker, the broker will continue processing requests to provision, deprovision, bind, and unbind service instances, without downtime.

Access using Apps Manager

To view the broker application in Apps Manager, log into Apps Manager as an admin user and select the system org. The application is deployed in the p-dataflow space.

Get Broker build information

The Spring Cloud Data Flow broker provides build information using the Spring Boot Actuator info endpoint, which is mapped to /info. You can access this endpoint by appending /info to the path of the Spring Cloud Data Flow broker.

If the Spring Cloud Data Flow service broker application is located at the following URL:

https://p-dataflow.apps.example.com

then you can access the info endpoint by visiting:

https://p-dataflow.apps.example.com/info

The service broker returns a JSON response, as in the following example.

{
	"git": {
		"commit": {
			"time": 1526673193000,
			"id": "740fb80"
		},
		"branch": "740fb80a6e1d83de033a4b81bf29c8b4cfa83b74"
	},
	"build": {
		"version": "1.1.0-build.19",
		"artifact": "scdf-for-pcf-service-broker",
		"name": "scdf-for-pcf-service-broker",
		"group": "io.pivotal.springcloud.dataflow",
		"time": 1526673593000
	}
}

The response contains information about the build of the service broker application, including the Maven project coordinates and build time. It also contains information about the Git repository for Spring Cloud Data Flow for VMware Tanzu at build time.

Fields such as those for Git repository information are for diagnostic purposes and intended to provide Broadcom Support with information to help in troubleshooting.

Service instances

See the following sections for information about service instances deployed by the Spring Cloud Data Flow for VMware Tanzu service broker.

Service instance architecture

For each Spring Cloud Data Flow service instance created, the service broker provisions the following resources, all within the space from which the service instance was created (“the user space”) unless noted otherwise.

• A new space within the p-dataflow org, named using the service instance GUID and containing:
  • A Data Flow server application.
  • A Spring Cloud Skipper package management application.
  • A relational database service, bound to the Data Flow server application. This relational database service is a “p.mysql” service instance by default. You can configure an alternate relational database when you create the service instance.
  • A relational database service, bound to the Skipper package management application.
  • A messaging data service. This messaging data service is a “p-rabbitmq” service instance by default. You can configure an alternate messaging service when you create the service instance.
• The following resources are created in the originating user space where the service instance command was targeted at:
  • A “p-dataflow” service instance.
  • A “p-dataflow” relational database service instance (providing access to the relational database service created in the service instance’s space within the p-dataflow org).
  • A “p-dataflow” messaging service instance (providing access to the messaging data service created in the service instance’s space within the p-dataflow org).

Set a domain for service instance backing apps

When deploying a backing app for a Data Flow service instance, the Spring Cloud Data Flow service broker uses the following strategy to select a domain for the app:

1. The broker looks for a private domain shared with the p-dataflow org. If it finds one or more, the broker uses the first for the app.
2. If the broker finds no private domain shared with the p-dataflow org, it looks for a shared domain. If it finds one or more, the broker uses the first for the app.

To cause the service broker to use a particular domain for service instance backing apps, configure the domain as a private domain and share it with the p-dataflow org. This will not affect the choice of domain for apps deployed by a Data Flow service instance.

Capacity requirements

Below are the usage requirements of the Spring Cloud Data Flow service broker.

The service broker is bound to a relational database service instance, which stores data relating to the broker’s service instances. The relational database service to use is configurable, as described in The Service Broker section above.

Below are the usage requirements of the Data Flow server and Skipper applications that back each Spring Cloud Data Flow service instance.

Spring Cloud Data Flow service instances are also backed by instances of other TAS for VMs services. These are either services from VMware Tanzu data service products or custom services provided to a Data Flow service instance at create time. These data services include a relational database service and a messaging service for each Data Flow service instance created. The Skipper backing application uses a MySQL database service for its backing store.