Módulo de Reencolado - Contingencia y acción Manual

Se describe la implementación del módulo de Reencolado, para dar brindar una estrategia de mitigación ante errores en al comunicación del Rabbit y/o posibilitar la acción manual por parte de un usuario en determinados flujos.

Se incluyen aspectos de interes desde la perspectiva del desarrollo.

Implementación

Estructura

 Se creó una estructura interna para representar las Colas de Rabbit y sus (posibles) mensajes.

 Donde Queue, representa la información de una cola existente de Rabbit. Su atributo name es el publisher declarado en app/config/swarrot.yml, y la descripción, es un texto breve representativo para los Usuarios del sistema («Notificar a VKM» p. ej.).

 Adicionalmente cuenta con 2 atributos, que guardan configuración de interés de

• allow_manual_insertion (Boolean): Este indica si dicha cola permite encolado por partes del Usuario

• classname (String): La clase de la entidad a la cual esta relacionada.

 Cada mensaje se guarda en la estructura, usando el valor de texto original que posea (básicamente JSON). Adicionalmente posee un atributo que indica si fue procesado (encolado satisfactoriamente) por el Sistema.

 Esta estructura es utilizada por ambas funcionalidades que se describen en las las secciones correspondientes.

Vale hacer una aclaración importante: El mapeo de Colas (Queues) se realiza mediante el DataFixture Queues (src/AppBundle/DataFixtures/ORM/Queues.php). Toda cola que no se encuentre mapeada en dicho archivo, no tendrá soporte en las funcionalidades descritas en este articulo.

Flujo de Contingencia

 El sistema esta preparado para que ante la imposibilidad de encolar un mensaje, indistintamente de su naturaleza (Rabbit caído, cortes de conexión,…) , persista el mensaje usando la estructura descripta anteriormente.

 Adicionalmente, es posible indicarle al Sistema que no intente encolar los mensajes sino que directamente los persista: de esta forma se le indicarle que evite iniciar comunicaciones con Rabbit, y que resulten fallidas de todas formas. Dicha configuración se encuentra en el parameters.yml:

    rabbit_active: boolean, #true encola directo, false: persiste

 Todos los mensajes persitidos, se almacenaran con el flag procesed en false, para que posteriormente puedan ser tratados por un comando a fin.

 Los mensajes y su estado se pueden visualizar desde el menú Configuración > Mensajes para encolar.

Comando de reencolado

 Todos los mensajes pendientes de encolar pueden ser encolados con el comando flqueue:messages:process .

 Su invocación sigue la siguiente sintaxis, cuyos sus parámetros son opcionales:

app/console flqueue:messages:process cola fecha_desde fecha_hasta

Un ejemplo de invocación seria:

app/console flqueue:messages:process 'shipping_registered_publisher' '2024-07-01 00:00:00' '2024-07-01 23:59:59' -vv --env=prod

Por ultimo se brindan algunas aclaraciones de interés:

•          Si no se ponen los parámetros, irá a buscar todos los elementos que requieren ser reencolados, luego los marca si pudo encolarlos, por lo que no estarán presentes en una posterior ejecución.

•          Los parámetros opcionales del comando pueden ser invocados en blanco, es decir ” (doble comilla simple), en el caso que se requiera completar un parámetro posterior.

•          Los nombres de las colas en realdiad son los “publicadores”, que la convención es el nombre del rabbit sin el if_ adelante y con publisher al final, por lo que la cola referenciada en el ejemplo sería “if___shipping_registered”. Esto es porque se guarda el dato que usa para encolar, pero se puede modificar si es necesario.

•          El parámetro hasta requiere que se haya definido el desde, pero el desde puede completarse solo (sin hasta).

Flujo de reencolamiento manual

 En los principales ABM del Backoffices se ofrece una acción, visualmente representada con un icono de “reproducir”, que abre un modal que permite seleccionar a cual de las colas se quiere enviar un elemento del listado.

 Este flujo se resuelve filtrando las Queues involucradas en el ABM, haciendo uso del atributo classname, comentado en la seccion de Estructura y no se tienen en cuanta las características del elemento para verificar si la cola destino es apropiada: dicha validación formará parte de la lógica de negocio invocada por el Consumer asociado a dicha cola.

 Por ultimo se definió una configuración en el parameters.yml, denominada manual_processing_mode, que posibilita alterar el comportamiento del Sistema al intentar reencolar un mensaje. Los valores posibles y su comportamientos son descriptos a continuación:

•          rabbit: al seleccionar una acción, la encola directamente.

•          db: En caso que se quisiera llevar un registro de las ejecuciones manuales, se puede definir que sea persistido y procesado junto a los mensajes provenientes del flujo de contingencia.

Un ejemplo de la configuración, sería así:

    manual_processing_mode: rabbit