Módulo de Órdenes Históricas

Para dar solución a la problemática de las órdenes históricas, se definió un nuevo flujo, el cual consiste en la migración (traspaso) de las órdenes antiguas del «entorno productivo», hacia un entorno réplica, que auspicia de archivador histórico.

En ese proceso de migración, a nivel orden ocurren las siguientes acciones, según el entorno:

Réplica (Archivador histórico):
- Se procede a la inserción (a nivel Base de Datos) de la orden y sus datos relacionados (Receiver, SenderAddress,..)
- Si la orden esta asociada a un Lote de Ordenes, se añade información de este (se pisará ante cada inserción)
- Ídem al anterior, pero en caso de Lote de Estados.
- Se insertan los datos del envío en el indice de shipping (Shipping Index).
Entorno Productivo:
- Se procede a la eliminación de la orden y sus datos relacionados.
- Si la orden esta asociada a un Lote de Ordenes, este se eliminará una vez que este vacio (osea sin ordenes, y en cuyo log solo figuren mensajes triviales)
- Ídem al anterior, pero con Lote de Estados
- Se elimina la información del envío de los índices de envíos (ShippingIndex) y de tramos (StepIndex).

Configuración de los entornos

Este nuevo flujo define una configuración adicional, definida en el parameters.yml, para ser llevada en ambos entornos (productivo e histórico). Además de incluir un nuevo tipo de usuario en el Sistema: SysUser.

Con respecto al Usuario, este es una representación del Sistema, y es creado de manera manual, al momento de deployar este módulo. Solo se requiere cambiar su contraseña, por una segura, dado que la default (tras inserción) es débil.

Por otro lado, con respecto a la configuración del parameters.yml:

     historical_data:
      hash_seed: 'SEED'
        allow_request: true
      url: 'http://iflow-historico.local/app_dev.php/api/'
      username: system
        password: PASSWORD

Donde:

Hash Seed (string): semilla involucrada en la generación del hash, que posibilita la incorporación de ordenes historicas. Este hash es compartido en la configuración de ambos entornos.
allow_request (boolean): indica si se permiten recibir peticiones/invocaciones de ordenes historicas, las cuales permiten almacenarlas. Por lo general, debe setearse:
- Entorno productivo: false
- Entorno histórico: true
url (string): URL absoluta del entorno histórico.
username y password (string): ambos datos correspondientes al usuario SysUser.

Componentes

Esta solución se apoya en distintos componentes con roles bien definidos. Los cuales se describen a continuación.

Comando

Se creo un comando, el cual busca una determinada cantidad de órdenes históricas, anteriores a una fecha dada, y las encola en if_historical_orders.

Dicho comando tiene la siguiente sintaxis:

app/console app1:historical_data:queue_orders AAAA-MM-DD limite -vv

Ejemplo de invocación:

app/console app1:historical_data:queue_orders 2018-06-01 1000 -vv

Consumer

Es el encargado de procesar una orden histórica encolada y realizar una petición a la API del entorno histórico, para su persistencia. Una vez que reciba una respuesta satisfactoria de ella, se encargará de la eliminación de dicha orden, del entorno productivo.

Sus dos grandes funciones son:

Encargarse del serializado de las operaciones de persistencia, que deberá ejecutar la API, en relación a la orden y todas sus entidades relacionadas (Envios, Traslados, Estados,..).
Eliminación completa de la orden, junto con sus entidades relacionadas, que cumplan el caracter de “eliminable”.

La sintaxis del consumer es la siguiente:

app/console swarrot:consume:historical_orders if_historical_orders -vv

API

Es la encargada de recibir y ejecutar las operaciones de persistencia de la orden histórica, provistas por el entorno productivo. Esta solo puede ser utilizada por un usuario del tipo SysUser, el cual fue creado en el entorno previamente, y responderá efectivamente a la consulta siempre y cuando haya sido configurado el entorno para ello (vía parameters.yml).

Ante la recepción de una orden ya existente, la API la acepta de todos modos, y sobreescribirá sus datos actualmente persistidos.

El endpoint definido para la API es el siguiente:

POST /api/v1/sys/create_historical_order/{tracking_id}/{hash}

Donde :

- tracking_id: es el seguimiento de la Orden histórica.

- hash: el resultado generado a partir del tracking_id y la semilla (hash_seed), configurado vía parameters.

El cuerpo de la petición tiene el siguiente esquema JSON:

{
    "sql":[
             "INSERT INTO ...",
             "INSERT INTO ....",
             ...
       ]
}

Aspectos técnicos de interés para desarrolladores

La solución descripta en este documento, se basa en la eliminación en cascada y en el tratamiento de los datos a migrar.

Para el primer caso, la eliminación en cascada, se le dan directivas explícitas a través de anotations de Doctrine.

Es importante tener la visión de que lo que se elimina es una Orden, con lo cual las directivas de que elementos se van a involucrar parten de ella y se dispersa esa misma orden recursivamente a través de las relaciones.

En cada relación, es posible indicarle al ORM, através del atributo cascade={all|persist|…} que hacer. Con un valor all, se propaga la eliminación a través de la relación, con un valor distinto a el, como persist, eso no ocurre.

Siguiendo este comportamiento, se ha configurado que elementos son eliminables del entorno productivo.

Por el otro lado, en cuanto a los datos a migrar, nos apoyamos en un utilitarios de MySQL, mysqldump, especializado en volcado de bases de datos, para indicarle que represente la instrucción de Insert (SQL) de un dato persistido basado en su Id (se incluyen todas las columnas).

Para realizar dicho proceso, navegamos todos los datos de interés a migrar y vamos acumulando los “inserts” requeridos para llevar a acabo la Migración completa.

Este puede observarse en el HistoricalService#processOrder(Order $order).

La información técnica provista en esta sección sirve para entender que implicancias conlleva añadir directivas para el tratamiento oportuno de nuevos atributos.