Desarrollo y despliegue de un sistema CRM escalable basado en Microsoft Azure, Dynamic CRM 365 Online y Azure Functions

Universidad de Valladolid Escuela de Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática (Mención Tecnologías de la información) Desarrollo y despliegue de un sistema CRM escalable basado en Microsoft Azure, Dynamic CRM 365 Online y Azure Functions Autora: Dña. Alba Francisco Gutiérrez Universidad de Valladolid Escuela de Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática (Mención Tecnologías de la información) Desarrollo y despliegue de un sistema CRM escalable basado en Microsoft Azure, Dynamic CRM 365 Online y Azure Functions Autora: Dña. Alba Francisco Gutiérrez Tutor: D. Benjamín Sahélices Fernández Tutor: D. Álvaro Estébanez Barrena Agradecimientos Me gustaría agradecer principalmente a mi tutor Benjamín Sahelices por sus consejos y apoyo en el desarrollo de este proyecto. También me gustaría agradecer a mi tutor dentro de la empresa Everis, Álvaro Estébanez, promotor de la idea detrás de este TFG, por haberme dado la oportunidad de llevarlo a cabo. También quiero agradecer a Alberto Casero, co-tutor de este trabajo dentro de la empresa aunque no aparezca en la documentación. Me gustaría agradecer a mi familia por todo su apoyo, no sólo durante el desarrollo de este proyecto, si no siempre. Gracias a ellos, he podido realizar la carrera que deseaba y emprender cosas que sin ellos no me hubiera atrevido. Y una mención especial a mi pareja, por todo su apoyo y cariño. Siempre dispuesto a escucharme y ayudarme en cualquier circunstancia. Sin su apoyo, este proyecto no hubiera podido llevarse acabo. Resumen El proyecto se basa en la tecnología en la nube, conocida también como servicios en la nube, informática en la nube, nube de cómputo, nube de conceptos o simplemente ”la nube”, la cual es un paradigma que permite ofrecer servicios de computación a través de una red, que usualmente es Internet. Utilizando de base dicha tecnología, se elaborará una solución que permita mantener la persistencia de los registros almacenados en un sistema en la nube, como lo es Microsoft Dynamics 365, en un sistema de bases de datos de Oracle. De esta manera, se pretende mantener un duplicado de la información, que se considere más sensible, en otro sistema. El desarrollo de esta solución se ha enfocado a que la información se almacene de forma autónoma y desatendida. Para ello se ha creado un conjunto de Azure Functions, que son un servicio de proceso sin servidor que permiten ejecutar código a petición sin necesidad de aprovisionar ni administrar explícitamente la infraestructura, que se encargarán de extraer los datos de Microsoft Dynamics 365 y almacenarlos en el sistema de base de datos de Oracle, utilizando el sistema de colas de Service Bus como intermediario. i Índice general Resumen i Índice de figuras v Índice de cuadros vii 1. Introducción 1 1.1. Contexto......................................... 1 1.2. Objetivos ........................................ 1 1.3. Tareasdelproyecto................................... 2 2. Entorno tecnológico 3 2.1. Azure .......................................... 3 2.1.1. ServiceBus ................................... 4 2.1.2. AzureFunctions................................. 7 2.2. MicrosoftDynamics365 ................................ 8 2.3. OracleDatabase..................................... 9 2.4. Lenguajes de programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5. Herramientas ...................................... 10 3. Análisis 11 3.1. Procesodedesarrollo.................................. 11 3.2. Roles y Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Plandeproyecto .................................... 13 3.3.1. Recursos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. Objetivosdelproyecto ................................. 16 3.5. Presupuestoeconómico................................. 21 3.5.1. Costestotales.................................. 23 3.6. Participantes del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.7. Análisisderiesgos.................................... 25 3.8. Planificacióndefases.................................. 32 3.8.1. Fasedeinicio .................................. 32 3.8.2. Fasedeelaboración............................... 33 3.8.3. Fasedeconstrucción .............................. 34 3.8.4. Fasedetransición................................ 35 3.9. Requisitosdelsistema ................................. 36 3.9.1. Funcionales ................................... 36 3.9.2. Nofuncionales.................................. 47 3.10.Actores.......................................... 50 3.11.Casosdeuso....................................... 51 3.12.Diagramadeclases ................................... 65 3.13.Diagramasdesecuencia................................. 66 ii Índice general 4. Diseño 74 4.1. Patrones......................................... 74 4.1.1. Patrón Command and Query Responsibility Segregation (CQRS) . . . . . 74 4.1.2. Patrón Imperative binder ........................... 77 4.1.3. Patrón Transaction Script y Patrón Data Access Object (DAO) ...... 77 4.1.4. Patrón Retry .................................. 77 4.1.5. Patrón Proxy .................................. 78 4.2. Diagramadeclases ................................... 78 4.2.1. Message_SB .................................. 80 4.2.2. CallToCrmCreateUpdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.2.3. CallToCrmDelete................................ 81 4.2.4. ConnectionToOracleCreate . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.2.5. ConnectionToOracleDelete . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.2.6. ConnectToOracleUpdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.2.7. RetryAutomatica................................ 83 4.2.8. ColaManual................................... 84 4.2.9. RegularizaciónDatosCrm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.2.10. EnvioEmailColaMensajesFallidos . . . . . . . . . . . . . . . . . . . . . . . 85 4.2.11.PapeleraReciclaje................................ 86 4.3. DiagramasdeSecuencia ................................ 86 5. Implementación 94 5.0.1. Primeraetapa ................................. 94 5.0.2. Segundaetapa ................................. 94 5.0.3. Terceraetapa.................................. 94 5.0.4. Cuartaetapa.................................. 95 5.0.5. Quintaetapa.................................. 95 5.0.6. Sextaetapa................................... 95 5.0.7. Séptimaetapa ................................. 96 5.0.8. Octavaetapa.................................. 96 5.0.9. Novenaetapa.................................. 97 5.0.10. Décimaetapa.................................. 97 5.0.11. Undécimaetapa ................................ 97 5.0.12. Duodécimaetapa................................ 97 5.0.13. Decimoterceraetapa.............................. 98 5.0.14. Decimocuartaetapa .............................. 99 5.0.15. Decimoquintaetapa .............................. 99 5.0.16. Decimosextaetapa............................... 99 5.0.17. Decimoséptima iteración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.0.18. Decimoctavaetapa............................... 100 5.0.19. Decimonovenaetapa.............................. 101 5.0.20. Vigésimaetapa................................. 101 5.0.21. Vigésimo primera etapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 6. Verificación 102 6.1. Pruebasdecajanegra ................................. 102 6.1.1. Pruebas de caja negra CallToCrmCreateUpdate . . . . . . . . . . . . . . . 102 iii Índice general 6.1.2. Pruebas de caja negra CallToCrmDelete . . . . . . . . . . . . . . . . . . . 103 6.1.3. Pruebas de caja negra ConnectionToOracleCreate . . . . . . . . . . . . . . 104 6.1.4. Pruebas de caja negra ConnectToOracleUpdate . . . . . . . . . . . . . . . 105 6.1.5. Pruebas de caja negra ConnectionToOracleDelete . . . . . . . . . . . . . . 107 6.1.6. Pruebas de caja negra Papelera de reciclaje . . . . . . . . . . . . . . . . . 108 6.1.7. Pruebas de caja negra RetryAutomatica . . . . . . . . . . . . . . . . . . . 109 6.1.8. Pruebas de caja negra EnvioEmailColaMensajesFallidos . . . . . . . . . . . 110 6.1.9. Pruebas de caja negra RegularizaciónDatosCrm . . . . . . . . . . . . . . . 111 6.2. Pruebasdecajablanca................................. 112 6.2.1. Pruebas de caja blanca CallToCrmCreateUpdate . . . . . . . . . . . . . . 112 6.2.2. Pruebas de caja blanca CallToCrmDelete . . . . . . . . . . . . . . . . . . . 114 6.2.3. Pruebas de caja blanca ConnectionToOracleCreate . . . . . . . . . . . . . 115 6.2.4. Pruebas de caja blanca ConnectToOracleUpdate . . . . . . . . . . . . . . . 117 6.2.5. Pruebas de caja blanca ConnectionToOracleDelete . . . . . . . . . . . . . . 117 6.2.6. Pruebas de caja blanca RetryAutomatica . . . . . . . . . . . . . . . . . . . 118 6.2.7. Pruebas de caja blanca EnvioEmailColaMensajesFallidos . . . . . . . . . . 119 6.2.8. Pruebas de caja blanca RegularizaciónDatosCrm . . . . . . . . . . . . . . . 120 7. Conclusiones y trabajo futuro 121 7.1. Conclusiones....................................... 121 7.2. Trabajofuturo ..................................... 121 Bibliografía 122 A. Manual de Instalación 126 B. Manuales de Usuario 134 C. Comparativa: Azure Service Bus vs RabbitMQ 137 iv Índice de figuras 2.1. La plataforma de servicios de Azure admite aplicaciones que se ejecutan en la nube yenlocal......................................... 3 2.2. Modelodecola...................................... 5 2.3. Modelo de cola con tema y suscripciones. . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Funcionalidades de Microsoft Dynamics 365. . . . . . . . . . . . . . . . . . . . . . 8 3.1. Las etapas del modelo en cascada. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Tareasfasedeinicio. .................................. 32 3.3. Diagrama de Gantt de la fase de inicio. . . . . . . . . . . . . . . . . . . . . . . . . 33 3.4. Tareasfasedeinicio. .................................. 33 3.5. Diagrama de Gantt de la fase de elaboración. . . . . . . . . . . . . . . . . . . . . 34 3.6. Tareas fase de construcción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.7. Diagrama de Gantt de la fase de construcción. . . . . . . . . . . . . . . . . . . . . 34 3.8. Tareasfasedetransición................................. 35 3.9. Diagrama de Gantt de la fase de transición. . . . . . . . . . . . . . . . . . . . . . 35 3.10. Diagrama de clases de análisis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.11. Diagrama de secuencia de Create............................ 66 3.12. Diagrama de secuencia de la política de reintentos de Create. . . . . . . . . . . . . 67 3.13. Diagrama de secuencia de Update............................ 68 3.14. Diagrama de secuencia de Delete. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.15. Diagrama de secuencia de la Azure Function encargada de reintentar automáticamentelosmensajes.................................... 70 3.16. Diagrama de secuencia de la Azure Function encargada de reintentar automáticamentelosmensajes.................................... 71 3.17. Diagrama de secuencia de la Azure Function encargada enviar e-mail . . . . . . . 72 3.18. Diagrama de secuencia del programa de consola que regulariza registros . . . . . . 73 3.19. Diagrama de secuencia del Plugin............................ 73 4.1. Aislamientodemodelos. ................................ 74 4.2. Separacióndedatos. .................................. 75 4.3. Modelo Command and Query Responsibility Segregation (CQRS) desarrollado. . . 76 4.4. Diagrama de clases de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.5. Mensaje ......................................... 80 4.6. Function CallToCrm_Create_Update . . . . . . . . . . . . . . . . . . . . . . . . 80 4.7. Function CallToCrm_Delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.8. Function ConnectoToOracleCreate . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.9. Function ConnectoToOracleDelete . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.10. Function ConnectoToOracleUpdate . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.11. Function Retry_automatica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.12.FunctionColaManual.................................. 84 4.13. Function RegularizaciónDatosCrm . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.14. Function EnvioEmailColaMensajesFallidos . . . . . . . . . . . . . . . . . . . . . . 85 v Índice de figuras 4.15. Plugin que salvaguarda los datos de los registros eliminados. . . . . . . . . . . . . 86 4.16. Diagrama de diseño que específica el flujo de los mensajes de Delete desde Microsoft Dynamics 365 hasta Service Bus. ........................... 87 4.17. Diagrama de diseño que específica el flujo de los mensajes de Create desde Service Bus hasta la base de datos de Oracle. . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.18. Diagrama de diseño que específica el flujo de los mensajes de Update desde Microsoft Dynamics 365 hasta Service Bus. ........................... 89 4.19. Diagrama de diseño que específica el flujo de los mensajes de Delete desde Service Bus hasta la base de datos de Oracle. . . . . . . . . . . . . . . . . . . . . . . . . . 90 4.20. Diagrama de diseño de RetryAutomatica ....................... 91 4.21. Diagrama de diseño de PapeleraReciclaje ...................... 92 4.22. Diagrama de diseño de EnvioEmailColaMensajesFallidos . . . . . . . . . . . . . . 93 A.1. Búsqueda un servicio nuevo en Azure.......................... 126 A.2. Creación de un servicio nuevo en Azure. ....................... 126 A.3. Creación de espacio de nombres y elección de suscripción. . . . . . . . . . . . . . . 127 A.4. Creación de una cola................................... 127 A.5. Parámetros de una cola. ................................ 128 A.6. Parámetros de un Topic................................. 128 A.7. Topics........................................... 129 A.8. Parámetros de un Subscription. ............................ 129 A.9. Portal de Azure...................................... 130 A.10.Búsqueda de Plugin Resgistration. . . . . . . . . . . . . . . . . . . . . . . . . . . 131 A.11.Registro de una nueva Assembly. ........................... 131 A.12.Carga de la .dll. .................................... 132 A.13.Registro de un nuevo paso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 A.14.Configuración del nuevo paso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 B.1. Inicio de la aplicación de consola. . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 B.2. Resultados arrojados por la consola. . . . . . . . . . . . . . . . . . . . . . . . . . . 134 B.3. Vista de una entidad concreta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 B.4. Creación de registros en Microsoft Dynamics 365,paso1 .............. 135 B.5. Creación de registros en Microsoft Dynamics 365,paso2 .............. 135 B.6. Creación de registros en Microsoft Dynamics 365,paso3 .............. 135 B.7. Actualización de registros en Microsoft Dynamics 365, paso 1 . . . . . . . . . . . . 136 B.8. Actualización de registros en Microsoft Dynamics 365, paso 2 . . . . . . . . . . . . 136 B.9. Eliminación de registros en Microsoft Dynamics 365,paso1 ............ 136 B.10.Eliminación de registros en Microsoft Dynamics 365,paso2 ............ 136 B.11.Eliminación de registros en Microsoft Dynamics 365,paso3 ............ 136 C.1. Modelo de colas de Service Bus ............................ 139 C.2. Modelo de temas de Service Bus ............................ 140 C.3. Patrón de consumidores de la competencia . . . . . . . . . . . . . . . . . . . . . . 147 C.4. Patrón de consumidores de la competencia . . . . . . . . . . . . . . . . . . . . . . 148 vi Capítulo 1. Introducción Fallos inesperados dentro del procesamiento de las Azure Functions que gestionan los mensajes extraídos de Service Bus. La política de reintentos asociada a estos errores se describirá en detalle en el presente trabajo, además de lo mecanismos implementados para mantener una coherencia entre los datos almacenados dentro de Microsoft Dynamics 365 con los datos que se encuentran en la base de datos de Oracle. 1.3. Tareas del proyecto Para la realización de este proyecto, el cual pertenece a la asignatura de Trabajo de Fin de Grado, se han realizado diferentes tareas. Se ha intentado seguir un procedimiento adecuado y aceptado dentro del marco de la ingeniería. En primer lugar, se analizó la aplicación de Microsoft Dynamics 365. Fue necesario investigar la manera en que genera las entidades y como almacena sus registros internamente para poder extraerlos correctamente y aprovechar las ventajas que ofrece. Por otro lado, también fue necesario investigar Azure. Es una plataforma informática en la nube la cual ofrece un conjunto de herramientas muy útiles, en especial las Azure Functions, que son las herramientas para elaborar este proyecto. Una vez que el marco queda definido es necesario familiarizarse con los lenguajes que se utilizan en el proyecto. La tarea de planificación permite controlar el progreso del proyecto, estudiar su viabilidad y calcular el coste final del mismo, además de permitir definir el alcance del mismo y su duración. En esta fase del proyecto, también es necesario definir que metodología de desarrollo se implementa. El análisis de los requisitos que se piden, incluyendo los funcionales y los no funcionales, y partir de ellos, obtener los casos de uso y las herramientas que, finalmente, se implementan en el proyecto. La realización del proyecto final en base de esta fase de análisis y la información obtenida. La implementación del proyecto describirá las etapas por las cuales ha pasado el proceso de desarrollo y las razones que llevaron a tomar ciertas decisiones de diseño, siempre basándose en los requisitos proporcionados por el cliente. El despliegue del sistema dentro Azure, por cuestión de licencias y alcance de los requisitos del proyecto, no se llevará a cabo y permanecerá simulado en un entorno local. La realización de la batería de pruebas y resolución de errores en relación a los fallos detectados mediante las mismas. Finalmente, se agrupa esta información en el presente documento y se prepara la documentación necesaria. 2 Capítulo 2 Entorno tecnológico En las siguientes secciones, se explica más en detalle las particularidades de las tecnologías que se han utilizado para desarrollar el proyecto. 2.1. Azure Azure es una plataforma de nube completa que puede hospedar las aplicaciones existentes, simplificar el desarrollo de nuevas aplicaciones o mejorar las aplicaciones locales. Azure integra los servicios en la nube que son necesarios para desarrollar, probar, implementar y administrar aplicaciones, mientras se aprovechan las ventajas en la nube. Con el hospedaje de las aplicaciones en Azure, se puede empezar con tamaño pequeño y escalar fácilmente una aplicación a medida que aumente la demanda de los clientes. Azure ofrece también la confiabilidad que se necesita para las aplicaciones de alta disponibilidad, e incluye conmutación por error entre diferentes regiones. Azure Portal le permite administrar fácilmente todos los servicios de Azure. También puede administrar los servicios mediante programación, con las API y las plantillas específicas del servicio [1]. Figura 2.1: La plataforma de servicios de Azure admite aplicaciones que se ejecutan en la nube y en local. 3 Capítulo 2. Entorno tecnológico Azure proporciona las ventajas que ofrece la nube pero, además, es una solución abierta y flexible. Azure Cloud es compatible con una variedad de sistemas operativos, idiomas, herramientas, plataformas, utilidades, y marcos. Es compatible con Linux y Windows, SQL Server, MySQL, Postgres..., C#, Python, Java, Node.js, Bash y más lenguajes, MongoDB y DocumentDB Bases de datos NoSQL, y Jenkins para VSTS como herramientas de integración continua. Toda la idea detrás de este ecosistema está en permitir a los usuarios poder elegir el lenguaje, la plataforma y el sistema operativo, la base de datos, y el tipo de almacenamiento que les resulte más conveniente, además de herramientas y utilidades. Esto está sujeto a la premisa de que los usuarios no tienen que estar ligados a una tecnología específica, sino concentrarse en crear soluciones de negocio. Azure es compatible con la elección del usuario de la tecnología que más se le adapte. Por ejemplo, Azure proporciona disponibilidad de todos los populares (código abierto o comercial) entornos de bases de datos. Azure proporciona el servicio Azure SQL, MySQL yPostgres PaaS. Eso proporciona un ecosistema de Hadoop y ofrece HDInsight, un PaaS basado en Apado Hadoop al 100 % servicios. También proporciona Hadoop en la implementación de VM de Linux para clientes que prefieren enfoque IaaS. Azure también proporciona un servicio de caché Redis y soporta otros populares entornos de bases de datos, como MongoDB, Couchbase, Oracle y muchos otros como la implementación de IaaS.[2] Windows Azure hace dos cosas principales: ejecuta aplicaciones y almacena sus datos. En las siguientes secciones sólo se mencionan las colas y las Azure Functions, que son una parte relevante de este trabajo. 2.1.1. Service Bus Microsoft Azure Service Bus es un agente de mensajes de integración empresarial completamente administrado. Service Bus se usa normalmente para desacoplar las aplicaciones y los servicios entre sí, además de ser una plataforma segura y confiable para datos asincrónicos, así como la transferencia de estado. Los datos se transfieren entre distintas aplicaciones y servicios mediante mensajes. Un mensaje está en formato binario, que puede contener solo texto, JSON o XML. Algunos escenarios de mensajería comunes son: Mensajería: transferencia de datos de empresa, como ventas o pedidos de compra, diarios o movimientos del inventario. Desacoplamiento de aplicaciones: mejora de la confiabilidad y escalabilidad de las aplicaciones y los servicios (el cliente y el servicio no necesitan estar conectados al mismo tiempo). Temas y suscripciones: habilitación de relaciones 1:n entre publicadores y suscriptores. Sesiones de mensajes: implementación de flujos de trabajo que requieren ordenación en los mensajes o aplazamiento de los mensajes. En relación a Service Bus, es necesario tener en cuenta tres características principales: Espacios de nombres: Un espacio de nombres es un contenedor con un ámbito para todos los componentes de la mensajería. Varias colas y temas pueden residir en un único espacio de 4 2.1. Azure nombres, y los espacios de nombres suelen servir de contenedores de aplicación. Colas: Los mensajes se envían y se reciben desde colas. Las colas permiten almacenar mensajes hasta que la aplicación receptora está disponible para recibirlos y procesarlos 2.2. Los Figura 2.2: Modelo de cola. mensajes de las colas se ordenan y se les asigna una marca de tiempo a su llegada. Una vez aceptado, el mensaje se conserva de forma segura en un almacenamiento redundante. Los mensajes se entregan en modo de extracción, que entrega los mensajes cuando se solicitan. Topic:Los mensajes se envían y se reciben desde colas. Las colas permiten almacenar mensajes hasta que la aplicación receptora está disponible para recibirlos y procesarlos 2.3. Los Topic Figura 2.3: Modelo de cola con tema y suscripciones. pueden tener varias suscripciones independientes. Un suscriptor a un tema puede recibir una copia de cada mensaje enviado a ese tema. Las suscripciones son entidades con nombre, que se crean de forma duradera pero pueden, opcionalmente, expirar o eliminarse automáticamente. Service Bus también tiene características avanzadas que permiten solucionar problemas de mensajería más complejos. A continuación, se describen estas características principales: Sesiones de mensajes: Para realizar una garantía primero en entrar/primero en salir (FIFO) en Service Bus, se usa sesiones. Las sesiones de mensajes permiten la administración ordenada y conjunta de secuencias sin enlace de mensajes relacionados. Reenvío automático: La característica de reenvío automático permite encadenar una cola o suscripción a otra cola o tema que forme parte del mismo espacio de nombres. Cuando el 5 Capítulo 2. Entorno tecnológico reenvío automático está habilitado, Service Bus elimina automáticamente los mensajes que se colocan en la primera cola o suscripción (origen) y los coloca en la segunda cola o en el segundo tema (destino). Colas de mensajes fallidos (DeadLetter): Service Bus admite una cola de mensajes fallidos (DLQ) para mantener los mensajes que no se pudieron entregar a ningún destinatario o los mensajes que no se pudieron procesar. A continuación, permite eliminar mensajes de la cola DLQ y examinarlos. Entrega programada: Se puede enviar mensajes a una cola o un tema para su procesamiento retrasado; por ejemplo, para programar un trabajo de forma que esté disponible para que lo procese el sistema a una hora determinada. Aplazamiento de mensajes: Cuando un cliente de una cola o una suscripción recibe un mensaje que se desea procesar, pero cuyo procesamiento no es posible en ese momento debido a circunstancias especiales dentro de la aplicación, la entidad tiene la opción de aplazar la recuperación del mensaje para un momento posterior. El mensaje permanece en la cola o suscripción, pero se mantiene separado. Lotes: El procesamiento por lotes en el lado del cliente permite que un cliente de una cola o un tema retrase el envío de un mensaje durante un período determinado. Si el cliente envía más mensajes durante este período, los transmite en un único lote. Transacciones: Una transacción agrupa dos o más operaciones en un ámbito de ejecución. Service Bus admite operaciones de agrupación en una sola entidad de mensajería (cola, tema, suscripción) dentro del ámbito de una transacción. Filtrado y acciones: Los suscriptores pueden definir los mensajes que quieren recibir de un tema. Estos mensajes se especifican en forma de una o varias reglas de suscripción con nombre. Con cada condición de regla de coincidencia, la suscripción crea una copia del mensaje, que se puede anotar de manera diferente para cada regla coincidente. Eliminación automática en estado inactivo: La eliminación automática en estado inactivo permite especificar un intervalo de inactividad después del cual se eliminará automáticamente la cola. La duración mínima es de 5 minutos. Detección de duplicados: Si se produce un error que hace que el cliente tenga dudas sobre el resultado de una operación de envío, la detección de duplicados saca de dudas en estas situaciones al permitir que el remitente reenvíe el mismo mensaje y la cola o el tema descartan cualquier copia duplicada. SAS, RBAC e Identidades administradas para recursos de Azure:Service Bus admite protocolos de seguridad como las firmas de acceso compartido (SAS), el Control de acceso basado en rol (RBAC) y Entidades administradas para recursos de Azure. Recuperación ante desastres geográficos: Cuando las regiones o los centros de datos de Azure experimentan un tiempo de inactividad, la recuperación ante desastres geográficos permite que el procesamiento de datos siga funcionando en una región o un centro de datos diferentes. Seguridad: Service Bus admite los protocolos estándar AMQP 1.0 yHTTP/REST. 6 2.1. Azure Por otro lado, Service Bus es compatible con las bibliotecas de cliente para .NET, Java y JMS. Para el desarrollo de este proyecto se utilizarán la biblioteca de .NET.[3] Service Bus no es el único sistema de colas que puede integrarse con Azure, también se podría haber usado el sistema RabbitMQ. La comparativa entre ambos sistemas y las razones por las cuales se ha decidido implementar Service Bus se encuentran en el Anexo C. 2.1.2. Azure Functions Azure Functions es una solución para ejecutar fácilmente pequeños fragmentos de código, o ”funciones”, en la nube. Simplemente, permite escribir el código que se necesita para el problema en cuestión, sin preocuparse de toda la aplicación o la infraestructura para ejecutarlo. Azure Functions permite utilizar el lenguaje de desarrollo que se prefiera, como C#, F#, Node.js, Java o PHP. La idea detrás de la computación sin servidor, también conocida como serverless, es eliminar esas consideraciones de infraestructura para el usuario. Sin servidor, un usuario puede simplemente crear y cargar código, y luego definir los desencadenantes o eventos que ejecutarán el código. Los desencadenantes pueden provenir de una amplia gama de fuentes, incluida la aplicación de otro usuario u otros servicios en la nube, como bases de datos, centros de eventos y notificaciones. En el contexto de este trabajo, los desencadenantes serán los mensajes que se encuentran Service Bus. Una vez que se produce un desencadenante o evento, es responsabilidad del proveedor de la nube cargar el código en un entorno de ejecución adecuado, ejecutar el código y luego liberar los recursos informáticos. Todavía hay servidores involucrados, pero el usuario ya no necesita aprovisionar o administrar instancias de cómputo. Además, en lugar de pagar por esas instancias de cómputo y otros recursos asociados cada mes, los usuarios pagan por la computación sin servidor en función de la cantidad de tiempo que una función se ejecuta en un ciclo de facturación determinado. En este servicio, sólo se paga el tiempo durante el que se ejecuta el código y, si fuera necesario, Azure proporcionaría la infraestructura necesaria para escalarlo fácilmente [4] [5] [6] [7]. Estas son algunas características clave de Azure Functions: Opción de lenguaje: Permite escribir funciones usando el lenguaje C#, F# oJavascript a elección del desarrollador. Modelo de precios de pago por uso: El pago derivado va en relación al tiempo, sólo el que se haya empleado ejecutando el código. Permite exportar otras dependencias: Las Azure Functions admiten NuGet yNPM, que permiten al desarrollador utilizar las bibliotecas que necesite. Seguridad integrada: Permite proteger las Functions desencadenadas por HTTP con los proveedores de OAuth como Azure Active Directory, Facebook, Google, Twitter y cuenta Microsoft. Integración simplificada: Permite aprovechar los servicios de Azure y ofertas de software como SaaS. 7 Capítulo 2. Entorno tecnológico Desarrollo flexible: Permite codificar las Functions directamente en el portal o configurarlas mediante la integración continua y permite implementar el código mediante GitHub, Azure DevOps Services y otras herramientas de desarrollo compatibles. Código abierto : Azure Functions es de código abierto y está disponible en GitHub. Azure Functions ofrecen plantillas para comenzar con situaciones clave, incluidas las siguientes: CosmosDBTrigger: Procesa documentos de Azure Cosmos DB cuando se agregan o se actualizan en las colecciones en una base de datos NoSQL. QueueTrigger : Responde a mensajes conforme llegan a una cola de Azure Storage. ServiceBusQueueTrigger: Permite conectar el código a otros servicios de Azure o servicios locales, mediante la escucha de las colas de mensajes. ServiceBusTopicTrigger: Permite conectar el código a otros servicios de Azure o a servicios locales mediante la suscripción a temas. 2.2. Microsoft Dynamics 365 Un software CRM (Customer Relationship Management) es una solución que permite centrar la estrategia de una empresa entorno al cliente. Es una herramienta que permite identificar clientes potenciales, y ofrecer servicios personalizados a los actuales clientes, con el objetivo de fidelizar y ser más efectivos a la hora de interactuar con estos, como se ve en la imagen 2.4. Figura 2.4: Funcionalidades de Microsoft Dynamics 365. 8 2.3. Oracle Database La decisión de implantar una solución de Customer Relationship Management (CRM) es un paso estratégico hacia la focalización de toda la actividad de la empresa en las necesidades del cliente. Las compañías están cambiando el modelo de negocio porque su futuro depende de: Su capacidad de analizar las preferencias de los clientes La planificación de la producción en función de la demanda del mercado Sus posibilidades de comercializar sus productos o servicios a los clientes adecuados y de la forma más eficiente Microsoft Dynamicss 365 for Sales es el nuevo nombre del anterior Microsoft Dynamics CRM. Se suelen utilizar las dos nomenclaturas para referirse al mismo software. Dynamicss 365 for Sales proporciona al personal de ventas las herramientas necesarias para conseguir relaciones duraderas con los clientes, actuar en consecuencia según los detalles que tengan y cerrar ventas aún más rápido. Dynamicss 365 for Sales se utiliza para realizar el seguimiento de las cuentas y contactos de los usuarios, consolidar una posible venta con un cliente potencial y convertirla en una venta real, crear ventas adicionales, crear listas de marketing y campañas e incluso seguir casos del servicio asociados a cuentas y oportunidades específicas.[8] 2.3. Oracle Database Oracle es básicamente una herramienta cliente/servidor para la gestión de base de datos, es un producto vendido a nivel mundial, aunque la gran potencia que tiene y su elevado precio hace que sólo se vea en empresas muy grandes y multinacionales, por norma general. En el desarrollo de paginas Web pasa lo mismo, como es un sistema muy caro no está tan extendido como otras bases de datos, por ejemplo, Access, MySQL, SQL Server etc. [9] Es el mayor y más usado Sistema Manejador de Base de Datos Relacional (RDBMS) en el mundo. La Corporación Oracle ofrece este RDBMS como un producto incorporado a la línea de producción. Además incluye cuatro generaciones de desarrollo de aplicación, herramientas de reportes y utilitarios. Oracle corre en computadoras personales (PC), microcomputadoras, mainframes y computadoras con procesamiento paralelo masivo. Soporta unos 17 idiomas, corre automáticamente en más de 80 arquitecturas de hardware y software distintos sin tener la necesidad de cambiar una sola línea de código. Esto es porque más del 80 % de los códigos internos de Oracle son iguales a los establecidos en todas las plataformas de sistemas operativos. El poderoso modelo relacional ha evolucionado desde herramientas y los modelos de datos de redes. La mayor aceptación y uso de un modelo de datos es el modelo relacional que fue conocido en 1969 con la revisión hecha por IBM, Dr. E. F. Codd. Este modelo relacional posee tres grandes aspectos: Estructuras: Definición de objetos que contengan datos y que son accesibles a los usuarios. Operaciones: Definir acciones que manipulen datos u objetos. Reglas: Leyes para gobernar la información, cómo y qué manipular. 9 Capítulo 2. Entorno tecnológico Una base de datos relacional es definida como un modelo de información que se puede visualizar, estrictamente, por los usuarios mediante tablas. Una tabla está compuesta por una matriz bidimensional de filas y columnas. La información almacenada, dentro de dichas tablas, puede ser modificada mediante el uso de consultas realizadas por el usuario en el formato de filas/columnas[10]. 2.4. Lenguajes de programación Para el desarrollo de este proyecto, se ha utilizado el lenguaje de programación C#. Este lenguaje, es propiedad de Microsoft como parte de su plataforma .NET que después fue aprobado como un estándar por la ECMA (ECMA-334) e ISO (ISO/IEC 23270). C# es uno de los lenguajes de programación diseñados para la infraestructura de lenguaje común. Su sintaxis básica deriva de C/C++ y utiliza el modelo de objetos de la plataforma .NET, similar al de Java, aunque incluye mejoras derivadas de otros lenguajes. A pesar de que las Azure Functions soportan varios lenguajes, incluidos JAVA yPHYTON, se decidió utilizar este lenguaje, aun siendo necesario aprenderlo para el desarrollo de la aplicación, debido a que es el lenguaje que pertenece a Microsoft y, por tanto, es el que mejor integración tiene con todos sus sistemas y herramientas. 2.5. Herramientas Para el desarrollo del proyecto se han utilizado un conjunto de herramientas. Para el desarrollo y depuración del proyecto se ha utilizado un ordenador portátil Toshiba Satellite P50 con procesador i7-4720HQ y 8 Gb de Ram. Se ha utilizado el sistema operativo W10 puesto que se está desarrollando un proyecto que utiliza la tecnología Microsoft y, como entorno de desarrollo, Visual Studio 2017 enlazado con repositorio TFS que permite un control de versiones y conexión con Azure integrada. Para permitir la conexión con Oracle, se ha instalado una máquina virtual sobre Virtual Box sobre la cual está instalado un servidor de bases de datos. La razón por la cual se ha decidido utilizar un máquina virtual, es debido a la facilidad de administración y mantenimiento de la misma. Resulta sencillo recuperar un servidor alojado en una maquina virtual si se produce algún fallo durante el desarrollo y, por cuestiones de tiempo, limitaciones de presupuesto y requisitos del proyecto, no se podía crear y administrar un servidor completo alojado en la nube o gestionar uno en local que permitiera el acceso desde una aplicación alojada en la nube. 10 Capítulo 3 Análisis En este capítulo se detallarán las cuestiones metodológicas, es decir, las metodologías y herramientas que se han utilizado para plantear el trabajo. También quedarán definidos los requisitos de todos los elementos que conforman el sistema, que se acuerden con el cliente de este proyecto, en el contexto de este trabajo son los tutores. 3.1. Proceso de desarrollo El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo de software se concibe como un conjunto de etapas que se ejecutan una tras otra. Se le denomina así por las posiciones que ocupan las diferentes fases que componen el proyecto, colocadas una encima de otra, y siguiendo un flujo de ejecución de arriba hacia abajo, como una cascada [2]. Figura 3.1: Las etapas del modelo en cascada. 11 Capítulo 3. Análisis Objetivo 004 Nombre Cola de reintentos manual Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción El sistema contará con una cola de reintentos manual. En esta cola quedarán almacenados los mensajes que no se han podidos tratar en Oracle, en relación a errores dentro del mensaje, como pueden ser incongruencias en los datos que se intentan manejar dentro de la base de datos. Estos mensajes deberán ser tratados de manera manual por el equipo de gestión. Para facilitar dicho tratamiento, estos mensajes se insertaran en forma de registro a Microsoft Dynamics 365. Importancia Vital Urgencia Alta Tabla 3.10: Objetivo 004 Objetivo 005 Nombre Envío de email al equipo de desarrollo Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción El sistema deberá mandar un e-mail al equipo de desarrollo, en el momento que se detecte un mensaje dentro de las colas de DeadLetter asociadas a los Topic Importancia Media Urgencia Media Tabla 3.11: Objetivo 005 18 3.4. Objetivos del proyecto Objetivo 006 Nombre Envío de e-mail al equipo de gestión Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción El sistema deberá mandar un e-mail al equipo de gestión, en el momento que se detecte que se han superado el valor de límite de mensajes. En este caso este valor es de 10 registro en Microsoft Dynamics 365, creados por la cola manual. Importancia Baja Urgencia Media Tabla 3.12: Objetivo 006 Objetivo 007 Nombre Regularización de registros. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Se debe de tener un programa de consola que, en el caso de que las Azure Functions que recolectan los registros del CRM, fallen por un intervalo de tiempo determinado, regularicen los registros enviando dichos registros no consumidos, a la cola para su posterior tratamiento en Oracle. Importancia Baja Urgencia Baja Tabla 3.13: Objetivo 007 19 Capítulo 3. Análisis Objetivo 008 Nombre Implementación de cola de reintentos automática. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción El sistema contará con una cola de reintentos automática. En esta cola quedarán almacenados los mensajes que no se hayan podidos tratar en Oracle, por un fallo de conexión con el mismo. En el momento que la Function, asociada a esta cola, detecte que Oracle está de nuevo en funcionamiento, reencolará los mensajes a su suscripción y Topic asociado. Importancia Vital Urgencia Alta Tabla 3.14: Objetivo 008 Objetivo 009 Nombre Plugin para mantener un histórico de registros eliminados. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Dentro del sistema de Microsoft Dynamics 365, habrá instalado un Plugin que, cuando se realice la eliminación de un registro, se encargue de almacenar los datos que serán necesarios para su posterior eliminación en Oracle, dentro de una entidad intermedia que hará las veces de "papelera". Importancia Alta Urgencia Alta Tabla 3.15: Objetivo 009 20 3.5. Presupuesto económico 3.5. Presupuesto económico Para la estimación del presupuesto se tendrán en cuenta las herramientas utilizadas (hardware y software, con los factores de impacto que correspondan a la duración del proyecto), junto con los recursos humanos necesarios, según la planificación de tareas, y el tipo de rol (analista, programador, etc) correspondiente a cada tarea. Para ello conviene tener una tabla actualizada, del coste por hora de cada tarea del proyecto, además del estudio previo de la planificación de tareas. La estimación de los gastos generados se dividirán en tres partes: Hardware, Software y RRHH para facilitar la visualización de los mismos. Hardware Al ser un proyecto enfocado en la nube, el hardware necesario como tal es limitado. En el siguiente presupuesto se incluirá el ordenador portátil que se utilizado para el desarrollo del trabajo 3.16. Coste de recursos de hardware Hardware Coste unitario(e) Cantidad (unidades) Coste(e) Toshiba Satellite P50-B-11L 797,27e1 797,27e Total 797,27e Tabla 3.16: Coste de recursos de hardware Software Para el desarrollo de este presupuesto se ha utilizado la herramienta Azure Pricing [11] Tipo de Servicio Región Descripción Coste estimado Azure Function West US 128 MB de memoria, 30 segundos de tiempo de ejecución y 44.000 ejecuciones/mes 0.00 e Azure Function West US 128 MB de memoria, 30 segundos de tiempo de ejecución y 44.000 ejecuciones/mes 0.00e Azure Function West US 128 MB de memoria, 30 segundos de tiempo de ejecución y 44.000 ejecuciones/mes 0.00e Azure Function West US 128 MB de memoria, 30 segundos de tiempo de ejecución y 1.000 ejecuciones/mes 0.00e Azure Function West US 128 MB de memoria, 30 segundos de tiempo de ejecución y 3.000.000 ejecuciones/mes 174.00e Azure Function West US 128 MB de memoria, 30 segundos de tiempo de ejecución y 3.000.000 ejecuciones/mes 174.00e Azure Function West US 128 MB de memoria, 30 segundos de tiempo de ejecución y 3.000.000 ejecuciones/mes 174.00e Service Bus East US Nivel Basic: <1 millón de operaciones de mensajería/mes 0.00e Support Support 0.00e Licensing Program MOSP Total Mensual 401.60e Total para 4 meses 1.606,4e Tabla 3.17: Presupuesto de servicios de Azure Se debe de tener en cuenta que Oracle proporciona una licencia gratuita para desarrolladores, siempre y cuando, el sistema generado no se use con fines comerciales [3]. Como el presente trabajo 21 Capítulo 3. Análisis Aplicación Aplicaciones disponibles en el plan Precio/Usuario Dynamicss 365 Plan Finance and Operations Retail Talent Customer Service Project Service Automation Field Service Marketing Solución Microsoft Relationship Sales PowerApps para Dynamicss 365 Flow 177.10 e Total (4 meses / un usuario) 2.833,62 e no abarca la implementación de un sistema en producción al uso, no se incluirá gastos por usar el sistema de bases de datos de Oracle. RRHH Nombre del recurso Coste unitario / hora(e) Cantidad (Horas) Coste(e) Jefe de proyecto 55,9 e85 4751,5 e Diseñador 53,9 e38 2048,2 e Desarrollador 31,2 e109 3400,8 e Tester 31,2 e18 561,6 e Analista 38,9 e70 2723 e Total 13.485,1 e Tabla 3.18: Coste de recursos humanos Horas extra En base a los precios aportados anteriormente, y en base a estas condiciones: Las aplicaciones utilizadas para el desarrollo de este proyecto tienen suscripción mensual. Por ello, el presupuesto se ha realizado en base a la duración del TFG, que son 300 horas. Redondeando esta cifra en base a la planificación, son cuatro meses de desarrollo. Se produjo un retraso de quince horas en la fase de desarrollo. Este retraso no impidió completar el trabajo en las fechas previstas, pero aumento el presupuesto en consecuencia 3.19. 22 3.6. Participantes del proyecto Coste extra de la tarea de desarrollo. Rol Coste unitario/Hora Aumento precio/ horas extra Coste total e Desarrollador 31,2 e25 % 585 e Tabla 3.19: Coste de las horas extra realizadas. 3.5.1. Costes totales Finalmente, la estimación del presupuesto queda de la siguiente forma. Este presupuesto no representa, de ninguna forma, todos los gastos que podrían generarse en un proyecto real pero sirve de aproximación: Coste total del proyecto Humanos 14070,1 e Hardware 797,27 e Software 4440,02e Total 19307,39e Tabla 3.20: Coste total del proyecto 3.6. Participantes del proyecto En la siguientes tablas queda reunida la información acerca de los participantes que han formado parte del proyecto. Participante 001 Nombre Alba Francisco Gutiérrez Organización Estudiante de Grado en Ingeniería Informática de la UVa Rol Jefa de proyecto, analista, diseñadora, desarrolladora y Tester Es desarrollador Sí Es cliente No Es usuario No Tabla 3.21: Participante 001 23 Capítulo 3. Análisis Participante 002 Nombre Benjamín Sahelices Fernández Organización Departamento de informática de la UVa Directo de la Escuela de Ingeniería Informática de la UVa Rol Tutor de TFG Es desarrollador No Es cliente Sí Es usuario Sí Tabla 3.22: Participante 002 Participante 003 Nombre Alberto Casero de la Calle Organización Everis and NTT Data Company Rol Tutor de TFG Es desarrollador No Es cliente Sí Es usuario Sí Tabla 3.23: Participante 003 Participante 004 Nombre Álvaro Estébanez Barrena Organización Everis and NTT Data Company Rol Tutor de TFG Es desarrollador No Es cliente Sí Es usuario Sí Tabla 3.24: Participante 004 24 3.7. Análisis de riesgos 3.7. Análisis de riesgos En la siguiente sección se detallará el análisis de riegos realizado. El análisis del riesgo es un método sistemático de recopilación, evaluación, registro y difusión de información necesaria para formular recomendaciones orientadas a la adopción de una posición o medidas en respuesta a un peligro determinado. Además, de permitir monitorizar el transcurso de un proyecto para evaluar el estado de los riesgos y actuar en consecuencia. BAJA TEMPORAL Número: 001 Fecha: 25/02/2019 Categoría: Predecible Probabilidad: Alta Tiempo: Cualquiera Consecuencia: Modificación en la planificación Proyecto: TFG Iteración: Cualquier iteración Creador:Alba Francisco Descripción El único miembro puede sufrir una baja temporal como consecuencia de enfermedades de corta o media duración. Plan de contingencia Estrategia: Tener tiempos lo suficientemente flexibles para evitar que tener un tiempo parado no afecte a las fechas de entrega. Indicador de riesgo Indicador: Síntomas previos Comentarios: El empleado afectado debe comunicar a sus tutores de proyecto su estado sintomático Resolución del riesgo Responsable: Jefe de proyecto: Fecha: Fecha: Tabla 3.25: Baja temporal EL CLIENTE NO ES ESPECÍFICO CON LOS REQUISITOS DEL PROYECTO Número: 005 Fecha: 25/02/2019 Categoría: Alta Probabilidad: Alta Tiempo: Cualquier momento Consecuencia: Retrasos Proyecto: TFG Iteración: Cualquier iteración Creador: Alba Francisco Descripción El cliente no tiene definidos los requisitos que quiere que cumplimente la aplicación a desarrollar. Plan de contingencia Estrategia: Reiterar las reuniones con el clientes hasta tener un requisitos mínimos a cumplimentar definidos. Indicador de riesgo Indicador: Síntomas previos Comentarios: El cliente puede dar síntomas de no tener definido unos propósitos concretos a los que quiere llegar. Resolución del riesgo Responsable: Jefe de proyecto: Fecha: Fecha: Tabla 3.26: El cliente no es específico con los requisitos del proyecto 25 Capítulo 3. Análisis FALLO DE HARDWARE Número: 005 Fecha: 25/02/2019 Categoría: Alta Probabilidad: Baja Tiempo: Cualquier momento Consecuencia: Retrasos Proyecto: TFG Iteración: Cualquier iteración Creador: Alba Francisco Descripción Un fallo de hardware en el ordenador de la alumna. Plan de contingencia Estrategia: En caso extremo, se podría recurrir al ordenador que proporciona la empresa Everis, para la finalización del proyecto. Indicador de riesgo Indicador: Síntomas previos Comentarios: El ordenador puede evidenciar fallas con anterioridad. Resolución del riesgo Responsable: Jefe de proyecto: Fecha: Fecha: Tabla 3.27: Fallo de hardware FALLO DE SOFTWARE Número: 005 Fecha: 25/02/2019 Categoría: Alta Probabilidad: Baja Tiempo: Cualquier momento Consecuencia: Retrasos Proyecto: TFG Iteración: Cualquier iteración Creador: Alba Francisco Descripción Un fallo de software en el ordenador de la alumna. Plan de contingencia Estrategia: Utilizar herramientas que la alumna haya probado con anterioridad y conocer herramientas similares que puedan sustituir a las que se ven afectadas Indicador de riesgo Indicador: Síntomas previos Comentarios: El ordenador puede evidenciar fallas con anterioridad. Resolución del riesgo Responsable: Jefe de proyecto: Fecha: Fecha: Tabla 3.28: Fallo de software 26 3.7. Análisis de riesgos PÉRDIDA DE INFORMACIÓN Número: 005 Fecha: 25/02/2019 Categoría: Alta Probabilidad:Media Tiempo: Cualquier momento Consecuencia: Retrasos y repetición de tareas ya realizadas Proyecto: TFG Iteración: Cualquier iteración Creador: Alba Francisco Descripción Pérdida de datos bien sea por fallo humano, de hardware o software. Puede perderse avances en la programación, documentación o estado de la máquina virtual donde se aloja Oracle Database. Plan de contingencia Estrategia: Realizar copias de seguridad periódicas de la documentación en local , ya que se trabaja en la nube, y de la máquina virtual en un sistema externo de almacenamiento. Establecer un sistema de control de versiones, como puede TFS, para mantener los avances del código. Indicador de riesgo Indicador: Síntomas previos Comentarios: El ordenador puede evidenciar fallas con anterioridad. Resolución del riesgo Responsable: Jefe de proyecto: Fecha: Fecha: Tabla 3.29: Pérdida de información INCAPACIDAD PARA AJUSTARSE A LA PLANIFICACIÓN Número: 005 Fecha: 25/02/2019 Categoría: Media Probabilidad: Media Tiempo: Cualquier momento Consecuencia: Retrasos Proyecto: TFG Iteración: Cualquier iteración Creador: Alba Francisco Descripción Puede darse el caso de que el equipo sea incapaz de ajustarse a la planificación bien sea por una mala planificación u otras causas. Plan de contingencia Estrategia: Ajustar las tareas críticas y rehacer la planificación. Indicador de riesgo Indicador: Síntomas previos Comentarios: Se puede dar que debido al desconocimiento la planificación no sea del todo correcta. Resolución del riesgo Responsable: Jefe de proyecto: Fecha: Fecha: Tabla 3.30: Incapacidad para ajustarse a la planificación 27 Capítulo 3. Análisis Figura 3.5: Diagrama de Gantt de la fase de elaboración. 3.8.3. Fase de construcción Figura 3.6: Tareas fase de construcción. Figura 3.7: Diagrama de Gantt de la fase de construcción. 34 3.8. Planificación de fases 3.8.4. Fase de transición Figura 3.8: Tareas fase de transición. Figura 3.9: Diagrama de Gantt de la fase de transición. 35 Capítulo 3. Análisis 3.9. Requisitos del sistema Los requisitos quedan separados en dos secciones, funcionales y no funcionales. 3.9.1. Funcionales El la siguiente sección se agruparan los requisitos funcionales que se ha seguido para la implementación de este trabajo. Los requerimientos funcionales son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares en base a la necesidades del cliente. Requisito funcional 001 Nombre El sistema evaluará los cambios producidos en los registros de una única entidad. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción El sistema evaluará los cambios que se producen en los registros de una única entidad del sistema Microsoft Dynamics 365. Tabla 3.39: Requisito funcional 001 Requisito funcional 002 Nombre Comprobación del sistema de la adición de nuevos registros. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción El sistema comprobará si hay nuevos registros creados, en un intervalo de tiempo de un minuto, en Microsoft Dynamics 365. Tabla 3.40: Requisito funcional 002 Requisito funcional 003 Nombre Sistema comprueba la actualización de registros. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción El sistema comprobará si hay nuevos registros actualizados, en un intervalo de tiempo de un minuto, en Microsoft Dynamics 365. Tabla 3.41: Requisito funcional 003 36 3.9. Requisitos del sistema Requisito funcional 004 Nombre Comprobación de la eliminación de registros en CRM. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción El sistema comprobará si hay nuevos registros eliminados, en un intervalo de un minuto, en Microsoft Dynamics 365. Tabla 3.42: Requisito funcional 004 Requisito funcional 005 Nombre Generación de mensajes en relación de los datos extraídos. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción El sistema generará mensajes, con un formato definido, usando la información de los registros y los encolará en un Topic, asociado a una Subscription, en función del tipo de mensaje que se genere. Tabla 3.43: Requisito funcional 005 Requisito funcional 006 Nombre Formato de mensajes Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción El sistema generará mensajes con el siguiente formato, que se encolaran en Service Bus: tipo:Create, Update oDelete. name_entity: Nombre de la entidad a partir de la cual se ha extraído el registro. id: Identificador único del registro. key: Nombre de los campos a partir de los cuales se compone el registro. value: Valores almacenado en los campos. error: Lugar donde se almacenará, si se produce, el tipo de error. retryCount: Número de reintentos. Tabla 3.44: Requisito funcional 006 37 Capítulo 3. Análisis Requisito funcional 007 Nombre Diferenciación entre registros creados y actualizados Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción La diferenciación entre los registros creados y los registros actualizados se realiza mediante la evaluación de equidad entre los campos modifiedon ycreatedon. Tabla 3.45: Requisito funcional 007 Requisito funcional 008 Nombre Cola manual Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Aquellos mensajes que Oracle no pueda gestionar debido a un error, exceptuando aquellos relacionados con la conexión de la base de datos, serán reencolados en una cola manual que será gestionada por el equipo de gestión. Tabla 3.46: Requisito funcional 008 Requisito funcional 009 Nombre Cola automática Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Los mensajes que no puedan ser gestionados por Oracle debido a problemas de conexión serán reencolados en una cola automática. Tabla 3.47: Requisito funcional 009 Requisito funcional 010 Nombre Incremento de retryCount en mensajes que pasán a cola automática. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Los mensajes que pasen a cola automática aumentarán en uno su valor de retryCount. Tabla 3.48: Requisito funcional 010 38 3.9. Requisitos del sistema Requisito funcional 011 Nombre Máximo número de reintentos Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Los mensajes que no puedan ser gestionados por Oracle, por cualquier motivo, y cuyo retryCount supere el valor de tres, serán reencolados en la cola manual. Tabla 3.49: Requisito funcional 011 Requisito funcional 012 Nombre Creación de registros cuando no existe el registro a actualizar. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Si, cuando intentamos actualizar un registro en Oracle, la base de datos informa de que no hay ningún registro con esos datos, se creará el registro. Tabla 3.50: Requisito funcional 012 Requisito funcional 013 Nombre Actualización de los campos que han sido modificados. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Cuando se actualice un registro, se evaluará que campos han sido cambiado en relación a la información que viene en el mensaje y la almacenada en Oracle. En relación a estos, se actualizarán los campos en la base de datos. Tabla 3.51: Requisito funcional 013 39 Capítulo 3. Análisis Requisito funcional 014 Nombre Antes de crear un registro nuevo se evalúa el retryCount. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Si el retryCount es superior a cero, antes de crear un registro nuevo se evaluará si este ya ha sido creado previamente. Si ha sido así, el mensaje se desecha. Tabla 3.52: Requisito funcional 014 Requisito funcional 015 Nombre Actualización de registro en relación al campo MODIFIEDON Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Si el registro almacenado en Oracle tiene un valor en MODIFIEDON posterior al valor de ese mismo campo almacenado en el mensaje, entonces el mensaje se desechará. Siempre debe prevalecer el mensaje más reciente. Tabla 3.53: Requisito funcional 015 Requisito funcional 016 Nombre Almacenamiento de los valores más importantes de un registro antes de su eliminación. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción La información más relevante de un registro: nombre de la entidad valor del identificador único nombre del campo donde se almacena dicho valor se almacenará en la entidad af_entitydelete cuando se elimine del Microsoft Dynamics 365. Tabla 3.54: Requisito funcional 016 40 3.9. Requisitos del sistema Requisito funcional 017 Nombre Eliminación de registro de af_entitydelete Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Una vez que el mensaje haya sido almacenado en la cola, el registro asociado a dicho mensaje se eliminará de la entidad af_entitydelete. Tabla 3.55: Requisito funcional 017 Requisito funcional 018 Nombre Comprobación de disponibilidad de Oracle Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Cada cinco minutos, se evaluará si Oracle está disponible para el tratamiento de mensajes. Tabla 3.56: Requisito funcional 018 Requisito funcional 019 Nombre Condiciones para la no extracción de mensajes de la cola automática. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Si Oracle no está disponible, no se extraerán mensajes de la cola automática. Tabla 3.57: Requisito funcional 019 Requisito funcional 020 Nombre Condiciones para la extracción de mensajes de cola automática. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Si Oracle está disponible, se extraerán mensajes de la cola automática. Tabla 3.58: Requisito funcional 020 41 Capítulo 3. Análisis Requisito funcional 021 Nombre Reasignación de los mensajes extraídos de cola automática. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Se evaluará el campo tipo del mensaje extraído de la cola automática. En relación al valor almacenado en dicho campo se enviará los mensajes desde la cola automática a los Topic adecuados. Tabla 3.59: Requisito funcional 021 Requisito funcional 022 Nombre Mensajes extraídos de cola automática incorrectos. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Si el mensaje extraído de la cola automática es incorrecto, se enviará a la cola manual. Tabla 3.60: Requisito funcional 022 Requisito funcional 023 Nombre Sin mensajes dentro de la cola automática. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Si no hay mensajes en la cola automática, no se realizará ninguna acción. Tabla 3.61: Requisito funcional 023 Requisito funcional 024 Nombre Evaluación de las colas de DeadLetter y registros creados por la cola manual. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Cada quince minutos se evaluarán las colas de DeadLetter asociadas a Create, Delete, Update y registros creados por la cola manual. Tabla 3.62: Requisito funcional 024 42 3.9. Requisitos del sistema Requisito funcional 025 Nombre E-mail al equipo de desarrollo por mensajes en las cola de DeadLetter de Create. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Si hay un mensaje dentro de la cola de DeadLetter del Topic y la Subscription ”Create” se enviará un e-mail al equipo de desarrollo. Tabla 3.63: Requisito funcional 025 Requisito funcional 026 Nombre E-mail al equipo de desarrollo por mensajes en las cola de DeadLetter de Update, Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Si hay un mensaje dentro de la cola de DeadLetter del Topic y la Subscription ”Update ”se enviará un e-mail al equipo de desarrollo Tabla 3.64: Requisito funcional 026 Requisito funcional 027 Nombre E-mail al equipo de desarrollo por mensajes en las cola de DeadLetter de Delete. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción Si hay un mensaje dentro de la cola de DeadLetter del Topic y la Subscription ”Delete”se enviará un e-mail al equipo de desarrollo. Tabla 3.65: Requisito funcional 027 Requisito funcional 028 Nombre Formato de la fecha y hora que utilizará el programa de consola. Versión 1.0 -05/04/2019 Autora Alba Francisco Gutiérrez Fuentes Álvaro Estébanez Barrena y Alberto Casero De La Calle Descripción El programa de consola deberá utilizar un intervalo de fecha de fecha y hora con el siguiente formato: dd/mm/yyyy hh:mm:ssss. Tabla 3.66: Requisito funcional 028 43 Capítulo 3. Análisis 3.10. Actores Actor 001 Nombre Usuario Versión 1.0-04/05/2019 Autor Alba Francisco Gutiérrez Descripción Será un cliente que gestionará los datos de Microsoft Dynamics 365. Creará, modificará y actualizará los registros. Tabla 3.83: Actor 001 Actor 002 Nombre Tiempo Versión 1.0-04/05/2019 Autor Alba Francisco Gutiérrez Descripción Las Azure Functions que conectan con Microsoft Dynamics 365 lo hacen de manera periódica. La manera más adecuada de representar este comportamiento es con un actor. Tabla 3.84: Actor 002 Actor 003 Nombre Equipo de gestión Versión 1.0-04/05/2019 Autor Alba Francisco Gutiérrez Descripción Es un usuario final con funciones de administración. Será el que recibas lo e-mail cuando se sobrepase un número concreto de mensajes en las colas manuales. Tabla 3.85: Actor 003 50 3.11. Casos de uso 3.11. Casos de uso Nombre de ID del CU CU-01 Extracción de registros creados en Microsoft Dynamics 365 Actor Sistema Descripción La información de un registro, que previamente ha sido creados en Microsoft Dynamics 365, se encolará en Service Bus. Pre-condiciones El registro debe de haber sido creado, durante el intervalo del último minuto, en Microsoft Dynamics 365. Post-condiciones La información del registro estará almacenada, en forma de mensaje, en Service Bus. Flujo normal 1. El sistema se conecta a Microsoft Dynamics 365 2. El sistema extrae todos los registros que cumplen la condición de haber sido modificados dentro del intervalo del último minuto al momento de la conexión. 3. El sistema evaluará si el registro extraído es un registro recién creado. 4. El sistema genera un mensaje con los datos extraídos. 5. El sistema enviará al Service Bus el mensaje. Flujo Alternativo 3.1 Si el registro extraído ha sido actualizado se realizará el caso de uso Extracción de registros actualizados en Microsoft Dynamics 365.. Excepciones 1. El sistema no puede conectar con Microsoft Dynamics 365. 4. El sistema no puede conectar con Service Bus. Tabla 3.86: Requisito CU-01 Extracción de registros creados en Microsoft Dynamics 365. 51 Capítulo 3. Análisis Nombre de ID del CU CU-02 Extracción de registros actualizados en Microsoft Dynamics 365 Actor Sistema Descripción La información de un registro, que previamente ha sido actualizado en Microsoft Dynamics 365, se encolará en Service Bus. Pre-condiciones El registro debe de haber sido actualizado, durante el intervalo del último minuto, en Microsoft Dynamics 365. Post-condiciones La información del registro estará almacenada, en forma de mensaje, en Service Bus. Flujo normal 1. El sistema se conecta a Microsoft Dynamics 365 2. El sistema extrae todos los registros que cumplen la condición de haber sido modificados dentro del intervalo del último minuto al momento de la conexión. 3. El sistema evaluará si el registro extraído es un registro que sido actualizado. 4. El sistema generará un mensaje con los datos extraídos. 5. El sistema enviará al Service Bus el mensaje. Flujo Alternativo 3.1 Si el registro extraído es de nueva creación se realizará el caso de uso Extracción de registros creados en el CRM. Excepciones 1. El sistema no puede conectar con Microsoft Dynamics 365. 4. El sistema no puede conectar con Service Bus. Tabla 3.87: Requisito CU-02 Extracción de registros actualizados en Microsoft Dynamics 365. 52 3.11. Casos de uso Nombre de ID CU-03 Extracción de registros eliminados en Microsoft Dynamics 365 Actor Sistema Descripción La información de un registro, que previamente ha sido eliminado en Microsoft Dynamics 365, se encolará en Service Bus. Pre-condiciones El mensaje debe de estar almacenado dentro de Service Bus. Post-condiciones La información del registro estará almacenada, en forma de mensaje, en Service Bus. Flujo normal 1. El sistema se conecta a Microsoft Dynamics 365 2. El sistema extrae todos los registros que han sido eliminados de Microsoft Dynamics 365 3. El sistema genera un mensaje con los datos extraídos. 4. El sistema enviará al Service Bus el mensaje. 5.El sistema eliminará, definitivamente, el registro dentro de Microsoft Dynamics 365. Excepciones 1. El sistema no puede conectar con Microsoft Dynamics 365. 4. El sistema no puede conectar con Service Bus. Tabla 3.88: Requisito CU-03 Extracción de registros eliminados en Microsoft Dynamics 365. 53 Capítulo 3. Análisis Nombre de ID CU-04 Creación de registros en la base de datos Oracle Actor Sistema Descripción La información de un registro, que estaba encolado en Service Bus, se almacenará dentro del sistema de bases de datos de Oracle. Pre-condiciones El mensaje debe de estar almacenado dentro de Service Bus. Post-condiciones La información del registro estará almacenada, en forma de mensaje, en Service Bus. Flujo normal 1. El sistema detectará que hay un mensaje dentro de Service Bus. 2. El sistema extrae el mensaje de la cola de Service Bus. 3. El sistema comprueba que si se ha intentado almacenar más de una vez el mensaje recibido en Oracle. 4. El sistema creará un comando de tipo SQL con la información recibida dentro del mensaje extraído de Service Bus. 5. El sistema enviará el comando al sistema de bases de datos Oracle. 6. El sistema de bases de datos Oracle creará un nuevo registro con la información recibida 7. El caso de uso se ejecuta hasta que no exista más mensajes en Service Bus. Flujo alternativo 3.1 Si el mensaje recibido se ha intentado más de una vez. 3.1.1 El sistema creará un comando de consulta. 3.1.2 El sistema envía el comando al sistema de bases de datos Oracle. Excepciones 5. y de 3.1.2 El sistema de bases de datos de Oracle lanza un error relacionado con problemas de conexión. 5.1 El sistema aumenta en el contador de reintentos del mensaje. 5.2 El sistema envía el mensaje a la cola de reintentos automática. 5. y de 3.1.2 El sistema de bases de datos de Oracle lanza un error relacionado con problemas asociados al mensaje. 5.1 El sistema envía el mensaje a la cola de reintentos manual. Tabla 3.89: Requisito CU-04 Creación de registros en Oracle 54 3.11. Casos de uso Nombre de ID CU-05 Actualización de registro en la base de datos de Oracle. Actor Sistema Descripción Los mensajes extraídos del Service Bus serán almacenados en el sistema de bases de datos de Oracle. Pre-condiciones El mensaje debe de estar almacenado en la cola de Service Bus. Post-condiciones Las información extraída del mensaje, actualizará la información que está almacenada en el sistema de bases de datos de Oracle. Flujo normal 1. El sistema detecta que hay un nuevo mensaje dentro de Service Bus. 2. El sistema extrae el mensaje del Service Bus. 3. El sistema crea un comando SQL de consulta en relación al mensaje extraído. 4. El sistema envía el comando de consulta a Oracle. 5. El sistema de bases de datos de Oracle devuelve la información que tiene relativa a la información del mensaje. 6. El sistema evalúa que campos han sido modificados en el mensaje extraído en comparación a la información almacenada en Oracle 7. El sistema genera un comando SQL con los campos modificados. 8. El sistema envía el comando al sistema de bases de datos de Oracle. Flujo Alternativo 4.1 Si no se encuentra información en Oracle relativa a la información recibida por Service Bus. 4.1.1 El sistema crea un comando SQL de creación de registro con la información del mensaje. 4.1.2 El sistema envía el comando al sistema de bases de datos de Oracle. 5.1 Si la información almacenada en Oracle es posterior a la información recibida por Service Bus el caso de uso finaliza. Excepciones 4 y 8 El sistema no puede conectar con Oracle debido a fallos relativos a la conexión. 1. El mensaje aumentará en uno el contador de reintentos del mensaje 2. El sistema envía el mensaje a la cola de reintentos automáticos. 4. El sistema no puede conectar con Oracle debido a fallos relacionados con el mensaje o el contador de reintentos supera el límite. 1. El sistema envía el mensaje a la cola de reintentos manual. Tabla 3.90: Requisito CU-05 Actualización de registros en Oracle 55 Capítulo 3. Análisis Nombre de ID del CU CU-06 Eliminación de registro de la base de datos de Oracle. Actor Sistema Descripción Los mensajes extraídos del Service Bus serán eliminados en el sistema de bases de datos de Oracle. Pre-condiciones El mensaje debe de estar almacenado en la cola de Service Bus. Post-condiciones Las información extraída del mensaje, actualizará la información que esta almacenada en el sistema de bases de datos de Oracle. Flujo normal 1. El sistema detecta que hay un nuevo mensaje dentro de Service Bus. 2. El sistema extrae el mensaje del Service Bus. 3. El sistema crea un comando SQL de eliminación en relación al mensaje extraído. 4. El sistema envía el comando de consulta a Oracle. Excepciones 4 y 8 El sistema no puede conectar con Oracle debido a fallos relativos a la conexión. 1. El mensaje aumentará en un el contador de reintentos del mensaje 2. El sistema envía el mensaje a la cola de reintentos automáticos. 4. El sistema no puede conectar con Oracle debido a fallos relacionados con el mensaje o el contador de reintentos supera el límite. 1. El sistema envía el mensaje a la cola de reintentos manual. Tabla 3.91: Requisito CU-06 Eliminación de registros en Oracle 56 3.11. Casos de uso Nombre de ID del CU CU-07 Reenvío de mensajes que están almacenados en la cola de reintentos autómatica. Actor Sistema Descripción Los mensajes almacenados dentro de la cola de reintentos automática deberán ser redigidos a las colas pertinentes en el momento en que el sistema de bases de datos de Oracle este disponible. Pre-condiciones El mensaje debe de estar almacenado en la cola de Service Bus de reintentos automáticos. Post-condiciones Los mensajes extraídos de la cola de reintentos automáticos deberán estar en las colas pertinentes. Flujo normal 1. El sistema envía un comando de pruebas al sistema de bases de datos de Oracle para comprobar su disponibilidad. 2. El sistema extrae el mensaje de la cola. 3. El sistema evalúa a cual cola debe de ser redigido el mensaje. 4. El sistema envía el mensaje a la cola pertinente. Excepciones 1. El sistema no puede conectar con Oracle. El caso de uso finaliza. 3. El mensaje ha llegado erróreno y no se puede enviar a ninguna cola. El sistema reenvía el mensaje erróneo a la cola de reintentos manual. 4. El sistema no puede conectar con Service Bus. Tabla 3.92: Requisito CU-07 Reenvío de mensajes que están almacenados en la cola de reintentos automática. 57 Capítulo 3. Análisis Nombre de ID del CU CU-08 Regularización de registros en Microsoft Dynamics 365 Actor Sistema Descripción Se realizará una regularización de registros creado o actualizados en un intervalo de tiempo concreto enviando la información relativa a ellos a Service Bus. Pre-condiciones Debe de haber mensajes, dentro de un intervalo de tiempo, creados o actualizados que no fueron enviados a Service Bus. Post-condiciones Los mensajes extraídos estarán en Service Bus. Flujo normal 1. El sistema pide que se introduzca la fecha de inicio. 2. El usuario proporciona fecha de inicio. 3. El sistema pide que se introduzca la fecha de fin. 4. El usuario introduce la fecha de fin. 5. El sistema se conecta a Microsoft Dynamics 365. 6. El sistema extrae todos los registros, creados o actualizados, dentro del periodo de tiempo proporcionado por el usuario. 7. El sistema evalúa que registros han sido de nueva creación y cual han sido actualizados. 8. El sistema genera un mensaje con la información extraída de Microsoft Dynamics 365. 9. El sistema envía el mensaje a Service Bus. Excepciones 5. El sistema no puede conectar con Microsoft Dynamics 365. 9. El sistema no puede conectar con Service Bus. Tabla 3.93: Requisito CU-08 Regularización de registros en Microsoft Dynamics 365 58 3.11. Casos de uso Nombre de ID del CU CU-09 Almacenamiento de los campos relevantes ante la eliminación de un registro en Microsoft Dynamics 365 Actor Sistema Descripción Se almacenarán en otra entidad los campos, y la información asociada a ellos, de los registros eliminados en Microsoft Dynamics 365 para su posterior eliminación en el sistema de bases de datos de Oracle. Pre-condiciones Debe de haber un registro creado en Microsoft Dynamics 365. Post-condiciones Los datos salvaguardados estarán almacenados dentro de otra entidad en Microsoft Dynamics 365. Flujo normal 1. El usuario elimina un registro dentro del Microsoft Dynamics 365. 2. El sistema extrae la información necesaria de ese registro. 3. El sistema crea un registro en otra entidad. 4. El sistema almacena la información salvaguardada dentro del nuevo registro. Excepciones 2. El sistema no puede conectar con Microsoft Dynamics 365. 2. El sistema no puede extraer la información que debe de ser salvaguardada. 3. El sistema no puede crear un nuevo registro. 4. El sistema no puede almacenar la información en el nuevo registro. Tabla 3.94: Requisito CU-09 Almacenamiento de los campos relevantes ante la eliminación de un registro en Microsoft Dynamics 365 59 Capítulo 3. Análisis 3.13. Diagramas de secuencia En la siguiente sección se incluirán los diagramas de secuencia de análisis, los cuales son un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML, asociados al sistema. Figura 3.11: Diagrama de secuencia de Create. 66 3.13. Diagramas de secuencia Figura 3.12: Diagrama de secuencia de la política de reintentos de Create. 67 Capítulo 3. Análisis Figura 3.13: Diagrama de secuencia de Update. 68 3.13. Diagramas de secuencia Figura 3.14: Diagrama de secuencia de Delete. 69 Capítulo 3. Análisis Figura 3.15: Diagrama de secuencia de la Azure Function encargada de reintentar automáticamente los mensajes. 70 3.13. Diagramas de secuencia Figura 3.16: Diagrama de secuencia de la Azure Function encargada de reintentar automáticamente los mensajes. 71 Capítulo 3. Análisis Figura 3.17: Diagrama de secuencia de la Azure Function encargada enviar e-mail . 72 3.13. Diagramas de secuencia Figura 3.18: Diagrama de secuencia del programa de consola que regulariza registros . Figura 3.19: Diagrama de secuencia del Plugin. 73 Capítulo 4 Diseño En el presente capítulo, se detallará el diseño del sistema. Esta etapa permite determinar como funcionará de forma general, sin entrar en detalles, el sistema. Se detallará el diseño de los componentes del sistema que dan respuesta a las funcionalidades, descritas en la etapa de análisis, también conocidas como las entidades de negocio. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación y para describir la interacciones entre la entidades y el secuenciado, se realizan diagramas que lo muestren claramente. 4.1. Patrones Para el desarrollo de este proyecto se ha utilizado los siguientes patrones, que explicaremos más en detalle a continuación, además de detallar las razones detrás de la elección de su uso. 4.1.1. Patrón Command and Query Responsibility Segregation (CQRS) Command and Query Responsibility Segregation (CQRS) es un patrón que segrega las operaciones que leen datos (consultas) de las operaciones que actualizan los datos (comandos) mediante interfaces independientes. Esto significa que los modelos de datos utilizados para realizar las consultas y las actualizaciones son diferentes. Posteriormente, se pueden aislar los modelos, como se indica en la imagen 4.1, aunque eso no es un requisito imprescindible. Figura 4.1: Aislamiento de modelos. 74 4.1. Patrones En comparación con el modelo de datos único que se usa en los sistemas basados en CRUD, el uso de modelos de consulta y actualización independientes para los datos de los sistemas basados en CQRS simplifica el diseño y la implementación. Sin embargo, una desventaja es que, a diferencia de los diseños CRUD, el código CQRS no se genera automáticamente mediante los mecanismos de scaffolding. El modelo de consulta para leer datos y el de actualización para escribirlos pueden acceder el mismo almacén físico, quizás mediante vistas SQL o mediante la generación de proyecciones sobre la marcha. Sin embargo, es habitual separar los datos en almacenes físicos diferentes para maximizar el rendimiento, la escalabilidad y la seguridad, tal como se muestra en la figura 4.2. Figura 4.2: Separación de datos. El almacén de lectura puede ser una réplica de solo lectura del almacén de escritura o los almacenes de lectura y escritura pueden tener una estructura diferente por completo. El uso de réplicas de solo lectura del almacén de lectura puede aumentar mucho el rendimiento de las consultas y la capacidad de respuesta de la interfaz de usuario de la aplicación, especialmente en escenarios distribuidos en los que las réplicas de solo lectura se sitúan cerca de las instancias de la aplicación. Algunos sistemas de bases de datos (SQL Server) proporcionan características adicionales como la conmutación por error de réplicas para maximizar la disponibilidad. La separación de los almacenes de lectura y escritura permite también que cada uno de ellos pueda escalarse adecuadamente para adaptarse a la carga 4.3. Por ejemplo, los almacenes de lectura normalmente se encuentran con una carga mayor que los de escritura [12]. En el presente trabajo, solo se implementará la parte de command del patrón por cuestiones de requisitos de cliente. 75 Capítulo 4. Diseño 4.2.4. ConnectionToOracleCreate La Azure Function representada en la figura 4.8, es la encargada el almacenar en la base de datos de Oracle la información recibida en los mensajes del Topic con la Subscription ”create”. Figura 4.8: Function ConnectoToOracleCreate CompruebaRetryCount: Método que comprueba si el mensaje ha sido reitentando con anterioridad. ConnectionOracleCheckExistAsync: Método que evalúa, en el caso de un mensaje que ha sido reintentado, si el registro asociado al mensaje ya ha sido creado en la base de datos de Oracle. ConnectionOracleCreateAsync: Método encargado de crear un nuevo registro en la base de datos de Oracle utilizando la información recibida dentro del mensaje. CompruebaErrores: Método encargado de evaluar los errores arrojados por Oracle. GeneraContenedorAsync: Método encargado de generar el recipiente que enviara los mensajes fallidos o bien a la cola de reintentos manual o bien a la cola de reintentos automática. SendMessagesAsync: Método encargado de enviar el mensaje a la cola correspondiente. 4.2.5. ConnectionToOracleDelete La Azure Function representada en la figura 4.9, es la encargada el eliminar en la base de datos de Oracle la información recibida en los mensajes de la Topic con la Subscription de ”delete” ConnectionOracleDeleteAsync: Método encargado de, asíncronamente, eliminar los registros asociados a lo mensajes recibidos. GeneraContenedorAsync: Método encargado de generar el recipiente que enviará los mensajes fallidos o bien a la cola de reintentos manual o bien a la cola de reintentos automática. SendMessagesAsync: Método encargado de enviar el mensaje a la cola correspondiente. 82 4.2. Diagrama de clases Figura 4.9: Function ConnectoToOracleDelete 4.2.6. ConnectToOracleUpdate La Azure Function representada en la figura 4.10, es la encargada el actualizar en la base de datos de Oracle la información recibida en los mensajes de la Topic con la Subscription de ”update”. Figura 4.10: Function ConnectoToOracleUpdate ConsultaYEnviaAOracle: Método encargado de consultar a Oracle la información relativa al mensaje recibido. Usando la información devuelta, se genera una query de actualización y se ejecuta si procede. GeneraQueryActualizacion: Método que genera la query de actualización en base a la información del mensaje y los datos almacenados en Oracle. GeneraContenedorAsync: Método encargado de generar el recipiente que enviara los mensajes fallidos o bien a la cola de reintentos manual o bien a la cola de reintentos automática. SendMessagesAsync: Método encargado de enviar el mensaje a la cola correspondiente. 4.2.7. RetryAutomatica La Azure Function representada en la figura 4.11, es la encargada de manejar la cola de reintentos automática. Una vez detectada la disponibilidad de Oracle reenviará los mensajes a los Topic ,con sus Subscription, adecuados . CheckOracleDisponible Método encargado de comprobar la disponibilidad de la base de datos de Oracle. 83 Capítulo 4. Diseño Figura 4.11: Function Retry_automatica ReceiveAsyn: Método encargado de recibir los mensajes encolados y de reenviarlos al Topic, con su respectiva Subscription, adecuado. GeneraContenedorAsync: Método de generar el contenedor que enviará los mensajes fallidos o bien a la cola de reintentos manual o bien a la cola de reintentos automática. SendMessagesAsync: Método encargado de enviar el mensaje a la cola correspondiente. 4.2.8. ColaManual La Azure Function representada en la figura 4.12, es la encarga de manejar la cola manual de reintentos. Los mensajes almacenados se insertaran el Microsoft Dynamics 365, para su posterior evaluación por el equipo de gestión. Figura 4.12: Function ColaManual ConexionToCrm: Método encargado de realizar la conexión con Microsoft Dynamics 365. CreaciónRegistrosDeMensajesError: Método encargado de crear un registro en Microsoft Dynamics 365, en base a los mensajes fallidos extraídos de la cola. 4.2.9. RegularizaciónDatosCrm El programa de consola representado en la figura 4.13, es el encargado de regularizar los datos en Dynamics CRM 365 dentro de un intervalo de tiempo. ConnectaToCRM: Método encargado de realizar la conexión con Microsoft Dynamics 365. 84 4.2. Diagrama de clases Figura 4.13: Function RegularizaciónDatosCrm EstablecerIntervalos: Método encargado de recoger el intervalo de tiempo en el cual se realiza la regularización de los datos. ExtraerRegistrosEnIntervalo: Método encargado de parametrizar la query que realiza la extracción de Microsoft Dynamics 365. GenerarMensaje: Método encargado de generar mensajes en base a los datos extraídos y determinar a que suscripción y topic deben de ser asignados. GeneraContenedorAsync: Método encargado de generar el recipiente asíncronamente que enviara el mensaje a la cola de suscripción adecuada. SendMessagesAsync: Método encargado de enviar el mensaje a la cola correspondiente. 4.2.10. EnvioEmailColaMensajesFallidos La Azure Function representada en la figura 4.14, es la encargada de comprobar la cantidad de registros que ha generado la cola manual y el número de mensajes que están almacenados en las colas de mensajes fallidos de los Topic. Si superan cierta cantidad de mensajes, enviara un e-mail de aviso. Figura 4.14: Function EnvioEmailColaMensajesFallidos CheckColas: Método encargado de comprobar la cantidad de mensajes de las colas y si el número de mensajes almacenado supera al permitidido. 85 Capítulo 4. Diseño CompruebaCantidadRegistrosEntidadManual: Método encargado de contabilizar el número de registros que ha creado la cola manual en base a los mensajes fallidos. RealizarConexionCRM: Método encargado de crear la conexiónMicrosoft Dynamics 365. Enviar_mail_custom: Método encargado de crear en Microsoft Dynamics 365 la entidad email. Microsoft Dynamics 365 será el encargado de enviar el e-mail. 4.2.11. PapeleraReciclaje El Plugin representado en la figura 4.15, es el encargado de salvaguardar los datos, que han sido eliminados en Microsoft Dynamics 365, que serán necesarios para eliminar, posteriormente, en la base de datos de Oracle. Esta información quedará almacenada en otra entidad. Figura 4.15: Plugin que salvaguarda los datos de los registros eliminados. Execute: Método encargado de extraer los datos requeridos de la imagen del registro eliminado y, utilizando dicha información, crear un nuevo registro en otra entidad con dicha información. 4.3. Diagramas de Secuencia 86 4.3. Diagramas de Secuencia Figura 4.16: Diagrama de diseño que específica el flujo de los mensajes de Delete desde Microsoft Dynamics 365 hasta Service Bus. 87 Capítulo 4. Diseño Figura 4.17: Diagrama de diseño que específica el flujo de los mensajes de Create desde Service Bus hasta la base de datos de Oracle. 88 4.3. Diagramas de Secuencia Figura 4.18: Diagrama de diseño que específica el flujo de los mensajes de Update desde Microsoft Dynamics 365 hasta Service Bus.89 Capítulo 4. Diseño Figura 4.19: Diagrama de diseño que específica el flujo de los mensajes de Delete desde Service Bus hasta la base de datos de Oracle. 90 4.3. Diagramas de Secuencia Figura 4.20: Diagrama de diseño de RetryAutomatica 91 Capítulo 5. Implementación tratar como fallido un mensaje desde una cola de mensajes fallidos. La cola de mensajes fallidos es totalmente compatible con las operaciones transaccionales y de entrega de bloqueo de información [deadletter]. Los mensajes permanecen en la cola de mensajes fallidos hasta que se recuperan explícitamente, de ahí la necesidad de realizar una Azure Function encargada de extraerlos en esta etapa para poder realizar pruebas en base a ella más realistas aunque no sea parte de los requisitos de cliente. 5.0.13. Decimotercera etapa En esta etapa, se modifica la estructura del mensaje que se envía a través de Service Bus añadiendo los siguientes campos: error: Donde quedará almacenado el error, si se produce, al intentar ejecutar el comando asociado a dicho mensaje en la base de datos de Oracle. retryCount: Donde se almacenará el número de veces que se ha intentado procesar el mensaje, si procede. Estos nuevos campos se añaden debido a la necesidad de realizar un control sobre la cola de reintentos que se va a implementar próximamente. En la fase de análisis, durante las conversaciones con cliente, se planteó en utilizar la cola de DeadLetter para este cometido, pero se descartó por lo motivos que se explican a continuación: La necesidad de utilizar un modelo de mensaje que Microsoft considera en desuso, y no recomienda utilizar, para poder enviar mensajes explícitamente a esta cola. La robustez del sistema se basa en la no pérdida de mensajes. Si el sistema falla cuando se extraen mensajes de la DeadLetter el mensaje puede perderse. La necesidad de realizar una diferenciación entre los tres tipos de fallos detectados durante las pruebas: •Los fallos producidos por la imposibilidad de de conectar con la base de datos de Oracle. •Los fallos asociados al mensaje por lo cual son rechazados por la base de datos de Oracle. •Los fallos inesperados relacionados directamente con las Azure Function y con Azure. Esta diferenciación da como resultado, un sistema más sólido y aislado. Al tener una fuerte diferenciación entre los errores, el tratamiento de los mismos puede ser llevado a cabo por distintos equipos, los cuales estarán mas especializados. Por la razones anteriormente mencionadas, la nueva estructura de colas queda, ajustándose a los requisitos de cliente, así (a mayores de las colas asociadas a los Topic ySubscription mencionados en las anteriores iteraciones): Cola de reintentos automática: Donde quedan almacenados los mensajes que no han podido se manejados por la base de datos de Oracle debido a problemas de conexión con la misma. Esta cola sera manejada por una Azure Function, que se desarrollará en las siguientes iteraciones. 98 Cola de reintentos manual: Será la encargada de almacenar los mensajes que tienen algún tipo de error por asociado que hace que no puedan ser manejados la base de datos de Oracle. DeadLetter(Create, Update yDelete): Hay una por cada Topic y será la última salvaguarda de los mensajes. En caso de haber fallos inesperados de manera reiterada por parte de las Azure Functions o de Azure los mensajes serán almacenado, automáticamente por Service Bus, en esta cola. 5.0.14. Decimocuarta etapa En esta etapa, se modifican las Azure Functions en base da los campos creados en la anterior etapa 5.0.12. Se comienza por las Azure Functions encargadas de extraer los mensajes desde Microsoft Dynamics 365. Se crea el campo error vacío y se inicializa el contador de retryCount a cero. Por otro lado, las Azure Functions que manejan las conexiones con la base de datos de Oracle también sufren cambios. Cuando se produce una excepción, se almacenará la información asociada a dicha excepción, en base al filtro realizado en la undécima etapa 5.0.11, en el campo de error. También se aumenta el contador de retryCount en uno, se evalúa en base al error que se ha producido a que cola debe ser enviado el mensaje y se reenvía a dicha cola. 5.0.15. Decimoquinta etapa En esta etapa, se genera la Azure Function encargada de gestionar la cola de reenvío automático. Los pasos que sigue son los siguientes: La Azure Function realiza una consulta genérica a la base de datos de Oracle. Si dicha consulta no es respondida por Oracle, no se hará nada mas puesto que no tendría sentido reencolar mensajes que no podrán ser procesados. En el caso de que sí responda correctamente a la petición, se extraen los mensajes almacenados en la cola ”retryAutomatica”. Se evalúan los mensajes para determinar a que Topic y a que Subscription pertenecen. Se envían todos los mensajes que estaban almacenados en la cola al momento de iniciar la evaluación. Aquellos que lleguen después no se evalúan puesto que se considera que, si están siendo almacenados en la cola de ”retryAutomatica”la base de datos de Oracle vuelve a no estar disponible. Esta consulta de disponibilidad se realizará cada quince minutos, de acuerdo a los requisitos proporcionados por el cliente. 5.0.16. Decimosexta etapa En esta fase, se modificarán las Azure Functions encargadas de conectar a la base de datos de Oracle para ajustar las condicione en base a la funcionalidad de reintentar los mensajes. 99 Capítulo 5. Implementación A la Azure Function encargada de gestionar los mensajes asociados a registros de nueva creación, se le añade la comprobación de mensaje reintentado, si este es el caso, es necesario consultar a la base de datos de Oracle si dicho registro ya ha sido creado. Esto puede pasar en el caso de que el registro original haya sido actualizado en el lapso de tiempo que se produce cuando el que mensaje de nueva creación se encola en la cola de reintentos automática. Si el mensaje de actualización ha llegado antes que el mensaje de creación a la base de datos de Oracle, el registro ya esta creado con los datos más recientes, por tanto, el mensaje de creación debe desecharse. Por otro lado, la Azure Function encargada de manejar los mensajes de actualización también se modifica. Se añade una condición, a partir de la cual, el mensaje solo se insertará si su campo de MODIFIEDON tiene una fecha posterior a la fecha almacenada en el mismo campo de la base de datos de Oracle. La Azure Function encargada de manejar los mensajes de eliminación no necesitara ninguna modificación puesto que no se vera afectada por el retardo de un mensaje de ese tipo. 5.0.17. Decimoséptima iteración En esta etapa, se crea una nueva Azure Function. Esta Azure Function será la encargada de enviar e-mail en las condiciones que se detallarán a continuación. Esta Azure Function se ejecutará, automáticamente, cada quince minutos. Se enviará un e-mail al equipo de gestión en el caso de que haya más de cinco mensajes almacenados en la cola manual. Como en esta cola se almacenan mensajes, cuyo contenido es erróneo, sera necesario que una persona los evalúe manualmente para poder concretar donde está el fallo. Esta Azure Function enviará el aviso al personal que se encargará de ello facilitando las tareas de gestión. Por otro lado, se envía un e-mail al equipo de desarrollo en el caso de que haya un mensaje en cualquiera de las colas de DeadLetter asociadas a los Topic. En un flujo normal, no debería haber mensajes en estas colas puesto que, supondría, que han sido reintentados diez veces automáticamente por Service Bus teniendo fallos inesperados en cada una de esas ocasiones. Si estas condiciones se están produciendo, el equipo de desarrollo debe evaluar que circunstancias están provocando el comportamiento anormal del sistema. 5.0.18. Decimoctava etapa En esta etapa, se realiza un programa de consola para regularizar los datos de Microsoft Dynamics 365. La necesidad de este programa, se produce en dos ocasiones. La primera vez se da justo antes de poner en funcionamiento el sistema. Las Azure Functions encargadas de extraer los registros solo extraerán los susodichos registros que hayan sido modificados en el último minuto. Por tanto, el resto de registros no se enviarían a la base de datos de Oracle. La segunda ocasión es similar a la primera. En el caso de que el sistema esté un intervalo de tiempo sin funcionar, por la razón que sea, hará que una cierta cantidad de registros no sean 100 enviados a la base de datos de Oracle. Para solucionar esto, se ejecuta el programa de consola pasándole como argumentos el intervalo temporal en el cual es necesario enviar los registros que han sido creados o actualizados. No será necesario regularizar los registros eliminados puesto que la Azure Function que maneja estos mensajes los extrae de una entidad con unas condiciones especiales mencionadas en la sexta etapa 5.0.6. 5.0.19. Decimonovena etapa En esta etapa, se crea una nueva Azure Function encargada de manejar los mensajes almacenados en la cola manual. Como los mensajes almacenados en esta cola deben de ser tratados manualmente, la información de dichos mensajes se almacenará en Microsoft Dynamics 365 en una entidad llamada ”Mensaje cola manual”, que comparte la estructura del mensaje, definida en la quinta etapa 5.0.5 y en la decimotercera etapa 5.0.13. De esta manera, se pretende facilitar el análisis del mensaje al equipo encargado de esta tarea. 5.0.20. Vigésima etapa En esta etapa, se plantea mover la base de datos de Oracle de una máquina en local a la versión Cloud de Oracle. Después de varias pruebas, que incluyó contacto con el servicio técnico de la empresa Oracle, esta opción se descarta. Después de plantear esta opción a los clientes, en el contexto del TFG son los tutores, se decide que es mejor mantener la versión de base de datos de Oracle en local tal y como estaba definido en los requisitos 3.9 proporcionados durante la fase análisis . Todos los cambios realizados en esta etapa se descartan. 5.0.21. Vigésimo primera etapa En esta etapa, se modifica la Azure Function que envía los e-mail a los distintos equipos. En vez de comprobar la cola manual, ahora se comprueba la cantidad de mensajes almacenados en la entidad ”Mensaje cola manual”, que es donde se almacenan los mensajes fallidos. Cuando haya más de cinco registros en dicha entidad, se envía el e-mail. Se considera que el personal encargado de manejar los mensajes fallidos, los borrará de dicha entidad una vez que se han corregido. Al finalizar esta etapa se puede dar por concluida la fase de desarrollo al haber cumplimentado los requisitos proporcionados por el cliente. 101 Capítulo 6 Verificación En este capitulo, se realizan las pruebas pertinentes al sistema. La pruebas se centra en la lógica interna del software y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren cumpliendo, de esta manera, los requisitos proporcionados por el cliente 3.9 y confirmando la calidad del software desarrollado. 6.1. Pruebas de caja negra En esta sección se incluirán las pruebas de caja negra que se han realizado para comprobar el correcto funcionamiento del sistema desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. 6.1.1. Pruebas de caja negra CallToCrmCreateUpdate Prueba de caja negra 001 Descripción Se comprueba que los registros creados de añaden al Topic ”Create”con la Subscription ”Create” Entrada Registro de nueva creación. Resultado esperado El registro se añade correctamente. Resultado de la prueba Correcto Tabla 6.1: Prueba de caja negra 001 Prueba de caja negra 002 Descripción Se comprueba que los registros actualizados de añaden al Topic ”Update”con la Subscription ”Update” Entrada Registro actualizado. Resultado esperado El registro se añade correctamente. Resultado de la prueba Correcto Tabla 6.2: Prueba de caja negra 002 102 6.1. Pruebas de caja negra 6.1.2. Pruebas de caja negra CallToCrmDelete Prueba de caja negra 003 Descripción Se comprueba que los registros eliminados de añaden al Topic ”Delete”con la Subscription ”Delete”. Entrada Registro eliminado. Resultado esperado El registro se añade correctamente. Resultado de la prueba Correcto Tabla 6.3: Prueba de caja negra 003 Prueba de caja negra 004 Descripción Se comprueba que el registro asociado al mensaje que se acaba de enviar a Service Bus, ha sido eliminado correctamente de Microsotf Dynamics 365. Entrada Registro con la id: 6c44efb1-f6a1-4271-894a-9240de45ad4b. Resultado esperado El registro con la id: 6c44efb1-f6a1-4271-894a-9240de45ad4b ya no está en la entidad. Resultado de la prueba Correcto Tabla 6.4: Prueba de caja negra 004 103 Capítulo 6. Verificación 6.1.3. Pruebas de caja negra ConnectionToOracleCreate Prueba de caja negra 005 Descripción Se comprueba que los registros creados almacenados al Topic ”Create”con la Subscription ”Create”se pueden extraer de la cola. Entrada Conexión a la cola de Service Bus. Resultado esperado El registro se extrae correctamente. Resultado de la prueba Correcto Tabla 6.5: Prueba de caja negra 005 Prueba de caja negra 006 Descripción El comando de creación de un registro funciona correctamente en la base de datos de Oracle. Entrada INSERT INTO af_objeto (af_objetoid,af_name,createdon,modifiedon) values (’83b17e23-0a8d-e911-a971-000d3ab5a0d7’,’hfratpnwbf’,’12/06/2019 12:03:53’,’12/06/2019 12:03:53’) Resultado esperado La información proporcionada por el comando queda reflejada en Oracle. Resultado de la prueba Correcto. Tabla 6.6: Prueba de caja negra 006 Prueba de caja negra 007 Descripción Si el comando de creación falla por error relacionado con la conexión hacia la base de datos. Entrada INSERT INTO af_objeto (af_objetoid,af_name,createdon,modifiedon) values (’83b17e23-0a8d-e911-a971-000d3ab5a0d7’,’hfratpnwbf’,’12/06/2019 12:03:53’,’12/06/2019 12:03:53’) Resultado esperado El mensaje sera enviado a la cola de reintentos automática. Resultado de la prueba Correcto. Tabla 6.7: Prueba de caja negra 007 Prueba de caja negra 008 Descripción Si el comando de creación falla por error relacionado relacionado con el mensaje. Entrada INSERT INTO af_objeto (af_objetoid,af_name,createdon,modifiedon) values (’83b17e23-0a8d-e911-a971’,’hfratpnwbf’,’12/06/2019 12:03:53’,’12/06/2019 12:03:53’) Resultado esperado El mensaje sera enviado a la cola de reintentos manual. Resultado de la prueba Correcto. Tabla 6.8: Prueba de caja negra 008 Prueba de caja negra 009 Descripción Si el comando falla y el mensaje se ha intentado entregar tres veces pasa a la cola manual. Entrada {”tipo”:”Create”,”name_entity”:”af_objeto”,”id”:”83b17e23-0a8d-e911-a971-000d3ab5a0d7”,”key”:”af_obje- toid,af_name,createdon,modifiedon”, ”value”:”’83b17e23-0a8d-e911-a971-000d3ab5a0d7’,Úpdate hfratpnwbf’,’12/06/2019 12:03:53’,’12/06/2019 12:03:53”’,”error”:””,”retryCount”:3} Resultado esperado El mensaje sera enviado a la cola de reintentos manual. Resultado de la prueba Correcto. Tabla 6.9: Prueba de caja negra 009 104 6.1. Pruebas de caja negra 6.1.4. Pruebas de caja negra ConnectToOracleUpdate Prueba de caja negra 010 Descripción Se comprueba que los registros actualizados almacenados en la al Topic ”Update”con la Subscription ”Update”se pueden extraer de la cola. Entrada Conexión a la cola de Service Bus. Resultado esperado El registro se extrae correctamente. Resultado de la prueba Correcto Tabla 6.10: Prueba de caja negra 010 Prueba de caja negra 011 Descripción El comando de consulta a la base de datos devuelve el registro relacionado con el mensaje de actualización Entrada select * from af_objeto where af_objetoid=’83b17e23-0a8d-e911-a971-000d3ab5a0d7’; Resultado esperado af_objetoid:83b17e23-0a8d-e911-a971-000d3ab5a0d7 af_name:Update createdon: 12/06/2019 12:03:53 modifiedon:12/06/2019 15:03:53 Resultado de la prueba Correcto. Tabla 6.11: Prueba de caja negra 011 Prueba de caja negra 012 Descripción En base a la información devuelta por Oracle y a la información almacenada en el registro se creara un comando de actualización coherente a los datos que han sido actualizados. Entrada Mensaje {”tipo”:”Update”,”name_entity”:”af_objeto”, ”id”:”83b17e23-0a8d-e911-a971-111d3ab5a0d7”, ”key”:”af_objetoid, af_name,createdon,modifiedon”, ”value”:”’83b17e23-0a8d-e911-a971-000d3ab5a0d7’, Úpdate dsfdfff’,’12/06/2019 12:03:53’, ’12/06/2019 12:23:53”’, ”error”:””,”retryCount”:1} Registro Oracle af_objetoid:83b17e23-0a8d-e911-a971-000d3ab5a0d7 af_name: update createdon: 12/06/2019 12:03:53 modifiedon: 12/06/2019 12:03:53 Resultado esperado En Oracle: af_objetoid:83b17e23-0a8d-e911-a971-000d3ab5a0d7 af_name: Update dsfdfff’ createdon: 12/06/2019 12:03:53 modifiedon: 12/06/2019 12:03:53 Resultado de la prueba Correcto. Tabla 6.12: Prueba de caja negra 012 105 Capítulo 6. Verificación Prueba de caja negra 013 Descripción Si el registro almacenado en Oracle tiene una fecha almacenada en MODIFIEDON posterior a la que esta guardada en el mensaje dicho mensaje se desechará. La información más reciente es la que debe prevalecer. Entrada Mensaje {”tipo”:”Update”,”name_entity”:”af_objeto”,”id”:”83b17e23- 0a8d-e911-a971-111d3ab5a0d7”, ”key”:”af_objetoid,af_- name,createdon,modifiedon”,”value”:”’83b17e23-0a8d-e911- a971-000d3ab5a0d7’,Úpdate dsfdfff’,’12/06/2019 12:03:53’, ’12/06/2019 12:03:53”’,”error”:””,”retryCount”:1} Registro Oracle af_objetoid:83b17e23-0a8d-e911-a971-000d3ab5a0d7 af_name: update createdon: 12/06/2019 12:03:53 modifiedon: 12/06/2019 12:20:53 Resultado esperado El mensaje se desechará. Resultado de la prueba Correcto. Tabla 6.13: Prueba de caja negra 013 Prueba de caja negra 014 Descripción Los mensajes de creación que den error al intentar crearlos en la base de datos de Oracle, debido a un mensaje incorrecto se enviara a la cola de reintentos manual. Entrada {”tipo”:”Update”,”name_entity”:”af_objeto”,”id”:”83b17e23-0a8d-e911-a971”, ”key”:”af_objetoid,af_na- me,createdon,modifiedon”, ”value”:”’83b17e23-0a8d-e911-a971-000d3ab5a0d7’,Úpdate dsfdfff’,’12/06/2019 12:03:53’, ’12/06/2019 12:23:53”’,”error”:””,”retryCount”:0} Resultado esperado Identificador no válido. El mensaje se reenvía la cola de reintentos manual. Resultado de la prueba Fallo. No se añadían correctamente al haber un error ortográfico en la cadena de conexión. Tabla 6.14: Prueba de caja negra 014 Prueba de caja negra 015 Descripción Los mensajes de creación que den error al intentar crearlos en la base de datos de Oracle debido a un problema relacionado con la conexión se envían a la cola de reintentos automática. Entrada {”tipo”:”Update”,”name_entity”:”af_objeto”,”id”:”83b17e23-0a8d-e911-a971-111d3ab5a0d7”, ”key”:”af_- objetoid,af_name,createdon,modifiedon”, ”value”:”’83b17e23-0a8d-e911-a971-000d3ab5a0d7’, Úpdate dsfdfff’,’12/06/2019 12:03:53’, ’12/06/2019 12:23:53”’,”error”:””,”retryCount”:0} Resultado esperado No se puede conectar con Oracle, Timeout. El mensaje se reenvía la cola de reintentos automática. Resultado de la prueba Fallo. No se añadían correctamente al haber un error ortográfico en la cadena de conexión. Tabla 6.15: Prueba de caja negra 015 Prueba de caja negra 016 Descripción Los mensajes de creación que dan error al intentar crearlos en la base de datos de Oracle y ya se ha intentado entregarlos tres veces pasan a cola manual. Entrada {”tipo”:”Update”,”name_entity”:”af_objeto”,”id”:”83b17e23-0a8d-e911-a971-111d3ab5a0d7”,”key”:”af_- objetoid,af_name,createdon,modifiedon”, ”value”:”’83b17e23-0a8d-e911-a971-000d3ab5a0d7’,Úpdate dsfdfff’,’12/06/2019 12:03:53’, ’12/06/2019 12:23:53”’,”error”:””,”retryCount”:3} Resultado esperado El mensaje se reenvía la cola de reintentos manual.. Resultado de la prueba Correcto. Tabla 6.16: Prueba de caja negra 016 106 6.1. Pruebas de caja negra 6.1.5. Pruebas de caja negra ConnectionToOracleDelete Prueba de caja negra 017 Descripción Se comprueba que los registros eliminados almacenados en el Tema ”Delete”con la suscripción ”Delete”pueden extraer de la cola. Entrada Conexión a la cola de Service Bus. Resultado esperado El registro se extrae correctamente. Resultado de la prueba Correcto Tabla 6.17: Prueba de caja negra 017 Prueba de caja negra 018 Descripción Al intentar ejecutar el comando de eliminación Oracle informa de que se ha producido un error relacionado con el formato del mensaje. Dicho mensaje será reenviado a la cola manual. Entrada {”tipo”:”Update”,”name_entity”:”af_objeto”,”id”:”83b17e23-0a8d-e911-a971-111d3ab5a0d7”,”key”:”af_- objetoid,af_name,createdon,modifiedon”, ”value”:”’83b17e23-0a8d-e911-a971-000d3ab5a0d7’,Úpdate dsfdfff’,’12/06/2019 12:03:53’, ’12/06/2019 12:23:53”’,”error”:””,”retryCount”:0} Resultado esperado No se puede conectar con Oracle, Timeout. El mensaje se ha enviado a la cola automática.. Resultado de la prueba Incorrecto. Las condiciones no estaban correctamente definidas. Tabla 6.18: Prueba de caja negra 018 Prueba de caja negra 019 Descripción Al intentar ejecutar el comando de eliminación Oracle informa de que se ha producido un error relacionado con el conexión a Oracle. Dicho mensaje será reenviado a la cola de reintentos automática. Entrada {”tipo”:”Delete”,”name_entity”:”af_objeto”, ”id”:”00000000-0000-0000-0000-000000000000”,”key":”af_- objetoid”,”value”:”’7bee8edb-318d-e911-a971”’,”error”:””,”retryCount”:0} Resultado esperado Se ha producido un error al intentar insertar un registro duplicado. El mensaje se ha enviado a la cola manual. Resultado de la prueba Incorrecto. Las condiciones no estaban correctamente definidas. . Tabla 6.19: Prueba de caja negra 018 Prueba de caja negra 020 Descripción Al intentar ejecutar el comando de eliminación Oracle informa de que se ha producido error y el mensaje ya ha se ha intentado entregar tres veces. Pasa a cola manual. Entrada Mensaje {”tipo”:”Delete”,”name_entity”:”af_objeto”, ”id”:”00000000-0000-0000-0000-000000000000”, ”key":”af_objetoid”,”value”:”’7bee8edb-318d-e911-a971”’, ”error”:””,”retryCount”3} Base de datos Oracle Sin iniciar. Resultado esperado . El mensaje se ha enviado a la cola manual. Resultado de la prueba Correcto. Tabla 6.20: Prueba de caja negra 020 107 Capítulo 6. Verificación 6.2.2. Pruebas de caja blanca CallToCrmDelete Prueba de caja blanca 007 Descripción Se comprueba que la Azure Function extrae correctamente lo registros eliminamos del Microsoft Dynamics 365 dentro de un intervalo de tiempo determinado. Entrada Registro actualizado en Microsoft Dynamics 365 con el GUID: {F949E58F-D766-E911-A964-000D3AB5A84E} 70 segundos antes de iniciar la Azure Function Resultado esperado La Azure Function extrae el registro con el GUID: {F949E58F-D766-E911-A964-000D3AB5A84E} Resultado de la prueba Correcto Tabla 6.38: Prueba de caja blanca 007 114 6.2. Pruebas de caja blanca 6.2.3. Pruebas de caja blanca ConnectionToOracleCreate Prueba de caja blanca 009 Descripción Se comprueba que el campo retryCount se evalúa correctamente. Entrada {”tipo”:”Create”,”name_entity”:”af_objeto”,”id”:”6367ff45-3b8c-e911-a96a-000d3ab5a3d0”, ”key":”af_objetoid,af_name,createdon,modifiedon”, ”value”:”’6367ff45-3b8c-e911-a96a-000d3ab5a3d0’,’pvvglyjduw’,’11/06/2019 11:23:07’,’11/06/2019 11:23:07”’, ”error”:””,retryCount”:0} Resultado esperado El mensaje no ha sido reintentado. Resultado de la prueba Correcto. Tabla 6.39: Prueba de caja blanca 009 Prueba de caja blanca 010 Descripción Cuando el mensaje de creación tenga almacenado un valor en su retryCount superior a 0, se consultará a la base de dats de Oracle si la información almacenada en dicho mensaje ya está guardada dentro del sistema de bases de datos de Oracle. Entrada {”tipo”:”Create”,”name_entity”:”af_objeto”,”id”:”6367ff45-3b9c-e911-a96a-000d3ab5a3d2”, ”key":”af_objetoid,af_name,createdon,modifiedon”, ”value”:”’6367ff45-3b8c-e911-a96a-000d3ab5a3d0’,’pvvpllyjduw’,’11/06/2019 11:24:07’,’11/06/2019 11:24:07”’,”error”:””,retryCount”:1} Resultado esperado En la base de datos ya está creado el registro asociado. Resultado de la prueba Correcto. Tabla 6.40: Prueba de caja blanca 010 Prueba de caja blanca 011 Descripción Si el mensaje de creación, que tiene un valor en retryCount superior a 0, tiene información de un registro que ya no esta creado en Oracle se creará dicho mensaje en la base datos de Oracle. Entrada {”tipo”:”Create”,”name_entity”:”af_objeto”,”id”:”6367ff45-3b9c-e911-a96a-000d3ab5a3d2”, ”key":”af_objetoid,af_name,createdon,modifiedon”, ”value”:”’6367ff45-3b8c-e911-a96a-000d3ab5a3d1’,’pvvpplyjduw’,’11/06/2019 11:24:07’,’11/06/2019 11:24:07”’,”error”:””,retryCount”:1} Resultado esperado El mensaje se crea en la base de datos de Oracle. Resultado de la prueba Correcto. Tabla 6.41: Prueba de caja blanca 011 Prueba de caja blanca 012 Descripción Se comprueba si el comando de consulta, generado con la información del mensaje recibido que tiene un retryCount suprior a 0, es correcto. Entrada {”tipo”:”Create”,”name_entity”:”af_objeto”,”id”:”6367ff45-3b9c-e911-a85a-000d3ab5a3d2”, ”key":”af_objetoid,af_name,createdon,modifiedon”, ”value”:”’6367ff45-3b8c-e915-a96a-000d3ab5a3d1’,’ssppslyjduw’,’11/06/2019 11:24:07’,’11/06/2019 11:24:07”’,”error”:””,retryCount”:1} Resultado esperado select * from af_objeto where af_objetoid=’6367ff45-3b8c-e915-a96a-000d3ab5a3d1’; Resultado de la prueba Correcto. Tabla 6.42: Prueba de caja blanca 012 Prueba de caja blanca 013 Descripción Si el mensaje se ha consultado correctamente, del mensaje de creación con retryCount superior a 0, el mensaje no se enviará a ninguna cola. Entrada message.error=Succefull Resultado esperado Ninguna acción Resultado de la prueba Correcto. Tabla 6.43: Prueba de caja blanca 013 115 Capítulo 6. Verificación Prueba de caja blanca 014 Descripción Si al realizar la consulta, en relación a un mensaje creación cuyo retryCount es superior a 0, se produce un error relacionado con el formato del mensaje dicho mensaje se reenvía a la cola manual. Entrada {”tipo”:”Create”,”name_entity”:”af_objeto”,”id”:”6367ff45-3b9c-e911-a96a-000d3ab5a3d2”, ”key":”af_objetoid,af_name,createdon,modifiedon”, ”value”:”’6367ff45-3b8c-e915-a96a-000d3ab5a3d1’,’sssslyjduw’,’11/06/2019 11:24:07’,’11/06/2019 11:24:07”’,”error”:””,retryCount”:1} Resultado esperado El mensaje queda almacenado en la cola manual. Resultado de la prueba Correcto. Tabla 6.44: Prueba de caja blanca 014 Prueba de caja blanca 015 Descripción Si al realizar la consulta, en relación a un mensaje creación cuyo retryCount es superior a 0, se produce un error relacionado con la conexión hacia la base de datos dicho mensaje se reenvía a la cola automática. Entrada {”tipo”:”Create”,”name_entity”:”af_objeto”,”id”:”6367ff45-3b9c-e911-a85a-000d3ab5a3d2”, ”key":”af_objetoid,af_name,createdon,modifiedon”, ”value”:”’6367ff45-3b8c-e915-a96a-000d3ab5a3d1’,’ssppslyjduw’,’11/06/2019 11:24:07’,’11/06/2019 11:24:07”’,”error”:””,retryCount”:1} Resultado esperado El mensaje queda almacenado en la cola automática. Resultado de la prueba Correcto. Tabla 6.45: Prueba de caja blanca 015 Prueba de caja blanca 016 Descripción El comando de creación de registro se crea correctamente usando la información almacenada dentro del mensaje recibido. Entrada {”tipo”:”Create”,”name_entity”:”af_objeto”,”id”:”83b17e23-0a8d-e911-a971-000d3ab5a0d7”, ”key”:”af_objetoid,af_name,createdon,modifiedon”, ”value”:”’83b17e23-0a8d-e911-a971-000d3ab5a0d7’,Úpdate hfratpnwbf’, ’12/06/2019 12:03:53’,’12/06/2019 12:03:53”’,”error”:””,”retryCount”:0} Resultado esperado INSERT INTO af_objeto (af_objetoid,af_name,createdon,modifiedon) values (’83b17e23-0a8d-e911-a971-000d3ab5a0d7’,Úpdate hfratpnwbf’,’ 12/06/2019 12:03:53’,’12/06/2019 12:03:53’) Resultado de la prueba Correcto. Tabla 6.46: Prueba de caja blanca 016 Prueba de caja blanca 017 Descripción Los errores devueltos por Oracle son filtrados correctamente. Entrada Mensaje de consulta sin haber iniciado el servidor de Oracle. Resultado esperado No se puede conectar con Oracle, Timeout Resultado de la prueba Correcto. Tabla 6.47: Prueba de caja blanca 017 116 6.2. Pruebas de caja blanca 6.2.4. Pruebas de caja blanca ConnectToOracleUpdate Prueba de caja blanca 018 Descripción Los mensajes de actualización generan un comando correcto de consulta. Entrada {”tipo”:”Update”,”name_entity”:”af_objeto”,”id”:”83b17e23-0a8d-e911-a971-111d3ab5a0d7”, ”key”:”af_objetoid,af_name,createdon,modifiedon”, ”value”:”’83b17e23-0a8d-e911-a971-000d3ab5a0d7’,Úpdate dsfdfff’, ’12/06/2019 12:03:53’,’12/06/2019 12:03:53”’,”error”:””,”retryCount”:0} Resultado esperado select * from af_objeto where af_objetoid=’83b17e23-0a8d-e911-a971-000d3ab5a0d7’; Resultado de la prueba Correcto. Tabla 6.48: Prueba de caja blanca 018 Prueba de caja blanca 019 Descripción Si la consulta acerca del mensaje de creación informa de que no hay registro asociado, los datos se crearan como nuevos. Entrada Mensaje {”tipo”:”Update”,”name_entity”:”af_objeto”,”id”:”83b17e23-0a8d-e911-a971-111d3ab5a0d7”, ”key”:”af_objetoid,af_name,createdon,modifiedon”, ”value”:”’83b17e23-0a8d-e911-a971-000d3ab5a0d7’,Úpdate dsfdfff’,’12/06/2019 12:03:53’, ’12/06/2019 12:03:53”’,”error”:””,”retryCount”:1} Registro Oracle Vacío Resultado esperado En Oracle: af_objetoid:83b17e23-0a8d-e911-a971-000d3ab5a0d7 af_name: update createdon: 12/06/2019 12:03:53 modifiedon: 12/06/2019 12:20:53 Resultado de la prueba Correcto. Tabla 6.49: Prueba de caja blanca 019 6.2.5. Pruebas de caja blanca ConnectionToOracleDelete Prueba de caja blanca 020 Descripción El mensaje de eliminación se convierte en un comando de Oracle. Entrada {”tipo”:”Delete”,”name_entity”:”af_objeto”, ”id”:”00000000-0000-0000-0000-000000000000”, ”key":”af_objetoid”,”value”:”’7bee8edb-318d-e911-a971-000d3ab5a0d7”’, ”error”:””,”retryCount”:0} Resultado esperado DELETE FROM af_objetoid WHERE af_objetoid = ’7bee8edb-318d-e911-a971-000d3ab5a0d7’ Resultado de la prueba Correcto. Tabla 6.50: Prueba de caja blanca 020 117 Capítulo 6. Verificación 6.2.6. Pruebas de caja blanca RetryAutomatica Prueba de caja blanca 021 Descripción Se comprueba la disponibilidad de Oracle enviado un comando de consulta. Entrada select * from countries where country_id=ÁR’ Resultado esperado Conexión con Oracle realizada Resultado de la prueba Correcto. Tabla 6.51: Prueba de caja blanca 021 Prueba de caja blanca 022 Descripción Se comprueba la falta de disponibilidad de la base de datos de Oracle enviado un comando de consulta. Entrada Mensaje select * from countries where country_id=ÁR’ Base de datos Oracle Sin iniciar. Resultado esperado La Azure Function finaliza. Resultado de la prueba Correcto. Tabla 6.52: Prueba de caja blanca 022 118 6.2. Pruebas de caja blanca 6.2.7. Pruebas de caja blanca EnvioEmailColaMensajesFallidos Prueba de caja blanca 023 Descripción El número de mensajes almacenados en Microsoft Dynamics 365por la cola manual se extrae correctamente. Entrada commandmanual Resultado esperado El mismo valor que muestra el portal de Microsoft Dynamics 365. Resultado de la prueba Correcto. Tabla 6.53: Prueba de caja blanca 023 Prueba de caja blanca 024 Descripción El número de mensajes almacenados en la DeadLetter de ”create” se extrae correctamente. Entrada DeadLetter de ”create” Resultado esperado El mismo valor que muestra el portal de Azure. Resultado de la prueba Correcto. Tabla 6.54: Prueba de caja blanca 024 Prueba de caja blanca 025 Descripción El número de mensajes almacenados en la DeadLetter de ”update” se extrae correctamente. Entrada DeadLetter de ”update” Resultado esperado El mismo valor que muestra el portal de Azure. Resultado de la prueba Correcto. Tabla 6.55: Prueba de caja blanca 025 Prueba de caja blanca 026 Descripción El número de mensajes almacenados en la DeadLetter de ”delete” se extrae correctamente. Entrada DeadLetter de ”delete” Resultado esperado El mismo valor que muestra el portal de Azure. Resultado de la prueba Correcto. Tabla 6.56: Prueba de caja blanca 026 119 Capítulo 6. Verificación 6.2.8. Pruebas de caja blanca RegularizaciónDatosCrm Prueba de caja blanca 027 Descripción Se comprueba que los registros extraídos de Microsoft Dynamics 365 fueron modificados dentro del intervalo temporal proporcionado por el usuario. Entrada Fecha de inicio 05/05/2019 12:00:00 Fecha de finalización 08/05/2019 12:00:00 Resultado esperado El valor del campo modifiedon, de los registros extraídos, esta dentro del intervalo temporal proporcionado por el usuario. Resultado de la prueba Correcto. Tabla 6.57: Prueba de caja blanca 027 Prueba de caja blanca 028 Descripción Se genera un mensaje acorde a los datos extraídos. Entrada Datos del registro. Resultado esperado Mensaje correcto. Resultado de la prueba Correcto. Tabla 6.58: Prueba de caja blanca 028 120 Capítulo 7 Conclusiones y trabajo futuro 7.1. Conclusiones El valor añadido que se puede extraer de la realización de este proyecto, es el aprendizaje que me ha supuesto. El cambio de paradigma, al ser en la nube, y el proceso de aprendizaje en una tecnología nueva, me ha permitido tener un cambio de mentalidad al afrontar los retos, que este trabajo ha puesto de manifiesto. También, todo el aprendizaje acerca del funcionamiento del procesamiento en la nube, gracias a las Azure Functions, el modelo de colas y la potencia que se puede obtener de las mismas ha hecho que el desarrollo de este TFG haya sido muy satisfactorio. Las Azure Functions son un modo de generar código útil muy enfocado a un problema concreto, que me ha permitido desarrollar soluciones muy específicas al contexto en que debía aplicarlas. El hecho de no tener que preocuparme por una infraestructura asociada, me ha dado la oportunidad de probar distintos enfoques sin tener que ajustar una infraestructura que limite dichas pruebas por el perjuicio de obligarme a desechar trabajo. Por su parte, el uso de Service Bus y la investigación relativa a ello, me ha permitido conocer tecnologías y modelos de los cuales tenía un conocimiento muy superficial. Al igual que sucedió con el uso de Azure Functions, la ausencia de necesidad de administrar un servidor me ha permitido realizar pruebas y desarrollar soluciones muy diversas sin tener preocuparme de tener que cambiar toda la infraestructura para poder desarrollarlas. Por otra parte, me ha hecho valorar, más si cabe, todo lo que he aprendido durante estos años en la carrera puesto que me ha permitido llevar a cabo todas esta enseñanzas en un trabajo, dándome una visión global de los procesos de ingeniería utilizados. 7.2. Trabajo futuro Las líneas futuro de desarrollo de este sistema vendrán guiadas por las siguientes ideas: Aumentar la cantidad de entidades, de las cuales, se mantiene la persistencia de sus datos. Ampliar la cantidad de Functions que consumen los mensajes de Service Bus y los insertan en la base de datos. Para ello, se utilizará las ventajas que ofrecen las suscripciones de los Temas. A diferencia de las colas de Service Bus, en las que un solo destinatario procesa cada mensaje, los temas y las suscripciones proporcionan una forma de comunicación de uno a varios 121 Capítulo 7. Conclusiones y trabajo futuro mediante un patrón de publicación/suscripción. Es posible registrar varias suscripciones en un tema. Cuando un mensaje se envía a un tema, pasa a estar disponible para cada suscripción para la administración o el procesamiento de manera independiente. Una suscripción a un tema se asemeja a una cola virtual que recibe copias de los mensajes que se enviaron al tema. Opcionalmente, puede registrar reglas de filtros para un tema por suscripción, lo que le permite filtrar o restringir qué mensajes para un tema reciben las suscripciones a un tema. De esta manera en el caso, por poner un ejemplo, que la cantidad de registros de creación aumentaran dentro del sistema, sería muy sencillo escalarlo. A largo plazo, sería recomendable hacer más robusto el algoritmo que consulta la disponibilidad de la base de datos, en la Azure Function que maneja los reintentos automáticos. Para ello, sería recomendable utilizar el patrón disyuntor [16]. Implementar una IA encargada de arreglar o formatear los mensajes fallidos. 122 Bibliografía [1] [Organización: Microsoft] , Patrón Command and Query Responsibility Segregation [Online], Disponible en: https://docs.microsoft.com/es-es/azure/architecture/patterns/cqrs [Publicado: Jun 23, 2017] [2] [Organización: Uniwebsidad] , Modelo en cascada [Online], Disponible en: https://uniwebsidad.com/libros/tdd/capitulo-1/modelo-en-cascada [Publicado: 2010-2013] [3] [Organización: Oracle] , Descargas de Software: Descarga gratuita, aprendizaje gratuito, evaluación ilimitada [Online], Disponible en: https://www.oracle.com/technetwork/es/indexes/downloads/index. html [Accedido: Feb 21, 2019 [4] [Organización: Microsoft] , Información general de auditoría [Online], Disponible en: https://docs.microsoft.com/es-es/dynamics365/ customer-engagement/developer/auditing-overview [Publicado: Ene 29, 2019] [5] [Organización: Microsoft] , Información general de colas de mensajes fallidos de Service Bus [Online], Disponible en: https://docs.microsoft.com/es-es/azure/service-bus-messaging/ service-bus-dead-letter-queues [Publicado: May 21, 2019] [6] [Organización: Microsoft] , Patrón de disyuntor [Online], Disponible en: https://docs.microsoft.com/es-es/azure/architecture/patterns/ circuit-breaker [Publicado: Jun 23, 2017] [7] [Organización: Microsoft] , Patrón Retry [Online], Disponible en: https://docs.microsoft.com/es-es/azure/architecture/patterns/ retry [Publicado: Jun 23, 2017] [8] [Organización: Microsoft] , Estilos de arquitectura [Online], Disponible en: https://docs.microsoft.com/es-es/azure/architecture/guide/ architecture-styles/ [Publicado: Sep 30, 2018] [9] [Organización: dofactory] , Patrón Iterator [Online], Disponible en: https://www.dofactory.com/net/iterator-design-pattern [Publicado: 2019] 123 Anexo A. Manual de Instalación 9. Así es como se ve finalmente A.9. Figura A.9: Portal de Azure. Despliegue de Plugin Papelera Reciclaje En el siguiente apartado, indicaremos los pasos a seguir para la instalación de un Plugin encargado de salvar los datos necesarios de un registro para su posterior eliminación dentro de la base de datos de Oracle. Requisitos previos Como requisito previos serán necesarias los siguientes: Será necesario compilar el Plugin para obtener la .dll derivada. Además, dicha .dll debe de ir firmada. Será necesario tener instalado la herramienta XrmToolBox [17] con el Plugin PluginRegistration [18] En la herramienta XrmToolBox estará, previamente, creada la conexión a CRM dynamic 365. 1. Se busca el Plugin, llamado Plugin Resgistration en la herramienta y se abre A.10. 130 Figura A.10: Búsqueda de Plugin Resgistration. 2. Se abre Register para registrar una nueva Assmeby A.11. Figura A.11: Registro de una nueva Assembly. 3. Se busca la .dll y se carga A.12. 131 Anexo A. Manual de Instalación Figura A.12: Carga de la .dll. 4. Una vez registrada, es necesario registrar un nuevo paso A.13. Figura A.13: Registro de un nuevo paso. 132 5. Se indica que, cada vez que se elimine una entidad dentro de Microsoft Dynamics 365, el Plugin debe de emperezar a funcionar A.14. Figura A.14: Configuración del nuevo paso. 133 Anexo B Manuales de Usuario Programa de consola de regularización de registros en Microsoft Dynamics 365 El siguiente manual, será utilizado por el equipo de gestión para regularizar registros que no hayan podido ser consumidos por las Azure Functions debido a una interrupción del servicio. 1. Se inicia el programa de consola, usando para ello el IDE Visual Studio 2017 B.1. Figura B.1: Inicio de la aplicación de consola. 2. Se introducen las fechas que conforman el intervalo temporal en el cual se extraerán los datos de Microsoft Dynamics 365. La consola mostrará que registros han sido codificados como mensaje y ha que Topic se ha enviado B.2. Figura B.2: Resultados arrojados por la consola. Creación, actualización y borrado de registros dentro de Microsoft Dynamics 365 En el siguiente manual, se explicara como crear, actualizar y borrar dentro del sistema de Microsoft Dynamics 365, desde el punto de vista de un usuario. 134 Figura B.3: Vista de una entidad concreta. 1. Para crear un registro, dentro de una entidad concreta, solo es necesario pulsar sobre el botón Nuevo B.4. Figura B.4: Creación de registros en Microsoft Dynamics 365, paso 1 2. Se rellenan los campos del formulario y se pulsa sobre el botón Guardar para que esta información quede reflejada en el sistema B.5. Figura B.5: Creación de registros en Microsoft Dynamics 365, paso 2 3. Finalmente, así es como queda almacenada la información en el nuevo registro B.6. Figura B.6: Creación de registros en Microsoft Dynamics 365, paso 3 135 Anexo B. Manuales de Usuario 4. Para actualizar el registro creado anteriormente, solo es necesario cambiar la información que esta almacenada en los campos B.7. Figura B.7: Actualización de registros en Microsoft Dynamics 365, paso 1 5. Se pulsa sobre el icono de Guardar para que esta información sobreescriba a la que esta almacenada.B.8 Figura B.8: Actualización de registros en Microsoft Dynamics 365, paso 2 6. Por último, si es necesario eliminar el registro se pulsa sobre el botón Eliminar B.9. Figura B.9: Eliminación de registros en Microsoft Dynamics 365, paso 1 7. Aparece una ventana donde se pide confirmar la eliminación. Se pulsa sobre el botón Eliminar B.10. Figura B.10: Eliminación de registros en Microsoft Dynamics 365, paso 2 8. La información más relevante de la entidad eliminada aparece dentro de la entidad Papelera B.11. Figura B.11: Eliminación de registros en Microsoft Dynamics 365, paso 3 136 Anexo C Comparativa: Azure Service Bus vs RabbitMQ Definición de sistemas Azure Service Microsoft Service Bus es un agente de mensajes de integración empresarial completamente administrado. Service Bus se usa normalmente para desacoplar las aplicaciones y los servicios entre sí y es una plataforma segura y confiable para datos asincrónicos y transferencia de estado. [19] Las principales preocupaciones arquitectónicas, abordadas por los mensajes, son las siguientes: Durabilidad: Los mensajes se almacenan en un lugar duradero y la aplicación puede leerlos después de que aparezcan. Confiabilidad: Los mensajes ayudan a implementar la confiabilidad puesto que estos mensajes se almacenan en el disco Disponibilidad de mensajes: los mensajes están disponibles para aplicaciones de consumo después de la restauración de la conectividad y el tiempo de inactividad anterior. Azure proporciona colas y temas del bus de servicio para implementar patrones de mensajería dentro de las aplicaciones. El Service Bus de Azure brinda soporte para mensajes de 256 KB tamaño.[2] RabbitMQ RabbitMQ, un sistema de mensajería empresarial completo y altamente confiable basado en el estándar AMQP. Está licenciado bajo la licencia de código abierto Mozilla Public License y cuenta con una distribución independiente de plataformas. Debido a esto es de los más extendidos, incluso existe un módulo de puppetlabs que permite instalarlo, configurarlo y administrarlo. Sus características principales son: Garantía de entrega. Enrutamiento flexible. Clusterización. 137 Anexo C. Comparativa: Azure Service Bus vs RabbitMQ Federación. Alta disponibilidad. Tolerancia a fallos. Comparativa Conceptos Namespaces Microsoft Service Bus Un namespace es un contenedor con un ámbito para todos los componentes de la mensajería. Varias colas y temas pueden residir en un único espacio de nombres, y los espacios de nombres suelen servir de contenedores de aplicación. RabbitMQ Rabbit no tiene un concepto de namespace, pero hay mucha similitud con el host virtual de Rabbit. El host virtual es compatible con los controles de seguridad similares alrededor del host virtual, como lo haría Microsoft Service Bus con un espacio de nombres. RabbitMQ emplea una realización más tangible de los hosts virtuales al convertirlo efectivamente en ”clusters virtuales”encima del broker. Esto significa que no solo los hosts virtuales no comparten intercambios y colas, sino que los Usuarios, las ACL, las Políticas, etc. son específicos de cada host virtual. Exchanges Microsoft Service Bus El uso del objeto ”Topic”en Service Bus es muy similar al objeto ”Exchange”en Rabbit. Los Topics pueden tener múltiples registros. Esto es así debido al sistema que emplea basado en suscripciones, en el cual un Topic puede tener registradas múltiples suscripciones, estando cada una asociada a un receptor. Dicho receptor solo recibirá los mensajes que hayan sido previamente filtrados por la propia suscripción, lo que permite controlar la información que llega a cada receptor atendiendo, por ejemplo, al perfil del mismo. RabbitMQ El ”Exchange”es el objeto de mensajería al que se envían los mensajes. Los hay de varios tipos: Direct Exchanges:Este tipo es útil cuando se desea distinguir los mensajes publicados en el mismo exchange utilizando un identificador simple. Entrega mensajes a colas basándose en las routing keys de los mensajes que funciona como la ”dirección”que el exchange usa para 138 decidir dónde enrutar el mensaje. Un mensaje va a la/s cola/s cuya binding key coincida exactamente con la routing key del mensaje. Si la routing key no coincide con ninguna binding key, será descartado. Exchange por defecto: Es un direct exchange pre-declarado sin nombre, generalmente referido por la cadena vacía ” ”. Cuando se usa este exchange, el mensaje será entregado a la cola cuyo nombre sea igual a la routing key del mensaje. Cada cola se enlaza automáticamente al exchange por defecto con una routing key que es igual que el nombre de la cola. Topic Exchange:Este tipo de exchanges enrutan mensajes a colas basadas en coincidencias de comodines entre la routing key y algo llamado routing pattern, especificado por el binding de la cola. Los mensajes se enrutan a una o varias colas en función de si hay coincidencia entre una routing key de mensaje y este patrón. Fanout Exchange:Este exchange copia y enruta un mensaje recibido a todas las colas que están vinculadas a él, independientemente de las routing keys o la coincidencia de patrones como pasaba con los exchanges anteriores. Las keys proporcionadas simplemente serán ignoradas. Headers Exchange:Estos exchanges son muy similares a los Topic exchanges, pero se enruta en función de los valores de cabeceras en lugar de las routing key. Un mensaje se considera coincidente si el valor de la cabecera es igual al valor especificado en el binding. Dead Letter Exchange:Si no se puede encontrar una cola coincidente para un mensaje, el mensaje se eliminará silenciosamente. RabbitMQ proporciona una extensión AMQP conocida como ”Dead Letter Exchange”que proporciona funcionalidad para capturar mensajes que no se pueden entregar Colas Microsoft Service Bus Los mensajes se envían y se reciben desde colas. Las colas permiten almacenar mensajes hasta que la aplicación receptora está disponible para recibirlos y procesarlos C.1. Los mensajes de las Figura C.1: Modelo de colas de Service Bus colas se ordenan y se les asigna una marca de tiempo a su llegada. Una vez aceptado, el mensaje se conserva de forma segura en almacenamiento redundante. Los mensajes se entregan en modo de extracción, que entrega los mensajes a una solicitud. RabbitMQ Funciona exactamente igual. 139