How Camunda is helping us Digitally Transform through Process Automation

Since some time now, we have embarked on a digital transformation journey that aims to automate as many aspects of the business as possible. This involves automation of business processes and decisions, management of manual tasks, and an increase in customers’ expectations. Automating business processes brings about its own unique set of challenges, such as making the various parts and systems of a company work together, called process orchestration, the means by which to handle scenarios where errors occur while carrying out a distributed transaction, for example an item is out of stock, and some form of rollback is required, such as a refund is issued to the customer.

Does this sound complex? Are you trying to figure out how to deliver all of this whilst keeping the highest level of quality?  

This concerns a lot of businesses and industries, with many relying on industry standard notations to structure their requirements, and use models such as Business Process Model and Notation (BPMN), Case Management Model and Notation (CMMN), and Decision Model and Notation (DMN). BPMN is the more mature and popular notation of the three. It is used to graphically represent well-defined business processes and looks just like a flowchart. CMMN was built on top of BPMN to handle more ambiguous scenarios where the exact order of activities within a process is not well-defined and predictable. Finally, DMN is a fancy term for a decision table where an output can be determined based on a set of inputs and rules. BPMN, CMMN, and DMN can be used independently, however, they are specifically designed to complement each other and be used together.

Mapping out your business processes using BPMN, CMMN, and DMN has its own merits. The real power of these notations comes when paired with workflow and decision automation platforms, which are designed to interpret the notations and carry out the actions described by either calling external APIs or Web Services, or by invoking underlying code deployed on the platform. Furthermore, these platforms offer out of the box tools for common use cases and patterns, such as timed retries, human task list management, and many more. One such workflow and decision automation platform is Camunda, which we’ll be reviewing closer.

What is Camunda?

Camunda is an open-source Java based workflow and decision automation platform. The platform can be either deployed on a standalone basis or it can be embedded inside Java applications, more specifically Spring Boot applications. Furthermore, all its functionality is available via Rest APIs making it virtually technology agnostic. Camunda also offers a lightweight desktop modeler to help you create BPMN, CMMN, and DMN diagrams, and a web-based dashboard to monitor your running instance.

On top of this, Camunda offers further functionality that is available against a license, such as advanced dashboards, online modelling collaboration tools, and extensive monitoring and reporting capabilities.

Let’s delve a little deeper, and see a quick example. On the right, we see a part of a much larger process where an email and an SMS are sent to a customer.

Under the hood, there is a small Java class known as a Java Delegate that prepares and sends emails and SMSs based on a number of input parameters (recipient address, message body, etc.). This Java Delegate is invoked directly through the Camunda modeler via a Service Task (the boxes with the cog wheels) through the class’ fully qualified name and parameters set directly in modeler.

The service tasks are linked to a Parallel Gateway (see diamond with the plus sign) in order to be executed concurrently and asynchronously without writing any code.

Furthermore, once a service task is marked as asynchronous in Camunda you are given the option to configure timed retries just by filling a text box in the modeler with an  ISO 8601 string; for example, R5/PT3M means repeat every 3 minutes (PT3M) for a maximum of 5 times (R5). If the service task does not manage to be completed successfully after the retries expire, an incident will be logged in Camunda Cockpit – a web-based dashboard. From this dashboard, you are presented with all the error’s details and the ability to manually retry the offending task after changing the parameters.

If this isn’t low code enough for you, we could have swapped the Java Delegate for a direct call to the Rest API that sends emails and SMSs directly from the Camunda modeler through the use of connectors.

We did not opt for this to reuse in-house libraries.

Why Camunda?

Camunda is not the only workflow and decision automation platform out there. So why did we choose Camunda over its “competitors”? There are a number of very good reasons, so here’s a list:

• It is open source, but there is the option for paid support and advanced features should we decide to invest further in the technology.
• It comes with enterprise ready features out of the box like dashboards, retries, etc.
• It is under active development, has good documentation, and an active online user community.
• It can be embedded in Spring Boot applications which is what our application ecosystem mostly consists of
• It is used by a number of large enterprises which see heavy throughput, indicating that the technology is mature and scalable.
• The platform and resultant code are fully testable through unit tests and mocks.

If this isn’t good enough, during development we found even more benefits!

• Multiple developers could work on the same code base at the same time without dealing with merge conflicts, as the individual building blocks are self-contained.
• The end result is self-explanatory, which comes in handy during meetings.
• The components and flow are easily re-usable (it’s like Lego, but without the risk of stepping on it)

Camunda Conundrums

Even with all the documentation and community support, using Camunda was a totally new experience for us and we did hit a few stumbling blocks along the way. Some things we learned the hard way, and some things we’re still figuring out. Here’s a brief rundown.

Black Box Thinking

One of the easiest pitfalls to fall in is not thinking about the various components as standalone modules. It’s easy to realise you’re missing some data while developing, and access it using the easiest way possible as opposed to setting up input variables. This obviously couples the various modules together and you would miss out on the reusability and testability of the module.

Error Handling

Error handling in Camunda is a little different than standard Java error handling. Primarily, because Camunda differentiates between technical and business errors. It is important to have a clear understanding of what should happen in the various error scenarios and keep track of all your error codes. Furthermore, the way you decide to handle your errors might affect your choice of notation between BPMN and CMMN.

Embedded vs Standalone

Camunda can be deployed as either a standalone application or as an embeddable within a spring boot application. Given that our application ecosystem is primarily Spring Boot based, we opted for the embedded approach. However, should we want more control over Camunda’s process engine or need advanced customisation, we know that the option is available. If your application ecosystem is not Java based, your only option is to deploy Camunda as a standalone. The option to use Camunda as a cloud service is also currently available in beta against a subscription.

Camunda @ GO

GO is a leading quad play telecoms operator in Malta and we started using Camunda to orchestrate a new automated internet troubleshooting service available through our customer portal. Camunda was instrumental for the project’s success as the troubleshooting process crosses many domains and requires interaction with a lot of different systems. We aim to take more advantage of Camunda’s capabilities in the coming months as we make the troubleshooting process smarter and capable of tackling different types of services. Stay tuned!

About the Author and the Team

Samantha Catania is a System Lead Developer within GO’s Digital Department. She joined the team in 2015 and specialized in the development of Rest APIs. Being part of an awesome team of 6, they mostly focus on GO’s customers’ online journey.

Have a look at our careers page and get in touch with us if you want to take your career to the next step!  For GO products and services, visit our official website or get in touch with our experts online or by visiting any of our GO outlets.