Mozart - a BPM platform written in Elixir

Mozart (mozart), an Elixir based BPM platform has been published to Hex. You can find it in GitHub at https://github.com/CharlesIrvineKC/mozart. Please have a look at the project readme file for more information.

If you aren’t that familiar with BPM, here are some good articles:

Here are some articles on the benefits of BPM:

Here are some links to some commercial BPM platforms:

Thanks

16 Likes

Preliminary ExDoc module and function documentation has ben generated and is available via hexdocs. Working on guides next.

Announcing the release of Mozart version 0.2.0.

From the project readme:

What is Business Process Management

See Introduction to BPM in hexdocs to get a basic understanding of Business Process Management (BPM).

Documentation

View documentation for Mozart in hexdocs at https://hexdocs.pm/mozart/api-reference.html

Introduction

Mozart is an open source BPM platform written using Elixir. Process models are defined using a set of Elixir structs providing a modelling language which is somewhat inspired by AWS Step Functions. See AWS Step Functions.

The most distinguishing feature of Mozart is that each business process model is executed in a GenServer instance, made possible by the well known character of Elixir (and Erlang) multi-processing.

Another important feature is that process models are not graphically constructed using BPMN2. Instead, they are textually represented by struct based Elxir data structures. This makes BPM, hopefully, just another tool in the software developers toolkit.

Current Use Cases (and Non Use Cases)

  • Elixir development teams wanting to explore and potentially implement exploratory BPM applications.
  • Non Elixir development teams having the goal of exploring and experimenting with Elixir.
  • Mozart is not ready for major enterprise BPM projects.
  • Mozart is not a low code or no code platform suitable for non developers.

I am pleased to announce version 0.3.0 of Mozart - an Elixir BPM platform.

The really big new feature is a DSL for defining business process applications. Elixir developers can develop BPM applications just by writing Elixir code. No external tools are required. I don’t believe this is currently possible with any other programming language.

Here is a relevant excerpt from the project readme filed:

===========================================================

Two Features Made Possible by Elixir

A Domain Specific Language (DSL) for BPM Applications

Elixir provides programmers with the ability to seemingly extend Elixir itself by creating domain specific programming idioms.

In the case of Mozart, this means that programmers can create BPM applications by using BPM specific programming constructs mixed with otherwise everyday Elixir code. Here a very simple but complete example:

defmodule MyBpmApplication do
  use Mozart.BpmProcess

  def sum(data) do
    %{sum: data.x + data.y}
  end

  defprocess "add x and y process" do
    service_task("add x and y task", function: &MyBpmApplication.sum/1, inputs: "x,y")
  end

end

This module can be used as-is to start and execute a BPM process engine as shown below. (A small quanity of system output was removed to improve clarity.)

iex > ProcessService.load_process_models(MyBpmApplication.get_processes())
iex > {:ok, ppid, uid, _key} = ProcessEntine.start_process("add x and y process", %{x: 1, y: 1})
[info] Start process instance [add x and y process][b82f5da1-6e5d-44df-b4ed-9064b877e484]

iex > ProcessEngine.execute(ppid)
[info] New service task instance [add x and y task][f396a252-fba4-4804-9fdd-360a6c24ed54]
[info] Complete service task [add x and y task[f396a252-fba4-4804-9fdd-360a6c24ed54]
[info] Process complete [add x and y process][b82f5da1-6e5d-44df-b4ed-9064b877e484]

iex > ProcessService.get_completed_process_data(uid)
%{sum: 2, y: 1, x: 1}

Conversely, with Mazart, process models are not graphically constructed using a visual programming environment typical of most of current BPM development. We believe that this kind of development is avoided by a substantial segment of the software development community and in some instances is not condusive to CI/CD developmemnt processes.

However, visual BPM modelling tools are highly regarded by business process analysts and the resulting graphical process depictions are highly readable by developers and process analysts alike. So, it was essential that the DSL developed produce process models that are as readily understood by process analysts as are BPMN2 process models. We hope you will think we have been reasonably successful achieving this goal.

We anticipate that BPMN2 tools will still be used by Mozart development teams, but only for analysis and documentation. Actual BPM process models will be created with the Mozart BPM DSL.

A Process for Each Business Process

Another distinguishing feature is that each business process model is executed in a separate Elixir process (GenServer) instance. This is possible due to Elixir’s (and Erlang’s) unique capacity for highly performant, fault tolerant and massively concurrent multi-processing.

The goal is extremely fast and relable business process model execution. We will be publishing performance metics in the near future to gage Mozart’s performance charateristics. Initial results look very promising.

===========================================================

Any feedback will be appreciated.

2 Likes

Hello,

Is the aim to build something similar to https://flowsforapex.org/ at the end ?

The goal was to be able to create executable business process models using the Mozart DSL, that is “plain old Elixir code”, instead of a graphical modelling tool. That goal has been mostly met, except for whatever bugs or gaps that might be lurking.

There will still be the need for GUIs, notably one for user task assignment and completion and one for monitoring and trouble shooting.

After many years of doing BPM development I know that a lot of programmers avoid BPM’s graphical modeling tools. They are the target audience.

Process analysts and business folks like the graphical tools and should continue to use them even for Mozart development. When the models are handed off to the development team, they would be converted to the Mozart DSL.

Released version 0.3.2.

Bug fixes and repeat task added.

Released v0.4.0

Breaking Changes:

  • Cleaned up the syntax for case_task and parallel_task. The old syntaxes will no longer compile. Should just take a few minutes to modify each task instance.

New:

  • Added defevent/3 DSL function. Just task exit event currently supported. Roughly equivalent to boundary events in BPMN2. Anticipate a few more event types.

What reception have you received from the business community? I ask as someone who did not enjoy my forced engagement with with Appian in the way past.

There’s been no reception at all from the business community and I’m not surprised. Most of the information that I have communicated so far would only be of interest to programmers. And maybe especially to programmers like yourself who didn’t like developing with the current BPM platforms (if I understood you correctly).

However, in general, business folks are very, very receptive to Business Process Management (BPM) tools. They are very familiar with all of their respective business processes and they know how important the quality and the speed of those processes are. I have presented BPM tools to the business side of companies many times, and I can’t remember one time when they didn’t enthusiastically buy in to the idea.

By the way, I looked at your profile. You might be interested in my other Elixir project.

1 Like

Status Update

Currently at version 0.4.3, Mozart is now functionality-complete. I don’t anticipate making any breaking changes in the near future. I will address any bug reports or small enhancements opened GitHub.

Mozart can be used now for service orchestration. If you Google for service orchestration BPM you will find numerous articles on the subject. Here is an interesting one.

You could also use Mozart for business processes with people in the loop, but only if you develop an end-user GUI for doing so. This is actually a common practice with the well known Camunda BPM platform.

For now, I’m going to shift my efforts to implementing an end-user Phoenix LiveView POC for starting processes and completing open user tasks.