Raúl Rodil Sanz
Sistema de notificación de avisos para eventos programables
Angel Luis Rubio García
Facultad de Ciencias, Estudios Agroalimentarios e Informática
Proyecto Fin de Carrera
Matemáticas y Computación
2012-2013
Título
Autor/es
Director/es
Facultad
Titulación
Departamento
PROYECTO FIN DE CARRERA
Curso Académico
© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2013
publicaciones.unirioja.esE-mail: [email protected]
Sistema de notificación de avisos para eventos programables, proyecto fin decarrera
de Raúl Rodil Sanz, dirigido por Angel Luis Rubio García (publicado por la Universidad deLa Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.
UNIVERSIDAD DE LA RIOJA
Facultad de Ciencias, Estudios Agroalimentarios e Informática
PROYECTO FIN DE CARRERA
Ingeniería Técnica en Informática de Gestión
Sistema de notificación de avisos para
eventos programables
Alumno: Raúl Rodil Sanz
Director: Ángel Luis Rubio García
Logroño, fecha (Mayo, 2013)
Sistema de notificación de avisos para eventos programables
Índice
Universidad de La Rioja Página 1
Índice 1. Documento de Objetivos del Proyecto .................................................... 3
1.1) Introducción................................................................................................. 4
1.2) Antecedentes ............................................................................................... 5
1.3) Recursos para la realización del proyecto ................................................ 5
1.4) Descripción y objetivos del proyecto ........................................................ 6
1.5) Alcance ........................................................................................................ 7
1.6) Arquitectura física ....................................................................................... 8
1.7) Entregables .................................................................................................. 9
1.8) Estructura de descomposición de tareas ................................................ 10
1.9) Plan de trabajo inicial ................................................................................ 11
1.10) Estimaciones globales y tiempos dedicados .......................................... 14
1.11) Diagrama de Gantt..................................................................................... 17
1.12) Justificaciones tecnológicas .................................................................... 19
1.13) Riesgos ...................................................................................................... 19
2. Análisis .................................................................................................... 23
2.1) Análisis previsto ........................................................................................ 24
2.2) Análisis tecnológico .................................................................................. 25
2.3) Análisis de Requisitos .............................................................................. 25
2.4) Modelo de casos de uso ........................................................................... 27
3. Diseño ...................................................................................................... 30
3.1) Introducción............................................................................................... 31
3.2) Diseño de modelo de datos ...................................................................... 32
3.3) Diseño de la aplicación ............................................................................. 39
4. Construcción ........................................................................................... 45
4.1) Introducción............................................................................................... 46
4.2) Construcción de la Base de Datos ........................................................... 46
4.3) Implementación de la lógica ..................................................................... 52
4.4) Implementación de la interfaz .................................................................. 59
4.5) Documentación y manuales ..................................................................... 86
Sistema de notificación de avisos para eventos programables
Índice
Universidad de La Rioja Página 2
5. Pruebas .................................................................................................... 87
5.1) Pruebas de inserción de datos ................................................................. 88
5.2) Pruebas de borrado de datos ................................................................... 89
5.3) Pruebas de consulta de datos .................................................................. 90
5.4) Pruebas de funcionamiento de la aplicación .......................................... 91
6. Gestión del Proyecto .............................................................................. 92
6.1) Duración real de las tareas ....................................................................... 93
6.2) Comparaciones de tiempos ...................................................................... 94
6.3) Diagrama de Gantt final ............................................................................ 95
6.4) Objetivos iniciales y alcanzados .............................................................. 97
7. Conclusiones ........................................................................................... 98
7.1) Conclusiones del proyecto ....................................................................... 99
Anexo I. Manual de despliegue e Instalación ............................................. 100
A I.1) Consideraciones previas ........................................................................ 101
A I.2) Instalación de las pantallas .................................................................... 101
A I.3) Creación de tablas................................................................................... 102
A I.4) Creación de vistas, funciones, procedimientos y jobs ......................... 107
Anexo II. Manual de administrador de la aplicación ................................. 114
A II.1) Introducción ......................................................................................... 115
A II.2) Funcionamiento general del programa .............................................. 115
A II.3) Pantalla de configuración de empleados ........................................... 117
A II.4) Pantalla de configuración de avisos .................................................. 121
A II.5) Pantalla de visualización de datos ..................................................... 124
Anexo III. Manual de usuario de la aplicación ........................................... 126
AIII.1) Introducción ......................................................................................... 127
AIII.2) Funcionamiento general del programa .............................................. 127
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 3
1. Documento de
Objetivos del Proyecto
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 4
1.1) Introducción
En este primer documento se exponen las estimaciones sobre distintos
aspectos para la realización del proyecto.
Este Proyecto Fin de Carrera tiene el objetivo de realizar una aplicación para el
envío de avisos o alertas sobre algún tipo de eventos. La aplicación permitirá
tanto la creación como la modificación de estos eventos, pudiendo cambiar la
forma o el momento de envío del evento en cuestión.
Este proyecto se desarrollará en una aplicación real y en funcionamiento
dedicada a la gestión de personal de una empresa. Con todos los datos de los
empleados ya recogidos, tanto datos personales como duración y definición de
contratos, bajas, vacaciones y otros datos. Los datos aparte de estar ya
introducidos se irán actualizando, ya que la aplicación se va nutriendo cada día
de nuevos datos. Dicha aplicación está diseñada con Forms y Reports de Oracle,
y sobre un sistema gestor de base de datos Oracle 10.
Nuestra aplicación se englobará dentro de esta aplicación ya creada. Se
realizará un desarrollo de pantallas en Oracle Forms, creando nuevas pantallas
con esta herramienta, toda la estructura de tablas con sus relaciones
correspondientes, un poco de desarrollo java para los avisos por correo
electrónico, y para los avisos vía web se desarrollará en php. Este desarrollo se
basará en el desarrollo web ya existente en la empresa. Que se englobará en
una web de la empresa, dentro de un apartado en el que sólo pueda ver cada
usuario sus posibles alertas.
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 5
1.2) Antecedentes
Para el desarrollo del proyecto me basaré en todos los conocimientos
adquiridos tanto en mi carrera, como en la experiencia en el centro de trabajo.
Siendo el de mi puesto de trabajo actual más preponderante ya que el
desarrollo lo realizaré en la empresa y se intentará poner en producción con
algunos cambios y supervisión de otro personal para la correcta adecuación a la
empresa.
El desarrollo de las pantallas, la configuración de tablas, algunos
procedimientos, jobs y triggers es en lo que realmente estoy más familiarizado,
pero resultará más costosa la configuración de dichos apartados. Se
desarrollará sobre una base de datos ya instalada con un SGBD de Oracle 10g.
La parte del desarrollo en java para el envío de correos y la configuración php
no estoy tan familiarizado por lo que el desarrollo me resultará más difícil
aunque tengo conocimientos adquiridos en la carrera.
Hay que señalar que las necesidades que se intentan cubrir con este proyecto
sobre avisos para determinados eventos no ha sido abordado en la empresa,
por lo que en este aspecto no tenernos ninguna aplicación en la que basarnos.
Aunque si hay algunos envíos vía email automáticos pero no para estos eventos
ni con estas características.
1.3) Recursos para la realización del proyecto
Los recursos necesarios para la realización del proyecto son un sistema gestor
de base de datos en el que crear las diferentes tablas, jobs, triggers, funciones,
vistas y procedimientos, y un espacio web en el que colgar una desarrollo web
realizado en php.
Todo lo necesario para la realización del proyecto será suministrado por mi
actual empresa. Ya que es en ella donde irá alojada la aplicación.
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 6
1.4) Descripción y objetivos del proyecto
La aplicación que se quiere realizar tiene como objetivo poder diseñar tipos de
avisos. Estos avisos podrán ser configurados para definir en qué situaciones han
de ser enviados, a quiénes y de qué modo van a ser informados.
Para ello tendremos que diseñar unas pantallas dedicadas a la configuración de
los diferentes eventos. Dichos eventos estarán relacionados con otras tablas o
vistas existentes ya en la aplicación para poder discernir cuándo se cumple un
determinado evento. Dichos eventos pueden ser desde la finalización
inminente de un contrato, el final de una baja maternal o la extinción de una
contraseña. El aviso de estos eventos no tiene por qué llegar al empleado en
cuestión, sino que en algunos casos es necesario que lleguen al responsable
inmediato de dicho empleado.
Por ello aunque los eventos se crearán y configurarán en nuestra aplicación, es
necesario la integración e interactuación con otras tablas del entorno para
discernir cuando se cumple un determinado evento.
Cuando se cree esta logística para los eventos, tendremos que realizar la parte
del aviso. Ya que una vez que sabemos que hay que enviar un aviso tendremos
varias posibilidades para informar sobre dicho aviso, estás vías son:
En la propia aplicación
Vía e-mail
En la web de la empresa.
Estos son los tipos de avisos a priori, aunque podría ser ampliable a otros tipos
dependiendo de las necesidades en cada momento.
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 7
1.5) Alcance
El alcance del proyecto consistirá en la creación de una aplicación funcional
para poder crear determinados eventos. Una vez creados los eventos, cuando
se cumplan deberá mandar un aviso del modo requerido y a las personas
asignadas.
Esta aplicación será utilizada por diferente personal.
A) Rol Administrador:
Este rol es el que llevará personal más familiarizado con la creación y
configuración de los eventos. Recibirán peticiones de Supervisores y
directores para que creen y gestiones los eventos para realizar los avisos.
B) Rol Supervisor
Son todo personal que se encuentre puesto como supervisor en las tablas
ya definidas en la aplicación. Un mismo supervisor, puede serlo de varios
grupos, y a su vez un mismo grupo puede tener varios supervisores.
Este personal es el que recibirá las alertas que se definan para que lleguen
al supervisor directo de un empleado. También este personal, dependiendo
de sus necesidades, es el que puede pedir al que se encuentre en el rol
administrador que cree nuevos eventos o que modifique los que están ya
creados.
C) Rol Empleado
En este rol se encuentran todos los empleados de la empresa, advertir que
todos los empleados tienen metido en sus atributos personales a qué
grupo pertenecen, para saber cuáles son sus supervisores inmediatos.
Este personal puede recibir las alertas que sean definidas para que les
llegue un aviso.
Otras consideraciones son:
Algunos supervisores pueden ser a su vez empleados.
La validación de los usuarios es única, siendo la aplicación la que
discierne si el usuario es un empleado, un supervisor o un administrador
Dependiendo del tipo de rol desempeñado se tendrá acceso a
determinadas opciones de la aplicación, o no.
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 8
1.6) Arquitectura física
Al tener que desarrollar el proyecto para una empresa nos tenemos que ceñir a
como están distribuidos los diferentes componentes.
En esta arquitectura nos encontramos los siguientes elementos:
A) Servidor de aplicaciones
En este servidor es donde se encuentra alojado nuestro SGBD, en este caso
un Oracle 10g. También en este servidor están almacenadas todas las
tablas y relaciones de la aplicación. Así como los procesos almacenados y
los jobs nocturnos que tengamos que programar. Además tendremos
instalada la consola java necesaria para los procesos de lanzamiento de
correos.
Servidor de Aplicaciones
SGBD Procesos Jobs
Consola de Java
Servidor de Correo Servidor de ficheros
Ficheros
Usuario
Servidor WEB
Usuario
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 9
B) Servidor de ficheros
En este servidor es donde los usuarios se conectan para recuperar los
archivos compilados para la aplicación. Aquí es donde dejaremos las
pantallas creadas en Oracle Forms.
C) Servidor de correo
El servidor de aplicaciones al ejecutar cierto proceso se conectará con este
servidor de correo para el envío de los e-mails para los avisos.
D) Servidor web
En este servidor se almacena el servicio y los archivos para el
mantenimiento de la página web de la empresa. El usuario se tendrá que
conectar a él para consultar cualquier página web de la empresa, y nuestra
parte de la aplicación web estará alojada en él.
1.7) Entregables
En este apartado aclarar que al realizar el proyecto para una empresa, no
podemos entregar ni código fuente ni compilado de algunas partes de la
aplicación.
Documento de Objetivos del Proyecto (DOP)
Memoria del proyecto
Scripts sobre alguna creación de las tablas
Videos sobre el funcionamiento de la aplicación
Manual de usuario para la instalación y utilización de la aplicación para
los diferentes roles.
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 10
1.8) Estructura de descomposición de tareas
Proyecto
Dirección y Gestión
Reuniones
Creación del DOP
Identificación de Requesitos
Seguimiento
Creación de la Memoria
Preparación de la defensa
Análisis
Análisis Previo
Análisis Tecnológico
Análisis Estructural
Diseño
Diseño de la BBDD
Diseño de las interfaces
Construcción
Construcción de la BBDD
Implementación de la lógica
Implementación de la Interfaz
Documentación y manuales
Pruebas
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 11
1.9) Plan de trabajo inicial
En este apartado se realizará un breve desglose y descripción de las diferentes
tareas que se desarrollarán a lo largo del proyecto, además de una estimación
de la duración de cada una de ellas.
A) Dirección y Gestión
Son las reuniones con el director de proyecto, así como la creación del primer
entregable y tareas de identificación de requisitos y seguimiento del proyecto
A.1) Reuniones:
Son las reuniones con del director de proyecto, consistirá también en la
realización de las actas. Se estima una reunión cada semana.
Duración: 10 horas
A.2) Creación del DOP
Consistirá en el tiempo en el que se realiza el Documento Objetivo del
proyecto, y cada uno de sus apartados.
Duración: 16 horas
A.3) Identificación de Requisitos
Son las tareas para la extracción de requisitos por parte del alumno. Esta tarea
se desarrollará durante las primeras reuniones con el personal al que va a estar
dirigido el proyecto. Esta identificación de requisitos según se vaya realizando
el proyecto puede verse modificado dependiendo del alcance real y su
funcionamiento.
Duración: 10 horas
A.4) Seguimiento
Tareas correspondientes al seguimiento de las diferentes partes del proyecto
en cuanto a su duración y posible desfase con las estimaciones realizadas.
Duración: 17 horas
A.5) Creación de la Memoria
Son las tareas referentes a la escritura de la memoria del proyecto.
Duración: 45 horas
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 12
A.6) Preparación de la defensa
En este apartado realizaremos todo lo referente para una vez presentado el
proyecto, defenderlo ante el tribunal de evaluación.
Duración: 20 horas
B) Análisis
En este apartado se realizan las tareas para el análisis de las diferentes
soluciones del proyecto. Primero una visión general y luego más concretamente
con el análisis tecnológico y estructural.
B.1) Análisis previo
Aquí analizaremos en un nivel general los aspectos del proyecto, tanto el
alcance como el funcionamiento que queremos alcanzar en la aplicación.
Duración: 7 horas
B.2) Análisis tecnológico
El fin de esta tarea es analizar las diferentes alternativas existentes para la
realización de nuestro proyecto. La parte principal se realizará en Forms y
Reports por lo que no tendremos que realizar un análisis de la tecnología a
aplicar. La parte web y envío de correos es donde tendremos que analizar la
tecnología a aplicar aunque siempre con la aprobación de la empresa.
Duración: 7 horas
B.3) Análisis estructural
Aquí analizaremos la estructura que tendrá el proyecto una vez terminado.
Duración: 12 horas
C) Diseño
En este apartado es donde definiremos el diseño que tendrá nuestro proyecto
en aspectos tan importantes como la base de datos y la interfaz.
C.1) Diseño de la BBDD
Nos ocuparemos del diseño de nuestra base de datos, tanto las tablas, la
definición de restricciones, jobs, funciones, vistas y procedimientos.
Duración: 5 horas
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 13
C.2) Diseño de las interfaces
Aquí decidiremos como quedarán cada una de nuestras pantallas en la
aplicación y también en la visualización vía web.
Duración: 10 horas
D) Construcción
En este apartado se pondrá en práctica todo lo analizado y diseñado en etapas
anteriores. Es donde realizaremos propiamente dicha nuestra aplicación.
D.1) Construcción de la BBDD
En esta etapa crearemos nuestras tablas y vistas y diferentes funciones
necesarias para la aplicación. También los procesos y jobs.
Duración: 15 horas
D.2) Implementación de la lógica
Aquí construiremos la lógica para llevar a cabo el lanzamiento de las alertas
para los eventos. También la previa configuración de los eventos y su creación.
Duración: 80 horas
D.3) Implementación de la interfaz
En esta tarea construiremos las diferentes pantallas que tendrá nuestro
proyecto. Tanto las pantallas en Oracle Forms como las páginas para la intranet.
Duración: 15 horas
D.4) Documentación y manuales
En este apartado realizaremos todos los documentos del proyecto, un
documento sobre cómo funciona la aplicación otro de como instalarla y
configurarla. También sobre el funcionamiento e instalación.
Duración: 20 horas
E) Pruebas
Aquí realizaremos las pruebas para verificar el correcto funcionamiento de la
aplicación. Es decir, que funciona bajo los requisitos previamente determinados
Duración: 5 horas
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 14
1.10) Estimaciones globales y tiempos dedicados
En la siguiente tabla se puede ver de manera más rápida la duración estimada
del proyecto en total.
Tarea Duración en horas
A) Dirección y Gestión 118
A1) Reuniones 10
A2) Creación del DOP 16
A3) Identificación de Requisitos 10
A4) Seguimiento 17
A5) Creación de la Memoria 45
A6) Preparación de la defensa 20
B) Análisis 26
B1) Análisis Previo 7
B2) Análisis tecnológico 7
B3) Análisis estructural 12
C) Diseño 15
C1) Diseño de la BBDD 5
C2) Diseño de las interfaces 10
D) Construcción 130
D1) Construcción de la BBDD 15
D2) Implementación de la lógica 80
D3) Implementación de la interfaz
15
D4) Documentación y manuales 20
E) Pruebas 5
TOTAL 294
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 15
En el siguiente gráfico podemos observar las diferencias de tiempos entre las
tareas a realizar a lo largo del proyecto.
Como se puede observar, en la previsión de tiempos, la tarea que más tiempo
va a ocupar es la construcción de la aplicación, con un 44% del total. Seguida de
esta tarea se encuentra la Dirección y Gestión, y la Creación de la memoria con
un 18% y 15% respectivamente.
18%
9%
5%
44%
2%
15%
7%
Duración de las tareas
A) Dirección y Gestión B) Análisis
C) Diseño D) Construcción
E) Pruebas F) Creación de la memoria
G) Preparación de la defensa
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 16
Para mostrar los tiempos dedicados al proyecto durante una semana normal
hay que tener en cuenta que trabajo de ocho de la mañana a tres de la tarde,
por eso las en la tabla se muestran las horas a partir de las tres y media de la
tarde.
Lunes Martes Miércoles Jueves Viernes
15:30-16:00
Libre Libre Libre Libre Libre
16:00-16:30
Libre Libre Libre Libre Libre
16:30-17:00
Libre Proyecto Proyecto Proyecto Libre
17:00-17:30
Libre Proyecto Proyecto Proyecto Proyecto
17:30-18:00
Proyecto Proyecto Proyecto Proyecto Proyecto
18:00-18:30
Proyecto Proyecto Proyecto Proyecto Proyecto
18:30-19:00
Proyecto Proyecto Proyecto Proyecto Proyecto
19:00-19:30
Proyecto Proyecto Proyecto Proyecto Proyecto
19:30-20:00
Proyecto Libre Libre Libre Proyecto
20:00-20:30
Proyecto Libre Libre Libre Libre
20:30-21:00
Libre Libre Libre Libre Libre
Según el esquema podemos estimar unas quince horas para el proyecto, más
seis horas que podremos realizar en fin de semana para recuperar tiempos en
los que no hayamos podido realizar las tareas estimadas.
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 17
1.11) Diagrama de Gantt
En el siguiente diagrama de Gantt se puede ver toda la evolución previsible del
proyecto, desde su inicio hasta su finalización.
Nos hemos puesto como inicio el 13 de diciembre de 2010, y siguiendo todas
las estimaciones sobre el proyecto, la finalización estimada es para el 28 de
abril de 2011.
En el diagrama se pueden ver en detalle el inicio y final estimado de cada tarea
del proyecto, así como la duración en días. Advertir que cada día equivale a tres
horas de trabajo y en el calendario están excluidos los fines de semana.
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 18
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 19
1.12) Justificaciones tecnológicas
Nuestra aplicación será realizada con las herramientas de la empresa. Ya que
todo el proyecto va a estar integrado dentro de otras aplicaciones más grandes.
Por todo eso no podemos utilizar otras tecnologías sino que seguiremos con las
que tienen en la empresa.
1.13) Riesgos
Los riesgos que puede tener la ejecución del proyecto pueden ser de diferentes
características y cada uno de ellos puede ocasionar un riesgo distinto con una
solución diferente. Entre ellos cabe destacar:
A) Modificación de los requisitos
Puede ocurrir que en el transcurso del proyecto cualquiera de los
requisitos para el proyecto pudiese cambiar. Cuando estemos realizando el
proyecto, nos podemos dar cuenta que alguna de las características de
nuestra aplicación necesita un conocimiento que no tenemos o alguna
parte necesita un mayor tiempo de desarrollo del que no disponemos.
Probabilidad: Alta.
Impacto: Muy alto.
Momento previsto: Durante todo el desarrollo del proyecto, y con mayor
probabilidad durante el diseño y la construcción.
Plan de contingencia: Revisar cada parte anterior al momento de la
modificación de los requisitos y revisar de nuevo el diseño de la aplicación.
B) Error en el diseño de la base de datos o las interfaces
Este riesgo puede darse al entender mal los requisitos del proyecto, o
simplemente al llegar a la fase de construcción o alguna de las pruebas, nos
damos cuenta que para la mejor funcionalidad, o simplemente para que
funcione correctamente, deberíamos haber diseñado de forma distinta
nuestra base de datos o alguna de las interfaces.
Probabilidad: Alta.
Impacto: Alto.
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 20
Momento previsto: Puede darse durante todo el desarrollo del proyecto, y
con mayor probabilidad durante la construcción.
Plan de contingencia: Volver a diseñar la base de datos o la interfaz
necesaria y volver a la etapa de construcción para realizarla con el diseño
pertinente.
C) Estimaciones de tiempos mal realizadas
Dado que las estimaciones de tiempo se realizan sin un conocimiento sobre
el alcance real de algunas partes del proyecto, puede ocurrir que en
algunos momentos se exceda en tiempo.
Probabilidad: Muy Alta.
Impacto: Alto.
Momento previsto: Este riesgo se da durante toda la realización del
proyecto.
Plan de contingencia: En el esquema sobre los tiempos dedicados,
disponemos tres horas y media durante el fin de semana para la
recuperación de esas horas de más que deberemos trabajar en el proyecto.
Si con esas no es suficiente, el esquema de tiempos será modificado.
D) Ausencia de recursos necesarios
Puede pasar que en el trascurso del proyecto, nos falte en alguna etapa
alguna tecnología o aplicación necesaria para la correcta realización de
nuestro proyecto. Esto conllevará la pérdida de tiempo y en consecuencia
el alargar con los plazos marcados para la realización del proyecto. Dadas
las características del proyecto dependemos de una empresa, que nos
conceda los recursos necesarios.
Probabilidad: Baja.
Impacto: Medio-Alto.
Momento previsto: Durante el trascurso de todo el proyecto.
Plan de contingencia: Necesitaremos saber lo que realmente vamos a
necesitar en etapas siguientes a la que nos encontremos para anticiparnos
a las necesidades que nos podemos encontrar y de esta forma minimizar el
posible error de no encontrarnos con los recursos necesarios para
continuar.
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 21
E) Pérdida de algún tipo de información
Durante el avance del proyecto, el avance de la memoria será guardada en
dos y hasta tres formatos distintos: disco duro del ordenador, memoria
USB, y en almacenamiento en internet. También puede ser debido al
conflicto entre versiones de trabajo que al avanzar en una versión
diferente se acaba perdiendo algo de información.
La creación de tablas, jobs y procedimientos, serán guardados en distintos
sitios en el centro de trabajo, así como las pantallas realizadas y el
desarrollo de las pantallas para la web.
Probabilidad: Baja
Impacto: Dependiendo de la pérdida puede ser Alta o prácticamente nula.
Momento previsto: Durante todo el trascurso del proyecto.
Plan de contingencia: Deberemos tomarnos muy en serio el sistema de
guardado de toda la información y actualizar al mismo tiempo todas los
sistema de guardado, para de este modo no sufrir ni pérdidas de
información ni incongruencias en versiones.
F) Ausencia del proyectante
Los motivos de la ausencia pueden ser ajenos, una enfermedad, cursos de
trabajo, reuniones inesperadas, o por motivos no ajenos. Como carga de
trabajo durante una época superior a la normal. Tanto unos motivos u
otros podrán ser subsanados por medio de una previsión para poder
modificar de fechas de las reuniones y las que puedan ocasionar en el
transcurso del proyecto.
Probabilidad: Alta.
Impacto: Alto.
Momento previsto: Durante todo el proyecto.
Plan de contingencia: Dependiendo de los motivos de la ausencia, se
llevarán a cabo pequeños o grandes aplazamientos del seguimiento del
proyecto.
Sistema de notificación de avisos para eventos programables
Documento de Objetivos del Proyecto
Universidad de La Rioja Página 22
G) Ausencia del Director de proyecto
Pueden ser tanto por motivos ajenos, una enfermedad, reuniones
inesperadas, o por motivos no ajenos. Como carga en clases o docencia,
posibles congresos etc. Tanto unos motivos u otros podrán ser subsanados
por medio de una previsión para poder modificar de fechas las reuniones y
las dudas ocasionadas. Teniendo en cuenta que el correo electrónico
puede ser de gran ayuda para la resolución de pequeñas dudas.
Probabilidad: Baja.
Impacto: Alto.
Momento previsto: Durante todo el proyecto.
Plan de contingencia: Dependiendo de lo inesperada de la posible ausencia
se podrán modificar fechas de reuniones o un aplazamiento mayor
siguiendo con una comunicación vía correo electrónico
Sistema de notificación de avisos para eventos programables
Análisis
Universidad de La Rioja Página 23
2. Análisis
Sistema de notificación de avisos para eventos programables
Análisis
Universidad de La Rioja Página 24
2.1) Análisis previsto
En este proyecto fin de carrera, queremos crear una aplicación para el aviso por
distintos sistemas, de algunos eventos que podremos crear. La aplicación
tendrá que integrarse en la empresa en una aplicación ya existente creada con
Oracle Forms. Esta aplicación tendrá que poder ser manejada por distintas
personas, las cuales podrán realizar distintas tareas sobre la aplicación. Para
ello contaremos con el login propio de la aplicación para poder distinguir las
opciones de cada usuario que se conecte.
La aplicación permitirá a los usuarios administradores poder crear nuevos
eventos. Dichos eventos deberán ser configurados al ser creados, poniendo
diferentes características, como son el método de aviso, cuándo se realizará el
mismo y a que personal irá dirigido.
Los usuarios supervisores podrán enviar peticiones para la creación de nuevos
eventos o solicitar cambios en alguno ya existente. Aunque el objetivo principal
de los supervisores es recibir los diferentes avisos creados. Dichos avisos los
podrán ver tanto en la aplicación, como por email o en la aplicación que la
empresa tiene en la intranet. Estos avisos sólo los recibirán los supervisores
responsables de los empleados por los que se lanza el aviso.
Los empleados de la empresa recibirán los avisos en los que se haya
configurado para tal efecto. Estos avisos podrán ser por email o por la intranet,
ya que no todos los empleados tendrán usuario para el acceso a la aplicación.
Tenemos que tener en cuenta que la estructura para llevar el control de
responsables y usuarios, el mantenimiento y la actualización, es realizada por el
personal de la empresa. Por lo que esta clasificación ya nos vendrá dada. Algo
que hay que considerar es que esta clasificación permite a un supervisor serlo
de varios grupos, y a su vez un mismo grupo tener varios supervisores. Además
hay que tener en cuenta que un responsable a su vez puede tener una persona
que sea su responsable. También considerar que no todos los supervisores
serán destinatarios de los avisos del personal del que sean responsables, ya que
pudiendo haber varios, se podrá discriminar decidiendo quienes sí y quienes no
los reciban.
Sistema de notificación de avisos para eventos programables
Análisis
Universidad de La Rioja Página 25
2.2) Análisis tecnológico
En este apartado es donde se analizan las diferentes posibilidades tecnológicas
para cada parte del proyecto. Como el proyecto se engloba dentro de una
aplicación de una empresa, no tenemos opción de evaluar distintas tecnologías
para realizar la estructura de la aplicación principal. Ya que el desarrollo deberá
realizarse con Oracle Forms, y en el Sistema Gestor de Base de Datos ya
existente en dicha empresa, Oracle 10g.
Aunque la gran parte del desarrollo del proyecto se realice con Oracle Forms,
los avisos que se realicen vía email se desarrollarán con java, y los relacionados
con la aplicación de intranet con php. Estas son las tecnologías utilizadas por la
empresa para la realización de este tipo de desarrollos.
La tecnología que estoy utilizando en la empresa y con la que estoy más
familiarizado es el desarrollo de pantallas en Oracle Forms. El desarrollo para
envío de emails y avisos en la intranet no estoy tan habituado a realizar.
2.3) Análisis de Requisitos
Los requisitos que debe cumplir nuestro proyecto los vamos a clasificar
dependiendo para quien está dirigida la funcionalidad.
Para todos los roles:
T.1 El sistema será capaz de validar el usuario que se ha conectado, tanto a
la aplicación para darle los permisos adecuados a las pantallas, como a la
aplicación vía web para mostrar los mensajes precisos.
T.2 El sistema tendrá en algunos casos un sistema de guardado para
modificaciones realizadas tanto para los supervisores como los usuarios, una
auditoría en algunas tablas.
T.3 El sistema deberá enviar los e-mails a cada supervisor y empleado
configurado en los distintos eventos para tal efecto.
Sistema de notificación de avisos para eventos programables
Análisis
Universidad de La Rioja Página 26
Para el rol administrador:
A.1 Poder dar de alta un evento, eligiendo sobre que tablas se cogerán los
datos y los valores de los que se extraerán los datos para que el aviso se realice.
A.2 El sistema permitirá sobre un evento ya crearlo, modificarlo o
eliminarlo.
A.3 El administrador podrá incluir o excluir a un grupo definido, para que no
reciban los avisos, así como también eliminar de los avisos a un responsable en
concreto para que deje de recibirlos.
Para el rol supervisor:
S.1 Podrán realizar peticiones para que el administrador cree nuevos
eventos, o los modifique.
S.2 El sistema permitirá ver en la aplicación todos sus avisos, ordenados por
día y tipo de evento. También poder sacar un informe.
S.3 En la aplicación web, podrá visualizar los avisos de cada día.
S.4 Podrá solicitar que para un determinado evento no le lleguen más
avisos, ya sean de tipo visual en la aplicación o vía email.
S.4 Un supervisor podrá sacar un informe diario, con los grupos del que es
responsable y la gente que se encuentra en él.
S.5 El sistema también permitirá sacar un informe al supervisor de los
eventos que tiene activados y de los tipos de avisos para cada uno de ellos.
Para el rol empleado:
E.1 Estos usuarios verán en la aplicación los avisos de los que hayan sido
objeto, así como de los e-mails que hayan sido enviados para tal efecto.
Sistema de notificación de avisos para eventos programables
Análisis
Universidad de La Rioja Página 27
2.4) Modelo de casos de uso
En el siguiente diagrama de casos de uso se pueden distinguir las distintas
funcionalidades del proyecto.
Como se puede observar existen dos actores bien diferenciados:
Administrador: este rol será desempeñado por los administradores de
la base de datos, no más de tres personas. Ya que deberán interpretar
de dónde han des sacar la información para la creación de los eventos.
Supervisor: son los empleados que sean las encargadas de otros
empleados, no tienen que ser estrictamente sus superiores o jefes, pero
si los que deben tener la información sobre sus diferentes acciones
dentro de la empresa, como sus vacaciones, bajas o jubilaciones.
Sistema de notificación de avisos para eventos programables
Análisis
Universidad de La Rioja Página 28
Después de analizar los diferentes actores, ahora vamos a realizar una
descripción más profunda de los casos de uso, determinando en cada caso cuál
de los requisitos se implementa en cada caso de uso.
1) Crear evento
Esta función sólo la puede realizar uno de los administradores de la
aplicación, después de recibir la petición por parte de algún supervisor.
Tendremos que decidir de dónde vamos a extraer los datos para crear un
evento, y la fecha en la que se lanzará el evento. Así como las
configuraciones propias en cada caso, como el método de aviso y a quién
va dirigido.
2) Modificar/eliminar evento
Esta función como la anterior sólo la podrá gestionar un administrador de
la aplicación. Pudiendo realizarla desde la misma pantalla en la que la
configuramos. Hay que tener en cuenta que se borraran los datos
referentes a los grupos y supervisores a los que iba dirigido el evento,
como la configuración del mismo.
3) Gestión grupos/supervisores para eventos
En esta tarea es donde el administrador de la aplicación, después de
recibir las diferentes peticiones de los supervisores, podrá configurar en
cada caso, si un grupo debe o no recibir notificación acerca de un evento.
También se podrá suprimir a uno de los supervisores de un grupo para
que deje de recibir la notificación de un determinado aviso.
4) Petición de nuevo evento
Esta función la podrá llevar a cabo un supervisor que se haya conectado a
la aplicación. Accediendo a una pantalla podrá describir la petición de un
nuevo evento, poniendo los datos que necesita y cuando quiere que se
envíe el aviso. Esta petición será recibida por los administradores, que
serán los que creen el nuevo evento.
5) Petición para la modificación de avisos
En esta función los supervisores podrán pedir para un determinado
evento, que no les llegue más el aviso. También podrán pedir la
modificación del modo de envío, o los datos que son enviados.
Sistema de notificación de avisos para eventos programables
Análisis
Universidad de La Rioja Página 29
6) Visualizar avisos en la aplicación
Para poder visualizar los avisos, un supervisor podrá acceder a una
pantalla en la aplicación, en ella podrá consultar los avisos que tenga por
empleado, por evento o por fecha.
7) Visualizar avisos en la intranet
En esta función igual que en la anterior, cada supervisor podrá visualizar
los avisos que tenga pendientes, pero en vez de en la aplicación, en la
intranet de la empresa.
8) Sacar informes de los avisos , informe sobre su personal, informe sobre
los eventos y avisos
Estas tres funciones permitirán a un supervisor poder lanzar desde una
pantalla de la aplicación un informe para poder ser imprimido con la
información solicitada en cada caso. Estos informes serán realizados en
Reports de Oracle.
Sistema de notificación de avisos para eventos programables
Diseño
Universidad de La Rioja Página 30
3. Diseño
Sistema de notificación de avisos para eventos programables
Diseño
Universidad de La Rioja Página 31
3.1) Introducción
Para el diseño de nuestra aplicación, tuvimos en cuenta en un principio todo lo
necesario para el correcto funcionamiento de la misma. Para ello se diseña un
modelo de Entidad/ Relación que nos permita de una manera conceptual saber
lo que necesitamos y luego con el modelo de datos determinar las tablas
oportunas.
Por otro lado, una vez tenemos el diseño de nuestra base de datos,
necesitamos las pantallas en las que se pueda introducir, mostrar y borrar los
datos de nuestra aplicación. Para ello, tenemos el diseño de las diferentes
interfaces de nuestra aplicación. Este diseño se realiza con el programa de
Oracle Forms y Oracle Reports.
También diseñamos como se va a mostrar la información de las alertas en los
correos enviados de forma automática a los diferentes responsables.
Hay que reseñar que tanto el sistema gestor de base de datos, como los datos y
los binarios de las pantallas se encontraran en el servidor de aplicaciones. Por
lo que cada usuario que se conecte a la aplicación deberá conectarse a este
servidor para el correcto funcionamiento de la aplicación.
Sistema de notificación de avisos para eventos programables
Diseño
Universidad de La Rioja Página 32
3.2) Diseño de modelo de datos
A) Diagrama Entidad/Relación
El diagrama entidad/Relación, nos permite ver de un modo conceptual, las
necesidades de nuestra aplicación. En él se pueden observar las distintas
entidades, atributos y relaciones existentes. Gracias a este diagrama nos
resultará más fácil comprender y diseñar el modelo de datos.
Sistema de notificación de avisos para eventos programables
Diseño
Universidad de La Rioja Página 33
Para entender mejor el diagrama, vamos a explicar cada de las entidades:
Entidad Empleado: esta entidad es una de las más importantes, ya que
representa, cada una de los empleados que se tienen guardados en la
base de datos. Estos empleados, tienen diversos atributos, aunque el
que actúa como identificativo, será el código.
Esta entidad, se relaciona con todas las demás entidades que integran el
esquema, estas relaciones serán comentadas en cada una de ellas.
Entidad Atributos: en esta entidad se definen los diferentes atributos
que puede tener un empleado, por ello, esta entidad se relaciona con
Empleados, un mismo empleado puede tener muchos atributos
distintos, todos ellos definidos por su tipo, fecha inicio y valor, si el
atributo sigue estando vigente la fecha fin no será necesario rellenarla.
Entidad Vacaciones: esta entidad es la que ofrece la información de las
vacaciones que tiene cada empleado, por eso se relaciona con la
entidad Empleados, cada empleado puede tener varias, estas se definen
por su tipo, fecha inicio y fecha fin.
Entidad Bajas: es en esta entidad donde quedan definidas las posibles
bajas de un empleado, como las maternales o accidentes de trabajo.
Esta entidad se relaciona con Empleados, pudiendo un empleado tener
más de una baja, estas se definirán por su tipo, fecha inicio y fecha fin.
Entidad Gfh: esta entidad es en la que se definen mediante un código y
una descripción los gfh (Grupos funcionales homogéneos). Se relaciona
con Empleados mediante dos relaciones distintas. Una es para definir
que gfh tiene un empleado en concreto, un gfh puede ser ocupado por
varios empleados, pero una persona sólo puede tener un gfh. La otra
relación con Empleados, es para saber los responsables de un gfh, ya
que un empleado puede ser responsable al mismo tiempo de varios gfh
distintos, así como un gfh puede tener varios responsables.
También se relaciona con la entidad Avisos, esta relación sirve para
saber por cada gfh los tipos de avisos que tiene. Cada gfh puede tener
varios avisos distintos, y cada aviso puede estar en varios gfh.
Entidad Avisos: es esta entidad es donde se definen los avisos
propiamente dichos, con su código, descripción, a que tabla de la base
de datos dirigirnos, que campo es el que hay que tener en cuenta,
cuántos días antes de que ocurra el evento hay que avisar, o cuántos
después. Esta entidad, se relaciona con la entidad Gfh como se ha
explicado anteriormente. También se relaciona con la entidad
Empleados, ya que un tipo de aviso lo pueden tener varios empleados, y
un empleado puede tener varios avisos.
Sistema de notificación de avisos para eventos programables
Diseño
Universidad de La Rioja Página 34
B) Modelo de datos
En el modelo de datos, se puede ver cómo quedan las entidades y las relaciones
explicadas en el esquema Entidad/Relación, pero ya sabiendo su distribución en
la base de datos que va a formar nuestra aplicación.
En el modelo de datos se puede observar que la entidad Avisos que estaba en el
esquema Entidad/Relación, se ha dividido en tres tablas: SNAP_TIPOS_AVISOS,
SNAP_TABLAS_AVISOS, SNAP_CONFIG_AVISOS. También podemos observar
que se crea la tabla SNAP_EMPLEADOS_AVISOS, donde se guarda los avisos de
cada empleado, que era la relación que existía entre Empleados y Avisos. La
tabla SNAP_AVISOS_GFH es la resultante de la relación entre Avisos y Gfh. Y por
último se crea la tabla SNAP_RESP_GFH, que relaciona la entidad Empleados y
Gfh, la otra relación entre estas dos entidades, que era para saber que gfh tenía
cada empleado, ha quedado englobada dentro de la tabla SNAP_EMPLEADOS.
Sistema de notificación de avisos para eventos programables
Diseño
Universidad de La Rioja Página 35
C) Esquema externo
La definición de las tablas que ocupan nuestra base de datos, se muestran a
continuación:
SNAP_EMPLEADOS: esta tabla es la que guarda la información referida
a todos los trabajadores de la empresa. La definición es la siguiente:
Nombre Tipo de dato Nulo?
Clave Principal
Observaciones
CODIGO_EMPLEADO Varchar2(10) No Si Coincide con el DNI de la persona sin letra.
APELLIDOS Varchar2(130) No No Apellidos del empleado
NOMBRE Varchar2(60) No No Nombre del empleado
EMAIL Varchar2(40) Si No Corresponde con el correo en el que recibirá los correos de las notificaciones
USUARIO Varchar2(15) Si No Es el nombre del usuario con el que el empleado entra en la aplicación
GFH Varchar2(20) No No Es el grupo funcional en el que se encuentra el empleado
SNAP_GFHS: en esta tabla se encuentran los grupos funcionales
homogéneos con sus descripciones. La definición es la siguiente:
Nombre Tipo de dato Nulo? Clave Principal
Observaciones
GFH Varchar2(15) No Si Es el código único para definir a un grupo funcional en concreto
DESC_GFH Varchar2(50) No No Descripción del grupo funcional
SNAP_TIPOS_AVISOS: es en esta tabla donde definimos los tipos de
avisos. La definición es la siguiente:
Nombre Tipo de dato Nulo? Clave Principal
Observaciones
COD_AVISO Varchar2(15) No Si Es el código único para definir a un aviso
DESCRIPCION Varchar2(30) Si No Descripción corta del tipo de aviso
DESCRIPCION_LARGA Varchar2(15) No No Es una descripción más detallada del tipo de aviso definido
LITERAL_CORREO Varchar2(50) No No Es una frase representativa que servirá para el envío de correos.
Sistema de notificación de avisos para eventos programables
Diseño
Universidad de La Rioja Página 36
SNAP_TABLAS_AVISOS: es en esta en la que se guarda dónde hay que
mirar para que se lance un aviso. La definición es la siguiente:
Nombre Tipo de dato Nulo? Clave Principal
Observaciones
COD_AVISO Varchar2(15) No Si Es el código único para definir a un aviso
TABLA_VISTA Varchar2(30) Si No Tabla de la base de datos en la que se encuentra el dato a buscar para el aviso
COLUMNA Varchar2(30) Si No Columna en la que hay que buscar un valor determinado que desencadena el aviso
VALOR Varchar2(30) Si No El valor que tiene que tener la Columna para que se mire el aviso
FECHA Varchar2(30) Si No Columna en la que se encuentra el campo fecha para saber el día a mirar en el que ocurre un determinado evento.
TIPO_FECHA Varchar2(1) Si No Nos informa de si la columna Fecha es de tipo numérico, carácter o fecha
SNAP_CONFIG_AVISOS: es en esta tabla donde definimos para cada
uno de los avisos, cuándo avisar, es decir si avisamos algún día antes de
que ocurra el evento o algún día después. La definición es la siguiente:
Nombre Tipo de dato Nulo?
Clave Principal
Observaciones
COD_AVISO Varchar2(15) No Si Es el código único para definir a un aviso
DIAS_ANTES1 Number Si No Los días antes de que ocurra un evento en el que hay que avisar
DIAS_ANTES2 Number Si No Los días antes de que ocurra un evento en el que hay que avisar
DIAS_DESPUES1
Number Si No Los días después de que ocurra un evento en el que hay que avisar
DIAS_DESPUES1
Number Si No Los días después de que ocurra un evento en el que hay que avisar
SNAP_RESP_GFH: es en esta tabla donde definimos los responsables de
cada gfh. La definición es la siguiente:
Nombre Tipo de dato Nulo? Clave Principal
Observaciones
GFH Varchar2(15) No Si Es el código único para definir a un grupo funcional en concreto
COD_RESP
Varchar2(10) No Si Es el código de empleado que será responsable del gfh
Sistema de notificación de avisos para eventos programables
Diseño
Universidad de La Rioja Página 37
SNAP_ATRIBUTOS: es en esta tabla donde definimos los atributos de los
empleados. La definición es la siguiente:
Nombre Tipo de dato Nulo? Clave Principal
Observaciones
COD_EMPLEADO
Varchar2(10) No Si Es el código del empleado
TIPO_ATRIBUTO Varchar2(15) No Si Tipo de atributo que se informa
FECHA_INI Number No Si Fecha desde que tiene el atributo
FECHA_FIN Number Si No Fecha en la que deja de tener el atributo definido
VALOR Varchar2(15) Si No Valor posible del atributo definido
SNAP_VACACIONES: es en esta tabla donde definimos las vacaciones de
los empleados. La definición es la siguiente:
Nombre Tipo de dato Nulo? Clave Principal
Observaciones
COD_EMPLEADO
Varchar2(10) No Si Es el código del empleado
TIPO_VAC Varchar2(15) No Si Tipo de vacación del empleado
FECHA_INI Number No Si Fecha desde que tiene ese tipo de vacación
FECHA_FIN Number Si No Fecha en la que termina ese tipo de vacación
SNAP_BAJAS: es en esta tabla donde definimos las bajas de los
empleados. La definición es la siguiente:
Nombre Tipo de dato Nulo? Clave Principal
Observaciones
COD_EMPLEADO
Varchar2(10) No Si Es el código del empleado
TIPO_BAJA Varchar2(15) No Si Tipo de baja del empleado
FECHA_INI Number No Si Fecha desde que tiene ese tipo de baja
FECHA_FIN Number Si No Fecha en la que termina ese tipo de baja
Sistema de notificación de avisos para eventos programables
Diseño
Universidad de La Rioja Página 38
SNAP_DESCRIPCIONES: es en esta tabla donde ponemos las
descripciones de los códigos correspondientes a las diferentes tablas de
atributos, vacaciones y bajas. La definición es la siguiente:
Nombre Tipo de dato Nulo? Clave Principal
Observaciones
TIPO_TABLA Varchar2(20) No Si Tabla en la que se define la descripción
TIPO Varchar2(15) No Si Tipo de baja, vacación o atributo
DESCRIPCIÓN Varchar2(400)
Si No Descripción larga del tipo definido
SNAP_AVISOS_GFH: es en esta tabla donde se guarda que tipos de
avisos se realizan para cada gfh. La definición es la siguiente:
Nombre Tipo de dato Nulo?
Clave Principal
Observaciones
COD_AVISO Varchar2(15) No Si Código del aviso
GFH Varchar2(15) No Si Código del gfh
AVISO_APLICACION
Varchar2(1) Si No Si existe una ‘S’ es que hay que avisar vía aplicación
AVISO_INTERNET Varchar2(1) Si No Si existe una ‘S’ es que hay que avisar vía intranet
AVISO_CORREO Varchar2(1) Si No Si existe una ‘S’ es que hay que avisar vía correo electrónico
SNAP_EMPLEADOS_AVISOS: es en esta tabla donde se guardan los
avisos que hay que realizar para un empleado en concreto en una fecha
determinada. La definición es la siguiente:
Nombre Tipo de dato Nulo?
Clave Principal
Observaciones
COD_EMPLEADO Varchar2(10) No No Código del empleado
GFH Varchar2(15) No No Código del gfh
COD_AVISO Varchar2(15) No No Código del aviso
FECHA_AVISO Number No No Fecha en la que hay que avisar del evento
FECHA Number No No Fecha en la que ocurre el evento a avisar
TIPO_AVISO Varchar2(20) No No Si el aviso es de días antes o después
AVIS_APLICACION Varchar2(1) Si No Si existe una ‘S’ es que hay que avisar vía aplicación
AVIS_INTRANET Varchar2(1) Si No Si existe una ‘S’ es que hay que avisar vía intranet
AVIS_CORREO Varchar2(1) Si No Si existe una ‘S’ es que hay que avisar vía correo electrónico
Sistema de notificación de avisos para eventos programables
Diseño
Universidad de La Rioja Página 39
3.3) Diseño de la aplicación
A) Diseño de las pantallas en Forms
Las pantallas de la aplicación se han diseñado con Oracle Forms Builder.
Tanto los colores como algunos diseños de los botones y tipos de letra vienen
dados por la imagen corporativa de la empresa. Aunque la disposición de los
campos y el tamaño ha sido diseñado íntegramente.
En una misma pantalla, la de Configuración avisos, tendremos diferentes
pestañas, cada una para un fin.
En la siguiente pestaña de la pantalla de Configuración de Avisos se definen los
avisos, la parte de la descripciones, la tabla a la que hay que ir a mirar si se
tienen que enviar y las demás configuraciones necesarias.
Sistema de notificación de avisos para eventos programables
Diseño
Universidad de La Rioja Página 40
En la siguiente pestaña de la misma pantalla, se administran los gfh, tanto para
poder borrarlos y darlos de alta, como para administrar los responsables de
cada grupo funcional.
En esta última pestaña de la pantalla de configuraciones, es donde se define
para qué grupos se realizan los avisos y por qué medio se realizan.
Sistema de notificación de avisos para eventos programables
Diseño
Universidad de La Rioja Página 41
La siguiente pantalla es donde se configuran los empleados, atributos, bajas,
vacaciones y las descripciones de cada tipo de uno de ellos. La pantalla se llama
Datos de empleados y descripciones.
En la siguiente imagen, se puede ver la pestaña en la que se configuran los
empleados, con su código, apellidos, nombre, email usuario y gfh al que
pertenece.
En la siguiente pestaña es en la que se definen los diferentes atributos de cada
empleado. Como su unidad, contrato o sexo.
Sistema de notificación de avisos para eventos programables
Diseño
Universidad de La Rioja Página 42
En la siguiente pestaña es donde se configuran las vacaciones de cada
empleado. Pudiendo determinar el tipo, su inicio y su fin.
La siguiente pestaña es donde se pueden configurar las distintas bajas de los
empleados. Identificando de que tipo es y su inicio y fin.
Sistema de notificación de avisos para eventos programables
Diseño
Universidad de La Rioja Página 43
En esta última pestaña es donde ponemos las descripciones de los tipos de
bajas, vacaciones y atributos.
La siguiente pantalla es la que se utiliza para visualizar los avisos de los
empleados. También desde aquí se puede lanzar el informe que se generará
con el Oracle Reports. Dicha pantalla se denomina Visualización de avisos.
Sistema de notificación de avisos para eventos programables
Diseño
Universidad de La Rioja Página 44
B) Diseño de los informes en Reports
El informe que se muestra a continuación es el que se imprime desde la
pantalla de Visualización de Avisos.
C) Diseño de los correos con los avisos
El diseño para los correos electrónicos que se mandarán a los supervisores será
el siguiente:
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 45
4. Construcción
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 46
4.1) Introducción
Para la implementación de nuestra aplicación, vamos a tener que realizar la
creación tanto de las tablas y vistas para el almacenamiento y visualización de
los datos, como la creación e implementación de funciones y procedimientos
almacenados para el correcto funcionamiento de la aplicación.
Por otro lado, también tendremos que realizar las diferentes pantallas e
informes para poder introducir y visualizar los datos almacenados en las tablas
y vistas creadas.
4.2) Construcción de la Base de Datos
La base de datos para nuestra aplicación, estará englobada dentro de la base de
datos de la empresa. Pero se instalará en distinto esquema.
La base de datos para la aplicación estará dentro del esquema SNAP y será el
propietario de las tablas, vistas, funciones y procedimientos.
Gracias al desarrollo en el apartado anterior del diseño de la base de datos, la
creación de las tablas resulta menos costosa. Pasamos a detallar la creación de
cada una de las tablas para nuestra base de datos.
SNAP_EMPLEADOS:
CREATE TABLE snap_empleados
(codigo_empleado VARCHAR2(10) NOT NULL,
apellidos VARCHAR2(130) NOT NULL,
nombre VARCHAR2(60) NOT NULL,
email VARCHAR2(40),
usuario VARCHAR2(15),
gfh VARCHAR2(20) NOT NULL)
ALTER TABLE snap_empleados
ADD CONSTRAINT snap_emple_uk UNIQUE (codigo_empleado, gfh)
USING INDEX
ALTER TABLE snap_empleados
ADD CONSTRAINT snap_empleados_pk PRIMARY KEY (codigo_empleado)
USING INDEX
ALTER TABLE snap_empleados
ADD CONSTRAINT snap_empleados_gfh_fk FOREIGN KEY (gfh)
REFERENCES snap_gfhs (gfh)
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 47
SNAP_GFHS:
CREATE TABLE snap_gfhs
(gfh VARCHAR2(15) NOT NULL,
desc_gfh VARCHAR2(50) NOT NULL)
ALTER TABLE snap_gfhs
ADD CONSTRAINT snap_gfhs_fk PRIMARY KEY (gfh)
USING INDEX
SNAP_TIPOS_AVISOS
CREATE TABLE snap_tipos_avisos
(cod_aviso VARCHAR2(15) NOT NULL,
descripción VARCHAR2(30),
descripcion_larga VARCHAR2(200),
literal_correo VARCHAR2(200))
ALTER TABLE snap_tipos_avisos
ADD CONSTRAINT snap_tipos_avisos_pk PRIMARY KEY (cod_aviso)
USING INDEX
SNAP_TABLAS_AVISOS:
CREATE TABLE snap_tablas_avisos
(cod_aviso VARCHAR2(15) NOT NULL,
tabla_vista VARCHAR2(30),
column aVARCHAR2(30),
valor VARCHAR2(30),
fecha VARCHAR2(30),
tipo_fecha VARCHAR2(1))
ALTER TABLE snap_tablas_avisos
ADD CONSTRAINT snap_tablas_avisos_pk PRIMARY KEY (cod_aviso)
USING INDEX
ALTER TABLE snap_tablas_avisos
ADD CONSTRAINT snap_tab_avis_tipos_fk FOREIGN KEY (cod_aviso)
REFERENCES snap_tipos_avisos (cod_aviso)
SNAP_CONFIG_AVISOS:
CREATE TABLE snap_config_avisos
(cod_aviso VARCHAR2(15) NOT NULL,
dias_antes1 NUMBER,
dias_antes2 NUMBER,
dias_despues1 NUMBER,
dias_despues2 NUMBER)
ALTER TABLE snap_config_avisos
ADD CONSTRAINT snap_config_avisos_pk PRIMARY KEY (cod_aviso)
USING INDEX
ALTER TABLE snap_config_avisos
ADD CONSTRAINT snap_conf_avis_tabl_fk FOREIGN KEY (cod_aviso)
REFERENCES snap_tablas_avisos (cod_aviso)
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 48
SNAP_RESP_GFH:
CREATE TABLE snap_resp_gfh
(gfh VARCHAR2(15) NOT NULL,
cod_resp VARCHAR2(10) NOT NULL)
ALTER TABLE snap_resp_gfh
ADD CONSTRAINT snap_resp_gfh_pk PRIMARY KEY (gfh, cod_resp)
USING INDEX
ALTER TABLE snap_resp_gfh
ADD CONSTRAINT snap_resp_gfh_gfhs_fk FOREIGN KEY (gfh)
REFERENCES snap_gfhs (gfh)
ALTER TABLE snap_resp_gfh
ADD CONSTRAINT snap_resp_gfh_emple FOREIGN KEY (cod_resp)
REFERENCES snap_empleados (codigo_empleado)
SNAP_ATRIBUTOS:
CREATE TABLE snap_atributos
(cod_empleado VARCHAR2(10) NOT NULL,
tipo_atributo VARCHAR2(15) NOT NULL,
fecha_ini NUMBER NOT NULL,
fecha_fin NUMBER,
valor VARCHAR2(15))
ALTER TABLE snap_atributos
ADD CONSTRAINT snap_atibutos_pk PRIMARY KEY
(cod_empleado,tipo_atributo,fecha_ini)
USING INDEX
ALTER TABLE snap_atributos
ADD CONSTRAINT snap_atributos_emple_fk FOREIGN KEY (cod_empleado)
REFERENCES snap_empleados (codigo_empleado)
SNAP_VACACIONES:
CREATE TABLE snap_vacaciones
(cod_empleado VARCHAR2(10) NOT NULL,
tipo_vac VARCHAR2(15) NOT NULL,
fecha_ini NUMBER NOT NULL,
fecha_fin NUMBER)
ALTER TABLE snap_vacaciones
ADD CONSTRAINT snap_vacaciones_pk PRIMARY KEY
(cod_empleado, tipo_vac, fecha_ini)
USING INDEX
ALTER TABLE snap_vacaciones
ADD CONSTRAINT snap_vacaciones_empleado_fk FOREIGN KEY
(cod_empleado)
REFERENCES snap_empleados (codigo_empleado)
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 49
SNAP_BAJAS:
CREATE TABLE snap_bajas
(cod_empleado VARCHAR2(10) NOT NULL,
tipo_baja VARCHAR2(15) NOT NULL,
fecha_ini DATE NOT NULL,
fecha_fin DATE)
ALTER TABLE snap_bajas
ADD CONSTRAINT snap_bajas_pk PRIMARY KEY
(cod_empleado, tipo_baja, fecha_ini)
USING INDEX
ALTER TABLE snap_bajas
ADD CONSTRAINT snap_bajas_emple_fk FOREIGN KEY (cod_empleado)
REFERENCES snap_empleados (codigo_empleado)
SNAP_DESCRIPCIONES
CREATE TABLE snap_descripciones
(tipo_tabla VARCHAR2(20) NOT NULL,
tipo VARCHAR2(15) NOT NULL,
descripción VARCHAR2(400))
ALTER TABLE snap_descripciones
ADD CONSTRAINT snap_descripciones_pk PRIMARY KEY
(tipo_tabla, tipo)
USING INDEX
SNAP_AVISOS_GFH:
CREATE TABLE snap_avisos_gfh
(cod_aviso VARCHAR2(15) NOT NULL,
gfh VARCHAR2(15) NOT NULL,
aviso_aplicacion VARCHAR2(1),
aviso_intranet VARCHAR2(1),
aviso_correo VARCHAR2(1))
ALTER TABLE snap_avisos_gfh
ADD CONSTRAINT snap_avisos_gfh_pk PRIMARY KEY (cod_aviso, gfh)
USING INDEX
ALTER TABLE snap_avisos_gfh
ADD CONSTRAINT snap_avis_gfh_config_fk FOREIGN KEY (cod_aviso)
REFERENCES snap_config_avisos (cod_aviso)
ALTER TABLE snap_avisos_gfh
ADD CONSTRAINT snap_avis_gfh_gfhs_fk FOREIGN KEY (gfh)
REFERENCES snap_gfhs (gfh)
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 50
SNAP_EMPLEADOS_AVISOS:
CREATE TABLE snap_empleados_avisos
(cod_empleado VARCHAR2(10) NOT NULL,
gfh VARCHAR2(15) NOT NULL,
cod_aviso VARCHAR2(15) NOT NULL,
fecha_aviso NUMBER NOT NULL,
fecha NUMBER NOT NULL,
tipo_aviso VARCHAR2(20) NOT NULL,
avis_aplicacion VARCHAR2(1),
avis_intranet VARCHAR2(1),
avis_correo VARCHAR2(1))
ALTER TABLE snap_empleados_avisos
ADD CONSTRAINT snap_emple_avis_emp_fk FOREIGN KEY
(cod_empleado, gfh)
REFERENCES snap_empleados (codigo_empleado,gfh)
ALTER TABLE snap_empleados_avisos
ADD CONSTRAINT snap_emple_avis_cod_a_fk FOREIGN KEY (cod_aviso)
REFERENCES snap_tipos_avisos (cod_aviso)
Además de todas estas tablas, tenemos las siguientes vistas para la correcta
visualización de los datos y mejor funcionamientos en la lógica del programa.
SNAP_AVIS_GFH_VW: esta vista la utilizamos para la configuración en
una de las pantallas sobre que avisos hay sobre que gfhs.
CREATE OR REPLACE VIEW snap_avis_ghf_vw
(cod_aviso,descripcion,gfh,desc_gfh,aplic,intranet,correo ) AS
select s.cod_aviso ,s.descripcion ,g.gfh ,g.desc_gfh ,
(select a.aviso_aplicacion from snap_avisos_gfh a
where a.cod_aviso = s.cod_aviso and a.gfh = g.gfh)as aplic,
(select a.aviso_intranet from snap_avisos_gfh a
where a.cod_aviso = s.cod_aviso and a.gfh = g.gfh)as intranet,
(select a.aviso_correo from snap_avisos_gfh a
where a.cod_aviso = s.cod_aviso and a.gfh = g.gfh)as correo
from snap_tipos_avisos s,snap_gfhs g
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 51
SNAP_AVISOS_UNION_VW: esta vista se utiliza para el procedimiento a
llamar por el que se realizarán los avisos
CREATE OR REPLACE VIEW snap_avisos_union_vw
(cod_aviso,tabla_vista,columna,valor,fecha,tipo_fecha,sumar_restar,
dias, literal, gfh, aviso_aplicacion, aviso_intranet,aviso_correo )AS
select t.cod_aviso ,t.tabla_vista ,t.columna ,t.valor ,t.fecha ,
t.tipo_fecha ,'S' as sumar_restar,c.dias_antes1 as dias, 'Dias antes
1' as literal,g.gfh ,g.aviso_aplicacion ,g.aviso_intranet ,
g.aviso_correo
from snap_tablas_avisos t,snap_config_avisos c, snap_avisos_gfh g
where t.cod_aviso = c.cod_aviso
and c.cod_aviso = g.cod_aviso
and c.dias_antes1 is not null
union all
select t.cod_aviso ,t.tabla_vista ,t.columna ,t.valor ,
t.fecha,t.tipo_fecha,'S' as sumar_restar,c.dias_antes2as dias,'Dias
antes 2', as literal,g.gfh ,g.aviso_aplicacion ,g.aviso_intranet ,
g.aviso_correo
from snap_tablas_avisos t,snap_config_avisos c, snap_avisos_gfh g
where t.cod_aviso = c.cod_aviso
and c.cod_aviso = g.cod_aviso
and c.dias_antes2 is not null
union all
select t.cod_aviso ,t.tabla_vista ,t.columna ,t.valor ,t.fecha ,
t.tipo_fecha ,'S' as sumar_restar,c.dias_despues1 as dias, 'Dias
después 1' as literal,g.gfh ,g.aviso_aplicacion ,g.aviso_intranet ,
g.aviso_correo
from snap_tablas_avisos t,snap_config_avisos c, snap_avisos_gfh g
where t.cod_aviso = c.cod_aviso
and c.cod_aviso = g.cod_aviso
and c.dias_despues1 is not null
union all
select t.cod_aviso ,t.tabla_vista ,t.columna ,t.valor ,t.fecha ,
t.tipo_fecha ,'S' as sumar_restar,c.dias_despues2as dias, 'Dias
después 2' as literal,g.gfh ,g.aviso_aplicacion ,g.aviso_intranet ,
g.aviso_correo
from snap_tablas_avisos t,snap_config_avisos c, snap_avisos_gfh g
where t.cod_aviso = c.cod_aviso
and c.cod_aviso = g.cod_aviso
and c.dias_despues2 is not null
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 52
4.3) Implementación de la lógica
La implementación de la lógica a grandes rasgos es conseguir que la aplicación
después de tener la información de cómo queremos que se ejecuten
determinados avisos, sea capaz de determinar con la información introducida
qué avisos hay que mandar, teniendo en cuenta a quién hay que avisar y por
qué medio.
Para ello realizamos un procedimiento en el que mirando en la vista
SNAP_AVISOS_UNION_VW se mira para cada aviso y tipo de aviso y se llama al
procedimiento en el que se crea el cursor dinámico para saber a qué personas
avisar.
PROCEDURE SNAP_AVISOS_TABLA_PROC
( p_fech date) IS
--cursor de la vista para saber que avisos hay que realizar
cursor avisos_union is
select s.cod_aviso ,s.tabla_vista ,s.columna ,s.valor ,s.fecha ,
s.tipo_fecha , s.sumar_restar ,s.dias ,s.literal,
s.gfh,s.aviso_aplicacion ,s.aviso_intranet ,s.aviso_correo
from snap_avisos_union_vw s;
v_cod_aviso varchar2(10);
v_tabla_vista varchar2(40);
v_columna varchar2(40);
v_valor varchar2(20);
v_fecha varchar2 (40);
v_tipo_fecha varchar2(10);
v_sumar_restar varchar2(1);
v_dias number;
v_literal varchar2(30);
v_gfh varchar2(30);
v_aviso_aplicacion varchar2(2);
v_aviso_intranet varchar2(2);
v_aviso_correo varchar2(2);
v_fecha_aux number;
v_aux_tipo_fecha varchar2(100);
BEGIN
--empezamos el cursor
For uno in avisos_union loop
begin
v_cod_aviso := uno.cod_aviso;
v_tabla_vista := uno.tabla_vista;
v_columna := uno.columna;
v_valor := uno.valor;
v_fecha := uno.fecha;
v_tipo_fecha := uno.tipo_fecha;
v_sumar_restar := uno.sumar_restar;
v_dias := uno.dias;
v_literal := uno.literal;
v_gfh := uno.gfh;
v_aviso_aplicacion := uno.aviso_aplicacion;
v_aviso_intranet := uno.aviso_intranet;
v_aviso_correo := uno.aviso_correo;
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 53
--dependiendo si la columna en la que se encuentra la fecha es de tipo
fecha, caracter o juliano, realizamos una conversión en cada caso
IF v_tipo_fecha= 'D' THEN
V_AUX_TIPO_FECHA:= 'TO_NUMBER(TO_CHAR('||v_fecha||',''J''))';
ELSE
IF v_tipo_fecha= 'V' THEN
V_AUX_TIPO_FECHA:=
'TO_NUMBER(TO_CHAR(TO_DATE('||v_fecha||',''DD/MM/YYYY''),''J''))';
ELSE
V_AUX_TIPO_FECHA:= V_FECHA;
END IF;
END IF;
--dependiendo si se trata de dias antes o días despues,
--sumamos o restamos para el cálculo de la fecha
if v_sumar_restar = 'S' then
v_fecha_aux:= TO_NUMBER(TO_CHAR(p_fech,'J'))+v_dias;
else
v_fecha_aux:= TO_NUMBER(TO_CHAR(p_fech,'J'))-v_dias;
end if;
--lamamos al procedimiento que crea el cursor dinámico con todas las
variables
SNAP_CURSOR_DINAMICO_PROC(p_fech, v_cod_aviso,
v_tabla_vista, v_columna,v_valor, v_gfh,
v_aviso_aplicacion, v_aviso_intranet,
v_aviso_correo,v_fecha_aux, v_aux_tipo_fecha, v_literal) ;
end;
end loop;
END;
Este procedimiento llama al del cursor dinámico que se detalla a continuación:
PROCEDURE SNAP_CURSOR_DINAMICO_PROC
( p_fech date,v_cod_aviso varchar2,v_tabla_vista varchar2,v_columna
varchar2, v_valor varchar2, v_gfh varchar2,v_aviso_aplicacion
varchar2,v_aviso_intranet varchar2, v_aviso_correo varchar2,
v_fecha_aux number, v_aux_tipo_fecha VARCHAR2, v_literal varchar2) IS
--definimos el tipo ref_curs_dinamico como cursor
TYPE ref_curs_dinamico IS REF CURSOR;
--definimos la variable curs_din de tipo ref_curs_dinamico, que es de
tipo cursor
curs_din ref_curs_dinamico;
--definimos un repositorio del mismo tipo que la tabla snap_aux
--snap aux es una tabla de una sola columna (cod_empleado varchar2(10)
repositorio snap_aux%ROWTYPE;
--definimos una variable para almacenar la select que será con la
--que creemoes el cursor
sql_stmt VARCHAR2(1000);
BEGIN
--creamos la select que será producto para nuestro cursor
--en ella creamo la select de la tabla pasado por referencia,
-- la columna a consultar, con el valor que ha de tener
-- y por último y más importante la columna en donde
--esta la fecha y el valor que ha de tener para realizar el aviso
sql_stmt := 'SELECT cod_empleado FROM '||v_tabla_vista||' where
'||v_columna||' = '''||v_valor||''' and '||V_AUX_TIPO_FECHA||' =
'||v_fecha_aux||' and SNAP_GFH_FUNC(cod_empleado)= '''||v_gfh||'''';
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 54
dbms_output.put_line('sql: '||sql_stmt);
--una vez tenemos almacenado en la variable sql_stmt la select para
-- la creación del cursor, abrimos dicho cursor
OPEN curs_din FOR sql_stmt;
--ahora recorremos con un bucle el cursor, almacenando el resultado
-- en repositorio, recorremos todo el cursor hasta el final
LOOP FETCH curs_din INTO repositorio;
EXIT WHEN curs_din%NOTFOUND;
--cada vez que entra y el cursor no se ha terminado, insertamos
--en la tabla los datos para el posterior envió de avisos.
INSERT INTO SNAP_EMPLEADOS_AVISOS VALUES
(repositorio.cod_empleado,v_gfh,v_cod_aviso,
TO_NUMBER(TO_CHAR(p_fech,'J')),v_fecha_aux,v_literal,
v_aviso_aplicacion,v_aviso_intranet,v_aviso_correo);
commit;
dbms_output.put_line('resultado: '||repositorio.cod_empleado);
--finalizamos el bucle y cerramos el cursor.
END LOOP;
CLOSE curs_din;
END;
Este procedimiento llama a la función SNAP_GFH_FUNC cuya definición se
detalla a continuación.
FUNCTION SNAP_GFH_FUNC (v_cod_empleado varchar2)
RETURN varchar2 IS ret_gfh varchar2(20);
BEGIN
select e.gfh into ret_gfh
from snap_empleados e
where e.codigo_empleado = v_cod_empleado;
RETURN ret_gfh;
END;
Gracias a estos dos procedimientos, se llena la tabla
SNAP_EMPLEADOS_AVISOS, una vez llenada esta tabla, lanzaremos el
procedimiento por el que se envían los correos electrónicos.
Este procedimiento lo que realiza es un repaso por todos los avisos que se
tienen que mandar, y lo que mira es el gfh que tienen los empleados a avisar en
el día pasado al procedimiento, y con ese gfh el responsable que tiene, de este
modo saber a qué responsables hay que mandar correo
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 55
PROCEDURE SNAP_AVISOS_CORREO
( p_fechdate) IS
cursor responsables is
--cursor en el que se mira si hay un aviso para el día que
--estamos lanzando y saca los distintos responsables
select distinct r.cod_resp
from SNAP_EMPLEADOS_AVISOS s,SNAP_RESP_GFH r
where s.avis_correo = 'S'
and s.fecha_aviso = TO_NUMBER(TO_CHAR(p_fech,'J'))
and s.gfh = r.gfh;
BEGIN
For uno in responsables loop
begin
dbms_output.put_line('Responsable: '||uno.cod_resp);
snap_enviar_correo(uno.cod_resp,p_fech);
end;
end loop;
EXCEPTION
WHEN others THEN
dbms_output.put_line('error');
END;
El procedimiento anterior, llama al procedimiento que crea el correo para
mandar al responsable introducido por parámetro:
PROCEDURE SNAP_ENVIAR_CORREO(v_cod_responsable varchar2,p_fecha date)
IS
-- Búsqueda de mail y datos de la incidencia.
CURSOR V_GFHS IS
--miro los gfh que es responsable
select distinct s.gfh
from SNAP_EMPLEADOS_AVISOS s,SNAP_RESP_GFH r
where s.avis_correo = 'S'
and s.gfh = r.gfh
and s.fecha_aviso = TO_NUMBER(TO_CHAR(p_fecha,'J'))
and r.cod_resp = v_cod_responsable;
CURSOR V_COD_AVISOS (cur_gfh varchar2 )IS
--miro los códigos de avisos distintos para el gfh pasado al cursor
select distinct s.cod_aviso,t.literal_correo
from SNAP_EMPLEADOS_AVISOS s,SNAP_TIPOS_AVISOS t
where s.gfh = cur_gfh
and t.cod_aviso = s.cod_aviso
and s.fecha_aviso = TO_NUMBER(TO_CHAR(p_fecha,'J'))
and s.avis_correo = 'S';
CURSOR V_EMPLEADOS (cur_gfh varchar2,cur_cod_aviso varchar2 ) IS
select s.cod_empleado ,E.apellidos ,E.nombre ,
TO_CHAR(TO_DATE(S.fecha ,'J'),'DD/MM/YYYY')AS FECHA
from SNAP_EMPLEADOS_AVISOS S,SNAP_EMPLEADOS E
where s.avis_correo = 'S'
AND S.cod_empleado = E.codigo_empleado
AND s.gfh = cur_gfh
and s.cod_aviso = cur_cod_aviso
and s.fecha_aviso = TO_NUMBER(TO_CHAR(p_fecha,'J'))
order by s.fecha ,s.cod_empleado;
v_fecha_c varchar2(15);
SENDER VARCHAR2(100) := xxxxxxxxxx;
RECIPIENT VARCHAR2(100);--el destinatario
SUBJECT VARCHAR2(400);
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 56
MESSAGE VARCHAR2(19000);
mailhost CONSTANT VARCHAR2(30) := xxxxxxx;
-- servidor de correo – ‘XXXX’;
mesg VARCHAR2(10000); -- texto del mensaje
mail_conn UTL_SMTP.CONNECTION; -- conexión con el servidor smtp
fallo_mail EXCEPTION;
fin_no_finalizada EXCEPTION;
V_MAIL VARCHAR2(100);
BEGIN
v_fecha_c:= to_char(p_fecha,'dd/mm/yyyy');
begin
--pongo en el Recipient el destinatario del correo, en este
--caso el email del responsable
select s.email into RECIPIENT
from SNAP_EMPLEADOS s
where s.codigo_empleado = v_cod_responsable;
end;
RECIPIENT:=xxxxxx;
--el asunto del mensaje
SUBJECT := 'Avisos sobre incidencias del día ' ||v_fecha_c;
--inicio el mensage del correo
MESSAGE :=MESSAGE || '<HTML><BODY>';
FOR G IN V_gfhs LOOP
--voy mirando los gfhs de los que es responsable y si tienen
--avisos para el día señalado
dbms_output.put_line('Responsable: '||v_cod_responsable|| '
Gfh: '||G.gfh);
MESSAGE := MESSAGE || '<B><U>Los avisos para el gfh: '||G.gfh||'
del día '||v_fecha_c||' son:</B></U>';
MESSAGE :=MESSAGE || CHR(13) || CHR(10) || CHR(13) || CHR(10) ||
'<br><br>';
FOR A IN V_COD_AVISOS(G.GFH) LOOP
--los diferentes códigos de avisos que existen para el gfh tratado
MESSAGE := MESSAGE || '<B>El aviso: '||A.cod_aviso||' que avisa de los
empleados que tienen '||A.literal_correo||' son:</B>';
MESSAGE :=MESSAGE || CHR(13) || CHR(10) || CHR(13) || CHR(10) ||
'<br><br>';
--inicio de lista
MESSAGE := MESSAGE ||'<UL>';
FOR E IN V_EMPLEADOS(G.GFH,A.cod_aviso) LOOP
--todos los empleados que tienen el código de aviso en
--la fecha señalada y el gfh tratado
MESSAGE := MESSAGE ||'<LI>'||e.cod_empleado ||' '||E.apellidos||',
'||E.nombre||' fecha en la que ocurre el aviso: '|| E.FECHA||'.</LI>';
END LOOP;
--fin de lista
MESSAGE :=MESSAGE ||'</UL>';
END LOOP;
MESSAGE :=MESSAGE || CHR(13) || CHR(10) || CHR(13) ||
CHR(10) || '<br><br>';
END LOOP;
MESSAGE :=MESSAGE || '</BODY></HTML>';
-- Una vez construidos los parámetros del mensaje, se
--construye el correo completo
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 57
mail_conn := utl_smtp.open_connection(mailhost, 25);
mesg := 'Date: ' ||
TO_CHAR(SYSDATE, 'dd Mon yy hh24:mi:ss' ) || ' +0000' ||
CHR(13) || CHR(10) ||
'From: <'|| Sender ||'>' || CHR(13) || CHR(10) ||
'Subject: '|| Subject || CHR(13) || CHR(10)||
'To: '||Recipient || CHR(13) || CHR(10) ||
'CC: '|| CHR(13) || CHR(10) ||
'Content-Type: text/html;' || CHR(13) || CHR(10) ||
CHR(13) || CHR(10) || Message;
utl_smtp.ehlo(mail_conn, mailhost);
--< Líneas para la autenticación del envío mail
UTL_SMTP.command(mail_conn,'auth login');
UTL_SMTP.command(mail_conn,
utl_raw.cast_to_varchar2(utl_encode.base64_encode(UTL_RAW.cast_to_raw(
xxxxxx'))));
UTL_SMTP.command(mail_conn,
utl_raw.cast_to_varchar2(utl_encode.base64_encode(UTL_RAW.cast_to_raw(
'xxxxx'))));
-->
utl_smtp.mail(mail_conn, Sender);
utl_smtp.rcpt(mail_conn, Recipient);
utl_smtp.rcpt(mail_conn, Sender);
utl_smtp.data(mail_conn, mesg);
utl_smtp.quit(mail_conn);
EXCEPTION
WHEN fallo_mail THEN
RAISE_APPLICATION_ERROR(-20002, 'No se ha encontrado el
mail del empleado en concreto ');
WHEN fin_no_finalizada THEN
RAISE_APPLICATION_ERROR(-20003, 'No se ha podido enviar el
mail.');
-- WHEN OTHERS THEN
-- RAISE_APPLICATION_ERROR(-20004,SQLERRM);
END snap_enviar_correo;
Gracias a estos procedimientos es como se llena la tabla para saber que
empleados tienen avisos y a que responsables hay que avisar de dichos avisos
por correo electrónico. Para lanzar los dos procedimientos se crea el
procedimiento SNAP_LANZAMIENTO, que contiene el siguiente código.
PROCEDURE snap_lanzamiento
( p_fechdate) IS
aux_fecha date;
BEGIN
aux_fecha:=p_fech-1;
SNAP.SNAP_AVISOS_TABLA_PROC(aux_fecha );
commit;
SNAP.SNAP_AVISOS_CORREO (aux_fecha);
commit;
EXCEPTION
WHEN others THEN
dbms_output.put_line('error');
END;
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 58
Este procedimiento es llamado por un “job” nocturno, cuyo código es el
siguiente
DECLARE
X NUMBER;
BEGIN
SYS.DBMS_JOB.SUBMIT
(job=> X
,what=>'SNAP.SNAP_LANZAMIENTO
(sysdate);'
,next_date => to_date('11/12/2012 17:45:35',
'dd/mm/yyyy hh24:mi:ss')
, interval=>'TRUNC(SYSDATE+1)'
,no_parse =>TRUE
);
SYS.DBMS_OUTPUT.PUT_LINE('Job Number is: ' || to_char(x));
END;
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 59
4.4) Implementación de la interfaz
En este apartado se explica para las diferentes pantallas diseñadas, las
restricciones, disparadores y eventos que se han puesto en cada una de ellas.
A) Implementación de la pantalla Configuración de avisos
I. Pestaña de Tipos de Avisos
En la siguiente imagen de la primera pestaña, se puede observar las relaciones
de la pestaña Tipos de Avisos, con los diferentes campos de cada tabla.
En rojo, son los campos de la tabla SNAP_TIPOS_AVISOS, en azul los de la tabla
SNAP_TABLAS_AVISOS y en verde los de la tabla SNAP_CONFIG_AVISOS.
Para relacionarse una tabla con la siguiente, se realiza en el forms una relación,
esta nos permitirá luego por medio de dos triggers sencillos, poder introducir
datos y consultarlos de forma más sencilla y correcta.
La relación la definimos de la siguiente forma:
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 60
En la imagen se puede observar que hay dos relaciones, la primera en rojo es la
que tiene la imagen de las propiedades en la parte inferior, relacionamos la
tabla de SNAP_TIPOS_AVISOS y SNAP_TABLAS_AVISOS. Para ello en las
propiedades se define en el apartado de Join Condition la igualdad entre el
campo COD_AVISO entre las dos tablas. La otra relación marcada en azul
relacionará la tabla SNAP_TABLAS_AVISOS con la tabla SNAP_CONFIG_AVISOS
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 61
Después de realizar estas dos relaciones, debemos poner dos disparadores para
que tanto al consultar como al insertar datos, estos queden correctamente.
Uno de los disparadores será ON-POPULATE-DETAILS:
DECLARE
recstat VARCHAR2(20) := :System.record_status;
startitm VARCHAR2(61) := :System.cursor_item;
rel_id Relation;
BEGIN
IF ( recstat= 'NEW' or recstat = 'INSERT' ) THEN
--cuando se inserta o es nuevo el campo los demás campos de la
tabla los ponemos vacíos
GO_BLOCK ('SNAP_TABLAS_AVISOS');
Clear_Block (NO_VALIDATE);
GO_BLOCK ('SNAP_CONFIG_AVISOS');
Clear_Block (NO_VALIDATE);
GO_BLOCK ('SNAP_TIPOS_AVISOS');
RETURN;
END IF;
-- si el campo tiene valor, miramos la relación creada y sacamos
los detalles para la tabla relacionada
IF ( (:SNAP_TIPOS_AVISOS.COD_AVISO is not null) ) THEN
rel_id :=
Find_Relation('SNAP_TIPOS_AVISOS.SNAP_TIPOS_AVIS_SNAP_TABLAS_AV');
Query_Master_Details(rel_id, 'SNAP_TABLAS_AVISOS');
END IF;
IF ( :System.cursor_item <>startitm ) THEN
Go_Item(startitm);
Check_Package_Failure;
END IF;
END;
El otro disparador será ON-CHECK-DELETE-MASTER:
DECLARE
Dummy_Define CHAR(1);
CURSOR SNAP_TABLAS_AVISOS_cur IS
SELECT 1 FROM SNAP_TABLAS_AVISOS S
WHERE S.COD_AVISO = :SNAP_TIPOS_AVISOS.COD_AVISO;
BEGIN
OPEN SNAP_TABLAS_AVISOS_cur;
FETCH SNAP_TABLAS_AVISOS_cur INTO Dummy_Define;
IF ( SNAP_TABLAS_AVISOS_cur%found ) THEN
Message('No se puede borrar este registro, ya que existen detalles
sobre este dato en otras tablas.');
CLOSE SNAP_TABLAS_AVISOS_cur;
RAISE Form_Trigger_Failure;
END IF;
CLOSE SNAP_TABLAS_AVISOS_cur;
END;
Lo que se consigue con este disparador es no poder borrar el registro de la
tabla si existen detalles en la tabla relacionada.
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 62
Además de estos disparadores y relaciones, se han creado cuatro listas de
valores para que aparezcan en los campos de la tabla SNAP_TABLAS_AVISOS.
En la siguiente imagen se pueden ver las cuatro listas de valores y a los campos
que se relaciona.
Estos ‘Lovs’ creados lo que hacen es ir a una consulta realizada en sql para que
estando en la pantalla y pulsando dos veces en el campo en cuestión aparezca
un desplegable con los posibles valores para este campo.
LOV_TABLAS:
SELECT d.table_name as nombre,'Tabla' as tipo
FROM dba_tables d
WHERE d.owner = 'SNAP'
union all
SELECT d.view_name as nombre, 'Vista' as tipo
FROM dba_views d
WHERE d.owner = 'SNAP'
order by nombre
COLUMNAS_TABLAS
SELECT d.column_name ,
case when d.data_type = 'VARCHAR2' then 'V'
When d.data_type = 'DATE' then 'D'
when d.data_type = 'NUMBER' THEN 'N'
ELSE 'E' END AS TIPO,D.DATA_TYPE
FROM dba_tab_columns d
WHERE d.table_name = :snap_tablas_avisos.tabla_vista
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 63
VALOR_REFERENCIA
select s.tipo ,s.descripcion
from snap_descripciones s
where s.tipo_tabla = :snap_tablas_avisos.tabla_vista
COLUMNA_FECHA
SELECT d.column_name ,
case when d.data_type = 'VARCHAR2' then 'V'
When d.data_type = 'DATE' then 'D'
whend.data_type = 'NUMBER' THEN 'N'
ELSE 'E' END AS TIPO,D.DATA_TYPE
FROM dba_tab_columns d
WHERE d.table_name = :snap_tablas_avisos.tabla_vista
Destacar que la consulta para el campo de Campo como referencia y Campo de
la fecha, que son los lovs COLUMNAS_TABLAS y COLUMNA_FECHA, son la
misma consulta sql. Con la salvedad que en el lov de COLUMNA_FECHA, cuando
se selecciona la columna, el tipo devuelto se graba en el campo TIPO_FECHA,
de la tabla SNAP_TABLAS_AVISOS.
A continuación mostramos el ejemplo de cómo quedaría al pulsar dos veces en
el campo Tabla/Vista.
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 64
II. Pestaña de Administración GFH’s Responsables
Después de esta pestaña, pasamos a la de Administracion GFHs Responsables,
en esta pestaña, aparecen los datos de las tablas SNAP_GFHS y
SNAP_RESP_GFH, estas dos tablas tienen una relación por el campo GFH. A
continuación mostramos la realción de cada campo de la tabla con su ubicación
en la pantalla.
Como se puede observar existe la relación entre las tablas, denominada
SNAP_GFHS_SNAP_RESP_GFH, con los dos disparadores explicados en la
anterior pestaña ON-CHECK-DELETE-MASTER y ON-POPULATE-DETAILS. Además
la tabla SNAP_RESP_GFH hay un disparador POST-QUERY que tiene el siguiente
código:
DECLARE
V_NOMBRE VARCHAR2(80);
V_EMAIL VARCHAR2(30);
BEGIN
select s.apellidos ||', '||s.nombre,s.email INTO
V_nombre,V_EMAIL
from snap_empleados s
WHERE S.CODIGO_EMPLEADO=:SNAP_RESP_GFH.COD_RESP;
:SNAP_RESP_GFH.NOMBRE_RESP:=V_nombre;
:SNAP_RESP_GFH.E_MAIL:=V_EMAIL;
END;
Esto es debido a que aunque se muestre el nombre y email de los empleados,
en realidad la tabla sólo tiene el GFH y el COD_RESP, y gracias a este
disparador, al ejecutar esta tabla, se muestran los nombres y los emails de las
personas accediendo a la tabla de SNAP_EMPLEADOS.
En esta tabla también tenemos una lista de valores para el campo Cod_Resp,
este lov contiene la siguiente consulta sql:
select s.codigo_empleado ,s.apellidos ||', '||s.nombre
as nombre,s.email
from snap_empleados s
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 65
III. Pestaña Avisos gfh
La última pestaña de esta pantalla es la de Avisos gfh, se muestran los datos de
la vista SNAP_AVIS_GHF_VW, en la imagen se muestra la realción entre los
campos de la vista y la pantalla.
Como se puede observar los campos de la vista APLIC, INTRANET y CORREO, no
se muestran en la pantalla, son unos campos fuera de la vista, que son V_APLIC,
V_INTRANET y V_CORREO, los que realmente se muestran en forma de
marcador. Para ello lo que hacemos es que cuando el campo de la vista cambia,
es decir, cambia de desmarcado a marcado, un disparador POST-CHANGE, lanza
un procedimiento por el que el campo en cuestíon pone el V_CAMPO a
marcado. Por ejemplo el código del POST-CHANGE del campo APLIC es el
siguiente:
:SNAP_AVIS_GHF_VW.V_APLIC:=:SNAP_AVIS_GHF_VW.APLIC;
Después de visualizar los datos, y tener en pantalla los diferentes avisos con su
gfhs y tipos de avisos correspondientes, podremos marcar y desmarcar los
campos que queramos. Pero al hacerlo se activaran los disparadores en cada
caso, por ejemplo al marcar o desmarcar el campo V_APLIC, se activará el
disparador WHEN-MOUSE-CLICK que realizará lo siguiente:
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 66
Declare
aux number;
Begin
select count(*) into aux from snap_avisos_gfh s
where s.cod_aviso = :SNAP_AVIS_GHF_VW.cod_aviso
and s.gfh = :SNAP_AVIS_GHF_VW.gfh;
if aux=1 then
if :SNAP_AVIS_GHF_VW.v_aplic = 'N'
and :SNAP_AVIS_GHF_VW.v_intranet = 'N'
and :SNAP_AVIS_GHF_VW.v_correo= 'N' then
delete from snap_avisos_gfh s
where s.cod_aviso = :SNAP_AVIS_GHF_VW.cod_aviso
and s.gfh = :SNAP_AVIS_GHF_VW.gfh;
else
update snap_avisos_gfh s
set s.aviso_aplicacion=:SNAP_AVIS_GHF_VW.v_aplic
where s.cod_aviso = :SNAP_AVIS_GHF_VW.cod_aviso
and s.gfh = :SNAP_AVIS_GHF_VW.gfh;
end if;
else
insert into snap_avisos_gfh values
(:SNAP_AVIS_GHF_VW.cod_aviso,:SNAP_AVIS_GHF_VW.gfh,'S','N','N');
end if;
silentcommit;
end;
Gracias a este disparador modificamos la tabla SNAP_AVISOS_GFH, en el caso
de no poner ningún aviso, borramos el registro entero para ese gfh y ese tipo
de aviso, si no existía lo creamos, y si ya existía, modificamos el campo del aviso
de la aplicación. Igual que este disparador es el que existen para los campos
V_INTRANET y V_CORREO.
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 67
B) Implementación de la pantalla Datos empleados y Descripciones
I. Pestaña de Empleados
En esta pantalla, la primera pestaña es la de Empleados, en ella es donde
introducimos y podemos dar de alta los diferentes empleados. En la siguiente
imagen se pueden observar las relaciones entre la tabla SNAP_EMPLEADOS y la
pantalla.
En el campo GFH, se ha puesto una lista de valores GFHS en el que la consulta
nos mostrara los gfhs que existen, con el impedimento de no poder dar de alta
un empleado en un gfh que no exista en dicha consulta.
select * from snap.snap_gfhs
II. Pestaña de Atributos
La siguiente pestaña es la de la pantalla es la de Atributos, en ella es donde
podemos configurar los diferentes atributos de los empleados, lo que se
muestra en la imagen es la relación de la pantalla con las columnas de la tabla
SNAP_ATRIBUTOS.
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 68
Como se puede observar, existen campos que no pertenecen a la tabla pero
que se muestran en la pantalla, estos son Apellidos, Nombre, Desc_Atributo,
F_INI_BIS y F_FIN_BIS. Estos campos salen calculados por los que componen la
tabla. Al ejecutar la consulta, se dispara el procedimiento POST-QUERY, que
contiene lo siguiente:
declare
aux VARCHAR2(10);
BEGIN
begin
IF :snap_atributos.FECHA_INI IS NULL THEN
aux := NULL;
ELSE
aux := TO_DATE(:snap_atributos.FECHA_INI,'J');
END IF;
:snap_atributos.f_ini_bis:=aux;
EXCEPTION
WHEN others THEN NULL;
end;
begin
IF :snap_atributos.FECHA_FIN IS NULL THEN
aux := NULL;
ELSE
aux := TO_DATE(:snap_atributos.FECHA_FIN,'J');
END IF;
:snap_atributos.f_fin_bis:=aux;
EXCEPTION
WHEN others THEN NULL;
end;
begin
select s.descripcion INTO
:SNAP_ATRIBUTOS.DESC_ATRIBUTO
from snap.SNAP_DESCRIPCIONES s
where s.tipo_tabla = 'SNAP_ATRIBUTOS'
and s.tipo = :SNAP_ATRIBUTOS.TIPO_ATRIBUTO;
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 69
EXCEPTION
WHEN others THEN
NULL;
end;
begin
select s.apellidos,s.nombre
INTO :SNAP_ATRIBUTOS.apellidos,:SNAP_ATRIBUTOS.nombre
from snap.SNAP_EMPLEADOS S
where s.codigo_empleado =
:SNAP_ATRIBUTOS.cod_empleado;
EXCEPTION
WHEN others THEN NULL;
end;
END;
Gracias a este disparador, al ejecutar esta pantalla se rellenan los campos que
no están en la tabla. Además de este disparador, podemos observar que
existen tres disparadores, pero en nivel de “ítems”.
Para el COD_EMPLEADO tenemos el disparador WHEN-VALIDATE-ITEM, que se
ejecuta al validar los datos que se introducen en este campo, el código es el
siguiente y sirve para rellanar los daos de Apellidos y Nombre.
Begin
select s.apellidos ,s.nombre
into :snap_atributos.apellidos,:snap_atributos.nombre
from snap.snap_empleados s
where s.codigo_empleado =
:snap_atributos.cod_empleado;
exception when others then
null;
end;
Otro de los disparadores es el que tiene el campo F_INI_BIS, que se ejecuta
cuando introducimos un valor en él, este disparador lo que realiza es una
validación para no poder dejar en blanco la fecha de inicio, ni que ésta sea
mayor que la fecha fin. Si es correcta, se introduce en la columna FECHA_INI de
la tabla SNAP_ATRIBUTOS.
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 70
declare
aux VARCHAR2(10);
BEGIN
if(:snap_atributos.f_fin_bis is not null
AND :snap_atributos.f_fin_bis<:snap_atributos.f_ini_bis)
OR :snap_atributos.f_ini_bis IS NULL then
PROC_MENSAJE_ALERTA('La fecha de inicio no puede ser
nula ni mayor que la fecha fin.', 'E', true);
else
aux := TO_NUMBER(TO_CHAR(:snap_atributos.f_ini_bis,'J'));
if nvl(aux,1)<>nvl(:snap_atributos.FECHA_INI,1) then
:snap_atributos.FECHA_INI:=aux;
end if;
end if;
end;
El disparador de F_FIN_BIS lo que hace es comprobar que no sea menor que la
fecha de inicio, si no es así, lo graba en la columna de FECHA_FIN de la tabla
SNAP_ATRIBUTOS.
declare
aux VARCHAR2(10);
BEGIN
if :snap_atributos.f_fin_bis is not null
AND faj(:snap_atributos.f_fin_bis)<
faj(:snap_atributos.f_ini_bis) then
PROC_MENSAJE_ALERTA('La fecha fin no puede ser menor
que la fecha inicio.', 'E', true);
else
if :snap_atributos.f_fin_bis is null then
aux := null;
else
aux := TO_NUMBER(TO_CHAR(:snap_atributos.f_fin_bis,'J'));
end if;
if nvl(aux,1)<>nvl(:snap_atributos.FECHA_FIN,1) then
:snap_atributos.FECHA_FIN:=aux;
end if;
end if;
end;
Además de estos disparadores, la pantalla tiene dos listas de valores. Una de
ellas es para el COD_EMPLEADO, esta lista nos muestra todos los empleados.
select s.codigo_empleado ,s.apellidos ,s.nombre
from snap.snap_empleados s
La otra lista de valores es para sacar los tipos de atributos y sus descripciones, y
está en el campo TIPO_ATRIBUTO
select S.tipo ,s.descripcion
from snap.SNAP_DESCRIPCIONES s
where s.tipo_tabla = 'SNAP_ATRIBUTOS'
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 71
III. Pestaña de Vacaciones
La siguiente pestaña es la de vacaciones, aquí podremos configurar las
vacaciones de los empleados. En la siguiente imagen podemos ver la relación
de las columnas de la tabla con la pantalla
En la pantalla aparecen los “ítems” Apellidos, Nombre, Desc_Vacaciones,
Fecha_ini_bis y Fecha_fin_bis, que no son parte de la tabla SNAP_VACACIONES.
Estos campos se rellanan al ejecutar la consulta, ya que se ejecuta el disparador
POST-QUERY que contiene lo siguiente:
DECLARE
aux VARCHAR2(10);
BEGIN
begin
IF :snap_vacaciones.FECHA_INI IS NULL THEN
aux := NULL;
ELSE
aux := TO_DATE(:snap_vacaciones.FECHA_INI,'J');
END IF;
:snap_vacaciones.f_ini_bis:=aux;
EXCEPTION
WHEN others THEN
NULL;
end;
begin
IF :snap_vacaciones.FECHA_FIN IS NULL THEN
aux := NULL;
ELSE
aux := TO_DATE(:snap_vacaciones.FECHA_FIN,'J');
END IF;
:snap_vacaciones.f_fin_bis:=aux;
EXCEPTION
WHEN others THEN
NULL;
end;
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 72
begin
select s.descripcion INTO :SNAP_VACACIONES.DESC_VACACIONES
from snap.SNAP_DESCRIPCIONES s
where s.tipo_tabla = 'SNAP_VACACIONES'
and s.tipo = :SNAP_VACACIONES.TIPO_VAC;
EXCEPTION
WHEN others THEN
NULL;
end;
begin
select s.apellidos,s.nombre
INTO :SNAP_VACACIONES.apellidos,:SNAP_VACACIONES.nombre
from snap.SNAP_EMPLEADOS S
where s.codigo_empleado =
:SNAP_VACACIONES.cod_empleado;
EXCEPTION
WHEN others THEN
NULL;
end;
END;
Gracias a este disparador, se rellenan los campos que no son propiamente de la
tabla. Además de este disparador, tenemos a nivel de “ítems” un WHEN-
VALIDATE-ITEM en el COD_EMPLEADO, con el siguiente código.
begin
select s.apellidos ,s.nombre into
:snap_vacaciones.apellidos,:snap_vacaciones.nombre
from snap.snap_empleados s where s.codigo_empleado =
:snap_vacaciones.cod_empleado;
exception when others then null;
end;
Por medio de este proceso, se cargaran los apellidos y nombres en la pantalla,
cuando introduzcamos un código. Si en vez de introducirlo, damos doble
“click”, nos aparecerá una lista de valores. Esta lista de valores la componen los
datos que aparecerán al ejecutar la siguiente consulta.
select s.codigo_empleado ,s.apellidos ,s.nombre
from snap.snap_empleados s
También tenemos una listado de valores en el campo TIPO_VAC, para que
aparezcan los siguientes datos
select s.tipo ,s.descripcion from snap.SNAP_DESCRIPCIONES s
where s.tipo_tabla = 'SNAP_VACACIONES'
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 73
Tanto en la FECHA_INI_BIS, como en la FECHA_FIN_BIS, existen los
disparadores exactamente iguales al que había en la pestaña de atributos.
Gracias a ellos se mira que la fecha de inicio no sea nula ni superior a la fecha
de fin, y que la fecha fin no sea inferior a la fecha de inicio.
IV. Pestaña de Bajas
En la siguiente pestaña se pueden consultar y administrar las posibles bajas de
los empleados. En la siguiente imagen se pueden observar las relaciones
existentes entre los campos de la tabla y los de la pantalla.
En esta pantalla aparecen los “ítems” Apellidos, Nombre, Desc_Baja,
Fecha_ini_bis y Fecha_fin_bis, que no son parte de la tabla SNAP_BAJAS. Estos
campos se rellanan al ejecutar la consulta, ya que se ejecuta el disparador
POST-QUERY que contiene lo siguiente:
DECLARE
aux date;
BEGIN
begin
IF :snap_bajas.FECHA_INI IS NULL THEN
aux := NULL;
ELSE
aux := :snap_bajas.FECHA_INI;
END IF;
:snap_bajas.f_ini_bis:=aux;
EXCEPTION
WHEN others THEN
NULL;
end;
begin
IF :snap_bajas.FECHA_FIN IS NULL THEN
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 74
aux := NULL;
ELSE
aux := :snap_bajas.FECHA_FIN;
END IF;
:snap_bajas.f_fin_bis:=aux;
EXCEPTION
WHEN others THEN
NULL;
end;
begin
select s.descripcion INTO :SNAP_BAJAS.DESC_BAJA from
snap.SNAP_DESCRIPCIONES s
where s.tipo_tabla = 'SNAP_BAJAS'
and s.tipo = :SNAP_BAJAS.TIPO_BAJA;
EXCEPTION
WHEN others THEN
NULL;
end;
begin
select s.apellidos,s.nombre INTO
:SNAP_BAJAS.apellidos,:SNAP_BAJAS.nombre
from snap.SNAP_EMPLEADOS S
where s.codigo_empleado = :SNAP_BAJAS.cod_empleado;
EXCEPTION
WHEN others THEN
NULL;
end;
END;
Gracias a este código, se rellenan los campos que no pertenecen a la tabla, pero
que sí están en la pantalla. Además de este disparador, tenemos en el “ítem”
COD_EMPLEADO un WHEN-VALIDATE-ITEM con el siguiente código.
begin
select s.apellidos ,s.nombre into
:SNAP_BAJAS.apellidos,:SNAP_BAJAS.nombre
from snap.snap_empleados s
where s.codigo_empleado = :SNAP_BAJAS.cod_empleado;
exception when others then null;
end;
Además de este disparador para rellenar los datos si introducimos el código del
empleado, tenemos también una lista de valores con los datos resultantes de la
siguiente consulta.
select s.codigo_empleado ,s.apellidos ,s.nombre
from snap.snap_empleados s
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 75
Tenemos una lista de valores en el campo TIPO_BAJA, que nos mostrará los
datos de la siguiente consulta.
select s.tipo ,s.descripcion from snap.SNAP_DESCRIPCIONES s
where s.tipo_tabla = 'SNAP_BAJAS'
También tenemos en el “ítem” F_INI_BIS, el disparador WHEN-VALIDATE-ITEM
con el siguiente código.
declare
aux date;
BEGIN
if (:snap_bajas.f_fin_bis is not null AND
:snap_bajas.f_fin_bis<:snap_bajas.f_ini_bis)
OR :snap_bajas.f_ini_bis IS NULL then
PROC_MENSAJE_ALERTA('La fecha de inicio no puede ser
nula ni mayor que la fecha fin.', 'E', true);
else
aux := :snap_bajas.f_ini_bis;
ifnvl(aux,to_date('01/01/1900','dd/mm/yyyy'))<>nvl(:snap_baja
s.FECHA_INI,to_date('01/01/1900','dd/mm/yyyy')) then
:snap_bajas.FECHA_INI:=aux;
end if;
end if;
end;
Gracias a este disparador actualizamos el campo de la tabla y miramos si la
fecha inicio no es nula ni es superior a la fecha fin. Por último tenemos el
WHEN-VALIDATE-ITEM del campo F_FIN_BIS, que contiene lo siguiente.
declare
aux date;
BEGIN
if :snap_bajas.f_fin_bis is not null AND
:snap_bajas.f_fin_bis<:snap_bajas.f_ini_bis then
PROC_MENSAJE_ALERTA('La fecha fin no puede ser menor
que la fecha inicio.', 'E', true);
else
if :snap_bajas.f_fin_bis is null then
aux := null;
else
aux := :snap_bajas.f_fin_bis;
end if;
if
nvl(aux,to_date('01/01/1900','dd/mm/yyyy'))<>nvl(:snap_bajas.
FECHA_FIN,to_date('01/01/1900','dd/mm/yyyy')) then
:snap_bajas.FECHA_FIN:=aux;
end if;
end if;
end;
Gracias a este código se controla que la fecha fin no sea inferior a la fecha de
inicio.
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 76
V. Pestaña de Descripciones
Por último tenemos la pestaña de las Descripciones, en la siguiente imagen se
pueden ver las relaciones entre los campos de la tabla y la pantalla.
El campo TIPO_TABLA, tiene asociado una listad de valores en los que parecen
los datos de la siguiente consulta.
select 'SNAP_VACACIONES' AS TIPO_TABLA
from dual
UNION ALL
select 'SNAP_BAJAS' AS TIPO_TABLA
from dual
UNION ALL
select 'SNAP_ATRIBUTOS' AS TIPO_TABLA
from dual
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 77
C) Implementación de la pantalla Configuración de avisos
En esta pantalla en la que se utiliza para poder consultar los avisos que se han
realizado. Por una parte tenemos en la parte superior los datos para el filtro,
más tres botones para distintos fines. En la siguiente imagen podemos ver la
relación entre ellos.
En el campo F_GFH, tendremos una lista de valores que la compondrán los
datos de la siguiente consulta.
SELECT G.gfh FROM SNAP_RESP_GFH G
WHERE G.cod_resp =
(SELECT S.codigo_empleado FROM SNAP_EMPLEADOS S
WHERE S.usuario = USER)
De esta forma sólo se podrán seleccionar gfhs de los que el usuario sea
responsable
En el campo F_COD_AVISO, también tendremos una lista de valores que
ejecutará la siguiente consulta.
select distinct s.cod_aviso
from snap_avisos_union_vw s
where s.aviso_aplicacion = 'S'
and nvl(:filtro.f_gfh,s.gfh)=s.gfh
and s.gfh in (SELECT G.gfh FROM SNAP_RESP_GFH G
WHERE G.cod_resp = (SELECT S.codigo_empleado
FROM SNAP_EMPLEADOS S
WHERE S.usuario = USER))
Gracias a esta consulta, sólo se podrán mirar los avisos de un gfh en el que el
usuario sea responsable y el aviso este activo para verlo en la aplicación.
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 78
Antes de explicar los procesos de cada botón, miraremos los demás campos de
la pantalla.
En la pantalla tenemos los cuatro campos que nos sirven para poder ordenar
tanto la consulta ejecutada en esta pantalla, como si lo imprimimos.
Estos campos contienen una lista de valores que se cargan en el disparador al
iniciar la pantalla (WHEN_NEW_FORM_INSTANCE). Es código es el siguiente.
declare
registroGrupoValores recordgroup;
V_errorcode number;
begin
-- Inicialización de valores posibles que puede tener el
campo de los filtros
registroGrupoValores := find_group('v_filtro');
if id_null(registroGrupoValores) then
registroGrupoValores := create_group_from_query('v_filtro',
'SELECT ''GFH'' COL1, ''GFH'' COL2 from dual
union all
SELECT ''Código Aviso'' COL1, ''COD_AVISO'' COL2 from dual
union all
SELECT ''Fecha en la que se realiza el Aviso'' COL1,
''FECHA_AVISO'' COL2 from dual
union all
SELECT ''Fecha en la que ocurre el Aviso'' COL1, ''FECHA''
COL2 from dual
union all
SELECT ''Código Empleado'' COL1, ''COD_EMPLEADO'' COL2
from dual');
v_errorcode := populate_group(registroGrupoValores);
end if;
populate_list('orden.orden1',registroGrupoValores);
populate_list('orden.orden2',registroGrupoValores);
populate_list('orden.orden3',registroGrupoValores);
populate_list('orden.orden4',registroGrupoValores);
end;
De esta forma tendremos los valores Gfh, Cod_aviso, fecha_aviso, fecha y
cod_empleado, que saldrán en los desplegables de los cuatro campos para el
orden.
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 79
Luego tenemos en la pantalla los datos que los empleados con sus avisos que
cumplen los requisitos del filtro y de la ordenación. A continuación mostramos
la relación de la tabla SNAP_EMPLEADOS_AVISOS con los campos de la pantalla.
Los campos Apellidos_Nombre, Descripcion_aviso, Fecha_aviso_f y Fecha_f no
forman parte de las columnas de la tabla SNAP_EMPLEADOS_AVISOS, pero se
añaden para la mejor comprensión de los datos. Estas columnas se rellenan con
el código del disparador POST-QUERY, que contiene lo siguiente.
declare
v_ape varchar2(200);
v_desc_aviso varchar2(300);
v_fecha_avio_f date;
v_fecha_f date;
begin
select s.apellidos ||', '||s.nombre
into v_ape
from snap_empleados s
where s.codigo_empleado = :SNAP_EMPLEADOS_AVISOS.COD_EMPLEADO;
:SNAP_EMPLEADOS_AVISOS.APELLIDOS_NOMBRE:=v_ape;
select s.descripcion into v_desc_aviso
from snap_tipos_avisos s
where s.cod_aviso = :SNAP_EMPLEADOS_AVISOS.COD_AVISO;
:SNAP_EMPLEADOS_AVISOS.DESC_AVISO:=v_desc_aviso;
select to_date(:SNAP_EMPLEADOS_AVISOS.FECHA_AVISO,'J')
into v_fecha_avio_f from dual;
:SNAP_EMPLEADOS_AVISOS.FECHA_AVISO_F:=v_fecha_avio_f;
select to_date(:SNAP_EMPLEADOS_AVISOS.FECHA,'J') into v_fecha_f
from dual;
:SNAP_EMPLEADOS_AVISOS.FECHA_F:=v_fecha_f;
end;
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 80
De esta forma los apartados que no formaban parte de la tabla, se rellenan con
los datos correctos para ser visualizados.
Pasamos ahora a describir lo que realizan cada uno de los botones. El primero
es el botón de consultar, este botón nos servirá para ejecutar el filtro y la
ordenación seleccionada y que aparezcan los datos en la parte inferior.
El código al pulsar este botón es el siguiente.
BEGIN
GO_BLOCK('SNAP_EMPLEADOS_AVISOS');
SET_BLOCK_PROPERTY
('SNAP_EMPLEADOS_AVISOS',ORDER_BY,fun_orden);
set_block_property
('SNAP_EMPLEADOS_AVISOS',DEFAULT_WHERE,fun_where);
EXECUTE_QUERY;
END;
Lo que realiza este código, es ir al bloque de los datos de los avisos, cambiar las
propiedades de ordenación llamando a la función fun_orden y luego las
propiedades del “where” y poner lo que devuelve la función fun_where.
La función fun_orden realiza lo siguiente.
FUNCTION fun_orden RETURN varchar2 IS
V_ORDEN VARCHAR2(2000);
BEGIN
IF :ORDEN.ORDEN1 IS NOT NULL THEN
V_ORDEN:=:ORDEN.ORDEN1;
IF :ORDEN.ORDEN2IS NOT NULL THEN
V_ORDEN:= V_ORDEN||','||:ORDEN.ORDEN2;
IF :ORDEN.ORDEN3IS NOT NULL THEN
V_ORDEN:= V_ORDEN||','||:ORDEN.ORDEN3;
IF :ORDEN.ORDEN4IS NOT NULL THEN
V_ORDEN:=V_ORDEN||','||:ORDEN.ORDEN4;
END IF;
END IF;
END IF;
END IF;
return(V_ORDEN);
END;
De esta forma va concatenando los diferentes valores de los campos de
ordenación para luego ejecutar la consulta.
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 81
La función fun_where, tiene el siguiente código.
FUNCTION fun_where RETURN varchar2 IS
V_where VARCHAR2(2000);
BEGIN
v_where:='GFH IN (SELECT G.gfh FROM SNAP_RESP_GFH G
WHERE G.cod_resp = (SELECT S.codigo_empleado
FROM SNAP_EMPLEADOS S WHERE S.usuario = USER))';
v_where:=v_where||' and NVL(:FILTRO.F_GFH,GFH)=GFH';
v_where:=v_where||
' AND NVL(:FILTRO.F_COD_AVISO,COD_AVISO)=COD_AVISO';
v_where:=v_where||' AND NVL(TO_NUMBER(TO_CHAR
(:FILTRO.F_FECHA_DESDE_F_AVISO,''J'')),FECHA_AVISO)<=
FECHA_AVISO';
v_where:=v_where||' AND NVL(TO_NUMBER(TO_CHAR
(:FILTRO.F_FECHA_HASTA_F_AVISO,''J'')),FECHA_AVISO)>=
FECHA_AVISO';
v_where:=v_where||' AND NVL(TO_NUMBER(TO_CHAR
(:FILTRO.F_FECHA_DESDE_FECH_OCU,''J'')),FECHA)<=
FECHA';
v_where:=v_where||' AND NVL(TO_NUMBER(TO_CHAR
(:FILTRO.F_FECHA_HASTA_FECH_OCU,''J'')),FECHA)>=
FECHA';
v_where:=v_where||' and avis_aplicacion=''S''';
return(v_where);
END;
Lo que hacemos concatenar para el “where”, si es responsable del gfh y luego si
tiene rellenado algún campo de la parte de filtro, añadirla. Por último ver si
tenía activo para que se pueda visualizar ese aviso en la aplicación.
El botón limpiar tiene la función de borrar de la pantalla todos los datos que se
encuentren rellenados. Ejecuta el siguiente código.
begin
Go_Block('SNAP_EMPLEADOS_AVISOS');
Clear_Block(NO_VALIDATE);
GO_BLOCK ('ORDEN');
Clear_Block (NO_VALIDATE);
GO_BLOCK ('FILTRO');
Clear_Block (NO_VALIDATE);
end;
De esta forma todos los campos quedan vacíos.
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 82
Por último está el botón de Imprimir, que lo que realizará es una llamada al
“Report” para poder imprimir los datos. Contiene el siguiente código.
BEGIN
SELECT TO_NUMBER(TO_CHAR(:FILTRO.F_FECHA_DESDE_F_AVISO,'J'))
INTO V_FECHA_DESDE_AVISO FROM DUAL;
SELECT TO_NUMBER(TO_CHAR(:FILTRO.F_FECHA_HASTA_F_AVISO,'J'))
INTO V_FECHA_HASTA_AVISO FROM DUAL;
SELECT TO_NUMBER(TO_CHAR(:FILTRO.F_FECHA_DESDE_FECH_OCU,'J'))
INTO V_FECHA_DESDE_OCU FROM DUAL;
SELECT TO_NUMBER(TO_CHAR(:FILTRO.F_FECHA_HASTA_FECH_OCU,'J'))
INTO V_FECHA_HASTA_OCU FROM DUAL;
if fun_orden is null then
v_orden:= 'order by rownum';
else
v_orden:= 'order by '||fun_orden;
end if;
-- Crea o Destruye la lista de Parámetros
VListaParams :=GET_PARAMETER_LIST('parametros');
IF NOT ID_NULL(VListaParams) THEN
DESTROY_PARAMETER_LIST(VListaParams);
END IF;
VListaParams := CREATE_PARAMETER_LIST('parametros');
-- Añade los parámetros necesarios
ADD_PARAMETER(VListaParams,
'PRM_orden', TEXT_PARAMETER, v_orden);
ADD_PARAMETER(VListaParams,
'PRM_GFH', TEXT_PARAMETER, :FILTRO.F_GFH);
ADD_PARAMETER(VListaParams,
'PRM_COD_AVISO', TEXT_PARAMETER, :FILTRO.F_COD_AVISO);
ADD_PARAMETER(VListaParams,
'PRM_FECHA_DESDE_AVISO',TEXT_PARAMETER, JAC(V_FECHA_DESDE_AVISO));
ADD_PARAMETER(VListaParams,
'PRM_FECHA_HASTA_AVISO',TEXT_PARAMETER,JAC(V_FECHA_HASTA_AVISO));
ADD_PARAMETER(VListaParams,
'PRM_FECHA_DESDE_OCU', TEXT_PARAMETER, JAC(V_FECHA_DESDE_OCU));
ADD_PARAMETER(VListaParams,
'PRM_FECHA_HASTA_OCU', TEXT_PARAMETER, JAC(V_FECHA_HASTA_OCU));
ADD_PARAMETER(VListaParams,
'PRM_orden2', TEXT_PARAMETER, fun_orden2);
RUN_PRODUCT(REPORTS,'avisos.rep', ASYNCHRONOUS, RUNTIME,
FILESYSTEM, VListaParams, NULL);
END;
Con este código se llama al report avisos.rep, con la lista de parámetros que
hay en el filtro y también con el orden establecido.
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 83
D) Implementación del report Avisos
El report avisos, es donde podremos ver los datos que hemos ejecutado desde
la pantalla de Visualización de avisos pulsando el botón imprimir.
Lo primero que haremos es introducir los campos que pasamos como
parámetro al report. Para ello los configuraremos en el apartado de User
parameters, gracias a esto luego los podremos utilizar.
Después configuraremos la consulta (query) introduciendo lo siguiente.
select s.cod_empleado ,
(select ss.apellidos ||', '||ss.nombre from snap_empleados ss
where ss.codigo_empleado = s.cod_empleado )as Apellidos_nombre,
s.cod_aviso ,
(select ss.descripcion from snap_tipos_avisos ss
where ss.cod_aviso = s.COD_AVISO)as Descripcion_aviso,
s.gfh, to_date(s.FECHA_AVISO,'J') as F_realiza_Aviso,
to_date(s.FECHA,'J') as F_ocurre_aviso
from SNAP_EMPLEADOS_AVISOS s
where GFH IN (SELECT G.gfh FROM SNAP_RESP_GFH G
WHERE G.cod_resp = (SELECT Ss.codigo_empleado
FROM SNAP_EMPLEADOS Ss
WHERE Ss.usuario = USER))
and NVL(:PRM_GFH,s.GFH)=s.GFH
AND NVL(:PRM_COD_AVISO,S.COD_AVISO)=S.COD_AVISO
AND NVL(CAJ(:PRM_FECHA_DESDE_AVISO),S.FECHA_AVISO)<=S.FECHA_AVISO
AND NVL(CAJ(:PRM_FECHA_HASTA_AVISO),S.FECHA_AVISO)>=S.FECHA_AVISO
AND NVL(CAJ(:PRM_FECHA_DESDE_OCU),S.FECHA)<=S.FECHA
AND NVL(CAJ(:PRM_FECHA_HASTA_OCU),S.FECHA)>=S.FECHA
and avis_aplicacion='S'
&PRM_ORDEN
De esta forma ya tendremos los datos para poderlos introducir en el informe.
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 84
En la siguiente imagen se muestra los diferentes bloques de datos creados y los
datos que tiene cada uno de ellos.
El bloque M_1, contiene los datos de la parte de los datos sobre el filtro.
El bloque M_2, contiene los datos pasados sobre la ordenación de los datos.
El bloque M_G_COD_EMPLEADO_GRPFR, contiene a su vez dos bloques.
El bloque M_G_COD_EMPLEADO_HDR, que está dentro del anterior bloque,
sirve de cabecera para los siguientes datos, y sólo contiene el texto para la
descripción de cada columna.
El bloque R_G_COD_EMPLEADO, es el que realmente tiene los datos ejecutados
de la consulta, y los muestra en este bloque que se puede alargar ya que está
definido de esta forma. Los otros bloques eran de tamaño fijo y no se podían
expandir, pero este se puede expandir hasta que no contenga más datos.
Fuera de estos datos del “body” del report, también tenemos datos como el
número de página y la fecha de ejecución. Estos están definidos en el “Margin”
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 85
Donde el F_11 tiene en el código lo siguiente.
El F_1, tiene lo siguiente.
El F_2 tiene lo siguiente.
Sistema de notificación de avisos para eventos programables
Construcción
Universidad de La Rioja Página 86
4.5) Documentación y manuales
En esta parte de la memoria es donde describiremos la diferente
documentación y manuales. Dichos manuales irán orientados para los usuarios
especializados que llevaran a cabo la instalación, los usuarios que mantendrán
la aplicación y los propios usuarios de la misma.
Los documentes que tendremos son los siguientes:
Anexo I. Manual sobre despliegue e instalación
Anexo II. Manual para administrar la aplicación
Anexo III. Manual para los usuarios de la aplicación
Dichos anexos están incluidos en la parte final de este documento.
Sistema de notificación de avisos para eventos programables
Pruebas
Universidad de La Rioja Página 87
5. Pruebas
Sistema de notificación de avisos para eventos programables
Pruebas
Universidad de La Rioja Página 88
5.1) Pruebas de inserción de datos
Se realizan pruebas de inserción en las diferentes pantallas de la aplicación
A) Pantalla de Configuración de empleados
En esta pantalla se han introducido satisfactoriamente los siguientes datos:
Un empleado, teniendo que existir el gfh con el que se graba.
Un atributo para un empleado, teniendo en cuenta que el empleado
debe existir, el tipo de atributo también, y si tiene fecha fin el atributo,
ésta debe ser mayor o igual a la fecha inicio.
Unas vacaciones para un empleados, teniendo en cuenta que el
empleado y el tipo de vacación debían existir, y que la fecha hasta debía
ser igual o mayor a la fecha desde
Una baja a un empleado, el empleado y la baja deben existir, y la fecha
hasta de la baja, debe ser mayor o igual a la desde.
Un tipo de atributo nuevo, éste no debía existir con el mismo código
Un tipo de vacación, este tipo no debía existir.
Un tipo de baja nuevo, éste tipo de baja no debía existir.
B) Pantalla de Configuración de avisos
En esta pantalla hemos insertado de forma satisfactoria los siguientes datos:
Un tipo de aviso nuevo, con su descripción corta, larga, a la tabla que
hacer referencia, las columnas a las que tienen que acceder y los días
oportunos para la realización de los avisos.
Un gfh nuevo, con su descripción
Un nuevo responsable para un gfh, el gfh debía existir, y el empleado
también.
Activar para que se realice el aviso por aplicación de un determinado
evento y gfh
Activar para que se realice el aviso por la intranet de un determinado
evento y gfh
Activar para que se realice el aviso por correo electrónico de un
determinado evento y gfh
C) Pantalla de Visualización de avisos
En esta pantalla no se pueden insertar datos, ya que sólo existe para la
visualización de los datos, no se pueden guardar datos.
Sistema de notificación de avisos para eventos programables
Pruebas
Universidad de La Rioja Página 89
5.2) Pruebas de borrado de datos
Se realizan pruebas de borrado de datos en las siguientes pantallas.
A) Pantalla de Configuración de empleados
En esta pantalla se han borrado satisfactoriamente los siguientes datos:
Un empleado, teniendo en cuenta que no puede tener ningún atributo,
vacación o baja. Tampoco ser responsable de un gfh.
Un atributo para un empleado determinado.
Unas vacaciones para un empleado determinado.
Una baja a un empleado determinado.
Un tipo de atributo creado.
Un tipo de vacación creado.
Un tipo de baja creado.
B) Pantalla de Configuración de avisos
En esta pantalla se han eliminado de forma satisfactoria los siguientes datos:
Un tipo de aviso cuando se haya borrado los días para realizar los avisos
y la configuración de la tabla y columnas a las que accede.
Las tablas y columnas a las que accede un aviso, siempre y cuando no
exista una configuración de días para dicho aviso.
Los días para realizar los avisos, siempre y cuando no este activo ningún
tipo aviso de ningún gfh sobre este aviso.
Un gfh, siempre y cuando no tenga ningún responsable, no exista
ningún tipo de aviso activo para este gfh, y no lo tenga ningún
empleado.
Un responsable de un gfh.
Desactivar para que no se realice el aviso por aplicación de un
determinado evento y gfh
Desactivar para que no se realice el aviso por aplicación de un
determinado evento y gfh
Desactivar para que no se realice el aviso por aplicación de un
determinado evento y gfh
C) Pantalla de Visualización de avisos
En esta pantalla no se pueden eliminar datos, ya que sólo existe para la
visualización de los datos, no se pueden borrar.
Sistema de notificación de avisos para eventos programables
Pruebas
Universidad de La Rioja Página 90
5.3) Pruebas de consulta de datos
Se realizan pruebas de consulta de datos en las siguientes pantallas.
A) Pantalla de Configuración de empleados
En esta pantalla se han consultado satisfactoriamente los siguientes datos:
Un empleado en concreto, consultando su código de empleado.
Un empleado consultando sus apellidos.
Un grupo de empleados consultando el campo “nombre”
Un empleado consultando el campo “email”.
Un empleado consultando el campo “usuario”.
Un grupo de empleados consultando el campo “gfh”
Los atributos de un empleado en concreto consultando el campo
“código_empleado”
Los tipos de atributos de un grupo de empleados consultando el campo
“tipo_atributo”
Los empleados y atributos con el inicio consultado en el campo
“fecha_inicio”
Los empleados y atributos con el fin consultado en el campo “fecha_fin”
Los empleados con el mismo valor en un atributo consultando el campo
“valor”
Las vacaciones de un empleado en concreto consultando el campo
“código_empleado”
Los tipos de vacaciones de un grupo de empleados consultando el
campo “tipo_vacacion”
Los empleados y vacaciones con el inicio consultado en el campo
“desde”
Los empleados y vacaciones con el fin consultado en el campo “hasta”
Las bajas de un empleado en concreto consultando el campo
“código_empleado”
Los tipos de bajas de un grupo de empleados consultando el campo
“tipo_baja”
Los empleados y bajas con el inicio consultado en el campo “desde”
Los empleados y bajas con el fin consultado en el campo “hasta”
Las tipos de atributos consultando el tipo de tabla “SNAP_ATRIBUTOS”.
Las tipos de vacaciones consultando el tipo de tabla
“SNAP_VACACIONES”.
Las tipos de bajas consultando el tipo de tabla “SNAP_BAJAS”.
Sistema de notificación de avisos para eventos programables
Pruebas
Universidad de La Rioja Página 91
B) Pantalla de Configuración de avisos
En esta pantalla hemos consultado de forma satisfactoria los siguientes datos:
Un tipo de aviso en concreto.
Un gfh determinado.
Un responsable dentro de un gfh ya consultado.
Los tipos avisos que tiene un determinado gfh.
Los tipos avisos que tiene un determinado evento.
C) Pantalla de Visualización de avisos
En esta pantalla es donde se pueden consultar tanto en pantalla directa, como
en un informe los avisos que han tenido lugar. Para ello se pueden consultar
filtrándolos por:
Gfh
Código de aviso
Fecha entre la que se realizó el aviso
Fecha entre la que ocurrió realmente el aviso
Para la consulta de estos datos, los podemos ordenar por orden de:
Gfh
Código de aviso
Fecha en la que se realiza el aviso
Fecha en la que realmente ocurre el aviso
Código de empleado
5.4) Pruebas de funcionamiento de la aplicación
Se han dado de alta datos para que al lanzar el procedimiento para la
inserción en la tabla de avisos a realizar, se pusieran datos.
También resultó de forma satisfactoria el envío por correo electrónico de
dicho aviso para el evento programado que se había dado de alta.
Sistema de notificación de avisos para eventos programables
Gestión del Proyecto
Universidad de La Rioja Página 92
6. Gestión del Proyecto
Sistema de notificación de avisos para eventos programables
Gestión del Proyecto
Universidad de La Rioja Página 93
6.1) Duración real de las tareas
En la siguiente tabla se muestra la duración estimada de las diferentes tareas,
junto con la duración real, la diferencia de horas y su diferencia en porcentaje.
Tarea Duración estimada
Duración real
Diferencia en horas
Diferencia en porcentaje
A) Dirección y Gestión 118 188 +70 +59,32%
A1) Reuniones 10 8 -2 -20%
A2) Creación del DOP 16 25 +9 +56,25%
A3) Identificación de Requisito 10 15 +5 +50%
A4) Seguimiento 17 20 +3 +17,65%
A5) Creación de la Memoria 45 80 +35 +77,78%
A6) Preparación de la defensa 20
B) Análisis 26 34 +8 +30,77%
B1) Análisis Previo 7 7 0 0%
B2) Análisis tecnológico 7 7 0 0%
B3) Análisis estructural 12 20 +8 +66,67%
C) Diseño 15 45 +30 +200%
C1) Diseño de la BBDD 5 15 +10 +200%
C2) Diseño de las interfaces 10 30 +20 +200%
D) Construcción 130 140 +10 +7,69%
D1) Construcción de la BBDD 15 20 +5 +33,33%
D2) Implementación de la lógica
80 80 0 0%
D3) Implementación de la interfaz
15 15 0 0%
D4) Documentación y manuales
20 25 +5 +25%
E) Pruebas 5 10 +5 +100%
TOTAL 294 417 +123 +41,84%
Sistema de notificación de avisos para eventos programables
Gestión del Proyecto
Universidad de La Rioja Página 94
6.2) Comparaciones de tiempos
Como se puede determinar por los datos en la tabla anterior, la estimación de
tiempos no se relaciona con la duración real de las tareas. Exceptuando en la
construcción, donde se ha tardado un 7,79% más de lo estimado, en todos los
demás apartados se ha tardado mucho más de lo estimado.
En la siguiente gráfica se puede observar la diferencia entre los tiempos
estimados y los tiempos reales para las distintas tareas.
Reseñar que todavía no se tiene la certeza de la duración para llevar a cabo la
defensa del proyecto.
0
20
40
60
80
100
120
140
160
180
200
H
o
r
a
s
Tareas
Diferencia de tiempos entre duración estimada y real
Duración estimada Duración real
Sistema de notificación de avisos para eventos programables
Gestión del Proyecto
Universidad de La Rioja Página 95
6.3) Diagrama de Gantt final
En el trascurso del proyecto que empezó en diciembre de 2010, se ha tenido un
gran periodo de tiempo en el que por circunstancias personales y laborales no
se pudo avanzar en él. Por eso separamos en un primer diagrama de Gantt las
primeras jornadas y luego en otro diagrama las últimas hasta la finalización.
Sistema de notificación de avisos para eventos programables
Gestión del Proyecto
Universidad de La Rioja Página 96
La última parte del diagrama de Gantt es el siguiente:
Sistema de notificación de avisos para eventos programables
Gestión del Proyecto
Universidad de La Rioja Página 97
6.4) Objetivos iniciales y alcanzados
El objetivo principal que era el de poder configurara determinados eventos,
para avisar a unos responsables definidos, se ha conseguido.
Gracias a las pantallas realizadas y los permisos para cada usuario, se puede
configurar un evento de una forma muy sencilla, si se tiene conocimiento sobre
las tablas de la base de datos donde está la información sobre la que queremos
realizar los avisos.
El objetivo de poder realizar el aviso de los eventos mediante correo
electrónico ha quedado totalmente cubierto.
El objetivo de poder sacar informes con los avisos en la propia aplicación,
también ha quedado totalmente cubierto.
El único aviso que no se ha podido realizar es el que informaba en la propia
intranet de la empresa. Pero ha quedado configurado, para que en posibles
mejoras se pueda avanzar y conseguir este objetivo.
Por lo tanto se puede decir que los objetivos iniciales han sido alcanzados en su
gran mayoría, pudiendo dejar todos alcanzados en posibles mejoras en la
aplicación.
Sistema de notificación de avisos para eventos programables
Conclusiones
Universidad de La Rioja Página 98
7. Conclusiones
Sistema de notificación de avisos para eventos programables
Conclusiones
Universidad de La Rioja Página 99
7.1) Conclusiones del proyecto
La realización de este proyecto ha supuesto conocer la dificultad y lo costoso de
realizar un trabajo desde cero. Aunque gracias a todos los conocimientos
adquiridos durante la carrera por las diferentes asignaturas ha resultado más
sencillo.
También señalar que al ser una aplicación realizada en un entorno de trabajo
real, se han tenido algunas dificultades añadidas. Como la de no poder elegir un
lenguaje de programación o no poder realizar un diseño de interfaces libre si no
teniendo que seguir unos estándares. Pero al mismo tiempo se han tenido las
ventajas del conocimiento sobre cómo realizar determinadas tareas, el diseño
de la base de datos o el código para el funcionamiento de determinadas
pantallas.
Durante la realización de todo el proyecto me he dado cuenta también de la
dificultad de poder compaginar la vida laboral, junto con la realización de un
proyecto fin de carrera. Tanto por la dificultad de sacar tiempo para la
realización como de la eficacia de los tiempos.
Los conocimientos que he adquirido durante la realización del proyecto, han
sido además de los propios por la realización de una aplicación, el gestionar el
tiempo y las tareas para la conclusión de un proyecto basado en una idea
inicial, y una necesidad en la vida real.
Gracias a todo lo aprendido y desarrollado, considero que el haber realizado
este proyecto, me ha resultado de mucha utilidad, tanto para posibles futuros
proyectos desde cero, como para mi vida laboral.
Sistema de notificación de avisos para eventos programables
Anexo I. Manual de despliegue e Instalación
Universidad de La Rioja Página 100
Anexo I.
Manual de despliegue e
Instalación
Sistema de notificación de avisos para eventos programables
Anexo I. Manual de despliegue e Instalación
Universidad de La Rioja Página 101
A I.1) Consideraciones previas
Para que la aplicación funcione satisfactoriamente, tiene que estar instalado el
programa “padre” en el ordenador. Después de esto se tendrán que realizar
distintas fases.
A I.2) Instalación de las pantallas
Localizaremos la unidad compartida en donde se encuentran los binarios del
resto de pantallas del programa. Estos binarios son las pantallas e informes
creados a partir de Oracle Forms Builder y Report Builder, y su posterior
compilado.
Una vez localizada esta unidad, copiaremos las pantallas creadas para la
aplicación así como los informes creados. Estos serán:
DEF_snap_avisos.fmx
DEF_snap_empleados.fmx
DEF_snap_resp_avisos.fmx
avisos.rep
También se suministrarán los fuentes para posteriores modificaciones y
actualizaciones. Los fuentes se guardarán con el resto de fuentes de la
aplicación, que son:
DEF_snap_avisos.fmb
DEF_snap_empleados.fmb
DEF_snap_resp_avisos.fmb
avisos.rdf
Sistema de notificación de avisos para eventos programables
Anexo I. Manual de despliegue e Instalación
Universidad de La Rioja Página 102
A I.3) Creación de tablas
Para el correcto funcionamiento de las pantallas instaladas se deberán ejecutar
el siguiente script para instalar las tablas y restricciones.
CREATE TABLE SNAP_AUX
( COD_EMPLEADO VARCHAR2(10 BYTE));
CREATE TABLE SNAP_DESCRIPCIONES
( TIPO_TABLA VARCHAR2(20 BYTE) NOT NULL,
TIPO VARCHAR2(15 BYTE) NOT NULL,
DESCRIPCION VARCHAR2(400 BYTE));
CREATE TABLE SNAP_GFHS
(GFHVARCHAR2(15 BYTE) NOT NULL,
DESC_GFH VARCHAR2(50 BYTE) NOT NULL);
CREATE TABLE SNAP_TIPOS_AVISOS
( COD_AVISO VARCHAR2(15 BYTE) NOT NULL,
DESCRIPCION VARCHAR2(30 BYTE),
DESCRIPCION_LARGA VARCHAR2(200 BYTE),
LITERAL_CORREO VARCHAR2(200 BYTE));
CREATE TABLE SNAP_EMPLEADOS
( CODIGO_EMPLEADO VARCHAR2(10 BYTE) NOT NULL,
APELLIDOS VARCHAR2(130 BYTE) NOT NULL,
NOMBRE VARCHAR2(60 BYTE) NOT NULL,
EMAIL VARCHAR2(40 BYTE),
USUARIO VARCHAR2(15 BYTE),
GFH VARCHAR2(20 BYTE) NOT NULL);
CREATE TABLE SNAP_EMPLEADOS_AVISOS
( COD_EMPLEADO VARCHAR2(10 BYTE) NOT NULL,
GFH VARCHAR2(15 BYTE) NOT NULL,
COD_AVISO VARCHAR2(15 BYTE) NOT NULL,
FECHA_AVISO NUMBER NOT NULL,
FECHA NUMBER NOT NULL,
TIPO_AVISO VARCHAR2(20 BYTE) NOT NULL,
AVIS_APLICACION VARCHAR2(1 BYTE),
AVIS_INTRANET VARCHAR2(1 BYTE),
AVIS_CORREO VARCHAR2(1 BYTE));
CREATE TABLE SNAP_RESP_GFH
(GFHVARCHAR2(15 BYTE) NOT NULL,
COD_RESP VARCHAR2(10 BYTE) NOT NULL);
CREATE TABLE SNAP_TABLAS_AVISOS
( COD_AVISO VARCHAR2(15 BYTE) NOT NULL,
TABLA_VISTA VARCHAR2(30 BYTE),
COLUMNA VARCHAR2(30 BYTE),
VALOR VARCHAR2(30 BYTE),
FECHA VARCHAR2(30 BYTE),
TIPO_FECHA VARCHAR2(1 BYTE));
Sistema de notificación de avisos para eventos programables
Anexo I. Manual de despliegue e Instalación
Universidad de La Rioja Página 103
CREATE TABLE SNAP_VACACIONES
( COD_EMPLEADO VARCHAR2(10 BYTE) NOT NULL,
TIPO_VAC VARCHAR2(15 BYTE) NOT NULL,
FECHA_INI NUMBER NOT NULL,
FECHA_FIN NUMBER);
CREATE TABLE SNAP_ATRIBUTOS
( COD_EMPLEADO VARCHAR2(10 BYTE) NOT NULL,
TIPO_ATRIBUTO VARCHAR2(15 BYTE) NOT NULL,
FECHA_INI NUMBER NOT NULL,
FECHA_FIN NUMBER,
VALOR VARCHAR2(15 BYTE));
CREATE TABLE SNAP_BAJAS
( COD_EMPLEADO VARCHAR2(10 BYTE) NOT NULL,
TIPO_BAJA VARCHAR2(15 BYTE) NOT NULL,
FECHA_INI DATE NOT NULL,
FECHA_FIN DATE);
CREATE TABLE SNAP_CONFIG_AVISOS
( COD_AVISO VARCHAR2(15 BYTE) NOT NULL,
DIAS_ANTES1 NUMBER,
DIAS_ANTES2 NUMBER,
DIAS_DESPUES1 NUMBER,
DIAS_DESPUES2 NUMBER);
CREATE TABLE SNAP_AVISOS_GFH
( COD_AVISO VARCHAR2(15 BYTE) NOT NULL,
GFH VARCHAR2(15 BYTE) NOT NULL,
AVISO_APLICACION VARCHAR2(1 BYTE),
AVISO_INTRANET VARCHAR2(1 BYTE),
AVISO_CORREO VARCHAR2(1 BYTE));
CREATE UNIQUE INDEX SNAP_DESCRIPCIONES_PK ON SNAP_DESCRIPCIONES
(TIPO_TABLA, TIPO);
CREATE UNIQUE INDEX SNAP_GFHS_FK ON SNAP_GFHS
(GFH);
CREATE UNIQUE INDEX SNAP_TIPOS_AVISOS_PK ON SNAP_TIPOS_AVISOS
(COD_AVISO);
CREATE UNIQUE INDEX SNAP_EMPLEADOS_PK ON SNAP_EMPLEADOS
(CODIGO_EMPLEADO);
CREATE UNIQUE INDEX SNAP_EMPLE_UK ON SNAP_EMPLEADOS
(CODIGO_EMPLEADO, GFH);
CREATE UNIQUE INDEX SNAP_RESP_GFH_PK ON SNAP_RESP_GFH
(GFH, COD_RESP);
CREATE UNIQUE INDEX SNAP_TABLAS_AVISOS_PK ON SNAP_TABLAS_AVISOS
(COD_AVISO);
CREATE UNIQUE INDEX SNAP_VACACIONES_PK ON SNAP_VACACIONES
(COD_EMPLEADO, TIPO_VAC, FECHA_INI);
Sistema de notificación de avisos para eventos programables
Anexo I. Manual de despliegue e Instalación
Universidad de La Rioja Página 104
CREATE UNIQUE INDEX SNAP_ATIBUTOS_PK ON SNAP_ATRIBUTOS
(COD_EMPLEADO, TIPO_ATRIBUTO, FECHA_INI);
CREATE UNIQUE INDEX SNAP_BAJAS_PK ON SNAP_BAJAS
(COD_EMPLEADO, TIPO_BAJA, FECHA_INI);
CREATE UNIQUE INDEX SNAP_CONFIG_AVISOS_PK ON SNAP_CONFIG_AVISOS
(COD_AVISO);
CREATE UNIQUE INDEX SNAP_AVISOS_GFH_PK ON SNAP_AVISOS_GFH
(COD_AVISO, GFH);
ALTER TABLE SNAP_DESCRIPCIONES ADD (
CONSTRAINT SNAP_DESCRIPCIONES_PK
PRIMARY KEY
(TIPO_TABLA, TIPO)
USING INDEX SNAP_DESCRIPCIONES_PK);
ALTER TABLE SNAP_GFHS ADD (
CONSTRAINT SNAP_GFHS_FK
PRIMARY KEY
(GFH)
USING INDEX SNAP_GFHS_FK);
ALTER TABLE SNAP_TIPOS_AVISOS ADD (
CONSTRAINT SNAP_TIPOS_AVISOS_PK
PRIMARY KEY
(COD_AVISO)
USING INDEX SNAP_TIPOS_AVISOS_PK);
ALTER TABLE SNAP_EMPLEADOS ADD (
CONSTRAINT SNAP_EMPLEADOS_PK
PRIMARY KEY
(CODIGO_EMPLEADO)
USING INDEX SNAP_EMPLEADOS_PK);
ALTER TABLE SNAP_EMPLEADOS ADD (
CONSTRAINT SNAP_EMPLE_UK
UNIQUE (CODIGO_EMPLEADO, GFH)
USING INDEX SNAP_EMPLE_UK);
ALTER TABLE SNAP_RESP_GFH ADD (
CONSTRAINT SNAP_RESP_GFH_PK
PRIMARY KEY
(GFH, COD_RESP)
USING INDEX SNAP_RESP_GFH_PK);
ALTER TABLE SNAP_TABLAS_AVISOS ADD (
CONSTRAINT SNAP_TABLAS_AVISOS_PK
PRIMARY KEY
(COD_AVISO)
USING INDEX SNAP_TABLAS_AVISOS_PK);
Sistema de notificación de avisos para eventos programables
Anexo I. Manual de despliegue e Instalación
Universidad de La Rioja Página 105
ALTER TABLE SNAP_VACACIONES ADD (
CONSTRAINT SNAP_VACACIONES_PK
PRIMARY KEY
(COD_EMPLEADO, TIPO_VAC, FECHA_INI)
USING INDEX SNAP_VACACIONES_PK);
ALTER TABLE SNAP_ATRIBUTOS ADD (
CONSTRAINT SNAP_ATIBUTOS_PK
PRIMARY KEY
(COD_EMPLEADO, TIPO_ATRIBUTO, FECHA_INI)
USING INDEX SNAP_ATIBUTOS_PK);
ALTER TABLE SNAP_BAJAS ADD (
CONSTRAINT SNAP_BAJAS_PK
PRIMARY KEY
(COD_EMPLEADO, TIPO_BAJA, FECHA_INI)
USING INDEX SNAP_BAJAS_PK);
ALTER TABLE SNAP_CONFIG_AVISOS ADD (
CONSTRAINT SNAP_CONFIG_AVISOS_PK
PRIMARY KEY
(COD_AVISO)
USING INDEX SNAP_CONFIG_AVISOS_PK);
ALTER TABLE SNAP_AVISOS_GFH ADD (
CONSTRAINT SNAP_AVISOS_GFH_PK
PRIMARY KEY
(COD_AVISO, GFH)
USING INDEX SNAP_AVISOS_GFH_PK);
ALTER TABLE SNAP_EMPLEADOS ADD (
CONSTRAINT SNAP_EMPLEADOS_GFH_FK
FOREIGN KEY (GFH)
REFERENCES SNAP_GFHS (GFH));
ALTER TABLE SNAP_EMPLEADOS_AVISOS ADD (
CONSTRAINT SNAP_EMPLE_AVIS_COD_A_FK
FOREIGN KEY (COD_AVISO)
REFERENCES SNAP_TIPOS_AVISOS (COD_AVISO));
ALTER TABLE SNAP_EMPLEADOS_AVISOS ADD (
CONSTRAINT SNAP_EMPLE_AVIS_EMP_FK
FOREIGN KEY (COD_EMPLEADO, GFH)
REFERENCES SNAP_EMPLEADOS (CODIGO_EMPLEADO,GFH));
ALTER TABLE SNAP_RESP_GFH ADD (
CONSTRAINT SNAP_RESP_GFH_EMPLE
FOREIGN KEY (COD_RESP)
REFERENCES SNAP_EMPLEADOS (CODIGO_EMPLEADO));
ALTER TABLE SNAP_RESP_GFH ADD (
CONSTRAINT SNAP_RESP_GFH_GFHS_FK
FOREIGN KEY (GFH)
REFERENCES SNAP_GFHS (GFH));
Sistema de notificación de avisos para eventos programables
Anexo I. Manual de despliegue e Instalación
Universidad de La Rioja Página 106
ALTER TABLE SNAP_TABLAS_AVISOS ADD (
CONSTRAINT SNAP_TAB_AVIS_TIPOS_FK
FOREIGN KEY (COD_AVISO)
REFERENCES SNAP_TIPOS_AVISOS (COD_AVISO));
ALTER TABLE SNAP_VACACIONES ADD (
CONSTRAINT SNAP_VACACIONES_EMPLEADO_FK
FOREIGN KEY (COD_EMPLEADO)
REFERENCES SNAP_EMPLEADOS (CODIGO_EMPLEADO));
ALTER TABLE SNAP_ATRIBUTOS ADD (
CONSTRAINT SNAP_ATRIBUTOS_EMPLE_FK
FOREIGN KEY (COD_EMPLEADO)
REFERENCES SNAP_EMPLEADOS (CODIGO_EMPLEADO));
ALTER TABLE SNAP_BAJAS ADD (
CONSTRAINT SNAP_BAJAS_EMPLE_FK
FOREIGN KEY (COD_EMPLEADO)
REFERENCES SNAP_EMPLEADOS (CODIGO_EMPLEADO));
ALTER TABLE SNAP_CONFIG_AVISOS ADD (
CONSTRAINT SNAP_CONF_AVIS_TABL_FK
FOREIGN KEY (COD_AVISO)
REFERENCES SNAP_TABLAS_AVISOS (COD_AVISO));
ALTER TABLE SNAP_AVISOS_GFH ADD (
CONSTRAINT SNAP_AVIS_GFH_CONFIG_FK
FOREIGN KEY (COD_AVISO)
REFERENCES SNAP_CONFIG_AVISOS (COD_AVISO));
ALTER TABLE SNAP_AVISOS_GFH ADD (
CONSTRAINT SNAP_AVIS_GFH_GFHS_FK
FOREIGN KEY (GFH)
REFERENCES SNAP_GFHS (GFH));
Sistema de notificación de avisos para eventos programables
Anexo I. Manual de despliegue e Instalación
Universidad de La Rioja Página 107
A I.4) Creación de vistas, funciones, procedimientos y jobs
Hay que instalar vistas, funciones procedimientos y Jobs para el correcto
funcionamiento de la aplicación.
Para instalar las vistas ejecutaremos el siguiente script:
CREATE OR REPLACE VIEW SNAP_AVIS_GHF_VW
( COD_AVISO, DESCRIPCION, GFH, DESC_GFH, APLIC, INTRANET, CORREO)AS
SELECT s.cod_aviso,s.descripcion,g.gfh,g.desc_gfh,
(SELECT a.aviso_aplicacion
FROM snap_avisos_gfh a
WHERE a.cod_aviso = s.cod_aviso AND a.gfh = g.gfh) AS aplic,
(SELECT a.aviso_intranet
FROM snap_avisos_gfh a
WHERE a.cod_aviso = s.cod_aviso AND a.gfh = g.gfh) AS intranet,
(SELECT a.aviso_correo
FROM snap_avisos_gfh a
WHERE a.cod_aviso = s.cod_aviso AND a.gfh = g.gfh) AS correo
FROM snap_tipos_avisos s, snap_gfhs g;
CREATE OR REPLACE VIEW SNAP_AVISOS_UNION_VW
( COD_AVISO, TABLA_VISTA, COLUMNA, VALOR, FECHA, TIPO_FECHA,
SUMAR_RESTAR, DIAS, LITERAL, GFH, AVISO_APLICACION, AVISO_INTRANET,
AVISO_CORREO)AS
SELECT t.cod_aviso,t.tabla_vista,t.columna,t.valor,t.fecha,
t.tipo_fecha,'S' AS sumar_restar,c.dias_antes1 AS dias,
'Dias antes 1' AS literal,g.gfh,
g.aviso_aplicacion,g.aviso_intranet,g.aviso_correo
FROM snap_tablas_avisos t, snap_config_avisos c, snap_avisos_gfh g
WHERE t.cod_aviso = c.cod_aviso AND c.cod_aviso = g.cod_aviso
AND c.dias_antes1 IS NOT NULL
UNION ALL
SELECT t.cod_aviso,t.tabla_vista,t.columna,t.valor,t.fecha,
t.tipo_fecha,'S' AS sumar_restar,c.dias_antes2 AS dias,
'Dias antes 2' AS literal,g.gfh,
g.aviso_aplicacion,g.aviso_intranet,g.aviso_correo
FROM snap_tablas_avisos t, snap_config_avisos c, snap_avisos_gfh g
WHERE t.cod_aviso = c.cod_aviso AND c.cod_aviso = g.cod_aviso
AND c.dias_antes2 IS NOT NULL
UNION ALL
SELECT t.cod_aviso,t.tabla_vista,t.columna,t.valor,t.fecha,
t.tipo_fecha,'R' AS sumar_restar,c.dias_despues1 AS dias,
'Dias después 1' AS literal,g.gfh,
g.aviso_aplicacion,g.aviso_intranet,g.aviso_correo
FROM snap_tablas_avisos t, snap_config_avisos c, snap_avisos_gfh g
WHERE t.cod_aviso = c.cod_aviso
AND c.cod_aviso = g.cod_aviso
AND c.dias_despues1 IS NOT NULL
UNION ALL
SELECT t.cod_aviso,t.tabla_vista,t.columna,t.valor,t.fecha,
t.tipo_fecha,'R' AS sumar_restar,c.dias_despues2 AS dias,
'Dias después 2' AS literal,g.gfh,
g.aviso_aplicacion,g.aviso_intranet,g.aviso_correo
FROM snap_tablas_avisos t, snap_config_avisos c, snap_avisos_gfh g
WHERE t.cod_aviso = c.cod_aviso AND c.cod_aviso = g.cod_aviso
AND c.dias_despues2 IS NOT NULL;
Sistema de notificación de avisos para eventos programables
Anexo I. Manual de despliegue e Instalación
Universidad de La Rioja Página 108
Además de estas vistas, se debe instalar la siguiente función:
CREATE OR REPLACE FUNCTION SNAP_GFH_FUNC (v_cod_empleado varchar2)
RETURN varchar2 IS ret_gfh varchar2(20);
BEGIN
select e.gfh into ret_gfh
from snap_empleados e
where e.codigo_empleado = v_cod_empleado;
RETURN ret_gfh;
END;
También se deberán instalar los siguientes procedimientos:
CREATE OR REPLACE PROCEDURE SNAP_AVISOS_CORREO
( p_fechdate) IS
cursor responsables is
--cursor en el que se mira si hay un aviso para el día que
--estamos lanzando y saca los distintos responsables
select distinct r.cod_resp
from SNAP_EMPLEADOS_AVISOS s,SNAP_RESP_GFH r
where s.avis_correo = 'S'
and s.fecha_aviso = TO_NUMBER(TO_CHAR(p_fech,'J'))
and s.gfh = r.gfh;
BEGIN
For uno in responsables loop
begin
dbms_output.put_line('Responsable: '||uno.cod_resp);
snap_enviar_correo(uno.cod_resp,p_fech);
end;
end loop;
EXCEPTION
WHEN others THEN
dbms_output.put_line('error');
END;
CREATE OR REPLACE PROCEDURE SNAP_AVISOS_TABLA_PROC
( p_fech date) IS
--cursor de la vista para saber que avisos hay que realizar
cursor avisos_union is
select s.cod_aviso ,s.tabla_vista ,s.columna ,s.valor ,
s.fecha ,s.tipo_fecha , s.sumar_restar ,s.dias ,s.literal,
s.gfh, s.aviso_aplicacion ,s.aviso_intranet ,s.aviso_correo
from snap_avisos_union_vw s;
v_cod_aviso varchar2(10);
v_tabla_vista varchar2(40);
v_columna varchar2(40);
v_valor varchar2(20);
v_fecha varchar2 (40);
v_tipo_fecha varchar2(10);
v_sumar_restar varchar2(1);
v_dias number;
v_literal varchar2(30);
v_gfh varchar2(30);
v_aviso_aplicacion varchar2(2);
Sistema de notificación de avisos para eventos programables
Anexo I. Manual de despliegue e Instalación
Universidad de La Rioja Página 109
v_aviso_intranet varchar2(2);
v_aviso_correo varchar2(2);
v_fecha_aux number;
v_aux_tipo_fecha varchar2(100);
BEGIN
--empezamos el cursor
For uno in avisos_union loop
begin
v_cod_aviso := uno.cod_aviso;
v_tabla_vista := uno.tabla_vista;
v_columna := uno.columna;
v_valor := uno.valor;
v_fecha := uno.fecha;
v_tipo_fecha := uno.tipo_fecha;
v_sumar_restar := uno.sumar_restar;
v_dias := uno.dias;
v_literal := uno.literal;
v_gfh := uno.gfh;
v_aviso_aplicacion := uno.aviso_aplicacion;
v_aviso_intranet := uno.aviso_intranet;
v_aviso_correo := uno.aviso_correo;
--dependiendo si la columna en la que se encuentre la fecha es
de tipo fecha, caracter o juliano,realizamos una conversión
distinta en cada caso
IF v_tipo_fecha= 'D' THEN
V_AUX_TIPO_FECHA:= 'TO_NUMBER(TO_CHAR('||v_fecha||',''J''))';
ELSE
IF v_tipo_fecha= 'V' THEN
V_AUX_TIPO_FECHA:=
'TO_NUMBER(TO_CHAR(TO_DATE('||v_fecha||',''DD/MM/YYYY''),''J''
))';
ELSE
V_AUX_TIPO_FECHA:= V_FECHA;
END IF;
END IF;
--dependiendo si se trata de dias antes o días despues,
--sumamos o restamos para el cálculo de la fecha
if v_sumar_restar = 'S' then
v_fecha_aux:= TO_NUMBER(TO_CHAR(p_fech,'J'))+v_dias;
else
v_fecha_aux:= TO_NUMBER(TO_CHAR(p_fech,'J'))-v_dias;
end if;
--lamamos al procedimiento que crea el cursor dinámico con
todas las variables
SNAP_CURSOR_DINAMICO_PROC(p_fech, v_cod_aviso, v_tabla_vista,
v_columna, v_valor, v_gfh, v_aviso_aplicacion,
v_aviso_intranet, v_aviso_correo,v_fecha_aux,
v_aux_tipo_fecha, v_literal) ;
end;
end loop;
END;
CREATE OR REPLACE PROCEDURE SNAP_CURSOR_DINAMICO_PROC
( p_fech date,v_cod_aviso varchar2,v_tabla_vista varchar2,v_columna
varchar2, v_valor varchar2, v_gfh varchar2,v_aviso_aplicacion
varchar2, v_aviso_intranet varchar2, v_aviso_correo varchar2,
v_fecha_aux number, v_aux_tipo_fecha VARCHAR2, v_literal varchar2) IS
Sistema de notificación de avisos para eventos programables
Anexo I. Manual de despliegue e Instalación
Universidad de La Rioja Página 110
--definimos el tipo ref_curs_dinamico como cursor
TYPE ref_curs_dinamico IS REF CURSOR;
--definimos la variable curs_din de tipo ref_curs_dinamico, que es de
tipo cursor
curs_din ref_curs_dinamico;
--definimos un repositorio del mismo tipo que la tabla snap_aux
--snap aux es una tabla de una sola columna (cod_empleado varchar2(10)
repositorio snap_aux%ROWTYPE;
--definimos una variable para almacenar la select que será con la
--que creemoes el cursor
sql_stmt VARCHAR2(1000);
BEGIN
--creamos la select que será producto para nuestro cursor
--en ella creamo la select de la tabla pasado por referencia,
-- la columna a consultar, con el valor que ha de tener
-- y por último y más importante la columna en donde
--esta la fecha y el valor que ha de tener para realizar el aviso
sql_stmt := 'SELECT cod_empleado FROM '||v_tabla_vista||' where
'||v_columna||' = '''||v_valor||''' and '||V_AUX_TIPO_FECHA||' =
'||v_fecha_aux||' and SNAP_GFH_FUNC(cod_empleado)= '''||v_gfh||'''';
dbms_output.put_line('sql: '||sql_stmt);
--una vez tenemos almacenado en la variable sql_stmt la select para
-- la creación del cursor, abrimos dicho cursor
OPEN curs_din FOR sql_stmt;
--ahora recorremos con un bucle el cursor, almacenando el resultado
-- en repositorio, recorremos todo el cursor hasta el final
LOOP FETCH curs_din INTO repositorio;
EXIT WHEN curs_din%NOTFOUND;
--cada vez que entra y el cursor no se ha terminado, insertamos
--en la tabla los datos para el posterior envio de avisos.
INSERT INTO SNAP_EMPLEADOS_AVISOS VALUES
(repositorio.cod_empleado,v_gfh,v_cod_aviso,
TO_NUMBER(TO_CHAR(p_fech,'J')),v_fecha_aux,v_literal,
v_aviso_aplicacion,v_aviso_intranet,v_aviso_correo);
commit;
dbms_output.put_line('resultado: '||repositorio.cod_empleado);
--finalizamos el bucle y cerramos el cursor.
END LOOP;
CLOSE curs_din;
END;
Sistema de notificación de avisos para eventos programables
Anexo I. Manual de despliegue e Instalación
Universidad de La Rioja Página 111
CREATE OR REPLACE PROCEDURE SNAP_ENVIAR_CORREO(v_cod_responsable
varchar2,p_fecha date) IS
-- Búsqueda de mail y datos de la incidencia.
CURSOR V_GFHS IS
--miro los gfh que es responsable
select distinct s.gfh
from SNAP_EMPLEADOS_AVISOS s,SNAP_RESP_GFH r
where s.avis_correo = 'S'
and s.gfh = r.gfh
and s.fecha_aviso = TO_NUMBER(TO_CHAR(p_fecha,'J'))
and r.cod_resp = v_cod_responsable;
CURSOR V_COD_AVISOS (cur_gfh varchar2 )IS
--miro los códigos de avisos distintos para el gfh pasado al
cursor
select distinct s.cod_aviso,t.literal_correo
from SNAP_EMPLEADOS_AVISOS s,SNAP_TIPOS_AVISOS t
where s.gfh = cur_gfh
and t.cod_aviso = s.cod_aviso
and s.fecha_aviso = TO_NUMBER(TO_CHAR(p_fecha,'J'))
and s.avis_correo = 'S';
CURSOR V_EMPLEADOS (cur_gfh varchar2,cur_cod_aviso varchar2 ) IS
select s.cod_empleado ,E.apellidos ,E.nombre ,
TO_CHAR(TO_DATE(S.fecha ,'J'),'DD/MM/YYYY')AS FECHA
from SNAP_EMPLEADOS_AVISOS S,SNAP_EMPLEADOS E
where s.avis_correo = 'S'
AND S.cod_empleado = E.codigo_empleado
AND s.gfh = cur_gfh
and s.cod_aviso = cur_cod_aviso
and s.fecha_aviso = TO_NUMBER(TO_CHAR(p_fecha,'J'))
order by s.fecha ,s.cod_empleado;
v_fecha_c varchar2(15);
SENDER VARCHAR2(100) := xxxxxxxxxx;
RECIPIENT VARCHAR2(100);--el destinatario
SUBJECT VARCHAR2(400);
MESSAGE VARCHAR2(19000);
mailhost CONSTANT VARCHAR2(30) := xxxxxxx;
-- servidor de correo -- 'EXDB.riojasalud.es';
mesg VARCHAR2(10000); -- texto del mensaje
mail_conn UTL_SMTP.CONNECTION; -- conexion con el servidor smtp
fallo_mail EXCEPTION;
fin_no_finalizada EXCEPTION;
V_MAIL VARCHAR2(100);
BEGIN
v_fecha_c:= to_char(p_fecha,'dd/mm/yyyy');
begin
--pongo en el Recipient el destinatario del correo, en este
--caso el email del responsable
select s.email into RECIPIENT
from SNAP_EMPLEADOS s
where s.codigo_empleado = v_cod_responsable;
end;
RECIPIENT:=xxxxxx;
--el asunto del mensaje
SUBJECT := 'Avisos sobre incidencias del día ' ||v_fecha_c;
Sistema de notificación de avisos para eventos programables
Anexo I. Manual de despliegue e Instalación
Universidad de La Rioja Página 112
--inicio el mensage del correo
MESSAGE :=MESSAGE || '<HTML><BODY>';
FOR G IN V_gfhs LOOP
--voy mirando los gfhs de los que es responsable y si tienen
--avisos para el día señalado
dbms_output.put_line('Responsable: '||v_cod_responsable|| '
Gfh: '||G.gfh);
MESSAGE := MESSAGE || '<B><U>Los avisos para el gfh: '||G.gfh||'
del día '||v_fecha_c||' son:</B></U>';
MESSAGE :=MESSAGE || CHR(13) || CHR(10) || CHR(13) || CHR(10) ||
'<br><br>';
FOR A IN V_COD_AVISOS(G.GFH) LOOP
--los diferentes codigos de avisos que existen para el gfh tratado
MESSAGE := MESSAGE || '<B>El aviso: '||A.cod_aviso||' que avisa de
los empleados que tienen '||A.literal_correo||' son:</B>';
MESSAGE :=MESSAGE || CHR(13) || CHR(10) || CHR(13) || CHR(10) ||
'<br><br>';
--inicio de lista
MESSAGE := MESSAGE ||'<UL>';
FOR E IN V_EMPLEADOS(G.GFH,A.cod_aviso) LOOP
--todos los empleados que tienen el código de aviso en
--la fecha señalada y el gfh tratado
MESSAGE := MESSAGE ||'<LI>'||e.cod_empleado ||' '||E.apellidos||',
'||E.nombre||' fecha en la que ocurre el aviso: '||
E.FECHA||'.</LI>';
END LOOP;
--fin de lista
MESSAGE :=MESSAGE ||'</UL>';
END LOOP;
MESSAGE :=MESSAGE || CHR(13) || CHR(10) || CHR(13) ||
CHR(10) || '<br><br>';
END LOOP;
MESSAGE :=MESSAGE || '</BODY></HTML>';
-- Una vez construidos los parámetros del mensaje, se
--construye el correo completo
mail_conn := utl_smtp.open_connection(mailhost, 25);
mesg := 'Date: ' ||
TO_CHAR(SYSDATE, 'dd Mon yy hh24:mi:ss' ) || ' +0000' ||
CHR(13) || CHR(10) ||
'From: <'|| Sender ||'>' || CHR(13) || CHR(10) ||
'Subject: '|| Subject || CHR(13) || CHR(10)||
'To: '||Recipient || CHR(13) || CHR(10) ||
'CC: '|| CHR(13) || CHR(10) ||
'Content-Type: text/html;' || CHR(13) || CHR(10) ||
CHR(13) || CHR(10) || Message;
utl_smtp.ehlo(mail_conn, mailhost);
--< Líneas para la autenticación del envío mail
UTL_SMTP.command(mail_conn,'auth login');
UTL_SMTP.command(mail_conn,
utl_raw.cast_to_varchar2(utl_encode.base64_encode(UTL_RAW.cast_to_
raw('xxxxxx'))));
UTL_SMTP.command(mail_conn,
utl_raw.cast_to_varchar2(utl_encode.base64_encode(UTL_RAW.cast_to_
raw('xxxxx'))));
utl_smtp.mail(mail_conn, Sender);
utl_smtp.rcpt(mail_conn, Recipient);
utl_smtp.rcpt(mail_conn, Sender);
utl_smtp.data(mail_conn, mesg);
Sistema de notificación de avisos para eventos programables
Anexo I. Manual de despliegue e Instalación
Universidad de La Rioja Página 113
utl_smtp.quit(mail_conn);
EXCEPTION
WHEN fallo_mail THEN
RAISE_APPLICATION_ERROR(-20002, 'No se ha encontrado el
mail del empleado en concreto ');
WHEN fin_no_finalizada THEN
RAISE_APPLICATION_ERROR(-20003, 'No se ha podido enviar el
mail.');
-- WHEN OTHERS THEN
-- RAISE_APPLICATION_ERROR(-20004,SQLERRM);
END snap_enviar_correo;
CREATE OR REPLACE PROCEDURE snap_lanzamiento
( p_fech date) IS
aux_fecha date;
BEGIN
aux_fecha:=p_fech-1;
SNAP.SNAP_AVISOS_TABLA_PROC(aux_fecha );
commit;
SNAP.SNAP_AVISOS_CORREO (aux_fecha);
commit;
EXCEPTION
WHEN others THEN
dbms_output.put_line('error');
END;
Y por último el job, para la ejecución nocturna y lanzamiento de los procesos
necesarios para la correcta funcionalidad de la aplicación.
DECLARE
X NUMBER;
BEGIN
SYS.DBMS_JOB.SUBMIT
( job=>X
,what=>'SNAP.SNAP_LANZAMIENTO
(sysdate );'
,next_date =>to_date('01/01/4000 00:00:00','dd/mm/yyyy h24:mi:ss')
,interval=>'TRUNC(SYSDATE+1)'
,no_parse =>FALSE );
SYS.DBMS_OUTPUT.PUT_LINE('Job Number is: ' || to_char(x));
SYS.DBMS_JOB.BROKEN
(job=>X,
broken=>TRUE);
COMMIT;
END;
Sistema de notificación de avisos para eventos programables
Anexo II. Manual de administrador de la aplicación
Universidad de La Rioja Página 114
Anexo II.
Manual de administrador
de la aplicación
Sistema de notificación de avisos para eventos programables
Anexo II. Manual de administrador de la aplicación
Universidad de La Rioja Página 115
A II.1) Introducción
Esta aplicación pretende poder definir determinados avisos para eventos que
se pueden programar. Para ello, tendremos que recoger los requisitos que
quieran los usuarios para poder configurar correctamente cada uno de los
avisos.
A II.2) Funcionamiento general del programa
La aplicación para la notificación de avisos, se encuentra dentro de un
programa más amplio. Por lo que se tendrá que entrar en el programa con un
usuario y contraseña ya facilitado. También hay que tener en cuenta que la
botonera principal viene dada por el programa y no se puede modificar.
Esta botonera principal es la siguiente:
Sirve para guardar los cambios realizados.
Para salir de la pantalla.
Para entrar en modo consulta en el campo donde este el cursor.
Para ejecutar la consulta cuando se está en modo consulta.
Para cancelar la consulta.
Para situase en el primer o último registro o simplemente
avanzar al siguiente o anterior registro.
Para que aparezca una pantalla con la lista de valores posibles en el
campo que estemos situados.
Limpia los campos en los que estemos situados.
Añadir un nuevo registro.
Borrar el registro en el que nos encontremos.
Para imprimir lo que estamos viendo en la pantalla.
Es para cambiar el tipo de versión de trabajo (inutilizado)
Sistema de notificación de avisos para eventos programables
Anexo II. Manual de administrador de la aplicación
Universidad de La Rioja Página 116
Son los botones de copiar, cortar y pegar, realizaran estos
comandos sobre el campo que estemos situados.
Botón de ayuda.
Cuando se esté ya dentro del programa principal, tendremos que ir al apartado
específico sobre la Notificación de avisos programados. Una vez dentro
veremos la siguiente pantalla donde se encuentran las tres pantallas a las que
se puede acceder.
Estas pantallas son las que vamos a explicar a continuación.
Sistema de notificación de avisos para eventos programables
Anexo II. Manual de administrador de la aplicación
Universidad de La Rioja Página 117
A II.3) Pantalla de configuración de empleados
En esta pantalla es donde podremos insertar, modificar y borrar todos los datos
relativos a los empleados.
Aunque en realidad todos estos datos ya estarán metidos en el programa
general, este apartado ha servido de simulación para la creación de unas tablas
diferentes desde donde poder coger los datos.
Desde esta pantalla se pueden insertar todos los datos necesarios para la
aplicación, tiene diferentes pestañas que pasamos a explicar a continuación.
A) Empleados
En esta pantalla es donde podemos consultar, insertar, modificar y borrar
empleados. Es importante tener bien rellenados los campos de Email y Gfh.
Para consultar pulsaremos el botón para tal fin y pondremos en alguno de los
campos la consulta que queramos ejecutar. Para insertar, pulsaremos el botón
correspondiente y añadiremos los campos para un nuevo empleado. Si
queremos modificar nos situaremos en el dato a modificar, lo cambiaremos y
pulsaremos el botón de guardar. Para borrar, nos situaremos en el registro que
deseemos eliminar y pulsaremos el botón de eliminar.
Sistema de notificación de avisos para eventos programables
Anexo II. Manual de administrador de la aplicación
Universidad de La Rioja Página 118
B) Atributos
En esta pantalla podremos consultar, insertar, modificar y borrar los atributos
de los empleados. Estos atributos son lo que se den de alta en la pantalla con
las descripciones que explicaremos más adelante.
Para consultar algún dato, se pulsará el botón de consulta situándose en alguno
de los campos de la pantalla y luego se ejecutará la consulta. Para insertar un
atributo nuevo para un empleado se deberá pulsar el botón de añadir, luego
seleccionar uno de los empleados pulsando el botón de lista de valores,
posteriormente con otra lista de valores seleccionar el atributo a añadir, y por
último poner las fechas de vigencia del atributo con su correspondiente valor.
Para modificar un atributo de un empleado, nos situaremos en el empleado y
atributo a modificar, lo cambiaremos y luego pulsaremos el botón de guardar.
Por último para borrar el atributo de un empleado, nos situaremos en el
registro a eliminar y pulsaremos el botón de borrar.
Sistema de notificación de avisos para eventos programables
Anexo II. Manual de administrador de la aplicación
Universidad de La Rioja Página 119
C) Vacaciones
En esta pantalla es donde podremos consultar, insertar, modificar y borrar los
distintos tipos de permisos o vacaciones de los empleados. Estos tipos de
permisos y vacaciones se darán de alta en la pantalla de descripciones que se
explicará más adelante
Para consultar las vacaciones de un empleado, hay que situarse en un campo
en concreto e introducir la consulta a realizar y pulsar el botón para ejecutarla.
Si lo que deseamos es modificar unas vacaciones ya introducidas,
consultaremos las que se quieren cambiar, nos pondremos en el campo que se
quiera modificar, que puede ser tanto el tipo de permiso como las fechas, se
cambia y luego se pulsa el botón de guardar. Para insertar un registro,
pulsaremos el botón de añadir y posteriormente elegiremos un empleado de la
lista de empleados, el tipo de vacación, la fecha inicio y fin y por último
pulsaremos el botón de guardar. Para borrar un registro, nos situaremos en el
que se desea eliminar, pulsaremos el botón de borrar y luego el de guardar.
Sistema de notificación de avisos para eventos programables
Anexo II. Manual de administrador de la aplicación
Universidad de La Rioja Página 120
D) Bajas
En esta pantalla se puede realizar lo mismo que en la explicada anteriormente
de vacaciones, pero en este caso en vez de tipos de permisos lo que se rellenan
son tipos de baja. Estas bajas son las que están configuradas en la pantalla de
descripciones que se explicará más adelante.
E) Descripciones
En esta pantalla podremos consultar, añadir, modificar y eliminar los distintos
tipos de atributos, vacaciones y bajas que se pueden añadir a cada uno de los
empleados.
Para consultar las descripciones existentes, nos situaremos en uno de los
campos y ejecutaremos la consulta. Para añadir una nueva descripción,
pulsaremos el botón de añadir, luego seleccionaremos de la lista de valores una
de las tres tablas (atributos, vacaciones o bajas) y luego un código y descripción
para dicho código. Para modificar uno existente, se consultará la descripción a
modificar, se cambiará lo que se desee y posteriormente se pulsará en guardar.
Para eliminar una descripción, nos tendremos que situar en el registro que se
desea eliminar y pulsaremos el botón de borrar y luego el de guardar.
Sistema de notificación de avisos para eventos programables
Anexo II. Manual de administrador de la aplicación
Universidad de La Rioja Página 121
A II.4) Pantalla de configuración de avisos
En esta pantalla es donde verdaderamente se crean los avisos para la
aplicación, esta pantalla tiene tres pestañas que se explican a continuación.
A) Tipos de avisos
En esta pantalla es donde se pueden visualizar, modificar, insertar y borra
avisos. Para consultarlos podremos dar al botón de consulta, ejecutarla y luego
ir pasando con las flechas de aviso en aviso. Para modificar o borrar un aviso, se
deberá hacer con el tipo de aviso en pantalla.
Para dar de alta un nuevo aviso hay que pulsar el botón de añadir, luego poner
un código para el aviso junto con una descripción breve y otra más larga para
explicar de una forma más extensa en que consiste el aviso. Luego podemos
rellenar el campo de literal correo que es lo que aparecerá a los supervisores
cuando reciban este aviso por correo electrónico. Luego se tiene que rellenar
de qué tabla queremos que se consulten los datos para realizar el aviso, puede
ser la tabla de atributos, vacaciones o bajas. Posteriormente seleccionaremos la
columna a consultar dentro de la tabla para lanzar el aviso, junto con el valor
que debe tener dicha columna. Luego tendremos que decidir si una vez
encontrada en la columna de la tabla el valor que hemos indicado, tendremos
que tener en cuenta la fecha inicio o la final para tener en cuenta el aviso. Por
último podremos decidir cuantos días antes o después realizaremos el aviso del
evento que estamos configurando. Para este fin podremos rellenar dos fechas
anteriores y dos posteriores.
Sistema de notificación de avisos para eventos programables
Anexo II. Manual de administrador de la aplicación
Universidad de La Rioja Página 122
B) Administración GFH’s Responsables
En esta pantalla podemos consultar, crear, modificar y borrar los gfh, que no
son otra cosa que los grupos funcionales homogéneos. Una manera de
englobar a personal dentro de un mismo grupo.
Para consultar nos situaremos en el campo de gfh, pulsaremos el botón de
consulta y luego al de ejecutarla. Pasando con las flechas podremos ver todos
lo que están creados. En la parte inferior podremos ver los responsables para el
gfh que estemos consultando. En esa parte también podremos insertar o
eliminar algún responsable. Sólo tendremos que pulsar el botón de borra en el
empleado que queremos que deje de ser responsable y luego el botón de
guardar. Para insertar uno, nos situaremos en la última fila y con el botón de
lista de registros elegimos un empleado en concreto y luego pulsamos guardar.
Para insertar un nuevo gfh, daremos al botón de añadir y a continuación
tenderemos que dar un código y una descripción, y por último pulsar el botón
de guardad. Para borrar un gfh, nos tendremos que situar en el registro
deseado, eliminar los responsables que tenga y mirar que ningún empleado
tenga asignado ese gfh, por último pulsaremos el botón de guardar y luego
eliminar.
Sistema de notificación de avisos para eventos programables
Anexo II. Manual de administrador de la aplicación
Universidad de La Rioja Página 123
C) Avisos gfh
En esta pantalla es donde después de pulsar el botón de consultar y ejecutar la
consulta, podremos ver todas las combinaciones de avisos y gfhs. En la parte
derecha podremos determinar cómo se realizará el aviso a los responsables del
gfh en cuestión y el tipo de aviso. Por lo que si se marca la parte de aplicación,
el aviso se realizará por las pantallas de esta aplicación. Si se marca intranet, los
avisos se podrán consultar en la página de la intranet de la empresa y si se
pulsa correo, el aviso le llegará al supervisor vía e-mail.
Sistema de notificación de avisos para eventos programables
Anexo II. Manual de administrador de la aplicación
Universidad de La Rioja Página 124
A II.5) Pantalla de visualización de datos
En esta pantalla es donde se podrán consultar los avisos que se han realizado,
tanto por la misma pantalla, como en un informe. Para mostrar los datos, se
puede filtrar por diferentes capos como son el gfh, código de aviso, las fechas
en las que realmente ocurre el aviso o la fecha en la que se realizó el aviso.
Aunque no se seleccione el gfh, cada usuario sólo podrá seleccionar aquellos de
los que sea responsable, y si no selecciona ninguno aparecerán los datos de los
que es responsable.
Además del filtro para sacar los datos, se puede seleccionar el orden en el que
queramos que salgan los datos. Dicho orden se puede seleccionar sobre las
columnas de código empleado, gfh, código de aviso, fecha en la que se realiza
el aviso o fecha en la que realmente sucede. Se puede seleccionar el primer
orden a tener en cuenta y si existen datos coincidentes en ese orden 1, se
tendrá en cuenta la columna seleccionada para el campo orden 2 y así
sucesivamente.
Sistema de notificación de avisos para eventos programables
Anexo II. Manual de administrador de la aplicación
Universidad de La Rioja Página 125
Una vez rellenados los datos del filtro y los órdenes, se puede pulsar el botón
de consultar, cuando se pulse, aparecerán los datos que cumplan los criterios
en la parte inferior. Al pulsar el botón de limpiar, se borraran los datos
consultados, así como lo que hayamos rellenado en la parte de filtro y de
orden.
Si pulsamos el botón de imprimir, una vez estén rellenados los campos para el
filtro y la ordenación, nos aparecerá una nueva pantalla con el informe de los
datos para poderlos imprimir. Ese listado tendrá la siguiente apariencia.
Sistema de notificación de avisos para eventos programables
Anexo III. Manual de usuario de la aplicación
Universidad de La Rioja Página 126
Anexo III.
Manual de usuario de la
aplicación
Sistema de notificación de avisos para eventos programables
Anexo III. Manual de usuario de la aplicación
Universidad de La Rioja Página 127
AIII.1) Introducción
Esta aplicación pretende poder definir determinados avisos para eventos que
se pueden programar. Para poder visualizar estos avisos tendremos diferentes
pantallas dentro de la aplicación.
AIII.2) Funcionamiento general del programa
La aplicación para la notificación de avisos, se encuentra dentro de un
programa más amplio. Por lo que se tendrá que entrar en éste con un usuario y
contraseña ya facilitado. Hay que tener en cuenta que la botonera principal
viene dada por el programa y no se puede modificar, ésta es la siguiente.
Sirve para guardar los cambios realizados.
Para salir de la pantalla.
Para entrar en modo consulta en el campo donde este el cursor.
Para ejecutar la consulta cuando se está en modo consulta.
Para cancelar la consulta.
Para situase en el primer o último registro o simplemente
avanzar al siguiente o anterior registro.
Para que aparezca una pantalla con la lista de valores posibles en el
campo que estemos situados.
Limpia los campos en los que estemos situados.
Añadir un nuevo registro.
Borrar el registro en el que nos encontremos.
Para imprimir lo que estamos viendo en la pantalla.
Sistema de notificación de avisos para eventos programables
Anexo III. Manual de usuario de la aplicación
Universidad de La Rioja Página 128
Es para cambiar el tipo de versión de trabajo (inutilizado)
Son los botones de copiar, cortar y pegar, realizaran estos
comandos sobre el campo que estemos situados.
Botón de ayuda.
Cuando se esté ya dentro del programa principal, tendremos que ir al apartado
específico sobre la Notificación de avisos programados. Una vez dentro
veremos la siguiente pantalla.
Sistema de notificación de avisos para eventos programables
Anexo III. Manual de usuario de la aplicación
Universidad de La Rioja Página 129
Pulsando en la que pone Visualización De Avisos se nos abrirá la siguiente
pantalla.
En esta pantalla es donde se podrán consultar los avisos que se han realizado,
tanto en la misma pantalla, como en un informe. Para mostrar los datos, se
puede filtrar por diferentes capos como son el gfh, código de aviso, las fechas
en las que realmente ocurre el aviso o la fecha en la que se realizó el aviso.
Aunque no se seleccione el gfh, cada usuario sólo podrá seleccionar aquellos de
los que sea responsable, y si no selecciona ninguno aparecerán los datos de los
que es responsable.
Además del filtro para sacar los datos, se puede seleccionar el orden en el que
queramos que salgan los datos. Dicho orden se puede seleccionar sobre las
columnas de código empleado, gfh, código de aviso, fecha en la que se realiza
el aviso o fecha en la que realmente sucede. Se puede seleccionar el primer
orden a tener en cuenta y si existen datos coincidentes en ese orden 1, se
tendrá en cuenta la columna seleccionada para el campo orden 2 y así
sucesivamente.
Sistema de notificación de avisos para eventos programables
Anexo III. Manual de usuario de la aplicación
Universidad de La Rioja Página 130
Una vez rellenados los datos del filtro y los órdenes, se puede pulsar el botón
de consultar, cuando se pulse, aparecerán los datos que cumplan los criterios
en la parte inferior. Al pulsar el botón de limpiar, se borraran los datos
consultados, así como lo que hayamos rellenado en la parte de filtro y de
orden.
Si pulsamos el botón de imprimir, una vez estén rellenados los campos para el
filtro y la ordenación, nos aparecerá una nueva pantalla con el informe de los
datos para poderlos imprimir. Ese listado tendrá la siguiente apariencia.