Una introducción a IPF

El Payments DSL (Domain Specific Language) es cómo se definen los flows/orquestaciones de pagos en el Icon Payment Framework (IPF) usando una herramienta llamada MPS que, combinada con nuestro lenguaje y elementos GUI personalizados, se presenta como la parte de Flow Designer de IPF Studio. Los flows de pago se definen como state machines y varios pueden combinarse para procesar un pago hasta su finalización.

Como parte del proceso de build de IPF, se genera documentación relacionada con los flow(s) definidos.

IPF usa patrones de Event Sourcing y Command Query Responsibility Segregation (CQRS). Esto significa que almacena una serie de events, o hechos, que han ocurrido durante el ciclo de vida de la transacción. Los eventos podrían ser 'PaymentValidated', 'PaymentBooked', 'PaymentSettled', etc.

CQRS y Event Sourcing significan que hay un log de solo anexado para cada transacción. Este log registra todos los hechos y SOLO registra los hechos. No hay actualizaciones de hechos ni eliminación de hechos: solo hechos nuevos. Esta colección de hechos se llama event store y es el 'write side' o 'event source' de IPF. El write side se separa como solución a muchos de los NFRs de IPF.

Los events/facts se transmiten a la base de datos ODS, que se usa para todas las consultas y se denomina 'read side', la cual es eventualmente consistente con el write side (después de, digamos, unos cientos de ms). La vista de read side puede generarse en varias formas basadas en los events, para que puedas ver una vista normal de transacción que muestra el estado actual del procesamiento, pero también puedes ver un registro de auditoría completo de lo que ocurrió. Los clientes pueden tener tantas read sides como deseen, cada una construyendo su propia vista a partir del event stream.

Para más información sobre event sourcing, lee Akka Persistence.

El message log se utiliza para almacenar todos los mensajes enviados y recibidos por IPF a CSMs, sistemas bancarios, etc. Estos se denominan External Messages.

Fundamentalmente, IPF tiene tres conceptos diferentes en su modelo de datos de flow.

IPF tiene un mapping framework que, desde una perspectiva no desarrolladora, podemos pensar como adaptadores que convierten una acción en el DSL en algo tangible en código. Por ejemplo, las acciones de external domain realizan una solicitud a algo externo a una implementación de IPF y el adaptador la convierte en una solicitud que el sistema/API/interfaz externo entiende y la envía por un transporte que pueda manejar.

Usando un ejemplo real, la acción 'screen payment' en el DSL utiliza un adaptador para llamar a una API concreta en ese sistema de Sanciones específico vía HTTP, o quizá 'check balance' en el sistema contable vía MQ.

Si escuchas hablar de mappers, bridges o connectors, estos son diferentes componentes técnicos que forman lo que alguien no desarrollador puede considerar un adaptador. Además de permitir enviar acciones desde el flow, los adaptadores pueden realizar las mismas tareas para recibir entrada (p. ej., el resultado de una comprobación de sanciones) o un mensaje que inicia un flow, p. ej., una iniciación de pago desde un canal. Los adaptadores pueden estar alrededor de sistemas bancarios o servicios de negocio de IPF (p. ej., Reachability en el diagrama anterior).

IPF se licencia de dos maneras diferentes. La licencia core incluye cosas que todo cliente necesitaría para construir una solución sensata de procesamiento de pagos. Additional Optional Modules (AOMs) son cosas que solo algunos clientes necesitarán, con cada módulo licenciado por separado. Ejemplos de módulos opcionales adicionales incluyen todos los Scheme packs, el Business Rules Framework, el ODS y Identity Resolution.

IPF tiene el concepto de Scheme packs (técnicamente conocidos como CSM Services, ver el diagrama anterior) que ocultan las complejidades de diferentes CSMs a los flows del DSL. Por ejemplo, si el CSM 'A' envía una respuesta positiva a un recall usando un Pacs004, mientras que el CSM 'B' envía una respuesta positiva a un recall usando un Camt029 y un Pacs008, estos se estandarizan de tal manera que el flow del DSL para procesar respuestas positivas no necesita saber cómo diferentes CSMs implementan respuestas positivas. IPF tiene varios CSM packs disponibles como módulos opcionales adicionales y el cliente también puede crear los suyos para cualquier ACH o relación bilateral con la que desee intercambiar mensajes de pago.

IPF ofrece dos enfoques para la configuración:

Human Task Manager (a menudo denominado HTM) proporciona a los flows la capacidad de crear tareas para operadores humanos y, opcionalmente, devolver los resultados de las tareas al flow. Ejemplos del tipo de cosas para las que se puede usar Human Task Manager incluyen:

La funcionalidad para encontrar y gestionar tareas forma parte de IPF, mientras que cada tarea en sí es definida por los clientes de IPF, incluyendo una pantalla personalizada para la tarea.

Una business function es una pieza discreta de lógica de negocio core que puede ser usada por los flows. Ejemplos de business functions incluyen Validate BIC, Duplicate Check y Desconstruct IBAN.

IPF viene con dos funcionalidades para manejar archivos de transacciones en lote. Bulker, que agrupa transacciones en archivos en lote según la configuración, y Debulker, que desagrupa archivos recibidos en lote en componentes individuales según la configuración.

IPF incluye una capacidad que permite la creación de varios business metrics y technical dashboards que muestran cómo están funcionando las soluciones construidas con IPF.

IPF incluye un Operational Dashboard que recomendamos usar para interactuar con ODS y tu implementación de IPF; aunque puedes usar cualquier front-end que quieras. El Operational Dashboard es altamente personalizable; los componentes GUI listos para usar pueden eliminarse, se pueden añadir componentes específicos del cliente y también los clientes pueden especificar mapeos a pantallas estándar para ajustarse a su modelo de datos de flow. Además, el look and feel está bajo el control de los clientes.

El Operational Dashboard utiliza el mecanismo de autenticación y autorización de los clientes; no gestiona usuarios por sí mismo.

El reachability service es un servicio dedicado para gestionar información relacionada con la reachability y tomar decisiones de enrutamiento basadas en esos datos. Carga datos de fuentes de industry, como ACH (ya sea como parte de un IPF scheme pack opcional o mediante un cargador creado por los clientes) y de SWIFT, así como datos procedentes del banco.

Los datos cubren áreas como la participación en CSM, detalles de las partes, límites, etc. Ejemplos del tipo de funcionalidad proporcionada por el reachabilty service son Select CSM Agent y Validate Intra Entity Reachability.

System events pueden pensarse como un log de aplicación tradicional. Como los logs tradicionales, tienen un nivel (INFO, DEBUG, ERROR o WARN) y un tipo (Functional o Technical). Hay un catalogue de eventos incluido con IPF, pero los clientes también pueden crear sus propios system events a medida. Las soluciones construidas con IPF publican system events basados en la configuración y cualquier sistema interesado puede escuchar los eventos.