Prueba J2EE Con Plex 5.1_03

Migrando Modelos AllFusion Plex a un entorno J2EE

Lic. Darío Fabini

Versión 1.0 Evaluación de herramientas para la

migración de un sistema generado en Plex 4.0 a una arquitectura J2EE

Introducción Llego el momento de empezar a migrar componentes a un entorno J2EE, en la actualidad se esta analizando un proyecto para generar todos sus modelos Plex en este entorno, la tarea no es trivial dada la cantidad de componentes a tener en cuenta. Esto presenta un nuevo desafío que Plex tendrá que superar, dado que conceptualmente es esta su función. Las dudas respecto a que esto funcione se plantean por lo que este trabajo de análisis de factibilidad pretende concluir que el proyecto terminará en éxito. Migrar todas las aplicaciones desde un entorno Windows-AS400 a uno J2EE (Windows-IAS-Oracle) para conseguir unificar las plataformas de los sistemas, no es algo que vamos a hacer de un día para el otro. En este documento se pretende documentar la experiencia del caso, empezando desde su análisis de factibilidad hasta la culminación del caso piloto.

Background

Sistema de Información Hospitalaria (HIS) El Sistema de Información Hospitalaria (HIS) de nuestra institución tiene un diseño estructurado en tres capas totalmente interconectadas brindando interoperabilidad en tiempo real. En este contexto el HIS se define como un sistema compuesto por, la Capa Clínica, la Capa Administrativa y la Capa de Integración. Capa Clínica: el sistema de información clínico dispone de servicios médicos exclusivamente. Esto apunta a atender los requerimientos desde la perspectiva de la actividad médica, su principal foco es la Historia Clínica Electrónica (HCE) siguiendo rigurosamente los estándares mundiales en lo

PDF created with pdfFactory trial version www.pdffactory.com

http://www.pdffactory.com


que respecta a funciones que deben contemplarse para soportar esta característica. Capa Administrativa: el Sistema de Administración Hospitalaria (SAH) modela los procesos administrativos que gobiernan el negocio. Los principales módulos dentro de esta capa son Turnos, Admisión y Egreso (ADT), Facturación, Finanzas, Producto, Cuentas a pagar, Cuentas a cobrar, Contabilidad, Costos, Honorarios, Farmacia, Suministro y RRHH. Capa de Integración: esta capa modela las componentes comunes a la capa administrativa y clínica (Tablas Maestras). Esta capa permite una integración directa entre la HCE y el SAH posibilitando interoperabilidad total. Los principales servicios que esta capa soporta son: Servicio de Paciente, Estructura asistencial, Estructura administrativa, Estructura física, Servicio de mensajería HL7, Servicio de terminología y Seguridad.

Capa Administrativa - Sistema de Administración Hospitalaria (SAH) El proyecto de reingeniería de los procesos administrativos se inicia en 1996, eligiéndose como plataforma principal DB2 sobre AS400 y como entorno de desarrollo AllFusion Plex (ex Obsydian). El equipo de desarrollo, compuesto originalmente por 11 profesionales se distribuye los distintos módulos y trabaja de forma disciplinada siguiendo un proceso propio de desarrollo. Como resultado final, al término de 5 años, se a logrando implementar por completo la capa administrativa con Plex. Por otro lado, en el año 2000 se inicia el desarrollo de la capa clínica (HCE) sobre una arquitectura J2EE , surgiendo la necesidad de integrar el sistema administrativo y clínico (SAH-HCE).

Capa Clínica

(HCE)

Capa de Integración

Capa Administrativa

(SAH)

Sistema de Información Hospitalario

Exterior




La capa de integración también se desarrolla sobre una arquitectura J2EE iniciando un desafío de comunicación con las aplicaciones Plex. Como resultado la interoperabilidad para la capa administrativa se realizó utilizando HL7 y servicios COM integrados totalmente con pattern desarrollados con Plex. En la actualidad el sistema administrativo soporta 1500 tablas y 5300 vistas, organizadas en 8 bibliotecas del AS400 que consumen mas de 200GB de espacio (2 años contables en línea), con tablas que en algunos casos superan los 16 millones de registros y 8GB. Al sistema acceden mas de 1000 usuarios diariamente con un promedio de 650 conexiones (OBSYTCP) y 300 usuarios simultáneos con picos de hasta 800 conexiones y 450 usuarios (Cada usuario ingresa a más de una aplicación). En este contexto el sistema tiene una tasa diaria superior a 130.000 transacciones (tomadas al final de la línea, ítems de asientos contables). La totalidad del sistema administrativo esta desarrollado con Plex, contando con 177 aplicaciones (.exe) organizadas en 12 modelos abstractos y 59 modelos de negocio, que son mantenidos por 7 desarrolladores Plex señor part-time, utilizando ClassLibs (OBASE sobre un "layer" interno) y PatternLibs en los últimos desarrollos. Actualmente los modelos están en la versión de Plex 4.0b. Fuentes (Borrador) Anexo I - WRACTJOBYOBSYTCP.xls Anexo II - Aplicaciones - usuarios - modelos.doc Anexo III - Estadística de Transacciones.doc

Objetivos El objetivo de este pre-proyecto es realizar un relevamiento completo del sistema para evaluara la factibilidad de una migración incremental de todos los modelos Plex a una arquitectura J2EE de modo de poder unificar las plataformas, haciendo la adecuación correspondiente sin impactar en la funcionalidad del mismo, realizando implementaciones incrementales sin tener que realizar cortes prolongados del sistema (a lo sumo 2hs). Los puntos que se analizan son los siguientes:

4 Performance: mantener la misma performance que se tiene con el AS400

4 Conectividad: las nuevas aplicaciones generadas en entorno J2EE con Plex deberían poder consumir lógica de las aplicaciones que quedan en el RPG/AS400 (ida y vuelta) y con aplicaciones java existentes sobre J2EE no hechas con Plex.

4 Impacto en los modelos: la intención, de máxima, es que los modelos no sean tocados.

Deseable a futuro: 4 GUI Web: los modelos Plex debería generarse con un cliente web




Casos de estudio

Entorno de prueba inicial

IAS de desarrollo El servidor de aplicaciones web a utilizar es el Oracle Internet Application Server (IAS) con java 1.5

Servidor: intel, procesador P4 HT de 3Ghz Sistema operativo: Redhat ES3 Versión IAS: 9.0.4.3.0 Memoria: 4Gb Discos: SCSI 73Gb

Base de datos (Desarrollo) La base de datos a utilizar también es la Oracle 11g

Servidor: SunFire 880 Sistema operativo: Solaris 9

Unificación de la plataforma de los sistemas

Panorama actual Actualmente el sistema administrativo está corriendo en un entorno cliente-servidor, los clientes son Windows (desde Windows95 a Windows XP) y el servidor es RPG/AS400. La HCE y los Master File, están en un entorno J2EE (IAS/Linus y Oracle10g/Linus) de alta disponibilidad, siendo esta última, la plataforma definitiva.

Migración del SAH a un entorno J2EE - Prueba Piloto Inicial La conclusión definitiva es migrar el SAH a un entorno J2EE, dada la posibilidad que tiene Plex de poder generar en este entorno. Esto abre varios interrogantes que serán analizados en este trabajo.




Como punto de partida se pone como objetivo analizar la problemática tomando un caso de prueba como referencia para lo cual se migra un modelo de Test que implementa las principales entidades de Plex:

4 FB User maintained entity 4 FB Grid maintained entity 4 FB Enumerated entity 4 FB Two parent child 4 FB Dual detail transaction

Como resultado de esta pequeña prueba se recolecta lo siguiente:

Variante La variante a utilizar es WinC para el cliente, Java para la lógica del negocio la cual corre sobre el IAS y Oracle 11g para la base de datos.

Generación, compilación y deploy Simplemente se modifican los nombre para que las tablas se generen con nombres largos (esto no se hará con los modelos de producción). En este aspecto todo funciono bien. La generación de la base de datos se realizó directamente desde Plex hacia Oracle vía ODBC. Los programas Java se empaquetaron en un .war y se realizó el deploy en primera instancia sin uso del pool de conexiones. Por último, los programas clientes en C++ se instalaron en una PC con Windows XP Profesional versión 5.1.2600.

Resultados

Performance Los tiempos de ejecución comparados contra igual función generada sobre AS400 son 1 a 20 a favor del AS (un proceso que tarda 1 segundo en el AS400, en el entorno J2EE tardó 21seg). La carga de grillas estándar con una tabla de más de 100000 registros tarda aproximadamente 10 seg en mostrarla, por más que la página sea de 64 renglones. Esta comparación no es muy relevante porque las dos arquitecturas de hardware no están homologadas pero la hicimos para tener un referencia.

Conectividad WinC a WS: desde el front-end WinC, podemos llamara a Web Services. Java a WS / Java a java: desde el Web Server, o sea de las funciones javas bac-end podemos llamar a otros .jar y Web Services hacia otras aplicaciones. Java externo a Java Plex: los javas generados con Plex empaquetados en jar los podemos llamar desde otras aplicaciones java no plex corriendo en el IAS. Las funciones javas back-end generadas con Plex las podemos exponer como Web Service - AXIS (SOAP) (En este caso nos quedó la prueba pendiente pero hay documentación que indica que funciona)




RPG a WS, para hacer que una función RPG pueda llamar a un Web service, usando características de ILE RPG (recordemos que los modelos están en plex 4.0b que no genera ILE) y armamos un CL para llamar a un WS y un pattern desde plex que abstrae el problema. Funciona intercambiando instancias simples, no analizamos retornar array. WS a RPG llamar desde un ws a una función RPG nos permite exponer todo nuestra lógica de negoción como ws-axis.

Impacto en los modelos Se presiente que el paso de los modelos a la nueva variante no es tan simple como uno esperaba. Esto es por problema de mantenimiento y diseño de los modelos actuales y no tiene nada que ver Plex. No es aconsejable generar con nombres largos o tocar algún nombre por el tremendo impacto que tendría sobre todos los consumidores externos de los datos.

Pool de conexiones No pudimos configurar el pool de conexione para que funcione desde el IAS. Pareciera que el nombre que definimos en el .properties no es el apropiado.

IAS La utilización de memoria de la aplicación resulto alta en relación con otras aplicaciones que están corriendo. Pareciera que las aplicaciones consumen demasiada memoria. Sería conveniente conocer un indicador de granularidad para dimensionar la cantidad de aplicaciones que se pueden poner por contenedor.

Conclusión La migración de los modelos es algo inminente y se plantea realizarlo a lo largo de los próximos años, la pregunta es si el entorno soportará la carga de las aplicaciones y si la performance será la misma. Si las aplicaciones correrán con la misma velocidad que el AS400, pregunta difícil de responder ahora. Por el tema conectividad no vemos inconveniente dado que hemos probado toda las variantes: RPG a Java, Java a RPG vía ws-axis, JavaPlex a JavaExterno, WinC a ws-axis/java, etc. Esto permite comunicarnos con funciones actualmente en entorno de tres capas J2EE (Java-java-oracle o WinC-Java-Oracle) y aplicaciones WinC-RPG.

Próximo trabajo: SAH Web Analizar la posibilidad de migrar el SAH íntegramente en un entorno web con cliente web también.




Prueba piloto Web Como prueba piloto se define migrar un modelo real (Modelo de Autorizaciones médicas) para ir resolviendo problemas reales. (Pendiente)

Ambiente Generador cliente Web: WWD+ Para la capa de presentación Web Server: Tomcat (luego se verá cual contenedor usamos) Back end: Prueba inicial con SQLServer, (luego Oracle10g)




Prueba J2EE Con Plex 5.1_03

Documents

Transcript of Prueba J2EE Con Plex 5.1_03