This is in developer preview and can be subject to breaking changes.

Camunda Connector SDK

The Connector SDK allows you to develop custom Camunda 8 Connectors in Java.

You can focus on the logic of the Connector, test it locally, and reuse its runtime logic in multiple environments. The SDK achieves this by abstracting from Camunda Platform 8 internals that usually come with job workers.

Head over to our Connector Template for a head start.

Contents

• Create a Connector
• Connector Validation
• Start a Connector
• Build
• Build a release

Create a Connector

Include the connector core via maven:

<dependency>
  <groupId>io.camunda.connector</groupId>
  <artifactId>connector-core</artifactId>
  <version>0.2.2</version>
</dependency>

Define your connector logic through the OutboundConnectorFunction interface:

@OutboundConnector(
    name = "PING",
    inputVariables = {"caller"},
    type = "io.camunda.example.PingConnector:1"
)
public class PingConnector implements OutboundConnectorFunction {

  @Override
  public Object execute(OutboundConnectorContext context) throws Exception {

    var request = context.getVariablesAsType(PingRequest.class);

    context.replaceSecrets(request);

    var caller = request.getCaller();

    return new PingResponse("Pong to " + caller);
  }
}

Expose your connector as an OutboundConnectorFunction SPI implementation.

Next steps

• Add Input validation to your Connector

Connector Validation

If you want to validate your Connector input, the SDK provides a default implementation using Jakarta Bean Validation with the connector-validation module. You can include it via maven with the following dependency:

<dependency>
  <groupId>io.camunda.connector</groupId>
  <artifactId>connector-validation</artifactId>
  <version>0.2.2</version>
</dependency>

Find more details in the validation module.

Start a Connector

Spin up your connector as a job worker or build your own run-time, tailored towards your environment.

Build

mvn clean package

Build a release

Trigger the release action manually with the version x.y.z you want to release. This can be done on the main branch as well as stable/.x.y maintenance branches. You can choose the branch to execute the action on as described in the GitHub documentation.

When triggered from the main branch, a maintenance branch stable/x.y will be created based on the release version x.y.z that you specified.

Note: This currently also applies for further classifiers like x.y.z-rc1 or x.y.z-alpha1, i.e. a new branch stable/x.y will be created for that release. If the branch to create already exists, the release will fail.