Validación

La validación es una parte importante de la ISO20022 Modelo de mensaje. Existen numerosos niveles de "validez" que pueden aplicarse a un mensaje, y estos niveles están en aumento. A menudo, diferentes componentes de software realizan distintas verificaciones de nivel de validación.

ISO20022 Niveles de Validación

La tabla a continuación muestra la enumeración de Validez de Mensaje exactamente como se especifica por el ISO20022 En el Meta-Modelo, también hemos incluido notas adicionales de calificación y describimos qué componente de software IPF estaría involucrado en la confirmación de cada Nivel de Validación.

Nivel de validación

Descripción de ISO20022

Implementación de IPF

Componente IPF relacionado

NO_VALIDATION

La instancia del mensaje no está validada.

Algo que no es sintácticamente válido no puede asumirse como analizables, se produce un error en la capa de deserialización.

XMLMapper or JsonMapper

SYNTAX_VALID

La instancia del mensaje tiene su sintaxis validada.

La sintaxis válida simplemente significa que el mensaje ha sido deserializado con éxito en un Java representación.

XMLMapper or JsonMapper

SCHEMA_VALID

La instancia del mensaje es Sintaxis Válida y se ha validado contra el Esquema de Mensaje XSD.

Message Component Validator

MENSAJE_VÁLIDO

La instancia del mensaje es válida según el esquema y validada contra las reglas del mensaje.

Esta es la aplicación de la ISO20022 Restricciones sobre Componentes de Mensaje y Tipos de Datos

Message Component Validator

REGLA_VÁLIDA

La instancia del mensaje es Mensaje Válido más validado contra las Reglas de Negocio.

Esta es la aplicación de Reglas Bancarias adicionales / Reglas de aplicación.

Message Component Validator

PRÁCTICA_DE_MERCADO_VÁLIDA

La instancia de mensaje es Mensaje Válido más validado contra las Prácticas de Mercado.

Esta es la aplicación de reglas específicas adicionales del Esquema de Mercado.

CSM Service

PROCESO_DE_NEGOCIO_VÁLIDO

La instancia de mensaje es Mensaje Válido más validado contra la Coreografía de Mensajes.

Esto es si el mensaje es válido dentro del contexto de su intercambio previsto. Por ejemplo, un huérfano recibido al azar pacs. 002 puede "técnicamente" ser válido en el mercado, pero no es "válido" en ausencia de un mensaje de origen.

Process Flow y CSM Service

COMPLETAMENTE_VÁLIDO

La instancia del mensaje es Mensaje Válido más validado contra todos Reglas y Prácticas del Mercado.

Process Flow

Como se describió anteriormente, la verificación SYNTAX_VALID se realiza a menudo en el momento de la deserialización de un mensaje externo, especialmente con una aplicación que utiliza un lenguaje de tipo estático como Java para modelar la Abstracción de Mensajes. Si hemos podido deserializar el mensaje en nuestro Java modelo, entonces es SYNTAX_VALID, luego examinamos los siguientes tres Niveles de Validación que se relacionan con la validez del contenido dentro del Mensaje de manera aislada.

El IPF ISO20022 El modelo de mensaje proporciona una clase de validación MessageComponentValidator que ofrece la capacidad de validar un dado Message Definition, o Componente de Mensaje en cualquiera, o en todos estos niveles.

Validador de Componentes de Mensaje

La clase Validador de Componentes de Mensaje proporciona la capacidad de validar un dado Message Definition(objeto o Componente de Mensaje individual). Soporta la validación para SCHEMA_VALID,MESSAGE_VALID y RULE_VALID. Las validaciones son configurables y se informan de manera independiente, de modo que el usuario tiene control total sobre cuáles validaciones deben realizarse en un momento dado.

Reglas de Esquema y Reglas de Mensaje se implementan como beanvalidation.org/1. 0/spec/[Anotaciones JSR303] sobre el Componente de Mensaje Java clases. El Validador de Componentes de Mensaje delega a un Hibernate Validator implementación para la ejecución de estas reglas.

Niveles de Validación

A menudo, usted puede querer realizar solamente SCHEMA_VALID al recibir el mensaje externo, y posponer el MESSAGE_VALID hasta una etapa posterior en el procesamiento, donde el contenido del mensaje puede haber sido enriquecido.

El Validador de Componentes de Mensaje está diseñado específicamente para apoyar estos escenarios.

Reglas del Esquema

Esto se refiere a menudo como "validar un mensaje contra un Esquema", específicamente el XSD asociado con el Message Definition. Esta validación a menudo incluye, pero no se limita a:

  • Comprobaciones de rango

  • Nulabilidad

  • Patrón restrictions

  • Modalidad

  • Cardinalidad

  • Enumeración

  • Exclusividad

Dentro del IPF ISO20022 La implementación del modelo de mensaje, las validaciones definidas por los esquemas XSD están completamente implementadas en el modelo de mensaje.java clasificado como beanvalidation.org/1. 0/spec/[JSR303 Bean Validación] Anotaciones. No se proporcionan XSDs para Message Definition s como parte del IPF ISO20022 Modelo de Mensaje. No es necesario validar el Message Definition s proporcionado por este modelo contra el ISO20022 XSDs, ni es posible debido a la Tipos Normalizados y eliminación de la agrupación de nombres.

La validación debe realizarse exclusivamente utilizando el Validador de Componentes de Mensaje.

Grupos de Validador JSR303

Las Reglas de Esquema se implementan como Anotaciones JSR303 bajo el grupo predeterminado. Esto significa que cualquier intento de validar un Componente de Mensaje directamente contra un Validador de Hibernate (u otra implementación) validará el objeto contra las Reglas de Esquema apropiadas.

Esto es similar, aunque con un alcance ligeramente más estricto que el conjunto predeterminado de anotaciones JSR303 comúnmente adjuntas por los modelos generados por XJC. Las anotaciones predeterminadas proporcionadas por XJC NO respetan algunas validaciones de esquema, como los Componentes de Elección y la exclusividad.- esto se dejó históricamente al proceso de validación XSD, externamente a JSR303 Bean Validadores

Si tiene un uso existente de Bean Validadores, puede notar que la validación predeterminada de los Componentes de Mensaje es más estricta que antes

Incluyendo Reglas de Esquema para Validación

Para incluir las Reglas de Esquema como parte del alcance de validación para una solicitud de validación, el parámetro ValidationOptions debe ser configurado para requerir Reglas de Esquema.

Construimos un objeto ValidationOptions que permite la validación de reglas de esquema; esto se puede hacer de manera explícita como se demuestra aquí o utilizando uno de los perfiles comunes detallados a continuación en Common ValidationOptions.

Definiendo las Opciones de Validación
// Only enable Schema Rule Validation
ValidationOptions onlyValidateSchemaRules = ValidationOptions.builder()
        .applySchemaValidation(true)
        .applyBusinessRuleValidation(true)
        .applyMessageRuleValidation(false)
        .build();
Validando un objeto de mensaje
// This will fail Schema Validation as GroupHeader and PaymentInstruction elements are not present
CustomerCreditTransferInitiationV09 ccti = CustomerCreditTransferInitiationV09.builder().build();

MessageComponentValidator validator = ISO20022MessageModel.getInstance().validator();
ValidationResult<CustomerCreditTransferInitiationV09> result = validator.validate(ccti, onlyValidateSchemaRules);
Verificando el resultado

El objeto de respuesta ValidationResult contiene niveles enumerados separados que indican el resultado de la Regla de Esquema, la Regla de Mensaje y la Regla de Negocio, ya sea VÁLIDO, INVÁLIDO o NO APLICADO, si no se solicitó un conjunto de reglas.

La respuesta también contiene listas separadas de cada tipo de Violación, así como una lista agregada de todas las violaciones para su conveniencia.

¿Entonces fue válido?

El MessageComponentValidator proporciona respuestas granulares que detallan si el mensaje de entrada es válido para diferentes niveles. Si bien el resultado proporciona una propiedad result.isValid(), esta debe ser considerada cuidadosamente en el contexto de la configuración de ValidationOptions solicitada.

Es responsabilidad de la aplicación tener conocimiento y contexto sobre si un determinado nivel de validación alcanzado es suficiente para un punto de invocación dado

Las violaciones devueltas en este ejemplo muestran que la instancia de Mensaje era inválida debido a 2 violaciones de esquema separadas (violación de nulabilidad para el Encabezado del Grupo y la Instrucción de Pago).

ValidationResult. ValidationLevelResult schemaValid = result.getSchemaValid(); // INVALID

Violation<CustomerCreditTransferInitiationV09> grpHdrViolation = result.getSchemaViolations().get(0);
String name1 = grpHdrViolation.getName(); // {javax.validation.constraints. NotNull.message}
String message1 = grpHdrViolation.getMessage(); // "must not be null"
String properyPath1 = grpHdrViolation.getPropertyPath(); // "grpHdr"
ValidationType type1 = grpHdrViolation.getType(); // SCHEMA_RULE
ConstraintViolation<CustomerCreditTransferInitiationV09> jsrViolation1 = grpHdrViolation.getJsr303ConstraintViolation(); // Original Validation details

Violation<CustomerCreditTransferInitiationV09> pmtInfViolation = result.getSchemaViolations().get(1);
String name2 = pmtInfViolation.getName(); // {javax.validation.constraints. NotNull.message}
String message2 = pmtInfViolation.getMessage(); // "must not be null"
String properyPath2 = pmtInfViolation.getPropertyPath(); // "pmtInf"
ValidationType type2 = pmtInfViolation.getType(); // SCHEMA_RULE
ConstraintViolation<CustomerCreditTransferInitiationV09> jsrViolation2 = grpHdrViolation.getJsr303ConstraintViolation(); // Original Validation details

Reglas de Mensaje

Las reglas de mensajes son la parte más interesante de la ISO20022 Validaciones del modelo de mensaje. Son reglas formales y lógicas definidas en contra de individuos Message Definition s o Componentes de Mensaje. Sin embargo, no están codificados en los XSDs tradicionales, ya que las reglas a menudo no pueden ser completamente articuladas en XSD de la misma manera que una Regla de Esquema. Por ejemplo, la presencia condicional a través de elementos secundarios anidados.

Estas reglas están definidas dentro del fundamento ISO20022*Meta-Modelo* y E-Repositorio, donde se les denomina Restricciones. En el IPF ISO20022 Modelo de mensaje estas reglas se implementan como anotaciones "trigger" JSR303, una regla de mensaje Cache, y interfaces dedicadas que deben ser implementadas para cada Regla de Mensaje.

Descripción general

El diagrama a continuación muestra una visión general de alto nivel de las diversas clases involucradas en la definición de una implementación de Regla de Mensaje.

core-classes

Para una regla de mensaje dada, por ejemplo "Regla de Identificación o Presencia de Proxy", generamos tres clases.

  1. Una interfaz específicamente para la Regla, que extiende una interfaz de Restricción de Icon. Estas reglas son luego implementadas manualmente por el equipo de ingeniería de IPF para un dado. Message Definition y se proporciona como parte del paquete Message-Model.

  2. Una anotación Jsr303 que decora el componente de mensaje asociado, en este ejemplo Cash Account41.

  3. Una clase ConstraintValidator que implementa el contrato ConstraintValidator de Javax para la JSR303 Annotation mencionada.

La implementación de ConstraintValidator delega la ejecución real de la regla a una implementación del Constraint generado (1). La implementación de ConstraintValidator intenta resolver una implementación en tiempo de ejecución de la regla buscando dentro de una instancia de MessageRuleCache una implementación registrada. La implementación de ConstraintValidator puede ser instruida por el MessageComponentValidator’sValidationOptions para fallar o omitir si una implementación no puede resolverse a partir de la Regla de Mensaje Cache en tiempo de ejecución.

El desacoplamiento de las implementaciones de *Message Rule* en tiempo de ejecución de los "Triggers" de *JSR303* proporciona la capacidad para el despliegue rápido de nuevas Message Definition s, adopción e implementación gradual de las Reglas de Mensaje, así como la capacidad de actualizar y cambiar la implementación de las Reglas de Mensaje sin la necesidad de una versión importante del Modelo de Mensaje.

Registro de una Regla de Mensaje

¿Qué regla de mensaje está implementada?

Implementaciones de las Reglas de Mensaje para todos los soportados Message Definition s se proporcionarán como parte del IPF ISO20022 Modelo de Mensaje, aunque esto se está lanzando de manera incremental y aún no está completo.

Mientras las Reglas de Mensaje se implementan como parte de la ISO20022 Modelo de Mensaje, documentamos el proceso aquí para su finalización y como referencia en caso de que se necesiten implementar nuevas o alternativas Reglas de Mensaje a nivel de proyecto.

En primer lugar, identificamos una Regla de Mensaje que se implementará; en este ejemplo, utilizaremos una regla que se aplica a un Componente de Mensaje de Cuenta de Efectivo donde al menos se debe proporcionar la información de identificación de la cuenta o la información de proxy. Estas reglas pueden ser observadas por la presencia de la anotación JSR303 asociada en el Componente de Mensaje.

Tenga en cuenta cómo Cash Account41 tiene una @Identification Or Proxy Presence Rule que debe ser aplicada.

..
@IdentificationOrProxyPresenceRule(groups = MessageRule.class)
public class CashAccount41 implements Serializable {
    ..
}

Para encontrar la Restricción asociada que necesita ser implementada, para ser triggered cuando este Componente de Mensaje es validado, simplemente busque en el paquete padre una Interfaz con el mismo nombre que la Anotación

com.iconsolutions.iso20022.message.components.cash_account.cash_account41.jsr303. Regla De Presencia De Identificación OProxy

vs.

com.iconsolutions.iso20022.message.components.cash_account.cash_account41. Regla De Identificación OPresencia De Apoderado

A continuación se presenta la Identification Or Proxy Presence Rule Constraint que necesitamos implementar.

Muchos de los Restricciones están documentados con una descripción pseudo formal del requisito. Esto puede ser crucial para resaltar escenarios de prueba adecuados para que estas reglas sean validadas.

package com.iconsolutions.iso20022.message.components.cash_account.cash_account41;

/*Generated by MPS */

import com.iconsolutions.iso20022.message.meta.validation. Constraint;

public interface IdentificationOrProxyPresenceRule extends Constraint<CashAccount41> {


  /**
   * Identification must be present or proxy must be present.
   *
   * <pre>
   *
   * <RuleDefinition>
   *     <SimpleRule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="SimpleRule">
   *         <mustBe>
   *             <connector>OR</connector>
   *             <BooleanRule xsi:type="Presence">
   *                 <leftOperand>/Identification</leftOperand>
   *             </BooleanRule>
   *             <BooleanRule xsi:type="Presence">
   *                 <leftOperand>/Proxy</leftOperand>
   *             </BooleanRule>
   *         </mustBe>
   *     </SimpleRule>
   * </RuleDefinition>
   *
   * </pre>
   */
  boolean isValid(CashAccount41 cashAccount41);
}

Entonces podemos escribir una implementación concreta de esta Regla, por ejemplo:

Implementación de una Regla de Mensaje
package com.iconsolutions.iso20022.message.components.cash_account.cash_account41;

public class IdentificationOrProxyPresenceRuleImpl implements IdentificationOrProxyPresenceRule {

    @Override
    public boolean isValid(CashAccount41 cashAccount41) {
        return cashAccount41.getId()!= null || cashAccount41.getPrxy()!= null;
    }
}

Estas reglas serán entonces independientes unit test ed como parte de la producción del IPF ISO20022 Modelo de Mensaje.

Registro de Reglas de Mensajes Automáticos

El MessageComponentValidator está configurado por defecto para poblar de manera anticipada el MessageRuleCache con la implementación de las restricciones. Esto se realiza utilizando Reflection (escanear el classpath en busca de los implementadores candidatos de las Interfaces Constraint) en el momento en que se inicializan los candidatos del ISO20022Message Model.

Tiene lógica para detectar candidatos duplicados y también registrará mensajes de información durante el inicio si no se han implementado todas las reglas.

Por lo tanto, siempre que la instancia de ISO20022Message Model utilice la inicialización predeterminada y, por lo tanto, utilice ScanningRuleCacheInitializer, las implementaciones deberían ser recogidas y aplicadas automáticamente.

Validando contra las reglas de mensajes

Construimos un objeto ValidationOptions que permite la validación de Message Rule, esto se puede hacer explícitamente como se demuestra aquí o utilizando uno de los perfiles comunes.

Configurando Opciones de Validación
ValidationOptions onlyMessageRules = ValidationOptions.builder()
              .applyMessageRuleValidation(true)
              .failIfMessageRulesHaveNotBeenImplemented(true)
              .applyBusinessRuleValidation(false)
              .applySchemaValidation(false)
              .build();

A continuación, validamos el Cash Account41 Componente de Mensaje

Validando un Mensaje
CashAccount41 cashAccount41 = CashAccount41.builder().build();
ValidationResult<CashAccount41> result = validator.validate(cashAccount41, onlyMessageRules);

Luego, inspeccionamos la respuesta de validación y confirmamos que este Mensaje no es válido ya que viola la Regla de Mensaje mencionada anteriormente (entre varias otras).

Verificando el Resultado
List<Violation<CashAccount41>> messageRuleViolations = result.getMessageRuleViolations();
Violation<CashAccount41> violation = messageRuleViolations.get(0);

String name = violation.getName(); // "IdentificationOrProxyPresenceRule"
String message1 = violation.getMessage(); // "IdentificationOrProxyPresenceRule"
String properyPath = violation.getPropertyPath(); // ""
ValidationType type = violation.getType(); // MESSAGE_RULE
ConstraintViolation<CashAccount41> jsrViolation1 = violation.getJsr303ConstraintViolation(); // Original Validation details

Si no se han implementado reglas de mensajes, se proporcionarán como parte de la respuesta a través del método a continuación.

Reglas de Mensaje No Implementadas
List<Violation<CashAccount41>> unmplementedMessageRules = result.getUnimplementedMessageRules();

Reglas de Negocio

Las reglas de negocio son reglas adicionales a nivel de aplicación que pueden aplicarse a la ISO20022 Mensajes para una implementación empresarial específica. Estas reglas son específicas del proyecto y podrían ser cosas como:

  • Verificación de límite para hacer cumplir un límite total de monto de transacción.

  • Exclusión de BIC / IBAN

  • Restricción de ciertas divisas del Código de Compensación para un tipo de pago determinado.

  • Asegurando que los identificadores propietarios se adhieran a t a custom patrón

Implementación de una Regla de Negocio

Las Reglas de Negocio, a diferencia de las Reglas de Esquema o las Reglas de Mensaje, no se invocan a través de JSR303 Annotations, ya que estas reglas se definen como parte del proyecto de implementación y se registran contra el tipo objetivo.

Para registrar una Regla de Negocio, primero implemente la regla de negocio para el tipo exacto. Este tipo debe ser el exacto tipo que se solicitaría validar.

Clases objetivo de la regla de negocio

Las Reglas de Negocio se evalúan únicamente en función del tipo de solicitud exacto; no se aplican a las clases hijas de la misma manera que las Reglas de Mensaje o las Reglas de Esquema.

Hasta que se realice esta mejora, se recomienda utilizar el nivel superior Message Definition clase como el objetivo para cada Regla de Negocio

A continuación, creamos una nueva Regla de Negocio, implementando la interfaz BusinessRule<T>, que requiere la implementación de un único método para realizar la validación. Se pueden devolver múltiples Violaciones de una única regla, cada una con sus propios detalles. La interfaz BusinessRule contiene métodos auxiliares como single Violation() para construir las Violaciones.

Definición de una Regla de Negocio
BusinessRule<CustomerCreditTransferInitiationV09> msgIdMustStartWithApple = new BusinessRule<>() {
    @Override
    public List<Violation<CustomerCreditTransferInitiationV09>> apply(CustomerCreditTransferInitiationV09 message) {
        if (! message.getGrpHdr().getMsgId().startsWith("Apple"))
            return singleViolation("MsgIdStartsWithApple", "grpHdr. MsgId", "Message ID should start with 'Apple'");
        else {
            return new ArrayList<>();
        }
    }
};

Una vez que se ha definido una Regla de Negocio, debe ser registrada con el MessageComponentValidator a través de su dependencia BusinessRuleAccess.

Registro de una Regla de Negocio
MessageComponentValidator validator = ISO20022MessageModel.getInstance().validator();
BusinessRuleAccess businessRuleAccess = validator.getBusinessRuleAccess();
businessRuleAccess.registerBusinessRule(CustomerCreditTransferInitiationV09.class, msgIdMustStartWithApple);

Validando contra las Reglas de Negocio

Para incluir la Regla de Negocio como parte del alcance de validación para una solicitud de validación, el parámetro ValidationOptions debe ser configurado para requerir Reglas de Negocio.

Construimos un objeto ValidationOptions que permite la validación de BusinessRule, esto puede hacerse de manera explícita como se demuestra aquí o utilizando uno de los perfiles comunes descritos en Common Rule Configurations.

Configuración de Opciones de Validación
ValidationOptions onlyValidateBusinessRules = ValidationOptions.builder()
              .applyBusinessRuleValidation(true)
              .applyMessageRuleValidation(false)
              .applySchemaValidation(false)
              .build();
Validando un Mensaje
CustomerCreditTransferInitiationV09 ccti = CustomerCreditTransferInitiationV09.builder()
        .grpHdr(GroupHeader85.builder()
                .msgId("Orange-s2ud2gs423d22").build())
        .build();

ValidationResult<CustomerCreditTransferInitiationV09> result = validator.validate(ccti, onlyValidateBusinessRules);
Verificando el Resultado
ValidationResult. ValidationLevelResult businessRulesValid = result.getBusinessRulesValid();// INVALID

Violation<CustomerCreditTransferInitiationV09> violation = result.getBusinessRuleViolations().get(0);

String name = violation.getName(); // MsgIdStartsWithApple
String message = violation.getMessage(); // "Message ID should start with 'Apple'"
String properyPath = violation.getPropertyPath(); // "grpHdr. MsgId"
ValidationType type = violation.getType(); // BUSINESS_RULE

Configuraciones Comunes de Opción de Validación

A menudo es engorroso definir manualmente una instancia de ValidationOptions cada vez. Se han proporcionado algunas instancias preconfiguradas como miembros estáticos de la clase ValidationOptions que pueden utilizarse de manera más conveniente; por ejemplo, las invocaciones a continuación realizan únicamente la validación del esquema, omitiendo las reglas de mensaje y las reglas de negocio.

ValidationResult<CustomerCreditTransferInitiationV09> result = validator.validate(ccti, ValidationOptions.schemaValid());

A continuación se presenta una tabla que describe las configuraciones proporcionadas, su impacto y el uso esperado.

Comportamiento Predeterminado

Si no se proporciona un argumento ValidationOptions al validador, utiliza ruleValidLoose().

Este es el nivel más alto de validación que puede realizar el Validador de Componentes de Mensaje, pero no fallará si ninguna de las Reglas de Mensaje se ha implementado aún.

Config Descripción Incluir Reglas del Esquema Incluir Reglas de Mensaje Incluir Reglas de Negocio Falle si las reglas de mensajes no están implementadas

schemaValid()

Solo realiza la validación del esquema.

Y

N

N

N

messageValid()

Además, realiza la validación contra las Reglas de Mensaje.

Y

Y

N

Y

ruleValid()

Además, realiza validación contra las Reglas de Negocio.

Y

Y

Y

Y

regla Válida Flexible()

Como ruleValid(), pero no fallará si no se han implementado todas las Reglas de Mensaje.

Y

Y

Y

N