Migrate to 6.1.1
Upgrading from version 6.1.0, see Atoti Sign-Off 6.1.1 Release Notes. Atoti Sign-Off is using Atoti Server 6.1.4, Atoti UI ~5.2.6, and Sign-Off API 4.2.0 . For new features and fixes included in these releases, please see:- Atoti UI documentation and Atoti UI Migration Notes
- Release notes for Atoti Server
- Release notes for Signoff API
Headline announcement
This is a maintenance release that includes bug fixes and performance improvements.Configuration properties
Files modified
application.yml
Updated properties:Migrate to 6.1.0
Upgrading from version 6.0.0, see Atoti Sign-Off 6.1.0 Release Notes. Atoti Sign-Off is using Atoti Server 6.1.4, Atoti UI ~5.2.6, and Sign-Off API 4.2.0 . For new features and fixes included in these releases, please see:- Atoti UI documentation and Atoti UI Migration Notes
- Release notes for Atoti Server
- Release notes for Signoff API
Headline announcement
- Starter changes: Multiple classes have been removed from the starter module. See Starter changes for more details.
- Package restructure: The package structure in the
signoff-activeviammodule has been reorganized to improve maintainability. See Package changes for more details. - Validation error changes: A new method has been added to the API for validation errors to support accurately reporting indexes. See Validation error changes for more details.
- Workflow Service API changes: The
ISignOffProcessDefinitionWorkflowServiceandISignOffProcessInstanceWorkflowServiceAPIs have been updated and a new method has been added to accommodate workflow file attachments. See Workflow Service API changes for more details. - Application server communication changes: Atoti Sign-Off has changed how it communicates with the application server. See Application server communication changes for more details.
- Exact location required for adjustments: Adjustments can only be performed at the exact location defined by the filters in
SupportedAdjustmentDTO.
Exact location required for adjustments
Adjustments can only be made at the specific locations defined by the filters inSupportedAdjustmentDTO instances. If a filter is not explicitly specified in the supported adjustment configuration, the corresponding value at that location cannot be adjusted.
If you want to display a hierarchy in the UI during adjustment, even if it isn’t directly related to the adjustment logic, include it as an optional filter.
Starter changes
Most of thesignoff-starter module has been moved into signoff-activeviam. The goal of these changes is ultimately to improve the developer experience when
migrating, particularly in the context of client customizations.
The following classes have been migrated from signoff-starter to signoff-activeviam:
The following classes have been migrated from
signoff-starter to signoff-activeviam and renamed to better reflect their purpose:
Any beans exposed by these classes have been annotated with
@ConditionalOnMissingBean which allows you to define your own implementations to override the
defaults. See the Getting Started guide for more information.
Package changes
The packages in thesignoff-activeviam module have been reorganized to improve maintainability. The table below lists the classes affected by this change. If
you have custom classes that depend on any of these classes, you will need to update the package imports accordingly.
Validation error changes
A new method has been added toIValidationError and an existing method was removed.
New method added
IValidationError, you will need to implement this method in your custom class. This method allows for the index set on
the errors to be updated after the errors are initially created. This is important because all validation errors in the default validators are initially created
with an index of 0 since the validation is performed on a single object at a time. If the validator is invoked in the context of a list of objects, such as
from the SignOffDefinitionListConstraintValidator or SignOffAdjustmentListConstraintValidator, the indexes on the resulting errors need to be updated to
reflect the actual index of the object in the list.
Removed method
ThegetAction() method has been removed from IValidationError. All information about the error, including any recommended resolution steps, should now be
provided in the getReason() method. If you have a custom implementation of IValidationError, you can safely remove the getAction() method.
Workflow service API changes
To support file attachments in the Atoti Sign-Off workflows, the methods associated with workflow actions inISignOffProcessDefinitionWorkflowService and
ISignOffProcessInstanceWorkflowService have been updated to include a variables parameter of type Map<String, Object> that is used to store a reference to
the saved file. A new method, processInstanceHistory, has also been added in both APIs to support retrieving these workflow variables as part of the workflow
history. If you have a custom implementation of these interfaces, you will need to update the existing method signatures and implement the new
processInstanceHistory method to match the updated APIs:
ISignOffProcessDefinitionWorkflowService
ISignOffProcessDefinitionWorkflowService
ISignOffProcessInstanceWorkflowService
ISignOffProcessInstanceWorkflowService
IWorkflowTaskActionsService new method
A new method getWorkflowTaskActions(UserTask task, String activitiProcessId) has been added to the IWorkflowTaskActionsService. This is to support
retrieving the workflow variables associated with a task so that file attachments can be retrieved as part of the history records.
If you have a custom implementation of IWorkflowTaskActionsService, you will need to implement the new method:
Application server communication changes
Previously, Atoti Sign-Off communicated with the application server using a customRestTemplate that was configured to use basic authentication. This was
configured in RestTemplateConfiguration. To conform with more modern Spring APIs and to improve extensibility, this has been replaced with a
RestClient.Builder bean that is exposed via ISignOffRestClientBuilder.
ISignOffRestClientBuilder
ISignOffRestClientBuilder
RestClient.Builder for each server that Atoti Sign-Off connects to, allowing you to build and send authenticated requests to the
Atoti servers. We use a builder pattern to allow for easy configuration of the RestClient instances, such as setting the URL, authentication, and custom headers.
By default, the RestClient.Builder is configured to use JWT authentication with the credentials defined in the sign-off.application.rest-apis.* properties.
You can revert this to use Basic authentication by setting the sign-off.application.authentication-mode property to basic.
JWT authentication requires that only a username is present, so you can now remove any passwords from your application.yml files if you continue to use the
JWT authentication.
Configuration properties
Properties added
signoff-activeviam
Files modified
application.yml
New properties:
Deleted properties:
Other changes
Validation error changes
The structure of validation errors has been streamlined to improve readability and usability. If you have custom validation errors in your project, you’ll need to migrate them accordingly.IValidationError changes
- new method added:
String getFieldName()- returns the name of the field containing the error. - method
getLineNumber()was renamed togetIndex(). - method
getColumnIndex()was removed and replaced bygetFieldName(). - method
getSource()was removed.
Spring configuration changes
The primary configuration class for thesignoff-actieviam module is now SignOffCoreAutoConfiguration which is a Spring AutoConfiguration
class. Most of the imports from SignOffAppConfig in the starter module have been moved to this new autoconfiguration class.
Additionally, many service imports have been removed in favor of exposing the services as Spring beans marked as @ConditionalOnMissingBean, making them easier
to override if you want to implement a custom service. To override a default service implementation, create your own implementation of the respective
interface and expose it as a Spring bean. The @Primary annotation is no longer required if the bean for the default implementation is marked as
@ConditionalOnMissingBean.