Solutions
Add a Powerful Workflow Engine to Your Application
Operaton is a community-driven, free, and open-source engine capable of executing BPMN, DMN and CMMN
Are you spending too much time hard-coding complex business logic, state management, and retry policies directly into your application code? When business requirements change, you’re faced with difficult and risky refactoring. A dedicated workflow engine offloads this complexity, allowing you to separate your process flow from your business logic.
Integrating a modern, standards-based process engine empowers you to build more resilient, scalable, and adaptable software faster. This page answers key questions for developers on how to seamlessly add powerful workflow capabilities to any new or existing application.
How Can a Process Engine Be Integrated into Your Software?
Modern workflow engines are not monolithic black boxes. They are designed to be developer-friendly services that you control programmatically. The primary method of integration is through a comprehensive, API-first approach.
A process engine exposes its full functionality—starting a process, assigning a human task, progressing a workflow after a service call, querying the status of a process—via a REST API. This means integrating a workflow is as simple as making standard HTTP calls from your existing code.
You can use these API endpoints to:
- Embed workflow triggers directly into your application’s UI or backend services.
- Query the state of any ongoing process to provide status updates to users.
- Correlate events from external systems (like a message from Kafka or a webhook) to a running workflow.
This API-driven contract makes integration straightforward, predictable, and easy to test, allowing you to add sophisticated, long-running process capabilities without fundamentally altering your existing application architecture.
What Operating Models and Architectures Are Possible?
A flexible workflow engine should adapt to your architecture, not the other way around. There are two primary architectural patterns for deploying a process engine, each with distinct advantages depending on your use case.
1. The Embedded Engine Model
In this model, the process engine runs as a library directly inside your application’s process. This is a common and powerful pattern for Java applications, for example, by adding a dependency to a Spring Boot service. Communication with the engine is a simple in-memory Java API call, offering maximum performance and the ability to bundle process and business logic changes within the same atomic transaction.
- Best for: Monolithic applications or single microservices that need to manage complex internal state.
- Benefits: Extremely high performance, transactional consistency, and simplicity of deployment.
2. The Standalone Engine Model (Workflow as a Service)
Here, the process engine runs as a separate, independent server. Your applications, regardless of what they are or where they run, communicate with the engine remotely via its REST API. This decoupled model is the foundation for modern microservices orchestration, where the engine acts as the central “conductor” for all your distributed services.
- Best for: Microservices orchestration, polyglot environments, and providing a central workflow capability to multiple applications.
- Benefits: Decoupled architecture, independent scalability, and language-agnostic integration.
Does It Work Independently of Programming Language?
Getting started with process orchestration is more straightforward than you might think. By following a proven, iterative approach, you can deliver value quickly and build momentum for wider adoption.
Yes, absolutely—when deployed using the standalone model. This is one of the most powerful features of a modern workflow engine.
The key to language-agnostic workflow automation is the combination of the standalone engine and the External Task Pattern. Here’s how it works:
- Your BPMN process model defines a service task (e.g., “Charge Credit Card”).
- The engine reaches this step and creates a job on a topic list (e.g., credit-card-charging) and waits.
- You write a small “worker” application in any language—Python, C#, Node.js, Go, PHP—that subscribes to this topic.
- The worker pulls the job, executes your custom business logic using your preferred libraries, and reports the result back to the engine via a REST API call.
This pattern allows you to use the best language for the job while the engine handles the overall process flow, state management, timeouts, and retries. You gain end-to-end process control without forcing your development teams into a single programming language.
