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 Settingsproporciona una plataforma para gestionar configuraciones ajustables y su ciclo de vida. La plataforma permite definir, mantener y exponer configuraciones ajustables que pueden ser referenciadas desde una aplicación externa como IPF.

Para más detalles sobre la configuración dinámica, por favor lea Dynamic Settings Documentation

En nuestro caso en particular, nuestras configuraciones dinámicas serán para Configuraciones 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 evento específico, basado en el nombre del evento y el nombre del flujo de proceso:

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

Hacemos uso de SettingsDTO, de Dynamic Settings agregando la siguiente dependencia de maven:

<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 el nombre del evento y el nombre del flujo de proceso.

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

  • Configuración de archivo de notificación de estado de pago Consulta

  • 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 el getPaymentStatusNotificationSettings se llama al método, una Configuración Cache La clave se instancia para el nombre del evento dado y el nombre del flujo de proceso.

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

Luego llama al settingsCacheAdapter (para más detalles sobre el almacenamiento en caché, por favor lea async cache adapter). Hay dos resultados:

  • Hay algo en la caché. Los valores se serializan, se completan y se devuelven.

  • No hay nada en la caché. Obtiene la configuración realizando un HTTP llamada al Request Reply Send Connector. Luego lo añade a la caché, 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 Se necesita la configuración del clúster. La implementación del conector estará llamando a un servicio externo que alberga el servicio de flujo de trabajo de configuraciones dinámicas.

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 el getPaymentStatusNotificationSettings se llama al método, verifica el notificationSettings y filtros basados en el nombre del evento y el flujo del proceso. Instancia la lista, la completa y la devuelve.

La aplicación puede ser sin estado, es decir, no Akka se necesita la configuración del clúster. 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 el getPaymentStatusNotificationSettings se llama al método, una Configuración Cache La clave se instancia, basada en el nombre del evento y el nombre del flujo de proceso.

Luego llama al settingsCacheAdapter (para más detalles sobre el almacenamiento en caché, por favor lea async cache adapter). Hay dos resultados:

  • Hay algo en la caché. Los valores se serializan, se completan y se devuelven.

  • No hay nada en la caché. 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 caché, completa y devuelve.

Para utilizar esta variante, los Ajustes deben incluirse dentro del Servicio de Notificaciones incluyendo el componente de gestión de ajustes y la siguiente dependencia de maven:

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

Se basa en un flujo de trabajo de configuraciones dinámicas. Lo que significa que hay un lado de escritura activo y un lado de lectura funcionando dentro del Servicio de Notificaciones. Las configuraciones dinámicas siempre están integradas 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 reiniciar para que se apliquen los nuevos ajustes. Se basa únicamente en la caché.

- Alta complejidad en la definición SendingConnector beans, transportes de conectores, etc
- Necesita conectarse a un servicio de configuración dinámica separado 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

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

Mongo

- Operaciones estandarizadas mediante el uso de la ReactiveCrudRepository

- Se basa en el componente de flujo de trabajo de configuraciones dinámicas. 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

La configuración dinámica 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 deshabilitarse 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 globalmente 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 Se recibe el (evento de dominio). Estas configuraciones son optional y si no está configurado, los datos de la DomainEvent se utilizará en su lugar.

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

Desde Para

PaymentStatusNotification.status

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

PaymentStatusNotification.proprietary

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

PaymentStatusNotification.code

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

PaymentStatusNotification.additionalInfo

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 desde el Dominio Event en sí mismo de la siguiente manera:

Desde Para

DomainEvent.originalReasonCode

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

DomainEvent.reasonCode

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

domainEvent

Cadena

Sí

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

Reglas del Esquema Validadas

processFlow

Cadena

Sí

El nombre del flujo para el cual se destina el evento

DebtorCT

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

additionalInfo

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 SpEL expresiones basadas en jsonPath.

  • csm == 'SIC'

  • csm == 'SIC' && #jsonPath(content, '$.status.originatingStatus') == 'Liquidación de Efectivo'

Ejemplos

Poblado desde Configuraciones

Esto 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 Dominio "Reglas del Esquema Validadas" Event se recibe para el " DebtorCT " flujo, se producirá una notificación de estado de pago al tema PAYMENT_STATUS_NOTIFICATION de kafka, con la siguiente información:

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

ACCC

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

validado

Poblado Desde Dominio Event

Esto 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 original DomainEvent recibido:

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

Esto significa que cuando un Dominio "Reglas del Esquema Validadas" Event se recibe para el " DebtorCT " flujo, se producirá una notificación de estado de pago al tema PAYMENT_STATUS_NOTIFICATION de kafka, 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.