docs: creating VanillaBP's tables with Liquibase or Flyway
Both pages said one sentence about switching the automatic creation off and left the reader
with the question where the statements come from. Story 75 answers it: the artifact
vanillabp-schema, the changelog to include, the generated SQL for Flyway - and why Flyway
needs an instance of its own, with its own history table, since it keeps one version
timeline and VanillaBP's numbers must not compete with the application's.
Also recorded: which databases a test covers, that a missing table ends the boot now, and
which two schemas are not ours (gruelbox on Spring Boot, the engine tables of Camunda 7).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jss55UjjvxYcLQPVFUFe25
docs: whose transaction covers a workflow aggregate, and what holds without one
Workflow aggregates: the paragraph naming the limits of story 67 is replaced by the three
ways to provide the transaction (the platform's, a TransactionRunner of the application,
one per aggregate), a table of what each way needs, and a table of what the guarantees
shrink to per store where nothing covers it. Quarkus and Spring Boot pages say the same
in their own words: JTA is always there but empty for a storage of your own, MongoDB
Panache brings a MongoDB transaction on a replica set, and on Spring Boot a
MongoTransactionManager is the application's to define.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jss55UjjvxYcLQPVFUFe25
docs: a phase-two failure repeating cannot fix blocks the entry at once
docs: what the aggregate persistence may expect from VanillaBP
VanillaBP calls the persistence from its own threads (task delivery, phase two of a
workflow start) and opens the transaction before doing so, on Quarkus also the CDI
request context. Says that once next to the SPI, and names the two limits: MongoDB
does not take part in the platform's transaction, and a persistence bringing its own
is not asked to open one.
Story 67.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jss55UjjvxYcLQPVFUFe25
Story 51: what VanillaBP remembers about a delivered task
docs: what a custom outbox store persists
Names the values a store writes and hands back at dispatch time, and that
operation names may be namespaced by extensions, so the column is wide
enough.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Unify the wording of all pages
Two passes over the wiki:
1. The pages written earlier (workflow modules, workflow aggregates, the
platform integration intros) were aligned with the wording of the newer
ones: grammar and typo fixes, consistent terminology (process = the BPMN
model, workflow = one execution; message names instead of event names)
and active voice instead of impersonal constructions.
2. All pages were revised to read less like generated text: em dashes in
prose replaced by proper punctuation, promotional phrasing and filler
removed, boldface and inline-header lists reduced to where they aid
scanning.
Two corrections found on the way: the Quarkus workflow-module page pointed
at the "main Spring Boot application module", and the property precedence
lists of the two platform pages are sorted in opposite directions, which is
now stated (Spring Boot: highest first, Quarkus: lowest first, matching the
config source ordinals 250/251/255/256).
No configuration key, behavior or example was changed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Document the VanillaBP BOM
Both platform integration pages get a subsection on 'io.vanillabp:vanillabp-bom' in their
dependency chapter: the Maven import, the Gradle equivalent, why BPMS adapters are not
part of it (they are released independently) and the one rule that matters - the BOM must
never be older than the adapters, because Maven lets an application-managed version win
over the version an adapter needs transitively without reporting a conflict. Adapters
detect that at startup, so the page tells readers what the resulting message means.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Add the V1 migration guide and the extensions page (story 29)
- **Migrating from VanillaBP 1 to 2** (new page, linked from Home): what stays (business
code, aggregates, BPMN models - Camunda 8 models even byte-identical), then every
required change with before/after - Java 21 / Spring Boot 4 / Quarkus 3.37, the renamed
adapter artifacts, the moved AggregatePersistenceAware import, the
META-INF/workflow-module descriptor (version 1 derived the module id from
spring.application.name respectively the config file name), default-adapter →
prioritized-adapters, adapter settings moving to vanillabp.adapters.<id>.* incl. a
key-by-key table (also naming the V1 keys with no V2 equivalent), the removed
ProcessService overloads, @BpmnProcess.primary, the @Transactional that has to GO from
workflow services, and the default methods of the two SPIs. Plus the behavior
differences (two-phase start, error contract, election, namespaced definition ids,
aggregate sync, the Camunda 8 cancelUserTask gap) and a five-step checklist.
- **Extensions** (new page, linked from Home): what an extension is, the two pipeline
steps it participates in, matching by model AND context type, ordering incl. the
reverse shutdown order, that an extension owns its own SPI (Business Cockpit as the
example), and how to register one on both platforms.
- Both platform pages: the outbox section gained the missing `retention` key and a "What
the outbox guarantees" block (idempotency keys, DONE instead of delete, at-least-once,
blocked entries as an operations duty).
- Workflow-modules: fixed an unclosed code fence and a link that pointed at GitHub's
/_edit URL.
Document convention over configuration (story 34)
Both platform pages lead with the zero-configuration case (one adapter
dependency + one workflow module = no vanillabp.* property) followed by
'prioritized-adapters' alone for several BPMS. 'Workflow modules' gains the
resources-location convention table - the page a developer looks at when their
BPMN is not found - linked from both platform-specific module pages.
Document the convention-over-configuration adapter configuration
An adapter id which IS the adapter type needs no 'type' property, and a
single configured adapter needs no 'prioritized-adapters' list. Both
platform pages now show this minimal variant first and the explicit
variant (custom ids, several BPMS) afterwards.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Move BPMS-specific content into the adapter wikis
The main wiki now documents only what is identical across all BPMS.
Everything specific to Camunda 7, Camunda 8 or the Process-Engine-API
moved into the respective adapter wiki.
Where such content stood, the pages now carry a list of the available
adapters linking directly to the matching page of the adapter's wiki.
The new page 'Available BPMS adapters' holds the full list and is
linked from Home. A custom footer with the VanillaBP logo and the
license notice was added.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Document BPMS migration: election, cache and start consistency
New page describing the headline feature end to end: configuring several BPMS
side by side, the two routing rules (new workflows start in the first-priority
adapter, operations on existing workflows go to the BPMS holding them), the
election guarantees (unknown falls through, unreachable never falls back,
completed is a no-op, guiding exceptions), the election cache including the
optional application-provided bean for cluster-shared caching, and the
at-least-once property of workflow starts against remote BPMS.
Linked from the concept overview, both platform integration pages, the workflow
tasks page and the message correlation page.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Document workflow-level configuration (story 27)
Both platform integration pages: prioritized-adapters overridable per
single workflow (most specific non-empty list wins), adapter-scoped keys
resolvable at the workflow level, deployment-target union, the guiding
startup WARN for unknown workflow IDs, and the deployment-failure 'warn'
rule now honoring workflow-level first priority. Adds a
"Migrating a single workflow" example.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015drvS8i7xLpNkuRNXdvtYM
Outbox SPI package updated (story 26i addendum)
PhaseTwoOutbox/PhaseTwoOutboxAware live in the business SPI now
(io.vanillabp.integration.spi) - custom outboxes are contributed by
applications, not by adapters.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Per-aggregate outbox selection + aggregate-ID type (story 26i)
- Spring Boot / Quarkus integration pages: the outbox is selected per workflow
aggregate (mixed persistence works transactionally, both defaults coexist),
availability is validated at startup, new configuration keys
(vanillabp.outbox.jdbc.*, vanillabp.outbox.mongo.*) and the
PhaseTwoOutboxAware attribution incl. dedicated outboxes for high-load
processes; Quarkus page now documents the MongoDB default, too.
- Workflow-aggregates page: full AggregatePersistenceAware method list incl.
getAggregateIdType() and the ID round-trip requirement.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Document canonical per-adapter config location and level resolution (story 26d)
Document env-var override limitation; drop stale resilience section (story 19)
Document canonical AggregatePersistenceAware, adapter configuration (deployment-failure, resilience)
Document transaction outbox configuration (vanillabp.outbox.*) for Spring Boot and Quarkus
Loading of workflow module property files from additional classpath locations
Add Spring Boot integration page