Gestión de calendarios para un servicio hospitalario
Abstract
El objetivo principal de este proyecto es diseñar e implementar un servicio de calendarios que permita publicar los turnos de los profesionales de un servicio hospitalario. Además, se generarán los calendarios individuales de los doctores involucrados, que les serán enviados por correo electrónico. La solución ha sido diseñada en el entorno Spring y siguiendo el estándar iCalendar. Para ello se han utilizado las librerías ical4j y Javaxmail. Este proyecto se basa en el trabajo realizado por Miguel Ángel González-Alorda Cantero titulado “Servicio para la gestión de actividades asistenciales complementarias” [1] y supone una versión de este, con las funciones de gestión de calendarios incorporadas.
Full text
Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Gestión de calendarios para un servicio hospitalario Autora: Carmen Cohen Calvo Tutora: Dra. Isabel Román Martínez Departamento de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2022
2
Trabajo de Fin de Grado Ingeniería de las tecnologías de Telecomunicación Gestión de calendarios para un servicio hospitalario Autor: Carmen Cohen Calvo Tutor: Dra. Isabel Román Martínez Profesora colaboradora Departamento de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2022
4 Gestión de calendarios para un servicio hospitalario Autora: Carmen Cohen Calvo Tutora: Dra. Isabel Román Martínez El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2022
El secretario del Tribunal
6 A mi familia A mis amigos
Agradecimientos A mi familia y amigos por el apoyo recibido. Resumen El objetivo principal de este proyecto es diseñar e implementar un servicio de calendarios que permita publicar los turnos de los profesionales de un servicio hospitalario. Además, se generarán los calendarios individuales de los doctores involucrados, que les serán enviados por correo electrónico. La solución ha sido diseñada en el entorno Spring y siguiendo el estándar iCalendar. Para ello se han utilizado las librerías ical4j y Javaxmail. Este proyecto se basa en el trabajo realizado por Miguel Ángel González-Alorda Cantero titulado “Servicio para la gestión de actividades asistenciales complementarias” [1] y supone una versión de este, con las funciones de gestión de calendarios incorporadas. Abstract The main objective of this project is to design and implement a calendar service that allows publishing the shifts of the professionals of a hospital service. In addition, the individual calendars of the doctors involved will be generated and sent to them by email. In addition, it has been simplifying the deployment method to facilitate continuous improvement of the project. The solution has been designed in the Spring environment and following the iCalendar standard. For this, the ical4j and Javaxmail libraries have been used. This project is based on the work conducted by Miguel Ángel González-Alorda Cantero entitled "Service for the management of complementary care activities" and is a version of this, with the functions of calendar management incorporated. [1]
8 Índice Agradecimientos 7 Resumen 7 Abstract 7 Índice 8 Índice de Tablas 9 Índice de ilustraciones 9 Fragmentos de código 10 Glosario 11 1 Introducción 12 1.1 Descripción del problema 12 1.1.1 Problema de asignación de horarios 12 1.1.2 Problema de gestión de horarios 12 1.2 Punto de partida 13 1.3 Alcance del proyecto. 15 2 Estado de la tecnología 15 2.1 Java 15 2.1.1 JavaMail 15 2.2 Spring 17 2.3 iCalendar 19 2.3.1 iCal4j 20 2.4 CalDAV 21 2.4.1 CalDAV4j 21 2.4.2 DAViCal 21 2.5 Docker 21 3 Requisitos 23 3.1 Actores 23 3.2 Casos de uso 23 3.2.1 Creación/modificación del calendario y notificación al doctor 24 3.3 Requisitos funcionales del sistema 28 3.3.1 Requisitos de información 28 3.3.2 Requisitos de conducta del sistema 29 3.3.3 Reglas de negocio 29 4 Solución diseñada 30 4.1 Servidor REST del nuevo sistema 30 4.1.1 Ampliación del sistema 30 4.2 funcionalidades añadidas al servicio REST 33 4.2.1 Casos de uso 35 4.2.2 Despliegue 44 5 Conclusiones y futuras mejoras 46 5.1 Futuras mejoras 46 5.1.1 Alojar calendarios individuales en el servicio de calendario 46 5.1.2 Añadir funcionalidades a la aplicación web 46
5.1.3 Crear perfiles de permisos. 46 5.2 Conclusiones 46 Referencias 48 ÍNDICE DE TABLAS Tabla 1: Doctor 23 Tabla 2: Gestor de turnos 23 Tabla 3: Información de asistente 28 Tabla 4: Información de evento 28 Tabla 5 : Información del calendario 28 Tabla 6: Disponibilidad del calendario 29 Tabla 7: Informe automático sobre el calendario 29 Tabla 8: Calendario personalizado 29 Tabla 9: Informe automático afectados directos 29 Tabla 10: Persistencia de turnos 29 Tabla 11: Recurso id de doctor 31 Tabla 12: Recurso ID de Telegram 31 Tabla 13: Recurso rol doctor 32 Tabla 14 : Recurso entidad rol 33 Tabla 15: Recurso evento 41 ÍNDICE DE ILUSTRACIONES Ilustración 1: Estructura del servicio 13 Ilustración 2: Listado de Doctores en cliente Web 13 Ilustración 3: Listado de planificaciones en el cliente Web 13 Ilustración 4: Ejemplo de planificación en el cliente Web 14 Ilustración 5: Fragmento planificación Excel 15 Ilustración 6: Patrón Modelo-Vista-Controlador 17 Ilustración 7: Capa de servicio 18 Ilustración 8: Estructura de calendario ical4j 20 Ilustración 9: Diferencia entre máquina virtual y Docker [20] 21 Ilustración 10: Diagrama de despliegue servicio actual 23 Ilustración 11: Diagrama de caso de uso actual 24
16 import java.util.*; import javax.mail.*; import javax.mail.internet.*; import javax.activation.*; public class SendEmail { public static void main(String [] args){ String to = "s[email protected]";//change accordingly String from = "[email protected]";//change accordingly String host = "localhost";//or IP address //Get the session object Properties properties = System.getProperties(); properties.setProperty("mail.smtp.host", host); Session session = Session.getDefaultInstance(properties); //compose the message try{ MimeMessage message = new MimeMessage(session); message.setFrom(new InternetAddress(from)); message.addRecipient(Message.RecipientType.TO,new InternetAddress(to)); message.setSubject("Ping"); message.setText("Hello, this is example of sending email "); // Send message Transport.send(message); System.out.println("message sent successfully...."); }catch (MessagingException mex) {mex.printStackTrace();} } } Código 1: Envío de correo electrónico En el ejemplo [6] se muestran las principales clases que se van a utilizar de esta librería: • public class MimeMessage: Esta clase representa un mensaje de correo electrónico de estilo MIME. Para enviar un correo electrónico con “partes”, por ejemplo, un archivo adjunto, se usa la clase MimeBodyPart, instanciando un objeto por cada parte. En el constructor de esta clase se le añade las propiedades a la cabecera del mensaje a través de la sesión que luego utilizará la clase transport para enviar el mensaje. • public final class Session: Esta clase representa una sesión de correo. Es en esta clase donde se agregan los parámetros de autentificación como usuario y contraseña. Incorpora las propiedades y los valores predeterminados utilizados por las API de correo. • public abstract class Transport: es una clase abstracta que modela el transporte de mensajes. El método send envía el mensaje a todas las direcciones de destinatario especificadas en el mensaje, utilizando el método de transporte adecuado para cada dirección.
2.2 SPRING Spring [7] es un framework libre para desarrollar aplicaciones en Java que favorece una estructura modular. Una de las características es la posibilidad de implementar los distintos estereotipos de Java a través de anotaciones en la definición de las clases. Gracias a esto la implementación del patrón modelo-vista-controlador es sencilla. Como se explica en [8] ‘El patrón MVC (Modelo, Vista, Controlador) [9] es un esquema de arquitectura por capas muy utilizado en el desarrollo de software basado en aplicaciones web. El modelo (M) controla todo lo relacionado con los datos, la vista (V) lo relacionado con las interfaces de usuario y el controlador (C) se encarga de la manipulación del M para mostrar información en la V’. Ejemplos de anotaciones utilizadas en Spring son @Controller o @Entity. Ilustración 6: Patrón Modelo-Vista-Controlador
18 Además de este patrón se implementa la capa de servicio a través de la notación @Service. [10] Como se define en [11] ‘Una capa de servicio define el límite de una aplicación y el conjunto de operaciones disponibles desde la perspectiva de la interfaz de capas de cliente y coordina la respuesta de la aplicación a cada operación.’ Es la capa que contiene la lógica del proceso. Ilustración 7: Capa de servicio Las dependencias entre objetos se especifican en Spring con la anotación @Autowired que especifica las inyecciones de dependencias. MVC
2.3 ICALENDAR iCalendar es un formato de datos estándar creado por el IETF para la transferencia de calendarios entre sistemas informáticos, independientemente de cualquier servicio de calendario o protocolo particular. Queda descrito en la RFC5545 [12]. Las extensiones más usadas en los archivos iCalendar suelen ser “. ical" o ".ics". BEGIN:VCALENDAR VERSION:2.0 PRODID:-//ZContent.net//Zap Calendar 1.0//EN CALSCALE:GREGORIAN METHOD:PUBLISH BEGIN:VEVENT SUMMARY:Abraham Lincoln UID:c7614cff-3549-4a00-9152-d25cc1fe077d SEQUENCE:0 STATUS:CONFIRMED TRANSP:TRANSPARENT RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=2;BYMONTHDAY=12 DTSTART:20080212 DTEND:20080213 DTSTAMP:20150421T141403 CATEGORIES:U.S. Presidents,Civil War People LOCATION:Hodgenville\, Kentucky GEO:37.5739497;-85.7399606 DESCRIPTION:Born February 12\, 1809\nSixteenth President (1861-1865)\n\n\n \nhttp://AmericanHistoryCalendar.com URL:http://americanhistorycalendar.com/peoplecalendar/1,328-abraham-lincoln END:VEVENT END:VCALENDAR Código 2: Formato de archivo iCalendar En el ejemplo [13] mostrado en el código se puede identificar lo siguiente: • Tanto los eventos como el calendario están delimitados por BEGIN y END; • Un calendario cuenta con propiedades como: o Versión de iCal (VERSION) o Un identificador (PRODID) o El tipo de calendario como gregoriano, hindú, islámico… (CALSCALE) o Método del calendario: add, cancel, publish, request… • Un evento cuenta con las siguientes propiedades entre otras: o Resumen/nombre del evento (SUMMARY) o Id único de identificación del evento, no puede repetirse en el calendario (UID) o Versión del evento (SEQUENCE) o Estado: confirmado, pendiente, cancelado (STATUS) o Fecha de inicio/final (DTSTART/DTEND) o Coordenadas GPS (GEO) Para trabajar con el estándar en Java se puede usar la librería iCal4j [14].
20 2.3.1 iCal4j iCal4j es una librería de Java que ayuda a manejar y crear calendarios, eventos y listas de tareas, siguiendo las pautas de la RFC5545 anteriormente comentadas. Un calendario está formado por componentes (como eventos o recordatorios), estos componentes contienen propiedades (como la fecha o los asistentes) y, por último, las propiedades tienen parámetros (como el nombre o email en el caso de un asistente a un evento). Ilustración 8: Estructura de calendario ical4j Calendar calendar = new Calendar(); calendar.getProperties().add(new ProdId("-//Ben Fortuna//iCal4j 1.0//EN")); calendar.getProperties().add(Version.VERSION_2_0); calendar.getProperties().add(CalScale.GREGORIAN); // Set date java.util.Calendar startDate = new GregorianCalendar(); startDate.add(java.util.Calendar.DAY_OF_MONTH, 25); startDate.set(java.util.Calendar.MONTH, java.util.Calendar.DECEMBER); // initialise as an all-day event.. VEvent christmas = new VEvent(new Date(startDate.getTime()), "Christmas Day") ; // Generate a UID for the event.. UidGenerator ug = new UidGenerator("1"); christmas.getProperties().add(ug.generateUid()); calendar.getComponents().add(christmas); Código 3: Creación de calendario con un evento En el ejemplo mostrado en el código 3 [15] vemos que para añadir propiedades al calendario que se acaba de instanciar es necesario obtener la lista de propiedades con el método getProperties () y posteriormente añadir la propiedad concatenando el método add(Property property).
En los eventos que duran todo el día no es necesario especificar la hora de finalización. Se instancia un objeto de tipo VEvent cuyos parámetros iniciales son la fecha y el nombre. Se añade un identificador único en el calendario generado con la clase Uidgenerator. Por último, se añade el evento al calendario 2.4 CALDAV CalDAV, especificado en la RFC 4791 [16], es un protocolo que permite manejar, acceder y compartir en internet los recursos de calendarios creados según el estándar iCalendar. Para trabajar con CalDAV en Java se puede usar la librería CalDAV4j [17]. 2.4.1 CalDAV4j CalDAV4j es una librería de Java que implementa el protocolo CalDAV y se basa en la librería iCal4j para el procesado de la información del calendario. A través de peticiones HTTP permite la comunicación con el servidor que ofrece el servicio de calendario. Para ello se apoya en la clase HttpClient de Java. La documentación se encuentra en [18] . 2.4.2 DAViCal DAViCal [19] es un servidor libre que implementa CalDAV y permite compartir y alojar calendarios. Utiliza una base de datos PostgreSQL para almacenar la información de los calendarios. 2.5 DOCKER Docker es un conjunto de herramientas que facilita la implantación de sistemas informáticos o aplicaciones a través de la virtualización basada en contenedores. Es un sistema operativo para contenedores que virtualizan el sistema operativo de un servidor. Estos contenedores se gestionan a través de comandos sencillos que permiten iniciar, parar o reinstaurar dichos contenedores. Los contenedores integran la aplicación y sus dependencias, pero comparten el kernel del sistema operativo con otros contenedores, que se ejecutan como procesos aislados en el sistema operativo anfitrión. En cambio, las máquinas virtuales integran la aplicación, las bibliotecas y/o los archivos binarios necesarios en un sistema operativo invitado completo. Esto lleva a que la virtualización basada en máquinas virtuales requiera más recursos que la inclusión en contenedores. Ilustración 9: Diferencia entre máquina virtual y Docker [20]
22 El proceso para generar un contenedor se apoya en un DockerFile. Un DockerFile es un archivo de texto que contiene los comandos necesarios para crear una imagen. Una imagen de Docker contiene la especificación de todo el sistema inicial en el que se va a basar un contenedor para su funcionamiento. Incluye: SO, sistema de ficheros, configuración, aplicaciones y sus dependencias, etc. Es una guía de instrucciones para construir un contenedor Docker. Puede contener aplicaciones ejecutables, así como todos los recursos necesarios (volúmenes, configuración de red, dependencias…). Una vez ejecutamos esa imagen se crea una instancia del contenedor. FROM openjdk:8-jdk-alpine VOLUME /tmp COPY target/*.jar app.jar ENTRYPOINT ["java","-jar","/app.jar"] Código 4: Ejemplo DockerFile En este mini Docker file [21] podemos ver los comandos principales: • From: imagen base de la que se parte. • Volume: crea un volumen que permite almacenar e intercambiar información con otros contendores. • Copy: copia el archivo jar al volumen creado. • Entrypoint: especifica el ejecutable que usará el contenedor al arrancar. Además, existe docker-compose para desplegar aplicaciones multicontenedor a partir de archivos YAML. En él se relacionan contenedores entre sí y se pueden especificar propiedades de volúmenes, puertos u otros parámetros, al igual que con el DockerFile.
3 REQUISITOS Este apartado incluye los requisitos del proyecto para el problema de la gestión de los calendarios. 3.1 ACTORES Estos son los actores participantes en los casos de uso de interés en este proyecto. A01 Doctor Descripción Este actor representa a los doctores miembros del servicio de medicina interna. Tabla 1: Doctor A02 Gestor de turnos Descripción Este actor representa al gestor de turnos. Tabla 2: Gestor de turnos 3.2 CASOS DE USO En el punto de partida contamos con un servidor REST, un servidor de aplicaciones web y el dispositivo de usuario. El servidor de aplicaciones web y el servidor REST se comunican entre sí a través de peticiones HTTP. Los componentes podrían desplegarse en una sola máquina o estar distribuidos. Durante el desarrollo se despliega todo en el mismo equipo para simplificar el trabajo. El dispositivo del usuario es el navegador web de un equipo. Ilustración 10: Diagrama de despliegue servicio actual
24 3.2.1 Creación/modificación del calendario y notificación al doctor 3.2.1.1 Sistema actual En la actualidad [1] el gestor de turnos es el encargado de generar la planificación a través del cliente web conectado al servicio REST. Posteriormente tendrá que gestionar los cambios de turno entre doctores si fuera necesario. Tras ambas acciones debe notificarse a los doctores a través de un email. Ilustración 11: Diagrama de caso de uso actual
Ilustración 12: Diagrama de actividad - Generación de horarios actualmente
32 Además, se añade un recurso rol para poder diferenciar los distintitos perfiles de los doctores. Estas peticiones deben incluir una cabecera de autentificación básica con las credenciales del servicio REST. Recurso Rol doctor URI /guardians/doctors/rol Nuevos recursos • GET o Parámetro: email o Respuestas: ▪ 200 OK: Devuelve los roles del doctor en formato String ▪ 404 NOT FOUND: Si no existe un doctor con el email dado • PUT: o Parámetros: el email personal del doctor va en la url y el rol va en el cuerpo. ("/rol/{email}") o Respuestas: ▪ 200 OK: devuelve un mensaje de texto si ha sido exitoso la inserción ▪ 404 NOT FOUND: si no existe un doctor con el email dado o si no existe el rol • DELETE o Parámetro: el email personal del doctor va en la url y el rol va en el cuerpo. ("/rol/{email}") o Respuesta: ▪ 200 OK: devuelve un mensaje de texto si ha sido exitoso la inserción ▪ 404 NOT FOUND: si no existe un doctor con el email dado, si no existe el rol o si el doctor no tiene ese rol asignado. Ejemplo "url": "dominio/guardians/octors/rol/{email}", "method": "PUT", "headers": { "Content-Type": "text/plain" }, "data": "Administrador" Tabla 13: Recurso rol doctor Recurso Entidad rol URI /guardians/rol Nuevos recursos • GET o Respuestas: ▪ 200 OK: Devuelve los roles en formato String • PUT:
o Parámetros: el rol a añadir. ("/rol/{rol}") o Respuestas: ▪ 200 OK: devuelve un texto si ha sido exitoso la inserción ▪ 404 NOT FOUND: si ya existe ese rol Propiedades • Rol Ejemplo "url": "dominio/guardians/rol/{rol}", "method": "PUT" "url": "dominio/guardians/rol", "method": "GET" Tabla 14 : Recurso entidad rol 4.2 FUNCIONALIDADES AÑADIDAS AL SERVICIO REST En este apartado se va a comentar al detalle la implementación del servicio de calendario incluyendo la notificación vía email a los doctores. La edición del calendario con el nuevo turno del mes se genera una vez que el gestor de turnos confirma el calendario o si un calendario ya generado se modifica. Como servicio de calendario se usa un servidor CalDAV en concreto en DaviCal. El servidor está alojado en un contenedor de Docker. Esto hace que al sistema original se añada un componente. Este punto es el objetivo principal de este trabajo. Además, como se ha comentado con anterioridad, se han añadido recursos y funcionalidades que darán soporte la modificación de turnos. El servicio REST se encarga de las operaciones de crear, leer, actualizar y borrar información del sistema. A las funcionalidades ya existentes se han añadido las que permitirán estas acciones para el servicio de calendario. El diagrama incluye el planificador, encargado de programar los turnos, y la aplicación web que otorga una interfaz al usuario para interactuar con el sistema. Ilustración 16: Diagrama de despliegue Estado de los elementos Naranja: Pendiente de integración Rosa: Modificados Azul: Nuevos
34 Ilustración 17: Diagrama de clases creadas
Las clases que se han creado para este este proyecto son las de color turquesa para diferenciarlas de las ya existentes. Estas son las siguientes: • generaFichero: es la clase que se encarga de crear el fichero con el calendario individual de cada doctor. Este es fichero que será enviado como archivo adjunto por correo electrónico a cada doctor. • La clase calendarioGeneral se encarga de manejar el calendario: Crea el calendario en formato iCalendar gracias a la librería ical4j a partir de la entidad Schedule y modifica el calendario generado si así se solicita. • La clase CalDAV se encarga de la comunicación con el servidor. Se encarga de publicar el calendario general una vez se ha creado y de recuperar el calendario de un doctor para un mes concreto cuando lo solicite. • CalendarioIndividual tiene una funcionalidad muy similar a la de calendarioGeneral, pero en este caso lo que se genera es un calendario individual con ical4j por cada doctor para que posteriormente puedan ser enviados a través de correo electrónico como archivo adjunto gracias a generaFichero. • EmailService se encarga de enviar por correo electrónico, gracias a la API JavaMail, el archivo ics generado con el calendario personalizado de cada doctor. 4.2.1 Casos de uso A continuación, se desarrollan los tres casos de uso principales del sistema. Con objeto de asimilar la explicación a la terminología de la API iCal4j en algunos casos se hablará de los turnos como eventos y de los doctores como asistentes. 4.2.1.1 Creación del calendario y notificación al doctor La clase SchedulerController es la encargada de gestionar la petición de creación de una nueva planificación. Será esta clase la que llamará a nuestro servicio una vez el gestor confirma que la planificación es correcta y comienza el proceso para persistirla. Este proceso incluye crear el calendario correspondiente a dicha planificación. Para ello se solicita el calendario del servicio de medicina vía http a la URL definida en las propiedades de la aplicación (en un archivo llamado application.properties) y la respuesta se convierte a formato iCal4j. Si no existe calendario en la URL otorgada se crea uno directamente en formato ical4j para publicarse posteriormente. En la clase calendarioGeneral se añade al calendario un evento por cada turno con los doctores que participan en ellos, además de enviar esos mismos eventos a la clase calendariosIndividuales donde, como su nombre indica, se crean los calendarios individuales de cada doctor. Cada evento tiene un UID único con el siguiente formato yyymmd(d)xx donde xx es una clave según el tipo de turno. Una vez todo ha sido creado la clase CalDAV publica el calendario general en el servidor y los calendarios individuales se pasan a un fichero que es enviado por correo electrónico a cada doctor gracias a la API JAVAX Mail.
36 Ilustración 18: Caso de uso - Crear calendario Este caso de uso se desarrolla según el siguiente procedimiento: Ilustración 19: Diagrama de actividad - Crear calendario
Ilustración 20: Diagrama de secuencia - Crear calendario
38 4.2.1.2 Recuperar calendario individual Cuando un doctor desea recuperar su calendario para un mes concreto. Se realiza una petición al servicio REST en la que se le pasa como parámetros el mes y año además del correo electrónico del doctor. El sistema solicita el calendario del servicio de medicina al servidor y se convierte a formato iCal4j. Una vez obtenido se utiliza un filtro para buscar todos los eventos en el mes del año seleccionado. A esta selección se le pasa un segundo filtro buscado eventos cuyos asistentes (doctores) contengan el email de la petición. Con los eventos que quedan tras la selección se genera un fichero con el calendario y se envía al correo electrónico proporcionado. Si no se encontrara ningún evento con las características deseadas se mostraría un mensaje de error. Ilustración 21: Caso de uso - Recuperar calendario individual
Ilustración 22: Diagrama de activad - Recuperar calendario individual
40 Ilustración 23: Diagrama de secuencia - Recuperar calendario individual
4.2.1.3 Modificación del calendario EventController es el controlador REST encargado de manejar las peticiones relacionadas con la modificación del horario que ya se había creado en el caso de uso Crear calendario. En el cuerpo de la petición HTTP deben incluirse los eventos a modificar, contenidos en un calendario en formato ical. Tabla 15: Recurso evento En la clase calendarioGeneral se solicita el calendario general del servicio de medicina al servidor y se convierte a formato iCal4j. Se comprueba que el UID de cada evento modificado proporcionado en la petición es igual a un UID de un evento ya existente en el calendario general. Una vez esto ha sido verificado, se comprueba que los doctores a los que involucra ese cambio existen en la base de datos. Una vez verificado que la información es correcta se modifica al calendario general y se generan los calendarios individuales de los doctores afectados por ese cambio. Cuando todo ha sido creado se publica el calendario general ya modificado en el servidor y se envían los calendarios individuales a través de correo electrónico. Como el UID de los eventos persiste, el doctor puede actualizar su calendario personal con el archivo enviado. Se le añadirán o eliminarán los eventos según proceda. Recurso Evento URI /guardians/event Nuevos recursos • POST: o URI: /guardians/event /update o Parámetros: el evento a modificar va en el cuerpo en formato String según el estándar ical o Respuestas: ▪ 200 OK: devuelve un mensaje de texto si ha sido exitoso la actualización ▪ 404 NOT FOUND: si no existe un evento con el id y fecha dada o, si los doctores asistentes al nuevo evento no existen en la base de datos Ejemplo "url": "http://localhost:8080/guardians/api/event/update", "method": "POST", "headers": { "Content-Type": "text/plain" }, "data": "BEGIN:VCALENDAR\nPRODID:- //Mozilla.org/NONSGML Mozilla Calendar V1.1//EN\nVERSION:2.0\nB EGIN:VEVENT\nDTSTAMP:20220207T194654Z\nUID:132022jc\nSUMMARY:Jo rnadas Complementarias\nATTENDEE:mailto:[email protected]\nA TTENDEE:mailto:[email protected]\nDTSTART;VALUE=DATE:20220301\nE ND:VEVENT\nEND:VCALENDAR\n"
48 REFERENCIAS [1] M. González-Alorda Cantero, Shift scheduling and management service, Sevilla: Universidad de Sevilla, 2020. [2] P. P. Garrido Abenza, «Comenzando a programar con JAVA,» Universidad Miguel Hernández, 2015. [3] Oracle, «Java™ Platform, Standard Edition 8,» [En línea]. Available: https://docs.oracle.com/javase/8/docs/api/. [Último acceso: 09 08 2021]. [4] Oracle, «JavaMail Reference Implementation,» [En línea]. Available: https://javaee.github.io/javamail/. [Último acceso: 09 08 2021]. [5] «JavaMail Documentation,» [En línea]. Available: https://www.javadoc.io/doc/javax.mail/javax.mailapi/latest/javax/mail/package-summary.html. [Último acceso: 09 08 2021]. [6] J. T. POINT, «Sending Email in Java,» [En línea]. Available: https://www.javatpoint.com/example-of- sending-email-using-java-mail-api. [Último acceso: 11 08 2021]. [7] VMware, «Spring Framework,» [En línea]. Available: https://spring.io/projects/spring-framework. [Último acceso: 11 08 2021]. [8] C. Ávila Garzón, «Modelo Vista Controlador,» Facultad de Matemáticas e Ingenierías, 11 12 2019. [En línea]. Available: https://repositorio.konradlorenz.edu.co/handle/001/1528. [Último acceso: 09 2021]. [9] [En línea]. Available: https://commons.wikimedia.org/wiki/File:MVC_Diagram.jpg. [Último acceso: 09 2021]. [10] J. P. Smith, «Architecture of Business Layer working with Entity Framework,» [En línea]. Available: https://www.thereformedprogrammer.net/architecture-of-business-layer-working-with-entity-framework/. [Último acceso: 09 2021]. [11] M. Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley , 2012. [12] I. E. T. Force, «Internet Calendaring and Scheduling Core Object Specification,» [En línea]. Available: https://datatracker.ietf.org/doc/html/rfc5545. [Último acceso: 08 2021]. [13] «iCalendar File Format,» [En línea]. Available: https://icalendar.org/. [Último acceso: 08 2021]. [14] B. Fortuna, «iCal4j User Guide,» [En línea]. Available: https://ical4j.github.io/ical4j-user-guide/. [Último acceso: 08 2021]. [15] B. Fortuna, «iCal4j Examples,» [En línea]. Available: https://ical4j.github.io/ical4j-user-guide/examples/. [Último acceso: 08 2021]. [16] «Calendaring Extensions to WebDAV (CalDAV),» [En línea]. Available:
https://datatracker.ietf.org/doc/html/rfc4791. [Último acceso: 08 2021]. [17] A. Mishra, «CalDAV4j Wiki,» [En línea]. Available: https://github.com/caldav4j/caldav4j/wiki. [Último acceso: 08 2021]. [18] «CalDAV4j Documentación,» [En línea]. Available: https://javadoc.io/doc/com.github.caldav4j/caldav4j/latest/index.html. [Último acceso: 08 2021]. [19] A. McMillan, «About DAViCal,» [En línea]. Available: https://www.davical.org/index.php. [Último acceso: 08 2021]. [20] Microsoft , «¿Qué es Docker?,» Microsoft , 2022. [En línea]. Available: https://docs.microsoft.com/eses/dotnet/architecture/microservices/container-docker-introduction/docker-defined. [21] Spring. [En línea]. Available: https://spring.io/guides/topicals/spring-boot-docker/. [Último acceso: 2022]. [22] IETF. [En línea]. Available: https://datatracker.ietf.org/doc/html/rfc822. [Último acceso: 09 2021]. [23] J. Klensin, «Simple Mail Transfer Protocol,» 11 07 2008. [En línea]. Available: https://datatracker.ietf.org/doc/html/rfc5321. [Último acceso: 10 2021]. [24] I. C. Education, «Dcoker,» IBM Inc., [En línea]. Available: https://www.ibm.com/cloud/learn/docker. [Último acceso: 06 2022]. [25] J.-P. Gouigoux, Docker : primeros pasos y puesta en práctica de una arquitectura basada en microservicios, Cornellá de Llobregat, Barcelona: Ediciones Eni, 2018. [26] Amazon, «¿Qué es Docker?,» [En línea]. Available: https://aws.amazon.com/es/docker/. [Último acceso: 06 2022].
50