sistema de notificación de avisos para eventos programables · 2013-10-16 · sistema de...

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)


Í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


Índice


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


Documento de Objetivos del Proyecto


1. Documento de

Objetivos del Proyecto




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.




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.




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.




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.




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




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.




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




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




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




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




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




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




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


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


18:30-19:00


19:00-19:30


19:30-20:00

Proyecto Libre Libre Libre Proyecto

20:00-20:30

Proyecto Libre Libre Libre Libre

20:30-21:00


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.




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.




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.




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.




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.




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


Análisis


2. Análisis


Análisis


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.


Análisis


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.


Análisis


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.


Análisis


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.


Análisis


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.


Análisis


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.


Diseño


3. Diseño


Diseño


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.


Diseño


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.


Diseño


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.


Diseño


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.


Diseño


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:


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.


Diseño


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:


Observaciones


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:


Clave Principal

Observaciones


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:


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


Diseño


SNAP_ATRIBUTOS: es en esta tabla donde definimos los atributos de los

empleados. La definición es la siguiente:


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:


Observaciones

COD_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:


Observaciones

COD_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


Diseño


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:


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:


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:


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


Diseño


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.


Diseño


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.


Diseño


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.


Diseño


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.


Diseño


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.


Diseño


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:


Construcción


4. Construcción


Construcción


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


ADD CONSTRAINT snap_empleados_pk PRIMARY KEY (codigo_empleado)

USING INDEX


ADD CONSTRAINT snap_empleados_gfh_fk FOREIGN KEY (gfh)

REFERENCES snap_gfhs (gfh)


Construcción


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


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


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)


Construcción


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


ADD CONSTRAINT snap_resp_gfh_gfhs_fk FOREIGN KEY (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)


SNAP_VACACIONES:

CREATE TABLE snap_vacaciones


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)



Construcción


SNAP_BAJAS:

CREATE TABLE snap_bajas


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)


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


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


ADD CONSTRAINT snap_avis_gfh_config_fk FOREIGN KEY (cod_aviso)

REFERENCES snap_config_avisos (cod_aviso)


ADD CONSTRAINT snap_avis_gfh_gfhs_fk FOREIGN KEY (gfh)



Construcción


SNAP_EMPLEADOS_AVISOS:

CREATE TABLE snap_empleados_avisos


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


Construcción


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




and c.dias_antes2 is not null

union all


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




and c.dias_despues1 is not null

union all


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




and c.dias_despues2 is not null


Construcción


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;


Construcción


--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||'''';


Construcción


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


Construcción


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



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.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


AND S.cod_empleado = E.codigo_empleado

AND s.gfh = cur_gfh

and s.cod_aviso = cur_cod_aviso


order by s.fecha ,s.cod_empleado;

v_fecha_c varchar2(15);

SENDER VARCHAR2(100) := xxxxxxxxxx;

RECIPIENT VARCHAR2(100);--el destinatario

SUBJECT VARCHAR2(400);

Construcción


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 || 'Los avisos para el gfh: '||G.gfh||'

del día '||v_fecha_c||' son:';

MESSAGE :=MESSAGE || CHR(13) || CHR(10) || CHR(13) || CHR(10) ||

' ';

FOR A IN V_COD_AVISOS(G.GFH) LOOP

--los diferentes códigos de avisos que existen para el gfh tratado

MESSAGE := MESSAGE || 'El aviso: '||A.cod_aviso||' que avisa de los

empleados que tienen '||A.literal_correo||' son:';


' ';

--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) || ' ';

END LOOP;

MESSAGE :=MESSAGE || '</BODY></HTML>';

-- Una vez construidos los parámetros del mensaje, se

--construye el correo completo

Construcción


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_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


END;


Construcción


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;


Construcción


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:


Construcción


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

Construcción


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');


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.


Construcción


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


Construcción


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.


Construcción


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



Construcción


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:


Construcción


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



else

update snap_avisos_gfh s

set s.aviso_aplicacion=:SNAP_AVIS_GHF_VW.v_aplic



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.


Construcción


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.


Construcción


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


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;


Construcción


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


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


: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.

Construcción


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


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


where s.tipo_tabla = 'SNAP_ATRIBUTOS'


Construcción


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;


Construcción


begin

select s.descripcion INTO :SNAP_VACACIONES.DESC_VACACIONES


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



: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.



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'


Construcción


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


Construcción


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


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


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.



Construcción


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.


Construcción


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


Construcción


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.


Construcción


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);




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.


Construcción


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


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;


Construcción


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;


V_ORDEN:= V_ORDEN||','||:ORDEN.ORDEN3;


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.

Construcción


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';


(:FILTRO.F_FECHA_HASTA_F_AVISO,''J'')),FECHA_AVISO)>=

FECHA_AVISO';


(:FILTRO.F_FECHA_DESDE_FECH_OCU,''J'')),FECHA)<=

FECHA';


(: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');


GO_BLOCK ('FILTRO');


end;

De esta forma todos los campos quedan vacíos.


Construcción


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);


'PRM_GFH', TEXT_PARAMETER, :FILTRO.F_GFH);


'PRM_COD_AVISO', TEXT_PARAMETER, :FILTRO.F_COD_AVISO);


'PRM_FECHA_DESDE_AVISO',TEXT_PARAMETER, JAC(V_FECHA_DESDE_AVISO));


'PRM_FECHA_HASTA_AVISO',TEXT_PARAMETER,JAC(V_FECHA_HASTA_AVISO));


'PRM_FECHA_DESDE_OCU', TEXT_PARAMETER, JAC(V_FECHA_DESDE_OCU));


'PRM_FECHA_HASTA_OCU', TEXT_PARAMETER, JAC(V_FECHA_HASTA_OCU));


'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.

Construcción


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.


Construcción


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”


Construcción


Donde el F_11 tiene en el código lo siguiente.

El F_1, tiene lo siguiente.

El F_2 tiene lo siguiente.


Construcción


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.


Pruebas


5. Pruebas


Pruebas


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.


Pruebas


5.2) Pruebas de borrado de datos

Se realizan pruebas de borrado de datos en las siguientes pantallas.


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.


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







En esta pantalla no se pueden eliminar datos, ya que sólo existe para la

visualización de los datos, no se pueden borrar.


Pruebas


5.3) Pruebas de consulta de datos

Se realizan pruebas de consulta de datos en las siguientes pantallas.


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


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


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”.


Pruebas



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.


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.


Gestión del Proyecto


6. Gestión del Proyecto




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%




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




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.




La última parte del diagrama de Gantt es el siguiente:




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.


Conclusiones


7. Conclusiones


Conclusiones


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.


Anexo I. Manual de despliegue e Instalación


Anexo I.

Manual de despliegue e

Instalación




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




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


TABLA_VISTA VARCHAR2(30 BYTE),

COLUMNA VARCHAR2(30 BYTE),

VALOR VARCHAR2(30 BYTE),

FECHA VARCHAR2(30 BYTE),

TIPO_FECHA VARCHAR2(1 BYTE));




CREATE TABLE SNAP_VACACIONES


TIPO_VAC VARCHAR2(15 BYTE) NOT NULL,

FECHA_INI NUMBER NOT NULL,

FECHA_FIN NUMBER);

CREATE TABLE SNAP_ATRIBUTOS


TIPO_ATRIBUTO VARCHAR2(15 BYTE) NOT NULL,

FECHA_INI NUMBER NOT NULL,

FECHA_FIN NUMBER,

VALOR VARCHAR2(15 BYTE));

CREATE TABLE SNAP_BAJAS


TIPO_BAJA VARCHAR2(15 BYTE) NOT NULL,

FECHA_INI DATE NOT NULL,

FECHA_FIN DATE);

CREATE TABLE SNAP_CONFIG_AVISOS


DIAS_ANTES1 NUMBER,

DIAS_ANTES2 NUMBER,

DIAS_DESPUES1 NUMBER,

DIAS_DESPUES2 NUMBER);

CREATE TABLE SNAP_AVISOS_GFH


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);




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);


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);




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);


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));


CONSTRAINT SNAP_RESP_GFH_EMPLE

FOREIGN KEY (COD_RESP)

REFERENCES SNAP_EMPLEADOS (CODIGO_EMPLEADO));


CONSTRAINT SNAP_RESP_GFH_GFHS_FK

FOREIGN KEY (GFH)





ALTER TABLE SNAP_TABLAS_AVISOS ADD (

CONSTRAINT SNAP_TAB_AVIS_TIPOS_FK


REFERENCES SNAP_TIPOS_AVISOS (COD_AVISO));

ALTER TABLE SNAP_VACACIONES ADD (

CONSTRAINT SNAP_VACACIONES_EMPLEADO_FK

FOREIGN KEY (COD_EMPLEADO)


ALTER TABLE SNAP_ATRIBUTOS ADD (

CONSTRAINT SNAP_ATRIBUTOS_EMPLE_FK



ALTER TABLE SNAP_BAJAS ADD (

CONSTRAINT SNAP_BAJAS_EMPLE_FK



ALTER TABLE SNAP_CONFIG_AVISOS ADD (

CONSTRAINT SNAP_CONF_AVIS_TABL_FK


REFERENCES SNAP_TABLAS_AVISOS (COD_AVISO));


CONSTRAINT SNAP_AVIS_GFH_CONFIG_FK


REFERENCES SNAP_CONFIG_AVISOS (COD_AVISO));


CONSTRAINT SNAP_AVIS_GFH_GFHS_FK

FOREIGN KEY (GFH)





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


WHERE a.cod_aviso = s.cod_aviso AND a.gfh = g.gfh) AS intranet,

(SELECT a.aviso_correo


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


t.tipo_fecha,'S' AS sumar_restar,c.dias_antes2 AS dias,

'Dias antes 2' AS literal,g.gfh,




AND c.dias_antes2 IS NOT NULL

UNION ALL


t.tipo_fecha,'R' AS sumar_restar,c.dias_despues1 AS dias,

'Dias después 1' AS literal,g.gfh,



WHERE t.cod_aviso = c.cod_aviso

AND c.cod_aviso = g.cod_aviso

AND c.dias_despues1 IS NOT NULL

UNION ALL


t.tipo_fecha,'R' AS sumar_restar,c.dias_despues2 AS dias,

'Dias después 2' AS literal,g.gfh,




AND c.dias_despues2 IS NOT NULL;




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



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


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);




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




--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;




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



and s.gfh = r.gfh


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.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


AND S.cod_empleado = E.codigo_empleado

AND s.gfh = cur_gfh

and s.cod_aviso = cur_cod_aviso


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;

--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 || 'Los avisos para el gfh: '||G.gfh||'

del día '||v_fecha_c||' son:';


' ';

FOR A IN V_COD_AVISOS(G.GFH) LOOP

--los diferentes codigos de avisos que existen para el gfh tratado

MESSAGE := MESSAGE || 'El aviso: '||A.cod_aviso||' que avisa de

los empleados que tienen '||A.literal_correo||' son:';


' ';

--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) || ' ';

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_raw.cast_to_varchar2(utl_encode.base64_encode(UTL_RAW.cast_to_

raw('xxxxxx'))));


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;

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


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;


Anexo II. Manual de administrador de la aplicación


Anexo II.

Manual de administrador

de la aplicación




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)




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.




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.




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.




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.




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.




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.




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.




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.




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.




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.


Anexo III. Manual de usuario de la aplicación


Anexo III.

Manual de usuario de la

aplicación




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.




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.




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.




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 · 2013-10-16 · sistema de...

Documents