Outbound connectors vs. job workers
Integrating with external systems can be done with a connector or a job worker.
You define the domain-specific UI for modeling a connector through a connector template. A connector template is a type of element template. Therefore, you can also build a connector-like system using element templates and job workers.
If they both share the same core functionality, how do they differ, and when should you choose what connectors and job workers serve different purposes when it comes to aspects like delivery, reusability, focus, and context.
Delivery
A connector is reusable code, written as an OutboundConnectorFunction using the Connector SDK.
It is not a standalone application, you cannot start it and have it work on Camunda 8 jobs.
Instead, a connector is delivered as a library and can be used in combination with other connectors in a Connector runtime environment.
In contrast, a job worker is usually part of a Zeebe client application that can be directly executed to work on jobs.
Reusability
A job worker usually runs as or inside a standalone Zeebe client. Without effort, you cannot simply run this in Camunda 8 SaaS or any other environment. As a Self-Managed user, you can run it standalone, but often not directly reuse the logic in your existing Zeebe client that you might already have. You can manually extract the job handler from the given job worker, but you also have to ensure that it is still working as expected afterward.
In contrast, a connector itself is environment-agnostic. There is a runtime environment for Camunda 8 SaaS that can wrap and call this connector. As the connector developer, you don't have to worry about this as the runtime takes care of it if you developed the connector using the Connector SDK.
You can also run the exact same connector (without any modification) in Camunda 8 Self-Managed; either as a standalone job worker, as additional job handler in your existing Zeebe client application, or together with other connectors in one Zeebe client application. This all comes with the Connector SDK, and there is no additional code necessary to get started. However, if you need a custom environment, the Connector SDK provides a guide and default helpers to do that.
Focus
A job worker is often a complete Zeebe client application, dealing with environment tasks like handling variables in and out. The core logic of calling a defined URL is only part of the application. Plus, it handles Camunda 8-specific APIs like the job worker API to handle variables, complete executions, and throw errors.
A connector only consists of core business functionality. No environment tasks, no Camunda 8 job worker-related code. You can run this from Camunda 7 as well if you have a runtime that takes care of this. The connector only needs input variables and access to secrets so they can be used in defined input attributes.
Context
Every job worker implementation defines on its own how to handle input data, validating and transforming it. Plus, there is no unified modeling experience for job workers. There can be an element template for the worker, but that template might look completely different for every job worker.
Secrets are the exception. The Orchestration Cluster resolves camunda.secrets.<name> references in a job's variables and injects the values when it activates the job. The job worker receives the sensitive values at runtime without storing them in its own configuration, regardless of its implementation language or deployment location. See secret resolution and job activation.
In contrast, connectors provide these capabilities out of the box, along with built-in secret management that lets you provide secrets in different ways. Element templates, called Connector templates, are a vital part of a connector. There are standardized best practices for developing those. Having used one connector template will make it easy for you to use the next one just the same.
Which one should you choose?
It depends on your use case.
- Need access to a low-level API in Camunda 8 to perform a very specific task? You are better off with job workers.
- Want to write your worker logic in something other than Java? Job workers are your way to move forward.
- Want to create worker logic that is reusable in any environment? Write a connector.
- Want to focus on your worker's logic and have no need for using low-level Orchestration Cluster REST API? Write a connector.
- Want to provide a standardized modeling experience alongside your runtime behavior? Write a connector.