Reusable Symfony bundle that exposes a Flowable
BPMN engine as Doctrine-less API Platform
pass-through resources, a per-request HTTP client and matching flowable:*
CLI commands.
The bundle owns no database tables: every resource reads from and writes to a
remote Flowable REST engine at request time. Connection details (base URL and
credentials) are resolved per request from an ApiConfiguration of type
flowable (provided by dmstr/api-configuration-bundle).
- PHP >= 8.4
- Symfony 7
- API Platform 4
- A reachable Flowable REST engine (
flowable-rest)
composer require dmstr/flowable-bundleIf you do not use a Symfony Flex recipe that registers the bundle, add it to
config/bundles.php:
return [
// ...
Dmstr\Flowable\FlowableBundle::class => ['all' => true],
];The bundle is self-wiring: it ships its own service definitions
(FlowableBundle::loadExtension()), registers a dedicated flowable Monolog
channel and needs no entry in the application's services.yaml. API Platform
discovers the resource classes automatically from src/ApiResource.
Create an ApiConfiguration of type flowable. Its configJson is validated
against schema.json:
{
"base_url": "http://flowable-rest:8080/flowable-rest/service",
"auth_type": "basic",
"username": "rest-admin",
"password": "..."
}auth_type is either basic (requires username + password) or bearer
(requires token).
All resources are served under /api/flowable/*:
| Resource | Notable operations |
|---|---|
FlowDeployment |
GET /deployments, GET /deployments/{id}, POST /deployments/upload, DELETE |
FlowProcessDefinition |
GET /process_definitions, POST /process_definitions/{id}/start |
FlowProcessInstance |
GET /process_instances, POST /process_instances, DELETE |
FlowTask |
GET /tasks, POST /tasks/{id}/complete, GET /tasks/{id}/input_schema |
FlowExecution |
GET /executions, POST /executions/{id}/trigger |
FlowHistoric* |
read-only history: activities, process instances, tasks, variables |
The input_schema endpoint returns the per-task input JSON-Schema, resolved at
runtime from either an authored <formKey>.schema.json deployment resource or
by converting inline Flowable form-data — via the pluggable
flowable.task_form_source chain.
Every REST operation has a matching command; command IDs mirror the resource URLs:
flowable:health
flowable:deployments flowable:deployments:upload
flowable:process-definitions
flowable:process-instances flowable:process-instances:create
flowable:tasks flowable:tasks:complete
flowable:executions flowable:executions:trigger
Reading is open to any authenticated user. Starting, triggering and completing
(all write operations) require ROLE_FLOWABLE_ADMIN. The acting user is taken
from the authenticated identity (JWT sub) and propagated to Flowable — see
docs/tenant-and-user.md.
docs/walkthrough-vacation-request.md— end-to-end walkthrough of a human-task process.docs/tenant-and-user.md— tenant and acting-user model.
MIT © diemeisterei GmbH