Consulta de Configuración de Notificación de Estado de Pago

Para entender de qué se trata esta Consulta de Configuración de Notificación de Pago, primero debemos comprender estos conceptos de Dynamic Settings y Configuración de Notificación de Estado de Pago.

Dynamic Processing Settings proporciona una plataforma para gestionar configuraciones configurables y su ciclo de vida. La plataforma permite definir, mantener y exponer configuraciones configurables que pueden ser referenciadas desde una aplicación externa como IPF.

Para más detalles sobre dynamic settings por favor, lea Dynamic Settings Documentation

En nuestro caso en particular, nuestro dynamic settings será para Configuración de Notificación de Estado de Pago.

Son una lista de configuraciones (que son configurables) que se utilizarán para establecer campos específicos en el documento PAIN 002 que se producirá. Para obtener más información sobre qué campos se espera que sean configurados y cómo deben ser establecidos, consulte con más detalle.este capítulo.

El PaymentStatusNotificationSettingsQuery la clase es solo una interfaz que nos ayudará a recuperar esos datos de configuración para un específico event, basado en el event nombre y el process flow nombre:

public interface PaymentStatusNotificationSettingsQuery {
    CompletionStage<SettingsDTO<PaymentStatusNotification>>  getPaymentStatusNotificationSettings(String eventName, String processFlowName);
}

Hacemos uso de SettingsDTO, de Dynamic Settings al agregar lo siguiente maven dependency:

<dependency>
    <groupId>com.iconsolutions.ipf.core.dynamicsettings</groupId>
    <artifactId>setting-domain</artifactId>
</dependency>

Se espera que devuelva un DTO de Configuración de Notificación de Estado de Pago, filtrando por event nombre y process flow nombre.

Existen 3 tipos de Configuración de Consulta de Notificación de Estado de Pago:

  • Configuración de Notificación de Estado de Pago Conector Consulta

  • Consulta de Configuración de Archivo de Notificación de Estado de Pago

  • Configuración de Notificación de Estado de Pago Consulta Mongo

Para más detalles sobre cada uno de los tres tipos de Configuraciones de Consulta, por favor consulte los siguientes capítulos.

Conector

Se instancia configurando la siguiente propiedad:

setting-retrieval-method = connector

Y al definir la siguiente configuración:

settings-api {
  http {
    client {
      host = "localhost"
      endpoint-url = "/settings-objects/"
      port = 8080
    }
  }
}

Cuando se llama al método getPaymentStatusNotificationSettings, una Configuración Cache La clave se instancia para el dado event nombre y process flow nombre.

@Value
@Builder
@AllArgsConstructor
public class SettingCacheKey {
    String eventName;
    String processFlowName;
}

Luego llama al settingsCacheAdapter (para más detalles sobre caching por favor lea async cache adapter). Hay dos resultados:

  • Hay algo en el cache. Los valores se serializan, completan y devuelven.

  • No hay nada en el cache. Obtiene la configuración realizando un HTTP llamada al Request Reply Send Connector. Luego lo añade a la cache, completa y devuelve.

La desventaja de esta variante es que necesita otro servicio para modelar la Configuración.

El Request Reply Send Connector, junto con el Dynamic Settings API apoyará la API llamadas a la url del settings-object.

La aplicación puede ser sin estado, es decir, no Akka cluster se necesita configuración. La implementación del conector estará llamando a un servicio externo que aloja el dynamic settings workflow servicio.

Archivo de Configuración

Se instancia configurando la siguiente propiedad:

setting-retrieval-method = file

La lista de notificación del estado de pago se instancia con la siguiente configuración (como ejemplo):

payment-status-notification.notification-settings = [
  {
    "domain-event": "Scheme Rules Validated",
    "process-flow": "DebtorCT",
    "status": "ACCC",
    "proprietary": "validated",
    "transport": "kafka",
    "predicate": null,
    "endpoints": [
      {
        "topic": "PAYMENT_STATUS_NOTIFICATION",
        "predicate": "eventId == 1"
      },
      {
        "topic": "PAYMENT_SECONDARY_TOPIC",
        "predicate": "eventId == 2"
      }
    ]
  }
]

Cuando se llama al método getPaymentStatusNotificationSettings, se verifica la notificationSettings y se filtra en función de la event nombre y process flow. Instancia la lista, la completa y la devuelve.

La aplicación puede ser sin estado, es decir, no Akka cluster se necesita configuración. Carga todo desde HOCON al iniciar la aplicación. Es la solución más simple. Solo necesita consultar una estructura en memoria.

Mongo

Se instancia configurando la siguiente propiedad:

setting-retrieval-method = mongo

Cuando se llama al método getPaymentStatusNotificationSettings, una Configuración Cache La clave se instancia, basada en event nombre y process flow nombre.

Luego llama al settingsCacheAdapter (para más detalles sobre caching por favor lea async cache adapter). Hay dos resultados:

  • Hay algo en el cache. Los valores se serializan, completan y devuelven.

  • No hay nada en el cache. Obtiene la configuración al llamar al Repositorio de Configuración de Notificación de Estado de Pago, que es un Repositorio de Configuración que almacena la Configuración de Notificación de Estado de Pago. Luego, la añade a la cache, completa y devuelve.

Para utilizar esta variante, los Ajustes deben incluirse dentro del Servicio de Notificaciones mediante la inclusión del componente de gestión de ajustes y lo siguiente maven dependency:

<dependency>
    <groupId>com.iconsolutions.ipf.core.dynamicsettings</groupId>
    <artifactId>dynamicsettings-query</artifactId>
    <version>${dynamic-settings-workflow.version}</version>
</dependency>

Se basa en dynamic settings workflow. Lo que significa que hay un lado de escritura activo y un lado de lectura funcionando dentro del Servicio de Notificaciones. El dynamic settings siempre se agrupan en la aplicación.

Seleccionando la Consulta de Configuración

Variante Pros Cons

Conector

- Capacidad para crear, actualizar, eliminar y obtener configuraciones con gran facilidad.
- No es necesario.restart para que se puedan aplicar nuevos ajustes. Confiando en cache solo

- Alta complejidad en la definición SendingConnector beans,connector transport s, etc
- Necesita conectarse a un separado dynamic settings servicio para recuperar la configuración
- Probablemente será el recuperador más lento, ya que tendrá que realizar un salto de red + esperar a que el servicio objetivo consulte los datos.

Archivo

- Versión más simple
- Más rápido

- Debe agregar todas las configuraciones manualmente.
- Se requiere que todos los nodos de servicio sean restarted para que se apliquen los nuevos ajustes

Mongo

- Operaciones estandarizadas mediante el uso de la ReactiveCrudRepository

- Se basa en dynamic settings workflow componente. Hay un lado de escritura activo y un lado de lectura que se ejecutan dentro del Servicio de Notificaciones (mismo contenedor)
- Es necesario construir una gran cantidad de "Consulta manual" al buscar registros específicos, los cuales son propensos a errores.

Dependencias

Actualmente, el Servicio de Notificación depende de Dynamic Settings. Este es actualmente el caso incluso si Consulta Basada en Archivos está configurado.

Mongo

El dynamic settings crea una colección en MongoDB con los siguientes índices:

        Index index = new Index()
                .on(PaymentStatusNotificationMongoSettingRecordIndexInitialiser.LAST_EVENT_TIME, Sort.Direction.DESC)
                .on(PAYLOAD_DOMAIN_EVENT, Sort.Direction.ASC)
                .on(PAYLOAD_PROCESS_FLOW, Sort.Direction.DESC);

La creación automática de los índices para el servicio puede ser desactivada aplicando lo siguiente a su application.conf:

payment-status-notification.mongodb.create-indexes=false

O globalmente con:

ipf.mongodb.create-indexes=false

Para deshabilitar la indexación a nivel global pero mantenerla para el servicio, aplique lo siguiente, manteniendo el orden:

ipf.mongodb.create-indexes=false
payment-status-notification.mongodb.create-indexes=true

El quórum de confirmación puede ser controlado de manera similar con:

ipf.transaction-cache.mongodb.commit-quorum=1

O bien anulado globalmente con:

ipf.mongodb.commit-quorum=1

Para establecer un quórum de confirmación diferente a nivel global al del Servicio de Notificación, aplique lo siguiente, manteniendo el orden:

payment-status-notification.mongodb.commit-quorum=1
ipf.mongodb.commit-quorum=1

Notificación de Estado de Pago

El servicio de notificación tiene un concepto de Notificación de Estado de Pago. Estos son ajustes utilizados para completar una Notificación de Estado de Pago cuando un Process Flow Event(Domain event) es recibido. Estas configuraciones son optional y si no está configurado, se utilizarán los datos del DomainEvent en su lugar.

Aquí hay una tabla que describe cómo los datos de PaymentStatusNotification está actualmente mapeado en CustomerPaymentStatusReport campos:

Desde Para

Notificación De Estado De Pago.estado

CustomerPaymentStatusReport.orgnlPmtInfAndSts[0].txInfAndSts[0].txSts

PaymentStatusNotification.proprietary

CustomerPaymentStatusReport.orgnlPmtInfAndSts[0].txInfAndSts[0].stsRsnInf[0].rsn.prtry

PaymentStatusNotification.codigo

CustomerPaymentStatusReport.orgnlPmtInfAndSts[0].txInfAndSts[0].stsRsnInf[0].rsn.cd

PaymentStatusNotification.información Adicional

CustomerPaymentStatusReport.orgnlPmtInfAndSts[0].txInfAndSts[0].stsRsnInf[0].addtlInf

Para más detalles sobre PaymentStatusNotification ajustes, por favor, lea Esquema de Notificación de Estado de Pago. Si no PaymentStatusNotification está actualmente configurado, entonces los siguientes campos se poblarán a partir del Domain Event en sí mismo de la siguiente manera:

Desde Para

DomainEvent.código De Razón Original

CustomerPaymentStatusReport.orgnlPmtInfAndSts[0].txInfAndSts[0].stsRsnInf[0].rsn.prtry

DomainEvent.código De Razón

CustomerPaymentStatusReport.orgnlPmtInfAndSts[0].txInfAndSts[0].stsRsnInf[0].rsn.cd

DomainEvent.reasonText

CustomerPaymentStatusReport.orgnlPmtInfAndSts[0].txInfAndSts[0].stsRsnInf[0].addtlInf[0]

Esquema de Configuración de Notificaciones de Pago

La siguiente tabla identifica los campos que pueden ser configurados para una Notificación de Estado de Pago.

Campo Tipo Obligatorio Descripción Ejemplo

eventoDominio

Cadena

Sí

El nombre del domain event, coincidiendo con el Domain Event nombre recibido

Reglas del Esquema Validadas

flujoDeProceso

Cadena

Sí

El nombre del flujo el event está destinado a

DeudorCT

estado

Cadena

Sí

El código de estado de la transacción que se debe mapear al generar la Notificación de Estado de Pago

ACCC

transporte

Cadena

Sí

El transporte que se debe utilizar al producir la Notificación de Estado de Pago. Actualmente, el único valor soportado es kafka

kafka

puntos finales

List<Endpoint>

Sí

La lista de puntos finales a los que se enviará la Notificación de Estado de Pago, para el domain event recibido, si se satisface el predicado. En caso de que el transporte sea kafka será una lista de temas y predicados

[{"topic": "TOPIC_1", "predicate": "eventId == 1"},{"topic": "TOPIC_2", "predicate": "eventId == 2"}]

código

Cadena

No

El código al que se debe mapear al generar la Notificación de Estado de Pago

TM01

propietario

Cadena

No

El propietario al que se debe mapear al generar la Notificación de Estado de Pago

CÓDIGO_PROPIETARIO

información Adicional

Lista<String>

No

La información adicional que se debe mapear al generar la Notificación de Estado de Pago

["información adicional 1", "información adicional 2"]

predicado

Cadena

No

Predicado contra un ProcessFlowEvent que debe ser respetado para una Notificación de Estado de Pago. Soporta docs.spring.io/spring-framework/docs/3. 2.x/spring-framework-reference/html/expressions.html[SpEL] expresiones basadas en jsonPath.

  • csm == 'SIC'

  • csm == 'SIC' && #jsonPath(content, '$.status.originatingStatus') == 'Liquidando Efectivo'

Ejemplos

Poblado desde Configuración

Este es el PaymentStatusNotification configurado en la configuración:

  {
    "domain-event": "Scheme Rules Validated",
    "process-flow": "DebtorCT",
    "status": "ACCC",
    "proprietary": "validated",
    "transport": "kafka",
    "endpoints": ["PAYMENT_STATUS_NOTIFICATION"]
  }

Esto significa que cuando un "Reglamento de Esquema Validado" Domain Event se recibe para el flujo "DebtorCT", se producirá una notificación de estado de pago a la NOTIFICACIÓN_DE_ESTADO_DE_PAGO kafka tema, con la siguiente información:

CustomerPaymentStatusReport.orgnlPmtInfAndSts[0].txInfAndSts[0].txSts

ACCC

CustomerPaymentStatusReport.orgnlPmtInfAndSts[0].txInfAndSts[0].stsRsnInf[0].rsn.prtry

validado

Poblado Desde Domain Event

Este es el PaymentStatusNotification configurado en la configuración:

  {
    "domain-event": "Scheme Rules Validated",
    "process-flow": "DebtorCT",
    "status": "ACCC",
    "transport": "kafka",
    "predicate": "csm == 'SIC'",
    "endpoints": ["PAYMENT_STATUS_NOTIFICATION"]
  }

Y este es el DomainEvent original recibido:

  {
    "reasonCode": "AM13",
    "reasonText": "Amount is above the limit"
  }

Esto significa que cuando un "Reglamento de Esquema Validado" Domain Event se recibe para el flujo "DebtorCT", se producirá una notificación de estado de pago a la NOTIFICACIÓN_DE_ESTADO_DE_PAGO kafka tema, con la siguiente información:

CustomerPaymentStatusReport.orgnlPmtInfAndSts[0].txInfAndSts[0].txSts

ACCC

CustomerPaymentStatusReport.orgnlPmtInfAndSts[0].txInfAndSts[0].stsRsnInf[0].rsn.cd

AM13

CustomerPaymentStatusReport.orgnlPmtInfAndSts[0].txInfAndSts[0].stsRsnInf[0].addtlInf[0]

La cantidad está por encima del límite.