DEV Community: Ghofrane WECHCRIA

OrqueIO: Fully Independent Platform

Ghofrane WECHCRIA — Thu, 18 Jun 2026 09:14:11 +0000

Introduction

Enterprise orchestration is evolving. As systems grow more distributed and performance expectations increase, platforms must do more than remain stable — they must adapt on a sustainable architectural foundation.

OrqueIO was introduced as a Camunda 7-compatible fork to ensure continuity and protect enterprise investments. That objective was achieved. However, the AngularJS-based frontend, built on a framework reaching end-of-life, gradually became misaligned with modern development standards. The challenge was not reliability, but long-term architectural viability.

Incremental fixes were not sufficient. Remaining within inherited constraints would have limited extensibility and slowed innovation. We therefore chose a structural modernization: a full frontend re-architecture with Angular 21, backend alignment with Spring Boot 4 and Java 25 readiness, and native SSO integration.

This was not a routine upgrade, but an architectural reset designed to remove technical debt and establish a foundation built for long-term evolution.

Before & After: What Actually Changed

The comparison between the AngularJS interface and the new Angular 21 frontend makes the transformation immediately visible. While the previous version reflected legacy patterns and architectural constraints, the redesigned frontend delivers clear structural improvements:

Clearer information hierarchy
More intuitive navigation
Improved responsiveness
A modern component-based architecture

This evolution goes beyond visual refinement. It aligns user experience, performance, and maintainability with contemporary enterprise standards, reinforcing the platform’s structural modernization.

A Reinvented Login Experience

The authentication interface was redesigned to deliver a cleaner structure, stronger visual identity, and improved usability. The new layout enhances clarity while aligning with modern enterprise UX standards.

A Modernized Welcome Interface

The new welcome page transforms a static layout into a visually structured entry experience. Clear hierarchy, refined spacing, and dedicated application cards improve orientation and reinforce the platform’s modern identity from the first interaction.

Enhanced Operational Visibility

The Cockpit dashboard has been refined to improve metric organization and monitoring clarity. Enhanced layout structure and improved visual grouping make it easier to navigate between process instances, incidents, and deployments while maintaining functional continuity.

Enhanced Process Visibility

Process monitoring now offers improved readability, structured filtering, and clearer execution tracking. The interface reduces cognitive load while increasing operational transparency.

Clearer Decision Insights

Decision tables and execution results are presented with improved layout and contextual clarity. The updated interface strengthens analysis efficiency and simplifies validation workflows.

Streamlined Task Operations

Task handling has been redesigned for better focus and usability. Improved layout and structured panels allow users to manage workflows more efficiently with fewer interactions.

Modernized Administration Experience

The administration view evolves from static sections to a structured, metrics-driven interface. User, group, and system management are now clearer, faster, and more scalable.

These examples highlight key interface changes, but they represent only part of the modernization effort.

You can explore the updated UI and evaluate additional workflows by running OrqueIO projects in your own environment and testing real use cases.

Technical Challenges Behind the Migration

Migrating a legacy AngularJS frontend to Angular 21 is not a linear upgrade path. It is effectively a re-engineering effort.

Several structural challenges had to be addressed:

1. No Direct Upgrade Path

AngularJS and modern Angular versions are fundamentally different frameworks. There is no seamless migration bridge. Controllers, scopes, and dependency injection patterns required full refactoring into component-based architecture.

2. State Management Redesign

AngularJS relied heavily on implicit scope propagation. Migrating to Angular 21 required explicit state management strategies, clearer separation of concerns, and reactive patterns.

3. UX Without Breaking Behavior

Enterprise users rely on stable workflows. While redesigning the UI, behavioral consistency had to be preserved to avoid operational disruption.

4. Technical Debt Extraction

Not all technical debt can be removed instantly. The migration required careful prioritization:

What to refactor immediately
What to stabilize
What to isolate

This was not a cosmetic redesign. It was a controlled architectural transition.

Conclusion

The migration from AngularJS to Angular 21 marks a structural milestone for OrqueIO.

What started as a compatibility-driven fork has evolved into a platform with architectural ownership and technical independence.

Modernization was not optional. It was necessary to ensure sustainability.

OrqueIO is now positioned not only to maintain continuity — but to evolve deliberately.

Want to see how OrqueIO can transform your operations management?

📩 Contact us at contact@orqueio.io to schedule a personalized demo
or visit our official website: www.orqueio.io/contact

📚 Resources :
Documentation: https://docs.orqueio.io

What is the best Camunda 7 compatible alternative in 2026?

Ghofrane WECHCRIA — Mon, 08 Jun 2026 14:43:59 +0000

Camunda 7 Community Edition officially reached end of life in October 2025. For the thousands of engineering and operations teams that built their workflow automation on it, the question was never really whether to act, it was which path made sense ?

Many organizations have invested years building on Camunda 7 Community. They have BPMN processes in production, DMN decision tables, integrations, and entire operational teams built around the platform. For them, the end of official support did not make that investment disappear. It created a new question: which compatible solution should they move to?

Today, several Camunda-compatible solutions are available on the market. They allow organizations to continue running their existing BPMN and DMN workflows, benefit from active maintenance and enterprise support, and keep full control over their platform without disruption.

This article compares the three leading compatible solutions available in 2026: OrqueIO, Operaton, and CIB seven.

Comparing the three solutions : OrqueIO, Operaton and CIb seven

Each one reflects a different way of responding to Camunda 7 end of life.

1. OrqueIO

OrqueIO was born in 2025 as a Camunda 7 compatible solution, but it was designed from the start to be much more than that.

The platform maintains full compatibility with existing BPMN and DMN workflows, allowing organizations to continue operating without any disruption. But compatibility is just the foundation. OrqueIO is an actively evolving product, with a rich roadmap and a long-term vision for workflow orchestration. Everything remains open-source, with a single version available for everyone : no enterprise tier, no paid features, no exceptions.

OrqueIO comes with Long Term Support until 2032, giving organizations the planning horizon they need to build confidently on the platform.

Behind OrqueIO is CodeOnce, a French company with over 6 years of hands-on experience deploying and maintaining Camunda 7 in production for large French enterprises, including Carrefour, Galeries Lafayette, and La Poste.

Beyond the platform itself, OrqueIO gives organizations access to a team of experienced architects and BPMN experts who can support them at every stage, from development and integration to production operations. Whether you need hands-on support during implementation, architectural guidance, or a reliable partner for production incidents, the CodeOnce team is available and engaged.

What OrqueIO brings today:

Full compatibility with existing BPMN and DMN processes
A fully rewritten Interfaces built on Angular 21
A standalone OrqueIO Modeler, distributed independently from the Camunda ecosystem
Native OAuth2/OIDC SSO with multi-IdP support ( Google, Keycloack, Github and more)
Spring Boot 4.0.x already supported, with 4.1 planned for June 2026
LTS until 2032 and enterprise support plans backed by a dedicated team
An active and rich 2026 roadmap: Entreprise features, Native Kafka connector, AI integration…
Everything is open-source. No feature is locked behind a paid tier.

Who it’s for: Organizations that want full Camunda 7 compatibility today, with a platform that is actively modernizing and a team that understands the real constraints of large enterprise deployments.

2. Operaton

Operaton was created in 2025, shortly after Camunda’s EOL announcement, by a group of contributors who wanted to ensure a maintained, up-to-date version of the Camunda 7 engine available for everyone.

Operaton is not trying to reinvent the platform. It is a community-led effort focused on keeping the engine alive, applying necessary updates, and security fixes. It does not offer enterprise support, dedicated consulting, or production assistance. The roadmap is driven by community availability and focuses on maintenance and stack alignment.

What Operaton brings today:

Full compatibility with existing BPMN and DMN processes
Security fixes and patch releases
A partial Cockpit rewrite
Spring Boot 4.0.x support, with 4.1 planned for October 2026
SSO via Keycloak plugin

Who it’s for: Teams that can rely on their own internal expertise, are comfortable with community support, and do not require a formal enterprise support model or a clear product roadmap.

3. CIB seven

CIB seven was created in 2024 by CIB Group, a German software company. It takes a more support-oriented path, with LTS and paid plans designed for organizations looking for stability and long-term maintenance.

CIB seven maintains full compatibility with Camunda 7. Beyond that, the platform is actively evolving with a structured roadmap. It operates on a two-tier model: a community edition and a paid enterprise edition. Several features, including advanced support, and parts of the product roadmap, are available exclusively in the entreprise version.

What CIB seven brings today:

Full compatibility with existing BPMN and DMN processes
A partial Cockpit rewrite
Spring Boot 3.5.6, with 4.x migration not yet publicly dated
SSO via plugin-based integration
LTS support and paid enterprise plans
An active 2026 roadmap: Web Modeler, AI features, MCP connections…

Who it’s for: Large enterprises, looking for a commercially backed option with vendor accountability and long-term maintenance guarantees.

Choosing a Camunda 7 compatible platform : Why modernization matters ?

Continuity alone is not enough.

A platform can remain compatible with Camunda 7 and still fall behind in areas that matter to modern enterprise teams: security, user experience, deployment models, maintainability, and support. The three solutions covered in this article have made very different choices on these dimensions.

The differences between these platforms become clear when looking at their priorities. Some focus on preserving the existing Camunda 7 experience with minimal changes. Others emphasize long-term maintenance, support, or platform evolution.

OrqueIO takes a different approach entirely. Full compatibility with Camunda 7 is the foundation, but the platform is built to evolve. Everything is included in a single open-source version, free for everyone, with no features locked behind a paid tier. The roadmap is active and ambitious.

Operaton stays focused on the essential: compatibility, security fixes, and stack updates. No enterprise support, no major feature evolution. It is a community effort with no enterprise support, it’s for teams that can self-manage.

CIB seven goes further, with a structured support model and an active product roadmap. But its evolution is split across two tiers. Organizations that want the full picture will need to factor in a licensing cost.

The table below summarizes how the three solutions compare across the criteria that matter most.

Final takeaway

For teams looking for an open-source compatible Camunda 7 alternative, an independant BPMN/DMN workflow engine with enterprise support, OrqueIO offers a clear direction:

- Keep your BPMN and DMN investments.
- Modernize the experience.
- Move forward without rewriting everything.

And the roadmap makes the future even clearer :

Entreprise Features ( Navigation Subprocess, call activity, reporting, bulk API, etc.)
Native Kafka connector, event-driven orchestration and Saga Pattern as first-class features
AI integration in the BPMN/DMN engine, to automate decisions, optimize task prioritization, and make workflows more adaptive

OrqueIO is not only about keeping Camunda 7 alive.

It is about giving existing BPMN and DMN investments a future-ready path forward.

OrqueIO is open-source and ready to run.

📩 Connect with us on GitHub or talk to the team if you have an enterprise context to discuss : https://www.orqueio.io/contact

Hands-on experience:
🔬 Join OrqueIO Labs to explore, test, and experiment with OrqueIO in a practical environment.

OrqueIO Benchmarking

Ghofrane WECHCRIA — Fri, 17 Apr 2026 13:44:38 +0000

A deep dive into load testing the open-source Camunda 7 fork with Gatling, Kubernetes, and Prometheus

When your business relies on a BPMN engine to orchestrate critical processes, performance is not just a nice-to-have. It is essential. Every millisecond of latency, every failed request, every resource bottleneck translates directly into business impact.

That is why we put OrqueIO through rigorous performance testing. The results speak for themselves.

What is OrqueIO?

OrqueIO is a production-ready, open-source fork of Camunda 7, the industry-standard BPMN 2.0 workflow engine trusted by enterprises worldwide. It was born from the need for long-term support and continuous improvement without costly migrations. OrqueIO preserves full compatibility with existing Camunda 7 processes while delivering enhanced security, stability, and performance.

For teams facing the end of Camunda 7 support or seeking a vendor-independent BPMN solution, OrqueIO offers a seamless path forward.

What is Gatling?

Before diving into the results, let me explain our testing tool. Gatling is an open-source load testing framework written in Scala. Unlike traditional tools that simulate users with threads (which gets expensive at scale), Gatling uses an asynchronous, non-blocking architecture. This means a single Gatling instance can simulate thousands of concurrent users without breaking a sweat.

Why we chose Gatling:

Code-based simulations: Tests are written in Java, making them version-controllable and easy to integrate into CI/CD pipelines
Realistic load patterns: You can ramp up users gradually, hold steady load, or create complex traffic patterns that mirror real-world usage
Beautiful reports: Gatling generates detailed HTML reports with response time distributions, percentiles, and throughput charts
Low resource footprint: Thanks to its async architecture, you can generate massive load from modest hardware

Our test scenario is straightforward: we repeatedly call the OrqueIO REST API to start new process instances. This is the most common and performance-critical operation in any workflow engine.

POST /engine-rest/process-definition/key/{processKey}/start

Each request creates a new BPMN process instance, persists it to the database, and returns the instance ID. Simple, but it exercises the full stack.

The Testing Setup

We designed our load testing infrastructure to simulate real-world production conditions.

Kubernetes Environment:

Amazon EKS cluster
All components deployed in the same namespace for simplified networking
PostgreSQL database running in EKS for consistent latency

Monitoring Stack:

Prometheus for metrics collection
Grafana Alloy for scraping container metrics
Real-time CPU and memory tracking during test execution

Load Testing Pipeline:

Gatling packaged in a Docker container
Jenkins for orchestration and parameterized test runs
Automatic report upload to S3

The entire setup is automated. We can spin up a test, adjust pod counts, change resource limits, and compare results across configurations with just a few clicks.

The Testing Infrastructure

We built a fully automated testing pipeline that anyone can replicate. Here is how all the pieces fit together:

The Flow:

Trigger: A developer kicks off a Jenkins build, either manually or on a schedule.
Parameters: Jenkins prompts for test configuration. How many pod replicas? What CPU and memory limits? How long should the test run? How many users per second?
Build: Jenkins builds the Gatling Docker image and pushes it to Amazon ECR.
Scale: Before the test starts, Jenkins uses kubectl to scale the OrqueIO deployment to the desired replica count and applies the specified resource limits.
Deploy: Jenkins deploys the Gatling container as a Kubernetes Job in the same namespace as OrqueIO.
Execute: The Gatling pod hammers the OrqueIO REST API with HTTP requests. OrqueIO processes each request and persists data to PostgreSQL.
Monitor: Meanwhile, Grafana Alloy scrapes CPU and memory metrics from all pods and pushes them to Prometheus.
Collect: When the test finishes, the Gatling pod queries Prometheus for resource usage during the test window, bundles everything into a report, and uploads it to S3.

Gatling in Docker: We packaged Gatling in a container along with scripts that automatically query Prometheus during test execution. When a test finishes, we capture not just the Gatling metrics but also the actual CPU and memory consumption of the target pods.

Jenkins Pipeline: Our Jenkins jobs accept parameters for pod count, CPU limits, memory limits, and test duration. This lets us quickly run comparison tests across different configurations without manual intervention.

Prometheus Integration: During each test, we collect container metrics in real time:

CPU usage via container_cpu_usage_seconds_total
Memory usage via container_memory_usage_bytes
Per-pod breakdowns for debugging hotspots

Everything gets uploaded to S3 at the end of each run, so we have a historical record of every test.

Benchmarking:

We ran three tests with different configurations to understand how OrqueIO behaves under various conditions:

Test 1: Single Pod Baseline
Configuration:

1 Pod replica
CPU: 500m request / 2000m limit
Memory: 512Mi request / 1Gi limit
Load: 10 requests per second for 1 minute (600)

Benchmark:
Gatling Report:

Interpretation:

Resource Consumption:

CPU: 0.031 cores average
Memory: 323 MB stable

What this tells us:

The single pod handled all 600 requests with zero failures. The minimum response time of 37ms represents the true baseline , when a request hits the pod with no GC activity. That is impressive for a full BPMN create, database persist, and response cycle.

The interesting story is in the tail latency. Look at the gap between P95 (72ms) and P99 (478ms) : a 6x jump. This is the classic signature of JVM garbage collection. Most requests fly through quickly, but roughly 1 in 100 gets caught waiting for GC.

The resource numbers tell us something important: the pod used only 0.031 cores (6% of requested) and memory sat stable at 323 MB. This pod is not struggling with capacity. It is struggling with GC pauses that happen regardless of load.

Test 2: Horizontal Scaling with 3 Pods

Configuration:

3 Pod replicas
CPU: 500m request / 2000m limit per pod
Memory: 512Mi request / 1Gi limit per pod
Load: 10 requests per second for 1 minute (600)

Benchmark:
Gatling Report:

Interpretation:

Resource Consumption:

CPU: 0.101 cores total (about 0.034 per pod)
Memory: 330 MB per pod

What this tells us:

We tripled the pods but kept the same load. The improvements go far beyond what simple load distribution would explain.

The minimum dropped from 37ms to 34ms : even the best-case benefits from reduced contention. But the real story is tail latency: P99 went from 478ms to just 60ms, an 87% improvement. Maximum response time fell from 758ms to 116ms.

Why? When one pod pauses for GC, the load balancer routes requests to the other two pods. The probability that all three pause simultaneously is tiny.

Most importantly, standard deviation collapsed from 68ms to just 7ms. The system became predictable. Each pod used about 0.034 cores and 330 MB — nearly identical to the single pod test. We did not waste resources. We simply distributed the workload and let each JVM breathe.

Test 3: Sustained Load (2-Hour Endurance Test)

Configuration:

1 Pod replica
CPU: 500m request / 2000m limit per pod
Memory: 512Mi request / 2Gi limit per pod
Load: 10 requests per second for 2 hours

Benchmark:
Gatling Report:

Interpretation:

Response Time Distribution:

Under 800ms: 71,971 requests (99.96%)
800ms to 1200ms: 28 requests (0.04%)
Over 1200ms: 1 request (0.001%)
Failed: 0 requests (0%)

Resource Consumption:

CPU: 0.040 cores per pod average
Memory: 320 MB per pod average, 450 MB per pod peak

What this tells us:

This is the real test. Two hours of sustained load, 72,000 process instances created, and not a single failure. That is production-grade reliability.

The latency profile stayed remarkably consistent with the short test. Minimum response time actually improved to 32ms, and P99 held steady at 65ms. Even after 2 hours, 99.96% of requests completed in under 800ms.

The 1509ms maximum and the 29 requests over 800ms represent rare GC pauses — about 0.04% of traffic. For most applications, this is perfectly acceptable.

Memory tells an interesting story. Each pod averages around 320 MB. Under sustained load, the heap grows as request objects are created, peaking at around 450 MB per pod, then shrinks after garbage collection runs. This sawtooth pattern is exactly how a healthy Java application behaves. No leaks, no OOM kills, no memory pressure. The 2Gi limit gave plenty of headroom for GC to work efficiently.

Key Performance Insights

1. GC Pauses are Solvable Through Architecture

The gap between P95 and P99 in single-pod deployments reveals the cost of garbage collection. But you do not need exotic GC tuning. Running multiple pods lets the load balancer route around pauses naturally.

2. Horizontal Scaling Pays Compound Dividends

Tripling pods gave us more than 3x benefit in tail latency. You get fewer pauses (less load per JVM) AND better handling of remaining pauses (redundancy). These benefits compound.

3. Memory is Stable and Predictable

All tests showed consistent memory usage around 320–330 MB per pod, peaking at 450 MB under load. No memory leaks, no accumulating state. A 512Mi request with 2Gi limit is appropriately sized.

4. CPU is Not the Bottleneck

At 0.03 cores per pod, CPU utilization is negligible. This is typical for IO-bound applications. You can pack OrqueIO pods densely on your nodes.

5. The Database Keeps Up

With response times in the 40–50ms range including database round trips, PostgreSQL has plenty of headroom. Our PostgreSQL pod (500m CPU, 512Mi memory) handled 72,000 inserts over 2 hours without breaking a sweat. The latency spikes come from JVM pauses, not database contention.

Conclusion

OrqueIO proves that open-source BPMN engines can deliver enterprise-grade performance. With sub-50ms median latency, linear scaling characteristics, and predictable resource consumption, it is a compelling choice for organizations seeking a sustainable, high-performance workflow automation platform.

The transition from Camunda 7 to OrqueIO is not just about maintaining compatibility. It is about building on a solid foundation with a clear path forward.

Resources:

OrqueIO Official Website: https://www.orqueio.io
OrqueIO Documentation: https://docs.orqueio.io

Have you tested OrqueIO in your environment? We would love to hear about your experience. Drop a comment below or reach out on GitHub.

Migrate your Drools rules to OrqueIO DMN

Ghofrane WECHCRIA — Thu, 16 Apr 2026 14:32:22 +0000

Introduction

In a business process, decision-making is essential because it defines the logic that guides the execution of activities. Historically, this logic was externalized into rule engines such as Drools, separating decision-making from orchestration. However, in today’s environments where transparency and collaboration are key, this separation reveals its limitations: rules often remain hidden in technical files, difficult to understand and maintain.
To address these challenges, organizations now seek more integrated approaches. This is exactly what OrqueIO DMN offers: a model in which decisions and processes are brought together within the same ecosystem, providing consistency, clarity, and traceability.

1.OrqueIO — The future of open-source orchestration

Before introducing DMN, it’s important to present the execution platform.
OrqueIO is a 100% open-source fork of Camunda, ensuring the long-term future of BPMN automation, maintaining full compatibility with existing workflows while extending and modernizing the engine.

What OrqueIO brings:

100% open-source and fully compatible with your current BPMN/DMN models, connectors, scripts, and APIs
Ongoing maintenance and guaranteed security updates, ensuring long-term reliability and stability
New, practical features for daily use, including improved Cockpit monitoring and native DMN integration
Enhanced performance and engine stability, even under high load
Expert technical support, transparent and reliable — with no vendor lock-in

In summary, OrqueIO enables organizations to preserve their existing investments while adopting a modern, sustainable, and open orchestration platform — an environment where integrated decision logic with DMN naturally thrives.

2. The limitations of Drools

Excessive separation from the BPMN process:
The rules are stored in .drl files, often isolated in a separate project or module, which scatters business logic and makes it difficult to understand the relationship between decisions and the process.

Maintenance complexity:
This separation between the rule engine and the process leads to difficulties in maintaining overall system consistency over time.

Barrier for business teams:
The rules are written in technical languages such as DRL or MVEL, requiring development skills.
Non-technical users cannot read or modify these rules without IT involvement.

Lack of traceability and transparency:
Drools does not natively provide decision traceability (which rules were applied and why).
This makes audits and regulatory compliance much more difficult.

Rigid update cycle:
Any modification to a rule requires a full redeployment of the engine or application module, slowing down update cycles and reducing responsiveness.

Limits in agility and governance:
The Drools model does not encourage collaboration between business and IT teams, nor does it provide clear governance of decision rules integrated into BPMN processes.

3. OrqueIO DMN: a unified, readable, and open-source approach

OrqueIO natively integrates the DMN standard (Decision Model and Notation), enabling the unification of process logic (BPMN) and decision logic within the same platform.
Whereas Drools externalizes rules into a separate rule engine, OrqueIO provides an integrated, visual, and transparent approach within a recognized open-source automation ecosystem.

Clear and accessible rule representation
In OrqueIO, decisions are modeled as DMN decision tables.
Each row represents a rule, and each column represents a condition or an output.
This visual format is understandable to both business users and developers, replacing the DRL or MVEL source code used in Drools.
Business analysts can define, adjust, and validate decision logic without heavy reliance on technical teams.

Native BPMN ↔ DMN Integration
In OrqueIO, a Business Rule Task can directly invoke a DMN decision table from within the same project.
No external connectors, no complex integration: the process and the decision belong to the same executable model.
This results in a decision logic that is coherent, centralized, and fully traceable across the entire workflow.

Built-in traceability and audit
Every decision execution is automatically logged.
Teams can easily review:

which rules were evaluated,
the input values,
and the resulting outputs.

This greatly simplifies audits, gap analysis, regulatory compliance, and continuous improvement.

A complete and consistent ecosystem
OrqueIO provides a unified environment combining:

BPMN for process orchestration,
DMN for decision logic,
Cockpit for monitoring and analysis.

Everything is centralized, extensible, interoperable, and designed to enhance collaboration between business teams and IT.

4. Why migrate to OrqueIO DMN?

The transition from Drools is not just a tool replacement —
it is the adoption of a more agile, readable, and collaborative decision model.

Centralization of decisions and processes
Decisions are no longer isolated in a separate technical module.
They coexist with business processes within the same execution environment, ensuring a unified and coherent view of the system’s behavior.

Simplified maintenance
Modifying a rule no longer requires redeploying the application.
A simple update to the DMN decision table is enough to adjust the business logic, reducing delivery cycles and improving operational responsiveness.

Enhanced collaboration
Business teams design and adjust rules, while developers focus on integration and robustness.
The result: fewer misunderstandings, fewer back-and-forth steps, and greater overall efficiency.

Monitoring and transparency
With the Cockpit interface, every executed decision is observable, explainable, and interpretable.
This transparency simplifies optimization, control, and regulatory compliance.

Below is a comparison table summarizing the main differences between Drools and OrqueIO:

5.Concrete example of the transition: from Drools to OrqueIO DMN

We want to apply discounts based on:

the customer type (Standard, Premium, VIP)
the order amount (orderAmount)

Drools version (Before)
This .drl file contains the rules, written in Drools syntax

import io.orqueio.bpm.exemple.dmn.model.Order;

rule "Standard < 100"
    when $o : Order(clientType == "Standard", orderAmount < 100)
    then $o.setDiscount(0);
end

rule "Standard 100..500"
    when $o : Order(clientType == "Standard", orderAmount >= 100 && orderAmount <= 500)
    then $o.setDiscount(5);
end

rule "Standard >= 500"
    when $o : Order(clientType == "Standard", orderAmount > 500)
    then $o.setDiscount(8);
end

rule "Premium < 100"
    when $o : Order(clientType == "Premium", orderAmount < 100)
    then $o.setDiscount(10);
end

rule "Premium 100..500"
    when $o : Order(clientType == "Premium", orderAmount >= 100 && orderAmount <= 500)
    then $o.setDiscount(15);
end

rule "Premium >= 500"
    when $o : Order(clientType == "Premium", orderAmount > 500)
    then $o.setDiscount(20);
end

rule "VIP < 500"
    when $o : Order(clientType == "VIP", orderAmount < 500)
    then $o.setDiscount(20);
end

rule "VIP 500..1000"
    when $o : Order(clientType == "VIP", orderAmount >= 500 && orderAmount < 1000)
    then $o.setDiscount(25);
end

rule "VIP >= 1000"
    when $o : Order(clientType == "VIP", orderAmount >= 1000)
    then $o.setDiscount(30);
end

Implementation with DMN in OrqueIO

With DMN, the decision logic is defined in the form of a decision model, in which we explicitly describe:

which data serves as inputs to the decision,
which conditions are applied,
and which result must be produced.

This model can be edited visually, either as a table or as a diagram, which allows business teams to understand and adjust the logic more easily.

At the same time, that same logic is stored in a standard DMN XML file, which is used by the engine for execution.
The graphical view and the XML view are simply two representations of the same model, always kept in sync.

In the BPMN diagram, you simply add a Business Rule Task:

Calling a decision does not require any complex configuration.
In the BPMN diagram, a simple Business Rule Task is enough.
You only need to specify the decision reference (the ID defined in the DMN model), and the engine takes care of the evaluation.No additional technical configuration is required.
The decision is executed automatically when the BPMN flow reaches the decision task.

Conclusion

Migrating from Drools to OrqueIO DMN is more than a modernization effort — it is a strategic shift toward transparency, agility, and collaboration. By bringing decision logic closer to BPMN processes, organizations eliminate silos, simplify maintenance, and empower business teams to directly contribute to the evolution of rules. The result is a unified, traceable, and adaptable system where decisions are easier to understand, update, and audit.

With OrqueIO DMN, your business logic becomes clearer, your delivery cycles faster, and your governance stronger. This transition enables organizations to move from rigid rule engines to an integrated decision model that supports continuous improvement and operational efficiency.

🌐 Learn more about OrqueIO
📂 Explore the example Order Process from the OrqueIO webinar

Camunda 7 End of Life: Why More Teams Are Choosing OrqueIO as Their Migration Alternative

Ghofrane WECHCRIA — Thu, 16 Apr 2026 13:48:23 +0000

With Camunda 7 Community Edition now officially reaching end of life, many organizations are asking the same question:

What comes next for our workflow orchestration platform?

For teams heavily invested in BPMN automation and process orchestration, the obvious path may seem to be migrating to Camunda 8.
But in reality, many companies quickly discover that moving to Camunda 8 is far from a simple upgrade.

It often requires:

Major process refactoring
New infrastructure and architecture changes
Reworking integrations and deployment pipelines
Significant investment in time, budget, and training

For organizations running large-scale orchestration environments, this can represent a major technical and business challenge.

That’s exactly why we built OrqueIO.

OrqueIO: A Modern Open-Source Alternative to Camunda 7

OrqueIO is a modern, long-term supported fork of Camunda 7, designed for organizations that want to preserve their existing workflow architecture without going through a painful migration.

Instead of rebuilding everything from scratch, OrqueIO allows teams to continue running their BPMN processes and applications on a modernized, future-proof foundation.

With OrqueIO, you get:

Full compatibility with existing Camunda 7 BPMN/DMN models and APIs
Java 25, Spring Boot 4 and Angular modern stack
Continuous security updates and platform improvements
Free and open-source licensing
Optional enterprise support for production environments

In short:

OrqueIO enables you to keep your Camunda 7 investment while moving forward with a modern platform.

Built for Enterprises That Need Stability and Continuity

OrqueIO was not created as an experimental fork.

It was designed by engineers with real-world enterprise experience operating Camunda-based systems in large production environments.

Our goal was simple:

Preserve compatibility. Remove technical debt. Modernize the platform.

This means organizations can benefit from:

smoother upgrades,
lower migration risk,
reduced maintenance overhead,
and long-term platform sustainability.

More Than a Fork: A Platform Evolving Beyond Camunda 7

While compatibility remains at the core of OrqueIO, our ambition goes further.

Our roadmap includes a growing set of enterprise-ready capabilities to make orchestration smarter, simpler, and more secure:

Single Sign-On (SSO) and centralized identity management
Enhanced observability and analytics dashboards
Built-in documentation and model insights directly in the UI
Continuous UI/UX modernization across all modules

Our philosophy remains unchanged:

Keep compatibility. Add value. Evolve continuously.

The Future of Camunda 7 Doesn't Have to End Here

Camunda 7 may have reached end of life, but that does not mean organizations need to abandon their architecture or rebuild everything.

For teams looking for a Camunda 7 alternative, Camunda 7 fork, or open-source workflow engine compatible with existing BPMN applications, OrqueIO provides a pragmatic path forward.

If your company wants to modernize without rewriting years of orchestration logic, OrqueIO may be exactly what you’re looking for.

Learn more about OrqueIO: https://www.orqueio.io

Camunda 7 EOL — What Comes Next?

Ghofrane WECHCRIA — Thu, 16 Apr 2026 10:39:30 +0000

Introduction

Camunda 7 Community Edition, one of the most widely used BPMN workflow engines, reached its end of life in October 2025. For many enterprises, this marks a critical turning point: running business-critical workflows on an unsupported platform can create security risks, operational challenges, and technical debt.

As organizations look for ways to maintain continuity and stability, it's essential to explore alternatives that preserve existing processes without major disruptions. OrqueIO, the most modern fork of Camunda 7, offers a practical solution for teams that want to keep the trusted architecture of Camunda 7 while gaining long-term support, security, and flexibility.

End of Life of Camunda 7 Community

In October 2025, Camunda 7 Community Edition reached its official end of life, with the final release (v7.24) published on October 14, 2025. Since then, Camunda 7 CE no longer receives updates, security patches, or official support.

Any production environment running Camunda 7 CE after that date faced increased security risks and potential operational issues. For enterprises relying on Camunda 7 to manage critical workflows, this resulted in higher maintenance costs, accumulated technical debt, and reduced system stability. Without vendor support, addressing bugs or vulnerabilities became more difficult, making business continuity a real challenge.

The Risks of Staying on Camunda 7 CE

Continuing to run Camunda 7 Community Edition after its end of life comes with several risks for enterprises:

Technical debt: Outdated workflows and custom extensions may become harder to maintain.
Security vulnerabilities: Without updates or patches, systems are more exposed to attacks.
Maintenance challenges: Troubleshooting and fixing issues without official support can slow down operations.
Impact on critical processes: Business-critical workflows may experience downtime or instability, affecting overall productivity and reliability.

Choosing the right path now can prevent disruptions and ensure that workflows continue running smoothly.

Migration to Camunda 8: A Complex Journey

Moving from Camunda 7 CE to Camunda 8 involves a complex process. Enterprises should be aware of the challenges involved:

Workflow adjustments: Existing BPMN models can often be migrated, but some elements, attributes, and extensions from Camunda 7 may need modification to run on Camunda 8.
New architecture: Camunda 8 uses a cloud-native, event-driven platform that differs significantly from Camunda 7.
Team adaptation: Developers and operators need to become familiar with Camunda 8's APIs, operational patterns, and new workflow tools.
High migration cost: Moving to Camunda 8 requires significant time, resources, and financial investment, especially for organizations with complex workflows.

While Camunda 8 introduces modern features, the migration effort can be significant, especially for organizations with complex or mission-critical workflows.

OrqueIO: A Camunda 7 Alternative

OrqueIO is the most modern fork of Camunda 7, designed to provide enterprises with a seamless path beyond Camunda 7 CE without disruptions or rewrites. It allows teams to maintain their existing BPMN workflows, APIs, and extensions while benefiting from a modern, continuously evolving platform.

Key benefits of OrqueIO:

Operational continuity: High availability and business continuity with zero code rewriting, keeping your BPMN workflows fully stable and running smoothly.
Innovation and modern architecture: A continuously evolving platform, adding new features, optimizations, and enhancements to stay modern and reliable.
Optimization: Simplified design and performance-focused execution, ensuring efficient and reliable processes.
Security: Native security features to protect workflows, data, and integrations.
Documentation: Clear, practical, and usable technical documentation for developers and operators.
Enterprise support: Dedicated support with SLA and guaranteed response times.

OrqueIO ensures continuity, stability, and scalability, giving enterprises confidence as they evolve their workflow automation.

Conclusion

Camunda 7 Community Edition reached its end of life in October 2025, leaving enterprises running critical workflows in need of a reliable path forward. Continuing on an unsupported platform exposed businesses to security risks, technical debt, and operational challenges.

OrqueIO provides a practical, future-proof alternative. With full compatibility for existing workflows, APIs, and extensions, enterprises can maintain business continuity with zero code rewriting and without major infrastructure changes. Combined with dedicated support, continuous updates, and flexible deployment options, OrqueIO enables organizations to evolve their workflow automation securely and confidently.

Want to see OrqueIO in action?

📩 Contact us at contact@orqueio.io to schedule a personalized demo
or visit our official website: www.orqueio.io/contact

📚 Resources :

Documentation: https://docs.orqueio.io/
GitHub: https://github.com/OrqueIO