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
