Gestión de Entradas de Estados

¿Como ingresan los estados?

En IFLOW el seguimiento de un Shipping involucra Steps y StepStates. Los Steps son tramos o pasos que fue atravesando el envío. Por ejemplo, un tramo para la Colecta, un tramo para el Reparto o alguno de ellos por separado. Los StepState son los estados que se incorporan a esos Step a medida que los recibimos de alguna de las 3 fuentes posibles de actualizacion:

Inserción manual
Procesamiento de StateInfo (pickeados por Unigis o creados a partir del consumo de otros Carriers, como por ejemplo URBANO)
Consumo del service de VKM TMS

Inserción manual

Desde el backend de IFLOW, si vamos al detalle de tracking de un envío, es posible crear nuevos estados para los Step que tiene actualmente. Esta funcionalidad es atrapada por el controller StepStateController y derivada al StateService.

Procesamiento de StateInfo

A traves del comando ProcessStateInfosCommand podemos ejecutar el procesamiento de todos los StateInfo que se encuentren en estado REGISTRADO. A partir de ellos, si corresponde, se crearan StepState. Esta funcionalidad se deriva al StateInfoService

Consumo del service de VKM TMS

A traves del comando ProcessTrackingStatesCommand podemos conectarnos al WebService que ofrece VKM TMS y obtener la actividad que hubo entre dos fechas. Este procesamiento es atendido por el service StateService.

ShippingService

Se han desacoplado todos los métodos relacionados con manejo de State, StateInfo y procesamiento de “documentos”, obtenidos del Tracking. Incluso la funcion newStep (que podría considerarse parte de la creación de un Shipping) fue movida al StateService.

StateInfoService

Posee la lógica para generar StateInfo (ya sea por API o desde los Service de Carrier como por ej, urbano), y procesarlos. Deriva al StateService la creación de StepState.

StateService

Tiene la lógica para crear los StepState. Al crear un StepState se obtiene el Step correspondiente a partir del modo de ese State que se quiere insertar. Por ejemplo: Registrado es de modo Colecta, entonces se recupera el Step de Colecta (se asume que habrá uno solo por Shipping).

Cada State puede configurarse por BD para definir si puede repetirse o no, dentro de un Shipping, y, de poder repetirse, cual es el intervalo en el que se considera que ese estado es duplicado.

Por ejemplo, un State de “Recibido en CD” puede repetirse, porque un Shipping puede pasar por varios CD. Ahora bien, asumimos que si ese State viene 2 veces en un intervalo de X segundos, se trata de la misma notificacion, que ha sido duplicada. En esos casos las ignoramos.

Es por eso que la entidad State tiene una propiedad llamada duplicate_range que nos indica los segundos durante los cuales tomaremos ese estado como duplicado.

Si duplicate_range es -1, ese State no admite duplicados. Por ejemplo

Registrado el 2018-06-13 12:00:00

Registrado el 2018-06-01 23:00:00 ← es duplicado, ya vino ese estado, no importa el date

Si es 0, se chequea exactamente el mismo segundo. Por ejemplo:

Registrado el 2018-06-13 12:00:00

Registrado el 2018-06-13 12:00:01 ←NO es duplicado

Registrado el 2018-06-13 12:00:00 ←es duplicado, ya vino ese estado en ese instante

Si es >0, se chequea dentro de ese rango de segundos. Por ejemplo, si es 10:

Registrado el 2018-06-13 12:00:00

Registrado el 2018-06-13 12:00:01 ←es duplicado (diferencia +1)

Registrado el 2018-06-13 11:59:53 ←es duplicado (diferencia -7)

Registrado el 2018-06-13 12:00:13 ←NO es duplicado (diferencia +13)

Por otro lado, la entidad State tiene una propiedad final que indica si ese State es final dentro de la secuencia de estados.

A) Si un Shipping se encuentra en un estado final y llega otro estado, se procede de la siguiente manera:

Si el nuevo estado es también final, se inserta normalmente
Si el nuevo estado NO es final, se modifica su fecha para que quede 1 segundo inmediatamente antes del último estado. De este modo no alteramos la consistencia si hubiera un desorden en el parseo de los States. Esto intenta corregir la situación de Shippings que habían sido Entregados y luego llegaba un estado “En distribución” o similares, alterando el estado actual de ese Shipping.

B) Si el Shipping se encuentra en un estado NO FINAL y llega un final que tiene fecha anterior al NO FINAL, lo que hacemos es modificar el final para que su fecha caiga 1 segundo después del NO FINAL y quede último. Esto corrige posibles “desordenes” del procesamiento.

Configuracion de State

Para flexibilizar el funcionamiento del flujo de State, se agregaron atributos para poder elegir el accionar de cada instancia. Para acceder a estas configuraciones se puede ingresar en el menu Configuración > Estados.

Mode

indica si se trata de un State que irá insertado en un Step de Colecta o de Reparto

Nombre de entrada

indica el nombre con el que se puede recibir desde StateInfo. Por ejemplo “entregado” se mapeará con el objeto State “Entregado”. Este texto debe estar en minúsculas y sin acentos.

Notificación por email

indica si el estado envía notificación por email ante un cambio (StateInfo)

Final

indica si el estado es final

Crea estado en tracking

indica si se creara un State dentro del Step que corresponda para ese envío

Notifica a VKM

indica si debe enviar la comunicación a VKM de este procesamiento

NOTA: los estados Registrado, Guardado, Valido, Invalido, Error, Omitido son de StateInfo, no deberíamos cambiar su configuración dado que son de uso interno del sistema.

Estados sin hora

URBANO nos manda notificaciones de State sin horas, solo día. Esto provoca que se inserten todos con hora 00:00:00. Por ejemplo, en un dia nos mandan el siguiente flujo:

1/7 Pedido ingresado

1/7 Pedido en distribucion

1/7 Entregado

Eso hace que nosotros despues tengamos 3 estados al mismo tiempo, si le ponemos la hora 00:00:00. Lo que hicimos en su momento fue concatenarles a esos estados la hora a la que se estaban procesando. De esa manera todos tenian horas distintas. Ahora bien, supongamos el siguiente procesamiento:

El dia 1/7 recibimos y procesamos, a las 22hs:

1/7 Pedido ingresado

1/7 En distribucion

Los procesamos a ultima hora e insertamos

1/7 22:00:00 Pedido ingresado

1/7 22:00:10 En distribucion

Cambia el día, y el 2/7 a las 3AM recibimos, en otra corrida del procesamiento, una notificacion que habia quedado colgada (no llego en su momento, no la mandaron, se perdio, X motivo)

1/7 Entregado

Como estamos procesando a las 3AM vamos a insertar

1/7 03:00:00 Entregado

Si juntamos las 3 inserciones veremos que va a quedar

1/7 03:00:00 Entregado

1/7 22:00:00 Pedido ingresado

1/7 22:00:10 En distribucion

Por lo tanto, lo que hacemos es: si el día del estado (1/7) es distinto al dia del procesamiento (2/7), en lugar de ponerle hora actual, le ponemos 23:59:59. Para que se inserte con la ultima hora de ese dia. En nuestro ejemplo quedaría:

1/7 22:00:00 Pedido ingresado

1/7 22:00:10 En distribucion

1/7 23:59:59 Entregado