CommuniCenter, una aplicación web para gestionar las comunicaciones de empresas con sus clientes

Título en español: CommuniCenter, una aplicación web para gestionar las comunicaciones de empresas con sus clientes Title in English: CommuniCenter, a web application to manage company communications with their clients Trabajo de Fin de Grado Curso 2023–2024 Autor Adrián Estévez Gallego Director Ramón González de Campo Rodríguez Barbero Grado en Ingeniería Informática Facultad de Informática Universidad Complutense de Madrid Título en español: CommuniCenter, una aplicación web para gestionar las comunicaciones de empresas con sus clientes Title in English: CommuniCenter, a web application to manage company communications with their clients Trabajo de Fin de Grado en Ingeniería Informática Autor Adrián Estévez Gallego Director Ramón González de Campo Rodríguez Barbero Convocatoria: Septiembre 2024 Grado en Ingeniería Informática Facultad de Informática Universidad Complutense de Madrid 7 de septiembre de 2024 Resumen Título en español: CommuniCenter, una aplicación web para gestionar las comunicaciones de empresas con sus clientes Este trabajo consiste en la implementación de una aplicación para poder gestionar las comunicaciones entre empresas y sus clientes de manera centralizada. En vez de tener una empresa un teléfono distinto por cada empleado de atención al cliente, aquí cada organización tiene un único teléfono desde el cual todos sus empleados pueden gestionar todas las conversaciones que tienen con sus clientes. La comunicación se realiza a través de la API de Whatsapp Business, ya que Whatsapp es la manera más cómoda para los clientes de comunicarse. Podremos en nuestra aplicación ver distintos formatos de mensaje de los clientes como texto, fotos, audio, documentos, vídeo y localizaciones. Y los empleados podrán enviar desde la aplicación los mismos mensajes a excepción de audios y localizaciones. Los chats también tendrán cada uno un estado asociado para saber de manera rápida el estado en el que se encuentra la conversación. Además cada chat incluye una sección de notas para que los usuarios puedan anotar datos relevantes de dicha conversación que puedan ser necesarios en el futuro. Existen tres tipos de usuarios de nuestra aplicación: Usuarios estándar El único uso que puede hacer de la aplicación será todo lo relacionado con los chats. Como son enviar y recibir mensajes, añadir notas a los chats y cambiar el estado del chat. También podrá modificar sus datos de usuario. Mánager Este usuario gestionará su propia organización. Podrá crear y eliminar usuarios y cambiar los datos de su propia organización. Administrador Los administradores podrán crear organizaciones y editarlas. Además podrá gestionar todos los usuarios del sistema. v Palabras clave Chat, Whatsapp, aplicación web, webhook, websocket, mensajes, organizaciones, Flask, Vue Abstract Title in English: CommuniCenter, a web application to manage company communications with their clients This work consists of implementing an application to manage communications between companies and their clients in a centralized manner. Instead of each customer service employee having a separate phone number, here each organization has a single phone number from which all employees can manage all conversations with their clients. Communication is made through the WhatsApp Business API, as WhatsApp is the most convenient way for clients to communicate. In our application, we can view different message formats from clients such as text, photos, audio, documents, video, and locations. Employees will be able to send the same types of messages from the application, except for audio and locations. Each chat will also have an associated status to quickly identify the current state of the conversation. Additionally, each chat includes a notes section where users can store relevant data from the conversation that may be needed in the future. There are three types of users in our application: Standard Users The only use they can make of the application is related to chats. This includes sending and receiving messages, adding notes to chats, and changing the chat status. They can also modify their user data. Manager This user manages their own organization. They can create and delete users and change their organization’s data. Administrator Administrators can create and edit organizations. Additionally, they can manage all users in the system. vii Keywords Chat, WhatsApp, web application, webhook, websocket, messages, organizations, Flask, Vue Índice 1. Introducción 1 1.1. Motivación................................. 1 1.2. Objetivos ................................. 2 1.3. Alcancedelproyecto ........................... 2 1.3.1. Funcionalidades incluidas . . . . . . . . . . . . . . . . . . . . . 2 1.3.2. Funcionalidades excluidas . . . . . . . . . . . . . . . . . . . . 3 Introduction 5 1.1. Motivation................................. 5 1.2. Objectives................................. 6 1.3. ProjectScope............................... 6 1.3.1. Included Features . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.2. Excluded Features . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Estado del Arte 9 2.1. Comunicación entre empresas y clientes . . . . . . . . . . . . . . . . . 9 2.1.1. Precedentes ............................ 9 2.1.2. Whatsapp............................. 10 2.2. APIdeWhatsapp............................. 11 2.2.1. Características principales . . . . . . . . . . . . . . . . . . . . 11 2.2.2. Limitaciones............................ 12 2.3. Análisis de la competencia . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.1. Aplicaciones similares . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.2. Wati................................ 13 2.3.3. Callbell .............................. 14 3. Fundamentos Teóricos y Tecnológicos 17 3.1. Tecnologías utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.1. Backend.............................. 17 3.1.2. SQL ................................ 18 3.1.3. Frontend.............................. 19 3.1.4. Tecnologías generales . . . . . . . . . . . . . . . . . . . . . . . 20 ix Introduction Figure 1.2: Communicenter logo 1.1. Motivation Customer service is a fundamental part of making a good impression on your company’s clients. Ensuring that the communication is comfortable for the customer highly helps making that good impression. Many companies rely on email for their communications. In many cases, this is not the best communication channel as it tends to be very formal. Messaging apps make customer service feel much more personal and informal, allowing for closer interactions with your clients and achieving a higher level of satisfaction. With the arrival of WhatsApp Business and later with the introduction of its API, a significant step forward has been taken. Customers can communicate with companies through the messaging app they use daily instead of using a specific application for each company. The use of the WhatsApp API means that there is no need to have a separate phone for each employee; instead of that, all conversations between the company and its customers can be centralized using a single phone number. The problem is that many companies do not have the resources or the time to implement their own application that integrates the WhatsApp API. 5 6Capítulo 1. Introducción 1.2. Objectives In this project, I implement a web application that allows different companies to use the WhatsApp API to manage communication with their clients. Each organization can add users to the application, and these users can use the chat functionality to communicate with their clients. Additionally, the chat will have some extra features such as a status system to get an overview of the conversation status at a glance, as well as a note system to save relevant information about each conversation. To complete the project and achieve the general objectives of the application, I have created more specific goals: Deeply understand the WhatsApp API, including its different endpoints and their responses. Implement a Webhook that can capture events such as incoming messages or updates of them. Analyze what extra features can be added to a chat to provide additional value that other messaging apps do not have. Implement various modules such as the management of organizations and users, as well as a chat functionality for the application. Use WebSockets to communicate the server with the views through events, without requiring the front-end to call a server endpoint. 1.3. Project Scope In this section, I describe the main features that have been included in the application, as well as other features that have been excluded. 1.3.1. Included Features Organization management module. Administrators can create new organizations, which will have their own WhatsApp API credentials. User management module. Administrators and managers can create new users through the application. Existing users can be edited or deleted. Implementation of the WhatsApp API to send and receive messages, as well as receive message status updates. Implementation of the application’s chat to allow users to manage their company’s conversations. Chat notes section that allows for better tracking of conversations that extend over a long period of time. 1.3. Project Scope 7 The application has been designed to be used comfortably on computers or devices with horizontal screens. 1.3.2. Excluded Features The WhatsApp Business API for managing message templates has not been implemented. The application has not been designed to be supported on mobile devices. Many views are not adapted for comfortable use on vertical screens. Users cannot send interactive messages, such as messages with buttons, through the application. The application has not been launched to production. The main issue is that in production, each message sent through the WhatsApp API incurs a monetary charge. Cap´ ıtulo 2 Estado del Arte En este capítulo explico cómo han funcionado las comunicaciones empresariales con clientes a lo largo de la historia. Cómo Whatsapp se esta haciendo un hueco, el cual es cada vez mas grande con la liberación de su API al público. También describiré las características de que tiene dicha API, con sus puntos fuertes y limitaciones. Por último, hablaré de las implementaciones actuales que se están realizando de ella. 2.1. Comunicación entre empresas y clientes La comunicación entre empresas y clientes ha sido una piedra angular en el desarrollo de relaciones comerciales y la satisfacción del cliente. Desde la antigüedad las empresas adoptado diferentes medios para comunicarse. Muchas de ellas se siguen utilizando hoy en día y tienen una gran popularidad, mientas otras fueron desplazadas por nuevas tecnologías más eficientes. A continuación, se presentan los principales métodos de comunicación utilizados a lo largo de la historia y su evolución hasta la era digital actual. 2.1.1. Precedentes 1. Correo físico: El correo físico lleva usándose desde la antigüedad para la comunicarnos. A partir del siglo XIX empezaron a crearse servicios postales nacionales, generalizando su uso. A nivel empresarial se ha utilizado hasta nuestros días para enviar cartas formales, contratos y facturas. Los clientes también, aunque en menor medida, pueden enviar quejas o dudas a empresas por este medio. 2. Telégrafo: Desde mediados del siglo XIX hasta inicios del XX, el telégrafo permitió a las empresas enviar mensajes breves y urgentes a largas distancias. La limitación en solo poder trasmitir texto y sus altos provocaron que con la aparición del teléfono desapareciera rápidamente. 3. Teléfono: Inventado en 1876, fué rápidamente adoptado por empresas para realizar sus 9 10 Capítulo 2. Estado del Arte comunicaciones. Se generalizó su uso a partir de la décadade 1920 y 1930, cuando empezaron a hacerse comunes en los hogares. El ser una comunicación hablada e instantánea permite que esta sea mucho más cercana, haciendo que el cliente se sienta más cómodo y escuchado. Las empresas pudieron establecer líneas de atención al cliente, donde los operadores podían resolver dudas, gestionar pedidos y recibir quejas en tiempo real. 4. Fax: El fax ganó popularidad en la década de 1970. Permitía enviar copias exactas de documentos a través de líneas telefónicas, lo que resultaba en una transmisión rápida y confiable de información escrita. Las empresas adoptaron rápidamente el fax para enviar contratos, facturas, órdenes de compra y otros documentos oficiales. 5. Correo electrónico: El correo electrónico (email) revolucionó la comunicación empresarial a finales del siglo XX. Los primeros sistemas de correo electrónico aparecieron en la década de 1960, pero no se popularizó hasta la expansión de Internet sobre 1990 y la aparición de servicios de correo electrónico accesibles y gratuitos. El email permite a las empresas enviar mensajes instantáneos y con la capacidad de adjuntar archivos, lo que facilita enormemente la transmisión de documentos y la comunicación escrita. 6. Foros: Los foros, al igual que el email, se popularizaron con la expansión de internet en la década de 1990. Permitían a los usuarios publicar preguntas, compartir información y discutir temas de interés común. Aunque hoy en día no son muy populares, se siguen utilizando en sectores donde la comunidad y el intercambio de información detallada son importantes. 7. Redes sociales: Antes de la llegada de WhatsApp a la empresarial, las redes sociales ya transformaron significativamente la forma en que las empresas interactuaban con sus clientes. Desde mediados de la década de 2000 y sobre todo la de 2010 se convirtieron en herramientas esenciales para la comunicación empresarial. Estas plataformas permitieron a las empresas no solo gestionar la atención al cliente de manera más efectiva y personal, sino también construir comunidades y realizar campañas de marketing más efectivas. 2.1.2. Whatsapp Whatsapp apareció en el año 2009. En pocos años se convirtió en la plataforma de comunicación más popular en gran parte del mundo; actualmente tiene miles de millones de usuarios que la usan en su vida cotidiana. Ya años antes de la liberación de su API, numerosas empresas ya utilizaban Whatsapp como su medio de atención al cliente, debido a que esta presenta numerosas ventajas sobre otras redes sociales: 2.2. API de Whatsapp 11 Permite la comunicación directa y en tiempo real. Aunque otras aplicaciones como Facebook o X también permiten mensajería instantánea, esta está relegada a ser una función secundaria; por lo cual gran parte de los usuarios no le presta atención. La frecuencia con la que los usuarios revisan sus mensajes. Mientras que muchas personas abren las redes sociales unas pocas veces al día, la mayoría de los usuarios de WhatsApp están pendientes de sus mensajes constantemente. Whatsapp proporciona un entorno de comunicación más personal y privado. Los clientes pueden sentirse más cómodos haciendo consultas detalladas y recibiendo atención personalizada. Permite enviar una gran variedad de contenido multimedia, como imágenes, vídeos, notas de voz, ubicaciones, etc. También incluye llamadas de voz y vídeo, que puede ser de ayuda para resolver ciertos problemas de forma efectiva. 2.2. API de Whatsapp La API de Whatsapp fue inicialmente lanzada en agosto de 2018. En un inicio estuvo disponible de forma limitada, teniendo solo acceso a ella un número reducido de grandes empresas por medio de invitación. En junio de 2021 WhatsApp facilitó en gran medida el acceso a la API, permitiendo que más empresas pudieran acceder a ella y beneficiarse de sus funcionalidades. 2.2.1. Características principales Enviar mensajes: La función principal de la API. Permite enviar mensajes en una gran variedad de formatos (texto, imágen, vídeo, interactivos...) Recibir mensajes: También serás capaz de recibir mensajes a tu servidor mediante la configuración de un Webhook. Un Webhook es un agente que es capaz de escuchar eventos y enviárselos a nuestra aplicación. En este caso, es capaz de captar los mensajes que son enviados a nuestro número de teléfono y enviarlos al servidor para ser procesados. Confirmaciónes de lectura: El cliente recibirá automáticamente la confirmación de que hemos recibido su mensaje. Para poder confirmar la lectura de dicho mensaje desde una aplicación externa debes invocar una función en la API. Esta función sólo es capaz de confirmar la lectura de mensajes individuales, no existe la posibilidad de confirmar todos los mensajes de un chat en una llamada. Si quieres confirmar todos los mensajes anteriores deberás hacerlo uno a uno. Recibir actualizaciones de mensajes: Para cada mensaje del cliente, recibirás un evento (que puedes capturar en 12 Capítulo 2. Estado del Arte el Webhook) para cada actualización del mensaje que enviaste. Estos estados son enviado, recibido, leído y error. Crear plantillas de mensajes: En muchas ocasiones, una empresa enviará mensajes cuya estructura es muy parecida a diferentes clientes. La API permite crear plantillas de mensaje, las cuales tienen la misma estructura que un mensaje normal, con la adición de poder añadirle variables. Las variables permiten personalizar partes específicas del mensaje, como el nombre del cliente, el número de pedido, la fecha de la cita, entre otros. Antes de poderse utilizar, las plantillas deben ser revisadas y aprobadas por Meta. 2.2.2. Limitaciones Limitación temporal: Después de recibir un mensaje por parte del cliente, tienes una limitación temporal de veinticuatro horas en las que se le puede enviar mensajes de vuelta. Los únicos mensajes que no están atados a esta limitación temporal son los mensajes de plantilla. Esta limitación existe para evitar el spam. Si la empresa necesita continuar la conversación después de este período, debe esperar a que el cliente envíe un nuevo mensaje o utilizar mensajes de plantilla. Formatos de mensaje no soportados: La API recibe acutalizaciones regulares, soportando cada vez más formatos de mensaje. Sin embargo, aún hay ciertos formatos que no es capaz de procesar. Estos son las encuestas (y las repuestas a las mismas), la ubicación en tiempo real y las llamadas de voz o vídeo. Grupos: Actualmente la API sólo permite enviar y recibir mensajes de individuos, no existe la posibilidad de participar en grupos. Tener la posibilidad de participar en grupos podría simplificar la comunicación en ciertas situaciones en las que un grupo de personas comparten información común. Un ejemplo sería gestionar un viaje en grupo, en el que todos los integrantes comparten alojamiento, vuelos e itinerarios. 2.3. Análisis de la competencia 2.3.1. Aplicaciones similares En esta subsección hablaré de algunas aplicaciones que también proveen de una aplicación que implementa la API de Whatsapp para la comunicación empresarial, señalando sus principales características que las diferencian de las demás. 2.3. Análisis de la competencia 13 2.3.1.1. Wasapi Incluye una gran cantidad de funciones. Entre ellas destaca la posibilidad de crear y gestionar chatbots, sin necesidad de código, que ayuden a automatizar parte de las conversaciones. También la aplicación te permite integrar ChatGPT en tus conversaciones, entrenando modelos específicos que también ayuden a automatizar las conversaciones. Figura 2.1: Chat de móvil de Wasapi 2.3.2. Wati En Wati, al igual que en Wasapi, tienes la posibilidad de gestionar de forma sencilla chatbots para poder automatizar conversaciones. También puedes crear grupos de contactos, a los cuales enviar el mismo mensaje en broadcast, incluyendo también estadísticas de número de contactos que han recibido/leído el mensaje. 20 Capítulo 3. Fundamentos Teóricos y Tecnológicos Axios Axios es una librería que nos permite realizar solicitudes HTTP de manera sencilla y versátil. Vuex Vuex es una biblioteca oficial para la gestión del estado en aplicaciones Vue.js. En nuestra aplicación se utiliza para poder guardar información sobre el usuario despues de que inicie sesión. Vue Router Vue Router nos permite gestionar la navegación y sus rutas en la aplicación. Socket.IO Socket.IO crea el WebSocket del lado del cliente en nuestra aplicación, lo utilizamos para escuchar eventos del servidor cuando el cliente recive mensajes. Tambien puede enviar eventos al servidor, aunque esta funcionalidad no la empleamos en mi aplicación. 3.1.4. Tecnologías generales 3.1.4.1. Github Github es una plataforma de alojamiento de código que utiliza Git para el control de versiones. Permite la colaboración eficiente entre los desarrolladores y la gestión de versiones del proyecto. Figura 3.4: Logo de Github 3.1.4.2. Visual Studio Code Visual Studio Code es un editor de código fuente, conocido por su flexibilidad y la amplia gama de extensiones disponibles para mejorar la productividad del desarrollo. Tanto el frontend como el backend se han desarrollado íntegramente en este editor de texto. 3.1. Tecnologías utilizadas 21 Figura 3.5: Logo de Visual Studio Code 3.1.4.3. DBeaver DBeaver es una herramienta de gestión de bases de datos que proporciona una interfaz gráfica para interactuar con diferentes sistemas de gestión de bases de datos. Facilita la administración y consulta de datos de manera intuitiva. Figura 3.6: Logo de DBeaver 3.1.4.4. Postman Postman es una herramienta para el desarrollo de APIs. Permite hacer peticiones HTTP de manera sencilla desde su interfaz, incluyendo cabeceras, formularios o queries. En la aplicación se ha utilizado para poder probar los endpoints del backend y de la API de Whatsapp de manera eficiente. 22 Capítulo 3. Fundamentos Teóricos y Tecnológicos Figura 3.7: Logo de Postman 3.1.4.5. Ngrok Ngrok es una herramienta que permite exponer un servidor local a Internet mediante la creación de túneles seguros. Ha sido necesario en el desarrollo de la aplicación para poder recibir en mi máquina local los mensajes entrantes. Figura 3.8: Logo de Ngrok 3.2. API de Whatsapp La API de WhatsApp permite a las empresas y desarrolladores integrar la funcionalidad de mensajería de WhatsApp en sus aplicaciones y sistemas. Esta API facilita la comunicación directa con los usuarios ofreciendo una variedad de características para interactuar de manera efectiva y eficiente. 1. Mensajería de Texto: La API de WhatsApp permite enviar y recibir mensajes de texto, lo que facilita la comunicación directa con los usuarios. 2. Mensajería multimedia: Es posible enviar y recibir archivos multimedia, como imágenes, videos, documentos y audios, permitiendo una comunicación más rica y dinámica con los usuarios. 3. Notificaciones y Alertas: La API puede utilizarse para enviar notificaciones automáticas y alertas a los 3.2. API de Whatsapp 23 usuarios, como confirmaciones de pedidos, actualizaciones de estado, recordatorios de citas, etc. 4. Interactividad Permite crear interacciones bidireccionales con los usuarios mediante botones de respuesta rápida y menús interactivos, mejorando la experiencia del usuario y facilitando la recopilación de información. Cap´ ıtulo 4 Especificación de casos de uso En este capítulo explico los distintos actores de la aplicación, así como los casos de uso principales de la misma. 4.1. Actores En mi aplicación se distinguen hasta cuatro tipos distintos de actores o usuarios. El objetivo de distinguir cada tipo de usuario es limitar la información que puede consultar o modificar dependiendo del rol que desempeña. Los distintos actores que he definido son: 1. Usuario no autenticado: Los usuarios no autenticados no tendrán acceso a ninguna función de la aplicación; solo podrán acceder al formulario de inicio de sesión. 2. Usuario estándar: La función de los usuarios estándar de mi aplicación es el uso del chat de la misma. Por ello dispondrá de acceso a los distintos chats de su organización, pudiendo enviar mensajes, cambiar su estado y acceder a la sección de notas. Además, podrán modificar su propia información de usuario, a excepción del rol asignado. 3. Manager: Los usuarios manager serán los encargados de la gestión de su organización. Incluirán todas las funcionalidades del usuario estándar. Adicionalmente, dispondrán de acceso a la información de todos los usuarios de su organización. Podrán editarla completamente, incluyendo el rol de usuario, además de poder registrar a nuevos usuarios en su organización. También serán capaces editar la información de su propia organización. 4. Administrador: El rol de administrador no se asignará a un usuario concreto, sino a una organización, y todos los usuarios de la misma serán administradores. Los administradores estarán al cargo de la gestión de las distintas organizaciones. 25 26 Capítulo 4. Especificación de casos de uso Además de tener acceso a todas las funcionalidades de los demás usuarios, los administradores podrán crear nuevas organizaciones y de editar cualquiera existente. También serán capaces de registrar usuarios en cualquier organización existente. 4.2. Casos de uso Esta sección describe los diferentes casos de uso de la aplicación, los cuales detallan las interacciones típicas entre los usuarios y el sistema. Los casos están categorizados según las principales funcionalidades de mi aplicación. 4.2.1. Gestión de usuarios Registrar usuario Actores Manager y Administrador Pre-condición El usuario tiene que haber iniciado previamente sesión. Flujo Normal 1. El usuario accede al menú principal de la aplicación. 2. El usuario pulsa en registrar nuevo usuario. 3. Al usuario se le muestra un formulario de registro. 3. El usuario rellena el formulario. 4. Pulsa en registrar. Postcondición 1. El usuario queda registrado en la base de datos. 2. El ususario es dirigido a la página de listado de usuarios Iniciar sesión Actores Usuario no autenticado Pre-condición El usuario debe no haber iniciado sesión o haberla cerrado previamente. Flujo Normal 1. El usuario inicia la aplicación. 2. El usuario pulsa en iniciar sesión. 3. Se le muestra al usuario un formulario de inicio de sesión con campos de email y contraseña 4. El usuario rellena el email y contraseña. 5. Pulsa inicar sesión. Postcondición 1. El usuario tiene la sesión iniciada. 2. El usuario vuelve al menú principal. Editar usuario 4.2. Casos de uso 27 Actores Usuario Estándar Pre-condición El usuario tiene que haber iniciado previamente sesión. Flujo Normal 1. El usuario accede al menú principal de la aplicación. 2. El usuario pulsa en editar usuario. 4. Al usuario se le muestra un formulario con los datos acutales. 5. El usuario edita en el formulario los datos necesarios. 6. Pulsa editar usuario. Postcondición 1. Los datos del usuario se editan en la BBDD. 2. El usuario vuelve al menú principal. Actores Manager y Administrador Pre-condición El usuario tiene que haber iniciado previamente sesión. Flujo Normal 1. El usuario accede al menú principal de la aplicación. 2. El usuario accede al listado de usuarios. 3. Al usuario se le muestra un lista con los usuarios de la aplicación 4. El usuario busca el usuario que le interesa editar y pulsa sobre su botón de editar. 5. Al usuario se le muestra un formulario con los datos acutales. 6. El usuario edita en el formulario los datos necesarios. 7. Pulsa editar usuario. Postcondición 1. Los datos del usuario se editan en la BBDD. 2. El usuario vuelve al listado de usuarios. Cerrar sesión Actores Usuario autenticado Pre-condición El usuario tiene que haber iniciado previamente sesión. Flujo Normal 1. El usuario pulsa en el botón de cerrar sesión de la cabecera de la aplicación. Postcondición 1. Se cierra la sesión del usuario. 2. El usuario vuelve al menú principal. 4.2.2. Gestión de organizaciones Crear organización 28 Capítulo 4. Especificación de casos de uso Actores Administrador Pre-condición El usuario tiene que haber iniciado previamente sesión. Flujo Normal 1. El usuario accede al menú principal de la aplicación. 2. El usuario accede a la lista de organizaciones. 3. El usuario pulsa en el botón de crear organización. 4. Se le mostrará al usuario el formulario para crear la organización. 5. El rellena el formulario con los datos necesarios. 6. Pulsa crear organización. Postcondición 1. Se crea el usuario en la BBDD. 2. El usuario vuelve al listado de organizaciones. Editar Organización Actores Manager Pre-condición El usuario tiene que haber iniciado previamente sesión. Flujo Normal 1. El usuario accede al menú principal de la aplicación. 2. El usuario pulsa en editar organización. 3. Se le muestra al usuario un formulario con los datos actuales de la organización. 4. El usuario edita en el formulario los datos necesarios. 5. Pulsa editar organización. Postcondición 1. Los datos de la organización se editan en la BBDD. 2. El usuario vuelve al menú principal. Actores Administrador Pre-condición El usuario tiene que haber iniciado previamente sesión. Flujo Normal 1. El usuario accede al menú principal de la aplicación. 2. El usuario accede al listado de usuarios. 3. Se le muestra al usuario una lista con las organizaciones de la aplicación. 4. El usuario busca la organización que desea editar y pulsa el botón de editar. 5. Se le muestra al usuario un formulario con los datos actuales de la organización. 6. El usuario edita en el formulario los datos necesarios. 7. Pulsa editar organización. Postcondición 1. Los datos de la organización se editan en la BBDD. 2. El usuario vuelve al listado de organizaciones. 4.2. Casos de uso 29 4.2.3. Chats y mensajería Seleccionar un chat Actores Usuario autenticado Pre-condición El usuario tiene que haber iniciado previamente sesión. Flujo Normal 1. El usuario inicia la aplicación. 2. El usuario pulsa en el botón a la página de chat 3. El usuario busca en el listado de chats el que quiere abrir. 4. El usuario pulsa en la tarjeta de dicho chat. Postcondición 1.Se abre dicho chat, apareciendo en la parte derecha de la página de chat. 2.Se marcan todos los mensajes del cliente que no tuvieran el estado de leído a este. Enviar mensaje de texto Actores Usuario autenticado Pre-condición El usuario debe haber abierto un chat previamente y este no debe haber expirado. Flujo Normal 1. El usuario selecciona el input de texto para escribir un mensaje. 2. El usuario escribe el mensaje que desea enviar. 3. El usuario pulsa el boton de enviar mensaje. Postcondición 1.El mensaje se envía por Whatsapp al número de teléfono correspondiente. 2. El mensaje se crea en la BBDD 3. El estado del chat se actualiza en la BBDD y en el lado del cliente. 4. El mensaje aparece en la parte de abajo del todo del chat seleccionado. 5. El chat sube arriba del todo del listado de chats. Enviar un archivo 36 Capítulo 6. Funcionamiento de la Aplicación contraseña. El campo de contraseña tiene a su derecha un botón que la la mostrará o volverá a ocultar. Figura 6.2: Pantalla de login 6.1.2. Registro Los usuarios que sean manager o administradores tendrán la posibilidad de registrar nuevos usuarios. El formulario de registro tendrá los campos para el email, nombre de usuario, contraseña, organización (en caso de ser administrador, si es manager no aparecerá el campo) y si es manager el usuario a crear. 6.1. Gestión de usuarios 37 Figura 6.3: Formulario registro El formulario del registro debe cumplir: Ningún campo está vacío. El email tiene el formato de la siguiente expresión regular: [A-Za-z0-9._+ %+-]+(?<!\.)@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$ El email tampoco está asociado a ningún otro usuario, este será único para cada usuario. El nombre de usuario sí puede ser compartido por varios usuarios. La contraseña tiene un longitud mínima de 7 caracteres. Se creará un usuario con los datos introducidos. La contraseña no se guardará tal cual en la base de datos, sino que se encriptará primero. 6.1.3. Modificar usuario Todos los usuarios podrán modificar sus propios datos. Los manager, en cambio, serán capaces de cambiar los de cualquier usuario que pertenezca a su organización. Por último los administradores podrán modificar cualquier usuario. Un usuario estándar tampoco tendrá la posibilidad de modificar su rol. Al cargar la página el email, el nombre de usuario y el rol (si tiene permisos para editarlo) se mostrarán con los valores que poseen actualmente. La contraseña, en cambio, permanecerá vacía, y en caso de quedar vacía al pulsar el botón de editar usuario, no se modificará en la base de datos. 38 Capítulo 6. Funcionamiento de la Aplicación Figura 6.4: Formulario de edición de usuario 6.1.4. Listado de usuarios Los manager y administradores tendrán acceso a una vista que muestre la lista de usuarios. Si el usuario es un administrador, podrá ver los usuarios de todas las organizaciones. En caso contrario sólo podrá ver los usuarios de su propia organización. En el listado podrá ver los datos relevantes de los usuarios, como el nombre, email y su organización. En la parte derecha de cada elemento de la lista, se mostrará un botón que redirigirá a la página de modificación de ese usuario y otro botón para poder eliminar dicho usuario. En la parte superior hay un selector para poder filtrar por organización. Al seleccionar la organización y pulsar el botón de buscar se mostrará el listado filtrado. 6.1. Gestión de usuarios 39 Figura 6.5: Listado de usuarios Los usuarios en la lista estarán paginados en caso de ser elevados, en la parte inferior podrás navegar entre las diferentes páginas del listado de usuarios. Figura 6.6: Paginación usuarios 6.1.5. Logout En cualquier momento el usuario puede cerrar su sesión pulsando el botón que aparece en la parte derecha de la cabecera. Figura 6.7: Botón cerrar sesión 40 Capítulo 6. Funcionamiento de la Aplicación 6.2. Gestión de organizaciones Las organizaciones son fundamentales en mi aplicación. Cada organización tiene sus propias creedenciales a la API de Whatsapp, sus propios usuarios y chats. Una organización no tiene acceso a la información de otras organizaciones. A excepción de la función de editar la información de tu propia organización, las funcionalidades de este módulo son exclusivas de los administradores de la aplicación. 6.2.1. Crear organización La página de crear una organización mostrará un formulario con todos los datos de la organización. En un inicio sólo será obligatorio el campo de nombre, pero para el funcionamiento del chat es necesario que en un futuro se introduzcan todos los campos. En ningún caso se podrá hacer administradora a una organización desde su página de creación (tampoco se podrá en la página de edición de la que hablo a continuación), debido a ser una acción delicada y rara que alguna vez ocurra. Si fuera necesario hacer una organización administradora, deberá modificarlo a mano el gestor de la base de datos. Figura 6.8: Formulario para crear una organización 6.2.2. Modificar una organización Los manager de una organización podrán modificar la suya. Los administradores podrán modificar cualquiera. Se mostrará un formulario similar al de creación de organización, éste cargará con los datos actuales de la organización. El usuario cambiará los datos que necesite y pulsará el botón de modificar organización. 6.2. Gestión de organizaciones 41 Figura 6.9: Formulario para editar una organización 6.2.3. Listado de organizaciones Los administradores poseen acceso a una vista con el listado de las organizaciones de la aplicación. En cada elemento de la lista se muestran los datos relevantes, como son el nombre y el id de número de whatsapp. A la derecha de cada elemento habrá un botón que redirija a la página de modificación de dicha organización. El listado de organizaciones está paginado. En la parte inferior de la vista hay un navegador de páginas de organizaciones. Figura 6.10: Listado de organizaciones 42 Capítulo 6. Funcionamiento de la Aplicación 6.3. Chats y mensajería 6.3.1. Página de chats El chat es el núcleo de mi aplicación. Consta de dos partes, el listado de chats, a la izquierda, y el chat abierto, a la derecha. Figura 6.11: Vista del chat 6.3.2. Listado de chats La parte izquierda de la vista de chats es la lista de chats. Estas están ordenadas por la fecha del último mensaje. En cada elemento de la lista se muestra: Arriba izquierda: Número de teléfono. Arriba centro: Nombre de Whatsapp. Abajo izquierda: Tiempo restante para responder (en hh:mm). Abajo centro: Fecha y hora del último mensaje. Derecha: Estado del chat. El chat que esté seleccionado se mostrará con color más oscuro. 6.3. Chats y mensajería 43 Figura 6.12: Listado de chats También arriba del listado habrá un selector para poder filtrar los chats por los estados que se seleccionen. Figura 6.13: Filtro de estados 6.3.2.1. Estado del chat El círculo a la derecha de cada elemento de la lista de chats indica el estado en el que se encuentra dicho chat. Si posicionas el ratón encima aparece un tooltip mostrando el nombre del estado. Los estados que puede tener un chat son: 0. Sin iniciar: Este estado indica que el chat está creado, aún no tiene mensajes. Ningún chat 44 Capítulo 6. Funcionamiento de la Aplicación puede llegar a este estado actualmente de manera natural, ya que los chats se crean en el momento en el que se crea el primer mensaje. Este estado existe para el caso de que en el futuro se pudieran crear chats de forma manual sin la necesidad de recibir un mensaje. 1. Cerrado: El tiempo para responder a dicho chat ha expirado. No es posible enviar mensajes. 2. Solucionado: Indica que una conversación ha finalizado de manera satisfactoria. Este estado se asigna únicamente de manera manual. 3. Primer pendiente: El cliente ha escrito, pero la organización aún no ha escrito ningún mensaje por el chat. 4. Pendiente: El cliente ha sido el último en escribir. 5. Respondido: La organización ha sido la última en escribir en el chat y aún no hemos recibido confirmación de que nos haya leído. 6. Visto: El cliente ha leído nuestro último mensaje, pero aún no ha respondido de vuelta. 7. Alerta: Indica que hay que estar especialmente atento a esta conversación. Este estado, al igual que el de solucionado, sólo se asigna manualmente. 6.3. Chats y mensajería 45 Figura 6.14: Colores estados 6.3.3. Chat Seleccionado Al seleccionar un chat del listado este se mostrará en la sección principal de la vista. En la parte superior habrá una cabecera con datos relevantes del chat, como el estado, el número de teléfono, el país del número de teléfono y un botón que nos llevará a la sección de notas del chat, que describo más adelante. 52 Capítulo 6. Funcionamiento de la Aplicación También procesamos los mensajes para guardarlos correctamente en la base de datos. 6.3.5. Recibir estado de mensaje El Webhook también recibe la actualización de los estados de un mensaje. Mediante el wam_id podemos identificar a qué mensaje está asociado. Al recibir el estado de un mensaje también se envia un mensaje mediante un socket para que se pueda actualizar en el chat si esta abierto. Cap´ ıtulo 7 Conclusiones y Trabajo Futuro 7.1. Conclusiones La realización del proyecto me ha permitido mejorar mis habilidades en desarrollo de aplicaciones web. Para la realización del trabajo he utilizado tecnologías que no había utilizado antes como son los frameworks de Flasy y Vue. También con este proyecto he aprendido a lidiar con conceptos a los que no me había enfrentado antes, como son los Webhooks, los Websockets o usar los endpoints de una API externa. De los objetivos planteados en un inicio he podido cumplir con prácticamente todos, aunque hay algunos formatos de mensaje que sí guardamos en la BBDD pero no se muestran en el chat, como son los mensajes de contactos o las reacciones a mensajes. También la aplicación guarda cuando un mensaje responde a otro la referencia de a qué mensaje responde, aunque su implementación en el chat nunca se planteó en los objetivos de la aplicación. He logrado crear una aplicación intuitiva, la única parte que puede ser un poco confusa en un inicio son los estados del chat y que el usuario reconozca cuál es el estado por el color. Aunque al no tener una gran cantidad de estados y por los colores elegidos, los usuarios no tardarían mucho en aprenderlos. He logrado mediante los websockets que la aplicación reciba los mensajes y actualizaciones de los chats en tiempo real. Recibiendo los mensajes del chat que tenga el usuario abierto, tanto la actualización de los las tarjetas de chats en el lateral, subiendo esta arriba del todo con la información actualizada al recibir o escribir un mensaje. El funcionamiento de la gestión de usuarios y organizaciones ha sido muy satisfactorio. Tener administradores que su principal funcionalidad sea la de crear organizaciones y usuarios. Los manager gestionando su propia organización y usuarios de la misma. Y los usuarios estándar cuyo único papel es el uso del chat de la aplicación. En resumen, el resultado ha sido satisfactorio tanto a nivel de aprendizaje como a nivel de implementación de los requisitos de la aplicación. 53 54 Capítulo 7. Conclusiones y Trabajo Futuro 7.2. Trabajo futuro Hay una gran cantidad de funcionalidades que quedan abiertas para poder expandir la aplicación, aquí hay un listado de las funcionalidades que podrían implementarse en un futuro, las cuales ayudarían a mejorar la comunicación en los chats de la aplicación. Incluir el soporte para los mensajes de contacto. Aunque estos no son para nada comunes, razón por la que se optó por no incluir, puede llevar a confusiones cuando los recibimos. Añadir la posibilidad de enviar mensajes interactivos, como por ejemplo mensajes con botones de selección. Este tipo de mensajes puede dar aire fresco a la conversación ya que son mensajes que no se utilizan fuera de Whatsapp Business. Adaptar las vistas para poder utilizar la aplicación desde un teléfono móvil. Implementar las plantillas de mensaje. Whatsapp tiene otra API la cual permite crear plantillas de mensaje, las cuales debe aceptar Meta para su utilización. Dichas plantillas no sufren la limitación temporal de los mensajes normales, pudiendo enviar plantillas de mensaje a cualquier número en cualquier momento. Poder crear chats manualmente, si se implementa el punto anterior de las plantillas de mensaje, sería interesante crear chats manualmente a los que puedas enviar dichas plantillas; y no tener que esperar a recibir un mensaje del cliente para que se cree dicho chat. Mejorar los mensajes de localización. En la versión actual de la aplicación sólamente incluye un link que te envía al maps con la latitud y longitud. Podría incluirse que la localización incluya el nombre del lugar que te envía si lo tuviera, y una previsualización de maps, no solo un texto con un enlace. Poder visualizar y realizar respuestas a mensajes. Esto ayudaría en muchas ocasiones a mantener la coherencia en la conversación. Enviar audio desde la aplicación, pudiendo grabar de un micrófono y enviarlo como audio al usuario. Un chatbot simple que pueda responder mensajes predefinidos cuando una empresa no se encuentre en su horario operativo. Poder implementar el envío de mensajes planificados temporalmente. Poder establecer la fecha y hora en la que se va a enviar un mensaje. Poder reconocer algún tipo de comando en los mensajes entrantes para que un usuario pueda dejar feedback de cómo ha sido su experiencia con la organización. Dichos mensajes no se mostraría en los chats las reviews serían anónimas. Conclusions and Future Work 7.1. Conclusions Completing this project has allowed me to improve my skills in web application development. For this work, I used technologies that I had not used before, such as the Flask and Vue frameworks. Additionally, through this project, I learned to deal with concepts that I had not encountered before, such as Webhooks, WebSockets, or using the endpoints of an external API. I was able to accomplish almost all of the objectives set at the beginning. However, there are some message formats that we do store in the database but do not display in the chat, such as contact messages or reactions to messages. The application also stores when a message replies to another, keeping a reference to the message it responds to, although implementing this feature in the chat was never part of the application’s objectives. I managed to create an intuitive application, with the only potentially confusing aspect being the chat states and users recognizing each state by its color. However, given the limited number of states and the chosen colors, users would not take long to learn them. Through the use of WebSockets, I ensured that the application receives messages and chat updates in real time. The application updates the currently open chat with new messages, as well as the chat cards on the side panel, moving the updated chat to the top when a message is received or sent. The functionality of user and organization management has been very satisfactory. Administrators primarily create organizations and users, managers handle their own organization and its users, and standard users are solely responsible for using the application’s chat. In summary, the result has been satisfactory both in terms of learning and in implementing the application’s requirements. 7.2. Future Work There are a large number of features that remain open to expand the application. Here is a list of functionalities that could be implemented in the future, which would 55 56 Capítulo 7. Conclusiones y Trabajo Futuro help improve communication within the application’s chats. Include support for contact messages. Although these are quite uncommon (which is why they were not included initially), they could cause confusion when received. Add the ability to send interactive messages, such as messages with buttons. These types of messages can refresh the conversation since they are not used outside of WhatsApp Business. Adapt the views to allow the application to be used on a mobile phone. Implement message templates. WhatsApp has another API that allows the creation of message templates, which Meta must approve for use. These templates do not suffer from the time limitation of regular messages, allowing template messages to be sent to any number at any time. Enable the manual creation of chats. If the previous point regarding message templates is implemented, it would be interesting to manually create chats to which these templates could be sent, rather than waiting for a message from the client to create the chat. Improve location messages. In the current version of the application, it only includes a link that directs to maps with latitude and longitude. It could be improved by including the location’s name (if available) and a preview of the map, not just a text link. Enable viewing and replying to messages. This would often help maintain coherence in some conversations. Allow sending audio from the application, with the ability to record from a microphone and send it as an audio message to the user. Implement a simple chatbot that can respond with predefined messages when a company is outside its operating hours. Implement the ability to send scheduled messages, allowing users to set the date and time a message will be sent. Recognize some kind of command in incoming messages so that a user can leave feedback on their experience with the organization. These messages would not be displayed in the chats, and the reviews would be anonymous. Bibliografía [1] ID Digital School, Evolución de la comunicación empresarial, Disponible en: https://iddigitalschool.com/ evolucion-de-la-comunicacion-empresarial/ [2] Luciano Ramalho, Fluent Python, O’Reilly Media, 2015. [3] Facebook Developers, WhatsApp Business API Documentation, Disponible en: https://developers.facebook.com/docs/whatsapp [4] Pallets Projects, Flask Documentation (3.0.x), Disponible en: https://flask. palletsprojects.com/en/3.0.x/ [5] Vue.js Team, Vue.js Documentation, Disponible en: https://vuejs.org/guide [6] Miguel Grinberg, Flask-SocketIO Documentation, Disponible en: https:// flask-socketio.readthedocs.io/en/latest/ [7] MDN Web Docs, Learn CSS, Disponible en: https://developer.mozilla. org/en-US/docs/Learn/CSS [8] Pallets Projects, Flask-SQLAlchemy Documentation (3.1.x), Disponible en: https://flask-sqlalchemy.palletsprojects.com/en/3.1.x/ [9] Flask-Login Documentation, Flask-Login Documentation (Latest), Disponible en: https://flask-login.readthedocs.io/en/latest/ [10] Flask-Migrate Documentation, Flask-Migrate Documentation (Latest), Disponible en: https://flask-migrate.readthedocs.io/en/latest/ [11] PostgreSQL Documentation, PostgreSQL Documentation (Current Version), Disponible en: https://www.postgresql.org/docs/current/ 57 Ap´ endice A Título del Apéndice A Aquí incluyo los enlaces a los repositiorios en GitHub con el código del proyecto: Backend: https://github.com/Averdrian/back-communicenter Frontend: https://github.com/Averdrian/front-communicenter 59