Skip to main content

​
6.1.21 to 6.1.22

This release only shipped bug fixes and performance improvements. It does not require any migration.

​
6.1.20 to 6.1.21

This release only shipped bug fixes and performance improvements. It does not require any migration.

​
4.2.2 to 6.1.20

From version 6.1.20 onwards, Atoti Limits version numbers are aligned with the Atoti Java SDK. Previously, Atoti Limits used its own versioning (the last release under the old scheme was 4.2.2).The jump in version numbers reflects this alignment. There are no missing releases between 4.2.2 and 6.1.20.
Maven dependencies have changed: update the following group IDs in your pom.xml:
  • com.activeviam.solutions → com.activeviam.modules
  • com.activeviam.solutions.limits → com.activeviam.modules.limits
  • com.activeviam.solutions.services → com.activeviam.modules.services

​
4.2.1 to 4.2.2

​
Scheduled evaluation properties

The properties used to configure the scheduled INTRADAY limit evaluation have been replaced. The old properties are deprecated and will be removed in a future release, but still function as a fallback if the new properties are not set.
You do not have to migrate these properties now, but we recommend doing so to reduce future upgrade efforts.
Old Property (deprecated)New Property
limits.alert-task.sample-rate-cronlimits.evaluation.scheduler.cron-expression
limits.task-scheduler.thread-pool-sizelimits.evaluation.scheduler.thread-pool-size
To migrate, replace the old properties in your application.yml: 
# Before (deprecated)
limits:
  alert-task:
    sample-rate-cron: 0 */5 * * * *
  task-scheduler:
    thread-pool-size: 4

# After
limits:
  evaluation:
    scheduler:
      cron-expression: 0 */5 * * * *
      thread-pool-size: 4
If both old and new properties are set, the new property (limits.evaluation.scheduler.*) takes precedence.

​
Limit repository change

The Atoti Limits codebase now lives within the Atoti Server codebase, which streamlines dependency management. This means that the Atoti Limits pom now inherits from 
<parent>
    <groupId>com.activeviam.modules</groupId>
    <artifactId>workflows</artifactId>
</parent>
where the version is aligned with the version of Atoti Server used by Atoti Limits, which for this release is 6.1.19. Please update your pom parent to this artifact. The pom file no longer requires the common-parent-pom, common-dependencies-bom or common-spring-services-bom, so you can remove these.

​
4.2.0 to 4.2.1

​
Connected server configuration

Server name property for connected servers with default catalog name
Previously, if-and-only-if the limits.autoconfiguration.server-name property was not defined and the connected Atoti Server used the default catalog name (Catalog), Atoti Limits would use this default catalog name as the primary way to identify the connected server. This usually led to issues when connecting to Atoti Limits and creating limits. Now, if the connected Atoti Server uses the default catalog name (Catalog) then you must define the limits.autoconfiguration.server-name property, or else the connection will fail with an exception. To resolve this, set the limits.autoconfiguration.server-name property in your connected Atoti Server’s configuration file (e.g. application.yml): 
limits:
  autoconfiguration:
    server-name: <your-server-name>
This will be used when creating limit structures to verify that the server for your structure is a valid, connected server. For more information on the available properties, see the limits integration common properties.

​
4.1.1 to 4.2.0

This guide explains how to migrate Atoti Limits from versions 4.1.1 to 4.2.0. This migration guide focuses on breaking changes. Consult the Atoti Limits 4.2.0 release notes and changelog for a complete view of changes.
  1. Back up your project.
  2. Automatically migrate your code and/or data using the Atoti Limits migration tool.
  3. Perform a diff between older Atoti Limits release builds and newer release builds.
    • Update your dependencies.
    • Update your code.
  4. Confirm successful build and startup.

​
How do I use the Atoti Limits migration tool?

The migration tool doesn’t account for customizations nor does it account for all required changes. It is used as a helper to automate part of the migration process.
The Atoti Limits migration tool is shipped with the Atoti Limits distribution files in the limits-migrations folder. It is a script written in Java that automates part of the migration process by updating your code and/or data to be compatible with the latest version of Atoti Limits.

​
How does the Atoti Limits migration tool work?

In general, the tool is installed and run as follows:
  1. cd limits-migrations
  2. Run mvn clean install
  3. Run java -jar path/to/limits-migrator-tool-exec.jar <target-version> <other-args>
Replace <target-version> with the version you are migrating to (e.g. 4.2.0), and <other-args> with the version specific arguments accepted by the migration tool for the target version. See the following section for more details.

​
4.2.0 migration script

This migration script updates the following files from Atoti Limits 4.1.x to 4.2.x:
  • limit_structures*.csv: Adds new columns Limit Workflow Variables and Incident Workflow Variables.
  • limits_approve*.csv: Renames the LimitValues column to Limit Value. Adds a new column Limit Changes Workflow Variables.
  • incident*.csv: Adds a new column Limit Type.
The original files are backed up in a separate folder, which you can delete after completing your migration. All new columns will be initialized as empty. This script expects the following program arguments (in this order):
  1. The target version of Atoti Limits, which should be 4.2.0
  2. The glob pattern of the structure files to be migrated, for example *.csv or **/*structures*.csv.
  3. The glob pattern of the limit files to be migrated, for example *.csv or **/*limits_approve*.csv.
  4. The glob pattern of the incident files to be migrated, for example *.csv, **/*incidents*.csv or **/2025-12-09/incidents/*.csv.
  5. The root folder of the files, for example ./data or /path/to/data.

​
What dependencies have changed?

The following dependency changes are required for migrating Atoti Limits 4.1.1 to Atoti Limits 4.2.0.

​
Updated

DependencyAtoti Limits 4.1.1Atoti Limits 4.2.0
workflow-service-2.0.0

​
How do I migrate my project?

The following information is applicable for migrating Atoti Limits 4.1.1 to Atoti Limits 4.2.0.

​
Low-Code/No-Code

If you are using Atoti Limits 4.1.1 in a low code/no-code setup and migrating to Atoti Limits 4.2.0, you’ll need to know high-level changes. This section focuses on the high-level changes when migrating, such as configuration/property, data model, cube, and dashboard changes.

​
Loading data

Moving from the DLC to the new file loading service
In order to migrate your initial load configuration from the DLC to the new file loading service, you need to update the following properties in your application.yml file:
Old (DLC) Property NameNew Property NameComment
limits.dlc.root-dirlimits.initial-load.root-dirThe path to the directory containing the CSV files to load.
limits.dlc.path-matchers.limitslimits.initial-load.file-path-matchers.limitsThe pattern to identify the CSV files containing limits.
limits.dlc.path-matchers.limitstructureslimits.initial-load.file-path-matchers.limit-structuresThe pattern to identify the CSV files containing limit structures.
limits.dlc.path-matchers.incidentslimits.initial-load.file-path-matchers.incidentsThe pattern to identify the CSV files containing incidents.
limits.dlc.path-matchers.asofdatelimits.initial-load.file-path-matchers.as-of-dateThe pattern to identify the CSV files containing AsOfDates.
The following properties do not have an equivalent in the new configuration and can be safely removed:
Service/Configuration Class
com.activeviam.limits.cache.cube.cfg.source.IDataLoadControllerConfig
com.activeviam.limits.cache.cube.cfg.source.ICSVSourceConfig
If you have customized the DLC configuration in Atoti Limits by overriding the default implementations of these configuration classes, you will need to replace your custom DLC beans with a custom implementation of the ILimitsFileLoadingService interface. See How to customize the file loading service for more details on how to override the default service. Once you have created your custom ILimitsFileLoadingService implementation that mirrors the behavior of your previous DLC configuration, you can safely remove all DLC-related configurations from your project.
Date roll via file no longer supported
With the removal of the DLC, rolling the date by sending the updated AsOfDate file to the DLC endpoint is no longer supported. Please use the Limits asOfDate endpoint to roll the date instead.
Managing Workflows
If you have made customizations to the default workflows then you will need to update them to conform to the new workflow service.