Introducción

Esta funcionalidad permite asociar tanto a Entidades (a nivel general) como a atributos de estas, reglas que permita comprobar la integridad de un dato como normalizar los datos a la entrada de los datos de forma sencilla, a esta funcionalidad la hemos llamado Data Classes.

Cómo usar los Data Class

Configuración centralizada DATACLASS

Las reglas se definen como un nuevo tipo de configuración centralizada, DATACLASS, donde se podrán definir reglas de validación y formato del dato, permitiendo así ejecutar un preprocesado antes de insertar los datos.

Este preprocesado permitirá definir mensajes de error que se insertarán en la entidad de auditoría del usuario, facilitando así la visualización de los datos fallidos y estadísticas de carga en un dashboard.

Para crear las reglas será necesario seguir el siguiente formato al crear el fichero de configuración:

...

Tipos de reglas

Como se puede observar, existen dos tipos de reglas, las property, que irán directamente relacionadas con un campo/propiedad de la entidad, y las entity, que serán reglas que relacionen distintas propiedades de una entidad.

Dentro de cada regla se distinguen dos tipos, las de validación y las de cambio de formato:

• Changes. Estas reglas son de cambio o corrección de formato, por ejemplo convertir a mayúsculas, minúsculas, corregir un texto… Por lo que será necesario indicar el orden de ejecución. Los campos a definir serán:

  • name: nombre del cambio de formato.

  • order: el orden de ejecución.

  • script: el código en javascript o groovy para procesar el cambio. Habrá que poner en primer lugar el lenguaje utilizado, groovy o javascript, y hay que tener en cuenta que value será la nomenclatura para el valor a cambiar.

Existe la opción de prescindir del uso de código javascript/groovy, siempre que el cambio sea sencillo del tipo condición/efecto. Para ello, habrá que rellenar los campos condition, effect y else, este último si fuese necesario, en vez del script.

• Validations. Estas reglas normalmente devolverán un verdadero o falso, dependiendo de si se cumple la condición o no, por ello se deberá indicar el tipo de error y el mensaje de error si la condición necesaria no se cumple. Los campos a rellenar serán:

  • name: nombre de la validación

  • script: código en javascript o groovy a ejecutar para validar el dato. Habrá que poner en primer lugar el lenguaje utilizado, groovy o javascript, y hay que tener en cuenta que rawdata será la nomenclatura para el json de inserción.

  • error: el tipo de error, puede ser error si se desea interrumpir la inserción de los datos, o warning si aunque falle se quiere seguir insertando el dato.

  • errormsg: mensaje que quieres que aparezca cuando no se cumple la regla de validación. Se puede mostrar el valor de la propiedad a editar o a validar, poniendo ${value} en el caso de que la regla sea de tipo property, o ${rawdata.dni} en el caso de que la regla sea de tipo entity (dni o la propiedad deseada del json de insercción).

Cómo asociar una DataClass a una Entidad

Para usar estas reglas, habrá que asociarlas a la entidad en la que queremos hacer ese preprocesado, por ello cuando se cree o edite una entidad, habrá dos opciones nuevas:

• Un check para habilitar o deshabilitar el preprocesado de reglas:

...

• Un selector múltiple donde poder elegir las reglas existentes a nivel de ontología:

...

• Un selector múltiple por cada propiedad, donde se podrán seleccionar las reglas de propiedad que existan:

...

De esta forma, cuando hagamos una inserción de datos en la ontología, se ejecutarán los cambios de formato y se comprobarán las reglas de validación antes de pasar a la inserción.

Auditoría

Todos los errores que se produzcan al ejecutar una regla de validación se insertarán en la ontología de auditoría del usuario (Audit_nombreUsuario).

...

Entre todos los campos que existen al guardar los errores de auditoría destacaremos los siguientes:

...

errorMessage: Indica que el error se ha producido en al insercción, y seguidamente mostrará el mensaje que se ha introducido en el dataclass donde se define esa validación

...

methodName: siempre será dataClassError, pudiendo así identificar todos los errores de preprocesado de datos con los dataclass.

...

type: indica si es un error o un warning.

...

formatedTimeStamp: indica la fecha y hora en el que se produjo el error.

...

user: el usuario que ha realizado la insercción de los datos.

...

Introduction

This functionality allows you to associate both Entities (at a general level) and their attributes, rules that allow you to check the integrity of a data and normalize the data to the data entry in a simple way. We have called this functionality Data Classes.

How to use the Data Class

DATACLASS centralized configuration

Tules are defined as a new type of centralized configuration, DATACLASS, where validation rules and data format can be defined, thus allowing preprocessing to be executed before inserting the data.

This preprocessing will allow you to define error messages that will be inserted into the user's audit entity, thus facilitating the visualization of failed data and showing load statistics on a dashboard.

To create the rules, it will be necessary to follow the following format when creating the configuration file:

...

Rule types

As can be seen, there are two types of rules, the property, which will be directly related to a field/property of the entity, and the entity, which will be rules that relate different properties of an entity.

Within each rule, there are two types, validation rules and format change rules:

• Changes. These rules are for changing or correcting the format, for example, converting to uppercase, to lowercase, correcting a text... Therefore, it will be necessary to indicate the order of execution. The fields to be defined will be:

  • name: name of the format change.

  • order: the order of execution.

  • script: The JavaScript or Groovy code to process the change. It will be necessary to say in the first place the language used, Groovy or JavaScript, and you must bear in mind that value will be the nomenclature for the value to change.

There is the option to dispense with the use of JavaScript/Groovy code, as long as the change is a simple condition/effect type. To do this, the condition, effect and else fields must be filled in, the latter if necessary, instead of the script.

• Validations. These rules will normally return true or false, depending on whether the condition is met or not, so the type of error and the error message should be indicated if the necessary condition is not met. The fields to fill in will be:

  • name: name of the validation.

  • script: JavaScript or Groovy code to execute to validate the data. It will be necessary to say in the first place the language used, Groovy or JavaScript, and it must be taken into account that rawdata will be the nomenclature for the insertion JSON.

  • error: the type of error. It can be error if you want to interrupt the insertion of the data, or warning if you want to continue inserting the data even if it fails.

  • errormsg: message that you want to appear when the validation rule is not met. You can show the value of the property to be edited or validated, with ${value} in the case that the rule is of the property type, or ${rawdata.dni} in the case that the rule is of the entity type (DNI or the desired property of the insert JSON).

How to associate a DataClass to an Entity

To use these rules, you have to associate them to the entity in which you want to do this preprocessing, so when an entity is created or edited, there will be varias new options:

• A check to enable or disable rule preprocessing:

...

• A multiple selector where you can choose the existing rules at the ontology level:

...

• A multiple selector for each property, where you can select the property rules that exist:

...

In this way, when we insert data into the ontology, the format changes will be executed and the validation rules will be checked before proceeding to the insertion.

Audit

All errors occuring when executing a validation rule, will be inserted into the user's audit ontology (Audit_UserName).

...

Among all the fields that exist when saving audit errors, we will highlight the following:

• errorMessage: indicates that the error has occurred during the insertion, and then shows the message that has been entered in the dataclass where that validation is defined.

• methodName: will always be dataClassError, thus being able to identify all data preprocessing errors with the dataclass.

• type: indicates whether it is an error or a warning.

• formatedTimeStamp: indicates the date and time when the error occurred.

• user: the user who inserted the data.

• ontology: the target ontology where the insertion was being made.