Synchronous vs. Asynchronous Service Invocations – BPMN Service Task (1)

By
  • Blog
  • >
  • Synchronous vs. Asynchronous Service Invocations – BPMN Service Task (1)
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 BPMN 2.0 Specification provides the Service Task activity allowing users to invoke some application service. In this Blogpost I want to explain the difference between a synchronous and an asynchronous service invocation in Camunda BPM.

NOTE: this blogpost covers the topic at an abstract level. If you are looking for concrete, ready-to-use examples, have a look at our quickstart repository: 

Synchronous Service
Invocations

Let’s start with synchronous service invocations. A synchronous service invocation follows the well-known Request/ Response Pattern:

Request / Response Pattern diagram

The process engine performs a synchronous request to a service and waits for a response.
The characteristic property of this invocation pattern consists in the fact that the process engine thread sending the request is blocked until the response is obtained:

process engine blocked

Transactional process engines such as the Camunda process engine will typically associate a database transaction (Process Engine Tx in the illustration above) with this thread.
Implementing a synchronous service invocation in Camunda BPM is very straight forward:
  1. Model a Process containing a Service Task
  2. Attach a “JavaDelegate”-Implementation to the service task.

Check out this quickstart on synchronous service invocations to learn how to to implement this.

Asynchronous Service Invocations

An asynchronous service invocation usually follows the Request / Acknowledge / Callback Pattern:

Request / Acknowledge / Callback Pattern diagram

The process engine sends the request to the service. But instead of processing the request right away, the the service first puts the request into a Queue. It then acknowledges the receipt of the request to the process engine. The request is then delivered asynchronously to the actual request processor. The request processor executes the business logic. Finally it sends a callback to the process engine which may now continue execution in the process instance.
In practice, we encounter multiple variations of this pattern. For example, the callback itself may be delivered synchronously or asynchronously. Furthermore, the queuing of the requests may be performed before or behind the service boundary. Here is an illustration of two of such variations:

synchronous and asynchronous process engine

Contrary to the synchronous service invocation, the transaction context of the process engine is  not propagated to the service implementation. In fact, an asynchronous service invocation always comes down to at least two transactions (labeled Tx1 and Tx2 in the illustration below):

process engine thread not blocked

  1. in the first transaction (Tx1), the request message is sent. If the request is acknowledged, the process engine interrupts execution and commits the transaction.
  2. in the second transaction (Tx2), the callback is sent and processed. This constitutes a new transaction in which the process engine resumes the state of the execution and ends the service task activity.
Implementing an asynchronous service invocation in Camunda BPM is a lot more complicated than implementing a synchronous service invocation. You have to:
  1. Model a Process containing a Service Task
  2. Attach a “SignallableActivityBehavior”-Implementation to the service task.
  3. In the execute() method, send a message to the actual Business Logic
  4. Implement a callback message which is correlated to the same process instance from which the request message was sent.
Check out this quickstart on asynchronous service invocations to learn how to to implement this.
Creative Commons License
This blogpost including images & illustrations is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

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.