Download Módulo Alertas para la aplicación Asesor de Ventas
Document related concepts
no text concepts found
Transcript
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