07. April 2020

3 min

Micronaut meets Camunda BPM

I'm proud to announce that we've just released our open source project to easily embed Camunda BPM into Micronaut projects: it's simply adding a dependency in your Micronaut project. You're welcome to try it out and we'd love to hear your feedback!

Integration between Micronaut and Camunda BPM

I’m proud to announce that we’ve just released our open source project to easily embed the Camunda BPM Process Engine into Micronaut projects: it’s simply adding a dependency in your Micronaut project. You’re welcome to try this out and we’d love to hear your feedback!

Please read on and then jump to https://github.com/NovatecConsulting/micronaut-camunda-bpm.

Motivation

In our Camunda BPM projects we often use the Camunda BPM Spring Boot Starter to embed Camunda BPM in a Spring Boot Application. It’s basically just as simple as pulling in a dependency to get started. With the Camunda BPM process engine you get very good BPMN 2.0 coverage and a great developer experience at the same time.

However, Spring Applications tend to have increasing startup times and high memory usage with every Starter you add. The reason is mainly that Spring Boot Starters do a lot of magic which they do at runtime by scanning the classpath, using reflection, creating proxies, creating caches, and modifying byte code.

Micronaut has solved this problem by using ahead-of-time (AOT) compilation in the build phase. The development model is actually very close to Spring Boot, i.e. you have your managed beans and you can inject them where needed. However, you have the advantage that more errors are already found during the build (which takes a little bit longer but Gradle takes good care of only building deltas) and beans are initialized lazily by default.

Novatec is already deploying Micronaut applications to production in Kubernetes clusters. According to my colleague Carlos they are experiencing 3x better boot up times and 40% less memory than comparable containerized Spring Boot applications. Actually, running in resource limited environments like Kubernetes will make more of a difference than running the applications natively on a local environment. Of course this highly depends on the use case but faster startup and less memory is a generally desirable – not only when scaling up and down in a clustered environment.

What was still missing was an easy integration for Camunda BPM within the Micronaut framework. And that is when we decided: let’s try to build it.

Micronaut Camunda BPM =

Our Open Source Project: micronaut-camunda-bpm

Our vision from the beginning was that for the developer it would be as simple as pulling in a dependency.

And actually, this is all you need for Gradle:

implementation "info.novatec:micronaut-camunda-bpm-feature:0.2.2"
implementation "com.h2database:h2"
implementation "org.camunda.bpm:camunda-engine:7.12.0"

implementation "info.novatec:micronaut-camunda-bpm-feature:0.2.2"

implementation "com.h2database:h2"

implementation "org.camunda.bpm:camunda-engine:7.12.0"

or this for Maven:

  info.novatec
  micronaut-camunda-bpm-feature
  0.2.2


  com.h2database
  h2


  org.camunda.bpm
  camunda-engine
  7.12.0

info.novatec

micronaut-camunda-bpm-feature

0.2.2

com.h2database

org.camunda.bpm

camunda-engine

7.12.0

Well, those are now two dependencies because we preferred to not bundle the h2 dependency in case you want to use a real database (what you definitely will do for production).

By including the dependency you already get quite a few nice features:

Using h2 as an in-memory database is simply adding a dependency. Other data sources can be configured via properties.
The Camunda process engine with its job executor is started automatically.
Models (*.bpmn, *.cmmn, and *.dmn) found in the classpath are automatically deployed.
The process engine and related services, e.g. RuntimeService, RepositoryService, …, are provided as lazy initialized beans and can be injected.
Micronaut beans are resolved from the application context if they are referenced in expressions within the process models.

We configure Camunda BPM with sensible defaults, so that you can get started with minimum configuration.

Isn’t that exciting?

To deploy a process model create an executable BPMN file and save it in the resources’ root. When starting the application you’ll see the logs saying:

Deploying model: helloworld.bpmn

1	Deploying model: helloworld.bpmn

To Inject the process engine or any related services use the standard javax.inject.Inject annotation:

@Singleton
public class MyComponent {

  @Inject
  private ProcessEngine processEngine;

  @Inject
  private RuntimeService runtimeService;

  // ...
}

@Singleton

public class MyComponent {

@Inject

private ProcessEngine processEngine;

@Inject

private RuntimeService runtimeService;

// ...

}

To invoke a Java Delegate first create a singleton bean:

@Singleton
public class LoggerDelegate implements JavaDelegate {

  private static final Logger log = LoggerFactory.getLogger(LoggerDelegate.class);

  @Override
  public void execute(DelegateExecution delegateExecution) {
    log.info("Hello World: {}", delegateExecution);
  }
}

@Singleton

public class LoggerDelegate implements JavaDelegate {

private static final Logger log = LoggerFactory.getLogger(LoggerDelegate.class);

@Override

public void execute(DelegateExecution delegateExecution) {

log.info("Hello World: {}", delegateExecution);

}

and then reference it in the process model with the following expression:

${loggerDelegate}

1	${loggerDelegate}

For a more detailed “Getting Started” (including configuration properties) see our project page on Github at https://github.com/NovatecConsulting/micronaut-camunda-bpm.

We still have more ideas and some issues in the backlog but on the other hand we’re happy to publish this release because it already provides a great value if you want to get started with Camunda BPM in Micronaut.

You’re welcome to try this out and we’d love to hear your feedback!

And as always: we’re happy to support you with our BPM Technology Consulting.