Updates since 3.3 Beta

This page lists the changes since 3.3.0-BETA, and explains any changes required to migrate from 3.3.0-BETA to the stated version of Atoti Limits.

Changes since 3.3.0-beta

Added

Changed

Removed

Fixed

For Removal

Fixed issues introduced in 3.3.0-BETA

Migrate to 3.3.0 from Beta

Upgrading from version 3.3.0-beta, see Atoti Limits 3.3 Release Notes.

Atoti Limits uses Atoti Server 6.0.14-sb3 and Atoti UI 5.1.x. For new features and fixes included in these releases, please see the Atoti UI documentation and Atoti UI Migration Notes, and the release notes for Atoti Server.

Summary

• Validation API Improvements : Additional methods have been added to IValidator to make it easier to interact with the validators. For more details, see IValidator changes.
• Modified Default Validation Behavior : The default validation behavior has been updated to be non-blocking for limits loaded through the DLC. Loading through REST (i.e. file upload) is still an atomic operation.
• Custom Evaluations : The IEvaluationService and IEvaluationTaskManager interfaces have been introduced to facilitate custom evaluation logic. See Adding Custom Evaluation Logic for more information.
• Migration scripts : We have added a new limits-migrations module for migrating CSV files. See CSV and properties migrations to 3.3.0.

Breaking Changes

Managed Object ID behavior

The behavior has changed for how IDs are used in Atoti Limits. Previously, for each structure, limit, or incident, a *key field was generated using a hash of that object’s key fields. Now we expect the following:

• when the user creates a structure/limit/incident using the DLC or the UI file upload, we expect the ID to be populated in the file.
• when the user creates a structure/limit/incident, we don’t expect the ID to be populated and instead we will auto-generate it on the server using implementations of IIdentityGenerator.

This behavior was introduced to simplify the user experience, to enhance data integrity, and to prevent potential hash-collisions.

Starter customizations

If you previously modified the data loading or cube configuration code in the limits-starter module then you will have to migrate that code. Please see the dev extensions section for how to do so.

Split of IAlertTaskManager

The IAlertTaskManager interface has been replaced with two interfaces to separate evaluation logic from scheduling logic. If you have a custom implementation of IAlertTaskManager, you will need to replace it with implementations of one or both of IEvaluationService and IEvaluationTaskManager. For more information on the new interfaces and how to implement them, see Adding Custom Evaluation Logic.

Entity field type changes

The following entity fields have been converted from arrays to singular values:

If you persist these in a database then the column type should be updated accordingly.

*ActivePivot* classes renamed to *AtotiServer*

Classes that follow the naming convention *ActivePivot* have been renamed to match *AtotiServer*. If you have any custom code that references these classes, you will need to update them.

UI Settings change

The availableApplicationServers setting has changed from a record to an array of server keys. AsOfDate settings that used to sit under this property are now supplied by the server, and therefore no longer need to be provided in the UI settings.

CSV and properties migrations to 3.3.0

The migration script migrates the limit_structures.csv files and limits.csv files from Atoti Limits 3.2.0 to 3.3.0. For details on how it works, see the 3.3.0 Migration Notes.

Input file formats

No changes.

Configuration files

The following *.properties property files have been deleted. Properties still in use have been moved to @ConfigurationProperties classes or application.yml:

• env-default.properties
• jwt.properties
• limits.properties
• limits_test.properties
• tracing.properties

Files Modified

application.yml

New properties:

Datastores

Modified stores

Cube schema

The limitKey hierarchy has been renamed to limitId.

Measures

No changes.

Context values

No changes.

Other changes

IValidator changes

The following methods have been added to the IValidator interface. If you previously implemented a custom IValidator class, you will need to update it to include these methods. If you have not implemented a custom IValidator class, you do not need to make any changes.

/** Operations to be performed before validation is started. */
void preValidation(Collection<T> objectsToValidate);

/**
 * @return true if validation succeeds for the tuple, false otherwise
 */
boolean validateTuple(Object[] tuple, int lineNumber);

/**
 * @return objects that have passed validation
 */
List<T> getValidObjects();

/**
 * @return objects that have failed validation
 */
List<T> getInvalidObjects();

/**
 * Clears the state of the validator, so it is ready to validate a new set of objects.
 *
 * @param throwException if true, an exception will be thrown if there are validation errors
 */
void reset(boolean throwException);

/**
 * @return true if there are validation errors, false otherwise
 */
boolean hasErrors();

The intent behind these changes is to have the validators keep better track of their state. This allows for better separation between validation logic and handling of valid/invalid objects. getValidObjects, getInvalidObjects and hasErrors allow calling code to access the state of the validator, and reset is used to clear the state of the validator between validation operations.

Additionally, to pair with the existing postValidation method, we have added a preValidation method to the IValidator interface. This method is called before the validate/validateAll methods and can be used to perform any pre-validation checks or operations. The default implementations of IValidator included with Atoti Limits have been updated to include an implementation of preValidation that populates a map of row indexes by ID to help with reporting line numbers for validation errors.

A validateTuple method has also been added to the IValidator interface. This method is called for each tuple in a file being validated. This allows for more fine-grained control over the validation process, validating tuples prior to converting them to objects.

Changes to ILimitsProcessInstanceWorkflowService

You will need to modify the update method to the new signature which includes the additional publishTuples and refreshKpis parameters.