Configuration

Configuration

The adapter is configured at VanillaBP's canonical per-adapter location vanillabp.adapters.<id>.* (see Configure the adapters):

vanillabp:
  prioritized-adapters:
    - pea
  adapters:
    pea:
      type: process-engine-api

Key	Default	Description
type	the adapter id	must be process-engine-api; may be omitted if the adapter id already IS process-engine-api

The adapter itself contributes no further configuration keys: how to reach a BPMS is the concern of the Process-Engine-API implementation you plug in, and it is configured by that implementation's own means.

Which engine does it talk to?

By default the adapter runs against the in-memory mock engine io.vanillabp.pea.mock.InMemoryProcessEngine shipped with it, which is useful for tests and for exploring the adapter without any infrastructure. Provide your own beans of the Process-Engine-API interfaces to replace it:

• Spring Boot: any bean of the respective interface replaces the mock.
• Quarkus: any non-default CDI bean of the respective interface replaces the mock (the mock is a @DefaultBean).

Deployment

On startup each workflow module's BPMN resources are parsed (JDK StAX, one entry per <bpmn:process isExecutable="true">) and deployed via the Process-Engine-API's DeploymentApi.

Because the API has no workflow-module / tenant namespace matching VanillaBP's, resources are deployed to the default tenant, so module isolation relies on unique BPMN process ids across modules (GAPS.md, entry 4).

Task-scoped configuration

The adapter has no task-scoped configuration keys, so VanillaBP's four-level configuration pattern does not apply here. Timeouts and retry behavior are properties of the underlying engine.

Keeping workflow modules apart

The Process-Engine-API has no isolation mechanism of its own: no tenants, no scopes (see the adapter's GAPS.md). The consequence for the name-clash-avoidance mode:

Mode	Supported?
by-adapter	no, and it is the DEFAULT, so this adapter fails the boot with a message naming the workflow module and the two alternatives. You have to choose actively
use-prefix	yes. The adapter rewrites the deployed BPMN itself (the API has no BPMN model type, so the raw XML is rewritten by element name, independent of the dialect your engine uses): process ids, call-activity references, message and signal names, escalation and error codes, task definitions and user-task form references
none	yes. Nothing is scoped, so your identifiers have to be unique across all workflow modules

vanillabp:
  adapters:
    pea:
      type: process-engine-api
      name-clash-avoidance: use-prefix   # or 'none'

Prefixing is transparent: your BPMN files, business code and configuration keep the plain identifiers. Only the engine behind the Process-Engine-API sees the prefixed ones, and the adapter translates them back when a task is delivered.