Modelado de datos de pago IPF

El enfoque IPF para la modelización de datos de pago

Fundamentalmente, IPF proporciona la capacidad de operar (persistir y propagar hacia abajo) en *cualquier*Java tipos, pero también proporcionamos un conjunto estándar y en crecimiento de Java implementaciones de mensajes ISO 20022.

  • Un pago se representa definiendo uno o más flujos de procesamiento.

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

  • Estos elementos de datos tienen un nombre, una categoría y un Java representación de tipo, y están definidos en una biblioteca fija y reutilizable de elementos de datos.

  • Estas bibliotecas pueden ser definidas por el cliente, pero Icon proporciona una biblioteca existente específicamente para mensajes de pago ISO 20022 para modelar los datos de pago.

Características de valor añadido de IPF

Muchas de las características de valor añadido de IPF dependen del uso de la biblioteca ISO 20022 de IPF para modelar datos de pago. Por lo tanto, le recomendamos la conversión a estas como parte de mapping dentro de la aplicación:

  • Descomposición

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

  • Mapeo

  • Proporcionamos varios mapping capacidades entre mensajes dentro de este modelo

  • Interservicio APIs

  • Proporcionamos un conjunto de API definiciones para modelar el procesamiento de pagos entre servicios, que son una buena referencia a seguir al buscar desarrollar múltiples servicios orquestados. Estos API definiciones hacen referencia a las cargas útiles en la estructura de estos mensajes ISO (por ejemplo, PaymentInitiationRequest espera un Pain. 001.

  • Consulta estándar APIs

  • Proporcionamos un conjunto de estándares APIs desde el ODS servicio para buscar pagos basados en campos de pago comunes dentro de los componentes de mensaje mencionados anteriormente (por ejemplo, buscar por txId, recallId, msgId, debtorName). Estos APIs operar siempre que los datos de pago hayan sido capturados utilizando la biblioteca IPF ISO 20022 en algún momento durante el flujo de procesamiento.

Mensaje ISO de IPF catalogue

IPF admite todos ISO20022(2019) mensajes como opciones genéricas, sin embargo, cualquier mensaje que no esté actualmente en el IPF específico catalogue no tendrá búsqueda directa APIs para consulta. Por lo tanto, añadimos nuevos mensajes a la catalogue, basado en customer requisitos, y revise constantemente la necesidad de nuevos campos buscables en el ODS inquiry API(este es un proceso automatizado y, por lo tanto, el tiempo de respuesta es rápido). La lista actual puede ser vista aquí.

La documentación detallada se puede encontrar en la ISO 20022 message definition s proporcionado por el Autoridad de Registro ISO 20022.

IPF Payments DSL

Un DSL (Lenguaje Específico de Dominio) es un lenguaje de programación con un nivel de abstracción más alto optimizado para una clase específica de problemas. Un DSL utiliza los conceptos y reglas del campo o dominio. Ejemplos de DSL incluyen, pero no se limitan a, SQL, HTML, CSS, etc. En el caso de IPF, Icon ha desarrollado un DSL cuyo dominio son los pagos, por lo tanto, el IPF Payments DSL.

El uso de un payments DSL simplifica y acelera las definiciones de procesos, empoderando al negocio mientras reduce el riesgo en la entrega de código a través de la alineación con la documentación y las pruebas.

dsl generation

  • Icon ha desarrollado un lenguaje orientado a pagos de alto nivel para configurar el pago process flow s. Este lenguaje específico de dominio (DSL) de pagos se crea con el MPS IDE de JetBrains.

  • Icon’s Payments DSL habilita a expertos en pagos y desarrolladores a configurar conjuntamente process flow s, ideal para un enfoque de entrega colaborativa Agile Scrum moderno.

  • El Process Flow La herramienta de construcción utiliza automáticamente process flow configuraciones como entrada para generar automáticamente:

    • Código fuente para ejecutar el proceso en IPF

    • Escenarios de prueba BDD que son utilizados por el Test Framework de Icon para la prueba automatizada de la process flow s

    • Diagrama de flujo como representación visual del process flow

    • Documentación clara de la process flow para una audiencia no técnica

IPF domain events

A domain event es, un hecho crítico que ocurrió en el state del agregado en el dominio del que usted desea que otras partes del mismo dominio (en proceso) estén al tanto. Las partes notificadas generalmente reaccionan de alguna manera a la events. Domain events ayudarle a expresar, explícitamente, las reglas del dominio, basadas en el lenguaje ubicuo proporcionado por los expertos del dominio. (como se define en Microservicios. NET: Arquitectura para Aplicaciones. NET Contenerizadas - Domain events: diseño e implementación).

Información del modelo sobre la actividad en el dominio como una serie de discretas events. Represente cada event como un objeto de dominio. Estos son distintos de system events que reflejan la actividad dentro del software mismo, aunque a menudo un system event está asociado con un domain event, ya sea como parte de una respuesta a la domain event o como una forma de transmitir información sobre el domain event en el sistema. A domain event es una parte integral del modelo de dominio, una representación de algo que ocurrió en el dominio. Ignore la actividad de dominio irrelevante mientras hace explícito el events que los expertos en dominios desean rastrear o ser notificados, o que están asociados con state cambio en los otros objetos del modelo. En un sistema distribuido, el state de una entidad puede inferirse de la domain events actualmente conocido por un nodo particular, permitiendo un modelo coherente en ausencia de información completa sobre el sistema en su conjunto.

Domain events son **inmutables**, ya que son un registro de algo en el pasado. Además de una descripción de la event, a domain event típicamente contiene un **timestamp** para la hora en que el event ocurrió, y **la identidad de las entidades involucradas en el event** (de http://domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf[Referencia DDD] por Eric Evans).

El *Journal*event se estratifica en cinco categorías diferentes que son definidas por el usuario a través del DSL:

  • Encabezados –event datos específicos

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

  • Datos de pago – el mensaje canónico de IPF de acuerdo con el conjunto de datos ISO 20022, según el mensaje de pago específico.

  • Pago processing data – datos relacionados con el proceso de pago

  • Datos no definidos – cualquier otro customer-datos específicos que no encajan en ninguna de las categorías anteriores