Migration notes 3.2

This page explains the changes required to migrate to the stated version of the Atoti Limits.

Migrate to 3.2.0-BETA

Upgrading from version 3.1.0, see the Atoti Limits 3.2.0-BETA Release Notes.

Atoti Limits is using Atoti Server 6.0.11-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.

Headline announcement

• Atoti Server upgrade : Atoti Limits has been upgraded to Atoti Server .
• Spring Boot upgrade : We have upgraded Spring Boot to version 3.2.0, which uses Spring Framework 6.
• Common Parent POM and Common Dependencies BOM upgrade: The Common Parent POM and the Common Dependencies BOM have both been upgraded to version 2.0.0.
• Activiti upgrade : We have upgraded Activiti to version 8.1.0 to be compatible with Spring Boot 3.
• Changes to LimitsRetrievalUtil: The LimitsRetrievalUtil class, which previously contained static methods, has been converted to a Spring service name LimitsRetrievalService. If used in custom code then the methods of this class will need to be updated.

Breaking changes

• Upgrades:
  • The version of Spring Boot has been upgraded to version 3.2.0, which includes breaking changes. See the Spring migration guide for more information.
  • In order to be compatible with Spring Boot 3.2.0 we have upgraded Activiti to version 8.1.0. This requires including extension.json files with each workflow file. See Activiti upgrade for more information.

Spring Boot 3 upgrade

The main change in the Spring Boot 3 upgrade involves migrating javax.** imports to jakarta.xx imports.

Limits Auto-Configuration

In order for the Limits auto-configuration to work with Atoti Server using Spring 5 and Spring 6, the context path of the application is now derived from Spring’s server.servlet.context-path variable instead of from the application runtime. No migration is required unless you specify your context path in another way. If so, we recommend you use the server.root.url specified in Auto-configuration properties.

Activiti upgrade

Extension JSON files

In order to upgrade Activiti, you now need to supply an **-extensions.json file for each of your workflows. These extension files externalize information about the workflow and provide it to Activiti’s runtime engine. An example of some of the contents in the **-extension.json file may look as follows:

{
   "id": "PROCESS",
   "name": "PROCESS",
   "extensions": {
      "limit-process-instance.straight-through": {
         "properties": {},
         "mappings": {
            "start.event": {
               "mappingType": "MAP_ALL"
            },
            "approvedUserTask": {
               "mappingType": "MAP_ALL"
            },
            "deletedServiceTask": {
               "mappingType": "MAP_ALL"
            },
            "flow1": {
               "mappingType": "MAP_ALL"
            }
         },
         "constants": {}
      }
   }
}

In the example above:

• limit-process-instance.straight-through corresponds to the ID of a process definition. This maps to a single BPMN file.
• start.event corresponds to the ID of a Start Event.
• approvedUserTask corresponds to the ID of a User Task.
• deletedServiceTask corresponds to the ID of a Service Task.
• flow1 corresponds to the ID of a Sequence Flow.
• "mappingType": "MAP_ALL" tells Activiti to map all input and output variables throughout the workflow.

When upgrading, we added mappings for all Start Events, User Tasks, Service Tasks and Sequence Flows, and you will have to do the same for any custom workflows or customizations to our default workflows.

Custom Task Action Delegator

If you are customizing the IWorkflowTaskActionDelegator as outlined in Executing the Java Task, you may need to reload the LimitStructureDTO. Please see the DefaultWorkflowTaskActionDelegator::executeTaskActionForTaskActionKey method for an example of how this is done.

Changes to LimitsRetrievalUtil

The LimitsRetrievalUtil class has been converted to a Spring service named LimitsRetrievalService, to make our code more Spring-compliant. If you have custom code that used this class, you will need to update that code. A summary of the changes are as follows:

1. The methods have been made non-static. As such, to access the methods, inject the service where you need it and publicly invoke the methods. For cases when injection is not possible, for example in code outside your control, we have added the ApplicationContextProvider bean, which allows you to statically retrieve the service. See the LimitsLoadDataTxControllerTask::initializeSpringBeans method as an example of how you may do so.
2. We have centralized the datastoreVersion parameter used in most methods inside the LimitsRetrievalService. This parameter is now no longer required when calling the methods.
3. The term limitDefinition present in some methods has been renamed to limitStructure, to update old terminology. For example, the getLimitDefinitions() method is now named getLimitStructures().
4. The term limitEvaluation present in some methods has been renamed to limit, to update old terminology. For example, the getLimitEvaluations() method is now named getLimits().
5. When implementing a custom IAlertTaskManager, you now need to override the getLimitsRetrievalService() method.

Property Re-Location

The workflow properties which were previously defined in the UI settings have now been moved to the server side in application.yml, namely:

• exceptionWorkflowParticipants
• limitsWorkflowParticipants
• roles

Please see below for the new properties.

Input file formats

Modified

Removed

Configuration files

Files Modified

application.yml

New properties:

Deleted properties:

Datastores

Modified stores

Cube schema

Added

Modified

Removed

Measures

Removed

Context values

No changes.

Other changes

No changes.