Adding Custom Validation

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.

Checks performed in the default validators

This section describes the validation performed by the default validators for limit structures, limits, and incidents.

Default limit structure validation

Field	Validation performed
Structure ID	Value must be non-null, non-empty, and unique. This field is validated regardless of the ID being provided or generated.
Name	Value must be non-null, non-empty, and unique.
Server Name	Value must be a valid server name in the current list of connections to Atoti Limits.
Cube Name	Value must be a valid cube name in the current list of cubes for the specified server.
Measure Name	Value must be a valid measure name in the specified cube OR a calculated measure saved in the content server.
Scope Keys	Value must contain the name of at least one level, and all levels expressed must exist in the specified cube.
Polling Frequency	Value must be a valid PollingFrequency enum (EOD or INTRADAY).
KPI Type	Value must be either Greater Than or Less Than.
Limit Changes Workflow Parameters	If the value for Limit Changes Workflow is StraightThrough or not provided (will default to StraightThrough), this field can be null. For all other workflow types, this field must be a valid map containing at least one field+value pair.

Default limit validation

Field	Validation performed
Limit ID	Value must be non-null, non-empty, and unique. This field is validated regardless of the ID being provided or generated.
Structure ID	Value must be a valid ID for an existing limit structure.
Scope	If the scope is aggregated (see advanced scopes), the structure this limit is being created on must not contain any live limits. Similarly, attempting to create a limit with any scope on a structure that contains an existing limit with an aggregated scope will result in a validation error.
Start Date	Value must be a valid date in ISO-8601 format (yyyy-MM-dd).
End Date	If provided, value must be a valid date in ISO-8601 format (yyyy-MM-dd) and must not fall before the Start Date.
Limit Type	Value must be a valid LimitType enum (OFFICIAL or TEMPORARY).

Limit overlapping date validation

The default limit validator also checks for overlapping dates between limits. Limits are considered to overlap if they have the same Structure ID, Scope, and LimitType AND if there is even a single day of overlap between the date ranges represented by each limit’s Start Date and End Date.

Temporary limit validation

In addition to the checks above, temporary limits require some extra validation:

• End Date must be provided. The overlapping date validation still applies to temporary limits.
• Source Limit ID must be provided and the value must be a valid ID for a limit with Limit Type = OFFICIAL.

Default incident validation

Field	Validation performed
Incident ID	Value must be non-null, non-empty, and unique. This field is validated regardless of if the ID was provided or generated.
Limit ID	Value must be a valid ID for an existing limit.