Mejora de gestión de servicios de TI a través de ITIL y la tecnología blockchain

Mejora de Gestión de Servicios de TI a través de ITIL y la Tecnología Blockchain Improving IT Service Management using ITIL and Blockchain Technology Trabajo Fin de Grado Curso 2021-2022 José Andrés Velasco Santos Yule Zhang Dirigido Por: María Cruz Valiente Blázquez Grado en Ingeniería del Software Facultad de Informática Universidad Complutense de Madrid 1 2 Mejora de Gestión de Servicios de TI a través de ITIL y la Tecnología Blockchain Improving IT Service Management using ITIL and Blockchain Technology Trabajo de Fin de Grado en Ingeniería del Software Departamento de Ing. Software e Inteligencia Artificial José Andrés Velasco Santos Yule Zhang Dirigido Por: María Cruz Valiente Blázquez Convocatoria: Junio 2022 Grado en Ingeniería del Software Facultad de Informática Universidad Complutense de Madrid 30 de mayo de 2022 3 4 Agradecimientos En primer lugar, queremos agradecer profundamente a nuestra directora del proyecto, Maricruz, por la propuesta que hizo para este proyecto, por las constantes ayudas que recibimos de su parte durante todo el curso, por mandarnos artículos de interés y contactos de diferentes personas, también por dedicar tiempo a reunirse con nosotros periódicamente para dar seguimiento al proyecto. Sus directrices e indicaciones nos han ayudado muchísimo para avanzar con el trabajo, sin ella es imposible llegar hasta dónde estamos ahora. Además, queremos agradecer a nuestras familias, parejas y amigos, por su apoyo y ánimo constante. 5 6 Resumen Mejora de Gestión de Servicios de TI a través de ITIL y la tecnología Blockchain Siendo la clave para mejorar la calidad del servicio de TI en una empresa, ITIL es una guía de buenas prácticas para la gestión de servicios de TI y abarca toda la infraestructura, el desarrollo y las operaciones de TI. Blockchain constituye una tecnología segura y transparente que utiliza la descentralización y el hashing criptográfico para aplicaciones en el mundo real. Puede ayudar a cada persona a tomar el control total de cada movimiento que realiza de la manera más segura posible. En este proyecto se propone trabajar en una solución para mejorar la gestión de servicios de TI para empresas utilizando SLA, el aspecto más fundamental de ITIL, y la tecnología Blockchain. Palabras clave: TI, Gestión de Servicios, ITIL, Blockchain, SLA 7 8 Abstract Improving IT Service Management using ITIL and Blockchain technology Being the key to improve the quality of IT service in a company, ITIL is a guide of good practices for IT service management and covers all IT infrastructure, development and operations. The Blockchain is the most secure and transparent technology by using decentralization and cryptographic hashing in today’s world. It can help every person take total control of every single move that he makes in the safest way possible. In this project we propose to work for a solution to improve IT service management for companies using SLA, the most fundamental aspect of ITIL, and Blockchain technology. Keywords: IT, Service Management, ITIL, Blockchain, SLA 9 Capítulo 1 - Introducción 1.1. Motivación Hoy en día, la necesidad del departamento de la Tecnología de la Información (TI) sigue creciendo, y lo está mostrando de una forma innovadora. Como afirma el artículo ¿Hace falta un departamento de informática? Pues, depende[3], en la actualidad, se está viendo el impacto del departamento de TI en el resto de los departamentos. “Algunas de estas cosas ya están pasando y, en muchas organizaciones los que más saben de Salesforce están en los departamentos de ventas, los que más saben de SAP están en finanzas o los que saben de las herramientas de datos están en todas partes en modo de autoservicio. Algunos departamentos de ‘innovación’ o de investigación y desarrollo están llenos de informáticos, afortunadamente.“ Por lo que se puede ver que la TI ya no solo constituye una parte importante en una empresa, sino que cada vez se está haciendo más imprescindible. Además, a raíz de la pandemia de la COVID-19 y la nueva ola de teletrabajo, la transformación digital en las empresas en el área de TI se ha acelerado de manera muy significativa, produciéndose cada vez mayor demanda de servicios. Por otro lado, debido a la crisis sanitaria y económica que se está viviendo, se están cerrando muchas empresas en el mercado. Se puede ver en la siguiente noticia El tejido productivo no se recupera: España tiene hoy 77.831 empresas menos que antes de la pandemia[4] del periódico El Mundo: “No todas las empresas que tuvieron que bajar la persiana en España por la crisis de la pandemia, han podido volver a subirla. De hecho, a cierre de 2021 el país cuenta con 1.411.902 empresas dadas de alta en la Seguridad Social, frente a las 1.489.733 que tenía en febrero de 2020 antes de que irrumpiera con fuerza la pandemia.” En este sentido, los entornos empresariales son cada vez más competitivos y las expectativas de la alta dirección son cada vez más ambiciosas en lo que respecta a los servicios de TI, tanto a nivel interno como externo (es decir, servicios que desea ofrecer a sus clientes). La Biblioteca de Infraestructura de Tecnologías de Información (del inglés Information Technology Infrastructure Library, ITIL) puede ayudar a las empresas a cumplir sus objetivos 16 ofreciendo unos servicios de TI con mayor calidad. ITIL ha sido reconocida internacionalmente como guía de buenas prácticas para la gestión de servicios de TI y es utilizada por cientos de organizaciones a nivel mundial demostrando su eficacia. La adopción de los procesos de ITIL se hace necesaria para poder obtener servicios TI con calidad y una alineación con el negocio en las empresas, ya que los directivos de las empresas esperan que las necesidades de la organización se conviertan en soluciones, y que TI no constituya un freno al negocio, como suele ocurrir en ciertas ocasiones. Por otro lado, los servicios descentralizados basados en la tecnología Blockchain, aunque todavía no son lo suficientemente maduros, están demostrando su gran potencial en la Industria gracias a la seguridad en su infraestructura, su transparencia y su trazabilidad. Es por ello, que en este proyecto se pretende hacer uso de ITIL en combinación con la tecnología Blockchain, a través de la implementación de contratos inteligentes (del inglés smart contracts), para que distintas organizaciones, independientemente de su tamaño y condición, puedan gestionar los Acuerdos de Nivel de Servicio (del inglés Service Level Agreements, SLAs) con sus clientes de una manera transparente, segura y descentralizada asegurando la calidad de la gestión del servicio. Cabe destacar que en el momento de la escritura de este proyecto no se ha encontrado ningún trabajo que vincule ITIL con la tecnología Blockchain para obtener los beneficios que pueden ofrecer la fusión de estos dos dominios. 1.2. Objetivos El objetivo principal de este proyecto es la creación de un sistema descentralizado basado en la tecnología Blockchain (conocido como Web3 ), que favorezca la gestión de los SLAs que se 1 establecen entre los proveedores de servicios de TI y sus clientes siguiendo las buenas prácticas de ITIL. A partir de este objetivo principal, se establecen los siguientes objetivos específicos: ● Implementar el sistema a través de una interfaz que sea lo más intuitiva, cómoda y accesible posible. Para que, de esta manera, el sistema pueda llegar al máximo público. 1https://www.gartner.es/es/articulos/que-es-la-web3 17 ● Establecer y mejorar la relación y comunicación entre proveedores de servicios de TI y los clientes de manera segura y transparente a partir de los SLAs. ● Garantizar que tanto los proveedores de servicios de TI como los clientes tengan una expectativa clara y sin ambigüedades del nivel de servicio que se va a contratar. ● Facilitar la contratación y monitorización de los servicios de TI por parte de los clientes a través de las transacciones registradas en Blockchain, mediante la implementación de contratos inteligentes gestionados con monederos digitales. ● Favorecer la medición y revisión de los niveles de servicio contratados mediante la implementación de un cuadro de mando (del inglés dashboard) que recupere los datos de contratos inteligente registrados en Blockchain, y muestre los principales Indicadores Clave de Rendimiento (del inglés Key Performance Indicators, KPIs) vinculados a los SLAs. ● Adquirir nuevos conocimientos en estándares y tecnologías punteras que permitan afrontar con mayor garantía de éxito la vida profesional como graduados universitarios informáticos. 1.3. Plan de trabajo En la Figura 1.1 se describen las fases del proyecto y el tiempo dedicado para cada una de ellas: Figura 1.1 Cronograma de trabajo Se resumen las respectivas fases del plan de trabajo a continuación: 1. Primera Toma de Contacto: Esta ha sido la primera fase realizada en este proyecto, que ha consistido en tener una visión inicial sobre el proyecto, definir los objetivos del mismo y conocer las tecnologías que se van a utilizar. 18 2. Investigaciones: Durante esta fase, se han realizado investigaciones sobre las diferentes tecnologías, términos y posibles implementaciones de funcionalidades del sistema objetivo. El resultado de esta fase está reflejado en el Capítulo 2 Estado de la cuestión de este documento. 3. Desarrollo Sistema: Esta fase se ha enfocado en el desarrollo del sistema, tanto en lo que respecta a la parte del front-end como del back-end. Las tecnologías utilizadas para su implementación se mencionan en el Capítulo 3 Tecnologías utilizadas. 4. Dashboard: En esta fase se ha desarrollado un dashboard intuitivo que permite visualizar la información clave relativa a los SLAs mediante la aplicación de ciertos KPIs. 5. Pasos Finales: Los pasos finales del proyecto se han centrado principalmente en completar la memoria, así como en mejorar pequeños aspectos del sistema implementado. 1.4. Estructura de la memoria El resto de la memoria está estructurada de la siguiente manera: Capítulo 2 Estado de la cuestión: Este capítulo contempla todos los conocimientos importantes que se requieren para la realización del sistema. Para ello, por un lado, se explica ITIL y su aspecto más fundamental de cara al ámbito de este proyecto, los SLAs. Por otro lado, en este capítulo se introduce la tecnología Blockchain, así como sus términos principales. Capítulo 3 Tecnologías utilizadas: En este capítulo se presentan todas las tecnologías que se han utilizado para este Trabajo Fin de Grado (TFG). Capítulo 4 Sistema descentralizado basado en Blockchain que almacena SLAs, SLink: En este capítulo se presenta en detalle el sistema desarrollado en este trabajo. Capítulo 5 Trabajo individual: En este capítulo se detalla el trabajo realizado por cada uno de los autores del presente proyecto. Capítulo 6 Conclusiones y trabajo futuro: En este capítulo se describen las conclusiones extraídas del proyecto, así como las futuras líneas de investigación si se continuará el desarrollo. 19 Chapter 1 - Introduction 1.1. Motivation Nowadays, the need for the Information Technology (IT) department continues increasing, and it is showing in an innovative way. As stated in the article Is an IT department necessary? Well, it depends [3], at present, the impact of the IT department is being seen in the rest of the departments. “Some of these things are already happening and, in many organizations those who know the most about Salesforce are in the sales departments, those who know the most about SAP are in finance, or those who know the data tools are everywhere in self-service mode. Fortunately, some ‘innovation’ or research and development departments are full of computer scientists.“ It can be seen that IT is not only an important part of a company, but is becoming more and more essential. In addition, as a result of the COVID-19 pandemic and the new wave of teleworking, the digital transformation in companies in the IT area has accelerated very significantly, producing an increasing demand for services. On the other hand, due to the current health and economic crisis, many companies in the market are closing. It can be seen in the following news The productive fabric is not recovering: Spain today has 77,831 fewer companies than before the pandemic[4] from the newspaper El Mundo: “Not all the companies that had to lower the blind in Spain due to the pandemic crisis, have been able to raise it again. In fact, at the end of 2021 the country had 1,411,902 companies registered with Social Security, compared to the 1,489,733 it had in February 2020 before the pandemic broke out with force.” In this sense, business environments are increasingly competitive and the expectations of senior management are increasingly ambitious regarding IT services, both internally and externally (that is, services that they want to offer to their customers). The Information Technology Infrastructure Library (ITIL) can help companies meet their goals by providing IT services with higher quality. ITIL has been internationally recognized as a best 20 practice guide for IT service management and is used by hundreds of organizations worldwide, proving its effectiveness. The adoption of ITIL processes is necessary in order to obtain IT services with quality and alignment with the business in companies, since company managers expect that the needs of the organization become solutions, and that IT does not constitute a brake on business, as often happens on certain occasions. On the other hand, decentralized services based on Blockchain technology, although they are not yet mature enough, are showing their great potential in the Industry thanks to the security of their infrastructure, transparency and traceability. For this reason, this project intends to make use of ITIL in combination with Blockchain technology, through the implementation of smart contracts, so that different organizations, regardless of their size and condition, can manage Service Level Agreements (SLAs) with their clients in a transparent, secure and decentralized way, ensuring the quality of service management. It should be noted that at the time of writing this project, no work has been found linking ITIL with Blockchain technology to obtain the benefits from the merger of these two domains. 1.2. Objectives The main objective of this project is the creation of a decentralized system based on Blockchain technology (known as Web3 ), which favors the management of SLAs established between IT 2 service providers and their clients following good practices of ITIL. As of this main objective, the following specific objectives are established: ● Implement the system through an interface that is as intuitive, comfortable and accessible as possible. So that, in this way, the system can reach the maximum public. ● Establish and improve the relationship and communication between IT service providers and customers in a secure and transparent way by means of SLAs. ● Ensure that both IT service providers and customers have a clear and unambiguous expectation of the service level to be contracted. 2https://hbr.org/2022/05/what-is-web3 21 ● Facilitate the hiring and monitoring of IT services by customers via transactions recorded in Blockchain, by means of the implementation of smart contracts managed with digital wallets. ● Promote the measurement and review of contracted service levels by implementing a dashboard that retrieves data from smart contracts registered in Blockchain, and displays the main Key Performance Indicators (KPIs) linked to SLAs. ● Acquire new knowledge in standards and cutting-edge technologies that allow to face the professional life for computer science graduates with a greater guarantee of success. 1.3. Workplan The Figure 1.1 describes the phases of the project and the time dedicated to each of them: Figure 1.1 Work schedule The respective phases of the work plan are summarized below: 1. First Contact: This has been the first phase carried out in this project, which consists of having an initial vision of the project, defining its objectives and learning the technologies that are going to be used. 2. Investigations: During this phase, investigations on the different technologies, terms and possible implementations of functionalities of the target system have been carried out. The result of this phase is reflected in Capítulo 2 Estado de la cuestión of this document. 3. System Development: This phase has focused on the development of the system, both in terms of the front-end and the back-end. The technologies used for its implementation are mentioned in Capítulo 3 Tecnologías utilizadas. 22 4. Dashboard: In this phase, an intuitive dashboard that allows visualizing the key information related to the SLAs through the application of certain KPIs has been developed. 5. Final Steps: The final steps of the project have focused mainly on completing the memory, as well as improving small aspects of the implemented system. 1.4. Memory structure The rest of the memory is structured as the follow way: Capítulo 2 Estado de la cuestión: This chapter covers all the important knowledge required to implement the system. To do this, on the one hand, it explains ITIL and its most fundamental aspect for the scope of this project, which are the SLAs. On the other hand, it introduces Blockchain technology, as well as its main terms. Capítulo 3 Tecnologías utilizadas: This chapter presents all the technologies that have been used for this Final Degree Project (FDP). Capítulo 4 Sistema descentralizado basado en Blockchain que almacena SLAs, SLink: This chapter presents in detail the system developed in this project. Capítulo 5 Trabajo individual: This chapter details the work carried out by each of the authors of this project. Chapter 6 Conclusions and future work: This chapter describes the conclusions drawn from the project, as well as future lines of research if its development continues. 23 Capítulo 2 - Estado de la cuestión Como ya se ha comentado anteriormente en el presente documento, el objetivo principal de este proyecto es la creación de un sistema descentralizado basado en la tecnología Blockchain que facilite la gestión de SLAs entre clientes y proveedores de servicios de TI. Por tanto, en este capítulo, por un lado, para la parte de gestión de servicios de TI, se realiza una introducción de los conceptos de ITIL; y por otro lado, para la parte de descentralización, se detalla la tecnología Blockchain. 2.1. Introducción al ITIL 2.1.1. ¿Qué es ITIL? Como ya se ha explicado anteriormente en la sección 1.1. Motivación, ITIL se corresponde con las siglas en inglés de Information Technology Infrastructure Library. ITIL abarca toda la infraestructura, desarrollo y operaciones de TI, y constituye el estándar de facto para la gestión de servicio de TI en las organizaciones. 2.1.2. ¿Cómo funciona ITIL? El ciclo de vida del servicio en ITIL consta de las siguientes fases según el libro Fundamentos de la Gestión de Servicios de TI basada en ITIL[2]: 1. Estrategia de servicio: Facilita a las organizaciones a establecer metas y estrategias para cumplir los requisitos y prioridades de los clientes. 2. Diseño del servicio: Ayuda al diseño de los procesos y funciones e incluye el diseño de la tecnología, la infraestructura y los productos de la gestión del servicio de TI. 3. Transición del servicio: Se pretende encontrar un nuevo cambio organizacional a la vez que se mantienen los servicios actuales para tener una opción B de cara a los riesgos. 4. Operación del servicio: Garantiza que las tareas operacionales diarias no se interrumpan con el fin de generar valor para los clientes y los proveedores de los servicios. 5. Mejora continua de los servicios: Se centra en la mejora continua de los procesos. 24 Las empresas pueden adoptar algunas de estas etapas, siempre y cuando sean adecuadas para la organización. Esto hace que ITIL sea flexible y pueda adaptarse según las distintas circunstancias. La Figura 2.1 muestra la visión del ciclo de vida del Servicio de acuerdo a ITIL. Figura 2.1 Ciclo de vida del Servicio3 2.1.3. Diseño de servicio de ITIL Dentro de la etapa de diseño de servicio de ITIL se obtienen múltiples procesos (según el libro Fundamentos de la Gestión de Servicios de TI basada en ITIL[2]: ● Gestión del catálogo de servicio ● Gestión del nivel de servicio ● Gestión de la capacidad ● Gestión de la disponibilidad ● Gestión de la continuidad ITSCM (Gestión de Continuidad del Servicio de TI) ● Gestión de la seguridad de la información ● Gestión de suministradores 3https://consultora-impresa.jimdofree.com/m%C3%A9todos/frameworks/itil/ 25 Sin embargo, las aplicaciones de Web3 son totalmente distintas: 1. No tienen una base de datos centralizada para almacenar datos de la aplicación, y tampoco disponen de un servidor web donde se incluye la lógica del back-end. 2. Hay proveedores de servicio que permiten la conexión entre el cliente (front-end) a la Blockchain (MetaMask, por ejemplo) pero se necesita la firma del cliente utilizando su propia clave privada. 3. Se permite recuperar datos de la Blockchain utilizando The Graph (ver la sección 3.13. The Graph para conocer en detalle The Graph). Finalmente, la estructura de aplicaciones de Web3 es la siguiente: Figura 2.5 Estructura de aplicaciones de Web27 7https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application 32 2.2.2. Conceptos importantes dentro de la Blockchain ●Prueba de trabajo La prueba de trabajo (del inglés Proof of Work, PoW), como indican en el libro Mastering Ethereum: building smart contracts and DApps[13], “Es una pieza de datos (la prueba) que requiere un cálculo significativo para encontrar”. Se trata del protocolo de consenso más conocido que consiste en que las partes de una red realicen con éxito un trabajo computacionalmente costoso para acceder a los recursos de dicha red. Esto provoca ineficiencia, pues existen alternativas como la prueba de participación que consiguen lo mismo de manera más eficiente. ●Prueba de participación La prueba de participación (del inglés Proof of Stake, PoS), es un protocolo de consenso que reemplaza al protocolo del punto anterior aportando seguridad, escalabilidad a la red y mayor eficiencia. Existen unos participantes de la red llamados validadores que acceden a los recursos de dicha red a cambio de tener bloqueada una cierta cantidad de criptomonedas. Se comenta en el libro Mastering Ethereum: building smart contracts and DApps[13]: “PoS pide a los usuarios que demuestren la propiedad de una cierta cantidad de criptomoneda (su ‘participación’ en la red) para poder participar en la validación de las transacciones.” No requiere trabajos computacionalmente costosos, por lo que es más eficiente que la prueba de trabajo. ●Criptomonedas Como monedas físicas se usan para facilitar transacciones financieras, las criptomonedas hacen la misma función pero siendo digitales, se usan tanto para transacciones financieras como contratos inteligentes en Internet de manera descentralizada, utilizando criptografía y programaciones avanzadas. ●Monedero digital A diferencia del monedero físico, el monedero digital no contiene criptomonedas, sino usa las claves criptográficas necesarias para acceder a las criptomonedas en la red 33 correspondiente. Esto significa que el monedero digital es más bien una llave electrónica que permite las acciones de comprar, vender y mantener las criptomonedas de forma segura y accesible. En este proyecto se ha utilizado MetaMask como el monedero digital, ya que es muy 8 potente y dispone de extensión de Chrome . 9 ●Token Se llama token a una unidad de valor basada en Blockchain y emitida por un contrato inteligente. Un token no es una criptomoneda, aunque muchas veces se confunden estos dos términos pensando que son lo mismo. Los tokens sirven para múltiples usos como el pago de comisiones dentro de una aplicación descentralizada basada en Blockchain o para votar propuesta en una aplicación descentralizada autónoma. ●Contrato inteligente Como indican en el capítulo 2 del libro Blockchain: blueprint for a new economy[11], “En el contexto de la Blockchain, los contratos inteligentes significan transacciones de cadena de bloques que van más allá de las simples transacciones de compra/venta de divisas y pueden tener instrucciones más detalladas integradas.” Para entender qué es el contrato inteligente, se recuerda lo que es un contrato, según el capítulo 2 del libro Blockchain: blueprint for a new economy[11]: “Un contrato en el sentido tradicional es un acuerdo entre dos o más partes para hacer o no hacer algo a cambio de otra cosa.” Los contratos hasta ahora han sido documentos escritos, que requieren muchos costes, tiempo y terceros que intervienen en el proceso. Lo peor, los contenidos de estos contratos pueden estar mal interpretados. En cambio, los contratos inteligentes son unos “scripts” (códigos informáticos) escritos con lenguajes de programación que se pueden ejecutar automáticamente. Por lo cual, se puede evitar el lastre de la interpretación al no ser escrito en los lenguajes que hablamos. 9https://www.google.com/intl/es_es/chrome/ 8https://metamask.io/ 34 Además, el contrato inteligente se puede crear por personas físicas y jurídicas, o por máquinas y programas, y su contenido es visible por todos y que no se puede cambiar al existir sobre la tecnología blockchain. Esto le confiere un carácter descentralizado, inmutable y transparente. 2.2.3. Ventajas de la Blockchain Las principales ventajas de la Blockchain son: ●Descentralización: Al realizar la aprobación de transacciones de forma descentralizada, se evita un poder centralizado que tome decisiones que afectan al resto y consigue una mayor democracia entre los integrantes de la red. ●Inmutabilidad: Como indican en el documento The Advantages and Disadvantages of the Blockchain Technology[14]: “Lo inmutable se logra en las transacciones acordadas y compartidas a través de Blockchain. Cuando la transacción se conecta a Blockchain, no es posible cambiarla o eliminarla.” Si bien puede ser vista como desventaja ante errores que podrían no ser subsanados, la inmutabilidad que ofrece Blockchain permite que las transacciones se lleven a cabo sin alteración posible. ●Transparencia: Una Blockchain pública como Ethereum, permite ver todas sus transacciones realizadas de forma pública, lo cual posibilita la trazabilidad pero siempre de forma anónima. ●Red distribuida: Nadie es propietario de la red y todos los integrantes de la red guardan la misma copia de datos de la red, por lo que si un integrante sufre un percance, no existiría ningún problema a diferencia de un sistema no distribuido. ●Bajos costes para usuarios: Las transacciones, por lo general, conllevan un coste mucho mejor que en la banca tradicional. ●Rapidez: Las transacciones en la Blockchain tardan muy poco en comparación a la banca tradicional. ●Seguridad: Como indican en el libro Blockchain: blueprint for a new economy[11]: “Una de las principales ventajas es que Blockchain es una tecnología de empujar (el usuario inicia y envía información relevante al red solo para esta transacción), 35 no es una tecnología de tirar (como para una tarjeta de crédito o banco, la información personal del usuario está archivada para ser extraída cada vez que se autorice).” De esta manera, se evita que los datos del usuario estén archivados en varios sitios y garantiza la mayor seguridad. 2.2.4. Desventajas de la Blockchain Las principales desventajas de la Blockchain son: ●Alto consumo de energía: Como indican en el documento The Advantages and Disadvantages of the Blockchain Technology[14],“La principal desventaja de Blockchain es el alto consumo de energía.” Algunas redes Blockchain utilizan el protocolo de consenso prueba de trabajo, el cual consume demasiada energía. Ethereum planea cambiar este por el protocolo de consenso prueba de participación, que al tener un consumo ya razonable, provocaría que dejara de existir esta desventaja. ● Sin copia de seguridad: Como indican en la introducción del libro Blockchain: blueprint for a new economy[11], si un usuario pierde su clave privada para acceder a la Blockchain, no hay manera para recuperar su cuenta y dinero. 36 Capítulo 3 - Tecnologías utilizadas 3.1. Javascript Javascript es un lenguaje de programación que se utiliza como complemento de HTML y CSS 10 para crear páginas web debido a su integración nativa en los navegadores (lenguaje interpretado sin necesidad de compilación). También es utilizado en la actualidad por muchos marcos de trabajo (del inglés frameworks) que permiten el desarrollo de aplicaciones de diferentes tipos. En este proyecto, se trata del lenguaje utilizado tanto en front-end como en back-end. 3.2. React Como indican en el libro Learning React: Functional Web Development with React and Redux[9]: “React es una biblioteca popular utilizada para crear interfaces de usuario.” React11 es un framework bajo entorno Node.js (entorno de ejecución para aplicaciones JavaScript) que utiliza el lenguaje Javascript para ayudar a crear front-end interactivas de forma sencilla. Se encarga de actualizar y renderizar los componentes de la página web de manera eficiente. Se trata del framework utilizado en este proyecto para el front-end. 3.3. GitHub Github es una forja para proyectos software utilizando si sistema de control de versiones GIT 12 13 . Es muy conocida por los desarrolladores y utilizada por los autores de este proyecto durante el estudio de la carrera. Se ha utilizado en este proyecto tanto para alojar el código del front-end como del back-end. 13 https://git-scm.com/ 12 https://github.com/ 11 https://es.reactjs.org/ 10 https://developer.mozilla.org/es/docs/Web/JavaScript 37 3.4. WebStorm WebStorm es un entorno de desarrollo integrado (de inglés Integrated Development 14 Environment, IDE) para JavaScript y tecnologías relacionadas (ver la Figura 3.1). Como indican en su página oficial: “WebStorm es el IDE más inteligente para JavaScript”. Tiene una interfaz muy intuitiva y hace que el proceso de desarrollo sea más agradable y organizado. Es el IDE elegido para el desarrollo de este proyecto. Figura 3.1 WebStorm 3.5. Postman Postman es una aplicación que ejerce de cliente HTTP para permitir testear peticiones HTTP 15 request (del inglés, HTTP request) a través de una interfaz gráfica de usuario. Es una herramienta utilizada en el proyecto para el desarrollo de la Interfaz de Programación de Aplicaciones (del inglés Application Programming Interface, API) con back-end y The Graph. 15 https://www.postman.com/ 14 https://www.jetbrains.com/es-es/webstorm/ 38 En la Figura 3.2 se muestra cómo realizar la petición de obtención de clientes a través de Postman, en la sección 4.5.3. API REST se explicarán todas las peticiones HTTP realizadas en el back-end de este proyecto. Figura 3.2 Postman 3.6. Ethereum 3.6.1. ¿Qué es Ethereum? Ethereum es una plataforma digital que adopta la tecnología Blockchain y expande su uso a 16 una gran variedad de aplicaciones. A día de hoy, se trata de la red Blockchain con contratos inteligentes donde más desarrollo existe, a pesar de sus altas comisiones y lentitud de transacciones en la actualidad frente a otras redes Blockchain. Prueba de ello, es su capitalización de mercado, la mayor de todas las redes Blockchain después de Bitcoin. 16 https://ethereum.org/en/whitepaper/ 39 3.6.2. ¿Cómo funciona Ethereum? En la red de Ethereum, existe un ordenador único y canónico (llamado máquina virtual de Ethereum o EVM), cuyo estado han acordado todos los participantes de la red. Cada usuario (nodo) de la red de Ethereum mantiene una copia del estado de EVM, y cuando un usuario quiere emitir una solicitud de transacción (un cambio de estado en la EVM), todos los demás la verifican, validan. El estado actual de la EVM se almacena en la Blockchain que, a su vez, almacenan y acuerdan todos los usuarios. De esta forma, se garantiza la protección en la red Ethereum al máximo. Al igual que Bitcoin (la red Blockchain pionera), se trata de una red Blockchain con protocolo de consenso prueba de trabajo (explicado en la sección 2.2.2. Conceptos importantes dentro de la Blockchain) lo que implica un gasto energético superior a otras redes Blockchain que utilizan el protocolo de consenso prueba de participación (explicado al principio de este apartado). También implica un gasto en comisiones superior por la misma razón. Aún así, se trata de la red Blockchain más utilizada para desarrollo de aplicaciones de propósito general, siendo prueba de ello la capitalización de mercado actual de Ethereum y la cantidad de proyectos relacionados. La criptomoneda utilizada en esta red es el Ether (ETH), utilizada tanto para pagar las transacciones como para envío de dinero entre direcciones. Por otro lado, mientras que Bitcoin es la red pionera de Blockchain con el objetivo de ser un sistema de pagos financieros, Ethereum tiene el objetivo de crear aplicaciones de propósito general, existiendo ya muchas de ellas. 3.6.3. Transacciones en Ethereum Como indican en Ethereum White Paper[7], una transacción en Ethereum es “un paquete de datos firmado que almacena un mensaje que se enviará desde una cuenta de propiedad externa”. Las transacciones contienen: 1. El destinatario de mensaje 2. Una firma que identifique al remitente 3. La cantidad de ETH a transferir del remitente al destinatario 4. Datos opcionales 40 5. Un valor STARTGAS, que representa el número máximo de pasos computacionales que la ejecución de la transacción puede tomar. 6. Un valor de GASPRICE, que representa la tarifa que paga el remitente por paso computacional. 3.6.4. Estructura de Ethereum Ethereum se puede dividir por niveles : 17 1. Máquina virtual de Ethereum: Entorno para contratos inteligentes en Ethereum. 2. Contratos inteligentes: Programas ejecutables en la red Blockchain de Ethereum. 3. Nodos de Ethereum: Conocidos como mineros, forman la red Blockchain, validan transacciones y permiten interactuar con la red. 4. APIs de clientes Ethereum: Librerías y aplicaciones que se comunican con la red de Ethereum. 5. Aplicaciones de usuario final. Es la red utiliza el proyecto para almacenar y recuperar SLAs en la Blockchain. 3.7. Remix Remix es un entorno de desarrollo de Ethereum para compilar y desplegar contratos 18 inteligentes a la Blockchain. Es el IDE que se utiliza para realizar pruebas de contratos inteligentes y desplegarlos en entorno real en el proyecto. La Figura 3.3 muestra un ejemplo de despliegue en Remix. Se puede conocer más sobre el despliegue en Remix en este proyecto en la sección 4.6.1. Despliegue del contrato inteligente. 18 https://remix-project.org/ 17 https://ethereum.org/en/developers/docs/ethereum-stack/ 41 4.3. Front-end En esta sección se expondrán todas las tecnologías y funcionalidades que se pueden observar en el front-end del sistema SLink. 4.3.1. Página principal En la Figura 4.2 se puede observar la página principal del sistema SLink, que consta de un diagrama giratorio de 360 grados con nodos y líneas azules en el fondo, cada nodo está conectado a través de las líneas con el resto. De esta manera, se asimila a la red de Blockchain, donde cada nodo tiene el mismo registro de datos que el resto de nodos. En la parte superior de la página está el nombre del sistema, SLink, y la licencia elegida para este sistema (ver la sección 4.7.1. Licencia para conocer más detalle sobre la licencia). Se ha aplicado un efecto de teclado a la frase “Abrir tu SLA AHORA, Abrir tu SLA en BlockChain” en color blanco, situada debajo del diagrama giratorio para que la interfaz sea más intuitiva y llamativa. Se disponen de dos botones en la parte inferior de la página, si lo que se quiere es enviar y registrar un SLA, al cliquear el botón izquierdo, se llevará a la página de SLA (ver la sección 4.3.2. Página de SLA y elementos de SLA en SLink). Y si lo que se quiere es conocer sobre SLink y enviar consulta al sistema, al cliquear el derecho, se llevará a la página de información y contactos (ver la sección 4.3.9. Página de Conocernos). 48 Figura 4.2 Página principal 4.3.2. Página de SLA y elementos de SLA en SLink Antes de conocer la página de SLA, se procede a explicar primero los elementos de SLA aplicados para el sistema SLink, se verán estos elementos en la página de SLA. Anteriormente, en la sección 2.1.5. Introducción a los SLAs, se hablaba de los elementos que pueden tener los SLAs, y en este sentido, hay que tener cuenta de que los elementos de los SLAs se podrían y se deberían modificar según las necesidades y funcionalidades de cada organización. En este caso SLink siendo un sistema creado con el fin de estudio para un Trabajo Fin de Grado (TFG), se ha adaptado una versión estándar incluyendo los elementos más relevantes y comunes de un SLA (ver la Tabla 4.1 para conocer más en detalle). Atributos Contenido Partes contratantes Datos de los participantes en el acuerdo: cliente (Dirección Ethereum, DNI, nombre y apellidos, sexo, email, teléfono, nombre de empresa, dirección de empresa, código fiscal de empresa), proveedor (nombre de empresa, dirección de empresa, código fiscal de empresa). Duración del SLA Periodo de vigencia del acuerdo según las partes contratantes (fecha de inicio y fin). 49 Atributos Contenido Servicios cubiertos Servicios prestados por el proveedor al cliente. Horario de servicio Horarios en los que se prestará el servicio (hora de inicio y fin). Licencias Posibles licencias que se necesitarán durante el curso de servicio. Niveles de servicio Parámetros bajo los que se prestará el servicio. Facturación Periodos y métodos de facturación. Tabla 4.1 Elementos de SLA en SLink La página de SLA se trata de un formulario donde se recogen los datos que se indican en la Tabla 4.1. Por motivos de seguridad, para poder visualizar correctamente dicha página, se necesita que el cliente ya se haya dado de alta en el sistema junto con su dirección Ethereum. La manera de darse de alta en el sistema es a través de hacer clic en el botón “Conocenos” en la página principal (ver la Figura 4.2) o el link “contacte con nosotros” en la Figura 4.3, en ambos casos se llegará a la página de información y contactos (ver la sección 4.3.9. Página de Conocernos) para poder contactar con nosotros. Si una persona no es cliente del sistema, es decir, después de conectar con su monedero digital (ver la sección 4.3.3. Conectar con el monedero digital para conocer más detalle sobre cómo conectar con el monedero digital), aparece que la dirección de Ethereum no está registrada en el sistema, se verá la pantalla que se muestra en la Figura 4.3 con la información mostrada en la Figura 4.4. 50 Figura 4.3 Página de SLA (visitante) 51 Figura 4.4 Información de error (visitante) En cambio, si una persona es cliente del sistema, se verán las pantallas mostradas en la Figura 4.5 y la Figura 4.6) organizadas en forma de formulario. Este formulario tiene 3 partes separadas que abarcan toda la información indicada en Tabla 4.1: 1. Información del cliente: Son campos no editables, ya que esta parte de información está almacenada en la base de datos privada cuando el cliente se registró en el sistema. Al entrar con su propia dirección de Ethereum, se recupera la información de la base de datos. La información del cliente disponible en esta parte son: ● Dirección de Ethereum ● DNI ● Nombre y apellidos ● Sexo ● Email ● Teléfono ● CIF y nombre de empresa ● Dirección de empresa 2. Información de la empresa: Igual que la parte de información del cliente, los campos de esta parte también son no editables y que se recupere de la base de datos. La información de la empresa disponible son: ● CIF y nombre de empresa ● Dirección de empresa 3. Detalles SLA: Se pedirá la siguiente información de SLA al cliente para poder enviarlo: ● Fecha inicial y si la renovación automática ● Horario y cobertura de servicio ● Soporte extra ● Pagador de licencias 52 ● Nivel de servicio ● Periodo de reporte ● Periodo y método de facturación Cabe destacar que al final de esta página se dispone de un campo de cálculo automático del precio total de SLA, hay que tener en cuenta que este precio es de referencia, el precio real se puede variar según las necesidades de cada cliente. 53 Figura 4.5 Página de SLA (cliente) - parte 1 54 Figura 4.6 Página de SLA (cliente) - parte 2 55 4.3.3. Conectar con el monedero digital Para conectar con el monedero digital, simplemente hay que hacer clic en el botón verde “Conectar monedero” colocado en la parte superior de cada página (excepto la principal, tal y como se muestra en la Figura 4.7). Al hacer clic en el botón, se muestra una ventana emergente con todos los monederos disponibles (ver la Figura 4.8), en este caso, se ha utilizado la extensión de MetaMask en Chrome, la cual se puede descargar a través de la 25 tienda online de Chrome. MetaMask hace de puente entre el sistema SLink y la red Ethereum. Figura 4.7 Botón Conectar monedero Figura 4.8 Elegir monedero Después de haber seleccionado MetaMask, se pide introducir la contraseña de la cuenta, tal y como se muestra en la Figura 4.9. 25 https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn 56 Figura 4.9 Notificación MetaMask A continuación, hay que seleccionar la cuenta de Ethereum que se quiere conectar (ver la Figura 4.10). Al estar conectado con la cuenta de Ethereum, si dicha cuenta ya está registrada en el sistema, se verá la página de SLA correctamente (ver la Figura 4.5). En cambio, si no se ha conectado se verá el error que se muestra en la Figura 4.3. 57 Figura 4.14 Listado de clientes 64 Figura 4.15 Creación de cliente 65 Figura 4.16 Actualización de cliente 66 Figura 4.17 Listado de empresas 67 Figura 4.18 Creación de empresa 68 Figura 4.19 Actualización de empresa 69 Figura 4.20 Listado de SLAs 70 Figura 4.21 Listado de datos de un SLA 71 Figura 4.22 Listado de peticiones de contacto 72 4.3.6. Dashboard El sistema proporciona un dashboard para visualizar los KPIs vinculados a los SLAs que permiten favorecer la medición y revisión de estos, consiguiendo así uno de los objetivos indicados en la sección 1.2. Objetivos. Para acceder al mismo, se debe pulsar el botón de la cabecera “Dashboard”, como se muestra en la Figura 4.5. Al igual que en el apartado anterior, este botón es visible únicamente por el proveedor de los servicios (propietario del contrato inteligente) en todas las pantallas salvo la principal y para ello, la dirección Ethereum conectada deberá ser la misma que tiene el propietario del contrato inteligente para determinar si se trata del proveedor. Como comentaba anteriormente en la sección 2.1.6. Los KPIs dentro de ITIL, debido a la limitación del tiempo y alcance, y la dificultad de probar el proyecto en los entornos empresariales reales, se han de definir unos KPIs propios y prácticos. Cada KPI se puede visualizar en 4 espacios temporales: ● Últimos 7 días ● Último mes ● Último año ● Desde comienzo del año en curso hasta la fecha actual (YTD por sus siglas en inglés Year To Date) Los KPIs se pueden clasificar según el tipo de vista gráfica: ●Gráfico de área: permiten mostrar cantidades en un espacio temporal a través de un área. Solo existe un KPI para esta vista gráfica (ver la Figura 4.23): ○ Cantidad de SLAs creados a lo largo de un espacio temporal. ●Gráfico de barras: permiten mostrar cantidades en un espacio temporal a través de barras. Son los siguientes: ○ Cantidad de SLAs creados con un servicio determinado a lo largo de un espacio temporal (para todos los servicios configurados) (ver la Figura 4.25). ○ Cantidad de SLAs creados con un servicio extra determinado a lo largo de un espacio temporal (para todos los servicios extras configurados). ○ Cantidad de SLAs creados con un espacio de servicio determinado a lo largo de un espacio temporal (para todos los espacios de servicios configurados). 73 Figura 4.27 Cambio de idioma (resultado) 80 4.3.8. Página de Aviso legal y política de privacidad La página de aviso legal y política de privacidad abarca la siguiente información (ver la Figura 4.28): Aviso legal: ● La duración del defecto de SLA en el sistema es de 1 año, el cliente tiene 3 meses desde la fecha inicial para cancelarlo gratis. ● También el cliente puede cancelar cuando quiera el servicio del próximo año hasta 2 meses antes de la próxima fecha de renovación. ● La renovación automática depende totalmente del cliente. ● Todos los precios que se muestran en la página web son precios generales, si el cliente tiene una solicitud específica, puede contactar con nosotros. ● Los horarios de servicio que se muestran en la página web son horarios generales, se pueden cambiar para que se ajusten a las necesidades del cliente. Política de privacidad: ● Nunca se compartirán los datos confidenciales del cliente con nadie más. ● El contenido de los emails de consulta y cualquier información mencionada en los mismos será leído y analizado únicamente por personales autorizados por SLink. ● Los datos sensibles incluyen: DNI, nombre y apellidos, dirección de correo electrónico, número de teléfono, datos de la empresa, dir. de Ethreum, precio total de SLA. ● Todos los datos sensibles se guardarán en una base de datos privada y no se lanzará en la Blockchain. Se dispone de 2 maneras en el sistema para acceder a la página de Aviso legal y política de privacidad: 1. Al enviar un contacto con SLink, se obliga a aceptar la política de privacidad, se muestra (ver la Figura 4.29) un enlace para ir a esta página. 2. Al enviar un SLA a la red Ethereum a través del sistema, se necesita que el cliente acepte la política de privacidad, se muestra (ver la Figura 4.30) un enlace para ir a esta página. 81 Figura 4.28 Aviso legal y política de privacidad Figura 4.29 Acceder a Aviso legal y política de privacidad (forma 1) 82 Figura 4.30 Acceder a Aviso legal y política de privacidad (forma 2) 4.3.9. Página de Conocernos La página Conocernos (ver la Figura 4.31) hace de puente entre el cliente y los personales de SLink, ofreciendo un formulario donde el cliente puede enviar peticiones de contactos al sistema y los siguientes datos de SLink: ● Oficina central (dirección y teléfono) ● Servicio de soporte técnico (teléfono y email) ● Centro de operaciones (dirección y teléfono) ● Atención comercial (teléfono) El formulario pide la siguiente información al cliente (ver la Figura 4.32): ● Nombre ● Apellidos ● Email ● Dirección Ethereum (opcional) ● Asunto ● Mensaje 83 Figura 4.31 Página Conocernos 84 Figura 4.32 Formulario de contacto Cabe destacar que todas las peticiones de contacto enviadas a través de este formulario aparecerán en el apartado Peticiones de contacto en la Lista de entidades (ver la sección 4.3.5. Lista de entidades). 4.4. Contrato inteligente En esta sección se expone el contenido y diseño del contrato inteligente. Cabe mencionar parte de los tipos de datos en Solidity utilizados en la implementación del contrato inteligente del sistema: ● Enteros sin signo: uint 85 ● Cadenas de caracteres: string ● Direcciones Ethereum: address ● Valores binarios: bool 4.4.1. Estructuras En la Figura 4.33 se muestran las estructuras existentes del contrato inteligente, las cuales están relacionadas entre ellas directamente, por ejemplo, un SLA contiene un ID (identificador) de servicio y por lo tanto, deberá existir un servicio con este ID. De esta manera, no existe redundancia de datos y además se reduce el coste de la transacción que crea un SLA al tener menor número de datos que guardar. Figura 4.33 Diagrama del modelo de datos del contrato inteligente 4.4.2. Variables Son todas aquellas variables con cualquier visibilidad que se almacenan dentro de un contrato inteligente. Toda aquella variable pública, puede ser consultada sin la necesidad de existir una función para ello. Se muestran a continuación las variables en el contrato del sistema. En la Tabla 4.2 se muestra información sobre el atritubo “Proveedor”. 86 Nombre Proveedor Tipo Dirección Ethereum Visibilidad Público Descripción Se trata de la dirección Ethereum del creador del contrato, el considerado como propietario de este. Tabla 4.2 Variable “Proveedor” En la Tabla 4.3 se muestra información sobre el atritubo “Niveles de servicio”. Nombre Niveles de servicio Tipo Cadena de caracteres Visibilidad Público Descripción Se trata de los niveles de servicio de los SLAs que permite crear el contrato. Tabla 4.3 Variable “Niveles de servicio” En la Tabla 4.4 se muestra información sobre el atritubo “IDs de servicios”. Nombre IDs de servicios Tipo Diccionario de pares con clave de tipo entero sin signo y valor servicio Visibilidad Privado Descripción Se trata de un diccionario donde la clave es el ID de un servicio y el valor es binario, indicando si existe o no este ID. Tabla 4.4 Variable “IDs de servicios” En la Tabla 4.5 se muestra información sobre el atritubo “Servicios”. Nombre Servicios Tipo Diccionario de pares con clave de tipo entero sin signo y valor servicio Visibilidad Público Descripción Se trata de un diccionario donde la clave es el ID de un servicio y el valor es el servicio en concreto. Tabla 4.5 Variable “Servicios” 87 En la Tabla 4.6 se muestra información sobre el atritubo “IDs de servicios extra”. Nombre IDs de servicios extra Tipo Diccionario de pares con clave de tipo entero sin signo y valor binario Visibilidad Privado Descripción Se trata de un diccionario donde la clave es el ID de un servicio extra y el valor es binario, indicando si existe o no este ID. Tabla 4.6 Variable “IDs de servicios extra” En la Tabla 4.7 se muestra información sobre el atritubo “Servicios extra”. Nombre Servicios extra Tipo Diccionario de pares con clave de tipo entero sin signo y valor servicio Visibilidad Público Descripción Se trata de un diccionario donde la clave es el ID de un servicio extra y el valor es el servicio extra en concreto. Tabla 4.7 Variable “Servicios extra” En la Tabla 4.8 se muestra información sobre el atritubo “IDs de espacios de servicios”. Nombre IDs de espacios de servicios Tipo Diccionario de pares con clave de tipo entero sin signo y valor binario Visibilidad Privado Descripción Se trata de un diccionario donde la clave es el ID de un espacio de servicio y el valor es binario, indicando si existe o no este ID. Tabla 4.8 Variable “IDs de espacios de servicios” En la Tabla 4.9 se muestra información sobre el atritubo “Espacios de servicios”. Nombre Espacios de servicios Tipo Diccionario de pares con clave de tipo entero sin signo y valor espacio de servicio Visibilidad Público 88 Descripción Se trata de un diccionario donde la clave es el ID de un espacio de servicio y el valor es el espacio de servicio en concreto. Tabla 4.9 Variable “Espacios de servicios” En la Tabla 4.10 se muestra información sobre el atritubo “IDs de licencias”. Nombre IDs de licencias Tipo Diccionario de pares con clave de tipo entero sin signo y valor binario Visibilidad Privado Descripción Se trata de un diccionario donde la clave es el ID de una licencia y el valor es binario, indicando si existe o no este ID. Tabla 4.10 Variable “IDs de licencias” En la Tabla 4.11 se muestra información sobre el atritubo “Licencias”. Nombre Licencias Tipo Diccionario de pares con clave de tipo entero sin signo y valor licencia Visibilidad Público Descripción Se trata de un diccionario donde la clave es el ID de una licencia y el valor es la licencia en concreto. Tabla 4.11 Variable “Licencias” En la Tabla 4.12 se muestra información sobre el atritubo “IDs de periodicidades de informes de revisión”. Nombre IDs de periodicidades de informes de revisión Tipo Diccionario de pares con clave de tipo entero sin signo y valor binario Visibilidad Privado Descripción Se trata de un diccionario donde la clave es el ID de una periodicidad de informes de revisión y el valor es binario, indicando si existe o no este ID. Tabla 4.12 Variable “IDs de periodicidades de informes de revisión” En la Tabla 4.13 se muestra información sobre el atritubo “Periodicidades de informes de revisión”. 89 Todos ellos se guardan en la base de datos privada, salvo el precio de las opciones de un SLA que estará en el fichero de configuración del sistema (src/config.js en el repositorio del código fuente del front-end). Un cliente puede cambiar de empresa, pero no se puede perder la vinculación a las empresas que pudiera tener anteriormente si creó algún SLA con ellas. Por ello, la base de datos privada almacena la vinculación de un SLA con su cliente, empresa y precio total. Este último campo es opcional, pero por cuestiones de rendimiento se almacena dentro de la base de datos privada, ya que estos datos son los mostrados para los SLAs creados en el listado de entidades. Además, debido a que la forma de contacto pasa por rellenar el formulario para tal finalidad, la base de datos privada contiene la información acerca de un contacto: ● Nombre ● Apellidos ● Email ● Dirección de Ethereum (opcional) ● Motivo de contacto ● Mensaje Se puede conocer más en detalle en la Figura 4.34. 96 Figura 4.34 Diagrama relacional de la base de datos 4.5.2. The Graph en el back-end Como se ha mencionado en la sección 3.13. The Graph, The Graph necesita la generación de eventos desde los contratos inteligentes de la red Blockchain de Ethereum para nutrirte de información y, a partir de esta, construir la información estructurada que ofrece en su API. Los eventos que genera el contrato inteligente del sistema están en la sección 4.4.4. Eventos. A partir de estos eventos, el subgrafo del sistema permite convertir toda la información obtenida en la siguiente estructura de datos (ver la Figura 4.35) para ser consultados: 97 Figura 4.35 Diagrama de clases de The Graph 4.5.3. API REST Con todo lo mencionado en los puntos anteriores, el back-end proporciona una Interfaz de Programación de Aplicaciones (del inglés Application Programming Interfaces, API) que proporciona un mecanismo de comunicación entre front-end y el propio back-end. Esta API es de tipo Transferencia de Estado Representacional (REST por sus siglas en inglés, Representational State Transfer). REST es un estilo de arquitectura software para el desarrollo web que sigue unos principios como: ● Arquitectura cliente-servidor (separación de responsabilidades y portabilidad). ● Ausencia de estado (el estado lo posee el cliente y no el servidor, de manera que este debe proporcionar toda la información necesaria al servidor en una solicitud). ● Sistemas por capas (el cliente debe tener únicamente el conocimiento de la capa a la que está hablando). Una petición a la API REST del sistema debe ajustarse a un verbo (utilizado para diferenciar acciones con una misma dirección), una URL y quizás a unos parámetros de consulta al final de la URL. Existen gran cantidad de verbos pero los utilizados en el sistema son: ● GET (consulta de recursos) 98 ● POST (creación de recursos) ● PUT (actualización de recursos) ● DELETE (eliminación de recursos) En la Tabla 4.22 se muestra la API REST que ofrece el sistema para la gestión de clientes. Verbo POST URL customers?ethAddress=A&name=B&surname=C&dni=D&email=E&phone= F&province=G&city=H&company=I Descripción Creación de un cliente donde: ●Aes la dirección de Ethereum ●Bes el nombre ●Ces el apellido ●Des el DNI ●Ees el email ●Fes el número de teléfono ●Ges la provincia ●Hes la ciudad ●Ies la compañía Verbo GET URL customer?A Descripción Consulta de un cliente donde Aes la dirección de Ethereum. Verbo GET URL customers Descripción Consulta de todos los clientes. Verbo PUT URL customers/A?&name=B&surname=C&dni=D&email=E&phone=F&province= G&city=H&company=I Descripción Modificación de un cliente donde: ●Aes la dirección de Ethereum ●Bes el nombre ●Ces el apellido ●Des el DNI ●Ees el email ●Fes el número de teléfono ●Ges la provincia ●Hes la ciudad 99 ●Ies la compañía Verbo DELETE URL customers/A Descripción Borrado de un cliente donde Aes la dirección de Ethereum. Tabla 4.22 API REST para gestión de clientes En la Tabla 4.23 se muestra la API REST que ofrece el sistema para la gestión de empresas. Verbo POST URL companies?cif=A&name=B&address=C Descripción Creación de una empresa donde: ●Aes el CIF ●Bes el nombre ●Ces la dirección postal Verbo GET URL companies?A Descripción Consulta de una empresa donde Aes el CIF. Verbo GET URL companies Descripción Consulta de todas las empresas. Verbo PUT URL companies?cif=A&name=B&address=C Descripción Modificación de una empresa donde: ●Aes el CIF ●Bes el nombre ●Ces la dirección postal Verbo DELETE URL companies/A Descripción Borrado de una empresa donde Aes el CIF. Tabla 4.23 API REST para gestión de empresas 100 En la Tabla 4.24 se muestra la API REST que ofrece el sistema para la gestión de SLAs. Verbo POST URL slas?id=A&customer=B&company=C Descripción Creación de un SLA donde: ●Aes el ID ●Bes la dirección Ethereum del cliente ●Ces el CIF de la empresa Recibe únicamente los datos sensibles, el resto se encuentra en Blockchain. Verbo GET URL slas?A Descripción Consulta de un SLA donde A es el ID. Devuelve todos los datos sensibles de un SLA. Verbo GET URL theGraph/slas?A Descripción Consulta de un SLA donde A es el ID. Devuelve todos los datos públicos almacenados en la red de Ethereum de un SLA. Verbo GET URL slas Descripción Devuelve todos los datos sensibles de todos los SLAs. Verbo GET URL theGraph/slas?start=A&end=B Descripción Consulta de todos los SLAs que estén entre AyB(fechas y horas en milisegundos opcionales). Devuelve todos los datos públicos almacenados en la red de Ethereum de los SLAs. Tabla 4.24 API REST para gestión de SLAs 101 En la Tabla 4.25 se muestra la API REST que ofrece el sistema para la gestión de peticiones de contacto. Verbo POST URL contactRequests?name=A&surname=B&email=CðAddress=D&subject= E&message=F Descripción Creación de una petición de contacto donde: ●Aes el nombre ●Bes el apellido ●Ces el email ●Des la dirección de Ethereum ●Ees el motivo de contacto ●Fes el mensaje Verbo GET URL contactRequests Descripción Consulta de todas las peticiones de contacto Verbo DELETE URL contactRequests?A Descripción Borrado de una petición de contacto donde Aes el ID. Tabla 4.25 API REST para gestión de peticiones de contacto En la Tabla 4.26 se muestra la API REST que ofrece el sistema para la gestión de servicios de SLA. Verbo GET URL theGraph//services/A?start=B&end=C Descripción Consulta un servicio, de los SLAs que lo incluyan y que estén entre ByC (fechas y horas en milisegundos opcionales). Verbo GET URL theGraph//services?start=A&end=B Descripción Consulta de todos los servicios, de los SLAs que los incluyan y que estén entre AyB(fechas y horas en milisegundos opcionales). Tabla 4.26 API REST para gestión de servicios de SLA 102 En la siguiente Tabla 4.27 se muestra la API REST que ofrece el sistema para la gestión de servicios extra de SLA. Verbo GET URL theGraph//extraServices/A?start=B&end=C Descripción Consulta un servicio extra, de los SLAs que lo incluyan y que estén entre By C(fechas y horas en milisegundos opcionales). Verbo GET URL theGraph//extraServices?start=A&end=B Descripción Consulta de todos los servicios extra, de los SLAs que los incluyan y que estén entre AyB(fechas y horas en milisegundos opcionales). Tabla 4.27 API REST para gestión de servicios extra de SLA En la Tabla 4.28 se muestra la API REST que ofrece el sistema para la gestión de espacios de servicios de SLA. Verbo GET URL theGraph//serviceSpaces/A?start=B&end=C Descripción Consulta un espacio de servicio, de los SLAs que lo incluyan y que estén entre ByC(fechas y horas en milisegundos opcionales). Verbo GET URL theGraph//serviceSpaces?start=A&end=B Descripción Consulta de todos los espacios de servicio, de los SLAs que los incluyan y que estén entre AyB(fechas y horas en milisegundos opcionales). Tabla 4.28 API REST para gestión de espacios de servicios de SLA En la Tabla 4.29 se muestra la API REST que ofrece el sistema para la gestión de licencias de SLA. Verbo GET URL theGraph//licenses/A?start=B&end=C Descripción Consulta una licencia, de los SLAs que la incluyan y que estén entre ByC (fechas y horas en milisegundos opcionales). 103 Verbo GET URL theGraph//licenses?start=A&end=B Descripción Consulta de todas las licencias, de los SLAs que las incluyan y que estén entre AyB(fechas y horas en milisegundos opcionales). Tabla 4.29 API REST para gestión de licencias de SLA En la Tabla 4.30 y la Tabla 4.31 se muestra la API REST que ofrece el sistema para la gestión de reportes de revisión y facturación de SLA. Verbo GET URL theGraph//revisionReport/A?start=B&end=C Descripción Consulta una periodicidad de informes de revisión, de los SLAs que la incluyan y que estén entre ByC(fechas y horas en milisegundos opcionales). Verbo GET URL theGraph//revisionReport?start=A&end=B Descripción Consulta de todas las periodicidades de informes de revisión, de los SLAs que las incluyan y que estén entre AyB(fechas y horas en milisegundos opcionales). Tabla 4.30 API REST para gestión de reportes de revisión de SLA Verbo GET URL theGraph//billings/A?start=B&end=C Descripción Consulta una periodicidad de facturación, de los SLAs que la incluyan y que estén entre B y C (fechas y horas en milisegundos opcionales). Verbo GET URL theGraph//billings?start=A&end=B Descripción Consulta de todas las periodicidades de facturación, de los SLAs que los incluyan y que estén entre A y B (fechas y horas en milisegundos opcionales). Tabla 4.31 API REST para gestión de facturación de SLA 104 En la Tabla 4.32 se muestra la API REST que ofrece el sistema para la gestión de métodos de facturación de SLA. Verbo GET URL theGraph//billingMethods/A?start=B&end=C Descripción Consulta un método de facturación, de los SLAs que lo incluyan y que estén entre ByC(fechas y horas en milisegundos opcionales). Verbo GET URL theGraph//billingMethods?start=A&end=B Descripción Consulta de todos los métodos de facturación, de los SLAs que los incluyan y que estén entre AyB(fechas y horas en milisegundos opcionales). Tabla 4.32 API REST para gestión de métodos de facturación de SLA 4.6. Despliegue del sistema Los pasos necesarios para realizar el despliegue del sistema requieren de un conocimiento y dominio avanzado de prácticamente todas las tecnologías utilizadas en el proyecto. En los siguientes apartados se muestran todos los pasos. 4.6.1. Despliegue del contrato inteligente El primer paso es disponer de la extensión MetaMask instalada con una dirección Ethereum dentro. Esta dirección debe contener una cantidad mínima de Ether. Para el desarrollo de este TFG, se ha utilizado una red de pruebas de Ethereum llamada Rinkeby . De cara al pago de transacciones, existen diversas formas de obtener Ether en la 27 red de pruebas Rinkeby, una de ellas es a través del siguiente enlace: https://faucets.chain.link/rinkeby. El despliegue del contrato inteligente se realiza en el entorno de desarrollo integrado Remix . 28 Para ello, se debe ir a su página web y ahí, conectar un monedero MetaMask con una dirección que será el creador del contrato inteligente (proveedor de servicios). 28 https://remix.ethereum.org/ 27 https://www.rinkeby.io/#stats 105 Figura 4.44 Verificación y publicación del código de un contrato inteligente Posteriormente, se proporciona el código del contrato inteligente y si es el correcto, el código ya estará en Etherscan, siendo este visible a cualquier persona desde su página web como se puede ver en la Figura 4.45. 112 Figura 4.45 Código verificado y publicado de un contrato inteligente 113 Una vez el subgrafo está creado y el código del contrato inteligente está desplegado en Etherscan, estos son los pasos a seguir: 1. Instalación de The Graph CLI (necesario tener npm o yarn instalado, ambos son gestores de paquete Javascript) como se puede ver en la Figura 4.46. Figura 4.46 Instalación de The Graph CLI32 2. Inicialización del subgrafo como se puede visualizar en la Figura 4.47. Figura 4.47 Inicialización del subgrafo33 3. Escritura del subgrafo: el comando anterior crea una base de estructura para el subgrafo, a partir del código público en Etherscan. En el caso de SLink, esto no es suficiente y se debe dar forma al modelo de datos como se indica en la sección 4.5.2. The Graph en el back-end editando los archivos: a. Manifiesto (subgraph.yaml): define qué fuentes de datos indexará el subgrafo. b. Esquema (schema.graphql): define los datos a recuperar de un subgrafo. c. Mapeador (mapping.ts): traduce los datos de las fuentes de datos a las entidades definidas en el esquema. Todos estos archivos mantienen el mismo contenido siempre salvo dos cambios necesarios en el despliegue dentro del manifiesto. Estos son la dirección del contrato y el bloque de inicio (bloque de la red de Ethereum donde se creó el contrato inteligente). 4. Despliegue del subgrafo como se muestra en la Figura 4.48 yFigura 4.49. 33 https://thegraph.com/docs/es/developer/quick-start/ 32 https://thegraph.com/docs/es/developer/quick-start/ 114 Figura 4.48 Generación y construcción del código de un subgrafo34 Figura 4.49 Autenticación y despliegue de un subgrafo35 Una vez desplegado el subgrado, ya está disponible para realizar pruebas tanto en la propia página de Subgraph Studio como vía API como se puede ver en la Figura 4.50. Figura 4.50 Página de edición de un subgrafo donde se muestran varios datos de este Para finalizar el despliegue de forma correcta, se ha de publicar el Subgrafo. Para ello, se hace clic en el botón “Publish” y se configura cómo se desea realizar la publicación como se puede ver en la Figura 4.51. Se recomienda marcar la opción “Ser el primero en señalar este subgrafo” para que se publique con mayor velocidad. Los subgrafos en The Graph deben ser seleccionados por los curadores para poder ser consultados y, de esta manera, saltamos el paso de esperar a que un curado seleccione el subgrafo. Esta opción no es gratuita y se debe 35 https://thegraph.com/docs/es/developer/quick-start/ 34 https://thegraph.com/docs/es/developer/quick-start/ 115 pagar con GRT, el token de The Graph. Cuanta más cantidad, más rápido se indexará. Para obtener tokens en la red de pruebas Rinkeby, se ha de visitar el servidor de Discord de The Graph y seguir los pasos indicados en este (https://discord.gg/vtvv7FP) en Discord . 36 Figura 4.51 Configuración para la publicación de un subgrafo Una vez el subgrado está desplegado y publicado, se puede visitar en una dirección similar a https://testnet.thegraph.com/subgraph?id=XX,donde XX es el ID del subgrafo generado, aunque también se puede buscar en la página https://testnet.thegraph.com/ para consultar toda 36 https://discord.com/ 116 la información disponible como se muestra en la Figura 4.52. Estos enlaces son para la red de Rinkeby, en caso de ser en la red Ethereum principal, desaparece “testnet” de estos. Figura 4.52 Subgrafo publicado a la espera de ser indexado 4.6.3. Despliegue del back-end en local Los pasos a seguir para desplegar el back-end son: 1. Disponer de una instancia de MySQL en el sistema para posteriormente crear la base de datos privada dentro de ella. 2. Disponer de Node.js en el sistema para poder ejecutar aplicaciones Node. 3. Ejecutar el comando “npm install” desde una consola, dentro del directorio raíz del proyecto. Este comando instalará las dependencias del proyecto. 4. Ejecutar el comando “node app.js” desde una consola, dentro del directorio raíz del proyecto. Este comando iniciará el proyecto. 117 Todos estos pasos se encuentran en el fichero Readme.md en el repositorio del código fuente. 4.6.4. Despliegue del front-end en local El front-end soporta tanto el idioma español como inglés, por lo que muchos campos de la configuración deben tener la traducción en ambos idiomas. Estos se marcan a continuación con la letra T. Los pasos a seguir para desplegar el front-end son: 1. Indicar la dirección Ethereum propietaria del contrato inteligente en el fichero config.js del repositorio del código fuente. 2. Configuración de las opciones de un SLA (disponible en el fichero src/config.js del repositorio del código fuente del front-end): a. Servicios: cada servicio debe contener un id, un nombre (T), una descripción (T), un precio, una periodicidad del precio y una indicación de si este es fijo u ocasional. b. Servicios extra: misma configuración que los servicios. c. Espacios de servicio: cada espacio de servicio debe contener un id, un nombre (T), una hora de inicio, una hora de fin, un precio, una periodicidad del precio y una indicación de si este es fijo u ocasional. d. Licencias: cada licencia debe contener un id y un nombre (T). e. Periodicidades de informes de revisión: cada periodicidad de informes de revisión debe contener un id, un precio, una periodicidad del precio y una indicación de si este es fijo u ocasional. f. Periodicidades de facturación: cada periodicidad de facturación debe contener un id y una periodicidad. g. Métodos de facturación: cada método de facturación debe contener un id y un nombre (T). 3. Disponer del back-end del sistema. 4. Disponer de Node.js en el sistema para poder ejecutar aplicaciones Node (imprescindible para el punto anterior). 5. Ejecutar el comando “npm install” desde una consola, dentro del directorio raíz del proyecto. Este comando instalará las dependencias del proyecto. 118 6. Ejecutar el comando “cd yujo/” desde una consola, dentro del directorio raíz del proyecto. Este comando cambiará la localización al código del proyecto. 7. Ejecutar el comando “npm start” desde una consola, dentro del directorio raíz del proyecto. Este comando iniciará el proyecto. Todos estos pasos se encuentran en el fichero Readme.md en el repositorio del código fuente. 4.7. Licencia y código fuente 4.7.1. Licencia En este proyecto se ha aplicado la siguiente licencia de Creative Commons para el código 37 fuente, salvo la parte de contrato inteligente (ver la Figura 4.53) Esto significa que se puede usar libremente el trabajo citando a los autores, no está permitido el uso comercial, modificaciones ni obras derivadas. Se puede observar dicha licencia en la parte superior de todas las páginas disponibles del sistema. Figura 4.53 Licencia Mientras para la parte de contrato inteligente, se ha utilizado la licencia MIT , licencia de 38 software libre. 4.7.2. Código fuente El código fuente de este proyecto está disponible en las siguientes direcciones de GitHub: 1. Front-end:https://github.com/Yule1223/BC-ITSM.git 2. Back-end:https://github.com/JoseVelascoSantos/BC-ITSM-BE.git 38 https://es.wikipedia.org/wiki/Licencia_MIT 37 https://creativecommons.org/ 119 Capítulo 5 - Trabajo individual En este capítulo se detalla el trabajo realizado por cada uno de los miembros del proyecto. 5.1. Trabajo individual de José Andrés Realizar este TFG supuso al principio un reto debido al desconocimiento de muchas de las tecnologías que íbamos a utilizar. Pero antes de ponernos a desarrollar, mi compañera Yule y yo, tuvimos que realizar diversas investigaciones. Las primeras investigaciones fueron sobre ITIL, SLA, y la Blockchain de Ethereum, en ese mismo orden puesto que primero tendríamos que conocer ITIL para dar paso a los SLAs y a partir de ello, tendríamos el conocimiento sobre qué debe contener un SLA para tratar de averiguar cómo Solidity nos permitiría desarrollar un contrato inteligente para almacenarlos. Una vez teníamos el conocimiento suficiente, empezamos el desarrollo. En mi caso, me ocupé del back-end aunque debido a mi experiencia profesional con React-Native (marco de trabajo para desarrollo multiplataforma de dispositivos móviles que nació a partir de React), ayudé a mi compañera con la arquitectura del front-end. En primer lugar desarrollé una primera versión del contrato inteligente del sistema. Esta primera versión, daría lugar a realizar entonces un diseño de la base de datos para almacenar los datos sensibles. Teniendo esto, desarrollé la API REST con Express para juntar todo y permitir la creación de un SLA al completo. El desarrollo del contrato inteligente se realizó de forma iterativa, donde en cada iteración nueva se actualizaba y mejoraba este hasta llegar a la versión final. Al mismo tiempo que avanzaba en el diseño del contrato inteligente, pensamos que sería buena funcionalidad tener un listado de entidades para gestionar estas y desarrollé esa parte que implicaba actualizar la API REST y crear una nueva pantalla junto con mi compañera en front-end. El dashboard fue lo último en desarrollar. Una vez pensamos en aquellos KPIs interesantes sobre un SLA, realicé una investigación y una prueba de concepto sobre The Graph. Surgieron dos problemas con ello: los eventos del contrato inteligente no eran suficientes para el subgrafo y la red de pruebas de The Graph no generaba momentáneamente tokens para poder publicar 120 el subgrafo. El primer problema se solventó actualizando el contrato inteligente y el segundo, con el paso de los días. Finalmente conseguí publicar el subgrafo que permitió ofrecer una API para realizar consultas sobre el contrato inteligente del sistema. Una vez se consiguió esto, actualicé la API REST del back-end para ofrecer un punto centralizado de consultas sobre todo el sistema y desarrollé la pantalla correspondiente a ello en front-end. 121 pueda darse de alta por su cuenta. De esta manera, el cliente ahorra el tiempo de espera y los personales de SLink ahorra la carga de trabajo. ●Mostrar mensajes de error con llamadas API: Actualmente no el sistema no dispone de mensajes de error con llamadas API, sería muy interesante tenerlo. ●Roles y permisos de la aplicación: La existencia de roles y permisos de la aplicación permitiría tener más de un propietario (de manera que más de una dirección Ethereum podría visualizar la lista de entidades y el Dashboard) o la existencia de usuarios con permisos para ello. ●Despliegue del sistema vía front-end: Actualmente el sistema se despliega para un entorno de producción de forma manual. Si existiera un despliegue en front-end, de manera que se siguieran los pasos necesarios sin requerir un conocimiento avanzado por parte del usuario, SLink podría ser desplegado sin ayuda y eso aumentaría la viabilidad del sistema. ●Configuración del sistema vía front-end: En la versión actual del sistema, se debe configurar este por un archivo de configuración (src/config.js en el repositorio del código fuente del front-end). Sería interesante tener la posibilidad de realizar esta configuración desde el front-end y/o mostrar la configuración actual en cualquier momento. ●Pruebas automatizadas de toda la aplicación: Por ejemplo, realización de pruebas unitarias para los componentes React creados y puntos finales de la API REST del back-end, pruebas funcionales para las pantallas del front-end y pruebas de rendimiento del sistema en general. ●Chat en directo como método de contacto: Esta mejora supone la existencia de personal pendiente de atender a clientes o bien un robot capaz de guiar al cliente hacia la ayuda necesaria para su necesidad. Sería útil para dar de alta a nuevos clientes de una forma rápida y actual junto a la existente opción de llamada telefónica (también opción de contacto rápido). ● Definir KPI más apropiados según la necesidad de las organizaciones: Dado la limitación de tiempo y alcance de este proyecto, se ha tenido que definir KPIs sencillos siendo un prototipo. Se tendrá que definir KPI más complejas según la necesidades de cada empresa en el entorno real. 128 Chapter 6 - Conclusions and future work This chapter presents the conclusions obtained in this Final Degree Project (FDP) and the future work that could be carried out if the development of this project were continued. 6.1. Conclusions The main conclusions that we obtain as a result of the work carried out for this FDP are related to the integration of SLAs within the Ethereum Blockchain. We have seen that it offers transparency since it is a network where any interested external party can find out about the SLAs created and registered within it, guaranteeing traceability and immutability that perhaps only a network of this type can ensure as it is a decentralized network. The use of this network is not an impediment for the system SLink, because although it is true that transactions last a few seconds with the current Proof-of-Work consensus protocol, this time is acceptable and the rest of the times where the network is involved (consultations to the Blockchain network via The Graph) are very short. The Graph, because of how it works (see section 3.13.2. ¿Cómo funciona The Graph?), has the available data to be queried ready, so query speed is not compromised. In addition, The Graph allows all kinds of queries with numerous configuration options for them, providing great flexibility when searching for data on the smart contract. This, together with an appropriate data model thanks to the smart contract events, allows you to have everything you need for a complete dashboard. The acceptance in the business world of certifications obtained through the Blockchain is already a reality: Iberdrola (a Spanish company dedicated to the production, distribution and 46 sale of energy), has recently used this technology to verify votes . In addition, at the end of 47 December 2021, a Judgment of the Provincial Court of Vitoria admitted the use of Blockchain 48 as a technological element that allows a minimum authenticity audit for an electronic document 48 https://www.poderjudicial.es/search/AN/openDocument/954cf088a7a89e01/20220510 47 https://www.ciospain.es/seguridad/la-tecnologia-blockchain-se-cuela-en-la-junta-de-accionistasde-iberdrola 46 https://www.iberdrola.es/ 129 presented as evidence in the procedure. Both facts convey that the certification and recognition of smart contracts established and registered in the Blockchain is increasingly recognized. On the other hand, when it comes to development, Javascript is a very versatile application technology that should be considered for agile development. As seen in this project, Javascript has allowed us to work with a front-end framework (React) and a back-end framework (Express). Outside of this project, cross-platform mobile applications (React-Native for example ) and desktop applications (Electron for example ) can be developed. As if this were not 49 50 enough, the syntax of languages like Solidity are quite similar, which is a great help when 51 learning another technology. We also believe that ITIL adoption should increase in relation to the IT services currently offered by companies due to the growth of the sector in recent years and what may grow in the future. Despite being used by hundreds of organizations, it is necessary to apply ITIL good practices in many more to achieve quality service provision in an increasingly digitized society; A company should not only be digitized to offer IT services, but these should also be of quality. Similarly, university students linked to any branch of computing should be familiar with the knowledge of SLA, since it is a fundamental part of the contracts of a company in the IT sector. Knowing the characteristics and applications of SLAs in the business world would help improve their professional careers. Finally, we believe that Blockchain technology has a great future to the point of perhaps completely revolutionizing the IT sector as it is known today. The arrival of Web3, a new iteration on the web with Blockchain technology, incorporates all the concepts of Blockchain technology such as decentralization and digital economy. But this technology is not just that: it allows the existence of cryptocurrencies (which continue to grow over time and the creation of new projects, they allow everything related to Blockchain to be promoted), NFTs (Non Fungible Tokens) (allow a digital property to be registered in a Blockchain) and Metaverses (digital 52 worlds where most use Blockchain technology). The objective of this FDP was to create a decentralized system based on Blockchain technology to favor the management of SLAs between IT service providers and clients following ITIL good 52 https://en.wikipedia.org/wiki/Metaverse 51 https://www.tutorialspoint.com/solidity/solidity_basic_syntax.htm 50 https://www.electronjs.org/ 49 https://reactnative.dev/docs/javascript-environment 130 practices and we believe that this has been achieved. Despite not having put SLink into a production environment, we believe that it is a system that achieves the above. Thanks to this FDP, we have obtained knowledge of numerous technologies: ●React as a front-end framework ●Postman as a testing application for REST APIs ●Ethereum as a Blockchain network intended for applications ●Solidity as a smart contract language ●Remix as a development and deployment environment for smart contracts on the Ethereum network ●GraphQL as a query and data manipulation language for APIs ●The Graph as a search engine for smart contracts ● The rest of the technologies were already known from the knowledge acquired in subjects of the software engineering degree in the computer science faculty of the Complutense University of Madrid: ○Databases (BD): In this subject we were given the introduction of relational databases, and we were taught to make queries to the database. ○Web Applications (AW): In this subject we were taught the knowledge about HTML, CSS, Javascript, and Express, which are used in the development of the front-end of the system SLink. We also learned the management of web services and the connection between them. ○Software Project Management (GPS): In this subject we were taught to use version control tools, work as a team, learn to write formal documents, and above all, it was where we met our director of the FDP and the good relationship between us began. ○Ethics, Legislation and Profession (ELP): In this course we were informed about the use of licenses, choosing an appropriate license to protect our work. They also explained to us about free software and the property of FDP. 6.2. Future work The SLink system has numerous expansion possibilities that, due to time limitations and the end of the study, have not been carried out. Here are some expansion possibilities that could be carried out in the future: 131 ●Payment of the SLA in the system itself: Although there is the payment of a fee by the client to create a new SLA in the smart contract of the Ethereum network (payment necessary to pay for the transaction that introduces changes in the network), it would be useful have payment methods within the system itself. For example, if the chosen billing method is bank transfer, you could provide the necessary bank details for it and even request a transfer receipt. If the chosen billing method is cryptocurrency payment, the smart contract could be modified to support this functionality and make the payment together with the transaction fee. ●Document management: Document management for SLAs would be interesting, so that each SLA could have a series of documents provided either by the service provider or by the client. This would make it possible, for example, to download the service levels offered in a document or to upload specific documentation requested from the client by the service provider. ●SLA summary in the form of a document: This functionality would make it possible to obtain a summary of the SLA created by the client in the form of a document and would reduce the complexity of reviewing this SLA in the smart contract externally to the system. ●More digital wallet options: Currently the system only has one digital wallet option, MetaMask, it would be interesting if it had more options to reach the largest audience. ●Register a client via front-end: Currently, if a client wants to register, they have to send a contract request through the Know Us page (see section 4.3.9. Página de Conocernos), the ideal is to have a page where the client can register by themselves. In this way, the customer saves the waiting time and the SLink personnel saves the workload. ●Show error messages with API calls: Currently the system does not have error messages with API calls, it would be very interesting to have it. ●Roles and permissions of the application: The existence of roles and permissions of the application would allow it to have more than one owner (so that more than one Ethereum address could view the list of entities and the Dashboard) or the existence of users with permissions to do so. ●System deployment via front-end: Currently the system is deployed to a production environment manually. If there was a front-end deployment, so that the necessary steps 132 were followed without requiring advanced knowledge on the part of the user, SLink could be deployed without help and that would increase the viability of the system as well. ●System configuration via front-end: In the current version of the system, it must be configured through a configuration file (src/config.js in the front-end source code repository). It would be interesting to have the possibility to make this configuration from the front-end and/or show the current configuration at any time. ●Automated testing of the entire application: For example, unit testing for built React components and back-end REST API endpoints, functional testing for front-end screens, and overall system performance testing. ●Live chat as a contact method: This improvement supposes the existence of staff waiting to attend to clients or a robot capable of guiding the client towards the necessary help for their need. It would be useful to register new clients in a fast and current way, together with the existing telephone call option (also a quick contact option). ●Define the most appropriate KPIs according to the needs of the organizations: Given the limited time and scope of this project, simple KPIs had to be defined as a prototype. More complex KPIs will have to be defined according to the needs of each company in the real environment. 133 Bibliografía 1. Ana Andrés Álvarez, Carlos Manuel Fernández Sánchez y Boris Delgado Riss. (2A. ED.). GUÍA PRÁCTICA DE ISO/IEC 20000-1 PARA SERVICIOS TIC. Universidad Complutense de Madrid. https://elibro.net/es/ereader/universidadcomplutense/131803 [Último acceso: 16/5/2022]. 2. Jan van Bon (2008). Fundamentos de la Gestión de Servicios de TI basada en ITIL. Van Haren Publishing. https://books.google.com.pe/books?id=WdFEBAAAQBAJ&printsec=copyright#v=onepag e&q&f=false [Último acceso: 20/5/2022] 3. Rodríguez, J. R. (1 de marzo de 2022). ¿Hace falta un departamento de informática? Pues, depende. Tecnología++. Blogs Institucionals UOC. https://blogs.uoc.edu/informatica/departamento-informatica/ [Último acceso: 16/5/2022] 4. OLCESE, A., & Moya, C. (3 de Febrero de 2022). El tejido productivo no se recupera: España tiene hoy 77.831 empresas menos que antes de la pandemia. El Mundo. https://www.elmundo.es/economia/macroeconomia/2022/02/03/61fab040fc6c832f698b4 5eb.html [Último acceso: 16/5/2022] 5. González Fernández-Villavicencio, N.; Menéndez Novoa, J.L.; Seoane García, C.; San Millán Fernández, M.E. (2013). Revisión y propuesta de indicadores (KPI) de la Biblioteca en los medios sociales. Revista Española de Documentación Científica, 36(1):e005. http://dx.doi.org/10.3989/redc.2013.1.919. [Último acceso: 16/5/2022] 6. IBM Blockchain. (n.d.). What is Blockchain Technology?. IBM. https://www.ibm.com/es-es/topics/what-is-blockchain [Último acceso: 16/5/2022] 7. Vitalik Buterin (2014). Ethereum White Paper.https://ethereum.org/en/whitepaper/ [Último acceso: 24/5/2022] 8. Sinclair Davidson, Primavera De Filippi, Jason Potts (2016). Economics of Blockchain. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2744751#:~:text=The%20basic%2 0economics%20of%20blockchain,cost%20of%20processing%20digital%20information% 2C [Último acceso: 23/5/2022] 9. Alex Banks & Eve Porcello (2017). Learning React: Functional Web Development with React and Redux.https://media.graphcms.com/HrM5QEqWSweYEQBwClSG?dl=true [Último acceso: 23/5/2022] 134 10. Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf [Último acceso: 24/5/2022] 11. Swan, M. (2015). Blockchain: blueprint for a new economy. First edition. ed. O’Reilly, Beijing : Sebastopol, CA. http://book.itep.ru/depository/blockchain/blockchain-by-melanie-swan.pdf [Último acceso: 24/5/2022] 12. Steinberg, R. A. (2006). Measuring ITIL: Measuring, Reporting and Modeling - The IT Service Management Metrics That Matter Most to IT Senior Executives. Trafford Publishing https://www.scribd.com/book/387796481/Measuring-Itsm-Measuring-Reporting-and-Mod eling-the-It-Service-Management-Metrics-That-Matter-Most-to-It-Senior-Executives [Último acceso: 25/5/2022] 13. Antonopoulos, A.M.;Wood, G. (2019). Mastering Ethereum: building smart contracts and DApps. First edition. ed. O’Reilly, Sebastopol, CA. https://dl.ebooksworld.ir/motoman/Mastering_Ethereum_Andreas.M.Antonopoulos.www. EBooksWorld.ir.pdf [Último acceso: 25/5/2022] 14. Julija Golosova; Andrejs Romanovs. (2018). The Advantages and Disadvantages of the Blockchain Technology. IEEE. https://ieeexplore.ieee.org/document/8592253 [Último acceso: 25/5/2022] 135 136