Add Validation Endpoint with Configurable Category, Entity, and Field Validation

[Azher2Ali]

Description

This feature introduces a configurable endpoint to validate the existence of a record with a specified value. It supports checks within a specific category, organization, and entity to ensure data integrity by preventing duplicates and confirming the presence of required records.

Key Features:

Validation Endpoint:
Path: /validator/category/{categoryId}/entity/{entityName}/exists?organization={organization}&value{value}

Method: GET
Behavior:

If the record exists in the submitted_data table, returns 200 OK with body:

{
  "message": "Record found"
}

If the record does not exist, returns 404 Not found with an error response:

{
   "error": "Not found",
   "message": "The specified value was not found"
}

Configuration Requirements:

• Added configuration properties in AppConfig to define the valid combinations of category, entity, and field.
• Requests to the endpoint validate that category, entity, exist in the configuration. If not, returns a 400 Bad request with error response:

{
   "error": "Bad Request",
   "message": "Validation is not enabled for categoryId '${categoryId}' and entityName '${entityName}'"
}

Implemented Changes:

• Added router ValidatorRouter for routing the new endpoint.
• Created a ValidatorController to handle the new endpoint.
• Developed a ValidationService to check records in the submitted_data table.
• Defined data models for ValidationRequest and ValidationResponse.

Configuration Validation Behavior

• Ensures the categoryId, entityName, and fieldName combinations are present in the configuration.
• Returns 400 Not Found if validation fails.
• This feature is crucial for applications needing configurable record validation, offering flexibility while ensuring strict data integrity standards.

Related issues:

• issue External validation endpoint #109
• issue Configuration of external validation endpoint #110

[leoraba]

Left some comments but more importantly about the configuration part. Also more details on issue #110

[joneubank]

Looks generally good to me now that all required files are here. I'll leave it to @leoraba to give final approval on this.

[joneubank]

Looks good, accomplishes our initial design goal. I think we need to update this design slightly for how we configure the end point, but that will require an additional task. This is good to be merged.

[joneubank]

This is a good system and does what we agreed to do, but we'll need to revisit this approach... since the categories are added as data, the validation endpoints also need to be configurable as data. This solution requires a system admin to update the config and restart the service after the category is added so that this can communicate with song.

After merging this work, let's make an additional ticket to move this info to the DB and add an endpoint to configure this per category.

[leoraba]

created ticket #150 to detail the work refactoring this configuration.

[joneubank]

This works fine, but is some very awkward syntax to work with as a developer... does the SQON builder client not work for this?

Something like:

const filterSqon = SQONBuilder.in(field, value);

[leoraba]

This could also be separated in 2 parts for better understanding:

const sqonFilter = SQONBuilder.default.in(field, value);
const sqlFilter = convertSqonToQuery(sqonFilter);

I've changed the code to address this.

[joneubank]

In general, functions signatures should declare their return types. Its good practice to be explicit about what you intend to return. In this case, its helpful to see that this could return undefined for the case where no match is found.

[leoraba]

Added return type ValidatorEntry | undefined as suggested.