Documentation for a newer release is available. View Latest

Modelado de datos de pagos de IPF

El enfoque de IPF para el modelado de datos de pagos

Fundamentalmente, IPF proporciona la capacidad de operar (persistir y propagar aguas abajo) sobre cualesquiera tipos de Java, pero también proporcionamos un conjunto estándar y creciente de implementaciones Java de mensajes ISO 20022.

  • Un pago se representa definiendo uno o más processing flows.

  • Estos processing flows pueden referenciar uno o más data elements que se capturan en varios puntos durante el procesamiento; esto podría ser datos de pago, datos de procesamiento o datos específicos del cliente.

  • Estos data elements tienen un nombre, una categoría y una representación de tipo Java, y se definen en una library fija y reutilizable de data elements.

  • Estas libraries pueden ser definidas por el cliente, pero Icon proporciona una library existente específicamente para ISO 20022 payment messages para modelar los datos del pago.

Funcionalidades de valor añadido de IPF

Muchas de las funcionalidades de valor añadido de IPF dependen del uso de la library ISO 20022 de IPF para modelar datos de pagos. Por ello, fomentamos la conversión a estas como parte del mapeo dentro de la aplicación:

  • Decomposición

  • Muchos de los mensajes ISO pueden usarse como sobres para una o múltiples transactions (por ejemplo, una única instrucción con muchas transferencias de crédito para un pacs.008). IPF entiende cómo descomponer las representaciones IPF de estos sobres en partes constituyentes. Por lo tanto, podemos modelar flujos para pagos únicos (un sobre pacs.008 con una única transferencia de crédito) o tramos individuales de transferencia de crédito (un process flow que opera sobre un pacs.008.creditTransfer individual), manteniendo referencias para rastrear un creditTransfer hasta su instrucción original. Esto proporciona la base para el procesamiento en lote/por lotes.

  • Mapeo

  • Proporcionamos varias capacidades de mapeo entre mensajes dentro de este modelo

  • APIs entre servicios

  • Proporcionamos un conjunto de definiciones de API para modelar el procesamiento de pagos entre servicios, que son una buena referencia a seguir cuando se busca construir múltiples servicios orquestados. Estas definiciones de API referencian payloads en la estructura de estos mensajes ISO (por ejemplo, PaymentInitiationRequest espera un Pain.001).

  • APIs estándar de consulta

  • Proporcionamos un conjunto de APIs estándar del servicio ODS para buscar pagos basados en campos comunes de pagos dentro de los componentes de mensaje mencionados (por ejemplo, encontrar por txId, recallId, msgId, debtorName). Estas APIs operan siempre que los datos de pago se hayan capturado usando la library ISO 20022 de IPF en algún punto durante el processing flow.

Catálogo de mensajes ISO de IPF

IPF admite todos los mensajes ISO20022 (2019) como opciones genéricas; sin embargo, cualquier mensaje que no esté actualmente en el catálogo específico de IPF no tendrá APIs de consulta directamente buscables. Por lo tanto, añadimos nuevos mensajes al catálogo, en función de los requisitos del cliente, y revisamos constantemente la necesidad de nuevos campos buscables en la API de consulta de ODS (este es un proceso automatizado y, por lo tanto, el tiempo de respuesta es rápido). La lista actual puede verse aquí.

La documentación detallada puede encontrarse en las definiciones de mensajes ISO 20022 proporcionadas por la ISO 20022 Registration Authority.

IPF Payments DSL

Una DSL (Domain Specific Language) es un lenguaje de programación con un mayor nivel de abstracción optimizado para una clase específica de problemas. Una DSL usa los conceptos y reglas del campo o dominio. Los ejemplos de DSL incluyen, entre otros, SQL, HTML, CSS, etc. En el caso de IPF, Icon ha desarrollado una DSL cuyo dominio es pagos, de ahí la IPF Payments DSL.

El uso de una payments DSL simplifica y acelera las definiciones de procesos, empoderando al negocio mientras se reduce el riesgo en la entrega de código mediante la alineación con la documentación y las pruebas.

dsl generation

  • Icon ha desarrollado un lenguaje de alto nivel orientado a pagos para configurar flujos de proceso de pagos. Este payments domain specific language (DSL) se crea con el MPS IDE de JetBrains.

  • La Payments DSL de Icon permite que expertos en pagos y desarrolladores configuren conjuntamente los flujos de proceso, ideal para un enfoque de entrega Agile Scrum colaborativo moderno.

  • El Process Flow Build Tool usa automáticamente las configuraciones de flujo de proceso como entrada para generar automáticamente:

    • Código fuente para ejecutar el proceso en IPF

    • Escenarios de prueba BDD que son usados por el Icon Test Framework para las pruebas automatizadas de los flujos de proceso

    • Diagrama de flujo como representación visual del flujo de proceso

    • Documentación clara del flujo de proceso para una audiencia no técnica

Eventos de dominio de IPF

Un domain event es un hecho crítico que sucedió al estado del agregado en el dominio del que quieres que otras partes del mismo dominio (en proceso) estén al tanto. Las partes notificadas suelen reaccionar de alguna manera a los eventos. Los domain events te ayudan a expresar explícitamente las reglas del dominio, basadas en el lenguaje ubicuo proporcionado por los expertos del dominio. (como se define en .NET Microservices: Architecture for Containerized .NET Applications - Domain events: design and implementation).

Modela información sobre la actividad en el dominio como una serie de eventos discretos. Representa cada evento como un objeto de dominio. Estos son distintos de los eventos del sistema que reflejan actividad dentro del propio software, aunque a menudo un evento del sistema está asociado con un domain event, ya sea como parte de una respuesta al domain event o como una forma de llevar información sobre el domain event al sistema. Un domain event es una parte de pleno derecho del modelo de dominio, una representación de algo que sucedió en el dominio. Ignora la actividad de dominio irrelevante mientras haces explícitos los eventos que los expertos del dominio quieren rastrear o de los que quieren ser notificados, o que están asociados con el cambio de estado en los otros objetos del modelo. En un sistema distribuido, el estado de una entidad puede inferirse a partir de los domain events conocidos actualmente por un nodo en particular, lo que permite un modelo coherente en ausencia de información completa sobre el sistema en su conjunto.

Los domain events son inmutables, ya que son un registro de algo en el pasado. Además de una descripción del evento, un domain event normalmente contiene una timestamp del momento en que ocurrió el evento, y la identidad de las entidades involucradas en el evento (de DDD reference de Eric Evans).

El evento del Journal se estratifica en cinco categorías diferentes definidas por el usuario a través de la DSL:

  • Headers – datos específicos del evento

  • Custom business data – se define como los datos suministrados por el cliente en la iniciación del pago que están fuera del conjunto de datos ISO 20022

  • Payment data – el mensaje canónico de IPF en línea con el conjunto de datos ISO 20022, de acuerdo con el mensaje de pago específico

  • Payment processing data – datos relacionados con el recorrido de procesamiento del pago

  • Non-defined data – cualquier otro dato específico del cliente que no encaja en ninguna de las categorías anteriores