Proceso de desarrollo de aplicaciones Web en Java Guía de Ayuda Descripción de la arquitectura Generalidades El e-IBS (Integrated Banking System) está conformado por: una aplicación host (eIBS Core Bancario), y una aplicación Web (e-IBS Plataforma). La aplicación e-IBS Plataforma tiene como propósito proveer una interfaz de usuario gráfica que permita la interacción del usuario con el e-IBS Core Bancario. Esta aplicación Web está construida con componentes JSP y Servlets que son parte de la especificación J2EE. La aplicación e-IBS Core Bancario es la aplicación central que soporta las operaciones financieras del banco. Está formado por Programas RPG, Servicios de Datos y DDS, que interactúan tanto con las aplicaciones IBS como con aplicaciones no-IBS. 1 de 1 Los Programas RPG se encargan de realizar toda la lógica del negocio. Los Servicios de Datos son programas RPGILE que efectúan todas las funciones de validación de información ingresadas, búsqueda de datos en la BD y retorno de los datos o de los mensajes de error, a la capa Web. Las DDS son estructuras de datos que se utilizan para intercambiar la información con la capa Web, donde su equivalente en la capa Web es un Java Bean. La comunicación de la capa Web con el Host se efectúa por medio de sockets que se encuentran activos en el ambiente al que pertenecen. En el mismo servidor AS/400 pueden existir diferentes ambientes (desarrollo, calidad, producción, etc.). Cada ambiente es una instancia diferente del IBS, y cada ambiente tiene asignado un conjunto diferente de sockets utilizados para la comunicación con la capa Web. Los ambientes en el servidor AS/400 se denominan XXXEIBS o EIBSXXX, donde XXX es el identificador del que está corriendo. Interfaz entre Back-end y Front-end Los programas RPG utilizan para el envío y recepción de información desde y hacia la capa Web, las DDS. Los programas RPG se denominan EXXNNNN, donde la E proviene de e-IBS, los 2 caracteres siguientes indican el módulo al que pertenecen (Ej.: DD = Sistema de Cuentas), y los últimos 4 caracteres indican numeración correlativa. Algunos de los programas RPG pueden usar más de una DDS, y se denominan EXXNNNNSS. Los primeros 7 caracteres son idénticos al programa RPG que lo usa, los 2 últimos caracteres corresponden al formato de DDS que estamos usando, con una numeración correlativa, dependiendo de la necesidad de la información a transmitir. Las DDS pasa a ser un Java Bean al ingresar a la capa Web donde se reconocen en dicha aplicación con el nombre EXXNNNNSSMessage.java. El nombre corresponde al mismo de la DDS en el AS/400. 2 de 2 Cada DDS posee un identificador de formato, el cual es una secuencia de dígitos hexadecimales que identifica unívocamente a dicha estructura de datos. Este identificador de formato lo asume también el Java Bean. Ciclo de vida de desarrollo de un módulo Ambiente de desarrollo Dos de las herramientas de desarrollo utilizadas son el IBM WebSphere Studio Application Developer 5.0.1 o superior; o el IBM Rational Software Development Platform 6.0 o superior. El servidor de aplicaciones utilizado es el IBM WebSphere Application Server 6.0 o superior. WebSphere es una herramienta para el desarrollo de aplicaciones empresariales bajo la plataforma J2EE, basado en la tecnología Eclipse. Incorpora diversas tecnologías open source; entre las más utilizadas están Ant y Concurrent Versions System (CVS). Arquitectura de la aplicación Web El archivo eIBS.properties es el archivo principal de configuración del e-IBS. El archivo ServiceLocator.properties contiene configuraciones de conexiones a servicios. La carpeta JavaSource contiene los Java Servlets de la aplicación Web organizados en paquetes, a excepción del paquete datapro.eibs.beans, que contiene los Java Beans utilizados para el intercambio de datos con el servidor AS/400. La carpeta WebContent contiene fundamentalmente todas las páginas JSP, así como los procedimientos JavaScript e imágenes que utilizan todos los módulos 3 de 3 del e-IBS. Dentro de la carpeta WebContent, la carpeta WEB-INF contiene todos los archivos necesarios para la ejecución de la aplicación Web, entre ellos el descriptor de despliegue (web.xml), las clases compiladas y las librerías. Esquema general del funcionamiento del e-IBS Interacción entre el e-IBS Plataforma y el e-IBS Core Bancario 4 de 4 Construcción de un módulo Generación del JavaBean. A partir de la DDS definida en el servidor AS/400 se genera el Java Bean correspondiente que será usado en la capa Web para el envío de información. Este Java Bean queda almacenado en el servidor AS/400. Importación del JavaBean. Se debe descargar el Java Bean generado e incluirlo en el proyecto Web. La estructura de datos generada se puede obtener del AS/400 de dos formas: 1. Usando una conexión FTP, para lo cual es necesario conocer el nombre o la IP del servidor AS/400, el usuario, la contraseña y el directorio remoto donde están localizados los Java Beans. 2. Accediendo al sistema de archivos integrado (si esta característica está habilitada en el servidor AS/400) haciendo un mapeo de una unidad de red. De esta forma se puede acceder directamente al directorio remoto que contiene los Java Beans. Creación del Servlet Todos los servlets deben heredar de la clase datapro.eibs.master.SuperServlet. Los servlets deben sobrescribir el método service(). Se verifica si la sesión es válida. Se establece la conexión con el servidor AS/400. Se ejecuta el método correspondiente al código de SCREEN recibido en el request. Se crea el mensaje a enviar y se asigna al mensaje la información a ser procesada. Envío el mensaje. Recepción de los mensajes de respuesta, procesamiento de los mismos y colocación en la sesión. Creación de las páginas JSP Obtener de la sesión los objetos que contienen la información (Error + Datos). Validar si hay errores y si los tiene, mostrarlos en pantalla. Mostrar la información contenida en el(los) mensaje(s) de datos en los campos correspondientes. 5 de 5 Ensamblaje y despliegue de la aplicación Para poder desplegar la aplicación en el servidor de aplicaciones, ésta se debe empaquetar de una forma estándar definida en la especificación J2EE. Servidor de aplicaciones J2EE >> WebSphere Archivo EAR (EAR file) Archivos WAR (WAR files) En el caso particular del e-IBS, el archivo EAR contiene solamente un archivo WAR. 6 de 6 Ejemplo de funcionamiento de un módulo Funcionalidad: Parámetros de Tesorería Módulo: Referencias de Monedas // Construcción del mensaje a enviar al servidor AS/400 msgList = (EGL036001Message) mc.getMessageRecord("EGL036001"); msgList.setH01USERID(user.getH01USR()); msgList.setH01PROGRM("EGL0360"); msgList.setH01TIMSYS(getTimeStamp()); msgList.setH01SCRCOD("01"); msgList.setH01OPECOD("0015"); msgList.setE01RATBNK(code); 7 de 7 msgList.send(); msgList.destroy(); // Obtención del mensaje de error (ELEERRMessage) newmessage = mc.receiveMessage(); if (newmessage.getFormatName().equals("ELEERR")) { msgError = (ELEERRMessage) newmessage; IsNotError = msgError.getERRNUM().equals("0"); flexLog("IsNotError = " + IsNotError); } else flexLog("Message " + newmessage.getFormatName() + " received."); // Recepción del mensaje de respuesta newmessage = mc.receiveMessage(); if (newmessage.getFormatName().equals("EGL036001")) { msgList = (EGL036001Message) newmessage; // procesamiento del mensaje } // Publicación de los mensajes en la sesión (si no hay errores) if (isNotError) { ses.setAttribute("header", msgList); ses.setAttribute("userPO", userPO); // Redirección a la página flexLog("About to call Page: " + LangPath + "EGL0360_fex_currency_list.jsp"); callPage(LangPath + "EGL0360_fex_currency_list.jsp", req, res); } else { flexLog("About to call Page: " + LangPath + "EGL0360_fex_sel_bank.jsp"); callPage(LangPath + "EGL0360_fex_sel_bank.jsp", req, res); } Los parámetros en azul, deben ser suministrados por el programador RPG, mientras que los parámetros en naranja, deben ser especificados por el programador Java. 8 de 8 Definición de estándares de programación Los mensajes se nombran según el nombre de la DDS precedido por el nombre Message. Ejemplo: EGL036001Message.java Las páginas JSP se nombran según el programa RPG, seguido de varias palabras clave que identifiquen el propósito de la página JSP en cuestión, separando con guiones bajos. Ejemplo: EGL0360_fex_sel_bank.jsp Los Servlets se nombran según el programa RPG antecedido por JS. Ejemplo: JSEGL0360.java Los Servlets extienden al SuperServlet (Datapro). Ejemplo: public class JSEGL0360 extends datapro.eibs.master.SuperServlet { … La aplicación e-IBS Plataforma cuenta con una hoja de estilos CSS que “pinta” automáticamente los controles HTML, tales como, tablas, botones, enlaces, imágenes, entre otros. Por lo tanto, no es necesario que el programador Java defina las características gráficas de la aplicación, ya que se encuentran definidas por Datapro. Las páginas JSP deben seguir las convenciones de diseño en cuanto a títulos, diagramación de los campos y otras funcionalidades. Así mismo, en la programación de los servlets, debe seguirse el mismo esquema estándar de programación para cada uno de los métodos que implementa el servlet. El estándar de mensajería entre la aplicación Web y el AS/400 es el siguiente: Se envía un mensaje con información a procesar. Ej.: EGL036001Message. Se recibe un mensaje con los posibles errores (ELEERRMessage). Se reciben los mensajes con los datos de respuesta. Ej.: EGL036001Message. Se pueden recibir uno o más mensajes de respuesta según la operación ejecutada. Ej.: consulta de una lista de valores, o consulta de un solo valor. 9 de 9 Requerimientos del sistema para un ambiente de trabajo Para instalar WebSphere Studio o Rational en una estación de trabajo para realizar desarrollos, se requiere fundamentalmente de tres aspectos básicos que debe cumplir dicha estación de trabajo. El sistema operativo debe ser Microsoft Windows XP o superior, se debe disponer de al menos 2 Gb de memoria RAM (usualmente se especifica 1 Gb como mínimo, pero se recomienda mayor capacidad para un mejor desempeño), y espacio suficiente en disco duro tanto para la herramienta como para los proyectos en sí. Casos de errores en el e-IBS Existen una serie de casos que pueden identificarse fácilmente para un diagnóstico rápido de los errores que puedan presentarse a nivel de la plataforma gráfica del sistema, en donde puedan requerirse ajustes bien sea del lado de la aplicación Web o del programa RPG. 1. Caso #1: Al accesar a un módulo del sistema, inmediatamente después de enviar la información, aparece el error ‘Se perdió la conexión con el servidor’. En estos casos, la causa más usual se debe a diferencia de clases, es decir, la definición del Java Bean utilizado por un servlet en particular difiere de la definición de la DDS en el servidor AS/400. Esto se soluciona reexportando la clase desde el AS/400 para actualizarla respectivamente en la aplicación Web. Otras causas posibles también pudieran ser: un error de ejecución en el servlet relacionado, para lo cual el programador Java deberá revisar el log del servidor, a fin de determinar el problema y hacer los correspondientes ajustes; o que los sockets del ambiente en el AS/400 se encuentran desactivados, para lo cual un operador dentro del servidor AS/400 deberá activar los sockets. 2. Caso #2: Al enviar información en un módulo, se queda esperando por una respuesta hasta que al cabo de unos segundos aparece el error ‘Se perdió la conexión con el servidor’. En estos casos, pudiera entonces haber un problema a nivel de la lógica del negocio. En este sentido, se recomienda revisar los sockets por si se ha generado algún mensaje de error durante la ejecución del programa RPG, y entonces el programador RPG hará la revisión pertinente en el programa para hacer las correcciones que sean necesarias. 3. Caso #3: La aplicación al tratar de cargar una página, aparece incompleta o en blanco. En estos casos, la causa se debe a un error de compilación o una excepción generada en un scriplet dentro de la página JSP. El programador Java es el encargado de hacer la 10 de 10 inspección debida, visualizando para ello el log del servidor, donde se describe la causa del error, y posteriormente hacer las debidas correcciones. 4. Caso #4: Aparece un error HTTP 404, indicando que se encontró el servlet, mas no un objeto utilizado en el mismo. Para solucionar este problema, debe hacerse revisión en el servlet y dentro de la aplicación Web, para diagnosticar qué objeto pudiera estar faltando, y entonces incorporar a la aplicación Web la clase compilada faltante. 5. Caso #5: En la barra de estado del navegador, aparece un signo de advertencia, indicando que se realizó una ejecución con algunos errores. Esto indica que se ejecutó uno o varios procesos dentro de una página JSP que ocasionaron uno o varios errores de JavaScript. El programador Java es el encargado de revisar la página JSP en cuestión para determinar las causas y aplicar los correctivos necesarios. 11 de 11