You can use BAMOE to develop stateful Workflow services using Business Process Model and Notation (BPMN) models. BPMN process models are graphical representations of the steps required to achieve a business goal. You can design your BPMN processes with BAMOE Canvas or BAMOE Developer Tools for VS Code. Alternatively you can import existing BPMN processes into your Business Services project for deployment and execution.
Stateful Workflow capabilities enable you to use elements such as process variables, events, timers, User Tasks and asynchronous Tasks (Service Tasks, Business Rule Tasks, and Script Tasks) to go further with BPMN Workflows that you implement.
The Compact Architecture is the reference architecture for Business Services containing stateful Workflows on BAMOE. In this architecture certain subsystems are colocated directly in your Business Services, simplifying configuration and minimizing communication between components, which ensures that Business Services are stable and robust.
Components of Compact Architecture
The following table details the different components in Compact Architecture, indicating whether they are mandatory or not for stateful Workflows.
| Component | Type | Stateful (Compact Architecture) | Stateless (STP) |
|---|---|---|---|
Workflow models |
BPMN files |
Mandatory |
Mandatory |
Workflow Engine |
System |
Mandatory |
Mandatory |
Runtime |
System |
Mandatory |
N/A |
Data-Index |
Subsystem (add-on) |
Optional |
N/A |
Data-Audit |
Subsystem (add-on) |
Optional |
N/A |
Jobs Service |
Subsystem (add-on) |
Mandatory |
N/A |
User Tasks |
Subsystem (add-on) |
Mandatory |
N/A |
Storage |
External system |
Mandatory |
N/A |
The following figure shows how they relate to each other in Business Services.
- Workflow models
-
BPMN files containing a sequence flow. Workflow models are compiled and wired in to the Workflow Engine when building Business Services into executables.
- Workflow Engine
-
The jBPM-powered engine for executing Workflows and which can delegate certain capabilities to other subsystems, like User Tasks or Jobs.
- Runtime
-
The Kogito-powered foundational framework providing basic services required for running Enterprise-grade Business Services: transactions, REST endpoints (JAX-RS), JDBC connection pools, thread pools, scalability, authentication and authorization, DI (dependency injection) etc. Quarkus and Spring Boot provide supported Runtimes.
- Storage
-
An external system where Business Services containing stateful Workflows store Process Instances, Data-Index, Data-Audit, Jobs Service, and User Tasks data. All subsystems store data in the same storage, which is usually a relation database such as PostgreSQL.
For more information on the subsystems: Data-Index, Data-Audit, Jobs Service and User Tasks see the following sections.
The Data-Index subsystem
The Data-Index subsystem is used to store a snapshot of the latest state of the Process Instance and allows it to be queried. The Workflow Engine sends diff events and Data-Index computes the last state by merging current data with the diff event data.
The information stored on Data-Index can be consumed through its GraphQL API exposed in the /graphql endpoint, e.g., http://localhost:8080/graphql for Business Services running locally.
See the associated Data-Index GraphQL API
The Data-Audit subsystem
The Data Audit subsystem enables you to inspect what happened during process execution. The system stores all diff event data coming from events, and can replay the process. The Data-Audit subsystem listens to events issued by the following components and persists them in the configured storage:
-
Workflow Engine
-
User Tasks
-
Jobs Service
See the associated Data-Audit API
The embedded Jobs Service subsystem
The embedded Jobs Service subsystem takes care of scheduling jobs, in particular timers such as those from boundary events, SLA, or throw events relevant to timers. It is also used for User Tasks notifications.
The User Tasks subsystem
In Workflows built with BPMN, User Task is a special type of activity that cannot be automatically executed by the workflow engine, requiring the
manual intervention of a user. When a Process Instance reaches a User Task node, a new User Task is created and the Process Instance is stopped waiting for the completion of the User Task. Once the User Task completes, the process can continue its execution normally.
The User Tasks subsystem is responsible for the execution of User Tasks initiated by the workflow engine, enabling users to move tasks through the different phases of their lifecycle until they reach a Completed state.
The User Tasks subsystem provides the following features:
-
Runs as a collocated service in the Workflow Engine with no extra configuration required in the application.
-
Generic set of REST API endpoints to interact with it, enabling users to transition User Tasks between the different lifecycle phases, modify User Task data (inputs and outputs), add comments and attachments to User Tasks.
-
Customization of User Task Assignment Strategy to automatically assign User Tasks to users during the task
Activatephase (see Configuring User Task assignment strategies).
You can choose between the two options for the User Task lifecycle inside your process:
-
The Kogito User Task Lifecycle (default)
-
The WS-Human Task Standard Lifecycle
For more information see The User Tasks Lifecycles and API
Getting started
To start developing stateful Workflows with Compact Architecture, go to Authoring Workflows with BPMN.
Migrating in-flight Process Instances
Process Instance Migration (PIM) using the Compact Architecture is based on simplified communication among the different Business Services removing the need for events (Kafka/HTTP). You can use the BAMOE Process Instance Migration (PIM) Add-on to manage the migration of long running Process Instances that contain User Tasks and Timers, to updated Process Definitions, for more information see Managing and Monitoring Business Services → Migrating in-flight Process Instances