Job Suspension – Powerful Operations with Camunda BPM

By
  • Blog
  • >
  • Job Suspension – Powerful Operations with Camunda BPM
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
This blogpost is about a very powerful feature in camunda BPM for operating critical processes which are in production. Given a core process which operates under high volume, almost any problem is critical in a way. The more options you have to deal with those problem the better. I am going to show you one of those options, namely job suspension.

 

The Process

Let’s say you have automated your order processing, i.e. the orders which are generated in your web shop. I will use a very simple example. New orders start a process in the backend, the delivery is scheduled and once the goods are delivered, the payment is scheduled. Let’s say your business is successful and you have many orders per minute.
Order processing model

From a technical perspective, all steps are executed asynchronously.

The Problem

Let’s assume that the payment service is down for an hour. Immediately you will observe loads of exceptions from your engine, arising from failing process instances, which cannot settle the payment.

Order processing model with payment service down

While the payment service stays down, what do you need?
  • You still need to take incoming orders, no argument about that, that’s your business
  • Still, you do not want any process instance that calls the payment service to end up in a corrupted state, that has to be dealt with afterwards.

The Solution

Since you are using asynchronous continuations, the job suspension feature of camunda BPM comes into play. Using job suspension you can suspend all jobs of process instances which are about to call the payment service. This is very helpful, since you are still able to start new process instances for incoming orders but you avoid running instances from ending up in a failed state. This can be done globally from a process perspective.

Stop process before it reaches payment service while it is down

Once the payment service is up again, you do the inverse and simply unsuspend the job definition. Of course it will take some time until all “waiting” jobs are executed, but in general the process engine is doing the job which would have involved manual intervention otherwise.
 

Other Use Cases

  • you are calling java code which has a bug. you can stop all instances from calling the wrong java code, deploy a hotfix and continue
  • you need to make changes to a script or business rules before you want processes to continues
  • any other problem which is related to your process but beyond the control of the engine

Job Suspension vs. Job Retry

What are the different use cases for job suspension and the engine’s built-in retry mechanism? In short, I would recommend the retry mechanism for unknown and unexpected problems which occur temporarily. As soon as you know that something is not going to work, I would recommend to use job suspension to avoid too many retries/exceptions of the same problem. Of course this is a general statement that has to be decided depending on the actual problem.

Related Readings

 

Getting Started

Getting started on Camunda is easy thanks to our robust documentation and tutorials

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.