Property to Disable Workflow Server CleanInTranslation Job

Added new configuration property workflow.blueprint.clean-in-translation.enabled in Blueprint class com.coremedia.blueprint.workflow.boot.BlueprintWorkflowServerAutoConfiguration as option to disable the Workflow Server’s CleanInTranslation background job. It defaults to true, which keeps it enabled as in previous releases. The default value will change to false in future releases.

The CleanInTranslation background job is not necessary and can be disabled if all used translation and localization processes use the CleanInTranslationFinalAction in their process definition, which is recommended. For details, see the Blueprint Developer Manual, section “CoreMedia Blueprint - Functionality for Websites | Workflow Management | Translation Workflow | Configuration and Customization”.

You can check whether CleanInTranslation is enabled or disabled in the Workflow Server log. If enabled, it will log an INFO message at startup time containing Scheduling CleanInTranslation. If no such message is logged after start, then CleanInTranslation is disabled.

(CMS-30617)

Updated Project Dependencies

Updated several dependency and plugin versions:

Preceding release for the documented updates is 2512.0.2.

(CMS-30522)

Forking Multiple Subworkflows and Dynamic Variable Assignment

The Workflow Server now allows workflow definitions to fork multiple workflow subprocesses at once in a <ForkSubprocess> task, and then join them again using one <JoinSubprocess> task. Furthermore, variables of a forked subprocess can now also be assigned dynamically from a struct value that is provided by the parent process. For details, see the documentation of the <ForkSubprocess> and <AssignStruct> XML elements in the Workflow Manual, chapters “Reference | XML Element Reference” and “Customize Workflow Definitions | Defining Workflows | Subworkflows”.

(CMS-30137)

Declare Variant-Stable Properties in the Content Type Definition Schema

Variant-stable properties can now be declared directly in the content type definition schema using the attribute extensions:variantStable:

<StringProperty Name="segment" extensions:variantStable="true"/>

Schema annotations are the preferred way to declare stable properties, as they keep the stability semantics co-located with the content type definition and need to be declared in only one location. As a fallback, stable properties can also be configured per content type via the configuration property variant.model.stable-properties-by-type for each application. See documentation for details.

Deprecation: The configuration property variant.model.stableProperties is deprecated. Use extensions:variantStable="true" in the content type definition schema (preferred), or migrate to variant.model.stable-properties-by-type for configuration-based setup.

The properties based configuration has been refactored to the content type schema configuration. The deprecated configuration variant.model.stable-properties=externalId has moved to variant.model.stable-properties-by-type.Document_=externalId. Any customization should be reviewed.

(CMS-29671)

Content Feeder Reindexing Order Of Content Items Changed

When reindexing Content in the Content Feeder, content items are now ordered by id descending instead of ascending. Higher content id means, the content has been created later, so now the content created last will be indexed first. Both, actuator endpoint and JMX operation provide an option to change the order to ascending (lowest ids first).

(CMS-29073)