Comparing and Contrasting Open Source BPM Projects

According to Black Duck’s 2016 Future of Open Source Survey, 65% of companies are now using and contributing to open source projects. Add to that Githubs 38 million projects and 15 million contributors/developers and you can see that this high level of contribution has led to a constant rate of change in the open source field. A trend that is only accelerating as new projects are created every day, while others are being forked off of existing open source projects. This expanding list of open source projects provides viable alternatives to many closed source products. One category of software that has been influenced by this open source trend is Business Process Management (BPM).

BPM Products are geared towards automating manual processes. Many business processes start off using e-mail or spreadsheets and grow to the point when these are no longer manageable. Some examples are when the business process spans multiple departments or when the workflow includes system-related steps in addition to human steps. More advanced use cases include case management type activities that require investigation and unstructured, dynamic type workflows. One particularly interesting trend on the case management front is that many industry products are starting to offer case management and business process management capabilities as part of the same tooling, vs. requiring separate products. You can see this trend present in open source BPM products.

A number of open source BPM products can provide an alternative to closed source BPM products. Some of these include Activiti, Camunda, and jBPM. jBPM, founded in 2006, was the first of these products with Activiti forking off jBPM in 2010 and Camunda forking off Activiti in 2012. While similar, there are a number of differences between these popular open source BPM products. Some of these differences include:

· Open source model (Community vs. Enterprise)

· Capability set

· Contributors

Let’s briefly touch on each of these topics through a compare and contrast of the open source BPM projects.

Open source model (Community vs. Enterprise)

Every company supporting an open source project has its own business model. Typically, open source companies offer enterprise open source products as a way to generate revenue — you typically have to pay for the enterprise version while the community version (in general) is free. Camunda provides an enterprise version of Camunda, Alfresco provides an enterprise version of Activiti, and RedHat provides an enterprise version of jBPM. I have found that the definition of “enterprise” can be different for each company. It is very important for developers using or sourcing an open source project to understand what a company means by “enterprise open source” before working with it.

In some cases, the enterprise version is not open source, but is comprised mostly of open source projects, enabling a lower price point than competing closed source products. One potential downside of this version is you lose the ability to contribute back to the code and are reliant on the supporting company to make the code changes.

In some cases, companies will provide a certain capability set in the community version, then offer additional capabilities in the enterprise version. Camunda and Alfresco both follow this approach. For example, with Activiti, the enterprise version has a full BPMN editor while the community version has a scaled back version.

In some cases, companies provide the same capability set in both the community and enterprise versions, the only difference is that with the enterprise version you pay for support. Depending on the degree of in-house expertise on the open source project, you may or may not want support. RedHat follows this approach with jBPM. The enterprise version of jBPM is based off a previous version of the community version, which is then run through a series of certification tests. Why? Sometimes community versions have experimental features that may have bugs, which is why older versions are often leveraged for enterprise versions.

Capability set

Let’s start and dig into the capabilities of Activiti, Camunda, and jBPM.

  1. Rules Engine

Some BPM products have their own rules engine, while others provide integration / plug-ins for commonly used rules engines. Drools is a common rules engine used in the industry. jBPM integrates Drools into its project whereas Activiti and Camunda take a different approach and provide integration with Drools. All three enable you to use a business rule task as part of the workflow; what differs is the integration behind the business rule task. Since Drools is native to jBPM, you can integrate the rules at the Ruleflow Group level (grouping of rules) in the model, whereas the others integrate at the rule level. This enables you to select a specific set of rules to execute at a particular point in the workflow using the native features of Drools. The same outcome can be achieved with Camunda and Activiti, but will require additional coding whereas jBPM provides the capability out of the box.

jBPM:

A look at how jBPM integrates the Drools rules engine.

Activiti:

A look at how Activiti integrates the Drools rules engine.

Camunda:

A look at how Camunda integrates the Drools rules engine.

2. Modeling & Execution Environment

BPM products typically provide an authoring/modeling user interface that enables users to build process diagrams. Some will also provide eclipse plug-ins for developers that would rather work in an IDE. Most BPM products have an execution user interface that enables users to view and process tasks assigned to them. Camunda provides four separate UIs — modeling, tasklist, process administration, and monitoring. This is a different approach than jBPM and Activiti as they provide a single web app for development and execution like the jBPM Workbench or the Activiti Modeler. One additional difference with the Camunda modeler UI is it’s currently only available as a desktop application. From an Eclipse plug-in perspective, Camunda no longer provides one as they decided to decouple from Eclipse to remove the need for updating the plug-in with each new release.

Camunda:

A view of the Camunda environment.

Activiti provides a single web app for development and execution. In the community version it is called Activiti Explorer and is very easy and simple to use. The enterprise version provides a full BPMN editor with advanced capabilities such as decision tables and step-based process designer. Activiti provides an Eclipse plug-in, giving developers flexibility to work in an IDE if they prefer.

Activiti Explorer:

A view of the Activiti Explorer environment.

Similar to Activiti, jBPM provides a single web app for development and execution. In the community version it is known as KIE Workbench where in the enterprise version it is called Business Central. Unlike Activti, jBPM offers the same capabilities in the community and enterprise versions. Similar to Activti, jBPM provides an Eclipse plug-in.

jBPM:

A view of the jBPM environment.

3. Form Builder

Form builders provide an easy way for users to view and add/update process related data within the execution user interface. jBPM provides a basic form builder through the KIE Workbench (same UI is used for modeling & execution as mentioned previously) that can be auto-generated from process variables. Camunda does not provide a form editor capability as they prefer that users build their own forms/UI in their preferred language. Activiti provides a form builder, but it is only available in the enterprise edition.

jBPM form builder:

A view of jBPM from builder.

4. Adapters

Given the importance of APIs in today’s software industry, the ability to make REST calls from applications is critical. All three products provide an ability to make REST API calls. jBPM provides an out of the box REST service task, while Camunda & Activiti require additional development to implement a REST call (custom java classes). An advantage of having an out of the box REST service task is it decreases development time by being configuration based instead of requiring custom development. While this makes it easier to add REST calls within a workflow, use it carefully. If you have many REST calls to make within a workflow, evaluate performing them in parallel to increase performance.

Below is a view of the jBPM REST service task:

A view of the jBPM REST service task.

jBPM Rest Service Task configuration:

A jBPM REST Service Task configuration.

Below is a view of the Service Task in Activiti Modeler. Once you add in a quick Java class, you can perform a REST call:

A view of the Service Task in Activiti Modeler.

Below is the Camunda service task. Similar to Activiti it requires further coding:

A Camunda service task that requires further coding.

5. Deployment modes

Camunda, jBPM, and Activiti all support embedded and standalone deployment modes. An embedded deployment enables you to run the BPM Engine as part of an existing application (within the same JVM). This can provide performance benefits as data is passed in memory instead of network calls. A standalone deployment exposes various API functions that can be invoked by a client via REST. This can be beneficial if you want to reuse a single workflow instance across different applications. It also can be a way to integrate an application to the workflow engine that may be written in a language that is different than the API of the BPM product. Let’s look at examples of how Activiti, jBPM and Camunda can be invoked via APIs.

The Activiti Engine can be invoked via REST through Spring Boot:

The below class, a Spring service, has two methods: one to start the process and one to get a task list for a given assignee. It is a wrapper around Activiti calls, but will be more complex in real life scenarios.

The below REST endpoint class is annotated with @RestController and delegates to the above service.

Both the @Service and the @RestController will be found by the automatic component scan (@ComponentScan) in the application class. The below curl command can interact with the REST API:

Below is an example of invoking a jBPM workflow using the jBPM java API that uses REST.

Camunda does not provide a java API out of the box, but can be accessed through REST calls. Below are two POST REST calls that can start the instance:

Contributors

Who contributes to the source code of an open source BPM project is important. An active community signals that a project is still being improved and enhanced. The number of contributors outside of the supporting company can also help indicate the degree of diversity in thought and ideas put into a project. Open Hub is one site that can be used to lookup this type of information. It provides details such as the activity, number of contributors, and commits. These are important factors to take into account. Below is an example Open Hub page for Camunda:

You can also see the list of contributors at the Activiti and jBPM and Camunda sites.

Summary

In this article, we’ve just briefly touched on some of the similarities and differences between the open source BPM projects Activiti, Camunda, and jBPM. All three have their benefits and the specific needs of your project will help determine which one is the right choice for you. The good news is, all three are viable open source alternatives for closed source BPM products. And their open source nature means they will continue to change and evolve over time.

  • The analysis in this article was performed on jBPM 6.4, Activiti 5.21, and Camunda 7.5

For more on APIs, open source, community events, and developer culture at Capital One, visit DevExchange, our one-stop developer portal. https://developer.capitalone.com/