Camundala — a new Way to develop Camunda BPMNs.

As a Scala Enthusiast I wanted to check out if it is possible to develop BPMNs with Scala.

Photo by Anda Deea on Unsplash

After I started this more than a year ago I had to stop my first attempt — as it took to much of my time — and yes I admit the weather was too nice😎. See here — if you are interested: https://github.com/pme123/camundala

Then when the first release candidate for Scala 3 arrived I wanted to check it out — and I thought why not with Camundala🤓.

This Blog should display the main ideas behind Camundala, how it is done with Scala and how you can use it to develop your BPMN processes.

State of the BPMN-Develop-Art

BPMNs are really powerful and easy to follow. However implementing them adds a lot of code and information that is cluttered in a XML. So for example merging them is a nightmare😱.

Pros:

• There is the Camunda Modeler that helps you — especially finding the snippets you added.

Cons:

• Everything is dynamic — you have to write tests or you find out during runtime💣.
• XML Handling in a Source Control.
• Bad Script support.
• Some conventions you must know in references (like embedded: )
• Multiple Sources are linked by a text reference (example: external Scripts).
• Adding information is tedious (example: Input-/ Output-Mapping).
• Mapping is a manual task.
• There is no clear boundary between the responsibilities of the business specialists and the (technical) implementors.
• Reusability is really hard.

I am sure there are much more pros and cons — but for me that was enough to give it a try. And as a Spoiler — these Cons mostly disappear with Camundala🥳.

Key focus

Separate Business Modelling from technical Implementation.

• The Business Model contains only the business relevant stuff — no mappings etc.
• The Implementation Model is generated from the Business Model and the technical Implementation — this is the Scala part.

BPMN Engineer centered.

• This is all about productivity.

Composable on any Granularity

• It does not matter if it is a simple variable, a form field or a whole process, everything can be shared and composed in an easy way.

Provide a Type-Safe way to model a BPMN Process.

• Let the compiler help you to do your BPMN right and fast.

100 % Camunda compatible.

• Deployed Models run on any Camunda Engine — no Extras needed.

Architecture

Camundala provides three layers:

1. model: The BPMN Domain Model.
2. dsl: A Domain Specific Language that allows you to define your BPMN in a fluent and simple way.
3. dev: Implementation of the Camundala Dev Cycle.

Then a Project also consists of three Layers:

1. services: The Services you need for your Processes — like Java Delegates.
2. dsl: The Project’s extensions to the Camundala DSL (yes you can add easily your specific Project DSL 🤩)
3. bpmn: Your BPMNs defined in the DSL.

Dev Cycle

One of the goals is to provide a pretty automated Process that takes a BPMN and updates it with your BPMN-DSL, runs the Tests and deploys everything. It will look something like this:

First there are only two manual steps (the red activities):

1. Create BPMNs und DMNs on Cawemo together with the Business Specialists.
2. Develop the Process with the DSL.

For now I have implemented the green Activities, to verify it works for the first example (we will see this in the next chapter).

• Generate IDs: Takes the names given in the Cawemo BPMN and generates IDs from them. The ID is the link between the Cawemo BPMN and the DSL-BPMN.
• Generate DSL stubs: Reads the Cawemo BPMN and creates stubs for the DSL-BPMN (so you have an easy start 🎉).
• Compare with existing DSL-BPMN: If you have already started — you want to check if there are changes in the Cawemo BPMN. So this will report any differences between these two models.
• Merge DSL with Camunda BPMN: In the end we want a 100% compatible Camunda BPMN. So in this step it merges the DSL-BPMN back to the Cawemo BPMN (with generated IDs).
• Generate the BPMN as XML, that can be deployed.
• Deploy the BPMN XML to the Camunda BPMN Engine.

Camundala Example

We take the UserTask, to show Scala 3 in action.

model

I try to model the Domain as close as possible to the BPMN standard and Camunda. However for now I support only the stuff needed for the examples I want to realise as a PoC.

UserTask class diagram

There are two parts here:

1. Composing the domain classes that hold the values. This is modelled with Case Classes. So composition is the only way to avoid redundancies.
2. A Hierarchy of Traits that describe the functionality of the different components. They are used by the DSL to manipulate the domain model as everything is immutable.

This is the UserTask Case Class where we see that it has a task and optionally there is a form. For each of these values there is a Trait we inherit.

All that is needed is an ElemKey (for sorting and naming) and functions to update the immutable values of the Case Class.

The Trait describes what an implementation will need, but it also implements the descriptions of its inherited Traits ( activity , withActivity ).

dsl

What we want to provide for the user is a fluent nice DSL to describe their BPMN processes.

We can distinguish two types:

1. Top level: as soon as there is a list of elements I decided to use a top level element. Examples are process , userTask and textField .
2. Extensions: if there is only one sub-element or an attribute we will extend the top level element. Examples are .nodes .form and .label .

This gives you a simple, nice to read description of your BPMNs. I hope you agree😉.

The implementation of this is pretty basic stuff:

• Top level elements are simple method calls.
• The extensions use the domain model within the new Scala 3 extension methods (cool 🙌 right?).

dev

All the automation for the Camundala Dev Cycle happens here (see the according chapter above). I won’t cover its implementation in this blog.

Project Example

For the first Prove of Concept I choose the famous Twitter example. You find it along with the Project on Github.

Let’s step through the Layers:

services

Here is what you usually have in your Camunda project, like Java Delegates.

I changed this also to Scala, but this could also be Java Code.

dsl

Now it gets more interesting. Today the link to this delegate is a text, that hopefully never changes. How can we improve this with our DSL?

This is now the example using the DSL. Looks fine and the weak textual link is replaced with the constants emailAdapter and tweetAdapter .

Now let’s add some extensions to the DSL, that are specific in our project.

Do you spot the extensions we did?

• createTweetForm / reviewTweetForm : the static forms.
• kpiRatio : a shortcut for the property.
• emailDelegate / tweetDelegate : hide the implementation of the Task implementation.

In the code this is again just using the Camundala DSL from within a Scala 3 extension method. I think you see the point that this lets you compose your BPMNs on any granularity.

bpmn

Well I showed you already the Twitter example DSL in the chapter above (that actually belongs in this layer). Next to the BPMN DSL we also setup the App that runs the Dev Cycle.

This is a ZIO App that needs a RunnerConfig. Sorry, no further explanations for now — but I think you get what it does😉.

Run the example

If you want to give it a try, here is what you have to do.

• You need SBT.
• Generate the Camunda BPMN from the Cawemo BPMN and the DSL BPMN:

sbt "exampleTwitter/runMain camundala.examples.twitter.bpmn.TwitterProcessRunnerApp"

• Run the Spring Boot App with the Twitter Process:

sbt "exampleTwitter/runMain camundala.examples.twitter.TwitterServletProcessApplication"

Conclusion

This project is in an early phase — but I hope this blog helps, that you can picture some potentials for Camundala🙏.

Let me know what you think🤓.

References

Camunda

Scala 3 Book

Camundala (contains Twitter example)

ZIO

Original Twitter example