Process Engine Internals
The tSM Process Engine combines BPMN/DMN standards with an embedded, tSM-maintained runtime and product-specific extensions. This page explains the architectural guarantees tSM preserves, the runtime lineage, and how the engine foundation and imported source components are maintained.
BPMN and DMN Foundation
tSM uses BPMN XML as the process-definition contract and supports standard BPMN constructs for processes, tasks, events, gateways, messages, timers, and subprocesses. DMN is used for decision models. Definitions can be imported and exported for use with external modeling tools.
tSM extensions use the tsm namespace for capabilities such as task definitions, statuses,
transitions, privileges, skills, configuration profiles, listeners, and task templates. Camunda
extension elements are also used where the embedded runtime provides the corresponding semantics.
A BPMN file therefore contains two layers:
- portable BPMN/DMN structure;
- executable tSM configuration and expressions that must be validated in the target environment.
tSM-maintained Camunda 7 Fork
The runtime is based on the Camunda 7/Activiti lineage and is maintained as a tSM product fork. tSM integrates the engine with its current Java/Spring platform, SpEL execution, Public APIs, task model, identity, history, observability, and configuration lifecycle.
The fork gives tSM direct ownership of the runtime and allows the product to:
- keep a stable embedded runtime for supported product versions;
- select compatible corrections and improvements from the wider successor ecosystem;
- apply relevant security and maintenance patches to supported branches;
- preserve tSM-specific behavior and customer process compatibility;
- evolve process capabilities without forcing a separate orchestration platform into every installation.
Exact engine and dependency versions are release-specific and are maintained as part of the tSM platform build.
Embedded Runtime Architecture
The engine runs inside each participating domain microservice rather than in one mandatory central cluster.
The target module is configured by Process Type. Deploying a definition installs it into the target service. Runtime instances, jobs, tasks, incidents, and local history belong to that service's process schema.
Why tSM Keeps the Engine Embedded
The embedded model is an intentional product guarantee:
- Local transactional integrity — process state and related business changes can share one service transaction between wait states.
- Low-latency local work — service tasks can call certified tSM services and SpEL without a network round trip.
- Failure isolation — participating microservices own their runtime, schema, scaling, and operational boundaries.
- Product integration — tSM tasks, statuses, forms, privileges, skills, history, and process modification remain first-class capabilities.
- Customer deployment control — the process runtime is part of the same supported application topology.
Cross-service or long-running work still uses explicit boundaries: External Tasks, Kafka Tasks, messages, timers, user tasks, idempotent APIs, and SAGA compensation.
tSM Runtime Enhancements
Human work
- user/group/team assignment and skill-based matching;
- task statuses, transitions, forms, conditions, and privileges;
- WFM integration and task lifecycle APIs;
- process/task configuration profiles and reusable templates.
Automated work
- SpEL expressions and script bindings;
- service, external, Kafka, messaging, and timer task patterns;
- dynamic process selection and entity-linked business keys;
- asynchronous transaction boundaries, retries, incidents, and process modification.
Platform integration
- tSM identity and authorization instead of engine-managed users;
- Public API and controlled process APIs;
- relational or Elasticsearch-backed history according to deployment policy;
- distributed tracing, correlation, logging, and operational metrics;
- versioned configuration, deployment, and running-instance migration checks.
Maintenance and Security Policy
tSM owns and maintains the fork as part of the supported product. The engineering process includes:
- monitoring security advisories, fixes, and maintenance changes across the Camunda-7 lineage;
- assessing relevance to tSM's embedded usage and supported deployment stack;
- integrating or backporting compatible changes into supported tSM branches;
- running regression tests over BPMN/DMN, active instances, tSM extensions, transaction behavior, tasks/workers, history, incidents, migrations, and supported databases;
- publishing applicable fixes through the normal tSM release and security process.
This approach allows tSM to keep the embedded architecture while several independent long-term continuation projects evolve.
Continuation and Related Engine Ecosystem
tSM follows several active projects and selectively incorporates relevant work.
| Project | Current relevance |
|---|---|
| Operaton | Community-led Camunda-7 continuation focused on compatible embedded execution, current Java/Spring support, and migration tooling |
| CIB seven | Camunda-7 continuation with community and commercial support/LTS/OEM options and an embedded model |
| FINOS Fluxnova | FINOS-governed continuation; current releases emphasize a modern Java/Spring/Jackson stack, monitoring, restricted variables, ad-hoc subprocesses, and AI/MCP plugins |
| Flowable | Related Activiti lineage and a broader BPMN/DMN evolution and replatforming reference |
tSM supports the current runtime through its own maintained fork while these projects evolve. When one continuation demonstrates the strongest long-term stability, security governance, support model, embedded compatibility, and product fit, tSM can align the maintained fork more directly with it through the normal product qualification process while preserving tSM behavior.
Agentic Automation Source Integration
The 2.5 agentic implementation uses selected source patterns and components available under the
Apache License 2.0 from the
FINOS Fluxnova plugins repository
as an engineering starting point. The reviewed baseline is pinned to commit 2a9079e; later changes
are imported only after source, license, security, compatibility, and regression review.
Two upstream capabilities are especially relevant:
- process start events published as MCP tools,
evaluated as an internal source pattern for invocation and correlation; the tSM public inbound
contract is instead one general A2A Script Binding with
DIRECTandTASKmodes; - engine-native orchestration of an ad-hoc agentic subprocess, used as the starting point for the tSM Agentic Subprocess execution loop.
Imported code becomes part of the tSM-maintained fork and is adapted to tSM namespaces, build, configuration lifecycle, security model, Agent Runtime, and supported platform versions. tSM's published configuration and runtime contracts remain the product interface.
tSM hardening and productization
| Starting capability | tSM product contract |
|---|---|
| Start-event tool discovery | Stable versioned Tool ID, typed JSON Schema, explicit input mapping, additionalProperties: false, authorization, tenant scope, idempotency, risk class, and restart-safe registration |
| Whitelisted process context | Certified context providers, field-level data policy, size limits, redaction, immutable execution snapshot, and no credentials or unrestricted variable map |
| Model-selected ad-hoc activities | Explicit Agent Tool manifest with typed arguments and outcomes, per-tool authorization, resource locks, approval policy, timeout, retry, and compensation metadata |
| Persisted orchestration callback | Durable AgentRun, AgentTurn, AgentToolCall, ApprovalDecision, and usage ledger with small references in process variables |
| Multiple Tool Calls | Bounded parallel scheduler, dependency/resource conflict checks, deduplication, repetition controls, late-result handling, and stable idempotency keys |
| Model conversation history | Token-aware context compaction, artifact references, retention policy, encryption, and model/provider-independent audit events |
| Provider tool calling | tSM Agent Profile, model routing, DLP, schema validation and bounded repair, token/cost telemetry, evaluation version, and tenant kill switches |
| Inbound MCP transport | Gateway authentication, per-tool discovery authorization, rate limits, input filtering, audit correlation, and safe error mapping |
The runtime enforces limits and security in code. The engine enforces maxModelCalls, Tool Call
totals and per-turn limits, parallelism, wall-clock
deadline, token/cost budget, allowed activities, approvals, and final-outcome validation before the
process can continue.
Agent-to-Agent support uses two tSM product adapters aligned with A2A Protocol 1.0. The outbound
client in tsm-ai resolves registered agents, persists a local invocation projection, normalizes
stream/push/poll updates, and maps remote Tasks, Messages, Artifacts, interrupted states, and
cancellation onto durable BPMN responses. The Process Engine applies state mappings and an optional
custom response listener. The remote server remains authoritative for its Task.
The inbound A2A server adapter in tSM Gateway uses the general Script Binding: DIRECT returns the
Script result, while TASK creates a Gateway-owned durable Task and transferable replyRef. A
process, ticket, Kafka consumer, or integration may carry the reference and explicitly call the
SpEL @a2a.reply binding. That explicit reply is the authoritative progress and completion
contract. Both adapters are tSM product capabilities beside the imported process-source patterns;
Gateway is not used for outbound A2A.
Every imported revision retains required copyright and license notices and is recorded in the source-provenance inventory. Qualification includes restart discovery, duplicate delivery, optimistic locking, delayed callback, tenant isolation, authorization, budget exhaustion, compensation, active-instance compatibility, and supported-database tests.
External Orchestrator Integration
Camunda 8 uses a remote, distributed runtime rather than the embedded Camunda-7 execution model. Its agentic orchestration, connectors, MCP, operations, testing, and optimization patterns are useful design references for tSM.
tSM preserves its embedded runtime architecture. A customer-operated Camunda 8 or another orchestrator integrates through Public API, External Tasks/workers, Kafka, messages, MCP, or a dedicated adapter, with each platform retaining its own transaction and lifecycle boundary.
Stable Product Boundaries
tSM continues to strengthen engine-independent use-case contracts around:
- deploy and version a definition;
- start and correlate an instance;
- claim, complete, or fail work;
- inspect and resolve an incident;
- modify or migrate an instance;
- read runtime and history data;
- invoke an external worker or durable business process.
These contracts make integrations and future engine alignment controlled product engineering. They also provide the foundation for Agentic Process Automation.