Prácticas Óptimas de Desarrollo

Los tipos de pago funcionalmente diferentes deben tener diferentes flujos de orquestación, por ejemplo, pagos entrantes y salientes.

Justificación- Tipos de pago diferentes, por ejemplo, entrante PACS. 008 mensajes comparados con salientes PAIN. 001 Los mensajes son funcionalmente diferentes desde la perspectiva del procesamiento de pagos y, por lo tanto, requerirán diferentes flujos de orquestación.

Implicaciones- Los flujos de orquestación de pagos deben dividirse por diferentes tipos de procesamiento:

Diferentes flujos consumirán datos de diferentes colas de mensajes, permitiendo que diferentes tipos de pagos sean priorizados de acuerdo con los requisitos.

Cabe destacar que los flujos de iniciación son normalmente CSM/Scheme agnóstico.

Aunque los diferentes tipos de pagos pueden tener diferentes flujos de orquestación, estos flujos pueden y deben contener componentes reutilizables compartidos entre los flujos (por ejemplo, componentes/bibliotecas compartidos, subflujos).

Justificación- El procesamiento de diferentes tipos de pago probablemente contendrá mucha similitud:

Implicaciones- IPF fomenta la reutilización de componentes de flujo mediante la creación de bibliotecas de flujo reutilizables. Estas bibliotecas pueden ser reutilizadas en múltiples flujos.

Consulte estas páginas para ejemplos y guías.Cree bibliotecas reutilizables&Subflujos

Es posible enviar notifications directamente de IPF flows, sin embargo, IPF tiene otros mecanismos para enviar notifications que puede ser más eficiente que añadir complejidad adicional a los flujos

Justificación- IPF tiene múltiples opciones para permitir que los clientes reciban notifications

Implicaciones- Añadiendo notifications a un flujo añade complejidad y latencia a ese flujo. Este puede ser el mejor enfoque cuando la notificación requiere lógica compleja y utiliza datos del contexto de procesamiento del flujo.

Sin embargo, cuando notifications son simples y frecuentes (es decir, enviar una notificación cada vez que se recibe un nuevo state se alcanza), considere utilizar ya sea IPF processing data o el servicio de notificación de pagos.

Un número excesivo de decision Los estados dentro de un flujo sugieren que se están cubriendo demasiados casos de uso dispares por un solo flujo, así como causando un número exponencialmente mayor de posibles caminos a través del flujo.

Justificación- Si hay un gran número de decisions En un flujo de procesamiento, esto puede deberse a que el flujo está tratando de abarcar demasiados casos de uso empresarial, y por lo tanto tiene demasiada complejidad.

Además, IPF utiliza un marco BDD para probar flujos como parte del proceso de construcción; durante estas pruebas se evalúa cada posible ruta a través de un flujo. Secuencial decisions puede aumentar exponencialmente el número de caminos posibles a través del flujo, haciendo que los BDD sean inmanejables.

Implicaciones- Divida flujos grandes, con múltiples decisions, en flujos más pequeños y coloque decisions acerca de qué flujo llamar en el flujo anterior.

Por ejemplo, cree flujos de ejecución adicionales y coloque decision lógica sobre cuál llamar en el flujo de iniciación.

Al interactuar con external domains y funciones, intente utilizar el conjunto de datos mínimo requerido para esa interacción en lugar de enviar cargas de datos grandes innecesariamente.

Justificación- Datos que se envían a external domains, y utilizado en otros procesos de flujo, se almacena en el dominio y system events. Estos events se almacenan en la base de datos y se transmiten a otros sistemas (por ejemplo, a la ODS vía IPF processing data).

El uso de objetos de datos innecesariamente grandes para estas interacciones provoca que se almacene y envíe datos innecesarios, consumiendo así recursos del sistema que no son requeridos.

Implicaciones- Al diseñar interfaces e interacciones con sistemas externos, asegúrese de que los contratos de datos solo requieran la información necesaria para ese caso de uso empresarial.

Cabe destacar también que los datos se recopilan dentro de la ODS(por uowId) y soporta la agregación de datos a través de sus flujos e interacciones con dominios externos.

No toda la lógica necesita ser implementada en la orquestación del flujo (es decir, dentro del flujo DSL). Puede ser preferible implementar cierta lógica dentro de Java código o incluso un servicio externo.

Justificación- A veces hay complejidad en el proceso de pagos que es causada por una interacción con un sistema externo específico (por ejemplo, una peculiaridad del sistema contable); sin embargo, esa complejidad se eliminaría si ese sistema fuera reemplazado en el futuro.

Implicaciones- Generalmente, si la lógica se relaciona con un flujo específico decision or state transición para el procesamiento del pago, entonces pertenece al flujo.

Sin embargo, si se relaciona con la complejidad de un sistema específico, en lugar del flujo general de transacciones de pago, entonces puede ser mejor encapsular esa lógica en un conector (java código) o mejor aún, un servicio separado. Entonces, si ese sistema es reemplazado en el futuro, la lógica específica puede ser reemplazada sin tener que cambiar el DSL del flujo de pagos.

El Icon Standard está diseñado para simplificar cómo los clientes integran su payment flows con los varios scheme pack s ofrecidos por Icon para la conectividad de esquemas de pago externos. Al seguir el Estándar de Icon, los clientes pueden construir mensajes y flujos de pago que son independientes del esquema — el mismo formato de mensaje puede ser enviado a cualquier sistema soportado.scheme pack sin que el cliente necesite entender o gestionar los requisitos específicos del esquema. Todos los requisitos específicos del esquema mapping y el enriquecimiento será gestionado por el scheme pack en sí mismo.

Este enfoque permite scheme pack s debe ser intercambiable con un esfuerzo de desarrollo mínimo.

Descubra cómo implementar y aprovechar al máximo Estándar de Icono

Todos los flujos deben estar versionados para que puedan ser actualizados de manera limpia.

Justificación- Si se realizan cambios en un flujo y se despliegan mientras hay transacciones en curso (por ejemplo, añadiendo un nuevo state) entonces puede que no sea posible continuar procesando esas transacciones en curso después de que se despliegue la nueva versión.

Implicaciones- Asegúrese de que todos los flujos estén versionados, puede encontrar instructions y orientación en el Tutorial.

Debería considerar crear una nueva versión para core cambios de orquestación, incluyendo la adición de un nuevo decision(por lo tanto, nueva ruta en el flujo), una nueva state, nueva interacción de dominio externo, un cambio en event comportamiento.

Siempre asegúrese de que los flujos de orquestación terminen en un "terminal".state.

Justificación- IPF flows se eliminan de la memoria cuando alcanzan un terminal state. Por lo tanto, si el final state si un flujo no está marcado como terminal, entonces el flujo permanecerá en memoria dependiendo de la Estrategia de Pasivación y no se marcará como completo.

Implicaciones- Siempre asegúrese de que el final state en un flujo se marca como terminal:

Cuando un flujo se ha pausado en un particular state, esperando una entrada de un proceso de larga duración, puede ser necesario desactivar el flujo para evitar que consuma memoria en el Akka cluster.

Justificación- Algunos flujos tienen estados que se sabe que son de larga duración, por ejemplo:

Durante este tiempo, el flujo permanecerá en memoria por defecto a menos que se tome acción para desactivar el flujo.

Implicaciones- Cuando un flujo entra en uno de estos estados, puede ser eficiente programáticamente pasivar el flujo

Asegúrese de que los identificadores de correlación sean siempre únicos al comunicarse con external domains.

Justificación- Al realizar interacciones asíncronas con external domains, IPF utiliza un almacén de correlación para asociar pares de solicitud / respuesta. Las entradas en este almacén de correlación se recuperan utilizando un id de correlación y, por lo tanto, cada interacción con un dominio externo, a través de cada flujo, debe utilizar un id de correlación único.

Implicaciones- Asegúrese de que todas las interacciones con external domains tiene un identificador de correlación único. Puede leer más sobre la correlación aquí Asociación de Mensajes&Modelo de Datos de Correlación

Al utilizar Versionado de Flujo, y al implementar una nueva versión de su flujo, debe considerar y estar al tanto de lo que sucede con las transacciones en curso.

Justificación - Puede haber casos en los que una transacción se haya iniciado en la V1 del flujo, pero esté en pausa esperando una respuesta/instrucción para un proceso de larga duración externo al flujo. Durante este tiempo, usted ha desplegado la V2 del flujo, pero las transacciones en curso aún no se encuentran en un estado terminal.state.

Este escenario es perfectamente válido y cuando las transacciones antiguas en el flujo V1 se reanuden, continuarán en el flujo en el que comenzaron, en este caso el flujo V1. Cualquier nueva transacción que se haya iniciado desde la actualización se ejecutará en el flujo V2.

Implicaciones- No es posible que una transacción iniciada utilizando una versión de un flujo (por ejemplo, V1) sea reanudada utilizando otra (por ejemplo, V2). Debe reanudar el flujo en el flujo original (V1) o iniciar un nuevo flujo en la nueva versión (V2).

A continuación se presenta un ejemplo de una transferencia de crédito saliente donde el banco actúa como agente deudor.

El process flow s se dividen en tres subdominios: Gestión de Iniciación, Ejecución y Liquidación & Compensación.

En el caso de la bulk procesamiento de pagos, el flujo de iniciación encapsulará un debulker componente; esto realizará la función de debulking la instrucción de pago y luego instigando un flujo de ejecución para cada uno de los instructions dentro de la bulk.

A continuación se enumeran las funcionalidades que se realizan típicamente en cada subdominio; esto es indicativo, más que fijo, y dependerá de los requisitos específicos del banco: