Una Introducción a la IPF

El Payments DSL(Domain Specific Language) es cómo payment flows/lasorquestaciones se definen en el Icon Payment Framework(IPF) utilizando una herramienta llamada MPS que, cuando se combina con nuestro idioma y custom Los elementos de la interfaz gráfica están marcados como la parte de Flow Designer de IPF Studio. Los flujos de pago se definen como máquinas de estados y varios pueden combinarse para procesar un pago hasta su finalización.

Como parte del proceso de construcción del IPF, se genera documentación relacionada con el(los) flujo(s) definido(s).

IPF utiliza Event Patrones de Sourcing y Segregación de Responsabilidad de Consultas (CQRS). Esto significa que almacena una serie de eventos, o hechos, que han ocurrido durante el ciclo de vida de la transacción. Events podría ser 'PaymentValidated', 'PaymentBooked', 'PaymentSettled' etc.

CQRS &Event La obtención significa que hay un registro de solo adición para cada transacción. Este registro documenta todos los hechos y SOLO documenta los hechos. No hay actualizaciones de hechos ni eliminación de hechos.- solo hechos nuevos. Esta colección de hechos se denomina el almacén de eventos y es el 'lado de escritura' o 'fuente de eventos' de IPF. El lado de escritura se separa como una solución a muchos de los NFR de IPF.

Los eventos/hechos se transmiten a la ODS base de datos que se utiliza para todas las consultas y se denomina 'lado de lectura', que es eventualmente consistente con el lado de escritura (después de, digamos, unos 100 ms). La vista del lado de lectura puede generarse en varias formas basadas en los eventos, por lo que puede ver una vista de transacción normal que muestra cómo se ve un pago en el estado actual de procesamiento, pero también puede ver un registro de auditoría completo de lo que sucedió. Los clientes pueden tener tantos lados de lectura como deseen, cada uno construyendo su propia vista a partir del flujo de eventos.

Para obtener más información sobre event sourcing, por favor lea 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 Mensajes Externos.

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

IPF tiene un mapping framework que, desde una perspectiva no desarrolladora, podemos pensar en ellos como adaptadores que convierten una acción en el DSL en algo tangible en código. Por ejemplo dominio externo las acciones realizan una solicitud a algo externo a una implementación de IPF y el adaptador convierte esto en una solicitud al sistema externo API/la interfaz entiende y lo envía a través de un transporte que puede manejar.

Utilizando un ejemplo del mundo real, la acción 'pantalla de pago' en el DSL utiliza un adaptador para llamar a un particular API sobre ese sistema de Sanciones a través de HTTP, o quizás 'consulte el saldo' en el sistema contable a través de MQ.

Si escucha a personas hablando sobre mappers, puentes o conectores, estos son diferentes componentes técnicos que forman lo que un no desarrollador puede considerar como un adaptador. Además de permitir que se envíen acciones desde el flujo, los adaptadores pueden realizar las mismas tareas para recibir entradas (por ejemplo, el resultado de una verificación de sanciones) o un mensaje que inicia un flujo, por ejemplo, una iniciación de pago desde un canal. Los adaptadores pueden estar relacionados con sistemas bancarios o servicios comerciales de IPF (por ejemplo, Alcance en el diagrama anterior).

IPF está licenciado de dos maneras diferentes. La licencia básica incluye elementos que cada cliente necesitaría para construir una solución de procesamiento de pagos sensata. Los Módulos Opcionales Adicionales (AOMs) son elementos que solo algunos clientes necesitarán, y cada módulo se licencia por separado.

Los módulos adicionales opcionales actuales son:

IPF tiene un concepto de Scheme packs(técnicamente conocido como CSM Services, consulte el diagrama anterior) que oculta las complejidades de diferentes CSMs de los flujos DSL. Por ejemplo, si CSM’A' envía una respuesta positiva a un recall utilizando un Pacs004, mientras que CSM’B' envía una respuesta positiva a un recall utilizando un Camt029 y un Pacs008, los cuales están estandarizados de tal manera que el flujo DSL para el procesamiento de respuestas positivas no necesita conocer cómo diferentes CSMs implementan respuestas positivas. IPF tiene varios CSM paquetes disponibles como módulos opcionales adicionales y el cliente también puede crear los suyos para cualquier relación ACH o bilateral deseada con la que desee intercambiar mensajes de pago.

IPF ofrece dos enfoques para la configuración:

Human Task Manager(a menudo denominado como HTM) proporciona a los flujos la capacidad de crear tareas para operadores humanos, así como la opción de devolver los resultados de las tareas al flujo. Ejemplos del tipo de cosas Human Task Manager puede ser utilizado para incluir:

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

Una función empresarial es una pieza discreta de lógica empresarial central que puede ser utilizada por flujos. Ejemplos de funciones empresariales incluyen Validar BIC, Verificación de duplicados y Desconstruir IBAN.

IPF viene con dos características para manejar archivos de transacciones masivas.Granelero, que agrupa transacciones en archivos por lotes según la configuración y Desmenuzador que interrupciones recibidas bulked archivos en componentes individuales según la configuración.

IPF viene con una capacidad que permite la creación de varios métricas empresariales y tableros técnicos que muestran cómo están funcionando las soluciones construidas con IPF.

IPF viene con un Operational Dashboard que recomendamos utilizar para interactuar con ODS y su implementación de IPF; puede utilizar cualquier interfaz que desee. La Operational Dashboard está fuertemente customisable, se pueden eliminar componentes de interfaz gráfica listos para usar, se pueden agregar componentes específicos del cliente y también mappings Las pantallas estándar pueden ser especificadas por los clientes para ajustarse a su modelo de datos de flujo. Además de esto, la apariencia y la sensación están 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 servicio de alcanzabilidad es un servicio dedicado a la gestión de información relacionada con la alcanzabilidad y a la toma de decisiones de enrutamiento basadas en esos datos. Carga datos de industria fuentes como ACH's (Ya sea como parte de un paquete de esquema IPF opcional o mediante un cargador creado por los clientes) y SWIFT así como datos provenientes del banco.

Los datos abarcan áreas que incluyen CSM participación, detalles de la fiesta, límites, etc. Ejemplos del tipo de funcionalidad proporcionada por el servicio de alcanzabilidad son Seleccione CSM Agente y Valide la Alcanzabilidad Intraentidad.

System eventsse puede considerar como un registro de aplicación tradicional. Al igual que los registros tradicionales, tienen un nivel (INFO, DEBUG, ERROR o WARN) y un tipo (Funcional o Técnico). Hay un catálogo de eventos incluidos con IPF, pero los clientes también pueden crear sus propios eventos de sistema personalizados. Las soluciones construidas con IPF publican eventos de sistema basados en la configuración y cualquier sistema interesado puede escuchar los eventos.