Download Módulo Alertas para la aplicación Asesor de Ventas

Departament d’Enginyeria Informàtica i M atemàtiques
Módulo Alertas para la aplicación
Asesor de Ventas
TITULACIÓN: Ingeniería Técnica de Telecomunicaciones, Especialidad en Telemática
AUTOR: Ángel Rolin Almagro
DIRECTOR:Jordi Castellà Roca.
FECHA: Septiembre / 2012.
1
Resumen
El proyecto que se ha desarrollado es un módulo web para una gran aplicación. Se ha
desarrollado en la empresa Tecnocom, perteneciente al ámbito de las tecnologías de la
información y comunicación, que ofrece servicios de subcontratación al cliente para
desarrollar aplicaciones informáticas.
El cliente desea un módulo donde sus empleados puedan visualizar un resumen de las
alertas que tienen pendientes de tratar, ordenadas por tipo y fecha de creación. Así mismo
se desea poder visualizar el detalle de una alerta, donde se pueda visualizar la lista
completa de los clientes adheridos a la misma. Bajo esta vista, el empleado deberá poder
realizar varias operaciones tales como visar o marcar un cliente como tratado, crear nuevos
contactos con el/los clientes o acceder a la Ficha Comercial del cliente, una aplicación
ajena. La aplicación debe de ser totalmente funcional sin obtener error alguno.
Se ha desarrollado el módulo bajo una pestaña llamada Alertas dentro de la aplicación
Asesor de Ventas, usando el mismo entorno de desarrollo e instalada en los mismos
servidores, haciendo uso de las tecnologías Java EE, Struts2, JavaScript y Oracle, entre
otras.
Bajo un exhaustivo juego de pruebas en diferentes entornos del desarrollador y otros del
cliente, se ha realizado el módulo cumpliendo todas las exigencias del cliente con un
resultado cómodo y fácil de usar, además de rápido y fiable.
2
Índice
1.
Introducción.............................................................................................................................. 7
1.1.
Sociedad TIC .................................................................................................................... 7
1.1.1.
1.2.
Necesidad .......................................................................................................................... 9
1.3.
Herramientas para el desarrollo de trabajo ................................................................ 10
1.4.
Objetivos ......................................................................................................................... 11
1.5.
Planificación.................................................................................................................... 11
1.6.
Organización de la memoria ......................................................................................... 12
1.7.
El Asesor de ventas......................................................................................................... 13
1.7.1.
2.
3.
El módulo de Alertas ................................................................................................... 13
Descripción de la empresa ..................................................................................................... 14
2.1.
Ubicación del proyectante en la empresa. .................................................................... 14
2.2.
Descripción de las tareas realizadas ............................................................................. 15
Tecnologías.............................................................................................................................. 17
3.1.
Java .................................................................................................................................. 18
3.1.1.
Filosofía ................................................................................................................... 18
3.1.2.
Orientado a objetos .................................................................................................. 18
3.1.3.
Independencia de la plataforma ............................................................................. 19
3.1.4.
J2EE (Java Enterprise Edition).............................................................................. 19
3.2.
JSP ................................................................................................................................... 20
3.3.
JavaScript ....................................................................................................................... 20
3.4.
HTML.............................................................................................................................. 21
3.4.1.
DHTML ................................................................................................................... 21
3.4.2.
Formularios ............................................................................................................. 22
3.4.3.
IFrame ..................................................................................................................... 22
3.5.
CSS .................................................................................................................................. 22
3.6.
Struts2 ............................................................................................................................. 23
3.7.
AJAX ............................................................................................................................... 23
3.8.
Oracle PL/SQL ............................................................................................................... 24
3.8.1.
3.9.
4.
Importancia de las TIC en el sector bancario .......................................................... 8
Vistas (views) ........................................................................................................... 24
Host(PL1) y Batch .......................................................................................................... 25
Diseño del proyecto ................................................................................................................ 27
3
5.
4.1.
Especificaciones .............................................................................................................. 27
4.2.
Diseño .............................................................................................................................. 28
4.2.1.
Definición de Alerta ................................................................................................ 29
4.2.2.
Casos de uso............................................................................................................. 29
4.2.3.
Flujo de navegación / diagrama de clases .............................................................. 30
4.2.4.
Tablas Oracle........................................................................................................... 31
4.2.4.1.
CRM_ALERTAS ............................................................................................. 31
4.2.4.2.
CRM_ALERTAS_CENTRO_GESTOR ......................................................... 32
4.2.4.3.
CRM_DETALLE_ALERTAS ......................................................................... 32
Desarrollo e Implementación ................................................................................................ 33
5.1.
Entorno de desarrollo .................................................................................................... 33
5.2.
Entrada en la aplicación ................................................................................................ 33
5.2.1.
User.java .................................................................................................................. 33
5.2.2.
El identificador de conversación (idConversation) ................................................ 33
5.2.3.
Las pestañas............................................................................................................. 33
5.2.4.
Las sub-pestañas...................................................................................................... 34
5.3.
Archivo de configuración de Struts (Struts-config.xml) ............................................. 34
5.4.
Recursos de texto ............................................................................................................ 34
5.5.
Entrada en el módulo Alertas ....................................................................................... 35
5.5.1.
Actions ..................................................................................................................... 38
5.5.1.1.
PantallaAlertasAction.java ............................................................................. 38
5.5.1.2.
AlertasFiltrarAction.java ................................................................................ 39
5.5.1.3.
DetalleAlertas .................................................................................................. 39
5.5.1.3.1. PantallaDetalleAlertasAction....................................................................... 40
5.5.1.3.2. DetalleAlertasResultadoAction .................................................................... 40
5.5.1.3.3. DetalleAlertasResultadoRefrescarAction .................................................... 40
5.5.1.3.4. DetalleAlertasVisarAction............................................................................ 40
5.5.1.4.
Ventana Información del cliente .................................................................... 41
5.5.1.4.1. VentanaAlertasInfoClienteAction ............................................................... 41
5.5.2.
Forms ....................................................................................................................... 41
5.5.2.1.
PantallaAlertasForm.java ............................................................................... 41
5.5.2.2.
PantallaDetalleAlertasForm.java ................................................................... 42
5.5.3.
JSPs.......................................................................................................................... 42
5.5.3.1.
PantallaAlertas.jsp .......................................................................................... 42
4
5.5.3.2.
AlertasCabecera.jsp ......................................................................................... 43
5.5.3.3.
AlertasFiltro.jsp ............................................................................................... 43
5.5.3.4.
AlertasResultados.jsp....................................................................................... 45
5.5.3.5.
AlertasPie.jsp ................................................................................................... 46
5.5.3.6.
Detalle de Alerta .............................................................................................. 46
5.5.3.6.1. PantallaDetalleAlertas.jsp ............................................................................ 46
5.5.3.6.2. DetalleAlertasCabecera.jsp .......................................................................... 46
5.5.3.6.3. DetalleAlertasResultados.jsp ........................................................................ 47
5.5.3.6.4. DetalleAlertasPie.jsp .................................................................................... 48
5.5.4.
JS’s ........................................................................................................................... 48
5.5.4.1.
Globales ........................................................................................................... 48
5.5.4.1.1. Boxover.js ..................................................................................................... 49
5.5.4.1.2. Ventana.js ..................................................................................................... 49
5.5.4.1.3. Funcionalitats.js ........................................................................................... 49
5.5.4.1.4. Prototype.js, Poslib.js y ScrollButton.js ....................................................... 49
5.5.4.1.5. C2c.js ............................................................................................................. 49
5.5.4.1.6. Sorttable.js .................................................................................................... 49
5.5.4.2.
Módulo Alertas ................................................................................................ 49
5.5.4.2.1. AlertasResultadoIFrame.js .......................................................................... 49
5.5.4.2.2. AlertasPantallaIFrame.js ............................................................................. 50
5.5.4.2.3. AlertasDetalleResultadoIFrame.js............................................................... 50
5.5.5.
DHTML ................................................................................................................... 51
5.5.5.1.
5.5.6.
alertasListadoAlertas.dynamic.table.js ........................................................... 51
Acceso a datos.......................................................................................................... 51
5.5.6.1.
AJAX ................................................................................................................ 52
5.5.6.1.1. AJAXGestoresDelCentroBPR.java .............................................................. 52
5.5.6.1.2. AJAXAlertasDesplegar.java ......................................................................... 52
5.5.6.2.
DAO ................................................................................................................. 52
5.5.6.2.1. AlertasDAO................................................................................................... 52
5.5.6.2.2. DetalleAlertasDAO ....................................................................................... 53
5.6.
Objetos Java locales ....................................................................................................... 54
5.6.1.
Alerta........................................................................................................................ 54
5.6.2.
Detalle Alertas ......................................................................................................... 54
5.7.
Entradas externas........................................................................................................... 55
5
5.7.1.
GCFEntradaAlertasAction ..................................................................................... 55
5.7.2.
GCFEntradaDetalleAlertasAction .......................................................................... 55
5.8.
Acceso a otras aplicaciones ............................................................................................ 55
5.8.1.
Módulos de la misma aplicación............................................................................. 55
5.8.1.1.
5.8.2.
5.9.
6.
Nuevo contacto sobre el cliente ....................................................................... 55
Ficha Comercial del cliente .................................................................................... 56
Carga y tratado de datos ............................................................................................... 56
5.9.1.
Procesos Batch ........................................................................................................ 56
5.9.2.
Tratado de datos en Oracle ..................................................................................... 57
Juego de pruebas / Evaluación .............................................................................................. 58
6.1.
Prueba y error ................................................................................................................ 58
6.2.
Entorno local................................................................................................................... 58
6.3.
Entorno Test ................................................................................................................... 59
6.4.
Entorno Pre-producción ................................................................................................ 60
6.5.
Entorno Producción ....................................................................................................... 60
7.
Conclusiones ........................................................................................................................... 61
8.
Bibliografía ............................................................................................................................. 62
6
1. Introducción
Este proyecto es el resultado del trabajo en la empresa Tecnocom, desarrollando un módulo
para una gran aplicación del cliente. El cliente, del sector bancario español, tiene una
aplicación comercial (previamente desarrollada por la misma empresa) que desea ampliar.
Dentro del equipo de trabajo, se han distribuido los distintos módulos de la aplicación entre
los integrantes del mismo con el fin de repartir las tareas en función de la producción. Así
mismo, el proyectante ha realizado el módulo de Alertas para la aplicación Asesor de
Ventas (véase sección 1.8). En este módulo, los usuarios de la aplicación podrían ver sus
alertas según su cargo dentro de la empresa, oficina, centro o equipo, además de poderlas
gestionar y realizar varias acciones desde la operativa.
1.1. Sociedad TIC
La empresa se ubica en el entorno de las tecnologías de la información y comunicación
(TIC), desarrollando aplicaciones y soporte técnico a sus clientes, entre otros modelos de
negocio. Pero, ¿qué son las TIC?
A nadie le sorprende estar informado minuto a minuto, comunicarse con personas del otro
lado del planeta, ver el vídeo de una canción o trabajar en equipo sin estar en un mismo
sitio. Las tecnologías de la información y comunicación se han convertido, a una gran
velocidad, en parte importante de nuestras vidas. Este concepto que también se llama
sociedad de la información se debe principalmente a un invento que apareció en 1969:
Internet.
Internet se gestó como parte de la Red de la Agencia de Proyectos de Investigación
Avanzada (ARPANET), creada por el Departamento de Defensa de los Estados Unidos de
América y se diseñó para comunicar los diferentes organismos del país. Sus principios
básicos eran: ser una red descentralizada con múltiples caminos entre dos puntos y que los
mensajes estuvieran divididos en partes que serían enviadas por caminos diferentes. La
presencia de diversas universidades e institutos en el desarrollo del proyecto hizo que se
fueran encontrando más posibilidades de intercambiar información. Posteriormente se
crearon los correos electrónicos, los servicios de mensajería y las páginas web. Pero no es
hasta mediados de la década de los noventa -en una etapa en que ya había dejado de ser un
proyecto militar- cuando se da la verdadera explosión de Internet. Y a su alrededor todo lo
que conocemos como Tecnologías de la información y comunicación.
¿Qué ofrecen las TIC?
Información, bajada de los costes:
•
•
Deslocalización de la producción ( centros de atención a clientes)
Mejor conocimiento del entorno, mejora de la eficacia de las tomas de decisiones.
A nivel de la estructura de la empresa y de la gestión del personal:
7
•
•
Organización menos jerarquizada, repartición sistemática y práctica de la
información.
Mejor gestión de los recursos humanos.
A nivel comercial:
•
•
•
•
Extensión del mercado potencial (comercio electrónico).
Una bajada de los costes logísticos.
Desarrollo de las innovaciones en servicios y respuestas a las necesidades de los
consumidores
Mejora de la imagen de marca de la empresa (empresa innovadora).
1.1.1. Importancia de las TIC en el sector bancario
Las TIC entraron con fuerza en el sector bancario, un sector que almacena y mueve
cantidades impresionantes de información. Sin las TIC hoy en día el consumidor no podría
disfrutar de muchísimas ventajas, algunas de ellas prescindibles, aunque otras quizá no:
•
•
•
Pago con tarjeta de crédito
Obtener efectivo desde un cajero automático
Realizar sus operaciones bancarias por internet
Para poder realizar todas estas tareas, se necesitaba de una base informatizada, con acceso
desde cualquier punto del mundo, donde cualquier transacción de dinero o el cobro de una
pensión no significaran más que el viaje de un poquito de información por internet.
El sector financiero está sometido a cambios constantes, producidos por el propio entorno
y naturaleza del mercado. Por esta razón es un sector pionero en la introducción de
tecnología e intensivo en su uso para lograr ventajas competitivas. Las entidades
financieras renuevan permanentemente sus infraestructuras de TI para adaptarlas a la
constante evolución de sus canales de distribución con objeto de incrementar su presencia
y mejorar la cantidad y calidad de los servicios financieros. En este sentido, afrontan dos
retos fundamentales: por un lado, flexibilizar su negocio para adaptarse rápidamente a la
evolución del mercado; y por otro, encontrar elementos diferenciadores en un entorno
competitivo muy agresivo. En este contexto, la innovación tecnológica es un factor clave.
Uno de los principales elementos diferenciadores reside en el modelo de relación con sus
clientes, área en la que más necesitan el apoyo de un socio tecnológico que les ayude a
generar modelos innovadores para fidelizar a los clientes existentes y penetrar en nuevos
segmentos. Internet, y en concreto las soluciones tecnológicas basadas en web 2.0, juegan
un papel clave en la mejora del modelo de relación.
El nivel de conocimientos financieros y exigencia de los clientes es mayor que hace unos
años, ya que ahora requieren de herramientas rápidas y seguras para sus interacciones con
la entidad financiera, y no sólo hablamos de banca ‘online’.
8
Las soluciones de movilidad, por ejemplo, permiten nuevas funcionalidades adaptadas a
las necesidades específicas de cada cliente. A medida que las tecnologías de redes móviles
evolucionan y los usuarios confían cada vez más en la seguridad de sus operaciones a
través de estos dispositivos, las entidades financieras adaptan este tipo de soluciones a sus
productos y servicios.
La tecnología aplicada a los nuevos canales ha revolucionando la relación de los clientes
con la entidad financiera, pero no hay que olvidar el canal tradicional, que continúa siendo
el más importante en las operaciones con clientes, especialmente en aquellas de mayor
valor añadido. Es importante contar con una tecnología actualizada que permita
personalizar el trato al cliente y optimizar la entrega de servicios. La tecnología es también
imprescindible para garantizar la seguridad en las transacciones y permitir que las
entidades financieras cumplan con la normativa vigente. En un contexto en el que cada vez
son más diversos, en cantidad y naturaleza, los medios de acceso a los servicios de banca,
las garantías de seguridad para el cliente son críticas.
Para ser capaces de poner en marcha todo lo anterior, es necesario contar con una
infraestructura tecnológica muy flexible que permita ir incorporando todos los productos y
servicios de la entidad por cualquiera de sus canales. La mejor forma de potenciar al
máximo la infraestructura de TI es contar con un socio capaz de integrar soluciones de
telecomunicaciones con soluciones de TI. De esta forma es posible contar con una red
capaz de transportar información de forma segura y a gran velocidad, a lo que se añaden
capacidades de TI que den el máximo rendimiento a esa información en sus múltiples
formatos.
Además, la actual coyuntura económica, que está afectando a las entidades financieras en
primer término, hace todavía más necesario incidir en la eficiencia operativa y en la
reducción de costes. La externalización de servicios TIC (outsourcing) puede resultar muy
ventajosa, contando con un socio tecnológico que proporcione un ahorro de costes
operativos, un mayor control del riesgo, y además genere ventajas direccionables hacia la
responsabilidad social corporativa de las entidades financieras, aplicando soluciones
sostenibles y comprometidas con el medio ambiente.
1.2. Necesidad
El cliente tiene una necesidad o un problema, y es aquí cuando se pone en contacto con su
socio tecnológico: Tecnocom. El evolutivo en cuestión cuenta con varios módulos que
amplían la anterior operativa para diferenciar sus centros u oficinas (y empleados de las
mismas) entre oficinas de Banca Privada y el resto.
La anterior operativa trataba a todas como igual, cuando unas necesitaban tener otras
opciones de operación a mano puesto que tienen un trato mucho más amigable con el
cliente. Es por esto que para los centros de banca privada se habilitaron módulos, y se
sustituyeron antiguos por otros modificados. El proyectante se ha centrado en el módulo de
Alertas (ver sección.
9
El cliente necesitaba que sus comerciales pudieran tener alertas de las operaciones que
tenían que realizar, como por ejemplo: dar de alta contratos a clientes de un grupo especial
para la semana siguiente, poder ver contratos pendientes de sus clientes…etc.
1.3. Herramientas para el desarrollo de trabajo
Para el desarrollo de las tareas realizadas, se ha hecho uso de varios programas
informáticos y entornos de trabajo.
La aplicación, como veremos más adelante, está ubicada en un servidor web Tomcat (Java)
el cual se puede instalar en el entorno de trabajo Eclipse.
Tomcat
Tomcat es un servidor web con soporte de servlets y JSPs. Tomcat no es un servidor de
aplicaciones, como JBoss o JOnAS. Incluye el compilador Jasper, que compila JSPs
convirtiéndolas en servlets. El motor de servlets de Tomcat a menudo se presenta en
combinación con el servidor web Apache.
Tomcat puede funcionar como servidor web por sí mismo. En sus inicios existió la
percepción de que el uso de Tomcat de forma autónoma era sólo recomendable para
entornos de desarrollo y entornos con requisitos mínimos de velocidad y gestión de
transacciones. Hoy en día ya no existe esa percepción y Tomcat es usado como servidor
web autónomo en entornos con alto nivel de tráfico y alta disponibilidad.
Dado que Tomcat fue escrito en Java, funciona en cualquier sistema operativo que
disponga de la máquina virtual Java.
Eclipse
La herramienta más usada en el mundo en programación Java y Web, además de otros
lenguajes de programación. Su fácil instalación, la gran cantidad de plugins y add-ons con
los que se puede trabajar hacen de él el mejor entorno de trabajo posible.
Por otra parte, el cliente ofrece librerías y plugins dedicados a este entorno de desarrollo
necesario para el desarrollo de la aplicación y su correcto funcionamiento.
Eclipse es un entorno de desarrollo integrado de código abierto multiplataforma para
desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecido", opuesto a las
aplicaciones "Cliente-liviano" basadas en navegadores. Esta plataforma, típicamente ha
sido usada para desarrollar entornos de desarrollo integrados (del inglés IDE), como el IDE
de Java llamado Java Development Toolkit (JDT) y el compilador (ECJ) que se entrega
como parte de Eclipse (y que son usados también para desarrollar el mismo Eclipse).
Eclipse es también una comunidad de usuarios, extendiendo constantemente las áreas de
aplicación cubiertas. Un ejemplo es el recientemente creado Eclipse Modeling Project,
cubriendo casi todas las áreas de Model Driven Engineering.
10
Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de
herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundación Eclipse, una
organización independiente sin ánimo de lucro que fomenta una comunidad de código
abierto y un conjunto de productos complementarios, capacidades y servicios.
Eclipse fue liberado originalmente bajo la Common Public License, pero después fue relicenciado bajo la Eclipse Public License. La Free Software Foundation ha dicho que
ambas licencias son licencias de software libre, pero son incompatibles con Licencia
pública general de GNU (GNU GPL).
1.4. Objetivos
•
•
•
•
•
•
Obtener una base teórica de programación web.
Configuración del entorno de desarrollo:
o Eclipse J2EE
o Apache Tomcat
o Struts framework
Conocer el funcionamiento de la aplicación global.
o Entender los objetivos de la aplicación.
o Distribución y estructuración del código interno.
Trabajo en grupo
o Conocer el funcionamiento de los repositorios SVN.
o Reparto de tareas.
o Comunicación con el equipo de trabajo para el correcto desarrollo de la
aplicación.
Desarrollo del módulo de Alertas: desarrollar un módulo completamente funcional
donde el empleado de nuestro cliente pueda realizar la operativa de alertas con
comodidad.
Diseño de la base de datos:
o Tablas a crear y relación entre ellas.
o Carga de datos
1.5. Planificación
En el siguiente diagrama de Gantt se detallan la duración de las distintas tareas en el
periodo de realización del proyecto:
11
Figura 1: Diagrama de Gantt de planificación
1.6. Organización de la memoria
Esta memoria se ha organizado de la siguiente manera:
En la sección 2 se describe la empresa donde se ha realizado el proyecto final de carrera.
Una breve información de ella, acompañada de la ubicación del proyectante en la empresa.
Además se describen
criben las distintas tareas realizadas por el estudiante.
En la sección 3 se describen todas y cada una de las tecnologías que el proyectante ha
usado directa e indirectamente durante la realización del proyecto.
En la sección 4 se explica el diseño del proyecto,
pr
, las especificaciones, los casos de uso y
los diferentes diagramas de flujo y clases.
En la sección 5 se explica el desarrollo del módulo Alertas. Todos los archivos .java
realizados, todas las páginas web, su
s estructuración y distribución.
Encontrarán
rán la sección 5 distribuida según la pantalla que se esté describiendo (o bien las
alertas, o el detalle de las alertas) y diferenciados según el tipo de archivo. Además
también podrán encontrar el desarrollo realizado según la tecnología a la que hacen
referencia
eferencia o si son de acceso a datos.
En la sección 6 encontrarán todo el juego de pruebas que se ha llevado a cabo durante la
realización del módulo Alertas.
12
Posteriormente encontrarán en la sección 7 las conclusiones derivadas de la realización del
proyecto, y finalmente la sección 8 donde encontrarán la bibliografía.
1.7. El Asesor de ventas
El Asesor de ventas es la gran aplicación donde se ubica el módulo de Alertas. Esta
aplicación que gestiona la empresa del proyectante, ofrece a los empleados del cliente una
operativa comercial cómoda, intuitiva y fácil de usar.
Los empleados del cliente podrán gestionar los datos de sus ventas, sus clientes, planificar
sus jornadas laborales, o visualizar resúmenes informativos de todo tipo de información
relativa a sus ventas y clientes.
1.7.1. El módulo de Alertas
El módulo que el proyectante ha realizado, Alertas, es uno de los varios resúmenes que
ofrece la aplicación Asesor de Ventas que, además ofrece vistas detalladas de los clientes y
varias operaciones a realizar sobre estos, como planificar un nuevo contacto sobre el
cliente, marcar alertas como tratadas, o visualizar la Ficha Comercial del cliente (ver
sección 5.8.2).
13
2. Descripción de la empresa
Tecnocom es una multinacional española que cotiza en la Bolsa de Madrid desde 1987. En
2006, Tecnocom inició un proceso Corporativo de expansión con el objetivo de llegar a ser
líder en el mercado de la tecnología de la información español.
Tecnocom es una de las cinco primeras empresas del sector de la tecnología de la
información en España (alrededor de 400 millones de euros de ingresos) con una amplia
experiencia en operaciones de elevado nivel tecnológico, como medios de pago bancarios
o sistemas de automatización. Su presencia regional incluye España, Portugal y América
Latina (Chile, Colombia, México, Perú, Brasil, Costa Rica y República Dominicana).
Domi
La empresa cuenta con una amplia oferta tecnológica y de soluciones de negocio, contando
con los sectores públicos y privados.
2.1. Ubicación del proyectante en la empresa.
En la siguiente imagen se muestra la distribución de la empresa:
Figura 2: Distribución de la empresa
El proyectante se ubica en el departamento de gestión de aplicaciones, desarrollando su
labor como Programador Junior en la aplicación GCF. El grupo de trabajo de la aplicación
se distribuye de la siguiente manera:
14
Figura 3: Ubicación del proyectante en la empresa
2.2. Descripción de las tareas realizadas
El proyectante ha realizado varias tareas desde su entrada en la empresa:
•
•
•
Módulos para aplicaciones
Evolutivos para aplicaciones
Testeo de las mismas para su distribución en producción.
El módulo de la aplicación realizado consta de varias tareas:
•
•
•
•
•
Aprendizaje de toda la aplicación: se necesitaba saber qué hace la aplicación y para
qué sirve para poder entenderla y realizar el módulo sin problemas. El módulo debe
comunicarse conn otros módulos de la misma aplicación hechos por otro integrante
del grupo de trabajo, o previamente existentes.
Diseño de la interfaz del usuario: el diseño lo elige siempre el cliente, por tanto, la
interfaz del usuario se debe ajustar a las exigencias de éste.
Diseño y realización del flujo de navegación: el cliente también especifica un flujo
de navegación determinado, no obstante hay que valorarlo y realizarlo.
Desarrollo de las JSPs
JSP y las clases Java.
Creación de las tablas Oracle y las llamadas a las mismas: se crearon las tablas en
Oracle,, definiendo las claves primarias y realizando el acceso a ellas desde la
aplicación, para su muestreo en la web y manejo de los datos online.
15
•
•
•
•
Realización de la carga de datos vía Batch: se desarrolló un script de SQL para la
carga de datos en las tablas de Oracle mediante la lectura de unos ficheros
preparados automáticamente y diariamente por el entorno Host en horario nocturno.
Integración del módulo con el resto de la aplicación.
Llamadas externas a otras aplicaciones.
Entradas externas a otras aplicaciones.
16
3. Tecnologías
Antes de hablar de las tecnologías utilizadas para el desarrollo del módulo, debería hablar
del patrón Modelo-Vista-Controlador:
Controlador:
Modelo Vista Controlador (MVC) es un patrón o modelo de abstracción de desarrollo de
software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de
negocio en tres componentes distintos. El patrón de llamada y retorno MVC, se ve
frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que
provee de datos dinámicos a la página. El modelo es el Sistema de Gestión de Base de
Datos y la Lógica de negocio, y el controlador es el responsable de recibir los eventos de
entrada desde la vista.
Figura 4: Esquema Modelo Vista-Controlador
Modelo
Esta es la representación específica de la información con la cual el sistema opera. En
resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las
presentaciones visuales complejas. El sistema también puede operar con más datos no
relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos
afines con el sistema modelado.
Vista
Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de
usuario.
Controlador:
Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y,
probablemente, a la vista.
Aunque se pueden encontrar diferentes implementaciones
implementaciones de MVC, el flujo que sigue el
control generalmente es el siguiente:
a) El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el
usuario pulsa un botón, enlace, etc.)
b) El controlador recibe (por parte de los objetos de la interfaz-vista)
interfaz sta) la notificación de
la acción solicitada por el usuario. El controlador gestiona el evento que llega,
frecuentemente a través de un gestor de eventos (handler)
(
o callback.
callback
17
c) El controlador accede al modelo, actualizándolo, posiblemente modificándolo de
forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador
actualiza el carro de la compra del usuario). Los controladores complejos están a
menudo estructurados usando un patrón de comando que encapsula las acciones y
simplifica su extensión.
d) El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de
usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada
para el usuario donde se reflejan los cambios en el modelo (por ejemplo, produce
un listado del contenido del carro de la compra). El modelo no debe tener
conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón
Observador para proveer cierta indirección entre el modelo y la vista, permitiendo
al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede
registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí
mismo sigue sin saber nada de la vista. Este uso del patrón Observador no es
posible en las aplicaciones Web puesto que las clases de la vista están
desconectadas del modelo y del controlador. En general el controlador no pasa
objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para
que se actualice.
e) La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo
nuevamente....
3.1. Java
Java es un lenguaje de programación orientado a objetos desarrollado por Sun
Microsystems a principios de los años 90. El lenguaje en sí mismo toma mucha de su
sintaxis de C y C++, pero tiene un modelo de objetos más simple y elimina herramientas
de bajo nivel, que suelen inducir a muchos errores, como la manipulación directa de
punteros o memoria.
3.1.1. Filosofía
Las aplicaciones Java están típicamente compiladas en un bytecode, aunque la compilación
en código máquina nativo también es posible. En el tiempo de ejecución, el bytecode es
normalmente interpretado o compilado a código nativo para la ejecución, aunque la
ejecución directa por hardware del bytecode por un procesador Java también es posible.
3.1.2. Orientado a objetos
El lenguaje Java se creó con cinco objetivos principales:
-
Debería usar la metodología de la programación orientada a objetos.
Debería permitir la ejecución de un mismo programa en múltiples sistemas
operativos.
Debería incluir por defecto soporte para trabajo en red.
Debería diseñarse para ejecutar código en sistemas remotos de forma segura.
18
-
Debería ser fácil de usar y tomar lo mejor de otros lenguajes orientados a objetos,
como C++.
3.1.3. Independencia de la plataforma
La segunda característica, la independencia de la plataforma, significa que programas
escritos en el lenguaje Java pueden ejecutarse igualmente en cualquier tipo de hardware.
Este es el significado de ser capaz de escribir un programa una vez y que pueda ejecutarse
en cualquier dispositivo, tal como reza el axioma de Java, “write once, run everywhere”.
Para ello, se compila el código fuente escrito en lenguaje Java, para generar un código
conocido como “bytecode” (específicamente Java bytecode) —instrucciones máquina
simplificadas específicas de la plataforma Java. Esta pieza está “a medio camino” entre el
código fuente y el código máquina que entiende el dispositivo destino. El bytecode es
ejecutado entonces en la máquina virtual (JVM), un programa escrito en código nativo de
la plataforma destino (que es el que entiende su hardware), que interpreta y ejecuta el
código. Además, se suministran bibliotecas adicionales para acceder a las características de
cada dispositivo (como los gráficos, ejecución mediante hebras o threads, la interfaz de
red) de forma unificada. Se debe tener presente que, aunque hay una etapa explícita de
compilación, el bytecode generado es interpretado o convertido a instrucciones máquina
del código nativo por el compilador JIT (Just In Time).
3.1.4. J2EE (Java Enterprise Edition)
Java Platform, Enterprise Edition o Java EE (anteriormente conocido como Java 2
Platform, Enterprise Edition o J2EE hasta la versión 1.4), es una plataforma de
programación—parte de la Plataforma Java—para desarrollar y ejecutar software de
aplicaciones en el lenguaje de programación Java con arquitectura de N capas distribuidas
y que se apoya ampliamente en componentes de software modulares ejecutándose sobre un
servidor de aplicaciones. La plataforma Java EE está definida por una especificación.
Similar a otras especificaciones del Java Community Process, Java EE es también
considerada informalmente como un estándar debido a que los proveedores deben cumplir
ciertos requisitos de conformidad para declarar que sus productos son conformes a Java
EE; estandarizado por The Java Community Process / JCP.
Java EE tiene varias especificaciones de API, tales como JDBC, RMI, e-mail, JMS,
Servicios Web, XML, etc. y define cómo coordinarlos. Java EE también configura algunas
especificaciones únicas para Java EE para componentes. Estas incluyen Enterprise
JavaBeans, servlets, portlets (siguiendo la especificación de Portlets Java), JavaServer
Pages y varias tecnologías de servicios web. Ello permite al desarrollador crear una
Aplicación de Empresa portable entre plataformas y escalable, a la vez que integrable con
tecnologías anteriores. Otros beneficios añadidos son, por ejemplo, que el servidor de
aplicaciones puede manejar transacciones, la seguridad, escalabilidad, concurrencia y
gestión de los componentes desplegados, significando que los desarrolladores pueden
concentrarse más en la lógica de negocio de los componentes en lugar de en tareas de
mantenimiento de bajo nivel.
19
3.2. JSP
Para la interfaz de usuario, se ha realizado todo mediante Java Server Pages (JSPs) y
JavaScript. Estas dos tecnologías nos han permitido crear una interfaz dinámica, que puede
cambiar según los datos de entrada o los de salida, o según las interacciones del usuario sin
tener que salir de la misma navegación.
JavaServer Pages (JSP) es una tecnología Java que permite generar contenido dinámico
para web, en forma de documentos HTML, XML o de otro tipo.
Esta tecnología es un desarrollo de la compañía Sun Microsystems. La Especificación JSP
1.2 fue la primera que se liberó y en la actualidad está disponible la Especificación JSP 2.1.
Las JSPs permiten la utilización de código Java mediante scripts. Además, es posible
utilizar algunas acciones JSP predefinidas mediante etiquetas. Estas etiquetas pueden ser
enriquecidas mediante la utilización de Bibliotecas de Etiquetas (TagLibs o Tag Libraries)
externas e incluso personalizadas.
3.3. JavaScript
Para ensalzar el dinamismo de la interfaz web, se ha utilizado JavaScript. JavaScript ha
permitido realizar validaciones web, tratamiento de datos para su presentación o para su
envío. Permite conectar los módulos con sencillas funciones implementadas rápidamente.
JavaScript es un lenguaje de programación interpretado. Se utiliza principalmente en su
forma del lado del cliente (client-side), implementado como parte de un navegador web
permitiendo mejoras en la interfaz de usuario y páginas web dinámicas, en bases de datos
locales al navegador... aunque existe una forma de JavaScript del lado del servidor (Serverside JavaScript o SSJS). Su uso en aplicaciones externas a la web, por ejemplo en
documentos PDF, aplicaciones de escritorio (mayoritariamente widgets) es también
significativo.
JavaScript se diseñó con una sintaxis similar al C, aunque adopta nombres y convenciones
del lenguaje de programación Java. Sin embargo Java y JavaScript no están relacionados y
tienen semánticas y propósitos diferentes.
Todos los navegadores modernos interpretan el código JavaScript integrado en las páginas
web. Para interactuar con una página web se provee al lenguaje JavaScript de una
implementación del Document Object Model (DOM).
Tradicionalmente se venía utilizando en páginas web HTML para realizar operaciones y
únicamente en el marco de la aplicación cliente, sin acceso a funciones del servidor.
JavaScript se interpreta en el agente de usuario, al mismo tiempo que las sentencias van
descargándose junto con el código HTML.
20
3.4. HTML
HTML, siglas de HyperText Markup Language (Lenguaje de Marcado de Hipertexto), es
el lenguaje de marcado predominante para la elaboración de páginas web. Es usado para
describir la estructura y el contenido en forma de texto, así como para complementar el
texto con objetos tales como imágenes. HTML se escribe en forma de "etiquetas", rodeadas
por corchetes angulares (<,>). HTML también puede describir, hasta un cierto punto, la
apariencia de un documento, y puede incluir un script (por ejemplo JavaScript), el cual
puede afectar el comportamiento de navegadores web y otros procesadores de HTML.
HTML también es usado para referirse al contenido del tipo de MIME text/html o todavía
más ampliamente como un término genérico para el HTML, ya sea en forma descendida
del XML (como XHTML 1.0 y posteriores) o en forma descendida directamente de SGML
(como HTML 4.01 y anteriores).
El lenguaje HTML puede ser creado y editado con cualquier editor de textos básico, como
puede ser Gedit en Linux, el Bloc de Notas de Windows, o cualquier otro editor que admita
texto sin formato como GNU Emacs, Microsoft Wordpad, TextPad, Vim, Notepad++,
entre otros.
Existen además, otros editores para la realización de sitios Web con características
WYSIWYG (What You See Is What You Get, o en español: “lo que ves es lo que
obtienes”). Estos editores permiten ver el resultado de lo que se está editando en tiempo
real, a medida que se va desarrollando el documento. Ahora bien, esto no significa una
manera distinta de realizar sitios web, sino que una forma un tanto más simple ya que estos
programas, además de tener la opción de trabajar con la vista preliminar, tiene su propia
sección HTML la cual va generando todo el código a medida que se va trabajando.
Algunos ejemplos de editores WYSIWIG son Macromedia Dreamweaver, o Microsoft
FrontPage.
3.4.1. DHTML
El HTML Dinámico o DHTML (del inglés Dynamic HTML) designa el conjunto de
técnicas que permiten crear sitios web interactivos utilizando una combinación de lenguaje
HTML estático, un lenguaje interpretado en el lado del cliente (como JavaScript), el
lenguaje de hojas de estilo en cascada (CSS) y la jerarquía de objetos de un Document
Object Model (DOM).
Una página de HTML Dinámico es cualquier página web en la que los scripts en el lado
del cliente cambian el HTML del documento, después de que éste haya cargado
completamente, lo cual afecta a la apariencia y las funciones de los objetos de la página. La
característica dinámica del DHTML, por tanto, es la forma en que la página interactúa con
el usuario cuando la está viendo, siendo la página la misma para todos los usuarios.
En una página DHTML, una vez ésta ha sido cargada completamente por el cliente, se
ejecuta un código (como por ejemplo en lenguaje JavaScript) que tiene efectos en los
valores del lenguaje de definición de la presentación (por ejemplo CSS), logrando así una
21
modificación en la información presentada o el aspecto visual de la página mientras el
usuario la está viendo.
3.4.2. Formularios
Un formulario o form es una etiqueta de HTML que representa un formulario. En este
formulario se agregan los diferentes campos de entrada de datos o de confirmación, así
como los botones, que como mínimo ha de haber uno, el de envío. También pueden
agregarse más botones como el de Restablecer que pone el formulario en blanco.
Los formularios en su envío mediante el atributo Action envían los datos del formulario a
una secuencia de comandos CGI, PHP, o bien ISAPI.
Los datos se envían de diferentes maneras, pero existen dos maneras de envío bien
diferenciadas: el POST y el GET. Cabe destacar que también puede ser enviado por
JavaScript, lo que ofrece mayor flexibilidad sobre el paso de datos sobre el lado del cliente,
que puedes ver en algunas páginas por ejemplo la de gMail en la página de registro se ve el
uso de JavaScript + AJAX que no hace falta cargar otra página confirmando/validando los
datos.
3.4.3. IFrame
IFrame (por inline frame o marco incorporado en inglés) es un elemento HTML que
permite insertar o incrustar un documento HTML dentro de un documento HTML
principal. Fue introducido en el navegador Microsoft Internet Explorer en 1997 y durante
mucho tiempo solo fue soportado en este navegador, la etiqueta IFrame actualmente es ya
aceptada por la W3 como un elemento estándar y es ampliamente soportado por gran
variedad de navegadores.
Los IFrames admiten diversos atributos como "Transparency" que permite una
visualización de la página mucho más atractiva ya que el fondo del IFrame va a ser
transparente, dejando ver el fondo original del archivo HTML principal.
Los documentos HTML también pueden incrustarse en otro documento a través del
elemento object.
Por otro lado, el uso de IFrames sirvió como inspiración de lo que hoy conocemos como
AJAX, ya que cada parte de un documento html es independiente
3.5. CSS
Las hojas de estilo en cascada (en inglés Cascading Style Sheets), CSS es un lenguaje
usado para definir la presentación de un documento estructurado escrito en HTML o XML
(y por extensión en XHTML). El W3C (World Wide Web Consortium) es el encargado de
formular la especificación de las hojas de estilo que servirán de estándar para los agentes
de usuario o navegadores.
22
La idea que se encuentra detrás del desarrollo de CSS es separar la estructura de un
documento de su presentación.
Ventajas que ofrece usar CSS:
-
-
-
Control centralizado de la presentación de un sitio web completo con lo que se
agiliza de forma considerable la actualización del mismo.
Los Navegadores permiten a los usuarios especificar su propia hoja de estilo local
que será aplicada a un sitio web, con lo que aumenta considerablemente la
accesibilidad. Por ejemplo, personas con deficiencias visuales pueden configurar su
propia hoja de estilo para aumentar el tamaño del texto o remarcar más los enlaces.
Una página puede disponer de diferentes hojas de estilo según el dispositivo que la
muestre o incluso a elección del usuario. Por ejemplo, para ser impresa, mostrada
en un dispositivo móvil, o ser "leída" por un sintetizador de voz.
El documento HTML en sí mismo es más claro de entender y se consigue reducir
considerablemente su tamaño (siempre y cuando no se utilice estilo en línea).
3.6. Struts2
Struts es una herramienta de soporte para el desarrollo de aplicaciones Web bajo el patrón
MVC bajo la plataforma Java EE (Java Enterprise Edition). Struts se desarrollaba como
parte del proyecto Jakarta de la Apache Software Foundation, pero actualmente es un
proyecto independiente conocido como Apache Struts.
Struts permite reducir el tiempo de desarrollo. Su carácter de "software libre" y su
compatibilidad con todas las plataformas en las que Java Entreprise esté disponible lo
convierten en una herramienta altamente disponible.
Con la versión 2 del framework se introdujeron algunas mejoras sobre la primera versión,
de cara a simplificar las tareas más comunes en el desarrollo de aplicaciones web, así como
mejorar su integración con AJAX, etc.
3.7. AJAX
En la aplicación se ha realiza un gran uso de esta tecnología, puesto que permite acceder a
datos sin tener que salir de la misma página de navegación:
AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML),
es una técnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet
Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los
usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo
plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de
recargarlas, lo que significa aumentar la interactividad, velocidad y usabilidad en las
aplicaciones.
AJAX es una tecnología asíncrona, en el sentido de que los datos adicionales se solicitan al
servidor y se cargan en segundo plano sin interferir con la visualización ni el
23
comportamiento de la página. JavaScript es el lenguaje interpretado (scripting language)
en el que normalmente se efectúan las funciones de llamada de AJAX mientras que el
acceso a los datos se realiza mediante XMLHttpRequest, objeto disponible en los
navegadores actuales. En cualquier caso, no es necesario que el contenido asíncrono esté
formateado en XML.
AJAX es una técnica válida para múltiples plataformas y utilizable en muchos sistemas
operativos y navegadores dado que está basado en estándares abiertos como JavaScript y
Document Object Model (DOM).
3.8. Oracle PL/SQL
Para acceder a datos, se ha utilizado una base de datos Oracle a la cual se puede acceder
con diversos programas y entornos de desarrollo como Toad, Pl/SQL Developer o
SQLPlus.
Oracle es un sistema de gestión de base de datos objeto-relacional (o ORDBMS por el
acrónimo en inglés de Object-Relational Data Base Management System), desarrollado por
Oracle Corporation.
PL/SQL (Procedural Language/Structured Query Language) es un lenguaje de
programación incrustado en Oracle. PL/SQL soportará todas las consultas, ya que la
manipulación de datos que se usa es la misma que en SQL, incluyendo nuevas
características.
En un entorno de base de datos los programadores pueden construir bloques PL/SQL para
utilizarlos como procedimientos o funciones, o bien pueden escribir estos bloques como
parte de scripts SQL*Plus.
Los programas o paquetes de PL/SQL se pueden almacenar en la base de datos como otro
objeto, y todos los usuarios que estén autorizados tienen acceso a estos paquetes. Los
programas se ejecutan en el servidor para ahorrar recursos a los clientes.
3.8.1. Vistas (views)
Una vista es un objeto. Una vista es una alternativa para mostrar datos de varias tablas; es
como una tabla virtual que almacena una consulta. Los datos accesibles a través de la vista
no están almacenados en la base de datos, en la base de datos se guarda la definición de la
vista y no el resultado de ella.
Entonces, una vista almacena una consulta como un objeto para utilizarse posteriormente.
Las tablas consultadas en una vista se llaman tablas base. En general, se puede dar un
nombre a cualquier consulta y almacenarla como una vista.
Una vista suele llamarse también tabla virtual porque los resultados que retorna y la
manera de referenciarlas es la misma que para una tabla.
Las vistas permiten:
24
•
•
Simplificar la administración de los permisos de usuario: se pueden dar al usuario
permisos para que solamente pueda acceder a los datos a través de vistas, en lugar
de concederle permisos para acceder a ciertos campos, así se protegen las tablas
base de cambios en su estructura.
Mejorar el rendimiento: se puede evitar escribir instrucciones repetidamente
almacenando en una vista el resultado de una consulta compleja que incluya
información de varias tablas.
3.9. Host(PL1) y Batch
En el entorno de nuestro cliente, se accede al entorno Host, basado en PL1 (viejo lenguaje
de programación creado por IBM hacia 1970…) mediante transacciones monitorizadas
para acceder a datos protegidos. En el grupo de trabajo del proyectante, existen integrantes
que realizan los módulos en este entorno de trabajo para devolver los datos según se
requiera.
Hay varios requisitos para poder acceder a estas transacciones desde el entorno de
desarrollo:
Para empezar, el desarrollador debe estar conectado a una red que nos proporciona el
cliente para usuarios externos. También se necesita poseer un usuario dado de alta en las
bases de datos del cliente asignado a un centro virtual para empleados externos.
Por otro lado, el desarrollador necesita “abrir” su terminal de desarrollo diariamente. Esta
apertura consiste en realizar una entrada en los entornos del cliente: Test, Pre-producción o
Producción (ver sección 6).
Una vez el usuario cumple estos requisitos, podrá realizar estas transacciones que vienen
controladas con unas librerías que ofrece el cliente.
Por otra parte, se usan procesos Batch realizar tareas Host o Java en procesos de horario
nocturno. Los procesos Batch se ejecutan fuera de horario de oficina del cliente, para no
utilizar recursos del servidor mientras los empleados realizan sus operaciones.
Periódicamente, las bases de datos del cliente necesitan un control que la operativa en línea
no puede realizar por motivos de saturación del servidor. Este periodo puede variar según
el programa, desde ejecuciones diarias y semanales hasta trimestrales o anuales.
Estos procesos realizan tareas tales como carga de datos diarios o del día, descarga de
datos inservibles u obsoletos, o actualizaciones masivas de datos según ficheros de
configuración que realicen otras aplicaciones.
Dado que el entorno del cliente es muy extenso, el número de aplicaciones de distintos
proveedores que acceden a unos mismos datos es muy grande, como por ejemplo, datos de
clientes. Una aplicación podría modificar estos datos a su antojo y provocar los errores en
otras aplicaciones.
25
Para solucionar este problema y, como norma general, cada aplicación crea sus módulos
de operaciones. Si una aplicación necesita ejecutar ciertas operaciones en tablas de otra
aplicación, se llama al módulo correspondiente de la aplicación consultada y si se puede
realizar un proceso Batch que trate las tablas de datos de la aplicación consultante con los
resultados de la operación.
El cliente tiene millones de datos en tablas DB2, que necesitan ser tratados y controlados
mediante Batch casi siempre diariamente, y uno de esos procesos formará parte de la carga
de alertas en Oracle (ver sección 5.9).
Cabe mencionar que los procesos Batch no se ejecutan en el entorno del desarrollador
(entorno local), si no en los entornos del cliente.
26
4. Diseño del proyecto
En la presente sección se describe el diseño del proyecto, las especificaciones y los
distintos diagramas de flujo de navegación y clases, entre otros.
4.1. Especificaciones
El cliente quiere una aplicación donde sus empleados puedan ver sus alertas. Este módulo,
formará parte de una aplicación ya existente, por tanto no se tiene demasiado margen de
maniobra.
La aplicación global funciona en un servidor apache Tomcat, y está programada en Java 2
Enterprise Edition. Dado que el módulo debe formar parte de la aplicación (será una subpestaña del Asesor de Ventas), el entorno de trabajo, el servidor, y el lenguaje de
programación no podrán variar, puesto que el cliente los exige así.
Por otro lado, se tuvo que decidir sobre las tablas de datos. Por un lado se podrían haber
creado las tablas en DB2 de IBM, i acceder a ellas mediante transacciones Host. Sin
embargo, se decidió hacer las tablas Oracle y realizar los accesos mediante los JDBC (Java
Database Connectivity) que nos proporciona el entorno J2EE. La ventaja de tener las tablas
en DB2 es que los datos provenían de otras aplicaciones, que también tienen los datos en
DB2. Así pues, un programa nocturno que cogiera los datos de una tabla DB2, los tratara y
los insertara en otra tabla DB2 de nuestra aplicación, hubiera sido bastante sencillo.
Además, el acceso a estas tablas desde el entorno web es relativamente fácil y muy seguro.
Sin embargo, nos decantamos por la otra opción: crear las tablas Oracle y realizar los
accesos mediante JDBC.
La decisión fue fácil: los accesos a DB2 y las tablas DB2 son mucho más caros que los
accesos a Oracle. Por tanto, la decisión fue consensuada entre el cliente y la empresa. Pero
si los datos están en DB2, debemos poder trasladar los datos a las tablas Oracle. Para
conseguirlo, el mismo programa que trata los datos de una tabla DB2, en vez de insertarlos
en otra tabla DB2, crea un fichero diario con los datos que se deben insertar y/o eliminar de
la tabla Oracle. Este programa se ejecuta mediante unos procesos Batch que se ejecutan
fuera de horario de oficinas.
Por tanto, cuando arranca la aplicación por la mañana (cada día se reinicia el servidor), se
ejecuta un script que carga el fichero en la tabla de Oracle, con lo cual, los datos que
tendremos de alertas serán calculados diariamente.
Teniendo el acceso a datos ya decidido a Oracle, y los entornos los decide el cliente, la
aplicación ya estaba lista para ser desarrollada, ya que el hecho de querer usar otra
tecnología para realizar una tarea debía tener el consentimiento del cliente. Esta tecnología
ha de ser instalada en los servidores del cliente y, teniendo en cuenta que otras tecnologías
existentes también podrían desempeñar las mismas funciones, la elección fue fácil.
27
4.2. Diseño
En las siguientes imágenes se muestran los prototipos de las dos pantallas a realizar.
Figura 5: Pantalla de Alertas
Figura 6: Pantalla del detalle de una alerta.
El cliente quiere este diseño con los mínimos cambios posibles. Por tanto habrá que crear
los estilos CSS correspondientes, las imágenes de información o teléfono las proporciona
el cliente, y el estilo de la web debe ir en concordancia con el resto de la aplicación.
No obstante, la ventana de información de cliente no vino especificada por el cliente. En
un principio no se supo si iba a ser una ventana o un “tooltip” de información. Optamos
por la ventana de información, que mostraría la información de la alerta, tanto de gestor
28
como de cliente. Por tanto, se realiza una ventana modal respecto a la aplicación para
evitar una posible acumulación de ventanas en el navegador.
Figura 7: Diseño ventana información de alerta.
4.2.1. Definición de Alerta
Ya hemos visto que una alerta es más o menos, como un “aviso” para un gestor o
empleado de evento pendiente de ocurrir, como el aniversario de uno o varios clientes, o
por ejemplo una acción que debe realizar el empleado en un periodo a ciertos clientes, o
simplemente un aviso personal.
Para ello crearemos un objeto Java llamado Alerta, con los campos correspondientes para
poder llevar a cabo el desarrollo del módulo.
4.2.2. Casos de uso
En el siguiente diagrama se muestran los diferentes casos de uso que presenta el proyecto.
Figura 8: Diagrama de casos de uso
29
4.2.3. Flujo de navegación / diagrama de clases
En las especificaciones del módulo se indica que el cliente decide el flujo de navegación de
la web. El proyectante se limita a cumplir el requisito del cliente haciendo uso de las
tecnologías que tiene a su alcance.
Como pueden ver más detalladamente en la sección 5, el diseño web está basado en
IFrames.
s. Esto nos beneficia a la hora de realizar distintas tareas durante el desarrollo. El
hecho de filtrar los datos que deban aparecer por pantalla nos obligaría a recargar la página
web. Sin embargo, el uso de IFramess nos permite sólo recargar la zona de resultados,
conservando los datos del filtro, y sin necesidad de volver a ejecutar todas las operaciones
de entrada en la aplicación.
Ell siguiente diagrama de clases detalla el flujo de navegación del módulo según los
eventos que pueden ocurrir mediante la interacción con el usuario. Para su correcta
interpretación, se debe entender que un evento que ejecuta una operación y da una JSP
comoo resultante, no significa que la interfaz gráfica cambie por completo y sólo se vea la
JSP cargada, si no que puede ser que sólo se recargue el IFrame correspondiente al
objetivo del formulario.
Figura 9: Diagrama de clases y flujo de navegación
30
4.2.4. Tablas Oracle
El diagrama de las tablas será el siguiente:
Figura 10: Esquema de tablas Oracle
Como se puede observar, las alertas se distribuirán en 3 tablas distintas, además de 2 vistas.
A continuación se detallan las tablas, sus campos y propósitos.
4.2.4.1.
CRM_ALERTAS
La tabla CRM_ALERTAS es la que contiene los datos de un tipo de alerta. Una alerta
tiene clave COD_ALERTA y F_INI (Fecha de inicio).
Los otros campos son:
•
Fecha fin
31
•
•
•
Descripción de la alerta en castellano
Descripción de la alerta en catalán
Tipo de alerta (de cliente o de gestor)
El resto de campos (TITOL1, LONG1, POS1,…TITOL6,LONG6,POS6) describen los
detalles que puede tener el tipo de la alerta como por ejemplo: Expediente, fecha de alta,
NIF…
En esta tabla se listarán todos los tipos de alertas habidas. Se consultará para obtener las
fechas y las descripciones para mostrar por pantalla, además de conseguir los datos de la
ventana de información de alerta.
4.2.4.2.
CRM_ALERTAS_CENTRO_GESTOR
La tabla CRM_ALERTAS_CENTRO_GESTOR es una tabla auxiliar que será la tabla
consultada en la pantalla de Alertas (o resumen de Alertas). La clave será COD_ALERTA,
F_INI, GESTOR, CENTRE.
Para cada fila de éstas, habrá un campo numérico que explica el número de clientes
adheridos a la alerta. Este número Total corresponde a la cantidad de registros de la tabla
CRM_DETALLE_ALERTAS con misma clave.
4.2.4.3.
CRM_DETALLE_ALERTAS
La tabla CRM_DETALLE_ALERTAS es la tabla que contiene los datos del detalle de una
alerta. La clave de la tabla es COD_ALERTA, F_INI, GESTOR, CENTRE y NUMPER
(número de persona / cliente).
Para cada cliente adherido a una alerta, existirá un registro en esta tabla indicando varios
campos:
•
•
•
•
•
•
•
Si la alerta está visada
Nombre del cliente
Primer apellido del cliente
Segundo apellido del cliente
NIF del cliente
Teléfono del cliente
Observaciones: un campo libre donde el empleado podrá ver las observaciones que
haya puesto otro empleado al crear la alerta.
Además también existen otros campos: (DADE1,…DADE6) donde se guardan los
distintos expedientes que puede llegar a tener cada cliente. Estos datos no se usan bajo la
operativa de alertas, aunque sí en otros módulos de la aplicación.
32
5. Desarrollo e Implementación
En esta sección se detallan brevemente el entorno de desarrollo y la toma de contacto con
la aplicación para entrar en el módulo de Alertas.
5.1. Entorno de desarrollo
Para la realización del módulo se ha utilizado un eclipse J2EE con un servidor Tomcat que
implementa la tecnología struts, además de otras muchas librerías libres y otras
pertenecientes al cliente. Este entorno nos lo facilita el cliente.
Por otra parte, los empleados de nuestro cliente acceden a la aplicación mediante un
programa que utiliza el motor de Internet Explorer 7. Sin embargo, otros usuarios pueden
entrar a la aplicación desde un IPad de Apple, que poseen una aplicación que utiliza el
motor de Safari. Para solucionar esto se tuvo que adaptar las páginas web para ambos
navegadores.
5.2. Entrada en la aplicación
Para poder entrar en la aplicación es necesario tener un código de usuario dado de alta en
las tablas de datos del cliente, incluso para desarrollar en local. En la pantalla de
identificación, los desarrolladores pueden modificar el usuario de entrada para hacer
distintas pruebas.
5.2.1. User.java
Una vez validado el usuario, la transacción de validación devuelve todos los datos del
usuario/empleado que entra en la aplicación. Estos datos se guardarán en un objeto llamado
User que se guardará en sesión, y se podrá acceder a él en cualquier lugar de la aplicación.
5.2.2. El identificador de conversación (idConversation)
A la vez que se valida el usuario, se crea el identificador de conversación o
idConversation. Este campo identifica la sesión del usuario para poder obtener siempre los
datos correctos. Además realiza tareas de tiempo de espera, y obliga siempre a tener un
identificador activo para poder realizar cualquier operativa en la aplicación.
5.2.3. Las pestañas
Figura 11: Pestañas principales de la aplicación Asesor de Ventas
Dentro de la interfaz que el usuario ve cuando entra en la aplicación, se observa un
pestañero donde se puede seleccionar:
•
•
Clientes: lista de clientes y las distintas operaciones que el empleado puede
gestionar.
Alertas: lista de alertas, eventos de fidelización, ideas comerciales y públicos
objetivos. Dentro de esta pestaña se ubica el módulo desarrollado.
33
•
•
Planificador: en esta pestaña está todo lo relativo a contactos con clientes o
personales.
Resumen: en el resumen podrán ver listas de seguimientos, resúmenes de tiempo y
varias operaciones más.
5.2.4. Las sub-pestañas
Figura 12: Sub-pestañas del módulo de Alertas
Navegando por las pestañas superiores vemos sub-pestañas que se pueden escoger. Dentro
del módulo de alertas se pueden apreciar las siguientes:
•
•
•
•
Alertas: el usuario podrá ver un resumen de las alertas por centro y gestor. La
operativa de alertas se ubica dentro de esta sub-pestaña.
Ideas comerciales: el usuario podrá ver un resumen de las ideas por centro y gestor.
Eventos de fidelización: el usuario podrá ver un resumen de los eventos por centro
y gestor.
Públicos objetivos: el usuario podrá dar de alta ideas y eventos a clientes o
personales.
5.3. Archivo de configuración de Struts (Struts-config.xml)
Dentro de este archivo .xml se definen 5 aspectos básicos del modelo vista-controlador:
•
•
•
•
Actions: el usuario deberá definir cada Action visto para ejecutar, y a qué JSP se
deberá redirigir. En cierto modo, es aquí donde, en parte, se especifica el flujo de
navegación a seguir.
Global Forwards: se pueden definir redirecciones globales también, como por
ejemplo las ejecuciones con error, las ejecuciones correctas, las vistas de PDF, etc.
Forms: el usuario deberá definir cada formulario Java dentro de este xml.
Recursos de texto: todos los recursos de mensajes o texto deben ir definidos aquí.
5.4. Recursos de texto
Una vez más, el cliente exige que la aplicación esté disponible en dos idiomas: castellano y
catalán. Los recursos de texto nos permiten tener archivos de texto con etiquetas o
identificadores que refieren a un texto en concreto.
Para el módulo de alertas se ha creado un recurso de texto que cuenta con dos archivos,
uno para catalán y otro para castellano:
•
•
PantallaAlertas-Text_es.properties
PantallaAlertas-Text_ca.properties
34
Estos dos archivos contienen exactamente las mismas etiquetas pero con descripciones que
difieren en el idioma.
5.5. Entrada en el módulo Alertas
Para acceder al módulo de Alertas, se debe clicar en la pestaña de Alertas y,
posteriormente, en la sub-pestaña del mismo nombre. Este link ejecuta el Action de entrada
al módulo: PantallaAlertasAction.java
Antes de entrar en más detalle, debemos profundizar en la organización de la pantalla: por
convención en la aplicación, todos los módulos están divididos en varias zonas:
•
Pantalla: la pantalla contiene todo lo demás (cabecera, filtro, resultados y pie). Es el
superior que invoca al resto para que se carguen uno a uno. Contiene los datos y
funciones globales a la que podrán acceder las pantallas “hijas”. En la siguiente
imagen se muestra la ubicación de este tipo de JSPs encuadrada en verde:
Figura 13: Ubicación de la JSP del resumen de Alertas
•
Cabecera: la cabecera solamente posee una etiqueta con la descripción de la
pantalla. Esta descripción puede ser fija o dinámica. Fija en el caso de que sea una
pantalla general, como Alertas, o dinámica, cambiante según si la pantalla es, por
ejemplo, el detalle de una alerta. Aquí se suelen ubicar también links para volver,
para realizar exportaciones a Excel y PDF, o de ayuda. En la siguiente imagen se
muestra la ubicación de este tipo de JSPs encuadrada en verde:
35
Figura 14: Ubicación de la JSP de cabecera
•
Filtro: El filtro es una de las 3 piezas importantes de la pantalla (filtro, resultados y
pie). En el filtro se muestran combos de selección con los que el usuario podrá
cambiar la entrada y así filtrar los datos que saldrán en los resultados. Cada filtro
vendrá precedido siempre de su etiqueta, y al final de todo habrá un botón “filtrar”,
que enlazará con el Action de filtrar correspondiente. En la siguiente imagen se
muestra la ubicación de este tipo de JSPs encuadrada en verde:
Figura 15: Ubicación de la JSP de filtro
•
Resultados: La pantalla de resultados suelen ser siempre tablas del mismo estilo
CSS que nos indica el cliente, pudiendo variar estos en pocos términos
establecidos. Las tablas pueden ser dinámicas mediante la tecnología Ajax. Con
JavaScript y las etiquetas o “tags” de struts podemos iterar entre los distintos datos
para crear las tablas según los datos de salida.
36
Hay que destacar que estas pantallas de resultados van incluidas en IFrames, puesto
que así no hay que recargar la página entera a la hora de filtrar, si no que sólo se
recargan los resultados y el pie en función de los datos.
En la siguiente imagen se muestra la ubicación de este tipo de JSPs encuadrada en
verde:
Figura 16: Ubicación de la JSP de resultados
•
Pie: En el pie se ponen los botones o menús de acciones sobre los resultados o los
links a otras pantallas según la opción escogida de los resultados. Aquí suele ir gran
parte de la operativa que el usuario puede realizar sobre los resultados obtenidos.
En la siguiente imagen se muestra la ubicación de este tipo de JSPs encuadrada en
verde:
Figura 17: Ubicación de la JSP de pie
37
A excepción de la cabecera, ya que no necesita tratamiento de datos, cada una de estas
zonas de la página web, tiene como mínimo un Action que trata sus datos y los devuelve, y
una JSP que los muestra, es decir, para la pantalla general (contenedor de todo) existe un
PantallaAlertasAction.java (entrada de datos, tratamiento de los mismos, y de vuelta al
controlador) y un PantallaAlertas.jsp (envía los datos de entrada a un Action por url o
mediante un submit de un form y espera la respuesta del Action que se ha llamado).
Ventanas emergentes, alertas o confirmaciones no siguen esta convención como norma
general, aunque hay casos excepcionales, como la ventana de nuevo contacto, que veremos
más adelante.
5.5.1. Actions
Antes de comenzar a explicar los Actions del módulo Alertas, explicaré qué pasos siguen
como norma general:
Los Action reciben por parámetro de entrada un form base, que se deberá hacer “cast” al
form correspondiente del módulo. Si el form llega nulo, se cogerán los datos de sesión.
5.5.1.1.
PantallaAlertasAction.java
Este Action obtiene la entrada que llega por parámetros y gestiona esos datos según dos
opciones:
•
No hay datos en sesión (de Alertas)
En este caso, la operativa que se realiza es coger los datos del usuario guardados en sesión
para obtener su identificador de centro e identificador de empleado, además de parámetros
como tipo empleado que nos servirá para dictaminar los permisos que podrá tener el
usuario.
Lo primero es recuperar los datos del centro del usuario: la lista de gestores para mostrarla
en el filtro. Para ello se llamará a una transacción Host que devolverá los datos según el
empleado, el tipo y el centro.
Por otro lado, debemos saber si el empleado ha entrado en su centro por defecto o no,
puesto que en caso de que haya entrado por un centro distinto (obviamente debe de tener
permisos para poder hacerlo), la transacción anterior no devolverá su propio nombre en la
lista de gestores, puesto que se estará consultando otro centro en el cual no está adscrito.
En este caso, obtendremos la lista de gestores del centro consultado (no el por defecto),
añadiendo manualmente al empleado consultante al principio de la lista.
Por último y, antes de devolver el control al controlador, este Action guarda los datos en
sesión, para que no se deba volver a recoger y tratar los datos anteriores.
•
Hay datos en sesión
38
Si hay datos en sesión, significa que ya hemos pasado por aquí previamente, hemos
navegado desde alertas hasta otra pestaña y hemos vuelto a alertas, o simplemente hemos
vuelto a clicar sobre la sub-pestaña de alertas.
Naturalmente, no todos los datos se guardan en sesión, puesto que estos datos se están
guardando en el servidor y ocupando memoria. Se debe procurar por petición del cliente,
mantener el mínimo de memoria consumiendo puesto que es una aplicación que usan miles
de empleados al instante, sobre todo en horas punta.
Por eso, sólo guardamos en sesión los datos del centro o equipo (id de centro, descripción
de centro), el id de empleado y el nombre del empleado, además del tipo de centro. La
lista de gestores se renovará automáticamente cada vez que se llame al módulo por si hay
cambios, puesto que un usuario puede realizar un cambio, como por ejemplo, añadirse a
otro centro, y en ese caso, una nueva consulta debería de devolver el mismo empleado
también.
El proceso final es igual para ambas opciones (con datos en sesión o sin datos): se retorna
el control al controlador, que busca en el archivo de configuración struts-config.xml a qué
JSP se debe redirigir, enviando los datos tratados para que puedan ser mostrados. En este
caso, será la pantalla PantallaAlertas.jsp
5.5.1.2.
AlertasFiltrarAction.java
En este Action se obtienen los datos del filtro que el usuario ha escogido. Con estos datos
se accede a las tablas de Oracle para obtener la lista de alertas que se mostrarán por
pantalla, en el IFrame de resultados.
Se instancia un objeto tipo AlertasDAO (ver sección objetos locales), que contiene las
funciones de acceso a Oracle según unos parámetros de entrada. Se distinguen dos pasos:
•
•
Si el gestor seleccionado es “Todos”, el código de este gestor es 0. Por tanto se
deben consultar todas las alertas del centro.
Si el gestor seleccionado es diferente de 0, buscaremos las alertas de ese gestor,
perteneciente al centro de consulta.
Ver sección AlertasDAO (5.3.6.2.1) para más detalle sobre la consulta a Oracle.
Una vez obtenemos la lista, guardamos los datos del filtro en sesión, para poder
recuperarlos en cualquier otra ocasión, y retornamos el control al controlador. Siempre que
se ejecute este Action, se redirigirá a la JSP AlertasResultados.jsp
5.5.1.3.
DetalleAlertas
Cuando el usuario hace clic sobre una alerta de cliente, navegará hasta el detalle de la
alerta. En esta sección se detallan todos los Actions relacionados con la vista del detalle de
una alerta.
39
5.5.1.3.1.
PantallaDetalleAlertasAction
En este Action simplemente recogeremos el form de sesión si el que nos llega por
parámetros llega nulo. En caso de que obtengamos parámetros, crearemos un nuevo form
para guardar este nuevo en sesión.
Para finalizar, devuelve
PantallaDetalleAlertas.jsp.
5.5.1.3.2.
el
control
al
controlador
para
redirigir
a
la
jsp
DetalleAlertasResultadoAction
En este Action también recogeremos el form de sesión si el que nos llega por parámetros
llega nulo. En caso de que obtengamos parámetros, crearemos un nuevo form para guardar
este nuevo en sesión.
Proseguimos a consultar el detalle de la alerta. Para ello se crea un objeto
DetalleAlertasDAO
y
se
llama
a
su
función
consultarPorIdAlertaFCreacionGestorCentroNoVisadas(). Esta función retorna las alertas
ordenadas por fecha de creación, correspondientes al gestor seleccionado previamente y
que no estén visadas. Para más detalle sobre la función, diríjase al punto 5.5.7.2.2
(DetalleAlertasDAO).
Una vez tenemos el listado se redirigirá a la JSP DetalleAlertasResultados.jsp
5.5.1.3.3.
DetalleAlertasResultadoRefrescarAction
Una vez se han visado alertas, o bien se ha hecho algún cambio como un nuevo contacto
sobre algún cliente. Se deben refrescar la lista de detalles. Este Action resuelve el problema
extendiendo de la clase DetalleAlertasResultadoAction.
En este caso, siempre se recupera el form de sesión, se crea uno nuevo con esos datos y se
vuelve a guardar con sólo los datos necesarios para la consulta.
Al finalizar, invoca al Action padre, que se ejecutará normalmente, y el resultado será un
refresco de la pantalla de resultados.
5.5.1.3.4.
DetalleAlertasVisarAction
Este Action realiza dos operaciones. Por parámetro llegará una lista de números de cliente
que vendrán por url separados por “$$”.
Primeramente se crea un objeto DetalleAlertasDAO y se llama a la función visarAlertas().
Teniendo la clave de la alerta en sesión, y la lista de números de cliente (o numper) a visar,
podemos ir a la base de datos a visar estos clientes en la tabla
CRM_DETALLE_ALERTAS.
Una vez visados, se debe modificar la tabla CRM_ALERTAS_CENTRO_GESTOR para
modificar el número total de clientes adheridos a una alerta, ya que al visar X clientes, el
número siempre se verá reducido.
40
Una vez acabado, el Action, que extiende de la clase DetalleAlertasResultadoAction,
guarda el form en sesión para devolver la ejecución a la clase padre.
5.5.1.4.
Ventana Información del cliente
Cuando el usuario clica sobre una alerta de gestor, se abre la ventana de información de la
alerta.
5.5.1.4.1.
VentanaAlertasInfoClienteAction
Cuando se ha hecho la consulta a la base de datos para obtener la lista de alertas, ya
obtenemos todos los datos necesarios para mostrar la ventana de cliente. Así pues no es
necesario volver a consultar la alerta mediante la clave para obtener esos datos adicionales
que no se pueden mostrar en la tabla. En este caso, los parámetros se envían por url, que el
form de la ventana recogerá y devolverá a la JSP VentanaAlertasInfoCliente.jsp.
En caso de estar ubicados en el detalle de una alerta, si se clica sobre el botón de
información, también se ejecutará este Action. Sin embargo, se ha de diferenciar, ya que si
estamos en el detalle de la alerta, significa que la alerta tiene clientes y, por tanto, es de
cliente.
5.5.2. Forms
Los forms en Java son clases auxiliares que sólo contienen variables con getters y setters.
El entorno struts relaciona automáticamente las variables que puedan llegar desde un
submit o por url y crea un Form base con estas variables en sus mismos nombres.
Haciendo un cast al form correspondiente, se consigue tener los datos de I/O en un objeto.
5.5.2.1.
PantallaAlertasForm.java
Este es el formulario de la pantalla general de alertas. Contiene variables para la entrada,
salida y paginación.
Entrada
•
•
•
•
•
•
•
Centro
Tipo de centro
Equipo
Descripción de centro o equipo
Identificador del gestor
Nombre del gestor
Asignación del empleado
Salida
•
•
Lista de gestores
Lista de alertas
41
•
Identificador de la alerta seleccionada
Paginación
•
•
•
Siguiente
Anterior
Tipo de paginación
5.5.2.2.
PantallaDetalleAlertasForm.java
Este es el formulario de la pantalla del detalle de una alerta.
Entrada
•
•
•
•
•
•
•
•
•
Origen
Identificador de alerta seleccionada
Descripción de alerta seleccionada
Número total de clientes
Fecha de creación de la alerta
Identificadores concatenados de alertas a visar
Pantalla de origen
Centro de ejecución
Identificador de gestor
Salida
•
Lista de detalles de la alerta.
Paginación y control
•
•
•
Ordenación de la tabla.
Siguiente
Anterior
5.5.3. JSPs
En esta sección se detallan las JSPs que conforman el módulo de Alertas.
5.5.3.1.
PantallaAlertas.jsp
Esta es la pantalla principal de alertas. Como ya hemos visto, por convención en la
aplicación, todos los módulos están divididos en varias zonas:
•
•
•
Pantalla
Cabecera
Filtro
42
•
•
Resultados
Pie
Se crea una tabla invisible que separará las distintas JSPs e IFrames. Con la etiqueta
<jsp:include> podemos incluir un archivo JSP dentro del trozo de código para tenerlo todo
distribuido y organizado. Así, se incluirán las JSP AlertasCabecera.jsp y AlertasFiltro.jsp
Además, se incluye un IFrame que ejecutará el Action AlertasFiltrarAction, que cogerá los
datos de la pantalla AlertasFiltro.jsp como parámetros de entrada, y éste redirigirá a la
pantalla AlertasResultados.jsp.
Por otra parte, se incluyen en esta página todos los JS globales que se necesitan para las
distintas funcionalidades de la pantalla que son globales para la aplicación, además de los
JS propios del módulo Alertas que contienen las funcionalidades propias de Alertas.
5.5.3.2.
AlertasCabecera.jsp
En esta pantalla se crea una tabla invisible (muy utilizada en toda la aplicación) para
distribuir los elementos que la constituyen. La cabecera de de la pantalla de Alertas es
simple:
Existe una etiqueta con el título “Alertas”, y además aparecerá uno o varios links de acceso
a la administración de las alarmas según si el usuario tiene acceso a ellos. Para saber si el
usuario puede ver los links, tenemos una variable en sesión que se obtiene en la misma
entrada del usuario en la aplicación, puesto que servirá también para otros módulos. En
caso de que pueda ver los links, debemos acceder a otra variable más para poder distinguir
si puede ver todos los links (2) o sólo uno de ellos. Esta variable también está en sesión y
se obtiene también durante la entrada del usuario en la aplicación.
5.5.3.3.
AlertasFiltro.jsp
Después de mostrar la pantalla de la cabecera, seguidamente se mostrará la pantalla del
filtro.
Primeramente se define un formulario llamado “formFiltro”. Se le añadirán los atributos
“Action” y “target”. El atributo Action define el Action a ejecutar en el servidor una vez se
haga un submit del form. El atributo target hace referencia al IFrame donde se cargarán las
JSPs de resultados.
Mediante las etiquetas <script> podemos insertar código JavaScript que se ejecutará en el
cliente, para poder hacer un control de los datos tratados previamente para su muestreo
correcto.
Primeramente se incluye una caja de texto donde se verá el id del centro y la descripción
del mismo. Pegado al mismo, se incluye un botón que abrirá una ventana de selección de
centro, donde el usuario podrá seleccionar el centro por el cual quiere consultar las alertas
y los gestores.
43
Para ello se llamará a la función JavaScript abrirVentanaCentroBPR(), incluida en el js
global Ventana.js. Esta función abre una ventana en la cual el usuario podrá cambiar el
centro consultante:
Figura 18: Ventana de selección de centro
Si el usuario tiene los permisos adecuados, podrá cambiar de centro, incluso filtrar por los
equipos de su oficina si su cargo lo permite. Al aceptar esta ventana, se ejecuta otra
función que cambia la descripción del centro en el filtro. Sin embargo, si el usuario entra
por otro centro, la lista de gestores que tenemos en el filtro deberá cambiar.
Seguidamente del botón para cambiar de centro, se incluye una “combo” o “select” de html
en el cual el usuario podrá elegir el gestor para filtrar. Los gestores que aparecen aquí son
los previamente tratados en el Action de entrada. Sin embargo, si el usuario cambia el
centro consultante, no podrá elegir un gestor del centro previamente calculado, puesto que
nos los tenemos. Por ello debemos llamar a un servicio Ajax.
Para ello se llama a una función JavaScript que prepara los datos actuales del filtro de
centro para obtener los gestores de la misma manera que se obtuvieron en la entrada del
módulo. Pero esta vez queremos que se recarguen sin tener que recargar la página web, por
ello usamos Ajax. Esta función realiza la llamada Ajax que ejecuta el Action
AJAXGestoresDelCentroBPR.java.
Una vez ejecutado en el servidor, la respuesta es interceptada vía JavaScript, y se itera
sobre la lista de gestores para modificar la select ya existente. De esta manera conseguimos
una gran comodidad para el usuario de la aplicación.
Para finalizar vemos un botón filtrar. Si el usuario pulsa sobre el botón, se hace un submit
del form que contiene todos los datos para poder volver a calcular los resultados.
44
5.5.3.4.
AlertasResultados.jsp
Primeramente de todo, se definen todos los includes que tendrá la página, desde .js y .jsj
del módulo Alertas como otros de la aplicación global.
Como siempre, se crea una tabla invisible para distribuir los componentes uniformemente.
Se crea un form de nombre “alertas” cuyo Action será PantallaDetalleAlertasAction.
¿Porqué? Muy sencillo, los links que se pueden llegar a crear en la tabla de alertas
únicamente conducirán al detalle de una Alerta o a la ventana de información de cliente.
¿Cómo se diferencia esto? Una alerta puede ser de cliente o bien de gestor, como bien se
ha dicho. Si una alerta es de cliente, el link de esta alerta conducirá al detalle de la alerta,
donde podrá ver la lista de clientes adheridos. En cambio, si la alerta es de gestor, es una
alerta personal, que lanzará una ventana emergente con la información de la alerta.
Proseguimos. Se guardan los campos clave (centro, gestor, y sus respectivas descripciones)
en campos ocultos para que se envíen mediante un submit. Se crea la tabla de los
resultados y se itera entre la lista de alertas proveniente de filtrar. Se hace un control
simple para cambiar el estilo de cada fila. Si la fila es par, el fondo será blanco, si es impar,
el fondo será de un color gris-azulado, para crear un efecto “pijama” que ayudará al
usuario a distinguir las filas con una simple mirada.
Durante la iteración sobre la lista de alertas, se debe ir muestreando fila a fila según cada
posición de la lista. Pero, además, debemos hacer varias diferenciaciones:
•
Si la alerta es raíz de otras:
La alerta no se podrá consultar y el total será la suma de todas las alertas hijas. Sin
embargo se podrá desplegar como vemos más adelante.
•
Si la alerta es de cliente:
La alerta se podrá consultar con un link en la descripción y en el total. La consulta redirige
la página al detalle de la alerta. Si la alerta es de cliente pero no tiene clientes adheridos, no
aparecerá por pantalla y el programa Batch nocturno la eliminará.
•
Si la alerta es de gestor:
La alerta no tiene detalles o clientes adheridos, por tanto sólo se podrá consultar desde la
ventana de información de alerta.
El número “Total” de la tabla, equivale al total de clientes adheridos a la alerta. Si la alerta
es de gestor, se mostrará 0 y no será clicable. Si la alerta es de cliente, se mostrarán la
cantidad de clientes adheridos a la alerta y además tendrá un link que dirige al detalle de la
alerta seleccionada.
45
Para finalizar, a cada fila de la tabla se le inicializa un campo estado a cerrado. Cuando el
usuario visualiza por primera vez la página, todas las alertas que sean raíz de otras, o
padres aparecerán con un icono “+” para desplegarlas, pues todas estarán cerradas.
5.5.3.5.
AlertasPie.jsp
En la pantalla de alertas no hay ninguna acción que pueda realizar el usuario, por tanto la
existencia de esta jsp es puramente decorativa, para distribuir y encajar el resto de la
pantalla.
5.5.3.6.
Detalle de Alerta
En esta sub-sección se detallan las JSPs que conforman la interfaz de la pantalla del detalle
de una alerta.
5.5.3.6.1.
PantallaDetalleAlertas.jsp
Esta es la pantalla principal del detalle de una alerta. Como en la anterior pantalla
principal, se crea una tabla invisible que separará las distintas JSPs y IFrames. Con la
etiqueta <jsp:include> podemos incluir un archivo JSP dentro del trozo de código para
tenerlo todo distribuido y organizado. Así, se incluirá la JSP DetalleAlertasCabecera.jsp.
Además se incluirá el IFrame de resultados que invocará directamente el Action
DetalleAlertasResultadoAction sin pasar por ningún tipo de filtro, ya que, realmente, el
filtro de esta pantalla no deja de ser más que la pantalla anterior (resumen de alertas.
Por otra parte, también se incluyen en esta página todos los JS globales que se necesitan
para las distintas funcionalidades de la pantalla que son globales para la aplicación, además
de los JS propios de la operativa de DetalleAlertas que contienen las funcionalidades
propias para el detalle de una alerta.
5.5.3.6.2.
DetalleAlertasCabecera.jsp
En esta pantalla se crea una tabla invisible para distribuir los elementos que la constituyen.
La cabecera de de la pantalla del detalle de una alerta es simple:
La etiqueta del título variará según la alerta que estemos consultando. Por tanto es uno de
los parámetros obligatorios que se deben enviar desde el resumen de alertas. Por otro lado,
debemos averiguar qué idioma está usando el usuario, y para ello accedemos al objeto
User.java desde JavaScript, y definimos una variable idioma según la cookie con la que
entró en la aplicación.
A la derecha del todo, saldrá un link de vuelta al resumen de alertas. Para poder formar
este link, se necesitan los parámetros del filtro con el que entramos la última vez, por tanto
se deben enviar por url al destino, para que el usuario no tenga que volver a filtrar (si es
que lo hizo) con los mismos datos.
46
5.5.3.6.3.
DetalleAlertasResultados.jsp
Primeramente de todo, se definen todos los includes que tendrá la página, desde .js y .jsj
del módulo Alertas como otros de la aplicación global. Además, se guardan en variables
JavaScript los datos del filtro de la pantalla anterior con los que se ha llegado aquí. Estos
servirán para poder realizar las operaciones correctas en el acceso a la base de datos.
Para empezar, la lista de clientes puede ser nula: aunque en el resumen de la alerta, si la
alerta es de clientes pero tiene 0 clientes adheridos, no se podrá consultar el detalle si no
que se redirige a la ventana de información de alerta; si se consulta el detalle de una alerta
con N clientes y se visan todos y cada uno de los clientes entonces regresamos al detalle de
alerta sin ningún posible cliente. Por ello debemos controlar que la caja o checkbox raíz
(Todos los clientes de la selección) no debe de ser clicable para proteger la web de un mal
uso.
Seguidamente se crea un formulario, llamado clientes. El Action de este formulario será
DetalleAlertasResultadoAction, con el target (objetivo) el IFrame de resultados:
AlertasDetalleResultadoIFrame.
Primeramente se crea una tabla con las cabeceras correspondientes. A partir de aquí se
itera sobre la lista de detalles para ir creando la tabla fila a fila siguiendo esta casuística:
A la izquierda de cada fila, debe haber un checkbox para seleccionar los clientes deseados
y operar con ellos. A cada checkbox se le asigna un identificador que equivale al número
de cliente de la fila. Así, en el momento de hacer una de las operaciones del pie de página,
se recorre la lista de checkbox de la tabla vía JavaScript para ver cuáles son seleccionados,
y se obtiene una lista de id’s que equivale a la lista de clientes seleccionados.
La siguiente columna será siempre un icono de información que, al clicar, llama a una
función JavaScript definida en el JS AlertasDetalleResultadoIFrame.js que redirige a la
ventana de información de cliente.
Acto seguido se añade la columna “nombre del cliente” fusionando los tres campos del
nombre de forma <apellido1 apellido2, nombre>. La siguiente columna será el NIF del
cliente, que será clicable y abrirá una ventanita con el NIF si el cliente posee una DNI
digital.
Por último, se añade la columna del teléfono. Para esta columna se llama a la función
printPhone() definida en el JS c2c.js que muestra el teléfono en la tabla y además, si el
empleado tiene un teléfono de oficina conectado al ordenador, puede llamar al cliente con
un solo click. Para realizar esta tarea, se usan unas librerías que nos ofrece el cliente y
nosotros adaptamos para su uso en la aplicación.
Finalmente se incluye la JSP DetalleAlertasPie.jsp que contendrá los botones de operación
sobre los clientes.
47
5.5.3.6.4.
DetalleAlertasPie.jsp
A diferencia con la pantalla de alertas, que no tiene operativa a pie de página, la pantalla
del detalle de una alerta tiene tres botones de acciones:
•
Nuevo contacto: el botón de nuevo contacto abre una ventana que pertenece a otro
módulo de la aplicación: el planificador. La llamada, eso sí, se ha tenido que
adaptar para su correcto funcionamiento. Mediante JavaScript, se preparan los
datos a enviar y pueden surgir dos opciones:
o Sólo un cliente seleccionado: Se abrirá la ventana de nuevo contacto para
que el empleado pueda crear un contacto con el cliente.
o Varios clientes seleccionados: Se abrirá la ventana de nuevo contacto
masivo, donde el usuario podrá escoger un perfil de contacto y crearlo para
todos los clientes seleccionados de una vez.
•
Servicio BPR: el botón de servicio BPR redirige la pantalla totalmente a otra
aplicación que se encuentra en un entorno totalmente distinto, aunque no ajeno a
nuestro proyecto. El proyecto de la empresa comprende a varias aplicaciones y éste
botón redirige a una de ellas: la Ficha comercial del cliente. En esta ficha el
empleado podrá ver todos los datos comerciales del cliente, además amplios y
variados resúmenes relacionados con el asesor de ventas. Sólo se permite visualizar
la ficha comercial de un cliente. Si se selecciona más de uno, el usuario recibirá una
alerta visual que le indica que sólo puede seleccionar un cliente.
•
Visar alertas: el último botón permite visar una alerta. Al seleccionar uno o más
clientes, se determina que la alerta para esos clientes ya ha sido tratada. Una vez la
alerta tiene todos los clientes tratados, ya no aparecerá en la pantalla de resumen de
alertas. Este botón hace que se ejecute el Action DetalleAlertasVisarAction.
Cabe decir que si el usuario no selecciona ningún cliente, saltará una alerta visual que se lo
indica.
5.5.4. JS’s
Los archivos JS son archivos JavaScript que se pueden incluir en webs HTML para su
acceso. Es recomendable externalizar las funciones JavaScript en archivos JS para poder
acceder a ellas donde interese.
En nuestro caso, agruparemos los JS en dos grupos: los pertenecientes y de exclusivo uso
del módulo de Alertas, y los globales de uso por parte de toda la aplicación.
5.5.4.1.
Globales
Los JS globales se incluyen en toda la aplicación. Contiene funciones JavaScript genéricas
relacionadas con ventanas, funcionalidades, tablas que no hace falta repetir en cada
módulo.
48
5.5.4.1.1.
Boxover.js
Este archivo JavaScript contiene las funciones para crear “tooltips” o recuadros de
información automáticos cuando el usuario pasa el ratón por encima de algún objeto. Por
ejemplo, si el usuario pasa el ratón por encima del icono de información de del detalle de
una alerta, aparecerá un recuadro de información.
5.5.4.1.2.
Ventana.js
Este archivo JavaScript contiene las funciones de toda la aplicación para abrir ventanas.
Hay funciones genéricas que se pueden modificar para hacer saltar la ventana deseada.
5.5.4.1.3.
Funcionalitats.js
Este archivo JavaScript contiene funciones genéricas relativas a cálculos de fechas,
numéricos y alfanuméricos.
5.5.4.1.4.
Prototype.js, Poslib.js y ScrollButton.js
Estos archivos proveen un entorno de desarrollo JavaScript para facilitar el desarrollo de
páginas web dinámicas. Funciones genéricas que repintan la pantalla a nuestro gusto.
5.5.4.1.5.
C2c.js
Este archivo JavaScript contiene las funciones relativas al “click to call” o click para
telefonear. Si el usuario tiene un teléfono conectado al ordenador, le saldrá un “popup”
para realizar la llamada sobre el número de teléfono.
5.5.4.1.6.
Sorttable.js
Este archivo JavaScript contiene las funciones relativas al orden de la tabla. Para el detalle
de la alerta, se puede ordenar la tabla por orden ascendente o descendente según la
columna nombre del cliente, teléfono o NIF.
5.5.4.2.
Módulo Alertas
Aquí se incluyen los JS de uso exclusivo por el módulo de Alertas. Contienen funciones
específicas para el módulo de Alertas que servirán para tratar los datos, hacer llamadas a
AJAX, etc.
5.5.4.2.1.
AlertasResultadoIFrame.js
En este JS se definen las funciones correspondientes al IFrame de resultados de la pantalla
del resumen de alertas.
•
Cambiar imagen
Cuando el usuario despliega una alerta padre, el icono “+” cambia por el icono “-“ y
viceversa.
49
•
Cargar alertas
Cuando el usuario despliega una alerta, se hace una llamada al Ajax
AJAXAlertasDesplegar que consulta a la base de datos las alertas que debe mostrar en caso
de no haberlas consultado antes.
Una vez consultadas las alertas, se crea una instancia de la clase DynamicTable por cada
alerta obtenida pasando por parámetro los datos de cada alerta.
Una vez se han pintado, se indica el campo estado de la fila pintada a abierto.
•
Borrar alertas
Es el proceso contrario a la carga de alertas. Si una alerta está desplegada, al volverla a
plegar se crea una instancia de la clase DynamicTable para borrarlas, indicando el estado
de las filas pintadas a cerradas.
•
•
Linkar al detalle de alerta
Abrir ventana información de alerta
5.5.4.2.2.
AlertasPantallaIFrame.js
En el js general de la pantalla de alertas, tenemos todas las funciones globales a las que se
accederá desde el filtro y la cabecera.
Entre las funciones a destacar son:
•
•
•
•
•
•
•
•
Guardar los datos del filtro en variables JavaScript.
Obtener la respuesta del Ajax de selección de centro.
Llamada al Ajax de carga del combo de Gestores, una vez se haya cambiado de
centro.
Obtener la respuesta del Ajax de carga de combo de Gestores.
Abrir la ventana de información de alerta
Funciones para redirigir al detalle de la alerta según si la alerta es de cliente y es o
no raíz de otras alertas.
Función filtrar. En esta función se recogen los datos actuales del filtro y se hace un
submit del form del filtro para su recogida en el Action correspondiente.
Abrir la ventana de selección de centro.
5.5.4.2.3.
AlertasDetalleResultadoIFrame.js
En este archivo JavaScript se detallan las funciones siguientes:
•
Abrir ventana información de cliente.
Cada icono de información contiene los datos necesarios para llamar a esta función. Abre
una ventana modal que muestra la información del cliente.
50
•
Abrir ventana nuevo contacto.
Al seleccionar un cliente y pulsar sobre el botón nuevo contacto llama a la ventana Nuevo
Contacto perteneciente al módulo Planificador del asesor de ventas. Informando el número
de cliente y el centro y el gestor, automáticamente prepara los datos de la ventana para
realizar un nuevo contacto sobre el cliente para el empleado ejecutor sobre su centro.
•
Seleccionar todos los clientes
Esta función se ejecuta al seleccionar el checkbox raíz (Todos los clientes de la selección).
Deja todos los checkbox de todos los clientes seleccionados para su posterior operación.
•
Deseleccionar todos los clientes
Si todos los clientes están seleccionados, al seleccionar el checkbox raíz de nuevo, se
deseleccionarán todos.
•
Visar alertas
Esta función llama al Action AlertasDetalleVisarAction enviando por parámetros la lista
de clientes seleccionados.
•
Validar la selección
Esta función valida que la selección sea correcta en cada caso, como por ejemplo, si no hay
ningún contacto seleccionado y se quiere visar una alerta, saltará una alerta visual avisando
al usuario.
5.5.5. DHTML
En esta sección se incluye los JS que extienden del prototipo DHTML de la aplicación.
5.5.5.1.
alertasListadoAlertas.dynamic.table.js
En este archivo JS se habilitan las funciones para la creación de la tabla dinámica de
alertas.
Una vez se ha accedido por AJAX a la base de datos y se han obtenido las alertas hijas, hay
que mostrarlas por pantalla en la tabla. Para ello se hace uso del DHTML.
Al ejecutar la función create() de este JS, este crea desde JavaScript una fila en la tabla en
la posición correcta. Por parámetros de entrada deben llegar los campos de la alerta nueva
a mostrar (código de alerta, descripción, fecha, tipo de alerta y total) además de la posición
de la tabla a pintar, además de los campos del filtro para poder crear los links necesarios,
ya que cada fila nueva debe funcionar como las anteriores.
5.5.6. Acceso a datos
En este apartado se detallan los distintos accesos a datos según la tecnología utilizada.
51
5.5.6.1.
AJAX
Como nota general, todos los Javas de AJAX extienden de la clase AJAXBase.java. Así se
consigue que todas las transacciones AJAX son monitorizadas y el control de errores está
unificado en una sola función para todas las llamadas, lo cual nos ahorra tiempo y código.
5.5.6.1.1.
AJAXGestoresDelCentroBPR.java
Este Ajax es ejecutado via JavaScript. En este Ajax llama a la misma transacción de
entrada en el módulo para obtener los gestores del centro. Una vez obtiene los gestores, los
preparara y los trata para que sean mostrados en la pantalla.
5.5.6.1.2.
AJAXAlertasDesplegar.java
Este Ajax ejecutado vía JavaScript cuando el usuario quiere desplegar una alerta que es
padre de otras. Como parámetros de entrada necesita los parámetros del filtro: centro y
gestor y la identificación de la alerta que se está desplegando.
Después de validar los datos se crea un objeto AlertasDAO. Si tenemos un gestor
seleccionado en el filtro que no sean “Todos”, se llama a la función
consultarPorCentro_AGRUPADO_TODOS().
Si no, se llamara a la función
consultarPorIdAlertaCentroGestor().
Una vez recuperadas las alertas, via JavaScript y utilizando DHTML, se modificará la tabla
previamente creada para que aparezcan justo debajo de la alerta padre.
5.5.6.2.
DAO
En los archivos denominados como DAO (Data Access Object) se realizan las
transacciones a Oracle mediante JDBC. En cada DAO hay varias funciones que realizan la
llamada de una manera u otra, según se necesite: consultar alertas por centro, consultar
alertas por identificación de alerta, o visar clientes de alertas, entre otros…
5.5.6.2.1.
AlertasDAO
En este DAO existen varias funciones, algunas de ellas se llaman entre sí para devolver
varios datos de una vez:
•
Consultar número de clientes.
Accede a la tabla CRM_ALERTAS_CENTRO_GESTOR y obtiene el número de clientes
adheridos a una alerta.
•
Consultar alertas por centro, gestor Todos agrupadas.
Accede a la vista del listado de alertas por centro y gestor y obtiene las alertas de todos los
gestores.
52
Las alertas tienen un identificador y una fecha de creación, que actúa como secuencial. Por
tanto, cuando decimos que una alerta es padre de otras, significa que es la alerta con fecha
de creación anterior, y las hijas, las posteriores con un mismo identificador.
Esta función obtiene solamente las alertas padres de todos los gestores.
•
Consultar alertas por centro y gestor.
Accede a la vista del listado de alertas por centro y gestor y obtiene las alertas del gestor
adherido al centro. No distingue de alertas padres o hijas.
•
Consultar alertas por centro, gestor agrupadas.
Accede a la vista del listado de alertas por centro y gestor y obtiene las alertas padres del
gestor adherido al centro.
•
Consultar alertas por identificación de alerta.
Accede a la vista del listado de alertas por centro y gestor y obtiene las alertas hijas de una
alerta del gestor adherido al centro.
•
Consultar alertas por clave de alerta.
Accede a la vista del listado de alertas y obtiene los datos de una alerta.
•
Visar alertas.
Esta función se ejecuta después de visar N clientes de la alerta desde del
DetalleAlertasDAO. Se accede a la tabla CRM_ALERTAS_CENTRO_GESTOR y se
modifica el campo Total para actualizarlo con el nuevo campo calculado, que equivale al
número total de clientes menos los clientes visados.
•
Visar todas las alertas.
Esta función se ejecuta después de visar todos los clientes de la selección. Se accede a la
tabla CRM_ALERTAS_CENTRO_GESTOR y se modifica el campo Total para ponerlo a
0.
5.5.6.2.2.
DetalleAlertasDAO
En este DAO existen también varias funciones:
•
Consultar clientes por identificación de alerta, fecha creación, gestor y centro no
visadas.
Se accede a la vista del detalle de alertas y se recuperan los clientes adheridos a la alerta,
con fecha de creación específica, gestor “Todos” o único, centro y que no hayan sido
tratadas. Si el usuario entra en el detalle de una alerta hija, se ejecutará esta operación para
obtener la lista de clientes adheridos a esta alerta hija.
53
•
Consultar clientes por clave de alerta, centro y gestor.
Se accede a la vista del detalle de alertas y se recuperan los clientes adheridos a la alerta
del gestor adherido a un centro. Esta función se ejecuta cuando el usuario entra en el
detalle de una alerta padre, ya que no diferencia por fecha de creación de la alerta.
•
Visar detalles de alertas (clientes)
Esta función actualiza la tabla CRM_DETALLE_ALERTAS poniendo el campo visada a
“S” para una lista de clientes. Esta lista de clientes deben formar parte de una misma alerta,
ya se hija o padre.
5.6. Objetos Java locales
Dado que estamos programando en Java, un lenguaje orientado a objetos, crearemos dos
tipos de objetos auxiliares que nos ayudarán en el desarrollo de nuestra aplicación.
5.6.1. Alerta
El primer objeto auxiliar será la Alerta. Contendrá los datos básicos que necesitan ser
mostrados por pantalla:
•
•
•
•
Código de alerta
Descripción de la alerta.
Total.
Fecha fin de la alerta.
En los Actions del resultado de alertas, se devuelve al controlador un formulario con una
lista del objeto Alertas. Como nota, la descripción de la alerta variará si el usuario entra
con idioma catalán o castellano. Por tanto, en el momento de acceder a las tablas Oracle se
debe recuperar la descripción correcta.
5.6.2. Detalle Alertas
Este objeto contendrá los datos básicos que deberán aparecer en la tabla de resultados,
además de la clave de la alerta que se está consultando, así pues serán los siguientes:
•
•
•
•
•
•
•
Código de la alerta
Descripción de la alerta
Fecha de creación de la alerta
Número de cliente
Nombre del cliente
Teléfono del cliente
Nif del cliente
Y dos campos indicadores:
•
Indicador de DNI digital
54
•
Indicador de alerta visada
Los Actions del resultado del detalle de la alerta también funcionan de la misma manera
que el anterior.
5.7. Entradas externas
En este apartado se detallan las entradas al módulo alertas desde cualquier aplicación
externa al asesor de ventas.
5.7.1. GCFEntradaAlertasAction
Para las entradas externas, o entradas directas a Alertas desde otra aplicación que no sea el
asesor de ventas, se ha creado el Action GCFEntradaAlertasAction. Este Action es un
equivalente al PantallaAlertasAction, con la diferencia de que se deben validar los datos
que, si estuviéramos dentro de la aplicación, ya se habrían validado.
Esta entrada debe recibir un parámetro origen, que indica la aplicación origen o que
invoca. Dependiendo del origen el usuario podrá tener todos o sólo algunos permisos, o
simplemente ver una versión reducida de la aplicación.
5.7.2. GCFEntradaDetalleAlertasAction
Para esta entrada se necesitarán más datos que en la anterior, puesto que estamos entrando
directamente al detalle de una alerta, por tanto, debemos pasar la clave de la alerta, el
centro, el gestor, además de los datos del usuario consultante. Se tratarán los datos de
entrada y se guardarán en sesión como si hubiésemos entrado desde la misma aplicación.
Igualmente recibe el parámetro origen con el mismo propósito que el anterior.
5.8. Acceso a otras aplicaciones
Desde el módulo de alertas se puede acceder a otras operativas de nuestro cliente, tanto de
la misma aplicación como de otros entornos. Estos accesos están ubicados a pie de página
en el detalle de una alerta.
5.8.1. Módulos de la misma aplicación
En este apartado se explica la operación de crear un nuevo contacto sobre el cliente, el
único acceso a un módulo de la aplicación Asesor de Ventas.
5.8.1.1.
Nuevo contacto sobre el cliente
Sobre el cliente, o varios, se pueden crear contactos. Cuando un empleado crea un
contacto, está guardando en la aplicación que va a visitar a un cliente, o entrevistarlo, o
simplemente una llamada telefónica, entre otros.
Desde el detalle de la alerta, se ofrece la posibilidad de crear un contacto sobre ese cliente
rápidamente sin tener que crearlo desde 0.
55
5.8.2. Ficha Comercial del cliente
También sobre el cliente, aunque en este caso solamente uno, se puede redirigir a otra
aplicación: la ficha comercial. Esta aplicación pertenece a otro entorno que está situado en
otros servidores de nuestro cliente. Por ello, las pruebas de este acceso no se han podido
realizar en el entorno local (sección 6), si no que se han tenido que realizar en el entorno
Test.
5.9. Carga y tratado de datos
Como se detalla en las especificaciones (ver sección 4.1), los datos de alertas se guardan en
tablas DB2, sin embargo el módulo de Alertas accede a tablas Oracle para obtener los
datos, por tanto se necesitan dos procesos: un proceso Batch nocturno que se ejecutará
diariamente para guardar los datos de Alertas en ficheros, y un script bash que cargará
diariamente las tablas Oracle con estos datos.
5.9.1. Procesos Batch
En el siguiente diagrama se muestran la relación de procesos Batch que cargan los datos en
Oracle:
Figura 19: Esquema de relación de los procesos Batch de carga de datos
•
•
•
El programa CtlALERTAS_CRM.ctl carga la descripción de alertas enviadas desde
Host.
El programa CtlALERTAS_CENTRO_GESTOR_CRM.ctl carga la relación de
alertas con centros-gestores.
El programa CtlALERTAS_DETALLE_CRM.ctl carga la relación de clientes para
una alerta de centro-gestor.
56
Como se detalla en la definición de procesos Batch en la sección 3.9, estos procesos no se
ejecutan en el entorno del desarrollador. Por tanto es otro de las tareas que sólo podrán ser
probadas en los entornos del cliente.
5.9.2. Tratado de datos en Oracle
Los datos existentes en la tabla de Oracle también necesitan ser tratados diariamente. Para
ello se crea un script SQL que se ejecuta durante el arranque de la aplicación por la
mañana.
Este script borra los registros de la tabla CRM_ALERTAS cuyo campo Tipo sea “abierta”
y no tenga detalles. Es decir, cuando el usuario visa todos los detalles de una alerta, ya no
debe aparecer en el resumen de alertas. Este hecho ya se controla mediante el acceso a
datos, sin embargo, se deben borrar los registros de la tabla Oracle ya que no se van a usar.
57
6. Juego de pruebas / Evaluación
Para el correcto funcionamiento del módulo, se ha debido hacer un exhaustivo juego de
pruebas, tal y como exige el cliente. El cliente exige que la aplicación sea funcional sin
errores el día que sustituya a la aplicación anterior. Así pues, el 60% del tiempo destinado
al desarrollo del módulo, se ha invertido en pruebas.
Por otro lado, diferenciaremos las pruebas realizadas, en los distintos entornos a los que
tenemos acceso. Primeramente nos centraremos en el método seguido: prueba y error. La
velocidad del entorno en aplicar los cambios realizados sobre la aplicación ha facilitado
mucho esta tarea. Por consiguiente, se mencionan los distintos entornos de pruebas que
tenemos en la empresa, y los que el cliente pone a nuestra disposición.
6.1. Prueba y error
Todo el módulo se ha ido desarrollando a base de prueba y error. Probar los casos más
inverosímiles para ajustar al mínimo los posibles errores cuando llegue a manos de nuestro
cliente.
El entorno de pruebas de local (más adelante explicado), ha facilitado este método de
pruebas, puesto que los cambios realizados se publican en el servidor en unos pocos
segundos. Esto da pie a realizar un código paso por paso, prácticamente línea por línea o
función por función para ir probando todo a medida que se va desarrollando. Cada link,
cada función JavaScript, cada iteración sobre la lista de alertas, el acceso a los distintos
idiomas… todo se ha desarrollado y probado a la vez.
6.2. Entorno local
Como se ha explicado anteriormente, el entorno local consiste de un eclipse J2EE con un
servidor Tomcat que implementa la tecnología struts. Los desarrolladores tenemos la
aplicación completa en nuestro entorno local, sin embargo otras aplicaciones como la
Ficha Comercial no se podían tener publicados en el mismo entorno local a la vez, puesto
que esto requeriría muchos recursos y los ordenadores no estaban preparados.
Por eso, todas las pruebas realizadas en el entorno de local tienen referencia al módulo o la
misma aplicación. Sin embargo, todas las pruebas referentes a otras aplicaciones, se debían
probar primeramente en los distintos entornos del cliente.
Para el resto de pruebas de local, primeramente se cargaron las tablas Oracle con datos de
prueba: varios tipos de Alertas con códigos o identificadores inventados, relación de alertas
por centro-gestor en base al centro de pruebas y el usuario del proyectante, y clientes
totalmente inventados con nombres, NIF y teléfonos ficticios. Esta serie de datos
constituyeron el primer juego de pruebas, sobre el que se sustentó el desarrollo de la
interfaz web y gran parte de la operativa:
•
Creación del flujo de navegación: eventos como el filtrado, la navegación a la
página de detalle de alertas y su posterior vuelta a la página de resumen, etc.
58
•
•
Desarrollo de la interfaz web: creación de los estilos CSS apropiados de las tablas e
iconos, desarrollo e implementación de las funciones DHTML para el desplegado
de Alertas en la página de resumen, etc.
Acceso a datos: desarrollo de las clases que acceden a las tablas Oracle para
obtener los datos de alertas y su posterior tratamiento en los distintos Actions de la
operativa.
Con estos datos de prueba, se desarrolla el prototipo que se envía al cliente para que éste lo
valide y dé permiso para continuar el desarrollo del módulo. Este prototipo no es funcional,
puesto que las operaciones del detalle, a excepción de la operación “Visar Alerta” no están
implementadas, ya que, por ejemplo, no se puede consultar la ficha comercial de un cliente
que no existe más que en los datos ficticios de Alertas.
El siguiente paso fue cargar las tablas con datos del entorno Test del cliente. En este
entorno todas las tablas de datos están cuadradas para simular un uso similar al de
producción. Para ello se ejecutó el proceso Batch manualmente en el entorno local
accediendo a las tablas DB2 del entorno local. Así, tenemos unos datos de prueba que
concuerdan con los del resto de la aplicación en el mismo entorno, con los que desarrollar
y probar toda la operativa.
Con estos nuevos datos, se procede a implementar los accesos a otras aplicaciones como la
Ficha Comercial (botón Servicio BPR), que más tarde se probará en el entorno de Test, o el
acceso al módulo de Nuevo Contacto. Además, se realiza un intenso juego de pruebas con
diferentes tipos de Alerta, empleados y centro que servirá para depurar el módulo
exhaustivamente.
Como ya hemos visto, los usuarios que entran a la aplicación pueden tener distintos
permisos de acceso definidos en el User.java. Por otro lado, los centros también se dividen
en varios tipos, como centros oficina o equipos de personas entre otros. Las pruebas de
depuración del módulo alertas se centrarán sobretodo en este aspecto, muy importante para
el cliente, puesto que hay un gran abanico de permisos distintos que supone la relación
entre el tipo de centro y los permisos del usuario.
Una vez se ha depurado el módulo, está listo para su distribución en el entorno de Test,
donde se realizan las pruebas con datos generales para todas las aplicaciones del cliente,
que servirán para seguir con la depuración exhaustiva exigida.
6.3. Entorno Test
Este es el primer entorno de pruebas del cliente. Un entorno donde todas las aplicaciones
están sujetas a cambios, y no tienen porqué funcionar realmente (aunque se aconseja). Este
entorno sirve para poder probar la aplicación desarrollada en un entorno parecido al de
producción (aunque con muchísimos menos recursos) donde el resto de aplicaciones del
cliente están a la disposición del usuario. Por tanto, todo lo que no se pudiera probar en
local, se debiera probar en Test.
59
Para subir la aplicación a Test se debía usar la herramienta harvest. Esta herramienta
permite ver los cambios realizados sobre la aplicación, y subir sólo aquellos que hayan
cambiado. Es un proceso automatizado que puede llegar a tardar varias horas en acabar.
Por esto, el método prueba y error no es muy recomendable en este entorno, ya que el
tiempo de publicado pasa de ser sólo unos segundos de local, a una o varias horas en Test.
Por ello, el desarrollador debe anticiparse a los posibles errores causados durante el
desarrollo de la aplicación. Este método requiere mucha práctica y cuesta de asimilar,
aunque es bastante sencillo. Con la experiencia, el desarrollador sabe qué va a funcionar y
qué es susceptible de tener error, por tanto debe imaginar los posibles errores y sus
soluciones y adaptar el código para que esto no pase.
La aplicación debe pasar por este entorno en su situación final, es decir, una vez la
aplicación esté completamente acabada, este será el primer entorno donde debe estar. Si en
este entorno no funciona, o algún módulo contiene errores, jamás pasará al siguiente: Preproducción.
6.4. Entorno Pre-producción
El entorno pre-producción es un entorno que nuestro cliente pone a nuestra disposición que
se asemeja muchísimo al entorno de producción. La única diferencia son los datos.
Los datos en este entorno no son los datos de producción, son datos parecidos que no
tienen porqué tener parecido a los reales. Sin embargo, la infraestructura es igual a la de
producción. Se procura tener las tablas de datos correctas para poder ver todas las
casuísticas que se pudieran dar en el entorno de producción.
Como norma general, si la aplicación funciona en pre-producción, funcionará en
producción. Por este entorno, la aplicación no suele pasar demasiado tiempo de pruebas.
Puesto que la gran mayoría de errores posibles surgen en los entornos de local y test. Si
surgiera cualquier problema, la aplicación se echa para atrás y volverá al entorno test para
su corrección.
Si la aplicación no presenta problemas o errores, se procede a su distribución en
producción.
6.5. Entorno Producción
El entorno de producción es el entorno que usa nuestro cliente, donde tiene todas las
aplicaciones y sus empleados acceden para realizar sus tareas diarias.
Todo y absolutamente todo debe funcionar correctamente en este entorno, y se da muy
poco margen para el error al desarrollador.
Cualquier error o problema que surja en este entorno debe ser corregido en el menor
tiempo posible.Una vez la aplicación está funcionando correctamente en este entorno, se da
el trabajo por terminado.
60
7. Conclusiones
El desarrollo de este módulo ha sido un trabajo constante de aprendizaje, prueba y error. A
pesar de parecer un módulo pequeño en una aplicación muy grande, ha requerido una
implicación extraordinaria en el desarrollo del mismo.
Se ha hecho una aplicación que permite al Gestor Comercial de nuestro cliente, poder ver
las alertas que diariamente debe atender. Se le ha facilitado una interfaz cómoda y fácil de
usar para poder desarrollar su trabajo con facilidad:
•
•
•
•
•
Poder ver las alertas que tiene.
Poder modificarlas una vez hayan vencido.
Poder visualizar las alertas de todo un centro si tiene permisos.
Visualizar los detalles de un tipo de alerta:
o Alertas de clientes (particulares y empresas)
o Alertas de Gestor: alertas individuales o personales
Poder realizar varias acciones según los clientes pertenecientes a una alerta:
o Realizar un contacto sobre el cliente.
o Poder ver la ficha comercial del cliente.
o Poder visar una alerta.
o Llamar al cliente con un solo click.
La realización del módulo ha aportado grandes conocimientos de varios entornos y
lenguajes de programación, algunos desconocidos, otros no, tal y como son:
•
•
•
•
•
•
Java
Java Server Pages (JSPs)
DAO (Data Access Object)
JavaScript
Oracle
PL/SQL
Durante los estudios universitarios, he adquirido conocimientos que me han ayudado
mucho:
Por un lado, los estudios universitarios me han brindado conocimientos de Java, Redes y
SQL que he podido aplicar durante el desarrollo de la aplicación.
Por otro lado, en la empresa he mejorado mi experiencia en trabajar en grupo, y he
aprendido varios lenguajes de programación como JavaScript, PL/SQL y struts2, entre
otros.
61
8. Bibliografía
No se ha consultado ningún libro en la realización de esta memoria. No obstante, la
información obtenida vía web vendrá recogida en los siguientes links:
•
•
•
•
•
•
•
•
•
http://www.tecnocom.es/Paginas/HOM-Descripcion.aspx
http://es.wikipedia.org/wiki/Tecnolog%C3%ADas_de_la_informaci%C3%B3n_y_l
a_comunicaci%C3%B3n
http://www.slideshare.net/BBVAtech/el-gran-valor-de-las-tic-en-el-sectorfinanciero
http://es.wikipedia.org/wiki/Batch_(Unix)
http://es.wikipedia.org/wiki/Archivo_batch
http://es.wikipedia.org/wiki/PL/SQL
http://es.wikipedia.org/wiki/Oracle_Database
http://es.wikipedia.org/wiki/Java_(lenguaje_de_programaci%C3%B3n)
http://es.wikipedia.org/wiki/Modelo_Vista_Controlador
Aplicaciones usadas para realizar la memoria:
•
•
•
•
•
•
•
•
•
http://www.ganttproject.biz/
http://notepad-plus-plus.org/
http://tomcat.apache.org/
http://struts.apache.org/
http://www.eclipse.org/downloads/moreinfo/jee.php
http://www.Oracle.com/technetwork/database/enterpriseedition/downloads/index.html?ssSourceSiteId=ocomes
http://www.allroundautomations.com/plsqldev.html
http://www.ieinspector.com/httpanalyzer/
http://www.easyeclipse.org/site/plugins/eclipse-cvs.html
62