Prácticas Óptimas de Desarrollo

Los recorridos de pago de extremo a extremo normalmente se dividen en 2 o más flujos de orquestación IPF discretos, cada uno representando piezas bien definidas de funcionalidad específica del dominio.

Justificación- Dividir los flujos por áreas de funcionalidad específicas del dominio y reducir la complejidad y el alcance de los flujos los hace:

Implicaciones- Los flujos que componen un viaje de pago deben desglosarse en áreas funcionales discretas. Estas típicamente pueden incluir:

Ver Ejemplo de Diseño de Flujo

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

Justificación- Los diferentes tipos de pago, por ejemplo, los mensajes PACS. 008 entrantes en comparación con los mensajes PAIN. 001 salientes, 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 notificaciones directamente desde IPF flows, sin embargo, IPF tiene otros mecanismos para enviar notificaciones que pueden ser más eficientes que añadir complejidad adicional a los flujos.

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

Implicaciones- Agregar notificaciones 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 las notificaciones son simples y frecuentes (es decir, enviar una notificación cada vez que se alcanza un nuevo estado), considere utilizar ya sea el procesamiento de datos IPF o el servicio de notificación de pagos.

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

Justificación- Si hay un gran número de decisiones 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 ruta posible a través de un flujo. Las decisiones secuenciales pueden 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 decisiones, en flujos más pequeños y coloque las decisiones sobre qué flujo llamar en el flujo anterior.

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

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

Justificación- Los datos que se envían a dominios externos y se utilizan en otros procesos de flujo se almacenan en eventos de dominio y del sistema. Estos eventos se almacenan en la base de datos y se transmiten a otros sistemas (por ejemplo, a la ODS a través del procesamiento de datos de IPF).

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 apoya 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 una decisión de flujo específica o una transición de estado 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 (código Java) o, mejor aún, en un servicio separado. Así, si ese sistema es reemplazado en el futuro, la lógica específica puede ser sustituida sin necesidad de 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 diversos paquetes de esquemas 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 paquete de esquema soportado sin que el cliente necesite entender o gestionar los requisitos específicos de cada esquema. Todos los requisitos específicos de cada esquema mapping y el enriquecimiento será gestionado por el propio paquete del esquema.

Este enfoque permite que los paquetes de esquemas sean intercambiables con un esfuerzo de desarrollo mínimo.

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

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, al agregar un nuevo estado), entonces puede que no sea posible continuar procesando esas transacciones en curso después de que se despliegue la nueva versión.

Versioningflows resuelve esto asegurando que todas las transacciones en curso continúen procesándose en la misma versión del flujo en la que fueron iniciadas.

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

Debe considerar crear una nueva versión para los cambios de orquestación central, incluyendo la adición de una nueva decisión (por lo tanto, una nueva ruta en el flujo), un nuevo estado, una nueva interacción con dominios externos y un cambio en el comportamiento de los eventos.

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

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

Implicaciones- Siempre asegúrese de que el estado final en un flujo esté marcado como terminal:

Cuando un flujo se ha pausado en un estado particular, 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 dominios externos.

Justificación- Al realizar interacciones asíncronas con dominios externos, 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 dominios externos tengan un id 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.

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.

Los flujos de proceso se dividen en tres subdominios: Gestión de Iniciación, Ejecución y Liquidación & Compensación.

En el caso del procesamiento de pagos en masa, el flujo de iniciación encapsulará un componente de desagregación; este realizará la función de desagregar la instrucción de pago y luego iniciará un flujo de ejecución para cada una de las instrucciones dentro del conjunto.

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: