Testing Components in Camunda 8 Using a Blue-Green Approach

While some would advise against testing anything in production, many use blue-green methods to test or validate components in production rather than trying to simulate production in nonproduction environments.

Typically, these components are tested with a small population of data rather than the entire population. In this way, a component can be battle-tested before being rolled out to a wider audience, limiting unexpected outcomes and subsequent fixes or rollbacks.

Testing different workers, connectors, rules, and subprocesses in Call Activities

What do workers, connectors, rules, and subprocesses have in common? They can all be dynamically invoked, meaning the types and IDs can be set to variables to use at runtime to enable dynamic behavior. Taking advantage of this feature will allow us to employ a blue-green strategy to test variants or entirely new components. We’ll also discuss ways to dynamically set those values via rules or expressions.

Testing different workers and connectors

The easiest way to enable different workers is to set a different type in Service Tasks. While you can set the type statically, using a FEEL expression allows for the type to be set at runtime.

Here is an example of setting a Service Task type to a FEEL expression:

Clicking on the fx icon in the Job Type field changes it from static text to a FEEL expression. If you’re not familiar with FEEL (Friendly Enough Expression Language), it’s part of the decision model and notation (DMN) standard. It’s used to appeal to a wide range of people, not just developers, to create logical operations. Don’t let the name of the expression language fool you—FEEL is quite powerful. For more information on FEEL, see our documentation. We’ll see more FEEL examples later.

What you see in this example is a FEEL expression that points to a variable called aVariable. In this example, aVariable needs to be set somewhere in the process to enable dynamic behavior in Service Task.

Instead of trying to come up with a unique name for the type or trying to remember what type a particular worker is looking for, you can concatenate strings and variables:

In this example we’ve taken the static string “myWorker.” and appended the variable version. We need to make sure version is set somewhere in the process. Let’s investigate some ways that it can be accomplished dynamically.

One option is to use rules to decide what worker to use. Take, for example:

While a business rule task could be added to the process, it might be more appropriate to use it if a rule task already exists to piggyback on. For something like this, if there is no existing rule task available, so you may want to use a FEEL expression instead.

Here is the equivalent:

At some point in the process, the variable amount needs to be set, and the FEEL expression will do the rest:

You can also randomize the use of the alternate version to employ a Canary deployment pattern with increasing probabilities as confidence in the newer version grows. A simple example would be to use the random number() FEEL function to generate a random number between 0 and 1 and set the probability percentage as needed.

Taking the example above, it would look something like:

Let’s move ahead with the example without the use of the random number() function. Note the jobType in the service task. It’s been correctly appended with the version:

The FEEL expression can occur almost anywhere in the process but it makes the most sense to include it, as in this example, as an input variable to a task to make it easy to find and update. Otherwise you may find yourself tracking down a “bug” of unwanted behavior.

You can also test connectors in a similar way by updating the job type in a connector template. Typically, the job type in a connector is a hidden value in the template, meaning a user or developer cannot change it in the properties panel, though it can be changed in a process definition BPMN XML once a connector template has been applied.

While not the most elegant solution, it will work:

A more elegant solution would be to update the connector template to make the job type field visible to allow people to update the job type in the properties panel instead.

Testing different rules and subprocesses

Using similar techniques (FEEL expressions), rules and sub-processes in Call Activities can also be blue-green tested. The IDs for both can be FEEL expressions, which can be set at runtime to dynamically invoke a rule or process:

Rule

Call Activity

And there you have it! A few ways to blue-green test various components in Camunda to reduce impacts to provide flexibility when introducing changes to your applications.