This section describes how to create custom validators, validation errors, and validation error handlers in Atoti Limits.
Limit structures, limits, and incidents
are validated whenever they are created or updated. The default implementations of these validation interfaces provide reasonable
checks to promote data quality, but you may wish to customize or extend these checks to suit your organization’s needs.
Implementing custom validation is not required, but it can be useful for enforcing business rules or data quality standards.
Additionally, any single component or combination of these components can be customized, and any components not customized will use default implementations.
For example, you could choose to implement a custom ILimitValidator but use DefaultLimitStructureValidator and DefaultIncidentValidator.
Alternatively, you could choose to implement a custom IValidationErrorHandler that overrides DefaultValidationErrorHandler in the default validators.
A note on the default validation behavior
The default implementations of the validation interfaces are agnostic to the source of the data being validated. However, there is different behavior
for limits loaded through the DLC and limits loaded through REST, like file upload. When limits are loaded through the DLC, the validation is non-blocking,
meaning that the system will proceed with publishing the valid limits even if some fail validation. When limits are loaded through REST, the validation is
atomic, meaning that the system will not publish any limits if even one fails validation.
This is because errors with limits loaded through the DLC are likely to be addressed by an administrator/developer
and should not block business users. However, loading through the UI (file upload) is more likely to be done by a business user and needs to have better
enforcement of data integrity.