9 posts tagged with "Engine"

BPMN engines can look intimidating at first. There are process diagrams, several kinds of events and tasks, gateways, variables, integrations, and a whole ecosystem of concepts that make it hard to know where to start.

This article goes back to basics. First, how a BPMN engine actually runs a process. Then, more importantly, what you can build with one: from simple workflows to processes involving data, external systems, and automation.

Let's start with the basics.

You have a business process. It is long-running, it has human steps, it needs an audit trail, and it lives in a Node codebase. Search for how to run BPMN from TypeScript and you get two kinds of answer: a JVM platform, or a diagram renderer that does not execute anything.

There are three real ways to run a BPMN workflow engine from JavaScript or TypeScript, and they differ on one axis that matters more than any other: where you pay for durability.

You have a booking flow that reserves a hotel, then charges a card, then books a flight. The flight step fails. Now what? The hotel is reserved and the card is charged, but there's no trip. You can't ROLLBACK: those were three separate services, three separate transactions, already committed. Someone has to walk the whole thing back: refund the card, release the hotel, and do it in the right order.

That walk-back is the saga pattern, and most teams hand-roll it: a pile of try/catch, a list of "things I've done so far," and a reverse loop that's wrong the first three times you write it. BPMN compensation is the saga pattern as a first-class engine feature: you declare each step's undo action, and the engine handles the reverse-order rollback, the data snapshots, and the recursion for you.

A question that comes up surprisingly often: "we're picking a workflow tool - should we use Airflow, Prefect, or a BPMN engine?" The fact that it's even a question is interesting, because the three tools are genuinely solving different problems. The confusion comes from the shared word "workflow", which has been overloaded into uselessness.

Short answer: Airflow, Prefect, and Dagster are DAG-based data orchestrators. BPMN engines are business-process engines. They look similar from far away and feel completely different up close. This post is about the difference and how to pick.

n8n is a popular open-core (under the Sustainable Use License) workflow automation tool. It's a node-based visual editor with a large library of pre-built integrations, designed for connecting SaaS APIs, automating internal tasks, and replacing the kind of glue code that used to live in cron jobs and shell scripts. Most teams that adopt n8n do so to get something working in a day instead of a sprint - and that's exactly what it's good for.

It's also a tool that teams outgrow in a specific, predictable way. This post is about that ceiling: where n8n stops being the right answer, and what changes when you move to a BPMN engine.

If you're building anything stateful and long-running on the JVM, in Go, or in TypeScript, Temporal has probably crossed your desk. It's the de-facto durable execution platform - Uber, Snap, Coinbase, HashiCorp, Stripe, Datadog and a long tail of others run production workloads on it. The natural question, when someone hands you a "build a workflow engine" requirement, is: do I just use Temporal, or do I need a BPMN engine?

Short answer: both can be right. The dividing line is who the model belongs to. This post explains why we built QuantumBPM on top of Temporal rather than competing with it, and how to decide which level you should be writing your workflow at.

BPMN - Business Process Model and Notation - is the OMG standard for diagramming business processes. It defines a visual language (rectangles for tasks, diamonds for gateways, circles for events) and an XML serialisation. Modern BPMN engines treat the diagram as something directly executable - the same model a business analyst draws is what the engine runs.

The BPMN 2.0 spec defines well over a hundred symbols. The honest truth is that you'll use about fifteen of them in 90% of real processes. This post walks through that core, then explains how a BPMN model actually executes.

BPMN and DMN are two of the most-cited OMG standards in business automation, and they're often confused. The short version: BPMN models processes over time. DMN models decisions at a point in time. They're complementary, not competitors. Most non-trivial systems end up using both.

This post walks through what each standard is, where each one fits, the boundary between them, and a worked example of the two working together.

When we started designing QuantumBPM's process engine, we ran into the same wall every workflow tool runs into: how do you make execution durable? Survive worker crashes, network partitions, weeks-long timers, replay after restart, exactly-once activity semantics? The honest answer turned out to be: don't build that yourself.

This post is about the bet we made - running BPMN on top of Temporal - what it cost us, what it bought us, and why we think Temporal developers are the audience that benefits the most from a BPMN layer sitting above their existing investment.