Una Introducción a la FPI

El Payments DSL(Domain Specific Language) es cómo payment flows Las /orquestaciones 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. Payment flows 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 Sourcing y patrones de Separación de Responsabilidad de Comando y Consulta (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 Sourcing significa que hay un registro de solo anexos 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 nuevos hechos. Esta colección de hechos se llama el event almacenar y es el 'lado de escritura' o 'event fuente' de IPF. El lado de escritura se separa como una solución a muchos de los NFR de IPF.

El events/factores se transmiten a la ODS base de datos que se utiliza para todas las consultas y se denomina 'lado de lectura' que es eventually consistente con el lado de escritura (después de decir, unos pocos 100ms). La vista del lado de lectura puede generarse en varias formas basadas en el events, para que pueda ver una vista de transacción normal que muestra cómo se ve un pago en la actualidad.state de procesamiento, pero también puede ver un registro de auditoría completo de lo que sucedió. Los clientes pueden tener tantas vistas de lectura como deseen, cada una construyendo su propia vista a partir de la event stream.

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. El core La licencia 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, siendo cada módulo licenciado por separado. Ejemplos de módulos opcionales adicionales incluyen todos Scheme packs, el Marco de Reglas de Negocio, el ODS y Resolución de Identidad.

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 parte discreta de core lógica empresarial 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 bulk archivos de transacción.Granelero, que agrupa transacciones en bulk archivos basados en 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 GUI 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 gestionar información relacionada con la alcanzabilidad y a realizar el enrutamiento.decisions basado en esos datos. Carga datos de industria fuentes como ACH's (Ya sea como parte de un IPF opcional scheme pack o por un cargador creado por los clientes) y SWIFT así como datos obtenidos de bancos.

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 of events incluido con IPF, pero los clientes también pueden crear su propio a medida system events. Soluciones construidas con IPF publican system events basado en la configuración y cualquier sistema interesado puede escuchar a events.