Summary

Clockspring gives you two major tools for configuration: controller services and parameters. They solve different problems. This guide explains what belongs in each so your flows stay clean, portable, and easy to maintain across environments.

What controller services are for

Controller services hold shared, reusable configuration that processors depend on.
They define how Clockspring connects to something or interprets something.

Use a controller service when you need to provide:

• Database connections

• Caches (MapCache, SetCache)

• SSL / TLS configuration

• OAuth / JWT token providers

• Record Readers / Record Writers

• Credential providers for APIs

• Anything required by many processors

If multiple processors will reference it, it belongs in a controller service.

What parameters are for

Parameters supply environment-specific values that change between Dev, Test, Prod, or customer deployments.

Use parameters for things like:

• Hostnames

• Ports

• API URLs

• Usernames

• Passwords

• Access tokens (non-OAuth flows)

• File paths

• Single-use configuration values

Parameters decouple flows from the environment.
Instead of editing a controller service per environment, you supply a different parameter context.

How they work together

Most clean Clockspring deployments follow this rule:

 Controller service defines the structure.
 Parameters supply the details.

Example:
A DBCPConnectionPool controller service defines the connection mechanism, pooling, and driver settings.

Parameters provide the hostname, port, username, and password.

This lets you promote flows without editing the service itself.

When something belongs in a controller service

Choose a controller service if the value:

• Is needed by more than one processor

• Should be centrally managed

• Represents a connection, credential provider, or reader/writer

• Is required by the processor’s property type (i.e., must reference a controller service API)

If the processor expects a controller service, there is no choice.

When something belongs in a parameter

Choose a parameter if the value:

• Changes between environments

• Might change frequently

• Contains sensitive information

• Does not need to be shared across processors

• Is a simple string used by one or more controller services

• Is needed at processor-level configuration instead of via a controller service

Parameters cleanly separate logic from environment settings.

Examples

Database connection

Controller Service: DBCPConnectionPool
Parameters: hostname, port, database name, username, password

API call via InvokeHTTP

Controller Service: SSLContextService, OAuth token provider
Parameters: base URL, API key, basic-auth username/password, tenant IDs

Record parsing

Controller Service: JsonTreeReader, CSVReader
Parameters: optional path settings or schema names

Deduplication

Controller Service: MapCache or SetCache
Parameters: none required; keys stay processor/attribute-level

Common mistakes

• Hardcoding environment-specific URLs in a controller service

• Embedding passwords directly in processor properties

• Duplicating controller services instead of passing parameters

• Editing controller services in each environment instead of providing different parameter contexts

Fix these, and your flows become far easier to maintain.

Related Articles

• Controller Services Overview

• Controller Service Inheritance and Scope

• Best Practices for Managing Controller Services