This is an overview of what Business Process Model and Notation is. Let's dig into what can be done with it, and how we can use Camunda to execute our process.
What is Business Process Modeling (BPM)?
When designing a system (or a process), it is a good practice to model it with all of its activities and states. To do this we use Business Process Management and Notation (BPMN). This way processes can be analysed, improved and automated. The beauty (for us developer folks) is that BPM is typically done by a business analyst. This, in turn, means that we start to code only when the entire process has been described and analysed.
To start using BPM, lets first go through BPMN and see what its building blocks are.
Business Process Modeling and Notation (BPMN)
Most people process data in a visual way, that is why we create graphs to represent data in tables since it allows us to "feel" and see the data. The same can be said for BPM, you could describe it by words, and for some, it would be enough. The N part of BPMN gives us standardised tools to visualise this process making it much more interesting than the mere text. The basic elements of BPMN are shown in the following picture.
BPMN building blocks
I won't go through all the BPMN elements and in details because there are so many that I feel if we go down that road it would be tiresome. I will only list the basics, and it is for you to decide where to go after this.
Events
In BPMN there are three types of events. Start Events, Intermediate Events and End Events. All of these can be catching and throwing events. Intermediate events can also be used as boundary events on tasks in which case they can be interrupting or non-interrupting.
Catching events are events with a defined trigger. They are started once the trigger has activated or fired. Catching events may result in:
- The process starting
- The process or a process path continuing
- The task currently processed or the sub-process being cancelled
- Another process path being used while a task or a sub-process executes
Throwing events are triggers for catching events and are triggered by the process. Throwing events can be:
- Triggered during the process
- Triggered at the end of the process
Boundary events can be attached to tasks (or subprocesses) which do not explicitly require waiting but do interrupt our activities.
Activity
Task
Tasks are activities where the logic of our process resides, BPMN defines several types of tasks:
- User Task - used to model work that needs to be done by a candidate
- Service Task - these tasks are programmed by developers, and are executed automatically as soon as they are eligible for execution
- Send Task - used to send a message
- Receive Task - a simple task that waits for the arrival of a certain message
- Manual Task - defines a task that is external to the BPM engine
- Business Rule Task - used to synchronously execute one or more rules
- Script Task - is an automated activity, when a process execution arrives at the Script Task, the corresponding script is executed
Task candidates
Users usually interact with the process through User Task. Users can run a task if they are listed among candidates for that task, or if they are members of one of the groups listed as candidate group.
Subprocess
Sub-process is embedded process within the original process definition.
Call Activity
Call activity references a process that is external to the process definition.
Multiple instances
If we want to define a repetition of a certain step in the process we can identify it as a multi-instance activity. They can be run in parallel (indicated by three vertical lines) or in sequentially (indicated by three horizontal lines). A Gateway or Event can not become multi-instance.
Gateways
Gateways control flow in a process. They allow modelling decisions based on data and events as well as fork / join concurrency. They are the following:
- Exclusive Gateway - used to model a decision in the process
- Parallel Gateway - used to model concurrency in a process
- Inclusive Gateway - a combination of an exclusive and a parallel gateway
- Event-Based Gateway - allows us to make a decision based on events
Flow
By connecting the BPM elements we are creating a flow of our process.
Putting it all together
Now that we introduced ourselves with building blocks let's look at this simple example:
This process describes the ordering of pizza. The first thing that a BPM system needs to do is to start a process indicated by Start Event Order received. Service Task Persist Order is executed automatically from its name. We can deduce that it will persist the order in some way (depending on how it is programmed). After that, the order needs to be approved, and this is done by User Task Approve Order. It is followed by Exclusive Gateway, and our "flow" splits in two ways. Depending on Approve Order task outcome system will either execute Service Task Send Rejection Email or wait for User Task Prepare Pizza, both of which are resulting in an End Event.
In these cases, all Service Tasks must have implemented logic, and User Tasks need to have properties we want the user to enter.
Camunda BPM
To execute the scenario above, we need some kind of a platform. There are many which do this, and since we are using Java, we chose Camunda. It was a fork of Alfresco’s Activity done by key engineers that resign from Alfresco.
What does Camunda bring to the table?
First of all, it gives us model execution engine that supports Object Management Group (OMG) standards BPMN 2.0 for process automation. So in short Core Engine can take BPMN (i.e. Pizza Order) and execute it. Second of all, it comes with a nice Modeler that can be used to create BPMN processes.
Camunda can be deployed on a variety of platforms, and fortunately, Wildfly is one of them. We can use Camunda to manage the process in its entirety (GUI, users, ...), and using this approach we only write logic for Service Tasks and configure User Tasks. A platform will do the rest.
We can use it in our own application contacting Camunda's API to create and manage processes and tasks. This integration can be done over REST API or by using Java API.
Versioning
One thing that fascinated me was the fact that you can redeploy a process, and by doing this you are changing its version. Process engine supports this in the following way:
- If you re-deploy a changed process definition, you get a new version in the database.
- Running process instances will continue to run in the version they were started in.
- New process instances will run in the new version - unless specified explicitly.
- Support for migrating process instances to new a version is supported within certain limits.
You can see that this provides us with the flexibility to do almost anything, even if we change the process at some point.
Conclusion
One thing I would like to mention is that when I first met with BPM in the form of Activity BPM, it looked like too much of a hassle to implement. But as I’ve started to work with it I saw that benefits far outweigh the initial cost of introducing BPM into a project.
Naturally, it is for you to decide if your process is either complex enough or is being modified that it would warrant an introduction of BPM.
I would leave you with one thought: if you look at BPMN processes (similar to our pizza order), do they make more sense that a series of if-then elses. And if you weren’t technically inclined would it be easier for you to understand, and even change what is happening using BPMN approach.
Now, taking all this into account, maybe in your next project, you will consider BPM.
