How Flowable and Apache Camel integration works
When a BPMN or CMMN process must exchange messages with legacy systems, the Flowable answer is the Camel task. In Flowable, the Camel task is a service task with flowable:type set to camel. It sends messages to Camel and receives messages from Camel, so the process model hands work to a Camel route and waits for the result without the process author writing connector code. The Flowable docs describe this in the BPMN constructs section, and that page is the right starting point for the exact task syntax in your Flowable version.
By default, the Camel task looks up a camelContext bean in the Spring container, the context that holds your Camel routes. That default shapes the architecture: the routes live in the same Spring application as the engine, and the team owning the process model must agree with the team owning the routes on the context bean name, the route endpoints and the message shape. Confirm whether your Flowable release and Spring setup need any override of that lookup before you rely on the default. Apache Camel is licensed under Apache-2.0 and maintained by the Apache Software Foundation, and its repository lists 350+ connectors, including Kafka, REST, JDBC, AWS, Azure, GCP and Salesforce. Those connectors are how a route reaches a legacy system that Flowable itself cannot call directly.
Before building, list each legacy endpoint the process must reach, check which Camel component already covers it, and confirm the license and support position of every component you plan to use. Decide who owns route changes after go-live, since a route update can change process behavior without a process redeployment. Test the round trip, including timeouts and failed responses, against the real legacy system or a faithful stand-in.
What you need before connecting Flowable to Camel
Connecting Flowable to Apache Camel couples two release trains, so the pairing is a decision you make before any route is written. The cards below cover the platform baseline, the Camel release line, the runtime, network reach to legacy endpoints and the support boundary, each of which changes what you build and who you call when something fails.
Flowable and Java baseline
Pick the Flowable version first, because its release notes set the Java, Spring and Jakarta baseline. Flowable 7.0.0 moved to Java 17, Spring Boot 3 and Jakarta EE, and Flowable 8.0.0 requires Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. Confirm the Flowable version and Camel version pairing against both sets of release notes before you pin dependencies, since a Camel line that is fine on one Spring Boot generation may not be on the other.
Camel release line and LTS dates
Choose between an LTS line and the latest standard release. Camel 4.22.1 is LTS with end of life in August 2027, and Camel 4.18.5 is LTS with end of life in February 2027. LTS releases receive bug and security fixes for up to one year. The non-LTS 4.23.0 release is the latest standard release and supports Java 17, 21 and 25. Ask your team which end-of-life date your upgrade calendar can meet.
Camel runtime choice
Decide where the Camel context runs before you design the camelContext bean. Camel runs on Spring Boot with connector starters, on Quarkus, from the Camel CLI, on Kubernetes through Camel K, or standalone. Because the Flowable Camel task looks up a camelContext bean in the Spring container by default, a Spring Boot runtime keeps the process engine and routes in one application. Other runtimes mean the process engine must reach the routes over a message channel, which changes your failure and deployment model.
Network reach to each legacy endpoint
Inventory every system a route will call before the build starts. Legacy endpoints such as mainframe gateways, older JDBC databases or SFTP hosts need firewall rules, service accounts and DNS entries from the team that owns them, often with lead times longer than the build. Record the protocol, port, certificate chain and rate limit for each endpoint. Confirm that the runtime host can reach each one from the same network zone where the Flowable engine runs.
Java and Camel component dependencies
List the Camel components each route needs and check that they ship in the release line you chose. Connectors cover many protocols, including Kafka, REST, JDBC, AWS, Azure, GCP and Salesforce, but a legacy protocol may need a community component or an internal one. Plan who maintains each component version, who reviews transitive dependencies for vulnerabilities, and how you will patch them between Camel releases.
Red Hat support boundary
If you buy commercial support for the Red Hat build of Apache Camel, check which runtimes it covers before you commit. Red Hat supports Spring Boot and Quarkus runtimes and no longer supports OSGi (Karaf) or JBoss EAP. A deployment on either unsupported runtime may run, but it falls outside that subscription. Ask your support provider to confirm coverage in writing for your exact runtime and Camel version.
Configuring the Camel task step by step
This sequence takes a Spring-based Flowable project from a plain BPMN process to a service task that hands a message to an Apache Camel route and reads the reply back into process variables. Each step ends with a check you can run before moving on.
Confirm the Spring Boot and Camel baseline
Before adding anything, the developer team confirms that the Flowable project already runs on Spring Boot and that the Camel version it will use supports the Java version in production. Camel's download page lists Apache Camel 4.22.1 as an LTS release supporting Java 17, 21 and 25, and Camel 4.18.5 as an LTS release with end of life in February 2027, so the team should pick a line whose end-of-life date fits its support plan. Flowable 8.0.0 moved to Spring Boot 4 and Spring Framework 7 and no longer supports Spring Boot 3, so the Camel and Spring Boot versions must line up with the Flowable release in use. Done when the team has written down the Flowable, Spring Boot, Camel and Java versions and the build runs an empty Spring Boot application with the Flowable starter.
Add the Camel dependency and Spring Boot starter
The developer adds the Camel Spring Boot starter for the connectors the integration needs, such as Kafka, REST or JDBC, alongside the Flowable Spring Boot starter in the build file. Connector starters pull in their own client libraries, so the team should add only the components the routes use and record them in the dependency review. Version management should come from a single bill of materials so Camel and its components stay aligned. Done when the project resolves its dependencies without conflicts and the application context starts with Camel auto-configuration logged at startup.
Define the camelContext bean and its routes
The developer creates a Spring configuration that declares a bean named camelContext, the bean the Flowable Camel task looks up by default in the Spring container. Routes are defined in Java, YAML or XML, and a simple first route can start from a direct endpoint so the process can call it without an external broker. The route should log the incoming body and return a value the process can use, such as a status code or a reference ID. Done when the application starts, the route appears as started in the Camel startup log or actuator output, and a test can send a message to the direct endpoint and get the expected reply.
Add the Camel service task in the BPMN model
The process designer adds a service task to the BPMN model and sets flowable:type to camel in the task definition, using the Flowable BPMN constructs documentation for the Camel task syntax. The task is configured to name the Camel endpoint it sends to, and the designer agrees the input and output variable names with the developers so the task reads and writes the names used in the routes. Done when the BPMN file validates in the modeler or the deployment step, and the deployed process definition shows the service task with the Camel type.
Map sending and receiving through process variables
The developers and the process designer decide which process variables are sent into the route and which variables the route's reply writes back. Keep the message body in one variable and the correlation or status values in others, and name them in the model and the route the same way. Avoid passing large payloads through process variables, since they are stored with the instance, and send references to stored data where the payload is large. Done when a test process instance started with known variables reaches the Camel task, and after completion the expected reply variable holds the value the route returned.
Test one route end to end
The developer writes an integration test that starts the Spring context, deploys a small test process containing one Camel task, starts an instance with known input, and checks the output variable after the task completes. The test should also confirm that the route received the message, for example by asserting on a mock endpoint or a log entry. Where the route calls a legacy system, the test uses a stub or test instance of that system, and the team confirms with the owner of that system which test environment is safe to use. Done when the test passes in the build pipeline and the process instance shows the Camel task as completed in the history.
Confirm the route in a deployed environment
Before release, the operations team confirms that the same Camel routes start in the target environment, that the Camel endpoints they call are reachable from the Flowable nodes, and that the connector credentials come from the secret store rather than the build. The team checks the actuator output for the Flowable and Camel components, and runs one controlled process instance through the Camel task. Done when the deployed environment shows the test instance completing the task, the route log shows the expected message, and the team has recorded the Camel and Flowable versions for the release.
Mapping process variables to Camel messages and legacy fields
This table compares each mapping layer between a Flowable process variable, the Camel message it becomes, and the legacy field it must match. Read each row as a contract to confirm with the legacy system's owner before build, since field names, types and formats rarely match the process model by default. The main takeaway is that most integration defects come from date, number and optional-field assumptions rather than from the Camel route itself.
| Mapping layer | What to define | Typical risk if left unconfirmed |
|---|---|---|
| Process variable to message body | Which variables form the body, and whether it is a single object, a map or a flat payload | Body shape differs from the legacy schema, so the receiving system rejects otherwise valid requests |
| Process variable to message header | Routing, correlation and operation headers that Camel components read, such as operation or target identifiers | Headers are missing or misnamed, so the route sends to the wrong endpoint or drops the call |
| Data types and numeric precision | Strings, integers, decimals and booleans as the legacy system expects them, including currency scale | Decimal amounts are silently rounded or sent as text, causing mismatched balances or totals |
| Date and time formats | Time zone, pattern and precision for each date variable, for example ISO 8601 or a local business date | Dates shift by a day across time zones or fail to parse on the legacy side |
| Required and optional fields | Which legacy fields must be present, which may be omitted, and default values for omitted fields | Optional fields sent as null break validation that the legacy system applies to required fields |
| Response fields to process variables | Which response fields are written back, their target variable names, and the type conversion applied | Response values overwrite variables used by later gateways, changing process paths unexpectedly |
| Error and empty response handling | What a fault, empty body or partial response maps to, and whether the process retries or routes to a user task | Failures are stored as successful results, leaving downstream steps running on stale data |
| Interface contract | The target system's current field specification, version and sample messages, confirmed in writing with its owner | Mapping built from assumptions diverges from the live interface after the legacy system changes |
Camel task or event registry: choosing the integration path
A Camel task fits when a process step needs to send a message to Camel and wait for a reply, and when the work involves routing, transformation or protocol mediation that Camel already handles well. Flowable's docs define the Camel task as a service task with flowable:type set to camel, and by default it looks up a camelContext bean in the Spring container that holds your routes. The process model stays focused on business steps while the route owns the details of how the message reaches the target.
- Request and reply: the task sends a message and receives a response into process variables, which suits synchronous-style steps.
- Routing logic in one place: content-based routing, retries and transformations live in Camel routes rather than in delegate code.
- Component reach: Camel components can reach databases, file shares and other systems that a plain HTTP task cannot.
- Single route owner: a platform or integration team can version and test routes independently of process definitions.
- Narrow scope: a handful of outbound calls usually stays manageable, while a large mesh of events often does not.
Before committing, confirm which Camel routes already exist, who owns them, and whether the process team can deploy changes to the Spring context without a full engine redeploy.
The event registry fits when Flowable must start processes, correlate messages to running instances or send events from models through an existing broker. Channels and event definitions describe the inbound and outbound flows, and the registry handles correlation parameters that route each message to the right instance. If your organization already runs Kafka, RabbitMQ or JMS, the messaging team usually expects integration through those brokers, so the event registry keeps the contract in the broker's terms.
- Broker alignment: the channel definition names the broker and topic or queue, which matches how the messaging team already governs traffic.
- Correlation: correlation parameters match incoming events to process or case instances without custom code in each model.
- Process starts: messages can start new instances, which a Camel task does not do on its own.
- Outbound events: send event tasks publish model state changes to subscribers.
- Dedicated broker topics: sibling topics cover Kafka, RabbitMQ and JMS in detail, so confirm which broker your team actually runs.
Confirm the broker, the message schema owner and the expected event volume with the messaging team before deciding.
The choice is often less about technology than about who operates each piece. A Camel task places routes in your integration layer, which means the Camel team or the platform team usually owns the route definitions, dependencies and release cadence. The event registry places channel definitions closer to the process team, while the broker stays with the messaging team. Mapping ownership early prevents a design where nobody can change a message format without a cross-team handoff.
- Route ownership: decide who edits
camelContextroutes and who approves changes that affect process variables. - Broker ownership: confirm whether the messaging team provisions topics, consumer groups and access rules for Flowable.
- Schema ownership: agree which team owns message schemas and how changes are versioned.
- Deployment coupling: a Camel route change and a process change may need to ship together, which affects release planning.
- Operational support: identify who responds when a message stalls, a route fails or a consumer lag builds up.
Ask the messaging team for their current broker standards and their process for onboarding new producers and consumers before the design review.
The number of integration points changes the answer. A few point-to-point calls from processes to legacy systems often fit neatly into Camel routes, which keep each call explicit and testable. When many processes and cases exchange events with several systems, a channel-based design through the event registry tends to scale better in terms of shared contracts and correlation. Count the distinct systems, the message directions, and the processes or cases that touch each one before choosing.
- Inventory: list every outbound call, inbound event and outbound event with its owner and direction.
- Overlap: note integration points that share a broker topic or a Camel route, since shared points favor shared patterns.
- Correlation needs: messages that must reach a specific running instance usually point toward the event registry.
- Hybrid designs: some organizations use a Camel task for legacy calls and the event registry for broker traffic, which needs a clear boundary.
- Legacy reach: when a legacy system is reachable only through a Camel component, a Camel task is the more direct path.
Illustrative example: a process that calls one mainframe gateway through Camel and receives one broker event may use both paths, but the boundary should be documented so nobody builds a second route for the same contract.
Once you have a candidate path, verify it against a short list of concrete checks before building. Confirm that your Flowable version and Spring setup support the chosen approach, and that the Camel release line you plan to use is supported for your Java version. Check the vendor documentation rather than assuming a component or channel type behaves the same way in your environment. A small proof of concept with one real message flow often exposes ownership or schema gaps faster than a design review.
- Version fit: confirm the Flowable release, Spring Boot baseline and Camel release line support your Java version and runtime.
- Support status: check whether your Camel release is LTS or standard and when it reaches end of life.
- Failure behavior: test what happens on timeouts, broker outages and malformed messages in both designs.
- Observability: decide where to see message flow, correlation misses and failed jobs.
- Exit path: note how hard it would be to move a flow from one approach to the other later.
Before finalizing, confirm the Camel release line, the broker version and the Flowable version with the vendors and your own platform team.
Securing the Camel integration
A Camel route in a Flowable process reaches systems that hold real data and real credentials, so the route is part of your security boundary. The cards below cover the decisions that carry the most risk: where secrets live, which accounts routes use, how connections are encrypted, who can change routes, and what gets logged.
Keep credentials out of routes
Camel route definitions in Java, YAML or XML are usually stored in source control and copied between environments, so credentials written into endpoint URIs end up in places many people can read. Resolve passwords, tokens and keys at runtime from a secrets store or environment-level properties that the Spring container provides to the camelContext bean. Check each Camel component's documented options for credential properties, and confirm how your deployment platform injects them. Rotation should not require editing a route.
Least-privilege accounts for legacy endpoints
Legacy systems often expose a shared account with broad rights, and a route reuses it because that is the account the team already has. Create a dedicated account per route or per integration, granted only the operations and tables or endpoints the route needs. Read-only routes should use read-only credentials. Ask the owners of each legacy system to confirm what the account can do today, and document the list so a later review can compare it with what the route actually calls.
TLS on outbound connections
Routes that call REST services, databases, message brokers or cloud APIs send data across networks you may not fully control. Enable TLS on every outbound endpoint that supports it, and verify server certificates rather than disabling verification to get a connection working. Confirm for each component how it loads trust stores and client certificates, and whose certificate authority signs internal services. Treat a route that silently falls back to plain text as a defect to fix before it reaches production.
Control who can deploy routes
A Camel route runs with the engine's permissions and can call any endpoint its credentials allow, so a change to a route is a change to what the process can do. Limit deployment rights to the team that owns the integration, require code review and a pipeline that builds and tests the route before release, and keep an audit trail of which version runs in each environment. Confirm how your Flowable deployment pipeline and your Camel runtime, whether Spring Boot, Quarkus or Kubernetes, each handle this.
Log messages without exposing personal data
Routes often carry customer names, account numbers or health details, and debug logging of message bodies can copy that data into log stores with weaker access controls than the source system. Log message identifiers, correlation keys and status instead of full payloads by default. Where a body must be logged for troubleshooting, mask defined fields and limit the log level and retention. Confirm which logging and tracing options each component writes by default, since some include headers or bodies automatically.
Review component security options
Each Camel component has its own authentication, encryption and timeout options, and defaults differ between components and versions. Before a component goes into a route, read its entry in the Camel documentation for security settings, note which ones your environment requires, and record the version you tested against. Pin the Camel release your organization has approved, and recheck component options when you upgrade, because a change in defaults can weaken a route without any change to its code.
Why the Camel task fails and how to fix it
This table lists the failures teams most often hit when a Flowable Camel task is wired to Apache Camel routes, with the likely cause and the first fix to try for each. Work down the rows in order when a process is stuck or a call errors, since several symptoms look alike from the BPMN side.
| Failure | Likely cause | First fix to try |
|---|---|---|
| Camel task cannot find camelContext | The Camel task looks up a camelContext bean by default in the Spring container, and that bean is missing, misnamed or defined in a different context | Confirm the bean exists in the same Spring context as the Flowable engine, or set the context reference the task expects to the bean name you actually use |
| Route does not start | The route builder is not registered as a Spring bean, or the route fails on startup because an endpoint, property or component is missing | Check application startup logs for route start errors, register the route builder as a bean, and verify each endpoint URI resolves |
| Camel and Spring Boot versions do not match | Camel starters and the Spring Boot version in the project come from different release lines, so auto-configuration or component classes conflict | Align the Camel BOM with the Spring Boot line your Flowable version uses, and confirm the Camel release supports your Java version |
| Legacy endpoint times out | The Camel route waits on a slow or unreachable system, and the default timeouts are longer or shorter than the legacy system needs | Set explicit connect and read timeouts on the Camel endpoint, then test the legacy call outside Flowable to measure real response times |
| Message format mismatch | The process variable is a Java object, JSON string or XML fragment, while the route expects a different body type or field names | Print the message body at the route entry, then convert it explicitly in the route with a processor or data format before the call |
| Unhandled exception leaves process waiting | The route throws an error that Camel does not map back to the process, so the Camel task never completes and the instance stays at the task | Add an error handler in the route that reports failure back to the engine, and check the failed job list for the instance |
Questions buyers ask about Flowable and Camel integration
What drives the cost and effort of a Flowable and Camel integration?
The main drivers are the number of external systems, how many Camel routes you need, and how much of each system's behavior the team has to learn. Each Camel component you use, such as Kafka, JDBC or a legacy protocol, adds configuration, error handling and testing. Cost is usually split between your own staff time for access, data ownership and sign-off, and any partner time for design, build and verification. One-time costs cover building routes and delegates. Recurring costs cover upgrades, Camel release tracking and monitoring. Ask any quote to list the systems in scope, the routes, the test environments and the handover of runbooks. No price figure is given here because none is supplied for this topic.
How long does it take to scope and build a Camel integration for Flowable?
Duration depends on how many systems the Camel task must reach, how well those systems are documented, and how quickly your teams can grant test access. Scoping usually comes first: you list the process steps that call Camel, the message formats, the error paths and the owners of each external system. The build then covers the camelContext bean, the routes and the Flowable service tasks that call them. Confirm the timeline in writing before work starts, and ask which parts depend on your change approval and test windows. No duration is stated here because none is supplied.
What does the client team need to provide for this integration?
The integration needs people who own each external system, test endpoints or sandboxes, and credentials managed through your normal secrets process. You also need someone who can explain the business meaning of each message, the expected error responses and the retry rules the business accepts. Your platform team should confirm where the Spring application runs, how it reaches the systems and which network paths are allowed. Ask the implementation partner to list these inputs in the written scope so that gaps are visible before the build starts.
Can our internal team build the Camel integration without a partner?
Yes, if your team already runs Java and Spring services and has someone who knows the Flowable engine, the Camel routes and the systems being called. The Camel task is defined as a service task with flowable:type set to camel, and by default it looks up a camelContext bean in the Spring container. That is a manageable pattern for experienced Java teams. The gaps usually appear in error handling, message correlation and operating the routes after go-live. Confirm your team's skills with each Camel component you plan to use, and decide who owns upgrades before you start.
How do Camel LTS and non-LTS releases affect the integration choice?
Pick a Camel LTS release for production integrations that you expect to run for a long time, because LTS releases receive bug and security fixes for a longer period, up to one year according to the Camel download page. The download page lists Apache Camel 4.22.1 as an LTS release supporting Java 17, 21 and 25, with end of life in August 2027, and Camel 4.18.5 LTS with end of life in February 2027. Camel 4.23.0 is a non-LTS release listed as the latest standard release in October 2026. Check the support dates against your Java baseline and your upgrade calendar before you choose a version.
When is the Flowable event registry a better option than Camel?
Use the event registry when the main need is to start or correlate Flowable processes and cases from messages, or to send events from models, and the messaging broker is the main integration point. Use Camel when the integration needs many connectors, protocol conversion, or routing logic that sits outside the process model. Many teams use both, with Camel handling transport and transformation and the event registry handling process-level events. The choice should follow the systems involved and the skills in your team. Ask for a short comparison of both options against your actual systems before committing to either.
How DeployOpen scopes and delivers Flowable and Camel integrations
DeployOpen plans, implements, integrates, tests, documents and supports Flowable engines inside your own infrastructure, including the Camel task and the Camel routes it calls. Engagements start from a written scope that sets the routes, components, legacy systems and handover items before any build begins.
How we scope
- Inventory the processes and cases that need external calls, and decide which ones call Camel versus the event registry.
- List each Camel component, legacy system endpoint, credential store and network path the routes will reach.
- Agree the Camel release line and Java baseline with your platform team before any routes are written.
How we build
- Implement the camelContext bean, service tasks with flowable:type set to camel, and route definitions in your repository.
- Map process variables to message bodies and headers, and test error paths for timeouts and failed downstream calls.
- Run routes against test copies of legacy systems so failures surface before production cutover.
How we hand over
- Deliver documented routes, variable contracts, configuration keys and deployment steps for your engineers to own.
- Walk your operations team through monitoring, failed jobs and route logs so they can diagnose incidents without us.
- Record open decisions and the versions tested, so future upgrades start from a known baseline.
How we support
- Ongoing support, Camel and Flowable upgrades and continuous testing are available as a retainer after handover.
- Review new Camel releases against your routes and Flowable release notes before you schedule an upgrade.
- Confirm support terms, response expectations and included upgrades in the written scope before work starts.
