Configuration
You can configure the Connector runtime environment in the following ways:
- The Zeebe instance to connect to.
- The Connector functions to run.
- The secrets that should be available to the Connectors.
Connecting to Zeebe
In general, the Connector Runtime will respect all properties known to Spring Zeebe.
SaaS
To use Camunda 8 SaaS specify the connection properties:
ZEEBE_CLIENT_CLOUD_CLUSTER-ID=xxx
ZEEBE_CLIENT_CLOUD_CLIENT-ID=xxx
ZEEBE_CLIENT_CLOUD_CLIENT-SECRET=xxx
ZEEBE_CLIENT_CLOUD_REGION=bru-2
You can further configure separate connection properties for Camunda Operate (otherwise it will use the properties configured for Zeebe above):
CAMUNDA_OPERATE_CLIENT_CLIENT-ID=xxx
CAMUNDA_OPERATE_CLIENT_CLIENT-SECRET=xxx
If you are connecting a local Connector runtime to a SaaS cluster, you may want to review our guide to using Connectors in hybrid mode.
Local installation
Zeebe:
ZEEBE_CLIENT_BROKER_GATEWAY-ADDRESS=127.0.0.1:26500
ZEEBE_CLIENT_SECURITY_PLAINTEXT=true
If the Zeebe Gateway is set up with Camunda Identity-based authorization, Zeebe client OAuth environment variables must be provided.
Connect to Operate locally using username and password:
CAMUNDA_OPERATE_CLIENT_URL=http://localhost:8081
CAMUNDA_OPERATE_CLIENT_USERNAME=demo
CAMUNDA_OPERATE_CLIENT_PASSWORD=demo
When running against a self-managed environment you might also need to configure the Keycloak endpoint to not use Operate username/password authentication:
CAMUNDA_OPERATE_CLIENT_KEYCLOAK-URL=http://localhost:18080
CAMUNDA_OPERATE_CLIENT_KEYCLOAK-REALM=camunda-platform
Disable Operate connectivity
Disabling Operate polling will lead to inability to use inbound (e.g., webhook) capabilities. However, if you still wish to do so, you need to start your Connector runtime with the following environment variables:
CAMUNDA_CONNECTOR_POLLING_ENABLED=false
CAMUNDA_CONNECTOR_WEBHOOK_ENABLED=false
OPERATE_CLIENT_ENABLED=false
Manual discovery of Connectors
By default, the Connector runtime picks up outbound Connectors available on the classpath automatically. To disable this behavior, use the following environment variables to configure Connectors and their configuration explicitly:
Environment variable | Purpose |
---|---|
CONNECTOR_{NAME}_FUNCTION (required) | Function to be registered as job worker with the given NAME |
CONNECTOR_{NAME}_TYPE (optional) | Job type to register for worker with NAME |
CONNECTOR_{NAME}_INPUT_VARIABLES (optional) | Variables to fetch for worker with NAME |
Through that configuration, you define all job workers to run.
Specifying optional values allow you to override @OutboundConnector
-provided Connector configuration.
CONNECTOR_HTTPJSON_FUNCTION=io.camunda.connector.http.HttpJsonFunction
CONNECTOR_HTTPJSON_TYPE=non-default-httpjson-task-type
Secrets
Providing secrets to the runtime environment can be achieved in different ways, depending on your setup.
Secrets in Docker images
To inject secrets into the Docker images of the runtime, they must be available in the environment of the Docker container.
For example, you can inject secrets when running a container:
docker run --rm --name=connectors -d \
-v $PWD/connector.jar:/opt/app/ \ # Add a connector jar to the classpath
-e MY_SECRET=secret \ # Set a secret with value
-e SECRET_FROM_SHELL \ # Set a secret from the environment
--env-file secrets.txt \ # Set secrets from a file
camunda/connectors-bundle:latest
The secret MY_SECRET
value is specified directly in the docker run
call,
whereas the SECRET_FROM_SHELL
is injected based on the value in the
current shell environment when docker run
is executed. The --env-file
option allows using a single file with the format NAME=VALUE
per line
to inject multiple secrets at once.
Secrets in manual installations
In the manual setup, inject secrets during Connector execution by providing them as environment variables before starting the runtime environment. You can, for example, export them beforehand as follows:
export MY_SECRET='foo'
Reference the secret in the Connector's input in the prefixed style {{secrets.MY_SECRET}}
.
Custom secret provider
Create your own implementation of the io.camunda.connector.api.secret.SecretProvider
interface that
comes with the SDK.
Package this class and all its dependencies as a JAR, e.g. my-secret-provider-with-dependencies.jar
. This needs to include a file
META-INF/services/io.camunda.connector.api.secret.SecretProvider
that contains the fully qualified class name of your secret
provider implementation. Add this JAR to the runtime environment, depending on your deployment setup.
Your secret provider will serve secrets as implemented.
For Docker images, you can add the JAR by using volumes, for example:
docker run --rm --name=connectors -d \
-v $PWD/my-secret-provider-with-dependencies.jar:/opt/app/my-secret-provider-with-dependencies.jar \ # Specify secret provider
-e ZEEBE_CLIENT_BROKER_GATEWAY-ADDRESS=ip.address.of.zeebe:26500 \ # Specify Zeebe address
-e ZEEBE_CLIENT_SECURITY_PLAINTEXT=true \ # Optional: provide security configs to connect to Zeebe
camunda/connectors:latest
In manual installations, add the JAR to the -cp
argument of the Java call:
java -cp 'connector-runtime-application-VERSION-with-dependencies.jar:...:my-secret-provider-with-dependencies.jar' \
io.camunda.connector.runtime.ConnectorRuntimeApplication