1. From Salesforce to Camel

You already know how to integrate systems — you did it on the Salesforce platform. Almost every concept has a counterpart here. The platform is different; the shape of the thinking is the same.

The translation table

You knew (Salesforce)	Here (Camel)
Apex classes & triggers	Java classes + Camel routes
Flows / Process Builder	Camel routes (declarative processing pipelines)
Platform Events / CDC	Azure Service Bus topics & queues
SOQL / sObjects	SQL (PostgreSQL) + Java DTOs (plain data objects)
Named Credentials	APIM subscription keys + Config Server secrets
Custom Metadata / Custom Settings	Spring Cloud Config Server
Scheduled Flow / Scheduled Apex	Camel timers & cron (@Scheduled, ShedLock)
Governor limits	No hard limits — but timeouts, DLQs & backpressure
Sandboxes	Environments: dev / qa / stage / prod
Change sets / packages	Git feature branches + Helm deploys
Debug Logs	Structured JSON logs in Datadog
Anonymous Apex / Developer Console	Local run + actuator endpoints + curl
Workbench	curl through APIM, actuator, a DB client

A Camel route in 30 seconds

A route is a pipeline: consume a message from somewhere, run it through some steps, produce it somewhere else. It's the closest thing here to a Flow. Here's a real (tiny) one:

@Component
public class TeamsNotificationRoute extends RouteBuilder {
    @Override
    public void configure() {
        from("direct:teamsNotify")                 // trigger / entry point
            .routeId("teams-notification-route")   // a name (for logs & control)
            .setHeader(Exchange.HTTP_METHOD, constant("POST"))
            .setHeader(Exchange.CONTENT_TYPE, constant("application/json"))
            .log("Sending Teams notification: ${body}")
            .to("https://dummyhost")               // do the work (call an endpoint)
            .log("Teams notification sent successfully");
    }
}

• from(...) — what kicks this off (a queue, an HTTP call, a timer, another route).
• the middle — transform, enrich, log, branch, call things.
• to(...) — where the result goes (an HTTP endpoint, a queue, a database).

Camel ships hundreds of these connectors (called components) — for Service Bus, HTTP, SFTP, files, databases — plus battle-tested patterns for splitting, routing, retrying, and dead-lettering messages. You wire them together; you don't reinvent the plumbing.

The four mindset shifts

1. Async first. A lot happens over the message bus. You publish a message and move on — you often don't get a synchronous return value. Trace the flow across services, not down a call stack.
2. At-least-once delivery. Messages can arrive twice or out of order. Design handlers to be idempotent (safe to run again).
3. No platform safety net. The framework won't roll back your transaction or stop you from NPE-ing. You handle nulls, timeouts, and retries yourself.
4. It's a fleet, not an org. A single business flow (say, shipping an order) touches several cm-* services. Understanding the flow matters more than understanding any one service.