Closed

Backend/webservice para app Android - 84245

Hola,

estamos buscando una persona que pueda desarrollar el backend del proyecto que exponemos a continuación. La parte app (recepción de notificaciones push) está ya desarrollada o en desarrollo pero necesitamos a una persona que implemente el lado servidor y el tracking/informes, etc.

Agradeceríamos si nos pudiera pasar un quote en cuanto a presupuesto económico y de tiempos. Muchas gracias.

El proyecto:

Actualmente, el cliente posee una aplicación de notificación a técnico basada en el envío de SMS. A grosso modo, el proceso completo actual se divide en los siguientes pasos:

1. Se genera un mail automático a un buzón de correo ([eliminado]).

2. La plataforma transforma ese mail en un SMS (usando el MSISDN) adjuntando una URL. En esa URL, hay información añadida de la orden de trabajo.

3. El técnico de campo, vía esa URL acepta o cancela la orden de trabajo:

? En caso de cancelar, se notifica a Call Center (TeleSecretaria) para iniciar el flujo de envío a otro técnico de campo.

? En caso de aceptar, se finaliza el flujo.

El flujo actual presenta problemas inherentes al SMS:

? Longitud superior a la permitida implica generar más de un SMS que podrían llegar al destinatario de forma desordenada.

? Cobertura GSM puede provocar que el SMS no llegue en tiempo y forma al destinatario, perdiendo, por tanto, tiempo valioso en la ejecución de la orden de trabajo.

Por ello, se plantea evolucionar el flujo de notificación a una plataforma multicanal que utilice las nuevas tecnologías ampliando las formas en las que un técnico puede llegar a ser notificado. En concreto, se plantea el desarrollo de una App instalada en el móvil del técnico, la cual servirá de receptor de notificaciones. Las ventajas principales de disponer un App móvil son:

? La cobertura de datos se ve ampliada gracias a recursos WIFI tanto de locales públicos como privados.

? Existe un mayor control en la notificación al terminal pudiendo conocer si el destinatario recibió la notificación así como si abrió la aplicación para leerla (“equivalente al doble check de WhatsApp”). En consecuencia, esto permite tomar otro tipo de decisiones.

Se define la siguiente operativa de notificación a técnico de campo, operativa susceptible de ser modificada o ampliada. En primera fase, sólo interesa conocer si el técnico de campo cancela o acepta, dejando sólo para fines estadísticos y de tracking eventos asociados a “cuándo el técnico recibe la notificación” y “cuándo abre la aplicación para, supuestamente, leer el mensaje”:

1. Se sigue manteniendo el flujo de recepción de mails como evento desencadenante de la notificación al técnico de campo.

2. Se realizará una primera notificación al técnico de campo vía App Móvil. Al técnico, le aparecerá una pantalla equivalente a la mostrada en la URL adjunta al SMS.

a. En caso de aceptar, se finalizará el flujo.

b. En caso de cancelar, se notificará a a TeleSecretaria, vía eMail, para que inicie un nuevo flujo con otro técnico de campo.

3. Si pasados 15min., no hay notificación por parte del técnico de campo, se enviará una segunda notificación vía App. De forma equivalente, el técnico cancelará o aceptará.

4. Si pasados 15min.:

a. Hay notificación de entrega en terminal, directamente se notificará a TeleSecretaria, vía eMail, para que inicie un nuevo flujo con otro técnico de campo.

b. No hay notificación de entrega (y en consecuencia, ni aceptación/cancelación) parte del técnico de campo, se notificará al técnico de campo vía SMS, de forma equivalente al proceso actual, siendo el técnico el que acepte/cancele vía URL.

5. Si pasados 5min., no hay notificación por parte del técnico de campo, se notificará a TeleSecretaria, vía eMail, para que inicie un nuevo flujo con otro técnico de campo.

COBERTURA TERMINAL MOVIL

Es importante tener controlado las posibles indisponibilidades del técnico de campo, lo cual podría provocar que fuera notificado más de una vez por los distintos canales, una vez que el técnico de campo volviera a zona de cobertura. Así pues, es necesario definir un conjunto de estados que permita obrar, en consecuencia. Se definen, por tanto, las siguientes acciones en caso que un técnico de campo recibiera más de una notificación de la misma orden de trabajo:

Cada vez que se envíe una n-sima notificación, se debe enviar una notificación equivalente, en los canales que sea posible, anulando la notificación anterior. Así, por ejemplo, en el primer proceso definido, si se enviara un SMS al terminal móvil, debería enviarse, de forma equivalente, una notificación a la App que anulase las duplicidades generadas por las dos primeras notificaciones.

? En caso que no fuera posible eliminar esas duplicidades (por ejemplo, envío de SMS), sólo quedaría controlar a nivel formulario (aceptar/cancelar) que ya se realizó una actuación previa, bien porque el técnico canceló/aceptó en otra notificación, bien porque se envió un eMail a TeleSecretaria y en consecuencia, esa orden de trabajo ya no le pertenece al técnico de campo.

TRACKING E INFORMES

Debe existir un tracking completo de una determinada orden de trabajo. A modo de log, debe almacenarse para su posterior análisis:

? Cuándo se recibe el mail.

? Cuándo se realizan las distintas notificaciones a la aplicación móvil.

? Cuándo esas notificaciones llegan al terminal móvil (doble check de WhatsApp).

? Cuándo el técnico abre la aplicación para “leer la notificación” (doble check azul de WhatsApp).

? Cuándo se realiza el envío del SMS al terminal móvil.

? Cuándo el carrier de telefonía móvil envía el último evento SMS (“Ready for delivery”, “Cancel”, etc…).

? Cuándo el técnico de campo accede a la URL de acceso.

? Cuándo el técnico de campo Acepta/Cancela tanto vía App como vía URL.

? Cuándo se notifica a TeleSecretaria.

Existirá un informe web al que podrá acceder cualquier persona que tenga permisos de acceso para visualizar el estado de cada una de las órdenes de trabajo. Ese informe contendrá la siguiente información:

? Fecha/Hora de la recepción del mail.

? Técnico (MSISDN).

? Texto. Contenido del mail que se envía tanto a la App como al SMS como a la URL de acceso.

? Estado. Notificado, Aceptado, Cancelado…

Medio. Indicará el medio que se ha usado en la última notificación (App/SMS).

? Link al tracking de la orden de trabajo.

REGISTRO DE USUARIO

Por políticas de seguridad, no parece factible capturar información del MSISDN que tiene el móvil del técnico de campo. Esto obliga a desarrollar, en el peor de los casos, una política de registro en la que el técnico de campo deberá introducir su nº de teléfono móvil como identificativo unívoco de técnico al cuál se le realizarán las notificaciones.

ARQUITECTURA

Se define la siguiente arquitectura de sistemas:

? Para la recepción y envío de mails, se utilizará SendGrid como proveedor:

o Vía API WebHook utilizando nodeJS, se recepcionarán los mail.

o Vía API SendGrid (SMTP client o HTTP client o SendMail), se enviará el mail correspondiente a Telesecretaria.

? Sistema intermedio de colas Beanstalkd como buffer para procesar las distintas notificaciones.

? Worker realizado en PHP para procesar las distintas órdenes de trabajo, toma de decisiones sobre qué canal usar para la notificación, enviar las distintas notificaciones, tracking de eventos, etc..

? Sistema PUSH de notificación a App Móvil. Se plantea tanto la posibilidad de utilizar plataformas existentes (Google GCM o Amazon ADM o Pushy; en caso de coste, será necesario evaluar viabilidad económica) como desarrollo propio; en cuyo caso, se utilizará nodeJS.

? La sección de informes debe estar integrada en la plataforma VC360, desarrollada en Zend Framework, como un módulo más dentro de la suite.

Skills: Codeigniter, Interspire, Javascript, Mailchimp, PHP

See more:

About the Employer:
( 0 reviews ) Spain

Project ID: #12398287