Flowable Bundle Laravel Package

Two asynchronous Flowable APIs are now available as pass-through resources, plus the engine jobs view that makes them observable.

External worker (#12)

The inverse of a flowable:type="http" service task: the engine puts a job on a topic and waits, the application polls. No inbound route from the engine to the app, and no credential in the deployment artifact — the worker authenticates, not the committed .bar.

• FlowExternalWorkerJob — read plus acquire / complete / fail / bpmnError / unacquire, each with its own input schema
• FlowJob — read-only engine jobs, ?kind=async|timer|suspended|deadletter|history, plus GET /jobs/{id}/stacktrace. Not optional in practice: a job that exhausted its retries disappears from external_worker_jobs and is only visible as ?kind=deadletter
• Worker core: implement ExternalWorkerHandlerInterface (topics() + handle()) — the interface is autoconfigured, so no attribute and no service entry is needed. A handler that throws is reported as fail (the engine owns backoff and dead-lettering); a topic without a handler is unacquired, never failed
• CLI: flowable:external-worker:run, the four report commands, flowable:external-worker-jobs, flowable:jobs

Event registry (#13)

A third engine repository next to the process and DMN engines, same ApiConfiguration. POST /event_instances hands an event straight to an inbound channel inside the engine, so inbound event correlation works without Kafka/RabbitMQ. The outbound direction stays broker-dependent and is not covered.

• FlowEventDeployment (+ upload, delete), FlowEventDefinition, FlowChannelDefinition, FlowEventInstance
• CLI: flowable:events:deployments[:upload], flowable:events:definitions, flowable:events:channels, flowable:events:instances:create

⚠️ Breaking change

FlowableClientInterface grows 25 methods. Code outside the bundle that implements the interface (typically a hand-written test double) becomes a fatal error; consumers that only use the client are unaffected. createStub(...)-style doubles keep working.

Worth knowing before you use it

• lockDuration / retryTimeout are ISO-8601 durations (PT10M), not numbers.
• externalWorkerInParameter is a whitelist: declare one and the job carries only the declared variables — silently, with no error anywhere.
• Graceful shutdown of flowable:external-worker:run needs ext-pcntl. Without it the command runs but ignores SIGTERM, so acquired jobs stay locked until their lockDuration expires.
• The event registry upload takes one .event/.channel file per call and rejects .bar/.zip, contrary to its own API description; deployment metadata goes on the query string as deploymentName.

Both features were verified end to end against flowable-rest:8.0.0 from a consuming application — acquire → complete/fail/bpmnError, dead-letter visibility, and an inbound event correlating a waiting process without a broker. Bundle-local tests are still missing (#14).

Also included: the previously untagged task-form prefill (x-process-data-var).

Added

• Server-side process-variable placeholder resolution in task form schemas (#9). Task form input schemas may carry {{ processVariable }} tokens (e.g. a dynamic x-collection filter /api/user?rolle=aussendienst_{{ kreisnummer }}); these are now resolved against the task's runtime variables before the schema reaches the client.
  • New ProcessVariablePlaceholderResolver — substitutes only bare-identifier tokens {{ name }}; dotted Jedison tokens {{ x.value }} (client-side x-watch/x-template) and unknown identifiers are left untouched.
  • New FlowableClient::getTaskVariables() — flattens /service/runtime/tasks/{id}/variables to a name => value map (404 → empty).
  • TaskFormInputSchemaResolver applies the resolver only when a {{ token is present.

Full Changelog: https://github.com/dmstr/flowable-bundle/compare/0.4.0...0.5.0