Automatización para entornos ITSM-ITIL basada en bots

Escuela de Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática Mención Ingeniería del Software Automatización para entornos ITSM-ITIL basada en bots Autor: D. Juan Carlos Gil Díaz Escuela de Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática Mención Ingeniería del Software Automatización para entornos ITSM-ITIL basada en bots Autor: D. Juan Carlos Gil Díaz Tutor interno: D. Diego Rafael Llanos Ferraris Tutor externo: D. Francisco Vallejo Luna 3 1Resumen Bot de Discord que se comunica con la aplicación Service Manager a través de su API REST y que permite a los usuarios la creación, modificación, comprobación de estado y cierre de Incidencias, además de la consulta de diversos Indicadores clave de rendimiento, todo ello a través del chat de Discord. Palabras clave: Bot, Discord, Service Manager, REST. 1.1Abstract Discord Bot which communicates with Service Manager application using its REST API, which allows users to create, modify, check the status of and close an Incident, in addition to the consult of various Key Performance Indicators, all done though Discord’s chat. Key words: Bot, Discord, Service Manager, REST. 4 2Tabla de contenidos 1Resumen .................................................................................................................................. 3 1.1Abstract ............................................................................................................................ 3 2Tabla de contenidos.................................................................................................................. 4 3Lista de figuras y tablas ............................................................................................................ 6 4Introducción .............................................................................................................................. 7 4.1Objetivo .............................................................................................................................. 7 4.2Motivación .......................................................................................................................... 7 4.3Definiciones ....................................................................................................................... 7 5Análisis de requisitos de usuario ............................................................................................ 10 5.1Requisitos del sistema ..................................................................................................... 10 5.2Planificación temporal ...................................................................................................... 11 5.3Análisis de riesgos ........................................................................................................... 15 5.4Presupuesto ..................................................................................................................... 15 6Modelo de análisis .................................................................................................................. 17 6.1Diagrama de Casos de Uso ............................................................................................. 17 6.2Secuencia de los Casos de Uso ...................................................................................... 18 6.2.1Caso de Uso “Crear Incidencia” ................................................................................. 19 6.2.2Caso de Uso “Modificar Incidencia” ........................................................................... 20 6.2.3Caso de Uso “Consultar estado de Incidencia”.......................................................... 21 6.2.4Caso de Uso “Cerrar Incidencia” ............................................................................... 22 6.2.5Caso de Uso “Consultar KPIs” ................................................................................... 23 6.3Diagrama simplificado de la base de datos de Service Manager ..................................... 24 6.4Modelo de dominio de la aplicación ................................................................................. 25 6.5Arquitectura empleada en la aplicación ............................................................................ 26 6.6Diagrama de recursos REST expuestos en Service Manager ........................................ 27 7Diseño ..................................................................................................................................... 28 7.1Metodología ..................................................................................................................... 28 7.2Diagramas de interacción ................................................................................................. 29 7.2.1Caso de Uso “Crear Incidencia” ................................................................................. 30 7.2.2Caso de Uso “Modificar Incidencia” ........................................................................... 31 7.2.3Caso de Uso “Consultar KPI”..................................................................................... 32 8Implementación ...................................................................................................................... 33 5 8.1Fase Previa al comienzo del desarrollo del Bot. .............................................................. 33 8.1.1Instalación de la Máquina Virtual ............................................................................... 33 8.1.2Instalación de PostgreSQL 12 [3] .............................................................................. 35 8.1.3Instalación de Service Manager [5] ........................................................................... 37 8.1.4Aprendizaje de uso de varios comandos de Service Manager. ................................. 40 8.2Software utilizado ............................................................................................................. 42 8.3Implementación de los casos de uso ............................................................................... 42 9Pruebas .................................................................................................................................. 43 9.1Creación de nuevas incidencias en el sistema. ............................................................... 43 9.2Consulta del estado de una incidencia. ............................................................................ 46 9.3Modificación de datos de una incidencia. ......................................................................... 46 9.4Cierre de una incidencia. ................................................................................................. 49 9.5Consulta de uno o varios Indicadores Clave de Rendimiento (KPI) ................................. 50 10Manual del programador ....................................................................................................... 51 11Manual de usuario de las aplicaciones desarrolladas........................................................... 52 11.1Obtener ayuda ............................................................................................................... 52 11.2Crear Incidencia ............................................................................................................. 52 11.3Modificar Incidencia ....................................................................................................... 53 12Conclusiones ........................................................................................................................ 55 12.1Características del proyecto ........................................................................................... 55 12.2Futuras aplicaciones ...................................................................................................... 55 13Bibliografía/Referencias ........................................................................................................ 56 6 3Lista de figuras y tablas Figura 1 - Estimación de tiempo total y sección configuración previa 12 Figura 2 - Estimación de tiempo CU Crear Incidencia 12 Figura 3 - Estimación de tiempo CU Modificar Incidencia 13 Figura 4 - Estimación de tiempo CU Consultar estado de Incidencia 13 Figura 5 - Estimación de tiempo CU Cerrar Incidencia 14 Figura 6 - Estimación de tiempo CU Consultar KPI 14 Figura 7 - Estimación de tiempo revisión final y documentación 15 Figura 8 - Tabla de riesgos al proyecto 15 Figura 9 - Presupuesto del proyecto 16 Figura 10Diagrama de casos de uso 17 Figura 11Detalle del Caso de Uso "Crear Incidencia" 19 Figura 12Detalle del Caso de Uso "Modificar Incidencia" 20 Figura 13Detalle del Caso de Uso "Consultar estado de Incidencia" 21 Figura 14Detalle del Caso de Uso "Cerrar Incidencia" 22 Figura 15Detalle del caso de uso "Consultar KPIs" 23 Figura 16Simplificación de la base de datos de SM 24 Figura 17Modelo de dominio de la aplicación 25 Figura 18 - Arquitectura genérica propuesta 26 Figura 19 - Diagrama REST de la aplicación 27 Figura 20 - Diagrama de Interacción CU Crear Incidencia 30 Figura 21 - Diagrama de Interacción CU Modificar Incidencia 31 Figura 22 - Diagrama de Interacción CU Consultar KPI 32 Figura 23Página de descargas de CentOs 33 Figura 24Configuración de la máquina virtual 34 Figura 25Primera pantalla tras el arranque de la máquina virtual 34 Figura 26Configuración del instalador de CentOs8 35 Figura 27Selección de la versión de postgreSQL a instalar 36 Figura 28Línea añadida en el fichero pg_hba.conf en el que se permite el acceso al usuario sm 37 Figura 29Ejecución del script de configuración de SM 38 Figura 30Configuración del cortafuegos 39 Figura 31Configuración de la conexión en el cliente de Service Manager 39 Figura 32Campo de texto para comandos en Service Manager 40 Figura 33 - Batería de pruebas CU Crear Incidencia 45 Figura 34 - Batería de pruebas CU Consultar Estado de Incidencia 46 Figura 35 - Batería de pruebas CU Modificar Incidencia 49 Figura 36Batería de pruebas CU Cerrar Incidencia 50 Figura 37 - Batería de pruebas CU Consultar KPI 50 Figura 38 - Solicitar ayuda al bot de Discord 52 Figura 39 - Solicitar creación de nueva Incidencia 52 Figura 40 - Canal de Creacion de la Incidencia 53 Figura 41 - Solicitar modificación de una Incidencia 53 Figura 42 - Canal de modificación de la Incidencia 54 7 4Introducción 4.1Objetivo El objetivo del proyecto ha sido el de automatizar la creación de Incidencias en la aplicación Service Manager mediante el desarrollo de un bot de Discord que interactúe con los usuarios (operadores) sin necesidad de que estos utilicen directamente la aplicación y de manera rápida y fácil mediante el uso del API REST de Service Manager. Los casos de uso a implementar son los siguientes:  Creación de nuevas incidencias en el sistema.  Consulta del estado de una incidencia.  Modificación de datos de una o varias incidencias.  Cierre de una incidencia.  Consulta de uno o varios Indicadores Clave de Rendimiento (KPI) 4.2Motivación La motivación para el desarrollo del proyecto se debe a la curva de aprendizaje presentada por Service Manager, que provoca que su rendimiento sea bajo durante el comienzo del uso de la aplicación, ya que desde un principio se presentan muchos campos para cada registro, lo que puede provocar un exceso de información debido a que el usuario no sabe el propósito de todos los campos, o qué campos son necesarios para realizar una determinada acción tal como cambiar el estado de una incidencia creada. El Bot de Discord simplificará los pasos en la realización de diversas acciones proporcionando un proceso sencillo y guiado que permitirá al usuario realizar ciertas tareas de forma más sencilla, sin necesidad de utilizar ninguno de los clientes de Service Manager, y manteniendo la seguridad y la integridad de los datos. 4.3Definiciones A continuación se definen varios conceptos que se utilizarán a lo largo de este documento:  Service Manager (SM): Solución desarrollada por Micro Focus que cumple con el estándar ITIL y que permite la gestión de servicios, activos, conocimiento y servicios empresariales. Proporciona una plataforma en la que estandarizar y automatizar procesos, flujos de trabajo y tareas de manera “code-less”.  Cliente Windows de SM: Aplicación cliente de Service Manager que se instala en un dispositivo Windows y que permite el acceso a toda la funcionalidad de Service Manager excepto al creador de flujos de trabajo. Es instalado por el cliente.  Cliente Web de SM: Aplicación cliente de Service Manager que se despliega en un servidor Tomcat y que permite el acceso a toda la funcionalidad de Service Manager exceptuando el diseñador de formularios. Se despliega en el servidor. 8  Operador: Usuario de Service Manager capaz de iniciar sesión en la aplicación y realizar distintas tareas dependiendo de los permisos que tenga. Debe tener un contacto asociado.  Contacto: Usuario de Service Manager que no puede iniciar sesión en la aplicación. Se utilizan como base para los operadores y como registros a los que podemos asignar “tickets”.  Ticket: Registro de Incidencia, Problema, Petición de cambio o Interacción. Cada ticket posee un flujo de trabajo individual.  Incidencia: Registro de un fallo o problema con algún elemento que previamente funcionaba correctamente. Pueden ser creadas directamente o creadas a partir de una interacción.  Problema: Incidencia que se repite a menudo o que provoca graves daños. Durante la resolución de problemas se comienza con una solución temporal (workaround) mientras se investiga la causa principal del problema (root cause analysis). Finalmente, una vez que se ha encontrado la solución al problema, se crea una petición de cambio y se resuelve el problema.  Petición de cambio: petición para realizar un cambio. Puede ser para corregir un problema conocido o para modificar el funcionamiento de algún elemento registrado. Pasan por una serie de aprobaciones a lo largo de su flujo de trabajo y deben tener al menos un plan de recuperación en caso de fallo durante la aplicación del cambio.  Interacción: Registro del primer contacto del cliente con el personal de asistencia. La interacción puede o bien resolverse de manera directa en ese estado, o bien ser escalada a Incidencia o incluso a Problema dependiendo de su complejidad, del tiempo que lleve abierta, o del conocimiento de los expertos asignados a la incidencia.  KPI: Key Performance Indicator, Indicador de Rendimiento Clave. Valores numéricos útiles para medir aspectos clave de rendimiento de los trabajadores o del sistema, tales como media de días entre la apertura y el cierre de un ticket, o el porcentaje de tickets que son escalados.  Discord: Plataforma de mensajería instantánea mediante chat, voz o vídeo lanzada en el año 2015, que permite la creación de servidores privados con canales, además de la integración con bots desarrollados en múltiples lenguajes de programación como Python o Javascript.  Bot: Aplicación diseñada para realizar tareas de manera automática a partir de comandos. En nuestro caso desarrollaremos un bot para Discord que interactuará con usuarios y se comunicará con Service Manager mediante su API REST. 9  Servidor de Discord: Grupo privado de Discord que contiene uno o más canales mediante los que los usuarios pertenecientes al servidor pueden comunicarse.  Canal de Discord: Chats dentro de servidores. Los canales pueden ser públicos (visibles para todos los usuarios en el servidor) o privados (solo visibles para un determinado número de usuarios). Cada canal tiene su propio chat independiente del resto de canales. Existen canales de texto y de voz, y en los canales de voz se permite la compartición de pantalla con otros usuarios en el canal.  Canal privado: Canal dirigido solo a un determinado número de usuarios en un servidor, no visible para el resto. Pueden ser de voz o de texto.  CentOs8: Sistema operativo de código abierto basado en Linux. Es una bifurcación de GNU/Linux Red Hat Enterprise Linux RHEL. Será descontinuado a finales del año 2021.  Micro Focus: Empresa multinacional de origen británico fundada en el año 1976 dedicada al ámbito de las tecnologías de la Información y el software.  ITIL: Infrastructure Technologies Information Library: Conjunto de consejos y buenas prácticas para la gestión y el desarrollo de servicios de Tecnologías de la Información. No es un estándar, puesto que no indica cómo se deben hacer las cosas, si no que indica qué se debe hacer.  CI (Configuration Item): Todo elemento hardware, software o incluso de personal que posee una empresa. 16  Gestor de Proyecto: Realiza la planificación inicial, así como las revisiones de la planificación al comienzo de cada caso de uso. Está presente en todas las reuniones de progreso y tiene un coste de 50€ la hora. Con estos recursos, obtenemos las siguientes horas de trabajo para cada recurso, y su coste:  Técnico: 493,5 horas, obtenemos un coste de 9.376€  Analista: 89,4 horas, obtenemos un coste de 4.470€  Gestor de Proyecto: 21,5 horas, obtenemos un coste de 1.075€ Esto nos da un coste total de 14.921€. Estimando que la empresa encargada de realizar este proyecto quiera obtener un margen de beneficios del 30% sobre el coste inicial del proyecto, añadiendo un 10% al valor de los costes debido a los riesgos, y añadiendo impuestos (únicamente IVA del 21%), realizamos los cálculos y obtenemos un presupuesto de 25.276€ Concepto Cantidad Costes iniciales 14.921 € + 10% riesgos 1.492 € + 30% beneficios 4.476 € Subtotal 20.889 € + 21% IVA 4.387 € TOTAL 25.276 € Figura 9 - Presupuesto del proyecto 17 6Modelo de análisis A continuación se exponen los diversos modelos creados para el proyecto. Para este proyecto se ha realizado un diagrama de casos de uso (con el detalle para cada CU), un diagrama entidadrelación de un fragmento de la base de datos de Service Manager, un diagrama de Dominio, y diagramas de interacción para los casos de uso “Crear Incidencia”, “Modificar Incidencia” y “Consultar KPI”. Además, se ha realizado un diagrama de los servicios REST a exponer desde Service Manager para que el bot pueda acceder a ellos. Todos los diagramas han sido realizados utilizando la herramienta Astah Profesional, proporcionada por la Escuela. 6.1Diagrama de Casos de Uso Figura 10Diagrama de casos de uso 18 Como se puede observar, en el diagrama se presentan 2 actores. Por un lado tenemos un actor “Usuario”, que será el que realizará la mayoría de casos de uso. En segundo lugar, tenemos un actor “Usuario 2”, que realizará los casos de uso más técnicos, tales como la consulta de KPIs. Aunque se diferencian los usuarios, no existe una restricción de ningún tipo para ejecutar dichos casos de uso, únicamente se separan con objetivo de señalizar que en la práctica, la aplicación sería utilizada por dos tipos de usuarios o roles diferentes. También podemos apreciar que el sistema se comunica con otro sistema, Service Manager. Estas comunicaciones se harán exclusivamente a través del API REST de Service Manager. 6.2Secuencia de los Casos de Uso A continuación se detalla el proceso a seguir durante la ejecución de los diversos casos de uso, incluyendo escenarios adicionales: 19 6.2.1Caso de Uso “Crear Incidencia” Figura 11Detalle del Caso de Uso "Crear Incidencia" 20 6.2.2Caso de Uso “Modificar Incidencia” Figura 12Detalle del Caso de Uso "Modificar Incidencia" 21 6.2.3Caso de Uso “Consultar estado de Incidencia” Figura 13Detalle del Caso de Uso "Consultar estado de Incidencia" 22 6.2.4Caso de Uso “Cerrar Incidencia” Figura 14Detalle del Caso de Uso "Cerrar Incidencia" 23 6.2.5Caso de Uso “Consultar KPIs” Figura 15Detalle del caso de uso "Consultar KPIs" 24 6.3Diagrama simplificado de la base de datos de Service Manager En el siguiente diagrama se presenta un fragmento muy simplificado de la base de datos de Service Manager. Como la base de datos original tiene cientos de tablas con decenas de campos para cada tabla, se ha simplificado el diagrama para mostrar solo las tablas que utilizaremos a lo largo del proyecto, indicando dentro de estas tablas los campos más importantes. De esta manera tendremos una mejor percepción de las entidades con las que deberemos trabajar posteriormente. Como se indica en el diagrama, el nombre de las tablas no es muy intuitivo y es necesario aclarar el propósito de algunas de ellas: La tabla “Probsummary” es la tabla de Incidencias en Service Manager, mientras que la tabla “Incident” es la tabla de Interacciones. Por otro lado, la tabla “Activity” almacena cambios en las Incidencias, tales como cambios de datos, de estado, reasignaciones… Figura 16Simplificación de la base de datos de SM 25 6.4Modelo de dominio de la aplicación A partir de los diagramas de casos de uso y entidad-relación, creamos el modelo de dominio que utilizaremos en el proyecto. Se ha optado por incluir solo las clases “Incident” (en representación de las Incidencias) y KPI (en representación de los KPIs) debido a que en el caso de otros posibles elementos de dominio como podrían ser los CIs o los operadores se comprueba que no se realizarían modificaciones en dichos campos, por lo que estaríamos creando un elemento de dominio para utilizarlo únicamente como registro, lo cual es incorrecto. En el caso del KPI, esta situación no se da debido a la forma en la que se almacena la fecha de obtención del KPI en Service Manager. Como queremos devolver la fecha en un formato más legible para el usuario (dd/mm/yyyy hh:mm) el método de devolución de la fecha la procesará antes de devolverla para darle el formato deseado. Figura 17Modelo de dominio de la aplicación 32 7.2.3Caso de Uso “Consultar KPI” Figura 22 - Diagrama de Interacción CU Consultar KPI 33 8Implementación 8.1Fase Previa al comienzo del desarrollo del Bot. Antes de comenzar el desarrollo propio del proyecto, se dedican varias semanas a la “Configuración inicial”. Esto es, la instalación y configuración del entorno virtual en el que se instalará el servidor de Service Manager, la instalación del propio Service Manager, el despliegue de su cliente web y la instalación del cliente Windows, y los aprendizajes tanto de la aplicación Service Manager en sus dos clientes, como del desarrollo de bots de Discord utilizando Python. Esta fase se ha incluido en la planificación inicial del proyecto, en la sección de “Configuración previa” 8.1.1Instalación de la Máquina Virtual El primer paso realizado fue el de instalar una máquina virtual CentOs 8, que se utilizará como servidor en el que se ejecutarán los servidores de Service Manager, Tomcat y postgreSQL. Para obtener la imagen del sistema operativo, accedemos a la página de descargas de CentOS [2] y descargar la imagen ISO de CentOs 8 64 bits, versión DVD. A continuación, creamos una máquina virtual usando Oracle VM VirtualBox. Las características de la máquina virtual son las siguientes:  Nombre: CentOS TFG  Tipo: Linux (other)  Tamaño de memoria: 8192 MB  Tipo de disco duro: VDI  Almacenamiento en unidad física: Reservado dinámicamente. Figura 23Página de descargas de CentOs 34 Tras esto, Se añade una unidad de CD a la máquina virtual con la imagen descargada previamente, y se comprueba que en el orden de arranque esté antes la unidad de CD que el disco duro, iniciamos la máquina virtual, y ejecutamos el instalador. Figura 24Configuración de la máquina virtual Figura 25Primera pantalla tras el arranque de la máquina virtual 35 Durante la instalación, seleccionamos el teclado en Español, establecemos la zona horaria, y creamos la contraseña para root (iR+uVqcgcf ) y el usuario administrador (jcarlos, con contraseña TFG20-21). Como queremos comprobar rápidamente el acceso al cliente web cuando esté desplegado, instalamos la opción de “Server with GUI”, que nos permitirá utilizar un navegador gráfico. Tras haber seleccionado la configuración deseada, iniciamos la instalación, con el resto de las características por defecto, y esperamos a que finalice. Tras finalizar la instalación reiniciamos el sistema, aceptamos el acuerdo de licencia, e iniciamos el sistema de manera satisfactoria. 8.1.2Instalación de PostgreSQL 12 [3] Ahora que ya tenemos el sistema operativo correctamente instalado, abrimos un emulador de terminal para instalar PostgreSQL12. En primer lugar ejecutamos el comando dnf module list postgresql (dnf es el instalador de paquetes de CentOs8) para listar todas las versiones disponibles, obteniendo que podemos instalar 3 versiones: 9.6, 10 y 12, siendo la que se instala por defecto la 10. Como queremos la versión 12, la habilitamos mediante el comando dnf module enable postgresql:12 y a continuación lo instalamos con con dnf install postgresql-server () Figura 26Configuración del instalador de CentOs8 36 Tras la instalación, ejecutamos el comando postgresql-setup –initdb, e iniciamos el servicio con el comando systemctl start postgresql, cambiamos a la cuenta de postgres con sudo -i -u postgres, y creamos una base de datos de prueba (createdb prueba), a la que accedemos (psql -d prueba) Allí creamos una tabla sencilla, añadimos varios registros, y los obtenemos mediante varias consultas, comprobando así que funciona correctamente. Figura 27Selección de la versión de postgreSQL a instalar 37 8.1.3Instalación de Service Manager [5] Comenzamos por instalar Perl en nuestra máquina virtual, debido a que es utilizado por el instalador (sudo yum install perl). A continuación, creamos el directorio en el que instalaremos el servidor de Service Manager. En nuestro caso, lo crearemos en /home/jcarlos, y lo llamaremos SM9.7 (mkdir /home/jcarlos/SM9.7). A continuación, ejecutamos el fichero proporcionado por el tutor externo, que contiene el instalador de Service Manager (./setupLinuxX64-9.70.bin), aceptamos los diversos contratos, e indicamos el directorio de instalación. Una vez que la instalación ha finalizado de forma exitosa, accedemos de nuevo al usuario postgres, y creamos una base de datos llamada “sm”, que será la utilizada por Service Manager (createdb sm) Ahora tenemos que permitir el acceso a Service Manager a la base de datos, para ello modificamos el fichero /var/lib/psql/data/pg_hba.conf para añadir el acceso a la nueva base de datos Hemos permitido el acceso a la base de datos “sm” por parte del usuario “sm”, que todavía no existe. Lo que haremos a continuación será crear este usuario de postgres y darle privilegios sobre la base de datos. Esto se hace con las líneas “create user sm;” y “grant ALL on database “sm” to sm;”. Para finalizar, cambiamos el propietario de la base de datos al nuevo usuario mediante la línea “ALTER DATABASE “sm” OWNER TO sm;”, y reiniciamos el servicio (systemctl restart postgresql). Ahora ya podemos conectar nuestro servidor de Service Manager con la base de datos creada. Para ello, ejecutamos el script “configure.sh” que se ha creado durante la instalación de Service Manager. El script nos va pidiendo los datos necesarios (puerto, tipo de entorno producción/pruebas, tipo de base de datos, y características de la base de datos, tales como el host, el puerto y el nombre). Tras un primer error debido a la falta de una librería que instalamos, ejecutamos el script de nuevo, terminando de manera correcta. Figura 28Línea añadida en el fichero pg_hba.conf en el que se permite el acceso al usuario sm 38 Figura 29Ejecución del script de configuración de SM Tras finalizar la configuración, aceptamos la creación de datos de prueba para la base de datos, lo cual crea múltiples tablas y las rellena con los campos de prueba necesarios. Esto tarda varios minutos debido a la inmensa cantidad de tablas y registros que se crean durante el proceso. Una vez que ha finalizado la creación de tablas y registros, iniciamos el servidor mediante el script “smstart”, instalado dentro del directorio “RUN” de Service Manager. Con esto ha quedado correctamente configurado el servidor de Service Manager, ya solo necesitamos un cliente con el que acceder. Para que dicho cliente pueda conectarse al servidor, necesitamos configurar el firewall de la máquina virtual para permitir las conexiones en el puerto 13080. Utilizando el comando “firewallcmd”, creamos el servicio, le asignamos el puerto y el protocolo, lo añadimos a la lista, y recargamos el cortafuegos para asegurarnos de que el nuevo servicio se ha añadido. 39 Figura 30Configuración del cortafuegos Ahora procedemos a instalar el cliente Windows de Service Manager. En este caso, el instalador consiste en un archivo .exe proporcionado por el tutor externo que realiza la instalación de forma automática. Tras la instalación, iniciamos el cliente, configuramos la conexión con el servidor, e iniciamos sesión con el operador de pruebas (falcon). Tras el primer inicio de sesión el sistema nos pide cambiar la contraseña del operador, por lo que la cambiamos a “Tfg20202021”. Figura 31Configuración de la conexión en el cliente de Service Manager 40 Aunque ya podemos acceder a Service Manager a través del cliente pesado Windows, también desplegaremos el cliente web de Service Manager, ya que nos será útil para acceder a alguna funcionalidad que no está disponible en el cliente Windows, como por ejemplo la visualización y configuración de flujos de estados para cada registro en Service Manager. Comenzamos por instalar Tomcat 9 en la máquina virtual (sudo dnf install Tomcat). A continuación, instalamos Java Zulu 8.52 JDK. Una vez que tenemos tanto el Java como el Tomcat, añadimos los puertos que utilizaremos (8080 y 8443 una vez que habilitemos la consexión segura ssl) utilizando firewalld. Movemos el fichero .war proporcionado por el tutor externo al directorio webapps de Tomcat. Tras esto recargamos Service Manager y Tomcat, consiguiendo acceder al cliente web de manera satisfactoria. 8.1.4Aprendizaje de uso de varios comandos de Service Manager. Antes de comenzar con el desarrollo del bot, es necesario conocer la herramienta que se va a utilizar, con objetivo de determinar la manera de realizar las acciones necesarias para el correcto funcionamiento del futuro bot, sin saltarnos ninguna etapa en los procesos. En primer lugar, se realiza una exploración de varios comandos utilizados por Service Manager que nos serán útiles. Estos comandos se escriben en la parte superior izquierda de la aplicación, tal y como se muestra en la imagen: Los comandos que se han estudiado han sido los siguientes: a. comp: Permite modificar los datos de la compañía (nombre, dirección, ciudad…) y otros datos de configuración como la longitud de las contraseñas de los operadores, el formato de la fecha y hora, o las abreviaturas para los meses. Para explorar la vista, se modifican algunos parámetros b. contacts: Permite tanto la búsqueda de un contacto a partir de su nombre completo como la creación de nuevos contactos. Para investigar esta vista más a fondo, creamos dos contactos cuyos operadores utilizaremos posteriormente a lo largo del proyecto: “jcgd” y “bot”. c. operator: De manera similar a contacts, permite buscar o crear operadores. Todo operador debe tener antes un contacto. Creamos un operador para cada contacto Figura 32Campo de texto para comandos en Service Manager 41 creado anteriormente, uno con rol de administradores, lo que les proporcionará acceso a toda la funcionalidad de la aplicación. d. df: Permite crear formularios o editar formularios ya existentes. El nombre del formulario en uso se muestra en la parte inferior derecha de la aplicación. Mediante este comando podemos crear nuevos formularios con diversos campos tanto para la creación como para la visualización de los datos de varios registros. Lo utilizaremos a lo largo del desarrollo del proyecto para crear los formularios que nos permitan visualizar los datos de los KPIs creados posteriormente. e. db: Este comando nos lleva a la vista en la que podemos añadir nuevas tablas o modificar campos de una tabla existente la base de datos. Lo utilizaremos en el proyecto para crear la tabla para los KPIs que se calcularán y almacenarán en la base de datos. f. sd: Permite crear scripts en JavaScript que utilicen y/o generen entradas de la base de datos. Crearemos varios para el cálculo y registro de los diversos KPIs que utilizaremos en el proyecto. g. sch: Nos lleva a la vista del planificador de Service Manager. Aquí podemos crear planificadores y añadirles tareas a realizar cada cierto tiempo (scripts a ejecutar). Utilizaremos un planificador para ejecutar de forma automática nuestros scripts calculadores de KPIs cada cierto tiempo, de manera que dichos indicadores siempre se mantengan actualizados. h. ws: Tras ejecutar este comando accedemos a la vista de servicios web (REST). Aquí podemos ver qué servicios están ya preconfigurados y listos para ser habilitados y sus propiedades y configuración. También podemos crear nuevos servicios. Utilizaremos este comando para configurar y exponer el acceso a determinadas tablas a través del API REST, además de añadir un nuevo servicio REST para el acceso a la tabla de KPIs que crearemos. Estudiamos también los flujos de estados (workflows) por los que pasan varios registros, en especial el de las incidencias, ya que necesitamos saber qué campos son necesarios para poder pasar de un estado a otro, y el nombre de los estados por los que deberemos pasar al utilizar el bot. Para comprender mejor el funcionamiento de los workflows, realizamos varias tareas con ellos, tales como modificar su flujo, añadir nuevos estados, modificar las condiciones para las transiciones etc. Una vez que ya hemos finalizado las tareas de instalación, configuración y estudio de Service Manager, podemos comenzar el desarrollo del bot objetivo del proyecto. 48 Durante la solicitud de la descripción para la incidencia, introducir la palabra “!exit” ¡exit El bot informa de que ha finalizado el caso de uso. RF010 Durante la solicitud del valor de impacto, introducir el valor “3” 3 El bot lo valida y pasa a pedir el valor de gravedad de la Incidencia. RF001 Durante la solicitud del valor de impacto, introducir el valor “1” 1 El bot informa de que no es válido, informa de los valores posibles, y vuelve a pedir un valor. RF007, RF008 Durante la solicitud del valor de impacto, introducir el valor “5” 5 El bot informa de que no es válido, informa de los valores posibles, y vuelve a pedir un valor. RF007, RF008 Durante la solicitud del valor de impacto, introducir el valor “h” H El bot informa de que no es válido, informa de los valores posibles, y vuelve a pedir un valor. RF007, RF008 Durante la solicitud del valor de impacto, introducir la palabra “!exit” ¡exit El bot informa de que ha finalizado el caso de uso y de que no se han realizado acciones. RF010 Durante la solicitud del valor de gravedad, introducir el valor “3” 3 El bot lo valida, pasa a crear y enviar la incidencia a Service Manager, e informa del fin de asistencia en el canal. RF004, RF008 Durante la solicitud del valor de gravedad, introducir el valor “1” 1 El bot informa de que no es válida, informa de los valores posibles, y vuelve a pedir un valor. RF007, RF008 Durante la solicitud del valor de gravedad, introducir el valor “5” 5 El bot informa de que no es válida, informa de los valores posibles, y vuelve a pedir un valor. RF007, RF008 Durante la solicitud del valor de gravedad, introducir el valor “h” H El bot informa de que no es válida, informa de los valores posibles, y vuelve a pedir un valor. RF007, RF008 Durante la solicitud del valor de gravedad, introducir la palabra “!exit” ¡exit El bot informa de que ha finalizado el caso de uso y de que no se han realizado acciones. RF010 Al finalizar el proceso, señalar que se quiere continuar modificando incidencias Yes Comienza el proceso de nuevo RF004, RF005, RF006, RF007 Al finalizar el proceso, señalar que no se quiere continuar modificando incidencias No El bot informa de que el caso de uso ha finalizado RF004, RF005, RF006, RF007 49 Al finalizar el proceso, enviar el comando “!exit” o cualquier cadena distinta de “yes” o “no” (o sus variantes en mayúsculas/minúsculas) ¡exit El bot informa de que la entrada no es válida y la vuelve a solicitar RF010 Mientras se está ejecutando el proceso, apagar el servidor de Service Manager <Tratar de continuar con el caso de uso> El bot informa de que se ha perdido la conexión con el servidor y finaliza el caso de uso RF010 Figura 35 - Batería de pruebas CU Modificar Incidencia 9.4Cierre de una incidencia. Acción Entrada Resultado esperado Relacionado con los requisitos Solicitar cierre de incidencia en el canal general. ¡closeIncident Se crea un canal y el bot informa de ello RF003, RF008, RF009 Durante la solicitud del identificador de la incidencia, enviar un identificador de incidencia existente IM10303 El bot lo valida y pasa a solicitar la solución del problema RF003, RF005, RF006, RF007 Durante la solicitud del identificador de la incidencia, enviar un identificador de incidencia no existente IM99999 El bot informa de que no existe una incidencia con ese identificador y finaliza el caso de uso. RF007 Durante la solicitud del identificador de la incidencia, enviar la palabra “!exit” ¡exit El bot informa de la finalización del caso de uso. RF010 Durante la solicitud del identificador de la incidencia, enviar la palabra “!exit” por el canal general ¡exit No ocurre nada en el canal creado para el caso de uso. RF010 Durante la solicitud de la solución de la incidencia, introducir una solución de 11 caracteres Solution 11 El sistema lo valida y pasa a solicitar el valor del código de cierre RF003, RF005, RF006, RF007 Durante la solicitud de la solución de la incidencia, introducir una solución de 10 caracteres Solution10 El sistema lo valida y pasa a solicitar el valor del código de cierre RF003, RF005, RF006, RF007 Durante la solicitud de la solución de la incidencia, introducir una solución de 9 caracteres Solution9 El sistema informa de que no es válido y lo vuelve a solicitar RF007 Durante la solicitud de la solución de la incidencia, enviar la palabra “!exit” ¡exit El bot informa de que ha finalizado el caso de uso RF010 Durante la solicitud del código de cierre de la incidencia, introducir un valor válido Cualquier valor de 0 a 12 (incluidos) El bot lo valida y pasa a cerrar la incidencia con los nuevos datos RF003, RF005, RF006, RF007 Durante la solicitud del código de cierre de la incidencia, introducir un valor no válido 13 El bot informa de ello y pasa a solicitar de nuevo el valor, imprimiendo la lista de posibles valores. RF007 50 Durante la solicitud del código de cierre de la incidencia, introducir el valor “!exit” ¡exit El bot informa de que ha finalizado el caso de uso RF010 Figura 36Batería de pruebas CU Cerrar Incidencia 9.5Consulta de uno o varios Indicadores Clave de Rendimiento (KPI) Acción Entrada Resultado esperado Relacionado con los requisitos Solicitar consulta de KPIs en el canal general. ¡getKpi Se crea un canal y el bot informa de ello RF011, RF008, RF009 Durante la solicitud de la lista de KPIs a obtener, enviar un valor válido 1,2,3,4,5,6 El bot valida la lista, obtiene los KPIs de Service Manager y los muestra por el chat RF011, RF008, RF009 Durante la solicitud de la lista de KPIs a obtener, enviar un asterisco * El bot valida la lista, obtiene todos los KPIs de Service Manager y los muestra por el chat RF011, RF008, RF009 Durante la solicitud de la lista de KPIs a obtener, enviar una lista válida con valores repetidos 1,2,3,2,3,3,5,4,7 El bot valida la lista, obtiene todos los KPIs de Service Manager y los muestra por el chat, eliminando duplicados. RF011, RF008, RF009 Durante la solicitud de la lista de KPIs a obtener, enviar un valor no válido 1,2,3,28 El bot informa de que algún valor no es correcto y vuelve a pedir la lista RF007 Tras obtener la lista de KPIs, indicar que queremos continuar solicitando KPIs yes El bot vuelve a solicitar la lista de KPIs a obtener, comenzando el caso de uso de nuevo RF011, RF008, RF009 Tras obtener la lista de KPIs, indicar que no queremos continuar solicitando KPIs no El bot informa de que ha finalizado el caso de uso RF011, RF008, RF009 Tras obtener la lista de KPIs, introducir un valor distinto de “yes” o “no” ¡exit El bot informa de que el valor no es válido y lo vuelve a solicitar RF007 Figura 37 - Batería de pruebas CU Consultar KPI 51 10Manual del programador A continuación se detallan varios aspectos que podrían resultar relevantes para un futuro desarrollo de un proyecto a partir del proyecto actual: En primer lugar, el sistema con el que se comunica el bot desarrollado (Service Manager) es un sistema propietario de Micro Focus, lo que implica que en caso de continuar el desarrollo de este proyecto será necesario obtener la licencia de dicho software. Este es otro de los motivos que ha llevado a que el proyecto se haya realizado utilizando el patrón MVC, ya que de esta manera si se desea desarrollar un bot de Discord para otro sistema similar, únicamente habría que modificar las llamadas al API REST en el controlador, pudiendo conservar el resto del código. Por otro lado, se ha intentado generalizar el código lo máximo posible, para permitir una mejor adaptación a otras plataformas. Por este motivo, el control de errores se ha realizado de forma muy estricta, de tal manera que se comprueban errores que en nuestro caso no pueden llegar a ocurrir debido a la manera en que se realiza el flujo de eventos de los casos de uso, lo que proporcionaría una reducción del tiempo de desarrollo en caso de que el proyecto se ampliase en el futuro. Además, el 100% del código se ha escrito en Python 3.6.8, de tal manera que las comunicaciones entre las diversas clases del sistema no conllevan la necesidad de usar adaptadores u otro software especial. Para la comunicación con el API REST de Service Manager se ha utilizado la librería “Request” [8], utilizando como formato de trasmisión de datos el formato Json [9], mientras que para la comunicación con Discord se ha utilizado la librería “DiscordPy” [7]. Los enlaces a la documentación oficial de ambas librerías se encuentran en el apartado 13Bibliografía/Referencias de este documento. Para finalizar, se indica que el proyecto actual se ha realizado dentro de un escenario académico, sin intención de uso real. Es por ello que no se ha añadido ningún tipo de “timeout” a los procesos realizables por el usuario, lo que en un uso real podría llevar a una sobrecarga de la memoria debido a varios procesos iniciados pero no completados. Posibles soluciones a este problema serían añadir el timeout mencionado, o bien asegurarnos de que se realiza un reinicio del sistema periódicamente para evitar el posible problema. 52 11Manual de usuario de las aplicaciones desarrolladas. A continuación se detalla un manual de usuario del bot de Discord desarrollado, en el que se explicarán las posibles tareas a realizar con el bot de manera no técnica. 11.1Obtener ayuda Si mandamos el comando ¡help a través del canal general, el bot nos responderá con un mensaje con las posibles acciones a realizar por parte de los usuarios. Figura 38 - Solicitar ayuda al bot de Discord 11.2Crear Incidencia Si enviamos el comando ¡newIncident a través del canal general, el bot creará un nuevo canal privado exclusivo para el usuario, informando de su creación y proporcionando un enlace a dicho canal. Figura 39 - Solicitar creación de nueva Incidencia En el nuevo canal se irán solicitando los datos de manera guiada, validando los datos según los introduce el usuario, de tal manera que se evita continuar con el caso de uso hasta no asegurar que los datos son correctos. 53 Figura 40 - Canal de Creacion de la Incidencia 11.3Modificar Incidencia Si enviamos el comando ¡updateIncident a través del canal general, el bot creará un nuevo canal privado exclusivo para el usuario, informando de su creación y proporcionando un enlace a dicho canal. Figura 41 - Solicitar modificación de una Incidencia En el nuevo canal se irán solicitando los datos de manera guiada, validando los datos según los introduce el usuario, de tal manera que se evita continuar con el caso de uso hasta no asegurar que los datos son correctos. 54 Figura 42 - Canal de modificación de la Incidencia No se expondrán el resto de casos de uso debido a que el proceso es similar a los descritos anteriormente. En todos los casos los procesos se iniciarán a través del canal general, lo que provocará la creación de un canal privado en el que el usuario pueda continuar el proceso de manera confidencial. 55 12Conclusiones Para finalizar con el documento, se resumirán las características del sistema desarrollado, así como los desafíos encontrados a lo largo del proyecto, y las posibles continuaciones que podría tener el proyecto. 12.1Características del proyecto  Se ha instalado y configurado una máquina virtual CentOs 8, incluyendo aspectos de cortafuegos, usuarios, bases de datos, servidores web e instalación de diversas aplicaciones mediante la terminal.  Se ha instalado y desplegado un servidor de Service Manager, y se ha aprendido a realizar acciones básicas de “customización” de la aplicación.  Se han creado diagramas de análisis y de diseño de la aplicación, con objetivo de tener un mayor conocimiento del sistema antes de desarrollarlo.  Se ha realizado una estimación de riesgos, costes y duración del proyecto para planificar correctamente el desarrollo del proyecto.  Se ha creado un bot en Python que se comunica con Service Manager a través de su API REST, y con el servidor de Discord definido en el fichero de configuración .env.  El bot diseñado se ha implementado aplicando el patrón MVC, obteniendo así un código fácilmente reutilizable.  Se ha hecho especial hincapié en la robustez del código para evitar fallos, añadiendo incluso comprobación redundante de errores para asegurar un correcto funcionamiento en caso de que el proyecto se amplíe en el futuro.  Se ha realizado una revisión de la calidad del código con objetivo de obtener métodos robustos, de un tamaño aceptable, y de baja complejidad.  Para finalizar, se ha realizado el presente documento para tratar explicar el proceso seguido a lo largo del proyecto. 12.2Futuras aplicaciones Entre las futuras aplicaciones que podría tener el proyecto, podría incluirse la de una integración real con Service Manager, permitiendo así a los usuarios una tercera forma de contacto con el servidor aparte de los dos clientes disponibles actualmente, o una ampliación de los servicios ofrecidos por el bot, aumentando su funcionalidad. Por otro lado, la modularidad del código permite su fácil adaptación a otras plataformas de chat, tales como Telegram, Facebook o Twitter, aumentando las posibles opciones de acceso a Service Manager. 56 13Bibliografía/Referencias [1] Repositorio del proyecto: https://github.com/jcgd2796/TFG_BotDiscord (fecha de última revisión: 14/06/2021). [2] Página oficial de CentOs: https://www.centos.org/download (fecha de última revisión: 12/05/2021) [3] Guía de instalación de PostgreSQL 12 en CentOs 8: https://www.digitalocean.com/community/tutorials/how-to-install-and-use-postgresql-on-centos8-es (fecha de última revisión: 13/05/2021) [4] Página oficial de Visual Studio Code: https://code.visualstudio.com/ (fecha de última revisión: 13/05/2021) [5] Guía de instalación de Service Manager: https://docs.microfocus.com/itom/Service_Manager:9.70/InstallSMServer (fecha de última revisión: 13/05/2021) [6] Página principal de Python 3.6.8: https://www.python.org/downloads/release/python-368/ (fecha de última revisión: 13/05/2021) [7] Documentación del API DiscordPy: https://discordpy.readthedocs.io/en/latest/api.html# (fecha de última revisión: 13/05/2021) [8] Guía de uso de la librería request: https://realpython.com/python-requests/ (fecha de última revisión: 13/05/2021) [9] Guía de uso de la librería json: https://docs.python.org/3/library/json.html (fecha de última revisión: 13/05/2021)