Flujo Versioning Guía
Con el tiempo,IPF flows puede necesitar ser actualizado debido a nuevos requisitos, cambios regulatorios o una comprensión más profunda del dominio. Si bien esto es sencillo durante el desarrollo, se vuelve crítico gestionar tales cambios con cuidado una vez que los flujos están en vivo y procesando pagos activamente.
Típicamente, los requisitos clave de los clientes son:
-
El servicio debe continuar procesando pagos con mínima o ninguna interrupción.
-
No hay procesamiento duplicado / doble envío de pagos.
-
Las transacciones en vuelo deben continuar procesándose con la mínima o ninguna interrupción.
Esta página resume las principales formas en las que IPF flows puede evolucionar con el tiempo y proporciona directrices 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 del negocio.
Domain Event Cambios
Estos son típicamente cambios a la definición de domain events dentro de un flujo existente. Como resultado, puede que tenga que escribir código de migración específico que permita una transición sin problemas a las nuevas definiciones actualizadas. Tenga en cuenta que todo depende del tipo de cambio y de si el cambio es disruptivo o no. A continuación se presentan algunos ejemplos de estos cambios:
-
Añadiendo un campo de datos a un event
-
Cambio del nombre de clase completamente calificado (FQCN) de un event
-
Cambio del nombre de un elemento de datos en un event
-
Cambiando el data type de un elemento en un event
-
Dividiendo un event en múltiples, más pequeñas events
-
Eliminando un event
Para entender cómo manejar estos cambios, consulte la documentación de desarrollo de IPF en evolución del esquema.
Cambios en el Flujo de Ruptura
Estos son típicamente los cambios a una definición de flujo existente que modifican la estructura.
Algunos ejemplos son:
-
Cambiando la secuencia de pasos y events en una definición de flujo
-
Agregar un nuevo paso a una definición de flujo existente
-
Eliminando un paso de una definición de flujo existente
-
Añadiendo un nuevo decision a una definición de flujo existente
-
Eliminando un decision de una definición de flujo
-
Agregar/eliminar una llamada a un subflujo en una definición de flujo existente
-
Aplicando los mismos cambios mencionados anteriormente a un subflujo.
Este tipo de cambios no pueden ser gestionados simplemente actualizando el flujo. Se deberá definir un nuevo flujo con un nuevo versioning.
Dependiendo de los requisitos, las versiones anteriores 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 utilicen las versiones anteriores se hayan completado. Mientras tanto, las nuevas transacciones de pago pueden ser dirigidas a una nueva versión del flujo. Para apoyar esta concurrencia, es esencial implementar el flujo.versioning desde el principio. Para un ejemplo práctico y una discusión sobre el flujo versioning, por favor consulte Versionado de Flujo.
Cambios en el Flujo No Interrumpido
Estos son cambios menores en la definición del flujo que no alteran la estructura general del flujo.
Un ejemplo de esto es cambiar la descripción de los elementos del flujo (descripción de events,business data)
En este caso, no será necesario crear una nueva versión del flujo. Aplicar los cambios en la definición del flujo existente será suficiente.