Estados de Orden - Reconstrucción histórica y gestión ante cambios

Se describe la funcionalidad asíncrona del cálculo de construcción histórica del Estado de una Orden, contemplando cambios en los avisos de estado en algunos de sus envíos.

Implementación

 En la entidad Order, se añadió el atributo orderStateProcessRequired, de tipo entero.

 Este atributo sirve para marcar a la orden ante cambios sufridos en algunos de sus envíos, puntualmente por alguna actualización (creación, eliminación y modificación) de algún aviso de estado.

 Los valores que puede adoptar ese atributo son:

• 0 -> No ha sufrido cambios.

• 1 -> Sufrió un cambio, dado una creación / actualización de un Aviso de Estado (StepState).

• 2 -> Sufrió un cambio,dado una eliminación de un aviso de Estado.

Ante operaciones, manuales o por sistema, ocurridas en el flujo de Aviso de Estados, se marcará la orden según el caso. Posteriormente el command app:order:process_state_change (OrderStateChangeProcessCommand), se encargará de buscarlas, y encolar en order_state_process, tipificando el evento originador (actualización o eliminación).

 El consumer swarrot:consume:order_state_process (OrderStateProcessConsumer) asociado a dicha cola, se encargará de ejecutar un algoritmo para llevar a cabo la «reconstrucción histórica». El mismo se basa en 2 parámetros:

1. El historial de avisos de estados asociados a la Orden.

2. El escenario (actualización o eliminación).

 Con dichos parámetros se procede a describir, abstractamente, el procedimiento:

1. Se construye una estructura (arreglo) de reglas involucradas a tratar, dependiendo del escenario:

   1. Actualización: se filtran aquellas reglas que ya hayan sido aplicadas previamente, tomando los ids de los estados por los cuales la orden ya pasó.

   2. Eliminación: Se buscan las reglas activas (vigentes).

2. Por cada regla de la estructura, se intentará enriquecer con la información de los StepStates: se determina una fecha de inicio, a partir de la menor del conjunto, y una fecha en la que se cumplió, tomada del primero de ellos (StepStates) que logró satisfacerla.
   Adicionalmente se consideran aquellas reglas que no se cumplieron, pero que serían candidatas de serlo, dado que parcialmente se cumple: dicho de otra forma, no se llega a satisfacer al porcentaje (minimo) objetivo definido en la configuración de reglas.

3. Se evaluaran las reglas candidatas:

   1. Actualización: Se añadiran al historial las reglas cumplidas.

   2. Eliminación: Se contrastarán las reglas cumplidas, calculadas en la estructura, con el historial vigente (persistidas). La diferencia entre ambos “conjuntos” determinaran eliminaciones del historial.

4. Se hacen los acomodos cronológicos mas finos: Se construye la vigencia (fecha desde) de cada una de las reglas que se consideran cumplidas (OrderStateHistory), y se añadé como estado de Orden actual a la mas reciente.

5.   Solo si el servicio indica que hubo cambios en el historial, se procede a actualizar de manera óptima el ShippingIndex, para todos los envíos de esa orden. Entrando en detalle, para los registros de los envios, solo se actualizaran los campos relacionados a los estados de orden, y no todos los restantes con el costo que eso conlleva.

6. Se evalúa si hubo reglas parcialmente cumplidas, y en caso de detectarse se fuerza al re-encolado del mensaje en la cola principal (order_state_process). Esto se logra al lanzar una Excepción (simbólica) para que fuerce el encolado en la colas de retry -> ejecución posterior.
   Vale aclarar que ante la ejecución del re-encolado, no se ve afectada la persistencia de los datos determinados en los pasos previos.

  Resta aclarar que la solución, no afectó al flujo existente de notificaciones, con lo cual todos los OrderStateHistory creados serán notificados.