Documentation for a newer release is available. View Latest

DSL 8 - Versionado

Comenzando

Este paso del tutorial utiliza como punto de partida la solución "handling_timeouts" del proyecto.

Si en cualquier momento quieres ver la solución de este paso, la encontrarás en la solución "add_version".

Versionado

Supongamos que tenemos un flujo ejecutándose en producción. Llega un requisito para añadir un nuevo paso al flujo: queremos que las transacciones en curso sigan en el flujo actual, pero que todas las nuevas transacciones comiencen a procesarse en el flujo actualizado. Podemos conseguirlo mediante versionado.

Para los fines de este tutorial, vamos a insertar un paso para llamar a un servicio CSM, pero también queremos preservar el flujo original. Lo haremos creando una nueva versión de nuestro flujo de ejecución y añadiendo el paso extra solo en esa versión.

Una visión general completa del versionado de flujos está disponible en nuestra guía de versionado de flujos.

Versionar el flujo

Es hora de configurar el versionado. Si miramos nuestro flujo actual veremos:

version 1

Aquí podemos ver que dice "No Versioning". Vamos a activar el versionado.

Empezaremos configurando la versión actual a 1 y después pulsaremos ALT + ENTER sobre el flujo y seleccionaremos "New Version" en el desplegable:

version 2

Si miras en el navegador, ahora veremos:

version 3

Aquí hemos elegido cambiar la versión del flujo original a 1 en este punto. También podríamos haberlo dejado sin versionar; en ese caso, nuestra nueva versión se definiría como V1. En general, si sabes que probablemente un flujo necesitará versionarse, puede ser mejor llamarlo versión 1 desde el principio, ya que hay un par de pequeños cambios de código requeridos (lo veremos en la sección de implementación).

Abramos "Ipftutorialflow (V2)"; encontraremos un clon exacto de nuestro flujo original, excepto que ahora tiene la versión especificada como V2 (nota: el flujo original ahora también tiene la Version especificada).

version 4

También puedes ver aquí que se ha creado un nuevo conjunto de funciones de mapeo en el nuevo flujo. Esto es porque las definimos a nivel de flujo. También es posible definirlas fuera de un flujo mediante una 'Mapping Library', en cuyo caso se usaría el mismo mapeo en ambos flujos.

Ahora estamos listos para editar nuestro flujo versión 2. Sin embargo, antes de hacerlo, necesitamos crear el servicio CSM que se usará en V2.

Definir el servicio CSM

Lo primero que necesitamos es invocar nuestro servicio CSM. Haremos:

  • Enviar al CSM un pacs.008

  • Recibir del CSM un pacs002, que puede contener un código de aceptado o rechazado.

Para esto necesitaremos un nuevo dominio externo y una petición definida en él. Es muy similar a lo que hicimos en DSL 4 - Uso de un dominio externo. Llamaremos a nuestra petición "Clear and settle".

Intenta configurarlo tú mismo; la solución está abajo:

version 5

Actualizar el flujo V2

Mientras que antes teníamos el siguiente "Event Behaviour":

version 6

Cambiarás esto para que, en lugar de movernos a "Complete" y lanzar nuestro evento adicional, pasemos a un nuevo estado "Clear And Settling" y después invoquemos nuestra petición Clear and Settle (definida en el servicio CSM).

Si la petición clear and settle es satisfactoria, pasaremos a completar y lanzaremos nuestro evento. Si falla, pasaremos a Rejected.

Intenta añadir esas condiciones ahora; la solución está abajo. Recuerda que necesitaremos añadir los States apropiados, las definiciones de Event, el Input Behaviour y, por último, el Event Behaviour.

(Si necesitas un repaso, revisa: DSL 4 - Uso de un dominio externo)

Primero, aquí está la definición de estados:

version 7

Luego necesitaremos un evento para la respuesta positiva y otro para la respuesta negativa del CSM:

version 8

No olvides, al configurar estos eventos, que el servicio CSM nos devuelve el pacs002 y queremos almacenarlo como business data.

A continuación, nuestro input behaviour; es muy estándar:

version 9

Y finalmente nuestro event behaviour:

version 10

Observa aquí que hemos aplicado la lógica de clear and settle tanto a los casos de "Skip Fraud" como de "Fraud Required".

Con esto ya está todo lo necesario: hemos creado con éxito una nueva versión del flujo y la hemos actualizado para usar nuestro servicio CSM. Si miramos el flujo para la versión 2 veremos:

version 11

Mientras que el flujo para la versión 1 permanece sin este paso.

Con esto termina nuestro trabajo en el DSL; pasemos ahora a la parte de implementación.

Implementación en Java

Como siempre, empecemos la implementación regenerando nuestra base de código.

mvn clean install

Cambios de configuración

Cuando habilitamos versiones, la clase de dominio generada expone constructores/adaptadores específicos por versión. Asegúrate de añadir los adaptadores necesarios para V2 y, si procede, mantener los de V1 para que las ejecuciones existentes continúen funcionando. Si usas implementaciones de ejemplo (sample adapters) para los puertos, añádelos para el nuevo dominio externo CSM.

Selección de versión en tiempo de ejecución

  • Las nuevas iniciaciones deben dirigirse a la última versión (V2). Puedes controlar esto en el punto de entrada (p. ej., controlador HTTP) estableciendo el FlowId/versión apropiados cuando inicies el flujo.

  • Las instancias en curso continúan en su versión original; IPF preserva automáticamente la asociación de versión para cada unidad de trabajo.

Si decidiste dejar el flujo original sin versionar y crear V1 como la nueva versión, puede que veas diferencias menores en los nombres de clases/puertos generados. La guía de versionado enlazada arriba detalla los ajustes requeridos.

Comprobación de nuestra solución

Arranca la aplicación como antes (si necesitas recordatorio, consulta Revisión de la aplicación inicial).

  • Inicia una nueva transacción y verifica, en la GUI del desarrollador, que recorre el flujo V2 e invoca el servicio CSM antes de completar.

  • Carga una transacción existente (iniciada antes del cambio) y confirma que sigue usando el flujo V1 sin el paso adicional.

Conclusiones

En esta sección:

  • Activamos el versionado del flujo y creamos V2 conservando V1.

  • Definimos un nuevo dominio externo (CSM) y su petición/respuestas.

  • Actualizamos el Event Behaviour para invocar clear and settle en V2.

  • Revisamos consideraciones de implementación y ejecución para múltiples versiones.