Camunda 8: The Complete Guide to Modern Workflow Orchestration

Camunda 8 and BPMN: The Complete Guide to Workflow Orchestration

Modern systems are built from many parts: REST APIs, microservices, SaaS integrations, and human workflows. The challenge is not building each service, but orchestrating them together in a way that is reliable, visible, and adaptable. This is where BPMN (Business Process Model and Notation) and Camunda 8 come into play. In this article we will cover what BPMN is, how it relates to the Camunda engine, the role of the Camunda Modeler, how REST connectors differ from microservice workers, how Camunda’s internal job queue works, and how everything comes together in real-world examples.

What is BPMN?

BPMN (Business Process Model and Notation) is a standard way of drawing business processes. Unlike flowcharts or static diagrams, BPMN models can be executed when deployed to a workflow engine like Camunda. This means the diagram is both documentation and code.

Core BPMN elements include:

Start Event – where the process begins.
Tasks – units of work (Service Task for automation, User Task for manual steps).
Gateways – decisions (if/else) or parallel branches.
End Event – process completion.

Example: Loan Approval Flow

Start → Validate Application (Service Task)
Check Credit Score (Service Task)
Gateway: If score > 700 → Approve Loan (User Task), else → Reject Loan
End

This diagram is business-friendly but also technical enough to be executed by Camunda directly.

BPMN and the Camunda Engine

BPMN defines the blueprint of a process. The Camunda engine (Zeebe) is the factory that executes that blueprint. Here’s how it works:

BPMN defines the flow: Start → Tasks → End.
Engine interprets BPMN: Each Service Task becomes a taskType that must be executed.
Engine enqueues jobs: When a process instance reaches a Service Task, the engine creates a Job in its internal distributed queue.
Workers or connectors pick up jobs: These can be built-in REST connectors or custom microservices.
Engine continues execution: Once a job is completed, results are merged back into process variables, and the workflow moves on.

Analogy: BPMN is the script for a play, the Camunda engine is the director, and workers or services are the actors. The director (engine) ensures everyone enters at the right time and the play runs to completion.

The Camunda Modeler

The Camunda Modeler is a drag-and-drop desktop application for creating BPMN diagrams. While it feels visual and business-friendly, the Modeler produces an executable BPMN XML file. This file is deployed to the Camunda engine where it becomes a live, running process definition.

Example: If you model a Service Task called fetch-coverage, when the engine hits that task at runtime, it will enqueue a job of type fetch-coverage. This job must then be executed by either a REST connector or a microservice worker.

Two Integration Approaches

1. REST Outbound Connector

REST connectors let you call HTTP APIs without writing code. You configure the endpoint, headers, and request body inside the Modeler. The engine’s connector runtime makes the HTTP call and maps the response into process variables.

Example: A Service Task configured to GET https://catfact.ninja/fact maps body.fact into a variable catFact.

2. Custom Microservice Worker

For complex cases, you build a microservice that connects to Camunda via the Zeebe client. It subscribes to jobs of a given type, executes business logic, and completes the job with results.

Java Example Worker:

@Component
public class CoverageWorker {
  @JobWorker(type = "fetch-coverage")
  public Map<String,Object> handle(ActivatedJob job) {
    String memberId = (String) job.getVariablesAsMap().get("memberId");
    // Custom logic here
    return Map.of("coverageFound", true, "planId", "PPO-100");
  }
}

REST Connector vs Service Worker: What’s the Difference?

While both execute tasks inside a BPMN workflow, they differ in architecture:

REST Connector – Runs inside Camunda’s connector runtime. Good for quick HTTP integrations, no code required. Limited to REST protocols.
Service Worker – Runs as an external service (your JVM, Node.js, Go). It pulls jobs from Camunda’s queue, executes complex logic, and pushes results back. Good for heavy, custom, or non-HTTP work.

In other words: Connectors are about configuration, Workers are about customization.

How Camunda’s Internal Queue Works

Under the hood, the Camunda engine (Zeebe) has a distributed log-based job queue. This is how it coordinates between BPMN and services:

When a Service Task is reached, the engine creates a job with a type and payload (variables).
Jobs are stored in the engine’s queue, replicated across brokers for fault tolerance.
Workers subscribe to job types. They pull jobs from the queue when available.
Workers complete jobs by sending results back. The engine merges these into process variables and moves the token forward.
If a worker fails, the engine retries the job, applies backoff, or triggers BPMN error events.

This queue-based architecture decouples orchestration (Camunda) from execution (services). Services don’t need to know each other — they only need to know their task type and talk to Camunda.

Architecture in Action

Let’s put it all together:

BPMN defines the sequence (Start → Tasks → End).
Engine enqueues jobs when tasks are reached.
Connectors or Workers pick up jobs and perform work.
Engine resumes the flow, applies gateways, waits at timers, or escalates errors.
Operate provides monitoring, Tasklist supports human approvals.

This separation gives clarity (process flow), reliability (retries and error handling), and scalability (workers can scale independently in Kubernetes/EKS).

Deployment Example (Kubernetes/EKS)

In Kubernetes, Camunda runs as its own cluster (brokers + gateway + Operate). Your workers run as separate Deployments:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: coverage-worker
spec:
  replicas: 3
  selector:
    matchLabels:
      app: coverage-worker
  template:
    metadata:
      labels:
        app: coverage-worker
    spec:
      containers:
        - name: worker
          image: ghcr.io/yourorg/coverage-worker:1.0.0
          env:
            - name: ZEEBE_GATEWAY
              value: zeebe-gateway.camunda.svc.cluster.local:26500

This ensures high availability. The engine will distribute jobs across all worker replicas automatically.

End-to-End Example: Insurance Claim

Start
Fetch Coverage (Custom Worker using DB + API)
Submit Claim (REST Connector → external insurance API)
Gateway: If approved → Notify Customer (Worker), else → Escalate to Human Task
End

This example shows how BPMN orchestrates both workers and connectors, with the engine ensuring the right order, retries, and visibility in Operate.

Conclusion

Camunda 8 and BPMN together solve the challenge of orchestrating distributed systems. BPMN gives you a visual, standard way to describe processes. The engine executes those processes, enqueuing jobs, dispatching them to connectors or services, and managing retries and state. REST connectors give you a fast path for API calls, while service workers give you full control for complex business logic. Behind the scenes, the engine’s internal queue ensures decoupling and scalability. Deployed in Kubernetes, Camunda becomes the conductor of your microservices orchestra, making workflows reliable, visible, and auditable.