Camunda BPM Camel 0.5.0 Released – External Task Support

By
  • Blog
  • >
  • Camunda BPM Camel 0.5.0 Released – External Task Support
TOPICS

30 Day Free Trial

Bring together legacy systems, RPA bots, microservices and more with Camunda

Sign Up for Camunda Content

Get the latest on Camunda features, events, top trends, and more.

TRENDING CONTENT

The community extension Camunda BPM Camel seamlessly connects Camunda BPM and the integration framework Apache Camel.

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 advantages.

Consuming Camunda’s external tasks

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

public class CamelRouteBuilder extends RouteBuilder {

   @Override
   public void configure() throws Exception {

      from("camunda-bpm:poll-externalTasks?topic=topic1")
            .convertBodyTo(Topic1SOAPRequest.class);
            .to("cxf://https://myserver/topic1service?serviceClass=com.example.topic1service&dataFormat=MESSAGE");

   }

}

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.

For more details, see the documentation.

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):

  1. As mentioned in “Non-blocking service execution”, an external task is a wait state and therefore the transaction which created the task commits immediately.
  2. 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).
  3. Processing the asynchronous response. E.g., store new data into your tables.
  4. By using the flag asyncAfter at the service task, further workflow processing will use it’s own transaction and won’t undo the data previously stored in case of a rollback.

For more details, see the documentation.

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.

This is a guest post by Stephan Pelikan.

Try All Features of Camunda

Related Content

We're streamlining Camunda product APIs, working towards a single REST API for many components, simplifying the learning curve and making installation easier.
Learn about our approach to migration from Camunda 7 to Camunda 8, and how we can help you achieve it as quickly and effectively as possible.
We've been working hard to reduce the job activation latency in Zeebe. Read on to take a peek under the hood at how we went about it and then verified success.