Nuevo Flujo Urbano [v2.17]

Se describe las novedades de la versión 2.17 de iFlow, las características principales de las funcionalidades y las pruebas mínimas de rigor de funcionalidad y/o consideraciones para las mismas.

Entrega

Urbano: Nuevo Flujo

Descripción

Se solicito la implementación de una solución que favorezca a un nuevo flujo, gestionado externamente, por el cliente:

Este desarrollo implicó añadir nuevas funcionalidades las cuales se detallan en los siguientes apartados

Cola de Steps a notificar

Se creó una nueva cola llamada «carrier_step_to_notify». En ella se encola información de aquellos Steps que provengan del flujo de Hojas de Rujas (Viajes Despachados), cuando se cree uno o bien se actualice su información, y se detecte que no hayan sido notificados a su Operador asignado (flag notify=true).

Para llevar a cabo esto, además del enganche en el flujo de H.R., se implemento un flujo genérico en el CarrierService, en el cual se definió la lógica del encolado de Steps (serializado,…) y dado que hoy en dia este flujo se usa principalmente con Urbano, en su service se hizo la implementación concreta, dado que se debía incluir información de autenticación,etc..

Se brinda un ejemplo de la serialización de los mensajes encolados:

{"id": 2968717,"shipment_id": "UQA0000000074689","carrier":{"id": 61,"name": "Urbano","username": "urbano"},"step":{"id": 2504223,"route":{"id": 6217,"number": 456000020}},"authentication":{"shipper": "1112","password": "123456"},"length": 20,"height": 25,"width": 20,"weight": 1,"value": "100.00","receiver":{"name": "Gon","telephone": "0221 111-2233","email": "devel@softlight.com.ar","address":{"street_name": "Matata","street_number": "321","floor": "6","apartment": "B","zip_code": "1900","city": "La Plata","state": "BUENOS AIRES","latitude": "-34.93139800","longitude": "-57.94890000","other_info": "Otra info test"}}}

Nuevos Endpoints de System

Se han implementado 2 nuevos endpoints para ser utilizados por el usuario System:

• GET /api/sys/carrier/

  Lista los Operadores disponibles, retorna la información mínima de ellos como son su id, nombre, username, número de agencia y si se encuentra activa.

• POST /api/sys/step/id/notified

  Permite marcar al Step como notificado.
  Se reciben la fecha de notificación y un parámetro de carrier_id para validar que el Step este asociado al Operador (y no se actualice por error).

Los detalles de los mismos junto a sus ejemplos de invocación y respuestas, se encuentra en la Documentación de la API (repositorio).

Adaptación en el Endpoint de Aviso de estados de Carrier

Se adapto el actual endpoint (POST /api/v1/carrier/step_state) para que realice el chequeo que actualmente se hace en el flujo de UrbanoService: verificar que el estado no exista, para lo cual analiza los StateInfo en búsqueda de equivalente existente.

Por lo tanto, al endpoint, se le añade un parámetro booleano opcional llamado check_state_info, el cual realiza esa verificación mencionada anteriormente.

El detalle de este endpoint se encuentra en la Documentación de la API (repositorio).

Pruebas básicas del flujo

• Probar la cola y su serializado al ejecutar el flujo de H.R a partir de mocks creados para tal fin, y procesados posteriormente con el consumer (id=61, Urbano):
  $ app/console app1:api:routes:vkm:get execute —id 61 -vv
• Probar los 2 endpoints de System. Para el caso de Notificación de Steps, se deberá chequear via BD (dado que no se muestra actualmente en ningún lado esa información) que el flag notify=false.
• Pegarle el mismo request a la API de Carrier, al intentar N veces enviar el mismo estado con y sin el flag de chequeo (de StateInfos).

Front de Tracking: Filtro de comprador en Envios

Descripción

Se añadió un filtro de Comprador y/o de que quien recibe (tercera Persona) en la pantalla principal de Envios del Front de Client. La búsqueda se realiza de manera parcial (like %) a partir de los atributos apellido y nombre del Comprador, o bien de la persona que se haya defindo que es responsable de recibir el envio.

Se optó por no añadir una columna con dicho campo en la pantalla principal, por una cuestión de “espacio”.

A nivel endpoint de la API, llega el parámetro filter[client], el cual representa esta búsqueda. Vale aclarar que esto fue igualmente especificado en la Documentación de la API (repositorio) correspondiente a esta versión.

Pruebas básicas del flujo

• Utilización del filtro desde el Front de Client. Opcionalmente podrá realizarse via PostMan.

Gráfico Tratado en reunión actualizado