Conceptos de Flujo

Flujos

En IPF, el procesamiento de un pago se realiza y controla mediante un "Flow". Un flujo representa un único proceso de negocio de principio a fin y está diseñado para especificar la duración de un único pago. Un solo flujo puede tener múltiples caminos a través de él, cada uno representando una forma diferente de procesar un pago individual basado en los datos proporcionados para ese flujo.

Un flujo contiene una serie de elementos:

  • "Nombre"

  • "Descripción"

  • "Versión"

  • "Conjunto de estado global"

  • Lista de "Estados"

  • Lista de "Events"

  • Initiation Behaviour"

  • Lista de "Input Behaviours

  • Lista de "Event Behaviours"

  • Lista de "Aggregate Functions"

  • Lista de "Definiciones de Funciones de Mapeo"

  • Lista de "Enriquecedores de Entrada"

Se discute una definición de cada uno de estos aspectos en las otras secciones de Conceptos.

La combinación de "Nombre del Flujo" y "Versión del Flujo" identifica de manera única un flujo. La versión es solo un identificador numérico opcional, por lo que, por ejemplo, un flujo puede llamarse "Prueba" y tener la versión 3. Entonces, el flujo puede ser identificado de manera única como "Prueba V3". Si no se definió una versión, puede ser identificado simplemente por el nombre "Prueba". Este identificador se conoce como "Flow Id".

Subflows

Lo siguiente a considerar son los segmentos reutilizables del flujo.

Podemos, por ejemplo, necesitar realizar un chequeo de sanciones en varios lugares diferentes dentro del flujo. Podríamos especificar cada sección del flujo por separado y redactar la lógica cada vez, pero idealmente nos gustaría poder reutilizar la lógica común cada vez. Aquí es donde se introduce el concepto de "Subflujo".

Un subflujo es un componente de flujo reutilizable. Es esencialmente lo mismo que un flujo en el sentido de que tiene estados, comportamientos de entrada y comportamientos de evento. Sin embargo, un subflujo no tiene vida propia y solo se utiliza como un mecanismo de reutilización y, por lo tanto, DEBE estar contenido dentro de un flujo exterior. Al invocar un subflujo, su comportamiento es muy similar al de recibir un evento:

concepts 6

Lo clave que debe entender es que, en lugar de moverse a un estado y luego llamar a una acción como en el procesamiento normal mencionado anteriormente, aquí nos movemos a un pseudoestado que actúa como un punto de entrada al subflujo. El "control" del flujo se transfiere al subflujo; en este punto, procesará a través de las entradas y comportamientos de eventos hasta que alcance un estado terminal en el subflujo. Cuando alcanza un estado terminal, el control se devolverá al flujo que lo llamó con un resultado del nombre del estado terminal. Esto puede ser utilizado para un procesamiento posterior.

Tenga en cuenta que, para lograr la reutilización del subflujo en múltiples lugares, cuando un subflujo se coloca dentro de un flujo principal, su estado se mostrará como "<subflowid> <nombre del estado del subflujo>", donde <subflowid> es el nombre del estado pseudo del flujo que llama y <nombre del estado del subflujo> es el nombre del estado dentro del subflujo.

Flow Calls

Finalmente, también es posible llamar directamente a un flujo desde otro, a veces denominado "flujo a flujo". En este caso, el control se transfiere al flujo secundario, y esperamos un resultado que se devuelva. El flujo hijo puede informar que ha alcanzado cualquier estado de vuelta al flujo padre. Más comúnmente, esto ocurrirá cuando se alcance un estado terminal y el flujo hijo haya terminado el procesamiento, pero también permite la retroalimentación del flujo hijo para estados intermedios antes de que finalice. Esto proporciona una oportunidad para transferir el control de un lado a otro entre el flujo hijo y el flujo padre según sea necesario.

concepts 7

Completar un Flujo

El final o la finalización de un IPF flow es donde el flujo transiciona a un estado Terminal (consulte aquí para definir). En este punto:

  • Puede realizar un Acción de Notificación sobre la transición al estado Terminal

  • No se puede activar ningún comportamiento de entrada adicional. Events(& por lo tanto, no hay más State transición)

  • El flujo terminado será pasivado

  • Las entradas del diario del flujo terminado son elegibles para archivo.

Cuando un estado se define como Terminal, esto significa que no se prevén más transiciones de estado (no definirá ninguna transición adicional). Event El comportamiento más allá de ese estado y ninguna entrada en el flujo activa ningún comportamiento adicional). Este es el final del procesamiento de los flujos. Si usted tiene la intención de potencialmente transitar desde este estado, el estado no debe definirse como terminal.