Integración bidireccional de Microsoft Teams con la plataforma de ServiceNow

Universidad Valladolid Escuela de Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática Mención Ingeniería de software Integración bidireccional de Microsoft Teams con la plataforma de ServiceNow. Alumno: Álvaro García Fuentes Tutor: Irene Lavín Perrino 2 i Agradecimientos Durante estos años se me abrió una nueva etapa, la universidad, una ciudad nueva y nuevas personas. El paso por la Universidad de Valladolid me ha permitido crecer como persona, aportándome valor, para años después poderlo dar yo en un entorno de trabajo. Esta etapa también ha dejado huella, brindándome amistades y un nuevo lugar donde vivir. El trabajo de fin de grado es el final del camino. Quiero agradecer a los docentes que he tenido durante estos años los valores aportados, algunos en una única ocasión y otros en diferentes cursos del grado. Por último, agradecer a mi guía de este trabajo, Irene Lavín Perrino que he podido conocer al final de esta etapa. Guiándome minuciosamente y con mucho empeño durante estos meses. También me gustaría dar otro reconocimiento a la empresa en la que me encuentro actualmente trabajando, SilverStorm. Por proporcionarme la “idea” que espero que les aporte valor. Además de por facilitarme los medios como el Microsoft Azure corporativo, que hay que recordar que es de pago y, totalmente necesario para el desarrollo que he llevado en este proyecto. ii iii Resumen La automatización de tareas habituales nos hace la vida sencilla, ServiceNow es una de las herramientas que trata de plasmar esto. Automatizando y digitalizando procesos habituales en un modelo de negocio mediante Software as a Service (SaaS). En la actualidad se han dado pasos gigantescos hacia la digitalización y automatización en Cloud, sufriendo una alta demanda para poder explotar todos estos recursos digitalmente sin importar la localización física. Por otra parte, los medios de comunicación como Microsoft Teams, se ha convertido también en una de las herramientas más solicitadas y con más crecimiento en los últimos años en prácticamente todos los ámbitos para la comunicación telemática, tales como empresariales, educativos o institucionales. En el presente no hay una unificación de ambos servicios, siendo ellos mismos independientes uno de otro. Lógicamente esto implica que no exista ninguna automatización entre ellos, teniendo que recurrir a métodos manuales y externos al servicio de Cloud. En este trabajo se buscará cubrir la necesidad, aportando sencillez y trasparencia al usuario unificando ambos servicios en uno mismo. Para conseguir este objetivo, se utilizarán algunos de los diferentes servicios que ofrece Microsoft Azure junto a un pequeño desarrollo, en el que se creará una API Rest. Mediante este API Rest se proporcionará la lógica de interacción entre ServiceNow y Microsoft Teams, permitiendo eliminar barreras a la comunicación telemática a través de un servicio de Cloud. iv v Abstract The automation of common tasks makes our lives easier, ServiceNow is one of the tools that tries to capture this. Automating and digitizing common processes in a business model through Software as a Service (SaaS). Nowadays, giant steps have been taken towards digitization and automation in Cloud, suffering a high demand to be able to exploit all these resources digitally regardless of the physical location. On the other hand, communication media such as Microsoft Teams, has also become one of the most requested and fastest growing tools in recent years in virtually all areas for telematic communication, such as business, educational or institutional. At present there is no unification of both services, being themselves independent of each other. Logically, this implies that there is no automation between them, having to resort to manual methods and external to the Cloud service. In this work we will try to cover this need, providing simplicity and transparency to the user by unifying both services in one. To achieve this goal, we will use some of the different services offered by Microsoft Azure together with a small development, in which a Rest API will be create. This API Rest will provide the interaction logic between ServiceNow and Microsoft Teams, allowing the elimination of barriers to telematic communication through a Cloud service. vi vii Tabla de contenidos 1 INTRODUCCIÓN ........................................................................................................................ 1 1.1 INTRODUCCIÓN .............................................................................................................................. 1 1.2 MOTIVACIÓN ................................................................................................................................. 2 1.3 OBJETIVOS .................................................................................................................................... 4 2 ESTADO DEL ARTE .................................................................................................................... 5 2.1 CLOUD COMPUTING ....................................................................................................................... 5 2.1.1 Introducción ..................................................................................................................... 5 2.1.2 Impacto Cloud Computing en la actualidad. .................................................................... 5 2.1.3 Modelos de Servicios en Cloud Computing ...................................................................... 5 2.1.4 Service Now ...................................................................................................................... 8 2.2 MICROSOFT TEAMS ........................................................................................................................ 9 2.3 API REST ...................................................................................................................................... 9 3 PLAN DE DESARROLLO ........................................................................................................... 10 3.1 INTRODUCCIÓN ............................................................................................................................ 10 3.2 METODOLOGÍA ............................................................................................................................ 10 3.2.1 SCRUM ........................................................................................................................... 10 3.2.2 Recursos disponibles para el proyecto ........................................................................... 11 3.3 GESTIÓN DE RIESGOS .................................................................................................................... 12 3.3.1 Introducción ................................................................................................................... 12 3.3.2 Riegos identificados ....................................................................................................... 14 3.4 PLANIFICACIÓN ............................................................................................................................ 17 3.4.1 Calendarización desglosando Sprints y Objetivos .......................................................... 18 3.5 IMPREVISTO EN LA PLANIFICACIÓN ................................................................................................... 25 3.6 ANÁLISIS DE COSTES. ..................................................................................................................... 26 3.6.1 Coste de recursos humanos ........................................................................................... 26 3.6.2 Coste de Hardware y Software ...................................................................................... 27 3.6.3 Coste Inicial del proyecto. .............................................................................................. 27 4 RECURSOS DE SOFTWARE Y HERRAMIENTAS ......................................................................... 29 4.1 OFFICE 365 ............................................................................................................................... 29 4.1.1 Microsoft Azure .............................................................................................................. 29 4.1.2 Microsoft Teams ............................................................................................................ 29 4.1.3 Microsoft Project ............................................................................................................ 31 4.2 SERVICENOW .............................................................................................................................. 31 4.2.1 Servicios en la nube ........................................................................................................ 31 4.2.2 Integraciones en ServiceNow ......................................................................................... 31 4.3 HERRAMIENTAS CHECK API REST .................................................................................................... 32 4.3.1 Postman (Check Api Rest) .............................................................................................. 32 4.3.2 SOAPUI ........................................................................................................................... 32 4.3.3 Probador de Microsoft Graph ........................................................................................ 32 4.3.4 Rest Messages de ServiceNow ....................................................................................... 33 4.4 CONTROL DE VERSIONES ................................................................................................................ 34 4.5 LENGUAJES DE PROGRAMACIÓN ...................................................................................................... 36 4.5.1 JavaScript ....................................................................................................................... 36 4.5.2 Angular .......................................................................................................................... 38 4.5.3 AJAX ............................................................................................................................... 38 5 ANÁLISIS DEL PROYECTO ........................................................................................................ 41 5.1 REQUISITOS ................................................................................................................................. 41 5.1.1 Requisitos funcionales. ................................................................................................... 41 5.1.2 Requisitos no funcionales ............................................................................................... 42 2 la herramienta, en este caso se buscará lanzar la reunión con los implicados directamente desde la propia incidencia. 1.2 MOTIVACIÓN La mayor motivación que me ha llevado a realizar este trabajo ha sido el potencial y la gran demanda que está generando el poder establecer un contacto virtualmente, en especial con reuniones de voz. Con las limitaciones actuales de la crisis sanitaria, la comunicación telemática se ha visto impulsada y se ha impuesto para hacer frente a la imposibilidad de celebrar reuniones físicas con varías personas. Por otro lado, las limitaciones de movilidad tampoco favorecen, obligando a recurrir a ponerse en contacto telemáticamente mediante software especializado (Webex, Google meeting, Microsoft Teams, Zoom, etc.). Dicho software ha ganado un peso importante en nuestro día a día y, por otro lado, el Cloud Computing, otro paradigma que se ha visto muy fortalecida en diversas empresas por las razones expuestas anteriormente y por el gran aumento del teletrabajo. A fecha de hoy en 2021, a medida que se va superando la crisis sanitaria sin precedentes vivida y a pesar de la llegada de la vacuna, el teletrabajo se impone al formato presencial, en diversos sectores. Tras prácticamente más de año y medio trabajando en remoto, son muchas las empresas e instituciones que han elegido una vuelta voluntaria y esporádica de los empleados al trabajo presencial o incluso en algunas situaciones, no volver presencialmente. La apuesta por el teletrabajo parece que ha ganado la batalla al presencialismo en sectores específicos, con el que parece ya el fin de la pandemia. Durante los últimos meses las últimas noticias de primeros del 2021 se ha visto un desplome del uso de las oficinas físicas o las que persisten son oficinas “calientes”. En mi caso personal del autor de este trabajo, con la inclusión en el mundo laboral, se ha vivido esta situación, donde no se permite acoger a toda la plantilla al mismo tiempo, como sucedía previamente a la pandemia. Se ha optado por habilitar un centro de trabajo voluntario para asistir determinados días al mes, pero nunca toda la plantilla o días sucesivos. A mayores de experiencias o pensamientos propios hay datos firmes de la transformación digital. Si se analiza el sector de la banca, que está sufriendo a día de hoy, una bajada en cuanto al número de sucursales físicas impulsando una profunda transformación digital a pasos agigantados. [3] Ilustración 1 Sucursales de entidades Bancarias en España Recuperado de Banco de España, www.epdata.es [4] 3 Con todo ello, parece indicar que estamos a ante un cambio de tendencia hacia la digitalización impulsado también por la crisis sanitaria causa del COVID-19. Las instituciones y empresas están apostando hacia esta digitalización y automatización en el Cloud Computing. Esto implica una alta demanda de poder explotar todos estos recursos digitalmente sin importar la situación física (Sin oficinas en muchos casos). Toda esta digitalización de los procesos va de la mano de una comunicación telemática, como puede ser Microsoft Teams, ya que se ha convertido en una de las herramientas más solicitadas y con más crecimiento en los últimos años en prácticamente todos los ámbitos. Para poner en contacto de forma telemática a los componentes de una organización, tales como empresariales, educativos o institucionales. [5] Si se toma como ejemplo a Microsoft, ha presentado sus resultados fiscales [6] y en ellos se constata que Teams, su aplicación de videoconferencia y colaboración, sigue ganando en cuotas de uso con 115 millones de usuarios cada día, según el CEO de Microsoft, Satya Nadella. Microsoft asegura que se han pasado 30.000 millones de minutos en Teams durante este trimestre. Todo esto supone que Teams ha crecido un 50% a lo largo del año 2020. Permitir enlazar ambos paradigmas, el Cloud Computing junto con ServiceNow y MS Teams como un medio de comunicación, mediante una integración y de manera automatizada podría permitir obtener unos grandes beneficios en cuanto a la productividad y efectividad del recurso más preciado que es el tiempo. ServiceNow es una plataforma que busca la digitalización y unificación de procesos de negocios mediante el Cloud Computing, centralizando y simplificando su gestión. De esta manera, trata de evitar largos hilos de correo para gestionar algún evento o evitar pérdidas de información, teniendo en mente siempre como objetivo, aumentar la productividad y la sencillez en los procesos de negocio. Aunque de manera general funciona correctamente, aún existen algunos puntos en los cuales no se explota esta productividad, sencillez o unificación. Uno de ellos es de los meetings, mediante algún medio de comunicación externa. ServiceNow está preparado para trabajar con ITSM, con asignaciones a departamentos, personas específicas, aprobaciones de encargados, notas de trabajo, periodos de estimación, SLAs [7] que miden productividad o contratos a cumplir. Sin embargo, hay momentos en los que está información no es suficiente y se requiere montar una reunión, la cual permita hablar con los implicados de una manera más directa. A partir de este punto, ServiceNow actualmente no contempla ninguna solución para esta situación. Esta situación requiere volver a métodos tradicionales externos, como intercambio de correos, acordar calendarios, disponibilidades para realizar la reunión y todo ellos con los respectivos tiempos de respuesta. Estas situaciones impactan directamente en el incumplimiento de la consecución de las características buscadas ya mencionadas anteriormente; productividad, sencillez y unificación. Este tipo de situaciones es la que buscará explotar en este trabajo. La cualidad principal será unificar y simplificar los procesos descritos anteriormente. De esta manera cuando un evento de la plataforma requiera una reunión, dicha reunión se pueda lanzar directamente desde el propio evento, invitando a los usuarios implicados en este. El propio sistema buscaría dentro de unas franjas horarias para reunión el momento en el cual se puede realizar la reunión, buscando huecos automáticamente de los implicados. 4 1.3 OBJETIVOS Dadas y mencionadas las motivaciones que impulsan este proyecto, se puede destacar que el objetivo principal se basa en unificar dos medios en pleno auge, Microsoft Teams y ServiceNow todo ello comunicado e integrado mediante API costumizada mediante Azure y consumida por ServiceNow. Esta unificación tendrá como objetivo: • Permitir generar reuniones de una manera automatizada y transparente para los usuarios de ServiceNow y por otro lado el registro automático de eventos de las reuniones generadas desde Ms-Teams hacia la plataforma de ServiceNow • Digitalizar un proceso de reserva de salas para reuniones, en las cuales los integrantes podrán asistir presencialmente en la propia sala o bien de manera online mediante la aplicación de MS-Teams, habiendo generado de manera automática la reunión de MSTeams desde la plataforma de ServiceNow. 5 2 ESTADO DEL ARTE En esta sección se recopilarán las tecnológicas implicadas en el proyecto detallando sobre ellas en líneas en generales y también en específico sobre la tecnología elegida para el proyecto. 2.1 CLOUD COMPUTING En pocas palabras, es un paradigma que permite el acceso remoto a software, almacenamiento de archivos y procesamiento de datos a través de Internet y, por lo tanto, es una alternativa a la ejecución en una computadora personal o servidor local. En la nube, no es necesario instalar aplicaciones localmente en la computadora. La computación en la nube brinda a las personas y empresas la capacidad de mantener un grupo de recursos informáticos bajo demanda bien mantenido, seguro y de fácil acceso. 2.1.1 Introducción La computación en la nube es la disponibilidad bajo demanda de los recursos del sistema informático, especialmente el almacenamiento de datos (almacenamiento en la nube) y las capacidades informáticas, sin la necesidad de que los usuarios los administren directamente de forma activa. [8] 2.1.2 Impacto Cloud Computing en la actualidad. Las empresas están experimentando una carga sin precedentes en su infraestructura de tecnología de la información (TI), agravado y forzado debido a la crisis sanitaria del COVID-19 sufrida durante el 2020 a nivel mundial. En la actualidad, se debe satisfacer a los clientes de cloud de una manera rápida, confiable y con crecientes expectativas en términos de servicios de seguridad. Al intentar aumentar la funcionalidad y la capacidad de almacenamiento de sus sistemas de TI, las empresas y organizaciones a menudo encuentran con la problemática de que desarrollar y mantener una infraestructura de TI escalable y segura paga un precio insostenible. Aquí es donde entra la computación en la nube. La empresa o institución no necesita comprar otro hardware, pero puede utilizar la computación en la nube. La computación en la nube es una industria en constante evolución que permite a las empresas eludir la infraestructura informática local y, en cambio, depender de servicios basados en Internet. Los proveedores basados en la nube suelen ofrecer servicios como software, almacenamiento y procesamiento a precios asequibles. Las redes de alta capacidad, la disponibilidad de computadoras y dispositivos de almacenamiento a un bajo costo, y la virtualización de hardware, la arquitectura orientada a servicios y autónoma han llevado al crecimiento de la computación en la nube en los últimos años. [5] 2.1.3 Modelos de Servicios en Cloud Computing La computación en nube engloba tres modelos de servicio diferentes, cada uno de los cuales satisface un conjunto único de requisitos empresariales. Estos tres modelos se conocen como Software como Servicio (SaaS), Plataforma como servicio (PaaS) e Infraestructura como servicio (IaaS). [9] 6 Estos modelos ofrecen una abstracción cada vez mayor, como se puede observar en el esquema de la Ilustración 2, por lo que generalmente se describen como las capas de la pila: Infraestructura, Plataforma y Software como Servicio, pero no tienen que estar relacionados. Por ejemplo, puede proporcionar Sofware como Servicio (SaaS) implementado en una máquina física sin utilizar la capa básica de Plataforma como servicio (PaaS) o Infraestructura como Servicio IaaS. En su lugar, puede ejecutar el programa en IaaS y acceder a él directamente sin empaquetarlo como SaaS. Ilustración 2 Pirámide de servicios Cloud Recuperado de ¿Qué es IaaS, SaaS y PaaS? [10] 2.1.3.1 Software as a service (SaaS) En la parte superior de la pirámide, el modelo de Software como Servicio es una solución que permite a los usuarios acceder al software del proveedor bajo un modelo de suscripción de pago por uso y / o pago por tiempo. En SaaS, la aplicación se ubica en la red en la nube del proveedor y la conexión se establece a través de la Web o API. Este tipo de computación en la nube pública proporciona aplicaciones en Internet a través de un navegador. Las aplicaciones SaaS más populares en los negocios se encuentran en G Suite de Google y Office 365 de Microsoft [11]. En aplicaciones empresariales, existen otras nubes conocidas tales como Salesforce, Oracle y la suite ERP de SAP, que han adoptado el modelo SaaS. En este tipo de servicio también es donde se encuentra ServiceNow, ofreciendo la digitalización de procesos del modelo de negocio y será la nube con la cual se trabajará en este proyecto. 7 Ilustración 3 Mercado primer cuatrimestre 2019 Recuperado de Statista [12] Las aplicaciones SaaS generalmente brindan una amplia gama de opciones de configuración, así como un entorno de desarrollo que permite a los clientes escribir sus propias modificaciones y agregar código. 2.1.3.2 Platform as a service (PaaS) Según el Instituto Nacional de Estándares y Tecnología de los Estados Unidos (NIST) la definición de computación en nube para la Plataforma como Servicio es la siguiente [9]: "La capacidad que se proporciona al consumidor es la de desplegar en la infraestructura de la nube aplicaciones creadas por el consumidor o adquiridas, creadas utilizando lenguajes de programación, bibliotecas, servicios y herramientas soportadas por el proveedor. El consumidor no gestiona ni controla la infraestructura subyacente de la nube, incluyendo la red, los servidores, los sistemas operativos o el almacenamiento, pero tiene el control sobre las aplicaciones desplegadas y, posiblemente, los ajustes de configuración para el entorno de alojamiento de aplicaciones." La Plataforma como Servicio se encuentra a medio camino entre la Infraestructura como Servicio (IaaS) y el Software como Servicio (SaaS). Proporciona acceso a un entorno basado en la nube en el que los usuarios pueden crear y entregar aplicaciones sin instalar y usar diversos entornos de desarrollo integrados (IDE) que habitualmente suelen ser muy costosos. PaaS tiene la participación de mercado más pequeña en estos tres modelos de servicio. [5] En el mercado actual, los proveedores de PaaS ofrecen aplicaciones como Microsoft Azure (incluida IaaS), Google App Engine y Apache Stratos. 2.1.3.3 Infrastructure as a service (IaaS) La Infraestructura como Servicio ofrece una forma estandarizada de adquirir capacidades informáticas bajo demanda y a través de la web. Estos recursos incluyen instalaciones de almacenamiento, redes, potencia de procesamiento y servidores privados virtuales. Los proveedores cobran de la manera habitual en los servicios en la nube es decir según un modelo de "pago por uso", en el que se facturan factores como la cantidad de almacenamiento utilizado o la cantidad de potencia de procesamiento consumida durante un período de tiempo 8 específico. En este modelo de servicio, el cliente no necesita administrar la infraestructura, pero el proveedor debe garantizar la cantidad de recursos contratados y su disponibilidad. Los servicios de IaaS que se ofrecen hoy incluyen Google Cloud Platform y Amazon EC2. 2.1.3.4 Definición de API pública (interfaz de programación de aplicaciones) En primer lugar, haremos un inciso para explicar brevemente que es una Application Programming Interfaces de aquí en adelante, mencionada con sus iniciales, API. Una API es una especificación formal que determina la manera de comunicarse o interactuar un software con otro software de terceros, al cual normalmente no se tiene alcance de desarrollo, para cumplir una o varias funciones. Así como SaaS proporciona aplicaciones a los usuarios a través de Internet, las API públicas proporcionan a un equipo de desarrollo funciones de aplicación a las que se puede acceder mediante programación. Por ejemplo, al crear aplicaciones web, los desarrolladores suelen utilizar la API de Google Maps para proporcionar direcciones de conducción; para integrarse con las redes sociales, los desarrolladores pueden recurrir a las API mantenidas por Twitter, Facebook o LinkedIn. Twilio ha creado una exitosa empresa dedicada a brindar servicios telefónicos y de mensajería a través de API públicas [13]. En última instancia, cualquier empresa puede proporcionar su propia API pública para que los clientes puedan utilizar los datos o acceder a las funciones de la aplicación. 2.1.4 Service Now ServiceNow es una plataforma de Cloud Computing que sigue el modelo Software as a Service (SaaS). habilita la transformación digital, permitiendo automatizar y digitalizando procesos habituales en un modelo de negocio, con la ventaja de que nació en la nube y para la nube, su principal objetivo es hacer más fácil el trabajo y la accesibilidad de los empleados de una empresa. ServiceNow permite una alta customización, esto hace que goce de una gran variedad de tipos de empresas e instituciones que utilizan esta plataforma para digitalizar sus procesos en el Cloud Computing. Los sectores que abarcan son muy variados, puede abarcar desde el sector financiero con clientes como son el Banco Santander y Open Bank, hasta el sector energético que no tiene ningún símil con el anterior, con clientes como Repsol o Cepsa; llegando a cubrir hasta a instituciones internacionales como puede ser Naciones Unidas. Todas ellas con procesos de negocio muy dispar, pero que han adaptado y digitalizado sus procesos a una instancia de ServiceNow. 2.1.4.1 Usos Los productos de ServiceNow pueden utilizarse para dar soporte a la mayoría de los modelos de negocio gracias a la amplia gama de herramientas que ofrece. Algunas de las formas más comunes de uso de los productos son los sistemas de ticketing y catálogo de servicios para gestionar proyectos a gran escala a través de la herramienta. (En este trabajo es lo que se desarrollará, un servicio dentro del catálogo.) Permite dar un seguimiento del progreso y el modelado predictivo para gestionar los modelos de negocio de una institución. ServiceNow es capaz de ayudar con procesos de aprendizaje automático e inteligencia artificial. También es capaz de trabajar con integraciones sin problemas. 2.1.4.2 Historia ServiceNow fue fundada en 2004 por Fred Luddy en la sede de la empresa en Santa Clara, California. Creó un sistema de flujo de trabajo basado en gran medida en formularios en la nube. En 2005, con un número muy reducido de clientes, ServiceNow creó su primer catálogo de 9 servicios limitados. En 2006, la empresa se expandió internacionalmente y creó su primera plataforma basada en la nube. 2.1.4.3 Antecedentes integraciones con ServiceNow En el ámbito laboral he realizado algunas integraciones con ServiceNow, esta plataforma brinda mediante arquitecturas de “webservices” [14] crear integraciones con diversos servicios tales como: • Rest API • SOAP Web Service • JSONv2 Web Service Creando de una manera relativamente sencilla un link público donde poder compartir diversos parámetros y métodos HTTP tales como get, put, post etc. propias de estos servicios. La experiencia que he tenido con integraciones y servicenow ha sido principalmente mediante soap, ya que era la tecnología solicitada por clientes, en el caso del trabajo que se va a realizar se realizará con Api Rest debido a que es la tecnología que nos facilita Microsoft para las integraciones con sus herramientas. 2.2 MICROSOFT TEAMS Microsoft Teams es una plataforma de comunicación y colaboración, desarrollada por Microsoft, está dotada de un chat persistente con miembros de una organización, al igual que permite reuniones bien con miembros de una organización o de terceros. Goza de herramientas tales como una compatibilidad de otros de sus productos como es el paquete de office e integración de este [15]. Por otro lado, y este es el punto más interesante para el desarrollo de este proyecto es que el servicio presenta extensiones que pueden integrarse con productos que no son de Microsoft, en este caso con ServiceNow. 2.3 API REST Es una estandarización la cual ha ganado en popularidad durante los últimos años, un modelo y un lenguaje estándar para describir una API REST y que esta, respete todas las restricciones de REST [16]. En estos días, una organización utiliza múltiples aplicaciones de software para gestionar sus trabajos. Estas aplicaciones también se basan en varios tipos de plataformas, distintas entre ellas y con sus propios ecosistemas. Por lo tanto, un desarrollo de software de interoperabilidad utilizando el servicio web se convierte en uno de los temas más populares en la actualidad. Mediante la arquitectura de servicios web API REST. El diseño pretende ser sencillo y estandarizado, permitiendo esa unión entre aplicaciones con la cual se desarrollará este trabajo [17]. 10 3 PLAN DE DESARROLLO 3.1 INTRODUCCIÓN En la siguiente sección se mostrará cual ha sido el método por el cual se ha desarrollado el proyecto, al igual que se detallarán las fases de la planificación de desarrollo a seguir. También se mostrará y explicara cuales han sido tanto las tecnologías requeridas para el desarrollo del mismo, con el fin de acercar al lector a entender como se ha analizado y diseñado, al igual que detallar los requisitos necesarios para permitir replicar el contenido de este en otros proyectos similares. 3.2 METODOLOGÍA Se realizará un primer estudio, en el cual se recogerán los requisitos del proyecto, con ideas muy generales de los metas y funcionalidades a conseguir, que básicamente consistirá en la integración completa y bidireccional de ambas plataformas ServiceNow y Teams. Con esta idea general en mente, se realizará un estudio profundo sobre que permite MS Teams y que no, ya que al ser una integración de software de terceros y de código cerrado, esto nos marcará los límites del desarrollo en el proyecto y una vez realizado, se podrá llevar a cabo una estimación y planificación precisa del proyecto. ServiceNow, aunque sea una plataforma de terceros, nos da un control y un acceso a prácticamente a todo su código y funcionalidad dentro de la instancia, por lo tanto, no nos impondrá líneas rojas a la hora de llevar a cabo funcionalidades. 3.2.1 SCRUM Se recurrirá a la metodología ágil de SCRUM para el desarrollo del proyecto, lo que conlleva que durante todo el proyecto se realizarán diversas entregas parciales regulares, normalmente asociadas en historias de usuarios. Las historias de usuarios por otra parte formarán parte de un Sprint, siendo este uno de los mayores puntos de control del proyecto. Las historias de usuarios están asociadas a uno o varios requisitos o casos de uso y son pequeños entregables, todas ellas formarán parte del Backlog de un Sprint. El Backlog de un Sprint, será un “contenedor” el cual contendrá todas las tareas pendientes de realizar. Al final de cada Sprint debe haber una retrospectiva de este, donde el equipo analizará cómo trabaja y qué problemas pueden impedirle progresar con normalidad, mejorando así continuamente su productividad. Con este conocido método al tener al menos 1 o 2 entregables(artefactos) por semana asociados a unas historias de usuario, se obtiene a su vez un feedback parcial muy inmediato del estado y avance del Sprint. Está metodología ágil de desarrollo de Software incorpora algunos roles entre los implicados: • Product Owner: Se encargará de representar a los Stakeholders ante el equipo de desarrollo, trasmitiendo la visión de los StakeHolders a todo el equipo. • Scrum Master: Su función será gestionar y planificar las tareas de lo Sprints. • Equipo de desarrollo: Sera el colectivo encargado de llevar a cabo el desarrollo técnico del proyecto. • Stakeholders: Es el colectivo que incluye personas o instituciones, quienes interactuarán principalmente con el producto. [18] 11 Ilustración 4 Esquema Sprint. Recuperado de appvizer [19] El proyecto se prolongará a lo largo de la estimación de la duración del proyecto, en Sprints. Estos tendrán duración de dos semanas aproximadamente salvo excepciones tales como imprevistos, incumplimiento de la planificación del Sprint o retrospectiva con resultados negativos. 3.2.2 Recursos disponibles para el proyecto Para la realización del proyecto presentado se dispondrán de dos recursos principales en el equipo de implementación, ambos tendrán el rol de “equipo desarrollo”: o Álvaro García Fuentes (Equipo desarrollo, Scrum Master) o SilverStorm (Product Owner , Equipo de desarrollo) La mayor parte de las tareas se realizarán a cargo del recurso de “Alvaro García Fuentes” el alumno que realiza este proyecto, a excepción de algunas tareas específicas a las cuales o bien por permisos u administración no podrá realizarlas “Álvaro García Fuentes”. SilverStorm llevará a mayores un rol más, en concreto el rol del ‘Product Owner’, es uno de los roles principales de Scrum y se encargará de representar a los stakeholders [18]. En este caso se encarga de revisar el trabajo realizado final y comprobar si se satisface las necesidades de los requisitos iniciales, también trasladados por ellos. A pesar de tener este rol también participará en alguna historia de usuario muy concreta, en la sección de a continuación se detallará las asignaciones por recurso. 18 3.4.1 Calendarización desglosando Sprints y Objetivos Se detallará en un calendario las diferentes tareas a realizar en el proyecto al igual de los diferentes hitos a conseguir en fechas establecidas. En primer lugar, se mostrará un calendario el cual contendrá la planificación dividida en los Sprints planteados en el punto anterior. A continuación del calendario se detallará cada Sprint y sus objetivos. Mes Lu. Ma. Mi. Ju. Vi. Sá. Do. Mar. 2021 1 SPRINT 1 2 SPRINT 1 3 SPRINT 1 4 SPRINT 1 5 SPRINT 1 6 7 8 SPRINT 1 9 SPRINT 1 10 SPRINT 1 11 SPRINT 1 12 SPRINT 1 13 14 15 SPRINT 2 16 SPRINT 2 17 SPRINT 2 18 SPRINT 2 19 SPRINT 2 20 21 22 SPRINT 2 23 SPRINT 2 24 SPRINT 2 25 SPRINT 2 26 SPRINT 2 27 28 29 SPRINT 2 30 SPRINT 2 31 SPRINT 2 1 Jueves Santo 2 Viernes Santo 3 4 Pascua Abr. 2021 5 SPRINT 3 6 SPRINT 3 7 SPRINT 3 8 SPRINT 3 9 SPRINT 3 10 11 Feria de Abril 12 SPRINT 3 13 SPRINT 3 14 SPRINT 3 15 SPRINT 3 16 SPRINT 3 17 18 19 SPRINT 3 20 SPRINT 3 21 SPRINT 4 22 SPRINT 4 23 Día Castilla y león 24 25 26 SPRINT 4 27 SPRINT 4 28 SPRINT 4 29 SPRINT 4 30 SPRINT 4 1 Día del Trabajo 2 Día de la Comunidad de Madrid May. 2021 3 SPRINT 4 4 SPRINT 4 5 SPRINT 4 6 SPRINT 4 7 SPRINT 4 8 9 10 SPRINT 4 11 SPRINT 4 12 SPRINT 4 13 San Pedro Regalado. 14 SPRINT 4 15 16 17 SPRINT 4 18 SPRINT 4 19 SPRINT 4 20 SPRINT 4 21 SPRINT 4 22 23 24 SPRINT 4 25 SPRINT 4 26 SPRINT 4 27 SPRINT 4 28 SPRINT 4 29 30 Día de Canarias 31 SPRINT 4 1 SPRINT 4 2 SPRINT 5 3 SPRINT 5 4 SPRINT 5 5 6 19 Mes Lu. Ma. Mi. Ju. Vi. Sá. Do. Jun. 2021 7 SPRINT 5 8 SPRINT 5 9 SPRINT 5 10 SPRINT 5 11 SPRINT 5 12 13 14 SPRINT 5 15 SPRINT 5 16 SPRINT 5 17 SPRINT 5 18 SPRINT 5 19 20 21 SPRINT 5 22 SPRINT 5 23 SPRINT 5 24 SPRINT 5 25 SPRINT 5 26 27 28 29 30 1 2 3 4 Tabla 9 Calendario del proyecto A continuación, se detallarán los Sprints expuestos en el calendario anterior, estarán compuestos de un backlog [20] de historias de usuario, que se irán abordando para conseguir el Sprint completo. Cada Sprint constará de dos partes: • La planificación inicial (Sprint Planning). • Retrospectiva El Sprint Planning tendrá una estimación y unas fechas de planificación, en caso de imprevistos en dicha planificación se marcarán en rojo cuando son negativos y en verde cuando son positivos. Por otro lado, en la retrospectiva de cada Sprint se analizarán tantos los puntos positivos como negativos que se ha encontrado el equipo de desarrollo al abordar las diversas historias de usuario. 3.4.1.1 Sprint 1 El primer Sprint tratará de reunir todos los recursos necesarios para comenzar el desarrollo propiamente dicho sobre la plataforma de ServiceNow, establecido alcanzarlo para el mes de abril, estará compuesto de dos Sprints y sus tareas están descriptas en Stories se especificará en las siguientes tablas. Sprint Plannnig En la tabla de a continuación se detalla las historias de usuario que componen este Sprint. Recurso Fecha inicio Fecha entrega Duración Estado Sprint 1 01/03/2021 15/03/2021 40 horas Completado US01: Inicio proyecto y tramites con las partes. Álvaro García Fuentes 01/03/2021 03/03/2021 12 horas 10 horas Completada US02: Recogida Requisitos Álvaro García Fuentes, SilverStorm 04/03/2021 08/03/2021 12 horas Completada US03: Estudio y viabilidad del API de Microsoft para la integración con MSTeams Álvaro García Fuentes 09/03/2021 12/03/2021 16 horas Completada 20 Tabla 10 Sprint 1 Retrospectiva Lanzamos un análisis/opinión por parte del equipo una vez finalizado el Sprint. Los objetivos del Sprint se han alcanzado y ajustado a la planificación inicial. Puntos positivos del Sprint: • La US01 Inicio proyecto y tramites con las partes, se ha conseguido antes de tiempo. • El resto de las historias de usuario no se han bloqueado y se han llevado a tiempo. Puntos negativos del Sprint: • Ninguno 3.4.1.2 Sprint 2 El Sprint 2 será conjuntos de Stories las cuales permitirán la configuración previa en Microsoft Azure para la integración con ServiceNow, permitiendo después de este Sprint centrarnos en la plataforma, consiguiendo empezar a abordar este objetivo para el mes de abril. En la tabla de a continuación se detalla las Stories que componen este Sprint. Sprint Plannnig En la tabla de a continuación se detalla las historias de usuario que componen este Sprint. Recurso Fecha inicio Fecha entrega Duración Estado Sprint 2 15/03/2021 31/03/2021 52 horas Completada US04: Documentar y plantear procesos de digitalización posibles con la API estudiada en Azure junto con ServiceNow. Álvaro García Fuentes 15/03/2021 19/03/2021 20 horas Completada US05: Solicitud de creación y configuración de nuevo usuario con permisos en Azure para el proyecto. Silverstorm 22/03/2021 24/03/2021 29/03/2021 12 horas Completada, pero sufrió retraso en la entrega. US06: Creación de una nueva APP en Azure con Microsoft. Álvaro García Fuentes 25/03/2021 29/03/2021 26/03/2021 30/03/2021 8 horas Completada 21 US07: Obtención de permisos y configuración llamadas de la API mediante MS-Graph en Azure. Álvaro García Fuentes 29/03/2021 30/03/2021 31/03/2021 12 horas Completada Tabla 11 Sprint 2 Retrospectiva Algunas historias de usuarios no se han alcanzado y ajustado a la planificación inicial, tampoco a la duración planificada. Puntos positivos del Sprint: • Las historias de usuario que dependían del lado del desarrollo (Álvaro García Fuentes), se han podido realizar sin dificultades. Puntos negativos del Sprint: • El entregable de la historia de usuario ‘US05: Solicitud de creación y configuración de nuevo usuario con permisos en Azure para el proyecto.’. Sufrió un retraso considerable. • El punto anterior obligo a realizar más de las 4 horas establecidas para alcanzar el objetivo del Sprint antes de que finalizará el mes de marzo. 3.4.1.3 Sprint 3 A partir del Sprint 3, se empezará con el desarrollo sobre la plataforma de ServiceNow, se configura todo lo necesario para tener la correcta comunicación entra las llamadas con la instancia de ServiceNow con la APP de Azure creada en las semanas anteriores. Sprint Plannnig En la tabla de a continuación se detalla las Stories que componen este Sprint. Recurso Fecha inicio Fecha entrega Duración Estado Sprint 3 01/04/2021 20/04/2021 48 horas Completado US08: Creación y configuración de una nueva instancia en ServiceNow, donde se va a realizar el proyecto. Álvaro García Fuentes 05/04/2021 09/03/2021 20 horas Completada US09: Diseño y creación de perfil con doble autenticación mediante token. (oauth 2.0) Álvaro García Fuentes 12/04/2021 15/04/2021 16/04/2021 16 horas + 8 horas Completada fuera de plazo, varios bloqueos. 22 US10: Creación de web Service en ServiceNow por que permitirán las llamadas mediante API REST a Azure. Álvaro García Fuentes 16/04/2021 17/04/2021 20/04/2021 12 horas Completada Tabla 12 Sprint 3 Retrospectiva Algunas historias de usuarios no se han alcanzado y ajustado a la planificación inicial, tampoco a la duración planificada. Puntos positivos del Sprint: • La gran mayoría de las historias de usuario se han abordado sin dificultades. Puntos negativos del Sprint: • Dificultades con la historia de usuario ‘US09: Diseño y creación de perfil con doble autenticación mediante token. (oauth 2.0)’, por parte del lado de Azure se encontraban muchos mecanismos de seguridad que no se tuvieron en cuenta en la primera estimación. Obligando a dedicar más tiempo, para conseguir esta historia de usuario y su correspondiente entregable. • El punto anterior obligo de nuevo a realizar más de las 4 horas establecidas para alcanzar el objetivo y calendarización del Sprint. 3.4.1.4 Sprint 4 Este Sprint será el más extenso en tiempo del proyecto, constará de la mayoría de la implementación del proyecto y abordará toda la digitalización del proceso de reserva de salas integrado con Microsoft Teams, haciendo uso de las llamadas a API implementadas en el Sprint anterior. Sprint Plannnig En la tabla de a continuación se detalla las historias de usuario que componen este Sprint. Recurso Fecha inicio Fecha entrega Duración Estado Sprint 4 21/04/2021 10/05/2021 104 horas Completado US11: Creación y diseño de las múltiples funciones de la clase ‘Handler_REST’ Álvaro García Fuentes 21/04/2021 04/05/2021 32 horas Completada US12: Creación nueva tabla U_ROOM, configurando Álvaro García Fuentes 05/05/2021 07/05/2021 12 horas 8 horas Completada 23 formulario a ella, campos y scripts de cliente y servidor. US13: Inclusión de creación de Meetins online con MS-Teams desde el proceso de reporte de incidencias de ServiceNow Álvaro García Fuentes 10/05/2021 12/05/2021 12 horas Completada US14: Ajax de comunicación entre Scripts de cliente con la función de Servidor ‘Handler_REST’ Álvaro García Fuentes 14/05/2021 18/05/2021 12 horas Completada US15: Petición “Room conference” digitalizando un flujo de reserva de salas física mediante ServiceNow y lanzando a su vez peticiones en MS-Teams para acceder de manera virtual. Álvaro García Fuentes 19/05/2021 01/06/2021 36 horas Completada Tabla 13 Sprint 4 Retrospectiva El análisis/opinión por parte del equipo una vez finalizado el Sprint es muy positivo. Este Sprint ha permitido ver grandes avances y cambios sobre el proyecto. Los objetivos del Sprint se han alcanzado y ajustado a la planificación inicial. Puntos positivos del Sprint: • Las historias de usuario se han abordado en las fechas establecidas y siempre en tiempos de duración iguales o menores a los estimados. Puntos negativos del Sprint: • Ninguno 24 3.4.1.5 Sprint 5 El Sprint 5 estará compuesto de Stories de diseño y customización de la instancia. Se dará estilo con Angular, CSS, JavaScript e HTML. Sprint Plannnig En la tabla de a continuación se detalla las historias de usuario que componen este Sprint. Recurso Fecha inicio Fecha entrega Duración Estado Sprint 5 02/06/2021 15/05/2021 40 horas Completado US16: Customización de Service Portal (Front ServiceNow) aplicando estilos (HTML/CSS/ANGUL AR/JAVASCRIPT) Álvaro García Fuentes 02/06/2021 11/06/2021 32 horas Completada US17: Customización de la vista técnica (back). Álvaro García Fuentes 14/06/2021 15/06/2021 8 horas Completada Tabla 14 Sprint 5 Retrospectiva El análisis/opinión por parte del equipo una vez finalizado el Sprint es muy positivo, al equipo de desarrollo le ha gustado las tareas de customización de la instancia. Los objetivos del Sprint se han alcanzado y ajustado a la planificación inicial. Puntos positivos del Sprint: • Las historias de usuario se han abordado en las fechas establecidas y siempre en tiempos de duración estimados. • Resultados muy visuales de los desarrollos. Puntos negativos del Sprint: • Ninguno 25 3.4.1.6 Sprint 6 Constará de Stories la cuales permitirán documentar el proceso al igual que incluirá pruebas de calidad sobre el proyecto. Sprint Plannnig En la tabla de a continuación se detalla las historias de usuario que componen este Sprint. Recurso Fecha inicio Fecha entrega Duración Estado Sprint 6 16/06/2021 25/06/2021 32 horas Completado US18: Pruebas desarrollo y redacción casos de uso. Álvaro García Fuentes 16/06/2021 18/06/2021 12 horas Completada US19: Documentación y manual del usuario. Álvaro García Fuentes 21/06/2021 25/06/2021 20 horas Completada Tabla 15 Sprint 6 Retrospectiva Los objetivos del Sprint se han alcanzado y ajustado a la planificación inicial. Puntos positivos del Sprint: • Las historias de usuario se han abordado en las fechas establecidas y siempre en tiempos de duración estimados. Puntos negativos del Sprint: • Ninguno 3.5 IMPREVISTO EN LA PLANIFICACIÓN Durante el proyecto han surgido imprevisto en la planificación inicial, sobre algunas historias de usuario específicas. La planificación frente a imprevistos puede resultar crucial para prevenir retrasos, incumplimientos u otros problemas en la planificación. Por consiguiente, para evitarlos y/o gestionarlos, se realizó un estudio de posibles riesgos y, por tanto, un incumplimiento de las estimaciones en la sección de [3.3] Gestión de Riesgos. Durante el desarrollo del proyecto hubo dos eventos a destacar, uno de ellos fue detectado e identificado previamente y otro por el contrario no. En primer lugar por el riesgo identificado, este sucedió con la US09: Diseño y creación de perfil con doble autenticación mediante token. (oauth 2.0) incluida en el [3.4.1.3] Sprint 3. Como consecuencia esta historia de usuario consumió más tiempo que del estimado inicialmente. En concreto, la historia de usuario necesitó dos días más para ser completada. Como consecuencia se incrementaron las horas diarias dedicadas en el siguiente Sprint, pasando de 4 a 5,5h para 26 cumplir con el calendario y los plazos. Este riesgo fue identificado previamente R7Problemas doble autentificación con Azure en el apartado [3.3] Gestión de Riesgos . Por otro lado, hubo problemas con la entrega del recurso externo ‘SilverStorm’ esto sucedió durante el [3.4.1.2] Sprint 2 y en concreto con la US05: Solicitud de creación y configuración de nuevo usuario con permisos en Azure para el proyecto. Se demoró una semana más de lo previsto la fecha de entrega. Esta situación obligó a aumentar en todo el proyecto la dedicación en horas por día trabajado, pasando de 4h a 4,5h. 3.6 ANÁLISIS DE COSTES. 3.6.1 Coste de recursos humanos Este proyecto será afrontado por un único desarrollador con pequeños apoyos externos en la API proporcionada de Microsoft Graph. Nombre del recurso Tipo Iniciales Capacidad Tasa Álvaro García Fuentes Trabajo AGF 50% 15,00€/Hora SilverStorm Trabajo S 25% 20,00€/Hora Ilustración 5 Recursos Humanos disponibles para el proyecto El proyecto se ajustará a una extensión aproximada de 300 horas esta estimación de horas se encuentra con detalle en el apartado [3.4] Planificación, específicamente sobre la tabla 7 de dicho apartado. El programador no se dedicará en exclusiva a este proyecto y no dedicará expresamente sus 8 horas, salvo excepciones o imprevistos, el programador realizará jornadas de entorno 4 horas para el desarrollo del proyecto como ya se ha comentado en otros apartados. Los días calculados en el apartado de [3.4.1] Calendarización desglosando Sprints y Objetivos suman una cuantía de 79 días, de los cuales 3 días son del recurso ‘SilverStorm’ y 76 del recurso ‘Álvaro García fuentes’ El periodo real del 1 de marzo al 30 de junio equivale a 87 días hábiles y unas 17 semanas, lo que nos da un margen de unas 3 semanas para cubrir posibles imprevistos. Cabe destacar que la situación ideal de dedicación del programador a 4 horas diarias puede variar y el horario es flexible, de ahí que se deje un margen de 3 semanas, en la cuales también se incluirán presentaciones, demostraciones y cierre del proyecto. La cuantía de llevar a cabo este proyecto será la siguiente por recursos humanos: Díasxhoras al díaxTasa= cuantía recurso 76x4x15=4560€ por el recurso Álvaro García Fuentes 3x2x20=120€ por el recurso SilverStorm Cuantía total de todos los recursos humanos empleados en el proyecto 4680€ 27 3.6.2 Coste de Hardware y Software 3.6.2.1 Hardware El desarrollador dispondrá de un equipo portátil, teclado y segunda pantalla. Los gastos se incluirán como parte del costo del proyecto, lo que con ello supone una cuantía de 900€ por parte del hardware. 3.6.2.2 Software de pago. El siguiente software se incluirá como parte de los gastos ya que es software propietario necesario para llevar a cabo el proyecto. Office 365 La licencia utilizada en el proyecto será “Microsoft 365 Empresa Premium” la cual tendrá un costo de 16,90€ al mes por usuario [21], al menos se tendrán 3 usuarios para pruebas y desarrollo y se deberá pagar un mínimo de 4 meses para su desarrollo lo que supone una cuantía de final de 16,90x3x4=202,8€. ServiceNow La licencia de ServiceNow se cobra anualmente la instancia en la que se realizará el proyecto no necesita contratar ningún modulo en particular, aunque el proyecto realiza customizaciones en el módulo de ITSM, en concreto sobre las incidencias. Como se deberá pagar un año completo para desarrollar el proyecto, incluiremos este precio en el proyecto. Cuota anual ServiceNow 948€ Cuota anual ITSM 407€ Cuantía total 1355€ 3.6.3 Coste Inicial del proyecto. Los costes iniciales de un proyecto son los que se producen durante el proceso de diseño y desarrollo. En la tabla de a continuación se realiza la suma de todos los apartados analizados anteriormente: Elemento Costo Software 1557,80 € Hardware 900 € Recursos Humanos 4.680€ Total 7.137,80 € Tabla 16 Coste del proyecto 34 Ilustración 9 Test de mensaje API Rest desde ServiceNow 4.4 CONTROL DE VERSIONES En ingeniería de software, el control de versiones es el sistema responsable de administrar cambios en el código en desarrollos de software, documentos, sitios web grandes u otras colecciones de información. El control de versiones es una parte integral de la gestión de la configuración del software y por ello muy importante para el estricto control y recuperación de versiones anteriores si fuera necesario. Durante el desarrollo se usará el control de versiones propio de ServiceNow, denominado “Version records”. Todas las versiones se almacenan en la tabla Update Versions [sys_update_version] que contiene registros que representan el estado de un objeto personalizable en un momento determinado. Un registro personalizable es cualquier objeto del que se hace un seguimiento mediante los Conjuntos de Actualización, como puede ser un script, una configuración, un campo de una tabla, etc. En líneas generales cualquier registro o configuración de ServiceNow tiene control de versiones. Los nuevos registros de versión se crean automáticamente cada vez que un usuario cambia un registro personalizable o cambia el archivo de aplicación para el registro personalizable, todo de una manera invisible para el usuario. Por otro lado, todos los registros modificados y sus versiones quedan registradas con fecha hora y usuario que realizo la modificación. En este punto ServiceNow saca musculo con un potente control de versiones perfectamente integrado en la plataforma. 35 A continuación, se muestra una pequeña prueba del funcionamiento de este control de versiones, sobre un Script, se realizará un pequeño cambio añadiendo alguna linea adicional y a continuación se compara con la anterior. Nos mostrará los cambios añadidos directamente sobre el código, indicando las líneas añadidas o cambios sobre ella. Una vez realizada la comparación disponemos de la posibilidad de revertir a la versión comparada o conservar la actual. Ilustración 10 Ejemplo control de versiones en ServiceNow 1 Ilustración 11 Ejemplo control de versiones en ServiceNow 2 36 4.5 LENGUAJES DE PROGRAMACIÓN 4.5.1 JavaScript JavaScript es un lenguaje de alto nivel, compilado en tiempo de ejecución y multiparadigma. Tiene una sintaxis de corchetes, tipificación dinámica, orientación a objetos basada en prototipos y funciones de clase. Este lenguaje de programación se ajusta a la especificación ECMAScript [36]. Aunque guarda muchas similitudes con Java, este lenguaje está orientado a la web, siendo más liviano y menos fuertemente tipado que su hermano mayor, Java. Sin embargo, su uso está muy extendido, y que, junto con HTML y CSS, JavaScript es una de las tecnologías centrales de la World Wide Web. Los sitios web lo utilizan habitualmente del lado del cliente para el comportamiento de las páginas web, incorporando a menudo bibliotecas de terceros, como las que detallaremos en los subapartados de a continuación. Todos los principales navegadores web tienen un motor JavaScript dedicado para ejecutar el código en el dispositivo del usuario. Sin embargo, en el caso de Servicenow, utiliza JavaScript en back-end, permitiendo configurar el lado del servidor con este lenguaje y potenciado con algunas bibliotecas que especificaremos más adelante. Como lenguaje multiparadigma, JavaScript admite estilos de programación orientados a eventos, funcionales e imperativos. Dispone de interfaces de programación de aplicaciones (API) para trabajar con texto, fechas, expresiones regulares, estructuras de datos estándar y el modelo de objetos del documento (DOM). 4.5.1.1 GlideRecord (Gestión Base de datos) Dentro de JavaScript, ServiceNow disfruta de algunas bibliotecas que ayudan a su gestión, una de ellas es la API de GlideRecord. Mediante los métodos de la API de GlideRecord, se puede devolver todos los registros de una tabla, devolver registros basados en condiciones o palabras clave específicas, o devolver registros de varias tablas con una sola consulta. A continuación, se muestra un pequeño fragmento código de ejemplo, donde se actualiza un campo, sobre las incidencias de prioridad 1 en ServiceNow var target = new GlideRecord('incident'); //Lanza la consultar sobrela tabla indicada target.addQuery('priority','>',1); //Filtra sobre la tabla con una condición de un campo determinado target.query(); // Ejecuta la query con los parámetros establecidos while (target.next()) { //Por ejemplo se puede modificar campos. target.comments =’Incidencia de prioridad alta’; target.updtate(); } 37 4.5.1.2 GlideForm (Cliente) La API de GlideForm proporciona métodos para personalizar los formularios. GlideForm.js es la clase JavaScript que contiene los métodos. El objeto global g_form se utiliza para acceder a los métodos de GlideForm. Los métodos GlideForm sólo se utilizan en el cliente. Estos métodos se utilizan para realizar cambios personalizados en la vista del formulario de los registros. Toda la validación de los ejemplos se ha realizado mediante scripts en el cliente. Algunos de estos métodos también pueden utilizarse en otros scripts de cliente (como los scripts de cliente de catálogo o los scripts de cliente de asistente), pero deben probarse primero para determinar si funcionarán como se espera. Un pequeño ejemplo, en un script de cliente, se controla que, si cambia un campo, se utiliza la API g_form, para mostrar u ocultar campos. function onChange(control, oldValue, newValue, isLoading, isTemplate) { //Si la página está cargando if (!isLoading) { //Si el nuevo valor es distinto de vacio if(newValue != '') { //Se muestra el campo de la prioridad g_form.setVisible('priority', true); } else //No se muestra el campo de la priodiad g_form.setVisible('priority', false); } } 4.5.1.3 JSON - Global Proporciona métodos para crear objetos JSON a partir de una cadena, y para convertir objetos JSON en cadenas. La API de JSON tiene métodos dinámicos y estáticos. Se accede a los métodos dinámicos creando un objeto JSON. Para utilizar los métodos dinámicos en una aplicación de ámbito, añada el prefijo global cuando llame al constructor. Para acceder a los métodos estáticos se utiliza el objeto JSON estático. El objeto JSON nativo de JavaScript ES5 se utiliza en lugar de los métodos estáticos JSON. Si su script necesita el comportamiento antiguo, utilice los métodos encode() y decode(). Este ejemplo, se obtiene un atributo de un objeto JSON que ha respondido el servidor de Azure en una cadena, mediante la trasformación de esa cadena de String a un objeto de JSON utilizando la biblioteca de JSON, lo obtenemos. var rM = new sn_ws.RESTMessageV2('AzureSILVERGlobal', 'Post Meet'); rM.setRequestBody(bodyMeet); var responseM = rM.execute(); var responseBodyM = responseM.getBody(); var httpStatusM = responseM.getStatusCode(); var enlaceMeet = JSON.parse(responseBodyM.toString()).joinUrl; 38 4.5.1.4 Resto de bibliotecas usadas por ServiceNow Lo anteriormente descrito, son dos de las bibliotecas que más se utilizan para cualquier desarrollo en ServiceNow prácticamente no obstante en este proyecto se han recurrido a bastantes más, los principales tipos usados han sido: • JavaScript API reference (servicenow.com) [37] • REST API reference (servicenow.com) [38] En la primera opción se muestran referencias con el uso de la propia instancia, las dos menciones de cliente y manejo de base de datos se incluirían en este punto ([4.5.1.1] GlideRecord (Gestión Base de datos) y [4.5.1.2] GlideForm (Cliente)). Por otro lado, el segundo punto se ha explotado mucho con funciones como la de [4.5.1.3] JSON - Global, propias para integraciones con API REST. Haciendo click sobre ellas, veremos su documentación con alto detalle proporcionada por ServiceNow. 4.5.2 Angular Angular es un framework de aplicación web de código abierto, mantenido por Google. Permite mejorar las aplicaciones basadas en navegador con el patrón modelo vista controlador (MVC), facilitando así el desarrollo y las pruebas. Angular lee HTML y en sus etiquetas se le indica atributos personalizados adicionales, estos atributos se manejan con JavaScript normalmente, toda la parte de Front de Servicenow, denominada ServicePortal se realiza mediante Angular. 4.5.3 AJAX AJAX son las siglas de Asynchronous JavaScript and XML, es un grupo de técnicas de desarrollo del lado del cliente interrelacionadas que se utilizan para crear aplicaciones web asíncronas. AJAX permite que las aplicaciones web envíen y recuperen información hacia y desde un servidor en segundo plano, sin afectar a la experiencia del usuario con la página web mostrada. Es realmente útil y necesario para el desarrollo del proyecto, ya que nos permite interactuar con diversos elementos web a nivel de cliente que se comunican en tiempo real con el servidor, todo ello sin deber refrescar la página web pro cada interacción, consiguiendo que estas operaciones entre cliente y servidor sean invisibles para el usuario. 39 ServiceNow nos ofrece alguna características propias y específicas, como siempre la plataforma nos ofrece documentación sobre ellas: AJAX | ServiceNow Docs [39]. En mi caso pondré un pequeño fragmento de código por parte de cliente y servidor para comprender su funcionamiento. El cliente solicitará un listado de usuarios que cumplan una condición y el cliente lo recibirá. Script Cliente: var invoiceApprovals = new GlideAjax('AjaxInvoiceApprovals'); //LLamada al Ajax invoiceApprovals.addParam('sysparm_name', 'getUsers'); //Se llama a la función invoiceApprovals.addParam('sysparm_nameID', g_form.getValue('u_invoice_type')); //Se pasa parámetro a función invoiceApprovals.getXML(UsersList); //cuando responde el servidor function UsersList(response) { var users = []; Ilustración 12 Esquema de funcionamiento Ajax Obtenido de w3schools [49] 40 var fromScriptInclude = response.responseXML.documentElement.getAttribute("answer"); users = JSON.parse(fromScriptInclude);//Se recibe array users //Se guardan en un campo los usuarios obtenidos en servidor g_form.setValue('u_invoice_approvers', users.join(',')); } Script Servidor: var AjaxInvoiceApprovals = Class.create(); AjaxInvoiceApprovals.prototype = Object.extendsObject(AbstractAjaxProcessor, { getUsers: function() { var answer = ''; //Consulta en servidor para obtener usuarios del sistema var grUsers = new GlideRecord('sys_user'); grUsers.query(); var arrayUsers = []; while (grUsers.next()) { arrayUsers.push(grUsers.getUniqueValue()); } //Pasa el objeto a un JSON y almacena en answer usurios. answer = JSON.stringify(arrayUsers); //JSON formatted string } return answer; }, } 41 5 ANÁLISIS DEL PROYECTO Una vez detallado el entorno y herramientas para el desarrollo en el capítulo anterior, en el presente se procederá con el análisis del proyecto. Se incluirán requisitos y riesgos del proyecto. 5.1 REQUISITOS Para poder identificar como y lo que se debe implementar, se debe realizar primero una identificación de necesidades técnicas del proyecto a desarrollar, algunos de ellas coincidirán con los hitos identificados. 5.1.1 Requisitos funcionales. En ingeniería de software, un requisito funcional define una función de un sistema o de su componente, donde una función se describe como una especificación de comportamiento entre salidas y entradas, en este apartado detallaremos los requisitos funcionales del proyecto a realizar. • RF0 El sistema podrá ofrecer realizar peticiones de reserva de salas físicas, pero también enviará invitación a los asistentes para unirse via MS-Teams a la sala. (Modelo hibrido) • RF1 El usuario podrá iniciar sesión tanto en ServiceNow como en MS-Teams con el mismo correo. • RF2 El sistema permitirá obtener el calendario de reservas de salas en ServiceNow. • RF3 El sistema se comunicará e identificará con MS-Teams mediante OAuth 2.0. • RF4 El sistema permitirá generar meetings en MS-Teams a través de API REST. • RF5 El sistema podrá cancelar una reunión previamente creada, obligando a dejar un mensaje explicativo y avisando automáticamente de los asistentes de dicha sala de reunión con dicho mensaje explicativo. • RF6 El sistema podrá modificar los participantes de una sala de reunión. • RF7 El sistema deberá tener aprobación de un grupo de usuarios especifico tanto para la reserva de salas de reunión como para la modificación de salas de reunión. • RF8 Se incorporará un módulo al sistema de registro de incidencias de ServiceNow que permitirá mediante una incidencia, si fuera necesario lanzar una reunión. • RF9 El módulo descrito en el RF8 deberá generar una reunión con el usuario actual y el solicitante de la incidencia de forma automatizada. • RF10 Se pueden añadir asistentes adicionales, en los cuales el sistema solo te mostrará usuarios que tengan asignado correo (Se requiere para enviar petición a TEAMS) • RF11 Tanto en la solicitud de reserva de salas como en la creación de reuniones a través de una incidencia, se deberán comprobar fechas y datos correctos y avisar al usuario en caso de no serlo. • RF 12 El sistema contará con una tabla ‘u_rooms’ que almacena los datos de la sala y si ha sido reservada. 42 • RF 13 El sistema deberá registrar si la ‘u_room’ pasa a estado reservada, los usuarios que han realizado la reserva de la sala, y la hora de reserva de esta. • RF14 Una vez se realice la solicitud de reserva de Sala y se apruebe, cuando está suceda se generará una task en el sistema asignado a un grupo especifico, el cual deberá como tarea revisar la sala física usada y al finalizar esta tarea el sistema marcará como disponible la sala para seleccionarla de nuevo. 5.1.2 Requisitos no funcionales En ingeniería de software, un requisito no funcional (NFR) es un requisito que especifica criterios que pueden utilizarse para detallar el funcionamiento de un sistema, en lugar de comportamientos específicos. Se contrapone a los requisitos funcionales, que definen comportamientos o funciones específicas. • RNF1 La base de datos debe alojarse en ServiceNow. • RNF2 Se utilizará el lenguaje de JavaScript con la API propia de ServiceNow GlideSystem [29]. • RNF3 El sistema deberá tener movilidad y manejarse tanto en sistemas moviles con APP como en navegadores. • RNF4 Seguridad en las comunicaciones con Azure mediante las librerías de autenticación Auth mediante renovación de Tokens • RNF5 Escalable, el sistema será escalable y se podrá ampliar constantemente usuarios y peticiones masivas, sí que esto afecte al sistema. • RNF6 El sistema tendrá como idiomas español e inglés. 43 5.2 DIAGRAMA DE ACTIVIDAD El lenguaje de modelado unificado incluye varios subconjuntos de diagramas, incluidos diagramas de estructura, diagramas de interacción y diagramas de comportamiento. En las siguientes secciones nos centraremos en los diagramas de comportamiento junto con los diagramas de actividad y más adelante en el diseño con los diagramas de casos de uso. Estos diagramas describen lo que debe suceder en el sistema que se está modelando. Las partes interesadas suelen tener muchos problemas a la ahora de especificar un sistema, por lo que una comunicación clara y concisa es muy importante. Los diagramas de actividades pueden ayudar a organizar al personal de desarrollo e interesados para comprender los procesos y comportamientos. Se utilizará un conjunto de símbolos especializados, incluidos símbolos para los pasos de inicio, final, fusión y recepción del proceso, para crear un diagrama de actividades. El diagrama de a continuación ayudará a tener una mejor compresión de una gran parte de la funcionalidad del sistema. Ilustración 13 Diagrama de secuencia de reserva de sala 50 6.1.2 Definición casos de uso. Los casos de uso serán identificados con la nomenclatura de CU y tendrán un código identificador para cada uno de ellos. CU01 Identificarse Descripción Un usuario inicia sesión en el sistema, tanto a través de la web como de la app móvil. Actor Usuario raso Precondiciones Se requiere una conexión internet Postcondiciones Se accede al sistema Flujo normal 1. El usuario accede al sistema accediendo a la url de la instancia https://dev62185.service-now.com/ o bien desde su app en dispositivo móvil. 2. El usuario introduce usuario y contraseña en el sistema. 3. El usuario accede al sistema Flujo Alternativo 2.A El usuario puede recuperar su contraseña y reiniciarla a través de “¿Olvido su contraseña?” Excepciones 2.B Si el usuario escribe su contraseña incorrectamente se le informará. Tabla 36 Caso de uso identificarse CU02 Validar Token Descripción ServiceNow solicita una petición de token desde un perfil de autenticación que se usará cada vez que se efectúa una llamada de API Rest. Actor Consumidor (ServiceNow) Precondiciones Tener perfil de autenticación generado y configurado en Azure y ServiceNow. Postcondiciones Azure devuelve un Token de validación para el sistema (ServiceNow). Flujo normal 1. Siempre que hay una llamada de API REST hacia Azure Excepciones 1.A Si los tokens no son válidos, Azure devolverá un error con código 403, informando de que revisemos los tokens. Tabla 37 Caso de uso Validar Token 51 CU04 Solicitud Reunión en MS-Teams desde Incidencia Descripción Un usuario, podrá solicitar una reunión en una incidencia. Actor Usuario raso Precondiciones Acceso a incidencia y en estado activa Postcondiciones Se envía una invitación de reunión de MS-Teams. Flujo normal 1. El usuario accede a una incidencia activa, una vez en ella pulsará en el botón “Nueva reunión en MS-Teams” 2. El sistema le obligará a rellenar una fecha y hora en la que transcurrirá la reunión y como opcional se permitirán añadir asistentes adicionales, serán usuarios del sistema. 3. El sistema comprobará las fechas, si las fechas son correctas, enviará una reunión de teams al usuario que pulsó el botón y al solicitante de la incidencia, si hubiera rellenado usuarios adicionales, también mandará convocatoria a todos ellos. 4. El sistema dejará constancia de la convocatoria sobré esta incidencia, dejando un mensaje permanente en la actividad de la incidencia. Excepciones 2.B Si el usuario indica las fechas pasadas a la actualidad o el fin de la reunión de una reunión es una fecha previa a la del comienzo, el sistema no dejará avanzar y mostrará mensajes informativos. Tabla 38 Caso de uso Solicitud Reunión en MS-Teams desde Incidencia CU07 Consultar calendario reserva de sala Descripción El usuario tendrá a su disposición un calendario, donde aparecerán todas las reservas actuales de salas, con horas y usuarios que hicieron reserva de sala. Actor Usuario raso Postcondiciones El sistema mostrará un calendario de reservas Flujo normal 1. El usuario tendrá en su home un calendario con reservas de salas. 2. Podrá interactuar con las reservas haciendo click en ellas. 3. El sistema les mostrará datos de la reserva, tales como la fecha, hora y usuarios que asistirán a la reserva. Tabla 39 Caso de uso Consultar calendario reserva de Sala 52 CU08 Petición reserva de sala Descripción El usuario tendrá disponible en el catálogo de peticiones “Solicitar sala de conferencias” para realizar una reserva digitalmente. Actor Usuario raso Precondiciones Disponibilidad de al menos una sala libre en el sistema. Postcondiciones Se realiza una reserva en el sistema y queda registrada. Flujo normal 1. El usuario accederá en el catálogo de peticiones a “Solicitar sala de conferencias” 2. El sistema le obligará a indicar participantes, hora y fecha 3. El usuario indicará fecha y hora. 4. El sistema obligará a seleccionar una Sala de un listado que proporcionará, con salas disponibles. 5. El usuario seleccionará la sala. 6. El sistema indicará al usuario que está pendiente de aprobación y mandará notificación y una aprobación a los usuarios pertenecientes al grupo de aprobadores de salas. 7. El usuario aprobador podrá aceptar o rechazar la petición, si se acepta pasará a estado “en progreso” el registro de la tabla Rooms pasará a estado reservado y se enviará una reunión a los usuarios implicados. También se actualizará el calendario con dicha reserva. Flujo Alternativo 7.A El usuario aprobador rechazará la petición, la petición pasará a estado “cancelado” y finalizará, no se modificará la tabla “u_rooms” ni tampoco se enviarán convocatorias de reunión de Teams. Excepciones 2.A Si el usuario indica las fechas pasadas a la actualidad o el fin de la reunión de una reunión es una fecha previa a la del comienzo, el sistema no dejará avanzar y mostrará mensajes informativos. 4.B Si no hay salas disponibles para la reserva, el usuario no podrá llevar a cabo la petición. Tabla 40 Caso de uso Petición reserva de sala 53 CU09 Modificar reserva sala Descripción El usuario podrá modificar fechas y horas de una reserva al igual que los asistentes a ella. Actor Usuario Raso Precondiciones Debe existir una petición previa a la cual se debe tener acceso y en estado “en progreso”. Postcondiciones Se modificará los datos de la reserva y enviará un correo a los afectados. Flujo normal 1. El usuario accederá a una petición en progreso, modificará datos de fechas o asistentes y tendrá disponible el botón “modificar evento”. 2. El sistema modificará los datos cancelando la anterior reserva si se ha modificado fecha y hora deberá ser aprobada de nuevo la solicitud y el estado de la petición pasará a pendiente de aprobación para los nuevos datos. 3. El usuario aprobador podrá aceptar o rechazar la petición, si se acepta pasará a estado “en progreso” el registro de la tabla Rooms pasará a estado reservado y se enviará una reunión a los usuarios implicados. También se actualizará el calendario con dicha reserva. Flujo Alternativo 3.A El usuario aprobador rechazará la petición, la petición pasará a estado “cancelado” y finalizará, no se modificará la tabla “u_rooms” ni tampoco se enviarán convocatorias de reunión de Teams. Excepciones 1.A Si el usuario indica las fechas pasadas a la actualidad o el fin de la reunión de una reunión es una fecha previa a la del comienzo, el sistema no dejará avanzar y mostrará mensajes informativos. Tabla 41 Caso de uso Modificar reserva Sala CU10 Cancelar reserva sala Descripción El usuario podrá cancelar una petición de reserva de Sala Actor Usuario Raso Precondiciones Debe existir una petición previa a la cual se debe tener acceso y en estado “en progreso”. Postcondiciones Se cancelará la reserva y se notificará a los usuarios, por último, se actualizará el calendario de reservas. Flujo normal 1. El usuario accederá a una petición en progreso, modificará datos de fechas o asistentes y tendrá disponible el botón “Cancelar evento”. 2. El sistema obligará a indicar un motivo de la cancelación. 3. El usuario escribirá el motivo que vea oportuno. 4. El sistema cancelará la reserva y el estado de la petición pasará a estado cancelado. Por otro lado, cancelará la reunión online de MS-Teams y se informará del motivo descrito por el cual se cancela la reserva, finalmente la petición finalizará quedando en estado cancelada. Tabla 42 Caso de uso Cancelar reserva sala 54 CU11 Aprobar solicitud Descripción Cada vez que se realicen solicitudes, se generará una aprobación, las aprobaciones se generarán para los usuarios que pertenezcan al grupo “AprobadoresSalas” Actor Usuario aprobador Precondiciones Debe existir una petición en estado “pendiente de aprobación”. Postcondiciones La petición cambiará a estado en progreso y se generará una reserva. Flujo normal 1. El sistema mostrará a los usuarios aprobadores un módulo “Mis aprobaciones”, donde se les mostrará todas aprobaciones pendientes. 2. Accederán a una aprobación y dentro de ella podrán rechazarla o aprobarla y dejar un comentario opcionalmente. 3. El sistema si se acepta la aprobación, pasará a estado “en progreso” la petición y el registro de la tabla Rooms pasará a estado reservado y se enviará una reunión a los usuarios implicados. También se actualizará el calendario con dicha reserva. Flujo Alternativo 3.A El usuario aprobador rechazará la petición, la petición pasará a estado “cancelado” y finalizará, no se modificará la tabla “u_rooms” ni tampoco se enviarán convocatorias de reunión de Teams. Tabla 43 Caso de uso Aprobar solicitud CU12 Completar tarea finalizar reserva sala Descripción Cuando la solicitud esté en “work in progress”, cuando finalice la reunión, se generará una tarea automáticamente de “finalización de reserva”. Actor Conserje Precondiciones Debe existir una petición en estado “en progreso”. Postcondiciones La petición cambiará a estado finalizado y se finalizará la reserva de una sala. Flujo normal 1. El sistema mostrará un módulo “Mi trabajo”, donde se les mostrará todas las tareas pendientes del usuario. 2. El usuario accede a una tarea de finalización de reserva y la completará. 3. El sistema marcará la sala como disponible y podrá ser seleccionada y futuras peticiones de reserva de sala. Tabla 44 Caso de uso Completar tarea finalizar reserva sala 55 6.2 MODELO CONCEPTUAL En esta sección se plasmará un modelo conceptual de los conceptos más destacados, donde se reflejará los principios de diseño para la realización de una petición de reserva. Presentando una ontología de comportamientos/conceptos y relaciones mediante multiplicidad que suceden en el sistema. Ilustración 15 Modelo conceptual reserva 56 6.3 MODELO LÓGICO En la presente sección se incluirá el detalle de las tablas descritas en el apartado anterior con los atributos que contienen las tablas y sus relaciones. Las relaciones en el sistema de ServiceNow se realizan mediante campos referenciados a un registro [40]. Cualquier campo referenciado en la tabla tiene un GUID (Globally Unique ID) único de 32 caracteres, llamado Sys ID (sys_id) para identificar cada registro en una instancia. [41]. Los campos/columnas referencias de la tabla se mostrarán en color rojo e internamente tendrán el valor único (sys_id). Hay que destacar que estamos efectuando cambios para adaptar un sistema existente a una integración y necesidad. Salvo la petición (item del catálogo de servicios) y la tabla u_rooms (sala conferencia) que son tablas creadas, el resto de las tablas son propias del sistema de ServiceNow y aunque se realizarán modificaciones sobre ellas son propias del sistema. En este modelo se mostrarán las tablas con su nombre interno en el sistema y sus campos/columnas a detalles, pero siempre basados en los principios de diseño del apartado anterior ([6.2] Modelo Conceptual). Se harán referencia a las tablas con su nombre técnico y sus campos/columnas técnicas también: • Catálogo de peticiones → ‘sc_cat_item’ • Petición reserva (peticiones realizadas) → ‘sc_req_item’ • Aprobación→ ‘sysapproval_approver’ • Sala de reserva→ ‘u_rooms’ • Tarea → ‘sc_task’ • Usuario → ‘sys_user’ • Grupo → ‘sys_user_group’ 57 Ilustración 16 Modelo lógico sistema 58 6.4 PATRONES DE DISEÑO En la ingeniería del software, un patrón de diseño de software es una solución general y reutilizable para un problema que se presenta comúnmente dentro de un contexto dado en el diseño de software. No es un diseño acabado que pueda transformarse directamente en código fuente o máquina. Se trata más bien de una idea o plantilla de cómo resolver un problema que puede utilizarse en muchas situaciones diferentes. Los patrones de diseño son las mejores prácticas formalizadas que el programador puede utilizar para resolver problemas comunes al diseñar una aplicación o un sistema. En este proyecto destacaremos algunos de los patrones de diseños llevado a cabo en este proyecto, algunos de ellos impuestos por la misma plataforma de ServiceNow. 6.4.1 Prototipo Prototipo es un patrón de diseño de creación en el desarrollo de software. Se utiliza cuando el tipo de objetos a crear está determinado por una instancia prototípica, que se clona para producir nuevos objetos. Con este patrón se consigue evitar subclases de un creador de objetos en la aplicación cliente, como hace el patrón Factory y por lo tanto evitar el coste de la creación de un nuevo objeto de la forma estándar (por ejemplo, utilizando "new") cuando es prohibitivo para una aplicación determinada. En el siguiente fragmento se muestra la declaración: var Handler_REST = Class.create(); Handler_REST.prototype = { initialize: function() {}, /*______________________Functions of API____________________________*/ createMeet: function(current) { var nombre = ''; … 6.4.2 Patrón DTO En el campo de la programación un objeto de transferencia de datos (DTO) es un objeto que transporta datos entre procesos. La motivación para su uso es que la comunicación entre procesos suele realizarse recurriendo a interfaces remotas (por ejemplo, servicios web), donde cada llamada es una operación costosa. Dado que la mayor parte del coste de cada llamada está relacionado con el tiempo de ida y vuelta entre el cliente y el servidor, una forma de reducir el número de llamadas es utilizar un objeto (el DTO) que agregue los datos que habrían sido transferidos por las varias llamadas, pero que se sirva de una sola llamada. En la Ilustración 17 DTO mapping data Recuperada de oscarblancarteblog se puede apreciar visualmente lo comentado anteriormente, con acceso a varios objetos, creando un objeto DTO se transmitirá los datos en un único objeto y por lo tanto una única llamada. 59 Ilustración 17 DTO mapping data Recuperada de oscarblancarteblog [42] Si bien un DTO es un objeto plano (se retrasmitirá como una cadena de texto pro la red), este debe cumplir algunos estándares para poder considerar que hemos creado un DTO correctamente: • Solo lectura: Dado que el objetivo de un DTO es utilizarlo como un objeto de transferencia entre el cliente y el servidor, es importante evitar tener operaciones o métodos que realicen cálculos sobre los datos, es por ello que solo deberemos de tener los métodos GET y SET de los respectivos atributos del DTO. • Serializable: Es evidente, que un objeto DTO deberá comunicarse mediante la red, por lo que deberán de poder ser serializables, pero no hablamos solamente de la clase u Objeto que se transmite, sino que también todos los atributos que contenga el DTO deberán ser serializables. Un error habitual es, por ejemplo, crear atributos de tipo Date o Calendar, ya que estos no tienen una forma estándar para serializarse por ejemplo en Webservices o REST. Este patrón es muy común cuando trabajamos con arquitecturas REST y es el caso del presente trabajo. Lo utilizamos por doble partida, por un lado, cuando realizamos una llamada mediante API REST realizamos una trasformación a objeto JSON serializarle y transferible hacia un servidor de Microsoft. Por otra parte, lo utilizamos dentro de las comunicaciones dentro del entorno de ServiceNow. Estas comunicaciones son las que existen en cliente y servidor, en diversas ocasiones hemos mencionado la necesidad del uso de AJAX [4.5.3], cuando lo hacemos realizamos estas comunicaciones de la misma manera con un objeto serializable como es JSON. Ilustración 18 Ejemplo uso patrón DTO en REST Recuperada de arquitectura Java [42] 66 Una vez hemos accedido a una de las peticiones que se centrará el proyecto, encontraremos un menú guiado que irá acompañando al usuario para rellenar los datos necesarios para realizar dicha solicitud. Ilustración 26 Solicitud sala de conferencias ServicePortal 67 Por parte del usuario aprobador dispondrá de una sección mayores de ‘aprobaciones’ en la parte superior donde aceptará y revisará la petición realizada por un usuario raso. Ilustración 27 Aprobación en ServicePortal 68 6.7.2 APP Móvil En esta sección repasaremos muy por encima los elementos que dispondrá para la APP Móvil, simplemente añadir que los usuarios tendrán una funcionalidad muy similar a la que disponemos desde ServicePortal, a continuación 3 imágenes de la interfaz en algunas de las secciones ya vistas anteriormente desde ServicePortal en esta ocasión con un móvil con Android. Ilustración 30 Menú en APP Móvil Ilustración 28Aprobación en App Móvil Ilustración 29 Estado petición en App Móvil 69 6.7.3 Vista técnica (Back) Aunque es una vista importante y la que más funcionalidad ofrece, no permite grandes customizaciones más allá que colores, logo u algunos formularios. Por lo tanto, se añadirá únicamente una pequeña imagen, de cómo se mostraría una solicitud en esta vista para familiarizarnos con ella. Ilustración 31 Petición Reserva de salas en la vista técnica 70 7 IMPLEMENTACIÓN 7.1 PLANTEAMIENTO Una buena realización del proyecto comienza con un buen diseño inicial, que debería sentar las bases y fundamentos para un desarrollo idóneo. En este apartado hablaremos de la Arquitectura que se seguirá para conseguir la integración entre MS-Teams y ServiceNow. 7.2 ARQUITECTURA Sobre la aplicación creada sobre Microsoft Azure, para que pueda acceder a los datos de Microsoft Graph, el usuario o administrador debe otorgarle los permisos correctos a través del proceso de consentimiento. Esta sección enumera los permisos asociados con cada conjunto principal de la API de Microsoft Graph utilizados con la integración de este proyecto. También proporciona información sobre cómo utilizar los permisos. 7.2.1 Autentificación OAuth 2.0. Open Authorization (OAuth) es un estándar abierto para la delegación de acceso, normalmente utilizado como una forma conceder sitios web o aplicaciones el acceso a su información en otros sitios web, sin necesidad de Identificarse mediante contraseña [42]. OAuth proporciona a los clientes un "acceso delegado seguro" a los recursos del servidor en nombre de un usuario propio del recurso. Especifica un proceso para que los propietarios de recursos autoricen el acceso de terceros a sus recursos de servidor sin necesidad de proporcionar credenciales. Diseñado específicamente para trabajar con el Protocolo de Transferencia de Hipertexto (HTTP), OAuth permite esencialmente que un servidor de autorización emita tokens de acceso a clientes de terceros, con la aprobación del propietario del recurso. El tercero utiliza entonces el token de acceso para acceder a los recursos protegidos alojados por el servidor de recursos [43]. 7.2.2 Estructura API de Azure Todas las llamadas a API de Microsft Graph llevarán el siguiente formato [44] [45] , se ha realizado un ejemplo obtenido del propio proyecto, aunque en la documentación de Microsoft muestra una llamada similar, con la operación de tipo GET y su correspondiente respuesta que siempre recibiremos en JSON. Un ejemplo de llamada de tipo GET: GET https://graph.microsoft.com/v1.0/me/ HTTP/1.0 De aquí en adelante, por abreviatura y claridad nos referiremos en la mayoría de las ocasiones a las operaciones directamente, por ejemplo, en el caso de la llamada superior “GET /me” evitando tener que escribir todo el enlace continuamente. Respuesta JSON: { "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users/$entity", "businessPhones": [], "displayName": "Álvaro García Fuentes", 71 "givenName": "Álvaro", "jobTitle": null, "mail": "alvaro[email protected]", "mobilePhone": null, "officeLocation": null, "preferredLanguage": "es", "surname": "García Fuentes", "userPrincipalName": "[email protected]", "id": "c8c527d7-efdd-4067-851e-e9465a0a1053" } Con esto tenemos una visión global de la estructura que va a llevar la comunicación entre ServiceNow y la API de Microsoft. 7.2.3 Operaciones API Implicadas para la integración de MS-TEAMS. En esta sección, detallaremos las principales operaciones de la API que se utilizarán en el proyecto, aunque se van a mencionar las principales en la documentación del proyecto, siempre serán más detalladas y actualizadas en la documentación propia de Microsoft [45], la cual se ha consultado para realizar esta sección. Todas las operaciones requerirán de una doble autentificación mediante un token, el cual irá en la cabecera de la llamada https, sin él no se podrá ningún tipo de operación, este token es de doble validación y se configura con la nueva aplicación en Azure como se detalló en la sección [7.3.1.1] Creación y configuración de nueva aplicación en Azure , también cada operación requerirá unos permisos propios de Azure que nuevamente se detallarán en la sección [7.3.1.1] Creación y configuración de nueva aplicación en Azure y la sección de a continuación [7.2.4] Permisos necesarios sobre la API. Por último, hablaremos de la función de búsqueda de usuarios y grupos sobre la API, esta permite que la aplicación busque cualquier usuario o grupo en el directorio de la organización (Usuarios en Azure) consultando el conjunto de recursos / users o / groups, por ejemplo, una llamada sería https://graph.microsoft.com/v1.0/users. (El formato de las llamadas lo leímos en la sección anterior [7.2.2] Estructura API de Azure y a su vez encontraremos más ejemplos en la siguiente sección actual) Los administradores y los usuarios pueden realizar esta función, pero los usuarios invitados no. Esto toma importancia, al tener cuenta que la integración lleva una autentificación OAuth 2.0, donde durante la configuración del consumidor de la API, en este caso ServiceNow, deberá indicarse un usuario propio de Azure ( [7.3.2.1] Configurar Credenciales ) y del cual dependerá el acceso a las llamadas de la API, todo esto adicionalmente a los propios permisos de la API que detallados en la sección [7.2.4] Permisos necesarios sobre la API. Si el usuario que inició sesión es un usuario invitado, según los permisos otorgados a la aplicación, puede leer el archivo de configuración de un usuario o grupo específico por ejemplo /users /c8c527d7-efdd-4067-851e-e9465a0a1053, pero no puede consultar conjuntos de recursos /usuarios o /grupos que pueden devolver varios recursos. 72 7.2.3.1 Operación GET: Enumerar usuarios Será el nexo de todas las operaciones, ya que partiremos de ella en diversas ocasiones, para obtener id de usuarios, ids de grupos, ids de equipos, ids de calendarios etc. Mostraré un primer ejemplo detallado para esta a operación, para mostrar una llamada de tipo GET, las pruebas y el desarrollo se han llevado sobre una corporación de pruebas “TFG947.onmicrosoft” y con unos únicamente dos usuarios, pero sería suficiente para ver el formato de respuesta para este tipo de operación. Ejemplo Llamada GET /users: GET https://graph.microsoft.com/v1.0/users HTTP/1.1 Respuesta: { "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users", "value": [ { "businessPhones" : [], "displayName": "Álvaro García Fuentes", "givenName": "Álvaro", "jobTitle": null, "mail": "[email protected]", "mobilePhone": null, "officeLocation": null, "preferredLanguage": "es", "surname": "García Fuentes", "userPrincipalName": "[email protected]", "id": "c8c527d7-efdd-4067-851e-e9465a0a1053" }, { "businessPhones": [], "displayName": "Carlos test", "givenName": null, "jobTitle": null, "mail": null, "mobilePhone": null, "officeLocation": null, "preferredLanguage": null, "surname": null, "userPrincipalName": "[email protected]", "id": "1c14f4db-f83f-4908-80a5-8d0613084049" } ] } Documentación de la operación: List users - Microsoft Graph v1.0 | Microsoft Docs [46] 73 7.2.3.2 Operación de GET: Obtención de reuniones de calendario Permitirán buscar reuniones existentes o comprobar horas libres sobre los usuarios de la corporación. Operaciones más útiles: GET /me/calendars GET /users/{id | userPrincipalName}/calendars Documentación de la operación: List calendars - Microsoft Graph v1.0 | Microsoft Docs [47] 7.2.3.3 Operación POST: Crear nueva reunión en MS-Teams Es una de la operación más importante para este proyecto, al ser la primera operación de tipo post, por lo tanto, daremos mayor detalle sobre ella pondremos algunas, la operación se realizará a través de la operación /me/events POST https://graph.microsoft.com/v1.0/me/events Las operaciones de tipo POST, tienen dos diferencias con respecto a las operaciones GET anteriores: 1. A mayores de él token de validación en el encabezado que será obligatorio como en cualquier petición, en las operaciones de tipo post, será obligatorio pasar en el encabezado el ‘content type’ que deberá contener el valor ‘application/json’ necesario para especificar los datos proporcionados al servidor. 2. Deberemos enviar nosotros un JSON, con los datos de los asistentes a la reunión fecha de inicio, fin, ubicaciones… etc. Para mayor facilidad a continuación se adjunta un ejemplo de un JSON, de un pequeño ejemplo de creación de meeting: { "subject": "Reunión de TEST", "body": { "contentType": "HTML", "content": "Reunion solicitada desde ServiceNow!" }, "start": { "dateTime": "2021-08-30T11:00:00", "timeZone": "Pacific Standard Time" }, "end": { "dateTime": "2021-08-30T12:00:00", "timeZone": "Pacific Standard Time" }, "attendees": [ { "emailAddress": { "address": "[email protected]", "name": "Álvaro García" }, "type": "Required" }, { "emailAddress": { 74 "address": "[email protected]", "name": "Usuario de test" }, "type": "Required" } ], "location": { "displayName": "Sala 2 de la oficina" "locationType": "Default" }, "locations": [ { "displayName": "Conf Room 2" }, { "displayName": " Conf Room 2", "address": { "street": "Paseo zorrilla 112", "city": "Valladolid", "state": "Castilla y León", "countryOrRegion": "Spain", "postalCode": "47008" }, "coordinates": { "latitude": 41.618446, "longitude": -4.748194 } }, { "displayName": "Home Office" } ], "allowNewTimeProposals": true } Debemos recibir un status 201 como respuesta al igual que otro objeto con la confirmación de datos, para confirmar que se ha creado correctamente el meeting de teams. Es importante guardar el atributo "id” del objeto que nos responde el servidor, lo almacenaremos en la propia instancia de ServiceNow, este “id” servirá para identificar este evento si fuera necesario, por ejemplo, para eliminarlo. Para más información y precisión sobre esta operación, como ya se ha indicado en puntos anteriores se debe consultar la documentación de Microsoft, la de esta operación en concreto es la siguiente Crear evento - Microsoft Graph v1.0 | Microsoft Docs 7.2.3.4 Operación de POST: cancelar reunión Esta operación permite al organizador de una reunión enviar un mensaje de cancelación y cancelar el evento. Está operación se utilizará por doble partida, ya que desde la plataforma de ServiceNow se permitirá modificar un evento, pero, aunque para el usuario final es invisible, por debajo consistirá en cancelar el actual evento y lanzar uno nuevo con las modificaciones que realice. Esta acción difiere de Eliminar en que Cancelar está disponible solo para el organizador y permite que el organizador envíe un mensaje personalizado a los asistentes sobre la cancelación. 75 En nuestro caso el mensaje que se enviará a los asistentes de la cancelación del evento será un campo previamente obligatorio en ServiceNow. La operación se realizará a través de la operación /users/{id}/events/{idDelEvento}/cancel POST users/{id | UserPrincipalName}/events/{id}/cancel Como será una operación de tipo POST: 1. Será obligatorio el encabezado con ‘content type’ que deberá contener el valor ‘application/json’ necesario para especificar los datos proporcionados al servidor. 2. A continuación, generaremos un JSON con el formato que nos dicta Azure, y como en el resto de las operaciones proporcionamos un pequeño ejemplo. { "Comment": "Cancelo la reunión de esta semana por motivos de salud" } 7.2.4 Permisos necesarios sobre la API En el apartado anterior se ha especificado las operaciones utilizadas, ahora bien, la política de Microsoft nos obliga a delegar o bien conceder unos permisos para que la API pueda actuar sobre los datos, por lo tanto, para obtener el correcto funcionamiento de las operaciones API es importante conceder unos permisos adecuados. Durante la sección de [7.3.1.1] Creación y configuración de nueva aplicación en Azure , se redacta en el punto y apartado donde conceder estos permisos. Los permisos propios de Microsoft Graph siguen la siguiente nomenclatura como identificación: recurso.operación.restricción. Algunos ejemplos, User.Read concede el permiso para leer los datos del usuario que ha iniciado sesión, User.ReadWrite concede el permiso para leer y modificar los datos personales del usuario que ha iniciado sesión y Mail.Send concedería el permiso para enviar correo en nombre del usuario. 7.2.4.1 Permisos sobre reuniones en linea de MS-Teams Permiso Descripción Ejemplo operación OnlineMeetings. Read Operación que permite obtener los detalles de la reunión en línea en nombre del usuario que inició sesión OnlineMeetings.Read: recupera las propiedades y relaciones de una reunión en línea: GET /beta/communications/onlinemeetings/{default id} OnlineMeetings. ReadWrite Operación para crear y ver reuniones en línea en nombre del usuario que inició sesión. OnlineMeetings.ReadWrite.All: crea una reunión en línea: POST /beta/communications/onlinemeetings Tabla 45 Operaciones sobre reuniones en linea de MS-Teams 82 autorización como el tipo de concesión predeterminado cuando el PKCE está habilitado. Es opcional Application Application scope Accessible from Application scope desde la que es accesible. Active Debe estar marcado el check Authorization URL OAuth authorization code endpoint. Introducir https://login.microsoftonline.com/<DirectoryID>/oauth2/v2.0/authorize Token URL OAuth server token endpoint. Introducir https://login.microsoftonline.com/<Directory-ID>/oauth2/v2.0/token Token Revocation URL OAuth server token revocation endpoint. Es opcional Redirect URL OAuth callback endpoint. Introducir https://<instance-name>.servicenow.com/oauth_redirect.do Use mutual authentication Opción para usar la autenticación mutua para la solicitud y revocación de tokens. Esta opción requiere que se especifique un perfil de autenticación mutua. Es opcional Send Credentials Credenciales de cliente en la solicitud. Una vez relleno debería quedar algo similar a lo siguiente: Ilustración 39 Configuración OAuth Se deberá insertar los siguientes registros en la OAuth Entity Scopes related list. Registro 1 en la OAuth Entity Scopes related list Name: auth_code OAuth scope: offline_access Registro 2 en la OAuth Entity Scopes related list Name openid OAuth scope openid 83 Debe quedar similar a Ilustración 40 Parametros OAuth Ilustración 40 Parametros OAuth Click derecho en el form header y click en Save. Se crea y muestra un perfil de entidad OAuth generado por el sistema en el OAuth Entity Profiles related list. En este caso se llamará MS Teams default_profile. Ilustración 41 Perfil OAuth 7.3.2.2 Configurar Credenciales En este caso usaremos una credencial que básicamente funcionará con un token, creado previamente Azure con una fecha de caducidad. Deberemos iniciar sesión una única vez en Azure para identificarnos con este usuario, el resto de consultar y operaciones en la API no será necesario. Nos deberemos dirigir al módulo Connections & Credentials > Credentials. Creamos un nuevo registro,el sistema nos muestra el mensaje, What type of Credentials would you like to create? Deberemos escoger OAuth 2.0 Credentials, en el formulario, rellenamos los campos. Campo Funcionalidad Name Nombre para identificar de forma única el registro. Por ejemplo, MSTeamsCredentials. Active Se debe dejar en Activo. OAuth Entity Profile El perfil de OAuth creado en el paso anterior de Microsoft Teams Graph por el sistema. En esta situación lo denominamos MS Teams default_profile. 84 Applies to MID Servers que puede utilizar esta credencial. Por ejemplo, seleccionamos All MID Servers. Order Orden en que se utilizan las credenciales. Por ejemplo, escribimos 100. Tabla 49 Configuración credenciales Click derecho en el form header y click en Save. Para generar el token OAuth, haga clic en el botón Get OAuth Token related link. Nos parecerá una Ventana de tipo Pop-up, deberemos iniciar sesión en Azure con una cuenta, importante tener cuenta que, a pesar de proporcionar permisos a la APP de Azure, si accedemos con una cuenta sin permisos, se quedará con los más restrictivos siempre, de ahí que interese acceder con una cuenta con ciertos permisos en Azure. Ilustración 42 Inicio Sesión con cuenta de Azure Una vez iniciemos sesión con la cuenta de Azure, ServiceNow nos informará de cuando expirará el token, que coincidirá con las fechas que se establecieron en la app de Azure. Ilustración 43 Mensaje Informativo Token 7.3.2.3 Web Services Por último, deberemos configurar los WebServices, esto estarán basados en HTTP y permiten que diversas aplicaciones se comuniquen entre sí. ServiceNow admite servicios web entrantes (proveedor) y salientes (consumidor). En el WebService, deberemos indicar un EndPoint que será https://graph.microsoft.com/ , el tipo de autentificación a usar en nuestro caso OAuth 2.0 y seleccionar como perfil OAuth 2.0 creado en el apartado anterior [7.3.2.2] Configurar OAuth 2.0 . 85 Ilustración 44 WebService en ServiceNow Un WebService es un contenedor y este contendrá HTTP Methods, será necesario un Method por cada operación API. A continuación, vemos como se declara un método HTTP. 86 Ilustración 45 Operación API REST en ServiceNow Una vez, se ha realizado esta configuración de toda la sección de [7] Implementación , podremos realizar un desarrollo con llamadas a API de Azure, como último recurso daré un pequeño fragmento de código con una llamada de ejemplo a un método HTTP a través de código. try{ var r = new sn_ws.RESTMessageV2('AzureSILVERGlobal', 'Post Meet'); r.setHttpMethod('get'); //override authentication profile //authentication type ='basic'/ 'oauth2' //r.setAuthenticationProfile(authentication type, profile name); var bodyMeet = '{ "startDateTime":"2019-07-12T14:30:34.2444915-07:00", " endDateTime":"2019-07-12T15:00:34.2464912-07:00", "subject":"Reunión: ' + ro om + ' ' + reason + '" }'; var rM = new sn_ws.RESTMessageV2('AzureSILVERGlobal', 'Post Meet'); rM.setRequestBody(bodyMeet); var responseM = rM.execute(); var responseBodyM = responseM.getBody(); var httpStatusM = responseM.getStatusCode(); 87 //Se recoge el atributo de respuesta del servidor, para identificar la reunió n en el futuro enlaceMeet = JSON.parse(responseBodyM.toString()).joinUrl; } catch(ex){ var message = ex.getMessage(); gs.info(message); } Como suele ser habitual, en la documentación de ServiceNow podemos obtener con una información más amplia todo lo relacionado RestMessageV2: RESTMessageV2 - Scoped, Global | ServiceNow Developers [48] Con esta última configuración se pone punto y final a lo necesario de una manera muy general y extrapolable a otras operaciones de cómo llevar a cabo la implementación de este proyecto u otros similares con API Rest entre ServiceNow y Microsoft Azure. 88 8 DESPLIEGUE En esta sección se darán las indicaciones apropiadas para el despliegue del sistema, al tratarse de un desarrollo totalmente en Cloud, apenas necesitaremos más que un navegador y en algunos casos y si se desea de un SmartPhone. En el caso del acceso mediante el navegador, no habrá que realizar ninguna operación, ya que si disponemos de una instancia de ServiceNow y está contratada funciona 24/7 los 365 días del año. (Existen opciones de instancias personales, en este caso solo permanecen activas durante unas horas y se deberán activar manualmente), bastará con acceder en este caso a https://NOMBREINSTANCIA.service-now.com/ a través del navegador. Por otro lado, y en el caso de querer acceder al proyecto mediante un teléfono móvil deberemos recurrir a las aplicaciones oficiales que nos ofrece Servicenow, una vez dentro de ellas se le deberá introducir nuestra instancia y un usuario a ella y así tendremos acceso, al proyecto y a las reservas de salas mediante con integración con MS-Teams. Si disponemos de un teléfono del ecosistema de Apple será a través del siguiente enlace: Now Mobile on the App Store (apple.com) Si, por el contrario, poseemos un teléfono con Android será a través de este enlace: Now Mobile - Apps en Google Play 89 9 CONCLUSIONES Y TRABAJO DEL FUTURO 9.1 CONCLUSIONES Durante la realización de este proyecto he utilizado y sacado utilidad a todas esas “herramientas” que me ha dado el haber pasado por el grado de Ingeniería informática. Por otro lado, me ha permitido entender dos grandes sistemas como es Azure de Microsoft y ServiceNow mediante sus documentaciones. En el caso de Azure, he podido comprobar que con una buena documentación puedes llegar a dominar las funcionalidades y manejo de la plataforma. También me ha permitido conocer el potencial de esta plataforma, pero sobre todo enfrentarme a ella desde el desconocimiento, ya que era un reto nuevo y desconocido para mí. Por otro lado, ServiceNow es una herramienta en la que llevo trabajando en el último año y medio a nivel profesional. Era más conocida para mí, pero siempre se aprende sobre ella y en mi caso he aprendido toda la dinámica de API Rest con la plataforma con una gran profundidad y las posibilidades que puede llegar a ofrecer. También he aprendido a planificar, y lo más importante, ver como surgen imprevistos y que la propia experiencia me irá dictando en dar mejores estimaciones. Siempre suceden imprevistos por muy mínimos que sean. 9.2 TRABAJO FUTURO Este trabajo solo es la base a una simple petición de reuniones y creación de videoconferencias a través de un sistema externo como es Microsoft Teams, pero asentada la base tiene desarrollos y mejoras muy inmediatos partiendo del punto donde se ha quedado el proyecto. Como búsqueda automatizada de horas libres para realizar una reunión, eventos programados…. Por otro lado, Azure muestra mucho potencial y en grandes corporaciones con Azure, se podría llegar a integrar otro tipo de peticiones, más allá de unas reservas de salas de reunión, tales como instalación de software automatizado a través de una solicitud; de manera que, si por ejemplo solicitamos instalar un office 365/Adobe/AutoCAD en nuestro puesto de trabajo y requerimos algún tipo software, si pertenecemos a un directorio Activo propio de MS, se instalaría en nuestro puesto de una manera automatizada, sin necesidad de un técnico físicamente. Al final, lo que se intenta conseguir con la digitalización de procesos es esa sencillez y accesibilidad y de la mano de Microsoft y ServiceNow se demuestra que es una buena pareja de baile para conseguirlo. 90 10 A. MANUALES 10.1 MANUAL RESERVA DE SALAS Este Anexo tratará de dar un pequeño tour por los elementos más importantes del proyecto, aunque es una interfaz no tiene mucha complejidad, sí que es conveniente dar unas pequeñas instrucciones de como moverse por la plataforma. 10.1.1 Solicitud Sala Uno de los elementos que se han desarrollado durante este proyecto es la digitalización del proceso de salas, para ello deberemos hacer al catálogo de solicitudes. Tenemos diversas maneras de hacerlo, Ilustración 46 Pantalla principal SP Ilustración 46 Pantalla principal SP Una vez hemos accedido al catálogo de servicios tendremos varías de buscar “Solicitar Sala de conferencias”, disponemos de un buscador directamente donde escribirlo, un explorador de categorías y una sección de “elementos populares” se muestra en Ilustración 47 catálogo de Servicios. 91 Ilustración 47 catálogo de Servicios Una vez hemos localizado los elementos debemos rellenar los 5 campos obligatorios, indicando motivo de la reunión, fechas, asistentes y la sala a reservar. (Ilustración 48 Item Solicitar sala de Conferencias) Ilustración 48 Item Solicitar sala de Conferencias 98 Una vez generada la reunión mostrará un mensaje informativo al usuario, indicando que todo ha ido bien, al igual que dejará registrado en las actividades de la incidencia que se ha lanzado una reunión. Ilustración 61 Reunión Lanzada Teams El usuario que pulsó el botón y el solicitante de la incidencia recibirán una reunión a la hora especificada, igualmente se indicarán los datos de la incidencia en el correo. Ilustración 62 Correo Recibido por los usuarios afectados 99 Ilustración 63 Calendario Nativo Windows con evento generado 100 11 BIBLIOGRAFÍA [1] Microsoft, «Información general de Microsoft Graph,» 2021 Abril 24. [En línea]. Available: https://docs.microsoft.com/es-es/graph/overview. [2] « Outlook Calendar REST API reference (version 2.0),» [En línea]. Available: https://docs.microsoft.com/en-us/previous-versions/office/office-365-api/api/version2.0/calendar-rest-operations#GetEvents. [3] EPdata, «El cierre de oficinas bancarias en España, en gráficos,» EPDATA, 4 Mayo 2021. [En línea]. Available: https://www.epdata.es/datos/cierre-oficinas-bancos-espanagraficos-datos/495. [Último acceso: 2021 Mayo 23]. [4] Banco de España, EPData, [En línea]. Available: https://www.epdata.es/datos/cierreoficinas-bancos-espana-graficos-datos/495. [5] Edward Jones, «Cloud Market Share – a Look at the Cloud Ecosystem in 2021,» 21 Abril 2021. [En línea]. Available: https://kinsta.com/blog/cloud-market-share/. [Último acceso: 2021 Abril 23]. [6] Microsoft Corporation, «www.microsoft.com,» Microsoft Corporation, 27 Octubre 2020. [En línea]. Available: https://www.microsoft.com/en-us/Investor/earnings/FY2021-Q1/press-releasewebcast?ranMID=46133&ranEAID=uX9G0lYjaAY&ranSiteID=uX9G0lYjaAY_DOmzuIpKaw7WnfwmAr4bg&epi=uX9G0lYjaAY_DOmzuIpKaw7WnfwmAr4bg&irgwc=1&OCID=AID2000142_aff_7791_1243925&t duid=%28ir__z. [Último acceso: 2021 Marzo 30]. [7] Servicetonic, «¿Qué es un SLA?,» [En línea]. Available: https://www.servicetonic.com/es/service-desk/que-es-un-sla/. [Último acceso: 2021 Junio 5]. [8] «IEEE Transactions on Green Communications and Networking, vol. 4, no. 3, pp. 873889,» IEEE, Septiembre 2020. [En línea]. Available: https://ieeexplore.ieee.org/document/9044834. [Último acceso: 2021 Abril 23]. [9] National Institute of Standards and Technology, «The NIST Definition of Cloud,» [En línea]. Available: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf. [10] M. J. Martín, «Servicios Cloud: ¿Qué es IaaS, SaaS y PaaS?,» 22 Marzo 2019. [En línea]. Available: https://profile.es/blog/servicios-cloud-que-es-iaas-saas-y-paas/. [Último acceso: 2021 Abril 11]. [11] «Top 75 SaaS Companies of 2021,» 2 Semptiembre 2020. [En línea]. Available: https://www.datamation.com/cloud/saas-companies/. [Último acceso: 2021 Junio 6]. [12] «Statista - The Statics of Market Studies,» [En línea]. Available: https://www.statista.com/. [13] «Twilio's REST APIs,» Twilio, 2021. [En línea]. Available: https://www.twilio.com/docs/usage/api. [Último acceso: 23 Mayo 2021]. [14] ServiceNow, «Web services,» ServiceNow, 26 Julio 2018. [En línea]. Available: https://docs.servicenow.com/bundle/quebec-applicationdevelopment/page/integrate/web-services/reference/r_AvailableWebServices.html . [Último acceso: 5 abril 2021]. [15] Microsoft, «Microsoft Teams,» [En línea]. Available: https://www.microsoft.com/eses/microsoft-teams. [Último acceso: 2021 Abril 17]. [16] Li Li; Wu Chou, «ieeexplore.ieee.org,» IEEE, 4-9 Julio 2011. [En línea]. Available: https://ieeexplore.ieee.org/abstract/document/6009431. [Último acceso: 2021 Abril 6]. 101 [17] «Design and implementation a REST API for association rule mining,» 2017. [En línea]. Available: https://ieeexplore.ieee.org/document/8096326. [Último acceso: 2021 Abril 06]. [18] «Qué son los stakeholders, qué tipos existen y de qué manera impactan a una empresa,» 21 Agosto 2019. [En línea]. Available: https://rockcontent.com/es/blog/que-es-unstakeholder/. [Último acceso: 2021 Junio 7]. [19] O. González, «Sprint retrospective,» 24 Marzo 2021. [En línea]. Available: https://www.appvizer.es/revista/organizacion-planificacion/gestion-proyectos/sprintretrospective. [Último acceso: 2021 Junio 8]. [20] «What is a Product Backlog?,» Scrum.org, [En línea]. Available: https://www.scrum.org/resources/what-is-a-product-backlog. [21] Microsoft Corporation, «www.microsoft.com,» Microsoft Corporation, [En línea]. Available: https://www.microsoft.com/es-es/microsoft-365/business. [Último acceso: 06 abril 2021]. [22] Clara Camprovin, «¿IaaS? ¿SaaS? ¿PaaS? Guía para entender Azure,» 2019 octubre 2019. [En línea]. Available: https://www.ibermatica365.com/iaas-saas-paas-guia-paraentender-azure/. [Último acceso: 5 abril 2021]. [23] «Información general de Microsoft Graph,» 05 Marzo 2021. [En línea]. Available: https://docs.microsoft.com/es-es/graph/overview. [Último acceso: 2021 Abril 7]. [24] «Microsoft Teams for Education adds assignments and grading features,» 11 Mayo 2018. [En línea]. Available: https://www.onmsft.com/news/microsoft-teams-foreducation-adds-assignments-and-grading-features. [Último acceso: 2021 Abril 7]. [25] «Creación de conectores de Office 365 para Microsoft Teams,» 19 Abril 2019. [En línea]. Available: https://docs.microsoft.com/es-es/microsoftteams/platform/webhooksand-connectors/how-to/connectors-creating. [Último acceso: 2021 abril 07]. [26] Nishanth Nadarajah, «Now available: Outlook add-in to schedule meetings in Microsoft Teams,» 31 Julio 2017. [En línea]. Available: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/now-available-outlookadd-in-to-schedule-meetings-in-microsoft/ba-p/71157. [Último acceso: 2021 Abril 07]. [27] Mozilla, «Teams,» 23 Abril 2020. [En línea]. Available: https://foundation.mozilla.org/en/privacynotincluded/teams/. [Último acceso: 2021 Abril 7]. [28] Jeff Schertz, «RealConnect Service Network Communications Explained,» 2019 Marzo 5. [En línea]. Available: http://blog.schertz.name/2019/03/realconnect-servicenetwork-communications-explained/. [Último acceso: 2021 Abril 7]. [29] ServiceNow, «API Reference ServiceNow GlideSystem,» [En línea]. Available: https://developer.servicenow.com/dev.do#!/reference/api/quebec/server_legacy/c_Glid eSystemAPI. [Último acceso: 13 Abril 2021]. [30] ServiceNow, «IntegrationHub,» [En línea]. Available: https://www.servicenow.es/products/integration-hub.html. [Último acceso: 2021 abril 10]. [31] Félix Redondo, «Postman: gestiona y construye tus APIs rápidamente,» 2017. [En línea]. Available: https://www.paradigmadigital.com/dev/postman-gestiona-construyetus-apis-rapidamente/. [Último acceso: 2021 abril 11]. [32] «SoapUI End User License Agreement,» 2019. [En línea]. Available: https://www.soapui.org/developers-corner/soapui-license/. [Último acceso: 2021 abril 11]. [33] «Ferguson Smart, John. Java Power Tools,» Abril 2008. [En línea]. Available: https://archive.org/details/javapowertools00smar/page/n584/mode/2up. [34] [En línea]. Available: https://www.soapui.org/getting-started/#tech-support. [Último acceso: 2021 abril 11]. 102 [35] Microsoft, «Probador de Graph - Microsoft Graph,» 15 Marzo 2021. [En línea]. Available: https://developer.microsoft.com/es-es/graph/graph-explorer. [36] «ECMAScript® 2022 Language Specification,» [En línea]. Available: https://tc39.es/ecma262/#sec-overview. [37] «JavaScript API reference,» [En línea]. Available: https://docs.servicenow.com/bundle/paris-applicationdevelopment/page/build/applications/concept/api-javascript.html. [38] ServiceNow, «REST API reference,» [En línea]. Available: https://docs.servicenow.com/bundle/paris-applicationdevelopment/page/build/applications/concept/api-rest.html#api-rest. [39] ServiceNow, [En línea]. Available: https://docs.servicenow.com/bundle/parisapplication-development/page/script/ajax/topic/p_AJAX.html. [40] ServiceNow, «Data management,» 2020 Junio 20. [En línea]. Available: https://docs.servicenow.com/bundle/paris-platformadministration/page/administer/managing-data/concept/c_DataManagement.html. [Último acceso: 2021 Junio 22]. [41] ServiceNow, «Unique record identifier (sys_id),» [En línea]. Available: https://docs.servicenow.com/bundle/paris-platformadministration/page/administer/tableadministration/concept/c_UniqueRecordIdentifier.html. [42] O. Blancarte, «Data Transfer Object (DTO) – Patrón de diseño,» [En línea]. Available: https://www.oscarblancarteblog.com/2018/11/30/data-transfer-object-dto-patrondiseno/. [43] C. Á. Caules, «REST DTO y JSON Arquitecturas Web y objetos,» 12 Marzo 2019. [En línea]. Available: https://www.arquitecturajava.com/rest-dto-y-json-arquitecturasweb/. [44] G. Henry, «Justin Richer on OAuth,» vol. 37, nº 1. [45] « The OAuth 2.0 Authorization Framework,» [En línea]. Available: https://datatracker.ietf.org/doc/html/rfc6749. [Último acceso: 2021 Mayo 24]. [46] Microsoft, «Referencia de permisos de Microsoft Graph,» 8 Mayo 2021. [En línea]. Available: https://docs.microsoft.com/es-es/graph/permissions-reference. [Último acceso: 12 Mayo 2021]. [47] Microsoft, «Referencia de la API de REST de Microsoft Graph versión 1.0,» 26 Enero 2021. [En línea]. Available: https://docs.microsoft.com/esES/graph/api/overview?view=graph-rest-1.0. [Último acceso: 23 Mayo 2021]. [48] Microsoft, «Enumerar usuarios,» Microsoft, [En línea]. Available: https://docs.microsoft.com/es-es/graph/api/user-list?view=graph-rest-1.0&tabs=http. [49] Microsoft, «List calendars,» Microsoft, [En línea]. Available: https://docs.microsoft.com/es-es/graph/api/user-list-calendars?view=graph-rest1.0&tabs=http. [50] ServiceNow, «RESTMessageV2 - Scoped, Global,» 1 Junio 2021. [En línea]. Available: https://developer.servicenow.com/dev.do#!/reference/api/orlando/server/sn_wsnamespace/c_RESTMessageV2API. [51] «w3schools,» [En línea]. Available: https://www.w3schools.com/whatis/whatis_ajax.asp.