Next to minor changes, the new release adds support for consuming Camunda’s external tasks (introduced in Camunda 7.4.0) in the form of a Camel route endpoint. This is another level of technical decoupling and brings a lot of adventages.

Consuming Camunda’s external tasks

This is a simple example, showing how to consume external tasks in a Camel route:

After starting the Camel context, the route starts polling Camunda for externals tasks of topic1. In this example, the task is converted to a SOAP request using a custom converter and is sent to a webservice endpoint. Once the webservice call is done, the external task is completed and the workflow proceeds.

Advantages

There are some good reasons to use external tasks for the combination of Camunda BPM and Apache Camel:

Loose coupling

Using a Camel route instead of a Java bean inside a service tasks gives you some degree of decoupling, since you don’t need the Camunda Java API any more (see here for details). Using external tasks also decouples Camel from your workflows, because both sides, BPMN and Camel, use the topic as the identifying feature for the work that needs to be done.

Non-blocking service execution

Do not block job executor threads

For example, calling a webservice might be a long task and is blocking the thread which is running the workflow. This thread might be an HTTP-thread if the process was started in the context of sending a form and the user has to wait for completing the webservice. If you place an asyncBefore flag at the service task, the user wouldn’t have to wait, because the thread is not blocked for executing the service task. Instead, the task is now executed by one of Camunda’s job executor threads.

But even job executor threads shouldn’t be blocked, because you have to think about proper configuration for scalability. Another problem which can arise is that the response message of an asynchronous service call might arrive before the engine transaction has committed. And that means the incoming message cannot be correlated. Using external tasks solves this problem, because an external task is a wait state within the workflow (like a user task). The service is not called before the transaction is committed, hence the response message can never be faster.

Asynchronous communication

Hide technical issues

A best practice when modeling BPMN is to hide technical issues, because then they don’t affect the readability of the workflow and it’s business aim. If you had asynchronous communication with foreign systems in the past, it was hard to find a clean way to do so.

The new Camel endpoints for external tasks offer a clean solution by splitting asynchronous communication into up to four transactions relevant in the context of a service task (see the image above):

As mentioned in “Non-blocking service execution”, an external task is a wait state and therefore the transaction which created the task commits immediately.

Polling the external task and sending the synchronous message is the next transaction. By using Camels “transacted” feature it is even possible to split this transaction into two transactions (consuming the external task; sending the request) or three (consuming the external task; sending the request; save information about failed communication).

Conclusion

Jus as Camunda BPM is a great engine for processing workflows, Apache Camel is a great framework for integration patterns. Camunda BPM Camel combines the two and gives you the ability of building complex systems which still are easy to maintain. The new release 0.5.0 takes the next step by using Camunda’s external tasks.