holunda-io/camunda-bpm-taskpool

Polyflow is a framework that synchronizes task and data management between Camunda BPM engines and external systems using an event-driven architecture. It captures process and task events from Camunda, normalizes them into domain events, and persists them in relational or document databases to provide a unified view for querying. The system supports flexible transactional sending of commands back to the engine and includes mechanisms for data anonymization, event versioning, and configurable URL resolution.

76 changes.

The project established its foundational infrastructure and rebranded to Polyflow, introducing a comprehensive View API for querying tasks, data entries, and process instances. Significant work focused on building diverse persistence backends, including MongoDB with change streams, JPA for relational storage, and an in-memory simple view for testing. The period also saw the development of core event sourcing aggregates, transaction-aware command senders, and a Camunda integration collector to synchronize runtime events.

24 changes.

This period focused on migrating the codebase to Spring Boot 3, introducing auto-configuration for core modules and the Camunda BPM starter. It expanded integration capabilities with new Camunda engine clients, transactional job senders, and type-safe view API clients, while refactoring taskpool event mapping logic. Extensive test coverage was added to validate serialization, database migrations, and new integration features.

The tasklist URL resolver module now includes a Spring Boot auto-configuration that provides a default \TasklistUrlResolver\ implementation based on the \polyflow.integration.tasklist.tasklist-url\ property. If this property is not set and no custom \TasklistUrlResolver\ bean is present, the application will fail to start with a clear error message, ensuring users explicitly configure the tasklist URL or provide their own resolver implementation.

integration/common/tasklist-url-resolver · high confidence

The simple view module now includes an in-memory implementation for development and testing purposes. This change introduces the \EnablePolyflowSimpleView\ annotation and \TaskPoolSimpleViewConfiguration\, which configures an in-memory token store and processing group for Axon Framework events, allowing the view to operate independently of external persistence backends like JPA or MongoDB.

view/simple/src/main/kotlin/io/holunda/polyflow/view/simple · high confidence

The view module now includes a new \PropertyBasedFormUrlResolver\ that allows administrators to configure URL templates for tasks, process start forms, data entries, and application pages via the \polyflow.integration.form-url-resolver\ configuration prefix. This component resolves URLs by substituting placeholders with runtime data (such as application name, task definition key, or process definition key) using templates defined in YAML properties, providing a flexible, configuration-driven alternative to hardcoded URL resolution logic.

view/form-url-resolver/src/main · high confidence

The view module now includes a new JPA-based storage layer for process data, introducing entities for process definitions and process instances along with their corresponding Spring Data repositories. This change adds the ability to persist process definition metadata (including authorization principals for starters) and process instance state (running, finished, cancelled, suspended) to the database, enabling local querying and filtering of process lifecycle data via JPA specifications.

view/jpa/src/main/kotlin/io/holunda/polyflow/view/jpa/process · high confidence

The MongoDB view now supports permanently removing data entries that have been marked as deleted. This is handled by the new DataEntryChangeTracker component, which monitors change streams for entries flagged as deleted and removes them after a configurable delay, or via a scheduled cleanup job. The DataEntryDocument model includes a 'deleted' flag and 'deleteTime' to support this lifecycle, and the DataEntryRepository provides queries to find entries by deletion status. This ensures that soft-deleted data does not accumulate indefinitely in the database.

view/mongo/src/main/kotlin/io/holunda/polyflow/view/mongo/data · high confidence

A new BeanPostProcessor in the core/spring-utils module automatically populates the \applicationName\ field in specific configuration properties (such as CamundaTaskpoolCollectorProperties, CamundaEngineClientProperties, and DataEntrySenderProperties) with the value of \spring.application.name\, but only if the field is currently set to the default placeholder value. This ensures that these components correctly identify the running application instance without requiring manual configuration, while preserving any explicitly set values.

core/spring-utils · high confidence

The data entry sender in the datapool integration is now configurable via the \polyflow.integration.sender.data-entry\ properties. Users can select the sender type between \simple\ (default, sends commands immediately) and \tx\ (accumulates commands and sends them within or after a transaction, controlled by \sendWithinTransaction\). The sender can be enabled or disabled globally, and payload serialization can be toggled. This change introduces the \DataEntrySenderConfiguration\, \DataEntrySenderProperties\, and specific sender implementations (\SimpleDataEntryCommandSender\, \DirectTxAwareAccumulatingDataEntryCommandSender\) to support these options.

integration/common/datapool-sender · high confidence

The Camunda BPM Spring Boot starter now registers its core configurations (CamundaTaskpoolCollectorConfiguration, SenderConfiguration, and DataEntrySenderConfiguration) via the Spring Boot 3 standard auto-configuration mechanism. This ensures that the taskpool collector and data entry sender components are automatically available in the application context when the starter is on the classpath, simplifying setup for users migrating to or using Spring Boot 3.

integration/camunda-bpm/springboot-starter · high confidence

The repository is initialized with essential configuration files to support development and documentation. This includes a Maven wrapper (mvnw) for consistent builds, a .java-version file specifying Java 17, and an .editorconfig to enforce coding standards. Documentation is structured using MkDocs with the Material theme, and code quality is managed via Detekt and Codacy configurations. Additionally, standard repository files such as LICENSE, README, SECURITY policy, and .gitignore are added to establish the project's open-source foundation.

(repo-wide) · high confidence

This change adds a new JPA view implementation for data entries, introducing a set of entities (DataEntryEntity, ProtocolElement, etc.) and a Spring Data repository to persist and query data entry information in a relational database. Users gain the ability to filter data entries by specific attributes such as entry ID, type, state, and payload values, as well as to find entries based on user involvement in the protocol log. The implementation also supports querying entries by authorization principals and includes logic to handle correlations between data entries, ensuring that payload attributes from correlated entries are included in search results.

view/jpa/src/main/kotlin/io/holunda/polyflow/view/jpa/data · high confidence

Adds a new JPA implementation for the Polyflow view services, enabling tasks, data entries, process instances, and process definitions to be persisted in a relational database. This change introduces the \EnablePolyflowJpaView\ annotation and \PolyflowJpaViewConfiguration\ to wire the persistence layer, along with services like \JpaPolyflowViewTaskService\ and \JpaPolyflowViewDataEntryService\ that handle event-driven updates and query execution. Users can now configure which item types to store via the \polyflow.view.jpa.stored-items\ property and control payload indexing with JSON path filters.

view/jpa/src/main/kotlin/io/holunda/polyflow/view/jpa · high confidence

The taskpool sender module now provides a configurable component for publishing task, process definition, process instance, and process variable commands. Users can choose between 'simple' (direct) and 'tx' (transaction-aware accumulating) sender types for tasks and process variables via properties like \polyflow.integration.sender.task.type\. The default task sender type is 'tx', enabling commands to be accumulated and sent within the current transaction, while process variables default to 'tx' and process definitions/instances default to 'simple'. Additionally, payload serialization for tasks can be controlled via \polyflow.integration.sender.task.serializePayload\ (defaulting to true), allowing users to opt out of serializing task payloads into Maps if needed.

integration/common/taskpool-sender/src/main/kotlin/io/holunda/polyflow/taskpool/sender · high confidence

The simple view now uses an in-memory projection backed by ConcurrentHashMaps instead of a persistent store. This new implementation handles events for tasks, data entries, process instances, process variables, and process definitions, providing query handlers for filtering, sorting, and retrieving these entities. It includes a revision support mechanism to track updates and emit query subscription updates, and exposes a restore function to replay events on startup.

view/simple/src/main/kotlin/io/holunda/polyflow/view/simple/service · high confidence

This change introduces the core data models for the Polyflow View API, defining how tasks, data entries, and process instances are represented and correlated. It adds the \Task\, \DataEntry\, \ProcessInstance\, and \ProcessDefinition\ data classes, along with \TaskWithDataEntries\ to link tasks with their associated business data. The \Extensions.kt\ file provides logic to construct and update tasks from engine events, ensuring that payload and correlation data are correctly merged without overwriting existing values with empty maps. Additionally, it includes a \FormUrlResolver\ interface for resolving form URLs and a \ComponentLike\ marker annotation to facilitate Kotlin component scanning.

view/view-api/src/main/kotlin · high confidence

The task pool core module now provides a dedicated Spring configuration class, TaskPoolCoreConfiguration, which registers event-sourcing repositories for Task, ProcessDefinition, and ProcessInstance aggregates, along with a weak reference cache and Jackson serialization settings. Users can enable this functionality in their applications by using the new @EnablePolyflowTaskPool annotation, which imports the core configuration.

core/taskpool/taskpool-core/src/main/kotlin/io/holunda/polyflow/taskpool/core · high confidence

Added a new \User\ data class and a \UserService\ interface within the \view/view-api\ module to support user identity and group management. The \UserService\ provides a hook for retrieving user details by identifier and throws an \UnknownUserException\ if the user is not found, laying the groundwork for authentication logic in the Polyflow view.

view/view-api/src/main/kotlin/auth · high confidence

The Mongo view now supports real-time task updates via MongoDB change streams (activated by setting \polyflow.view.mongo.changeTrackingMode\ to \CHANGE\_STREAM\). This introduces a new \TaskChangeTracker\ component that listens for task modifications and handles the delayed deletion of tasks marked as deleted, configurable via \clearDeletedTasks\ properties. To support this, new domain models (\TaskDocument\, \ReferenceDocument\, \TaskWithDataEntriesDocument\) and repositories (\TaskRepository\, \TaskWithDataEntriesRepository\) have been added, along with extension implementations for querying tasks by user/application and tracking task counts. The change stream subscription also includes backpressure handling to prevent delays in task updates.

view/mongo/src/main/kotlin/io/holunda/polyflow/view/mongo/task · high confidence

The view module now persists process definitions in MongoDB using a new \ProcessDefinitionDocument\ model and \ProcessDefinitionRepository\. A \ProcessDefinitionMongoService\ listens for \ProcessDefinitionRegisteredEvent\ events to save definitions and emits reactive query updates, enabling users to retrieve the latest version of process definitions they are authorized to start via the \ProcessDefinitionsStartableByUserQuery\.

view/mongo/src/main/kotlin/io/holunda/polyflow/view/mongo/process · high confidence

A new command interface and data class have been introduced to the process definition API, allowing the system to register details about process definitions deployed in the engine. This includes specific metadata such as the process definition ID, key, version, application name, and user/group starter candidates, enabling downstream components to react to new process deployments.

core/taskpool/taskpool-api/src/main/kotlin/io/holunda/camunda/taskpool/api/process/definition · high confidence

The taskpool API now includes a new set of command classes in the \io.holunda.camunda.taskpool.api.process.instance\ package to represent process instance lifecycle events. These commands, including \StartProcessInstanceCommand\, \EndProcessInstanceCommand\ (and its subclass \FinishProcessInstanceCommand\), \CancelProcessInstanceCommand\, \SuspendProcessInstanceCommand\, and \ResumeProcessInstanceCommand\, allow the system to track and react to process instance creation, completion, cancellation, suspension, and resumption. Each command carries essential context such as the process instance ID, source reference, business key, and relevant user or activity identifiers.

core/taskpool/taskpool-api/src/main/kotlin/io/holunda/camunda/taskpool/api/process/instance · high confidence

The view API now exposes a dedicated interface for querying process variables, allowing clients to request variables for a specific process instance. This change introduces a filtering mechanism via the \ProcessVariableFilter\ interface and its implementations (\ProcessVariableFilterExactlyOne\ and \ProcessVariableFilterOneOf\), enabling users to include or exclude variables by name. The query response is returned as a \ProcessVariableQueryResult\ containing a list of \ProcessVariable\ objects.

view/view-api/src/main/kotlin/query/process/variable · high confidence

The taskpool API now includes a new set of commands and data structures to capture and transmit changes to process variables. Users can now send commands to create, update, or delete process variables, with each change explicitly typed (Create, Update, Delete) and associated with variable values that support primitive types, object maps, or Camunda typed values. This provides a structured way to track variable lifecycle events within process executions.

core/taskpool/taskpool-api/src/main/kotlin/io/holunda/camunda/taskpool/api/process/variable · high confidence

The datapool API now exposes a comprehensive set of new types to manage data entry operations. This includes command objects for creating, updating, deleting, and anonymizing data entries, alongside data models for entry state (with processing types like PRELIMINARY, IN\_PROGRESS, COMPLETED, CANCELLED, and DELETED), authorization changes (adding/removing users and groups), and modification tracking. These changes enable finer-grained control over data entry lifecycle and access permissions within the task pool.

core/datapool/datapool-api · high confidence

This change introduces a new auto-configured client component that bridges Axon event handling with the Camunda BPM engine. Users can now enable this integration via the \@EnableCamundaEngineClient\ annotation or by relying on Spring Boot auto-configuration. The client listens for task-related events (claim, unclaim, complete, defer, undefer) from Axon and applies them to the Camunda Task Service, filtering events by application name. It also provides a \ProcessStarter\ component to initiate process instances via the Camunda Runtime Service. Configuration is managed through \CamundaEngineClientProperties\, allowing users to specify the application name for event filtering.

integration/camunda-bpm/engine-client/src/main · high confidence

The Camunda Taskpool Collector is now available, enabling automatic synchronization of Camunda process artifacts and runtime events to the Task Pool. This integration listens to Camunda Spring Events to collect, enrich, and send task, process definition, process instance, and process variable commands. It includes built-in listeners for task lifecycle events, metadata generation for IDE auto-completion, and configurable process-variable correlation and filtering via application properties. Users can enable or disable specific collectors (tasks, process definitions, instances, variables) and exclude specific task events through configuration.

integration/camunda-bpm/taskpool-collector/src/main · high confidence

The view API now exposes a new set of query objects and interfaces for retrieving data entries, including \DataEntryApi\ and \ReactiveDataEntryApi\. These allow querying data entries by identity, type, or user (with optional involvement filtering), supporting pagination, sorting via a list of strings, and custom filters. The new query classes replace older patterns and include deprecated constructors for backward compatibility with single-string sort parameters.

view/view-api/src/main/kotlin/query/data · high confidence

The task pool event module now provides a new annotation-driven mechanism for defining event upcasters, allowing developers to create custom upcasters by extending \AnnotationBasedSingleEventUpcaster\ and marking them with \@AnnotatedEventUpcaster\. To simplify migration management, the module introduces \taskpoolEventUpcasters()\ and \taskpoolEventUpcasterChain()\ functions that centrally aggregate all defined upcasters (including existing ones like \ProcessDefinitionEventJSONNullTo1Upcaster\ and various \Task...EngineEvent...Upcaster\ instances), ensuring that new upcasters are automatically included in the chain as the system evolves without requiring manual registration.

core/taskpool/taskpool-event/src/main/kotlin/io/holunda/camunda/taskpool/upcast · high confidence

The datapool-event module now exposes explicit domain events for the full data entry lifecycle: creation, update, deletion, and anonymization. Corresponding mappers translate commands (CreateDataEntryCommand, UpdateDataEntryCommand, DeleteDataEntryCommand, AnonymizeDataEntryCommand) into these events, ensuring that details such as entry type, ID, payload, correlations, state, authorizations, and form keys are consistently propagated. The anonymization event specifically captures the username used for anonymization and a list of excluded usernames (e.g., SYSTEM). Tests verify that each command maps correctly to its respective event.

core/datapool/datapool-event · high confidence

The view API now includes a new \Filter.kt\ module that provides logic for filtering lists of tasks and data entries. This implementation supports comparison operators such as equals, like, greater than, less than, and between, allowing users to filter by task attributes, data entry attributes, and payloads. The filter logic combines multiple criteria using AND operations, ensuring that all specified conditions must be met for an item to be included in the results.

view/view-api/src/main/kotlin/filter · high confidence

The taskpool event API now includes new data classes for process and task lifecycle events. Process events cover definition registration, instance start/end/cancel/suspend/resume, and variable changes. Task events define engine interactions such as creation, assignment, completion, deletion, attribute updates, and candidate changes, along with user interactions like claiming tasks. These events form the core communication interface for the taskpool system.

core/taskpool/taskpool-event/src/main/kotlin/io/holunda/camunda/taskpool/api · high confidence

The view API now exposes new interfaces and query types for process definitions and instances. Users can query process definitions startable by a specific user via \ProcessDefinitionApi\ and \ReactiveProcessDefinitionApi\, which filter based on candidate starter users and groups. Additionally, \ProcessInstanceApi\ allows querying process instances filtered by their state, returning results wrapped in \ProcessInstanceQueryResult\ with support for pagination and sorting.

view/view-api/src/main/kotlin/query/process · high confidence

The taskpool-sender module now includes new components to handle process variable commands (create, update, delete). A simple sender (\SimpleProcessVariableCommandSender\) sends individual variable changes immediately if enabled, while a new transaction-aware sender (\TxAwareAccumulatingProcessVariableCommandSender\) collects multiple variable changes within a single transaction and groups them by process instance and execution before sending. This allows users to control whether variable updates are sent within the transaction (\sendWithinTransaction\ property) or after commit, reducing network overhead by batching related changes.

integration/common/taskpool-sender/src/main/kotlin/io/holunda/polyflow/taskpool/sender/process · high confidence

The view API introduces a new set of query interfaces to support advanced data retrieval. FilterQuery allows applying custom filter functions to elements. PageableSortableQuery defines the structure for pagination (page, size) and sorting, including a sanitizeSort method that validates sort parameters against allowed fields and enforces specific direction signs. QueryResult wraps the returned elements and total count, providing a slice method to apply pagination logic based on a PageableSortableQuery.

view/view-api/src/main/kotlin/query · high confidence

The view API now includes a new sorting module in the \io.holunda.polyflow.view.sort\ package, introducing \DataEntryComparator\, \TaskComparator\, and \TasksWithDataEntriesComparator\ classes. These components enable sorting of tasks and data entries by specific fields, supporting both ascending and descending directions. The implementation handles various data types including strings, integers, dates, and instants, and provides a robust mechanism for comparing null values during sort operations.

view/view-api/src/main/kotlin/sort · high confidence

Added the \EnableTaskpoolEngineSupport\ annotation and its backing \TaskpoolEngineSupportConfiguration\ to simplify enabling task pool engine components in Spring Boot applications. This configuration automatically wires the \DataEntryCommandSender\ and \EngineTaskCommandSender\, reducing the manual setup required for integrating with the Camunda task pool. An integration test confirms that these components are correctly initialized when the annotation is applied.

integration/camunda-bpm/springboot-autoconfigure · high confidence

The view API now exposes a comprehensive set of query objects and interfaces for retrieving tasks, enabling users to filter, sort, and paginate task lists by user, group, candidate user, application, or ID, as well as retrieve task attribute names and values. This includes the introduction of \TaskApi\ and \ReactiveTaskApi\ interfaces, query classes like \AllTasksQuery\, \TasksForUserQuery\, and \TasksWithDataEntriesForUserQuery\, and result wrappers such as \TaskQueryResult\ and \TasksWithDataEntriesQueryResult\. The API supports both synchronous and reactive consumption patterns and allows querying tasks with or without correlated data entries.

view/view-api/src/main/kotlin/query/task · high confidence

The view-api-client module now provides dedicated query client classes (DataEntryQueryClient, ProcessDefinitionQueryClient, ProcessInstanceQueryClient, ProcessVariableQueryClient, and TaskQueryClient) that encapsulate Axon QueryGateway calls with correct response types. Additionally, a QueryGatewayExt object adds type-safe extension functions to QueryGateway, allowing users to execute queries for data entries, process definitions, process instances, process variables, and tasks (including candidate user/group queries and attribute lookups) without manually specifying response types.

view/view-api-client · high confidence

Users can now safely integrate Polyflow into an existing database that already contains the required tables. By enabling the new \polyflow.liquibase.adoption.enabled\ property, the application runs a one-time synchronization that records the current changelog state and tags the schema with the current release version, then shuts down. This mechanism prevents the standard Liquibase migration runner from executing, allowing Polyflow to recognize and operate on a pre-existing verified schema without attempting to modify or upgrade it.

integration/common/liquibase · high confidence

The Mongo-based view component has been rebranded from 'TaskPool' to 'Polyflow' to align with the broader project identity. This includes renaming the main configuration class to \TaskPoolMongoViewConfiguration\ (with a new \EnablePolyflowMongoView\ annotation replacing the deprecated \EnableTaskPoolMongoView\) and updating the package structure for converters. Additionally, the view now supports data entry anonymization, allowing user identities in protocol entries to be masked when an anonymization event occurs. The configuration properties have been expanded to include \deleteDeletedDataEntries\ and detailed \changeStream\ settings for controlling how and when deleted documents are cleared from MongoDB, supporting both change stream subscriptions and scheduled jobs.

view/mongo/src/main/kotlin/io/holunda/polyflow/view/mongo · high confidence

The taskpool sender now includes a new accumulator module that groups and merges multiple engine task commands (such as create, update, assign, and candidate changes) into single, optimized commands before sending them. This logic sorts commands by order, detects primary intents, and projects property changes from detail commands onto the main command, while handling specific edge cases like candidate user/group additions and deletions. It also prevents redundant commands (like standalone attribute updates) from being published and optionally serializes payloads to maps for safer deserialization.

integration/common/taskpool-sender/src/main/kotlin/io/holunda/polyflow/taskpool/sender/task/accumulator · high confidence

Users can now decouple task command sending from the originating transaction by configuring the sender type as 'txjob' via the 'polyflow.integration.sender.task.type' property. This new capability introduces a Camunda job-based sender that accumulates commands, serializes them into a byte array resource, and schedules a dedicated Camunda job to asynchronously deliver the commands to the Taskpool Core gateway, ensuring reliable delivery independent of the initial transaction's outcome.

integration/camunda-bpm/taskpool-job-sender · high confidence

The variable serializer now allows users to control which nested attributes are included or excluded from serialized payloads using a new \PathFilter\ mechanism (supporting include/exclude rules) and to enforce a maximum length on string values via a \valueLengthLimit\ parameter. This ensures that large payloads can be truncated to fit system constraints and that sensitive or unnecessary nested data can be filtered out before indexing or transmission.

integration/common/variable-serializer/src/main · high confidence

The mapping logic for converting commands to events and internal models to events has been moved out of aggregate classes into dedicated mapper files (ProcessDefinitionMapper, ProcessInstanceMapper, TaskEventMappers, and TaskFactoryMethods). This refactoring centralizes the transformation of commands like RegisterProcessDefinitionCommand, StartProcessInstanceCommand, and CreateTaskCommand into their corresponding domain events, ensuring that updates to task attributes, assignments, and lifecycle states are correctly mapped to events such as TaskAttributeUpdatedEngineEvent and TaskAssignedEngineEvent.

core/taskpool/taskpool-event/src/main/kotlin/io/holunda/camunda/taskpool/mapper · high confidence

New upcaster classes have been introduced to handle the migration of ProcessDefinitionRegisteredEvent from revision 0 to revision 1. These upcasters ensure backward compatibility by transforming legacy event payloads (both XML and JSON formats) into the current structure, specifically updating the serialized type name and payload representation to match the expected API contract.

core/taskpool/taskpool-event/src/main/kotlin/io/holunda/camunda/taskpool/upcast/definition · high confidence

New upcaster classes have been added to handle legacy task event formats, ensuring backward compatibility when reading older events. Specifically, the system now includes upcasters to patch missing payload and correlation attributes in TaskAttributeUpdatedEngineEvent version 4 (upgrading to version 5), and to remove duplicate source reference elements from various task events (such as TaskCreated, TaskCompleted, and TaskAssigned) that were introduced by previous schema changes. These changes allow the task pool to correctly deserialize and process historical events without data loss or structural errors.

core/taskpool/taskpool-event/src/main/kotlin/io/holunda/camunda/taskpool/upcast/task · high confidence

The \core/bus-jackson\ module now provides a unified set of Jackson configuration helpers to ensure correct deserialization of polymorphic types and abstract interfaces. It introduces specific mapping modules for \DataEntryState\ (mapping to \DataEntryStateImpl\) and Camunda's \VariableMap\ (mapping to \VariableMapImpl\), resolving issues where these types failed to restore or serialize correctly. Additionally, it registers type discriminators via mixins for interfaces with multiple implementations, such as \SourceReference\, \AuthorizationChange\, \Criterion\, and \ProcessVariableFilter\, and enables auto-detection of all fields to support Kotlin serialization patterns.

core/bus-jackson/src/main/kotlin/io/holunda/polyflow/bus/jackson · high confidence

A new extension file, QueryEmitterExt.kt, has been added to the JPA view update module to standardize how query subscriptions are notified of changes. This change introduces specific helper functions (updateProcessDefinitionQuery, updateDataEntryQuery, updateProcessInstanceQuery, and updateTaskQuery) that encapsulate the logic for emitting QueryUpdateEmitter messages. For users, this ensures that updates to process definitions, data entries, process instances, and tasks are consistently broadcast to relevant query handlers (such as those filtering by user, application, or state), improving the reliability and maintainability of real-time query results within the view layer.

view/jpa/src/main/kotlin/io/holunda/polyflow/view/jpa/update · high confidence

The data pool core now allows administrators to control how deleted data entries are handled via the \polyflow.core.data-entry.deletion-strategy\ property, supporting both \lax\ (default, allows updates to undelete) and \strict\ (throws errors on operations after deletion) modes. Additionally, a new \FirstEventOnlyEventSourcingRepository\ is available via \polyflow.core.data-entry.event-sourcing-repository-type\ to optimize performance by loading aggregates using only the first event, reducing snapshot dependency and load times for this specific aggregate structure.

core/datapool/datapool-core/src/main · high confidence

The taskpool sender now supports sending engine task commands either within the transaction or after commit, controlled by the \senderProperties.task.sendWithinTransaction\ flag. This change introduces an \AbstractTxAwareAccumulatingEngineTaskCommandSender\ that accumulates commands and registers transaction synchronizations to send them at the appropriate time, alongside a \DirectTxAwareAccumulatingEngineTaskCommandSender\ for immediate sending and a \SimpleEngineTaskCommandSender\ for non-transactional scenarios. Users can now configure whether task commands are sent inside the transaction boundary or deferred until after commit, allowing for better control over transactional consistency and performance.

integration/common/taskpool-sender/src/main/kotlin/io/holunda/polyflow/taskpool/sender/task · high confidence

A new auto-configuration class, FallbackPayloadObjectMapperAutoConfiguration, has been introduced to provide a default Jackson ObjectMapper when no user-defined bean with the qualifier 'payloadObjectMapper' is present. This fallback instance is configured with Polyflow-specific settings and registered modules. Crucially, when this fallback is used, the application logs a warning advising users to provide their own ObjectMapper bean with the specific qualifier, signaling a shift towards explicit configuration rather than implicit defaults.

core/bus-jackson/src/main/kotlin/io/holunda/polyflow/bus/jackson/config · high confidence

The JPA task view now indexes task payload attributes, storing them in a dedicated \PLF\_VIEW\_TASK\_AND\_DATA\_ENTRY\_PAYLOAD\ table to enable filtering by specific data entry payload values. Additionally, the view supports filtering tasks by due date and follow-up date ranges, and allows filtering for tasks where an assignee is explicitly set or unset.

view/jpa/src/main/kotlin/io/holunda/polyflow/view/jpa/task · high confidence

The taskpool sender now includes a new Axon-based gateway that processes command lists sequentially, respecting the sender's enabled property to either dispatch commands or log debug messages when disabled. This change introduces specific error and success handlers that log command outcomes using the oshai kotlin-logging library, replacing the previous microutils dependency.

integration/common/taskpool-sender/src/main/kotlin/io/holunda/polyflow/taskpool/sender/gateway · high confidence

The logic for registering process definitions and managing process instance lifecycle (start, finish, cancel, suspend, resume) and variable changes has been extracted from existing aggregates into new, dedicated components: ProcessDefinitionAggregate, ProcessInstanceAggregate, and their respective command handlers. This refactoring centralizes command-event mapping for process-related operations, ensuring that process definitions can be registered and process instances can be manipulated through explicit aggregate roots, while also allowing variable updates to create the instance aggregate if it was missed during initial creation.

core/taskpool/taskpool-core/src/main/kotlin/io/holunda/polyflow/taskpool/core/process · high confidence

The task API has been restructured to introduce a new set of interfaces and data classes for handling task events and commands. This includes the new \CamundaTaskEventType\ interface to standardize event names (such as create, assign, complete, and attribute updates), and the \EngineTaskCommand\ interface which adds an \order\ property to control command sequencing. A new \EngineTaskCommandSorter\ class has been added to enforce this ordering, ensuring that operations like task creation and completion are processed before attribute updates. The API now distinguishes between engine-originated commands (e.g., \CreateTaskCommand\, \UpdateAttributeTaskCommand\) and user interaction commands (e.g., \ClaimInteractionTaskCommand\, \CompleteInteractionTaskCommand\). Additionally, new reference types like \ProcessReference\ and \CaseReference\ have been introduced to better identify the source of tasks.

core/taskpool/taskpool-api/src/main/kotlin/io/holunda/camunda/taskpool/api/task · high confidence

The bus-jackson module now registers its FallbackPayloadObjectMapperAutoConfiguration via the Spring Boot 3 standard auto-configuration mechanism (META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports), ensuring the custom Jackson ObjectMapper fallback is automatically applied when the library is on the classpath.

core/bus-jackson/src/main/resources · high confidence

The JPA view now introduces a new PayloadAttribute entity to handle the serialization of list variables, addressing previous limitations where filtering by data entry payloads did not work correctly. This change enables the system to store and search payload attributes derived from map entries, ensuring that complex variable structures are properly persisted and queryable within the JPA view layer.

view/jpa/src/main/kotlin/io/holunda/polyflow/view/jpa/payload · high confidence

The task import mechanism now prevents duplicate task creation by checking the event store before emitting a CreateTaskCommand. A new TaskAggregateEngineTaskCommandFilter validates incoming commands against existing aggregates, ensuring that only tasks not already present in the system are created, while an ExternalCommandHandler manages the idempotent creation or replay of commands for existing tasks.

core/taskpool/taskpool-core/src/main/kotlin/io/holunda/polyflow/taskpool/core/task · high confidence

The taskpool sender module now provides an \@EnableTaskpoolSender\ annotation to activate the sender configuration, simplifying setup for users. Additionally, Jackson object mapper configuration is centralized via a moved helper function (now deprecated in this module in favor of the separate \polyflow-bus-jackson\ artifact), and a new extension function is added to serialize process variable values into primitive or object representations based on their type.

integration/common/taskpool-sender/src/main/kotlin/io/holunda/polyflow/taskpool · high confidence

The Task model in the taskpool-event module now includes an update method that allows task attributes to be refreshed with data supplied by incoming events. This ensures that fields such as name, description, priority, due date, and correlations are correctly synchronized with the latest event payload, addressing previous issues where attribute updates were not handled properly.

core/taskpool/taskpool-event/src/main/kotlin/io/holunda/camunda/taskpool/model · high confidence

Added database migration scripts for Camunda 7.21–7.23 integration tests; Added database migration scripts for JPA view integration tests; Added deserialization tests for view queries; Added integration and unit tests for the JPA view service; Added integration test application context for Data Pool; Added integration test for message start events; Added integration test infrastructure for JPA view; Added integration test infrastructure for the taskpool collector; Added integration tests for Mongo task repository and document builder; Added integration tests for task and process definition collectors; Added integration tests for the task transaction job sender; Added serialization tests for bus-jackson components; Added test application configuration for in-memory event storage; Added test configuration for TaskPoolMongo integration tests; Added test coverage for taskpool sender configuration and command handling; Added test service provider for Jackson data format configurator; Added tests for Data Entry aggregate and event sourcing repository; Added tests for DataEntryConverter authorization handling; Added tests for DataEntryCreatedEventUpcaster; Added tests for FormUrlResolver; Added tests for Mongo view service change tracking, retry logic, and sorting; Added tests for data entry deletion strategy configuration; Added tests for event upcasting logic; Added tests for sort parameter sanitization in pageable queries; Added tests for task and data entry correlation logic; Added tests for task-level and process-level variable correlation and filtering; Added tests for taskpool collector property configuration and variable enrichment; Added tests for variable serialization and JSON path filtering; Added unit and integration tests for Camunda engine client properties and handlers; Added unit and integration tests for JPA data and process repositories; Added unit and integration tests for JPA task handling; Added unit and integration tests for task and process aggregates; Added unit tests for SimpleDataEntryService and SimpleTaskPoolService; Added unit tests for data entry query filters and authorization; Added unit tests for task command sorting and process query filters; Added unit tests for task query filters; Added unit tests for task sorting comparators; Added unit tests for the task filtering logic; Added unit tests for view-api data models and extensions.

The project now provides dedicated Maven Bill of Materials (BOM) artifacts to centralize dependency versioning. The new \polyflow-parent\ BOM manages core framework versions, including Spring Boot 3.5.16, Axon Framework 4.13.3, and Kotlin 2.4.10. Additionally, \polyflow-datapool-dependencies\ and \polyflow-taskpool-dependencies\ BOMs are introduced to manage the specific versions of the Data Pool and Task Pool modules respectively, simplifying dependency management for consumers of the Polyflow framework.

(dependencies) · high confidence

The Maven Wrapper configuration has been updated to use Apache Maven 3.9.2, ensuring that builds consistently use this specific version of the build tool across all environments.

.mvn · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 54 → 56 (+2.0)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 93 → 96 (+2.7)
• Architecture 99 → 89 (-9.1)
• Maturity 68 → 83 (+15.1)
• Readiness 71 → 71 (+0.0)
• Security 43 → 44 (+0.2)
• Domain Modelling 49 → 52 (+3.1)
• Event Sourcing 100 → 100 (+0.0)

• Change coupling: DataEntryCommands.kt ↔ BusinessEvents.kt (core/datapool/datapool-api/src/main/kotlin/io/holunda/camunda/taskpool/api/business/DataEntryCommands.kt)
• Change coupling: JpaPolyflowViewDataEntryService.kt ↔ ConverterExt.kt (view/jpa/src/main/kotlin/io/holunda/polyflow/view/jpa/JpaPolyflowViewDataEntryService.kt)
• Change coupling: SimpleDataEntryService.kt ↔ SimpleTaskPoolService.kt (view/simple/src/main/kotlin/io/holunda/polyflow/view/simple/service/SimpleDataEntryService.kt)
• Concentrated knowledge decay
• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
• Duplicated block (10 lines × 2) (view/mongo/src/main/kotlin/io/holunda/polyflow/view/mongo/task/TaskDocument.kt)
• Duplicated block (10 lines × 2) (view/view-api/src/main/kotlin/query/task/TaskAttributeValuesQuery.kt)
• Duplicated block (10 lines × 4) (view/mongo/src/main/kotlin/io/holunda/polyflow/view/mongo/MongoViewService.kt)
• Duplicated block (11 lines × 2) (core/taskpool/taskpool-event/src/main/kotlin/io/holunda/camunda/taskpool/mapper/task/TaskEventMappers.kt)
• Duplicated block (11 lines × 2) (view/jpa/src/main/kotlin/io/holunda/polyflow/view/jpa/JpaPolyflowViewTaskService.kt)
• Duplicated block (11 lines × 2) (view/jpa/src/main/kotlin/io/holunda/polyflow/view/jpa/JpaPolyflowViewTaskService.kt)
• Duplicated block (11 lines × 2) (view/mongo/src/main/kotlin/io/holunda/polyflow/view/mongo/Converters.kt)
• Duplicated block (11 lines × 2) (view/mongo/src/main/kotlin/io/holunda/polyflow/view/mongo/process/ProcessDefinitionMongoService.kt)
• Duplicated block (11 lines × 2) (view/simple/src/main/kotlin/io/holunda/polyflow/view/simple/service/Converters.kt)
• Duplicated block (12 lines × 2) (integration/camunda-bpm/taskpool-collector/src/main/kotlin/io/holunda/polyflow/taskpool/HistoricProcessInstanceEventExtensions.kt)
• Duplicated block (12 lines × 2) (view/jpa/src/main/kotlin/io/holunda/polyflow/view/jpa/data/DataEntryRepository.kt)
• Duplicated block (12 lines × 3) (view/simple/src/main/kotlin/io/holunda/polyflow/view/simple/service/SimpleTaskPoolService.kt)
• Duplicated block (13 lines × 2) (integration/camunda-bpm/taskpool-collector/src/main/kotlin/io/holunda/polyflow/taskpool/collector/task/TaskServiceCollectorService.kt)
• Duplicated block (13 lines × 2) (integration/common/datapool-sender/src/main/kotlin/io/holunda/polyflow/datapool/sender/gateway/AxonCommandListGateway.kt)
• …and 31 more

• Context is only one sentence and lacks any problem statement (e.g. why an ADR convention matters) (specs/adr/000-adr-conventions.md)
• Dependency hygiene PARTLY measured — Maven/Gradle declarations read, no dependency graph resolved
• Documentation: no architecture or design documentation (docs/developer-guide/project-setup.md)
• Documentation: no architecture or design documentation (docs/reference-guide/components/view-jpa.md)
• Duplicated block (10 lines × 2) (view/jpa/src/main/kotlin/io/holunda/polyflow/view/jpa/JpaPolyflowViewDataEntryService.kt)
• Duplicated block (10 lines × 4) (view/mongo/src/main/kotlin/io/holunda/polyflow/view/mongo/MongoViewService.kt)
• Duplicated block (11 lines × 2) (view/jpa/src/main/kotlin/io/holunda/polyflow/view/jpa/JpaPolyflowViewTaskService.kt)
• Duplicated block (11 lines × 2) (view/mongo/src/main/kotlin/io/holunda/polyflow/view/mongo/Converters.kt)
• Duplicated block (11 lines × 2) (view/view-api/src/main/kotlin/query/task/TaskAttributeValuesQuery.kt)
• Duplicated block (11–12 lines × 4) (view/mongo/src/main/kotlin/io/holunda/polyflow/view/mongo/Converters.kt)
• Duplicated block (11–13 lines × 2) (view/simple/src/main/kotlin/io/holunda/polyflow/view/simple/service/SimpleDataEntryService.kt)
• Duplicated block (12 lines × 2) (view/mongo/src/main/kotlin/io/holunda/polyflow/view/mongo/process/ProcessDefinitionMongoService.kt)
• Duplicated block (12 lines × 4) (core/taskpool/taskpool-event/src/main/kotlin/io/holunda/camunda/taskpool/mapper/task/TaskEventMappers.kt)
• Duplicated block (13 lines × 2) (view/simple/src/main/kotlin/io/holunda/polyflow/view/simple/service/Converters.kt)
• Duplicated block (13–14 lines × 2) (view/mongo/src/main/kotlin/io/holunda/polyflow/view/mongo/Converters.kt)
• Duplicated block (14 lines × 2) (view/jpa/src/main/kotlin/io/holunda/polyflow/view/jpa/data/DataEntryRepository.kt)
• Duplicated block (14–15 lines × 3) (view/simple/src/main/kotlin/io/holunda/polyflow/view/simple/service/SimpleTaskPoolService.kt)
• Duplicated block (14–20 lines × 2) (integration/camunda-bpm/taskpool-collector/src/main/kotlin/io/holunda/polyflow/taskpool/collector/task/TaskServiceCollectorService.kt)
• Duplicated block (15 lines × 2) (integration/common/datapool-sender/src/main/kotlin/io/holunda/polyflow/datapool/sender/gateway/AxonCommandListGateway.kt)
• Duplicated block (16–17 lines × 3) (core/taskpool/taskpool-event/src/main/kotlin/io/holunda/camunda/taskpool/mapper/task/TaskEventMappers.kt)
• …and 62 more

• 42 commits — 41 feature/other, 1 fixes

• (repo) — 10 commits
• .github/workflows — 8 commits
• bom/parent — 8 commits
• integration/camunda-bpm — 6 commits
• (root) — 4 commits
• view/jpa — 3 commits
• integration/common — 2 commits
• view/pom.xml — 1 commit

• fix: Maven Fixes and JDK bump (#1295)
• change: Improve liquibase support (#1294)
• change: Liquibase support (#1290)
• change: Merge branch 'release/4.6.2'
• change: Merge branch 'release/4.6.3'
• change: Merge pull request #1297 from holunda-io/dependabot/maven/maven-patch-dependencies-71a2f52077
• change: Merge pull request #1298 from holunda-io/dependabot/maven/maven-minor-dependencies-32843da574
• change: Merge pull request #1299 from holunda-io/dependabot/github_actions/github/codeql-action-4.38.0
• change: Merge pull request #1301 from holunda-io/dependabot/maven/maven-patch-dependencies-ffc4e05bd2
• change: Merge pull request #1302 from holunda-io/dependabot/maven/maven-minor-dependencies-0f9ead576e
• change: Merge pull request #1303 from holunda-io/dependabot/github_actions/github/codeql-action-4.38.1
• change: Merge tag '4.6.2' into develop
• change: Merge tag '4.6.3' into develop
• change: Property based correlation and enrichment (#1292)
• change: Update for next development version
• change: Update for next development version
• change: Update for next development version
• change: Update for next development version
• change: Update release notes generator action version
• change: chore(deps): bump actions/setup-java from 5 to 6 (#1281)
• …and 22 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

holunda-io/camunda-bpm-taskpool was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.