Guía de versionado de flujos
Con el tiempo, los flujos de IPF pueden necesitar actualizarse debido a nuevos requisitos, cambios regulatorios o una comprensión más profunda del dominio. Aunque esto es sencillo durante el desarrollo, se vuelve crítico gestionar dichos cambios con cuidado una vez que los flujos están en producción y procesando pagos activamente.
Típicamente, los requisitos clave de los clientes son:
-
El servicio debe seguir procesando pagos con una interrupción mínima o nula
-
No debe haber procesamiento duplicado / doble envío de pagos
-
Las transacciones en curso deben seguir procesándose con una interrupción mínima o nula
Esta página resume las principales formas en que los flujos de IPF pueden evolucionar con el tiempo y proporciona pautas de alto nivel sobre cómo implementar los cambios descritos.
Tipos de cambios
Los cambios en los flujos pueden tener diferentes formas, dependiendo del cambio en los requisitos de negocio.
Cambios en Domain Events
Estos suelen ser cambios en la definición de los domain events dentro de un flujo existente. Como resultado, puede que tengas que escribir código de migración específico que permita una transición fluida a las definiciones nuevas/actualizadas. Ten en cuenta que todo depende del tipo de cambio y de si el cambio es breaking o no. A continuación algunos ejemplos de estos cambios:
-
Añadir un campo de datos a un evento
-
Cambiar el nombre de clase totalmente cualificado (FQCN) de un evento
-
Cambiar el nombre de un elemento de datos en un evento
-
Cambiar el tipo de datos de un elemento en un evento
-
Dividir un evento en varios eventos más pequeños
-
Eliminar un evento
Para comprender cómo manejar estos cambios, consulta la documentación de IPF sobre evolución de esquemas.
Cambios breaking en el flujo
Estos suelen ser los cambios en una definición de flujo existente que cambian la estructura.
Algunos ejemplos son:
-
Cambiar la secuencia de pasos y eventos en una definición de flujo
-
Añadir un nuevo paso a una definición de flujo existente
-
Eliminar un paso de una definición de flujo existente
-
Añadir una nueva decisión a una definición de flujo existente
-
Eliminar una decisión de una definición de flujo
-
Añadir/eliminar una llamada a subflujo en una definición de flujo existente
-
Aplicar los mismos cambios anteriores a un subflujo
Este tipo de cambios no puede manejarse simplemente actualizando el flujo. Será necesario definir un nuevo flujo con una nueva versión.
Dependiendo de los requisitos, las versiones antiguas del flujo deberán permanecer disponibles en la aplicación durante un período de tiempo, específicamente hasta que todas las transacciones en curso que usan las versiones antiguas hayan completado. Mientras tanto, las nuevas transacciones de pago pueden encaminarse a una nueva versión del flujo. Para soportar esta concurrencia, es esencial implementar el versionado de flujos desde el principio. Para un ejemplo práctico y una discusión sobre el versionado de flujos, consulta Flow Versioning.
Cambios no breaking en el flujo
Estos son cambios menores en la definición del flujo que no cambian la estructura general del flujo.
Un ejemplo de esto es cambiar la descripción de los elementos del flujo (descripción de eventos, business data).
En este caso, no será necesario crear una nueva versión del flujo. Aplicar los cambios en la definición de flujo existente será suficiente.