Manual. Generador JAVA. Versión 6.1

Transcripción

1 Manual Generador JAVA Versión 6.1 Ultima actualización: Julio, 2000

2 Copyright ARTech Consultores Todos los derechos reservados. El presente documento no puede ser duplicado de ninguna forma sin el expreso consentimiento de ARTech Consultores SRL. La información contenida en este documento es para uso personal de lector. TRADEMARKS Todos los productos mencionados en este documento son propiedad de sus respectivos dueños. 1

3 Tabla de Contenido INFORMACIÓN GENERAL SOBRE JAVA... 7 INFORMACIÓN GENERAL SOBRE EL GENERADOR JAVA... 9 IMPORTANTE REQUERIMIENTOS DE HARDWARE...10 INSTALACIÓN Y CONFIGURACIÓN DEL SOFTWARE NECESARIO SOFTWARE NECESARIO Navegadores Java Development Kit Compiladores Drivers JDBC Otros INSTALACIÓN DE LOS SDKS/JDKS PARA JAVA JDK de Sun SDK de Microsoft Jikes de IBM INSTALACIÓN DEL SOFTWARE NECESARIO PARA ACCESO CLIENTE SERVIDOR JDBC/ODBC Bridge Informix Thin Driver Oracle Thin Driver AS/400 JDBC Native Driver AS/400 Toolbox for Java i-net Software Weblogic jdbckona Merant DataDirect SequeLink Java Edition CONFIGURACIÓN TCP/IP DEL SQL SERVER CONFIGURACIÓN DE LAS OPCIONES DE EJECUCIÓN DENTRO DE JAVA OPTIONS Platform EXECUTE SETTINGS Applet WEB BROWSER SETTINGS WEB PANEL EXECUTE SETTINGS COMPILER SETTINGS Compiler path Make Path Customize Classpath EJECUCIÓN DESDE FUERA DE SDK de Microsoft JDK de Sun EJECUCIÓN DENTRO DE UN WEB BROWSER Como instalar automáticamente la Máquina Virtual de Microsoft SIGNIFICADO DE LAS PREFERENCES...25 REORGANIZE SERVER TABLES JDBC LOG FILE MAXIMUM OPEN CURSORS PER CONNECTION SMTP SERVER (FOR MAIL FUNCTIONS)

4 ADDITIONAL JAVA CLASSES JAVA PACKAGE NAME GENERATE MAKEFILES JDBC DRIVER DATABASE URL DATABASE NAME USER ID USER PASSWORD LIST OF REMOTE PROGRAMS (JDBC) AS/400 SPECIFIC / LIBRARY LIST FIELD EXIT REFRESH KEY SHOW FORM DEFAULT USER INTERFACE JFC LOOK & FEEL USE.GIFS INSTEAD OF.BMPS CLICK TO SORT IN SUBFILE (WORKPANEL) COLOR IN READ-ONLY FIELDS MANEJO DE LA INTERFAZ DE USUARIO CONSIDERACIONES ACERCA DE WFC CONSIDERACIONES ACERCA DE JFC CONSIDERACIONES ACERCA DE AWT LLAMADAS A PROCEDIMIENTOS EXTERNOS LLAMADAS A PROCEDIMIENTOS JAVA NO GENERADOS POR COMANDO JAVA PASAJE DE PARÁMETROS EXTERNOS LLAMADAS A PROGRAMAS EXTERNOS ( STORED PROCEDURES ) Ejecución de procedimientos almacenados en el AS/400 utilizando múltiples generadores por modelo 36 REORGANIZACIÓN ACTUALIZACIÓN DE LAS GXDB PASAJE DE ARRAYS COMO PARÁMETROS IDENTIFICACION DE VERSIONES REPORTES WEBPANELS POR QUE WEB PANELS EN JAVA? FUNCIONALIDAD ADICIONAL DISPONIBLE EN JAVA Compresión de páginas Web Manejo de sesiones REQUERIMIENTOS PREFERENCES Servlet Directory Images Directory Auto compress web pages Protocol specification Subfile Transparency Use Tables Include <PRE></PRE> Tags

5 Include standard header Include standard footer CONSIDERACIONES ADICIONALES CONFIGURACIÓN CON DIFERENTES ENTORNOS JavaServer Web Development Kit JRun LIMITACIONES ACTUALES EJECUCIÓN EN MULTIPLES CAPAS DEFINICIÓN DE LOCATIONS PREFERENCES Distributed Execution GXDB++ Location Automatic Remote Procedures Host Name Server Host ORB Connection timeout (seconds) Application Server Log File Application Namespace ARQUITECTURA DE LAS APLICACIONES DISTRIBUIDAS UTILIZACIÓN DE CORBA CLASSPATH UTILIZACIÓN DE RMI SOPORTE PARA RMI CON SDK DE MICROSOFT UTILIZACIÓN DE DCOM CONFIGURACIÓN RECOMENDADA Ejecución en Internet Ejecución en red local INSTALACIÓN/EJECUCIÓN DEL SERVIDOR DE APLICACIONES INSTALACIÓN DEL SERVIDOR DE APLICACIONES CONFIGURACIÓN DEL SERVIDOR DE APLICACIONES EJECUCIÓN DEL SERVIDOR DE APLICACIONES DESDE LA LÍNEA DE COMANDOS CONNECTION POOLING LDAP PREFERENCES Autenticate users using LDAP - No/Yes LDAP URL LDAP Autentication Method LDAP Principal Template Use LDAP user for userid('server') Lista de valores de las preferences para diferentes servidores LDAP INSTALACIÓN AUTOMÁTICA DE APLICACIONES EN EL CLIENTE COMO OBTENER CERTIFICADOS DE PRUEBA Netscape Internet Explorer DEPLOYMENT WIZARD Browser Deployment JAR Deployment IBM Win32 Native Java Compiler Transferencia de archivos EJECUCIÓN EN INTERNET A TRAVÉS DE PROXIES Ejecución con RMI

6 Ejecución con DCOM Ejecución con CORBA APPLICATION SERVER MONITOR FUNCIONES DE EXCEL FUNCIONES DE MAIL FUNCIONES DE FTP FUNCIONES DE TEXTO ARCHIVOS ASCII DELIMITADOS LECTURA DE ARCHIVOS ASCII DELIMITADOS GRABACIÓN DE ARCHIVOS ASCII DELIMITADOS CONSIDERACIONES SOBRE LOS ARCHIVOS ASCII DELIMITADOS DEVELOPER MENU CONSIDERACIONES ESPECIALES DE LA VERSIÓN ACTUAL DEL GENERADOR CARACTERÍSTICAS QUE NO SON SOPORTADAS AÚN CARACTERÍSTICAS SOPORTADAS POR Y NO IMPLEMENTABLES EN JAVA SOLUCIÓN A ERRORES COMUNES BUGS CONOCIDOS OTRAS CONSIDERACIONES ANEXO I DÓNDE OBTENER EL SOFTWARE NECESARIO? Navegadores Virtual Machine Java Development Kits Drivers JDBC Soporte para CORBA Soporte para RMI Java Foundation Classes (JFC) Web panels Utilitarios LDAP EJECUCIÓN CON DCOM

7 Tabla de Figuras Figura 1: Diálogo de Opciones de Ejecución Figura 2: Formas de ejecución application/applet Figura 3: Programa de Administración del JRun Figura 4: Configuración JRun - JSE General Settings Figura 5: Configuración JRun - Service Manager Settings Figura 6: Configuración de DCOM Figura 7: Configuración Servidor Aplicaciones GeneXus - General Figura 8: Configuración Servidor Aplicaciones GeneXus - General Figura 9: Configuración Servidor Aplicaciones GeneXus NT Service Figura 10: Configuración Servidor Aplicaciones GeneXus - Namespaces Figura 11: Namespace Configuration - General Information Figura 12: Namespace Configuration - Database Information Figura 13: Namespace Configuration - Select Namespace Figura 14: Namespace Configuration - Pool Information Figura 15: GeneXus Deployment Wizard 1/ Figura 16: GeneXus Deployment Wizard 2/ Figura 17: GeneXus Deployment Wizard 3/ Figura 18: GeneXus Deployment Wizard 4/ Figura 19: Browser Deployment - Generación del.cab para IE...79 Figura 20: Browser Deployment - DCOM Client Configuration Figura 21: Browser Deployment - Generación del.jar para Netscape Figura 22: Browser Deployment - Creación de Paquetes Figura 23: JAR Deployment Figura 24: IBM Win32 Native Java Compiler Figura 25: Transferencia de archivos Figura 26: Proxy Settings en Internet Explorer Figura 27: GeneXus Application Server Monitor Figura 28: GX App. Monitor - Read-Only Pool Information Figura 29: GX App. Monitor - Read-Write Pool Information Figura 30: Developer Menu Figura 31: "About" en el Dev. Menu

8 INFORMACIÓN GENERAL SOBRE JAVA Java es un lenguaje creado por Sun Microsystems. Desde el punto de vista de los usuarios de, sus características mas importante son las siguientes: Interpretado El código Java se escribe en fuentes con extensión.java, y se compila a clases con extensión.class. En tiempo de ejecución se interpretan y ejecutan los.class. Portable Para ejecutar una aplicación Java es necesario tener una máquina virtual que interprete y ejecute el código Java. Estas máquinas virtuales son las que traducen las instrucciones de los.class a las instrucciones nativas del sistema operativo. Existen máquinas virtuales para prácticamente todos los sistemas operativos. Es posible realizar llamadas a código nativo de cada plataforma, lo que permite aprovechar las ventajas específicas de cada sistema operativo, pero le quita la portabilidad. Orientado a ejecución en Internet Las aplicaciones Java pueden ejecutarse de modo que el código se va descargando de un servidor Web a medida que es necesario ejecutarlo. Esto tiene como ventaja que no se descarga mas código que el necesario, y que la distribución de las aplicaciones deja de ser un problema, ya que cambiando la aplicación en el servidor, se actualizan para todos los clientes de forma automática. Como contrapartida, cada.class se transfiere en una operación de descarga independiente (en un requerimiento HTTP distinto), lo que implica una carga agregada importante. Para evitar esto se pueden instalar automáticamente en el cliente las clases necesarias para ejecutar la aplicación. Por otro lado, Java tiene en sus bibliotecas estándar, clases para utilizar TCP-IP de una forma sencilla, lo que simplifica la programación de aplicaciones que utilicen Internet como medio de comunicación, y clases para permitir la ejecución distribuida de las aplicaciones. Seguro Las aplicaciones Java que se descargan de Internet, ejecutan en una caja que no les permite realizar diversas operaciones, como por ejemplo leer/escribir el disco duro del usuario. Esto da a los usuarios de aplicaciones Java la tranquilidad de que su máquina no corre ningún peligro Las diferentes versiones de Java en el mercado están dadas por los Java Development Kit (JDKs). Los JDKs son especificados y desarrollados por Sun Microsystems, y portados a diferentes plataformas/navegadores. La versión 1.0 es la más soportada por los navegadores, comenzando con Netscape 2.0 e Internet Explorer 3.0 La versión 1.1 incluye mejoras muy importantes para la realización de aplicaciones para empresas, fundamentalmente JDBC (Java Data Base Connectivity) que es el API para acceso a base de datos (el equivalente a ODBC en Windows), y RMI (Remote Method Invocation) que permite la ejecución de aplicaciones distribuidas. Es soportado por Internet Explorer 4. Netscape soporta JDK 1.1 desde su versión Las aplicaciones GeneXus requieren JDK 1.1 o superior para poder ejecutar. 7

9 La versión 2 (también conocida como 1.2) incluye un IDL (Interface Definition Language) para ejecutar aplicaciones distribuidas con CORBA, y las JFC (Java Foundation Classes) que son un conjunto de bibliotecas para interfaz gráfica, además de tener mejoras en casi todas las áreas. Ningún navegador hasta la fecha soporta Java 2, pero es posible ejecutar las aplicaciones en los navegadores utilizando un producto de Sun que instala la máquina virtual de Sun (1.1 o 2) en cualquier navegador. Existen en el mercado diferentes implementaciones de Java Development Kits. Para Windows existen básicamente 3: los de Sun, los de IBM y los de Microsoft. Para compilar/ejecutar las aplicaciones GeneXus es necesario tener alguno de los tres. El código compilado con cualquier JDK es compatible con todas las máquinas virtuales, por lo que no es necesario compilar y ejecutar con el mismo JDK. Para obtener mas información sobre Java se pueden consultar las siguientes URLs: : Café au Lait - FAQs y noticias del mundo Java : Página oficial de Java : Java Developer Connection información para desarrolladores 8

10 INFORMACIÓN GENERAL SOBRE EL GENERADOR JAVA Esta versión del generador Java genera work panels, procedimientos, reportes, web panels y menubars. Las transacciones serán incorporados en una próxima versión del generador. No se van a generar Menúes. A efectos de poder compilar las aplicaciones existentes sin problemas, se generan programas vacíos para transacciones. El generador solo generará aplicaciones cliente-servidor (no habrá una versión que genere programas con acceso a base de datos local como Access o DBFs). Las aplicaciones pueden generarse en 2 capas utilizando JDBC (el equivalente Java a ODBC) o en 3 capas utilizando CORBA, DCOM o RMI como protocolo de comunicación entre las capas. Actualmente el generador ha sido probado con los drivers JDBC de Oracle (contra ORACLE), con el JDBC- ODBC bridge (ORACLE y DB2/400, no funciona con SQL Server), con el Borland DataGateway (ORACLE), el SequeLink de Merant (SQL Server, Oracle y DB2), el JDBC Weblogic (SQL Server e Informix), los drivers de i-net para SQL Server y el AS400 Toolbox para DB2/400. Para el manejo de la interfaz de usuario existen 3 alternativas en el mundo Java. La primera, que es la nativa de Java y que está desde la primer versión es AWT (Abstract Windowing Toolkit). La segunda, son las Java Foundation Classes (JFC) que son un nuevo conjunto de clases que desarrolló Sun Microsystems. La tercera, son las Windows Foundation Classes (WFC) que fueron desarrolladas por Microsoft y solo funcionan en plataformas Windows. Mas adelante se explicará el soporte del generador para estas clases. A la fecha, las aplicaciones generadas con el generador Java funcionan correctamente utilizando el JDK de Sun Microsystems, la máquina virtual del Internet Explorer 4 y el Netscape Navigator versión 4.06 o posterior. Es posible también usar la máquina virtual del IE4 con el IE3. El generador Java se apoya en las GXDB++ para realizar el acceso a la base de datos. Las GXDB++ son un conjunto de clases Java, generadas en tiempo de creación/reorganización, que encapsulan los accesos a la base de datos y luego son utilizadas por los programas generados. En las siguientes versiones del generador también encapsulará las fórmulas y controles de integridad. Adicionalmente se publicará una especificación de dichas clases para que puedan ser utilizadas independientemente de los programas generados por. Un detalle importante que se debe tomar en cuenta es que las GXDB++ deben estar sincronizadas con el modelo. O sea, si se modifica algo en diseño y luego se hace un copy model a un modelo de prototipo, las clases no quedan sincronizadas con este modelo. Es necesario realizar una reorganización (si se desea, puede utilizarse la preference Reorganize Server Tables = No). Las aplicaciones Java pueden ejecutarse de dos formas. Como applets o como applications. En el primer caso se ejecutan dentro de un web browser, los programas compilados java residen en el server y son bajados al cliente cuando este los necesita ejecutar, o bien se pueden instalar en el cliente utilizando un utilitario que se provee con el generador llamado Deployment Wizard. En el segundo caso, se ejecuta como una aplicación independiente, y los programas compilados están en el disco del cliente (o de algún file server al que pueda acceder). Es necesario tener la versión 6.0 patch 7 o posterior de para utilizar el generador. El generador Java genera programas fuente con nombres largos (de mas de 8 letras), por lo que el modelo debe crearse en una unidad de disco que soporte nombres largos. 9

11 Importante 1. Si al correr el GXAUTHOR para solicitar la clave de autorización del generador, éste no aparece en la lista de generadores a seleccionar, será necesario aplicar los patches #11 o #2 del Development Environment de GeneXus 6.0 o 6.1 respectivamente para poder obtener el código. Esto se debe a que las versiones anteriores del generador no tienen protección, 2. Si se está utilizando GeneXus 6.0 es necesario bajarse (de la página de download en algunos archivos (dlls60.zip) para poder utilizar el generador. Estos deben ser copiados al directorio de instalación de GeneXus.. 3. Si se instala una versión del generador en un equipo en que ya existía una versión anterior seguir las siguientes instrucciones, de lo contrario no se podrá compilar ningún objeto con la versión nueva Es necesario realizar una creación de la base de datos con Java, dado que luego de que ésta se ejecuta correctamente se crean las clases de acceso a la base de datos (GXDB++) que los programas generados utilizan. Si no se desea crear la base de datos física, utilizar la preference Reorganize Server Tables = No Si se había había ejecutado una aplicación GeneXus como applet desde el Internet Explorer, habrá un conflicto entre las clases GeneXus que se instalan automáticamente en el Internet Explorer al ejecutar un applet GeneXus y las clases que se distribuyen con la nueva versión. Para solucionar esto existen dos posibilidades. La primera es ir al directorio Windows\Downloaded Program Files, posicionarse sobre Genexus Java Standard Classes, presionar el botón derecho y seleccionar Remove. La otra opción es generar algún objeto cualquiera, y antes de compilar ejecutarlo como applet. Probablemente la aplicación no funcione correctamente, pero se actualizarán las clases standard GeneXus con las de la nueva versión del generador Si se generó una aplicación, se creó un.cab con el Deployment Wizard, se ejecutó como applet de modo que las clases se instalara en la máquina del usuario, y luego se quiere volver a generar/compilar el modelo correspondiente, el compilador encontrará dichas clases antes que las generadas por GeneXus. Es necesario removerlas del directorio "Downloaded Progam Files" antes de volver a trabajar con el modelo. REQUERIMIENTOS DE HARDWARE Para utilizar las aplicaciones generadas, es necesario tener un mínimo de 32MB de RAM, recomendándose que se tengan 48MB o más. Para compilar las aplicaciones, en caso de utilizar el SDK de Microsoft, se necesita un mínimo de 32MB de RAM. Para utilizar el JDK de Sun es necesario un mínimo de 48MB. El procesador en principio no es tan crítico como la memoria RAM, pero se recomienda utilizar al menos un Pentium de 133 para compilar/ejecutar las aplicaciones. 10

12 INSTALACIÓN Y CONFIGURACIÓN DEL SOFTWARE NECESARIO Software necesario Para trabajar con el Generador Java es necesaria la instalación y configuración de Software que se describen a continuación. Además en el Anexo I de este documento se puede encontrar las direcciones en Internet de dónde poder obtenerlos. Navegadores No es necesario tener ningún navegador para utilizar el generador Java,. Sin embargo, se recomienda tener ambos para probar el correcto funcionamiento de la aplicación como applet. Netscape se soporta desde la versión 4.06 en adelante. Java Development Kit Compiladores Para la compilación y ejecución de los programas es necesario tener el JDK o JDK de Sun, el SDK 3.1 de Microsoft, el JDK 1.1.7B de IBM o posteriores. No es necesario tener todos los development kits, aunque es recomendable tener por lo menos el JDK 1.1.x de Sun y el SDK de Microsoft. El compilador de Microsoft es más rápido que el de Sun, por lo que se puede utilizar dicho compilador y ejecutar en el ambiente de Sun. Actualmente, el JDK es mucho mas estable que el JDK de Sun, por lo que se recomienda utilizar el primero. Drivers JDBC El generador GeneXus Java solamente genera aplicaciones Cliente/Servidor. Por lo que es necesario contar con alguno de los DBMS soportados por GeneXus (en cualquiera de sus generadores Client/Server), que son los siguientes: DB2/400, DB2/Common Servers, Informix, Oracle y SQL Server. Dependiendo del DBMS y del tipo de acceso a la base de datos que se utilizará, puede ser necesario obtener uno u otro driver JDBC para el acceso al mismo. Otros Protocolos de Comunicación: soporte para RMI y CORBA Java Foundation Classes (JFC) Instalación de los SDKs/JDKs para Java JDK de Sun Para instalar el JDK de Sun, bajar la versión para Win32 del JDK del web site de Sun (ver Anexo I). Para la instalación simplemente ejecutar EXE que se haya bajado y seguir las instrucciones. 11

13 SDK de Microsoft Hay dos formas de bajar el SDK de Microsoft, con un SDK Setup Wizard, que baja e instala los componentes automáticamente, o bajar los ejecutables para luego instalarlos. Esta ultima opción es la que se recomienda, dado que luego puede instalarse en otros equipos, o reinstalarse en el mismo equipo. La página en la que se puede bajar el SDK de esta manera es : Es necesario bajar los siguientes archivos: Microsoft SDK for Java, versión 3.2 Microsoft virtual machine for Java Se debe instalar primero el SDK y luego la virtual machine. La última versión liberada a la fecha es el build 3186 ( ). Se recomienda tener esta versión para el correcto funcionamiento de las aplicaciones generadas.. Es imprescindible la versión o posterior para usar las funciones de interfaz con Office (ver Anexo I). Jikes de IBM Para instalar el compilador Jikes de IBM, bajar el archivo jikeswin.exe para Windows 95/NT del web site indicado en el Anexo I Para la instalación simplemente ejecutar este EXE, el cual solicita el directorio en el cual se quiere dejar el compilador (jikes.exe) y documentación (jikes.htm y license.htm). Por ejemplo se puede dejar en un directorio c:\jikes Para poder utilizar este compilador es necesario que esté instalada alguna versión del JDK de Sun, dado que necesita las bibliotecas de clases de este. Este compilador se soporta porque es mas rápido que el compilador del JDK de Sun, y logra compilar algunos objetos GeneXus que no pueden compilarse con el compilador del SDK de Microsoft, dado que este último cancela. Se han detectado problemas en llamadas a procedimientos con muchos parámetros (mas de 60). Instalación del software necesario para acceso cliente servidor Las aplicaciones generadas utiliza un API llamado JDBC para interactuar con la base de datos. Existen 4 tipos de driver JDBC: Tipo 1: el bridge JDBC-ODBC provee acceso al JDBC a través de la mayoría de los drivers ODBC. Notar que el código binario de algunos ODBC, y en muchos casos el código del cliente de la base de datos, debe ser cargado en la máquina de cada cliente que use el driver. Tiene como ventaja importante que se pueden utilizar los drivers ODBC existentes, pero la desventaja de que hay que instalarlos en cada máquina. De todos modos, si se opta por una arquitectura de 3 capas, donde el acceso a la base de datos no se hace en el cliente sino en el servidor de aplicaciones, puede ser una alternativa viable. Las implementaciones actuales de estos drivers no son muy fiables, por lo que no se recomienda su utilización en ambientes de producción. Tipo 2: el driver native-api partly-java convierte llamadas JDBC en llamadas en el API del cliente Oracle, Sybase, Informix, DB2, o cualquier otro DBMS. Notar que, igual que el bridge driver, este tipo de driver requiere que se cargue código binario en la máquina de cada cliente. En teoría sería el tipo de driver con mejor performance. 12

14 Tipo 3: el driver net-protocol all-java traduce llamadas JDBC en un protocolo de red independiente del DBMS que es luego traducido por el server a un protocolo del DBMS. Este middleware de red del servidor es capaz de conectar todos los clientes Java a diferentes bases de datos. El protocolo específico usado depende del proveedor. Para su utilización hay que instalar en un servidor un software que atiende las llamadas de los programas Java, y las traduce a una llamada nativa al DBMS. Si se instala este servidor en el mismo host donde ejecuta el web server, permite que los applets, que no pueden conectarse con otro host que no sea del que provienen, puedan conectarse a un DBMS que no esté en el web server. Tipo 4: el driver native-protocol all-java convierte llamadas JDBC directamente en el protocolo de red usado por el DBMS. Esto permite llamadas directas desde la maquina del cliente al servidor del DBMS y es una solución practica para el acceso a Intranets. Dado que muchos de estos protocolos son propietarios, los proveedores de bases de datos son la principal fuente de este tipo de driver. A continuación veremos como se configuran algunos drivers JDBC. Es importante destacar que ninguno de los drivers fue testeado a fondo, y que la mayoría de los tests se hicieron utilizando Oracle, SQL Server y DB2/400. Para configurar estos drivers, muchas veces es necesario conocer el port tcp-ip en el que la base de datos está escuchando los requerimientos. En Windows NT, esta información se puede obtener en el archivo c:\winnt\system32\drivers\etc\services. Existe una página en Internet donde se puede consultar una lista de drivers JDBC disponibles, (ver en Anexo I) JDBC/ODBC Bridge Si se utiliza el bridge JDBC/ODBC es necesario instalar los drivers ODBC para el DBMS correspondiente. No se puede utilizar el bridge JDBC/ODBC con una base de datos SQL Server. Hay que setear las siguientes preferences de la siguiente forma: JDBC Driver Database URL sun.jdbc.odbc.jdbcodbcdriver o com.ms.jdbc.odbc.jdbcodbcdriver jdbc:odbc:<odbc data source> Como se observa, el nombre del JDBC comienza con sun, o con com.ms. Estos drivers funcionan solo en el JDK de Sun o el de Microsoft, respectivamente. De todos modos, si se usa uno de estos drivers, y se está ejecutando en la máquina virtual no correspondiente, la aplicación utiliza el otro. O sea, si está configurado con sun.jdbc.odbc.jdbcodbcdriver y se ejecuta en la maquina virtual de Microsoft, el programa automáticamente utilizará el com.ms.jdbc.jdbcodbcdriver, y viceversa. Si no se setea la preference JDBC Driver, asume que se quiere utilizar el JDBC/ODBC Bridge. No se recomienda usar este driver en producción, dado que tiene varios problemas conocidos. Entre ellos, algunos relativos a su utilización desde múltiples threads (lo que lo hace peligroso de utilizar en el servidor de aplicaciones), y de conversión de datos (lo que se traduce en que a veces ocurren errores en tiempo de ejecución del tipo invalid precision o invalid numeric length ). Acceso vía ODBC a DB2/400. Para conectarse al AS/400 vía ODBC es necesario configurar el Data Source directamente desde el ODBC. 13

15 Además de indicar el Nombre del Servidor al que se va a conectar y el usuario a utilizar se debe configurar: En el Tab de Format, setear la opción Naming Convention en System Naming Convention En el Tab de Performance (Rendimiento), deshabilitar el bloqueo de registros. En el mismo Tab, desmarcar el check sobre "Habilitar búsqueda previa durante ejecución" (Enable prechecking during execute) Si se ejecuta con JDK de Sun, no es necesario configurar el Data Source desde el diálogo ODBC, dado que pueden configurarse esos valores directamente en la preference Database URL del modelo de la siguiente manera; jdbc:odbc:<odbc data source>;nam=1;recblock=0;prefetch=0 Informix Thin Driver Es un driver de tipo 4. No necesita una configuración especial en el cliente. Hay una versión para JDK 1.1.x y superiores, y otra solo para JDK 1.2.x. Hay que setear las siguientes preferences de la siguiente forma: JDBC Driver Database URL com.informix.jdbc.ifxdriver jdbc:informixsqli://<host>:<port>/<database>:informixserver=<server> host = dirección IP del servidor. port = port en el que escucha el DBMS database = nombre de la base de datos server = nombre del servidor Por ejemplo: jdbc:informix-sqli://myhost:1526/mydb:informixserver=ol_myhost Notas de instalación: El producto se distribuye en un archivo llamado setup.class. Es necesario ejecutar este archivo con un intérprete Java, por ejemplo: java setup Se presentara un wizard de instalación. Entre las cosas que pide: Serial nbr = INF#J Key = ABCDEF Directorio destino = <cualquiera>, por ejemplo c:\jdbc\informix Luego de instalado, en el directorio LIB habrá un archivo ifxjdbc.jar que debe agregarse al CLASSPATH. java setup Oracle Thin Driver Es un driver de tipo 4. No necesita una configuración especial en el cliente. Hay que descomprimir el classes111.zip (el nombre de este archivo puede variar con su versión, ej: jdbco73.zip) que viene con el JDBC de Oracle en el directorio C:\JDK11\LIB\ORACLE (luego de la instalación deben quedar dos directorios debajo del directorio Oracle, uno llamado jdbc y otro sqlnet). 14

16 Hay que setear las siguientes preferences de la siguiente forma: JDBC Driver Database URL oracle.jdbc.driver.oracledriver host = nombre o dirección IP del servidor. port = port en el que escucha el sqlnet, en general 1526, puede ser 1525 o 1521 instance = en general ORCL Por ejemplo: jdbc:oracle:thin:@myserver:1526:orcl La versión del driver, que es la primera que se ha liberado sin el carácter de Beta, tiene un problema que causa que si en se graba un valor con el NullValue de un campo Date, luego si se quiere recuperar el dato preguntando por campo = nullvalue(campo) no lo recupera. Esto es porque no es capaz de almacenar la fecha que es la que utiliza como NullValue del Date. Esto no ocurre si se usan los drivers SequeLink de Intersolv para Oracle. AS/400 JDBC Native Driver Es un driver de tipo 2 que debe usarse para acceder a DB2/400 desde código que se ejecuta en el AS/400. Se debe configurar de la siguiente forma: JDBC Driver Database URL com.ibm.db2.jdbc.app.db2driver jdbc:db2://systemname/library; Por ejemplo: jdbc:db2://myas400/mylibrary El driver está incluido en el soporte para Java del AS/400 por lo que no es necesario agregar nada en el CLASSPATH. AS/400 Toolbox for Java Es un driver de tipo 4, se debe usar si se quiere acceder a DB2 desde equipos no AS/400. Se debe configurar de la siguiente forma: JDBC Driver Database URL com.ibm.as400.access.as400jdbcdriver jdbc:as400://systemname/library Por ejemplo: jdbc:as400://myas400/mylibrary Con el toolbox se distribuye un archivo llamado jt400.jar o jt400.zip que se debe poner en el CLASSPATH. 15

17 Para poder utilizar el AS/400 Toolbox for Java, es necesario tener instalados algunos PTFs. La lista de PTFs necesarios está publicada en una página de IBM(ver la referencia en Anexo I). i-net Software Este proveedor fabrica drivers de tipo 4 para SQL Server. Actualmente proveen un driver compatible con JDBC 1.x y otro compatible con JDBC 2.x. Se recomienda utilizar el compatible con JDBC 1.x Se debe configurar de la siguiente forma: JDBC Driver Database URL com.inet.tds.tdsdriver jdbc:inetdae:<host>:<port>?database=<database> Por ejemplo: jdbc:inetdae:myserver:1433?database=test Weblogic jdbckona Este proveedor fabrica drivers de tipo 2 y tipo 4. Se han probado los de tipo 4. Para SQL Server: JDBC Driver Database URL weblogic.jdbc.mssqlserver4.driver jdbc:weblogic:mssqlserver4:<database>@<host>:<port> Para Informix: Por ejemplo: jdbc:weblogic:mssqlserver4:test@myserver:1433 JDBC Driver Database URL weblogic.jdbc.informix4.driver jdbc:weblogic:informix4:<database>@<host>:<port> Por ejemplo: jdbc:weblogic:informix4:test@myserver:1526 La versión 3.11 de este driver tiene el mismo problema que el driver thin de Oracle para manejar los nullvalues en las fechas de Genexus. Funciona bien si se usa el jdbc-odbc bridge con un driver ODBC de Informix. Notas de instalación : Al descomprimir el archivo.zip en el que se distribuye el driver para SQL Server, se crea una estructura de directorios como la siguiente: weblogic mssqlserver4 classes - weblogic connect utils com - examples 16

18 En el classpath debe indicarse el directorio weblogic\mssqlserver4\classes, o sea, debe indicarse el directorio que tiene los subdirectorios weblogic, connect, utils y com. Para Informix es análogo, con la diferencia que el directorio de segundo nivel no se llama mssqlserver4 sino informix4. Merant DataDirect SequeLink Java Edition Es un driver de tipo 3, se ha probado con éxito para SQLServer, Oracle y DB2. JDBC Driver : intersolv.jdbc.sequelink.sequelinkdriver Database URL : Para SQL Server : jdbc:sequelink://<host>:<port>/[sqlserver];database=<database Name> Por ej: jdbc:sequelink://myserver:4006/[sqlserver];database=test; Para Oracle : jdbc:sequelink://<host>:port/[oracle] Por ej: jdbc:sequelink://myserver:4003/[oracle] Para DB2 Common Servers: jdbc:sequelink://<host>r:4007/[db2 on NT]database=<database> Por ej: jdbc:sequelink://myserver:4007/[db2 on NT]database=test Según la documentación del driver hay que poner un ';' antes de 'database', pero de esa forma no funciona. Es posible que se arregle para próximas versiones del driver, por lo que es posible que haya que poner el ';' antes de database. Si la plataforma donde ejecuta el DB2 es Unix, se debe poner "DB2 on Unix" en vez de "DB2 on NT" Notas de instalación : Como en todos los drivers de tipo 3, el producto consta de dos partes, una que debe instalarse en el cliente, y otra en el servidor. Al bajar el producto, se obtienen dos archivos, uno llamado setup.class que que es el correspondiente al cliente, y otro llamado slkntsrv.zip si se elige bajar el servidor para NT. Al bajar la parte del cliente hay dos opciones, una con weak encryption y otra con strong encryption. Se recomienda bajar la primera, a no ser que realmente sea necesario utilizar la segunda. Adicionalmente, si se desea bajar la versión con strong encryption hay que obtener una contraseña de activación de un distribuidor de Merant. Para instalar las clases en el cliente, hay que ejecutar un intérprete de Java y pasarle como parámetro el archivo setup.class. Por ejemplo, si se tiene instalada la máquina virtual de Microsoft, hay que ejecutar jview setup. Si se tiene instalada la máquina virtual de Sun, hay que ejecutar java setup. Esto iniciará un programa de instalación en el que debe ingresarse una password que se obtiene en la misma página web en la que se baja el software. Una vez instalado el software, en el subdirectorio driver\classes del directorio de instalación habrá un archivo slje.jar, que hay que incluir en el classpath (en el del cliente si se ejecuta en 2 capas, o en el del servidor de aplicaciones si se ejecuta en 3 capas). Para instalar las clases del servidor, ejecutar el programa de instalación y seguir las instrucciones. Debe ser instalado en el servidor donde está el DBMS que se desea acceder. 17

19 Configuración TCP/IP del SQL Server Para utilizar SQL Server desde Java debe configurarse el SQL Server de modo de que acepte conexiones TCP/IP. Para habilitar el protocolo TCP/P se deben seguir los siguientes pasos: Microsoft SQL Server 6.5: En el grupo de programas de SQL Server, ejecutar SQL Setup. En los dos primeros diálogos presionar el botón Continue. En el tercer diálogo, seleccionar Change Network Support. Seleccionar la opción TCP/IP y presionar el botón Ok En el siguiente dialogo ingresar el port TCP/IP en que quiere que el SQL Server reciba las llamadas (el valor por defecto es 1433). Microsoft SQL Server 7.0: En el grupo de programas de SQL Server, ejecutar SQL Server Network Utility. En la hoja de propiedades General presionar el botón Add Seleccionar la opción TCP/IP que está debajo de Network libraries Ingresar el port TCP/IP Para asegurarse de que el servidor está escuchando en un servidor/puerto específico, ejecutar: telnet <servidor o dirección ip> <número de port> Si la conexión es denegada, entonces el servidor o el puerto son incorrectos. 18

20 CONFIGURACIÓN DE LAS OPCIONES DE EJECUCIÓN DENTRO DE A continuación describiremos el significado de las diferentes secciones del diálogo de opciones de ejecución (ver Figura 1). Figura 1: Diálogo de Opciones de Ejecución Java Options Platform El diálogo de ejecución provee la posibilidad de configurar varios ambientes de ejecución de las aplicaciones Java. Actualmente permite almacenar una configuración para ejecutar y compilar aplicaciones en: Microsoft Sun JDK 1.1.x Sun JDK 1.2.x IBM s Jikes Compiler Para ejecutar en el ambiente de Microsoft y con el compilador Jikes es necesario utilizar un programa de make. En el diálogo de opciones de ejecución se permite elegir cual programa de make se quiere utilizar. Se recomienda utilizar el NMAKE, que se distribuye con el SDK de Microsoft para Java. 19

21 En algunos casos el código generado por la versión actual del compilador de Sun no ejecuta correctamente en el ambiente de Microsoft. El código generado por el compilador de Microsoft ejecuta correctamente en ambos ambientes, por lo que si se quiere que la aplicación ejecute en ambos ambientes se recomienda utilizar el compilador de Microsoft. En el ambiente de Microsoft, es posible habilitar y deshabilitar el compilador JIT. Hay que tenerlo habilitado (esto se configura en las opciones del Internet Explorer: Advanced/ Java JIT Compiler - Enabled) para que funcione correctamente la compilación. El compilador de Microsoft es, a la fecha, el mas rápido de todos, seguido por el compilador de IBM y luego el de Sun. En algunos casos, el compilador de Microsoft cancela con un Internal Error (por ejemplo en algunos procedimientos con mas de 50 parámetros). En esos casos, se debe utilizar alguno de los otros dos compiladores. Execute settings En esta sección se permite elegir si se quiere ejecutar la aplicación como application o como applet. Application Si se selecciona Application, tal como está seleccionado en el diálogo que se mostró anteriormente, se solicita el path del intérprete. Si se selecciona el ambiente de Microsoft, se pueden poner como intérpretes el JVIEW.EXE y el WJVIEW.EXE. La diferencia entre ambos es que el primero abre una ventana DOS antes de ejecutar la aplicación, y el segundo no. Aunque queda estéticamente mejor que se no se abra la ventana DOS, a veces es necesario hacerlo para poder ver algún mensaje de error. Si se selecciona el ambiente de Sun, las opciones correspondientes son JAVA.EXE y JAVAW.EXE. Applet Si se selecciona Applet, el diálogo de ejecución cambia (ver Figura 2) deshabilitando la especificación del path del intérprete y habilitando las opciones del Web Server. Figura 2: Formas de ejecución application/applet Si se selecciona Use Web Server, el navegador utilizará la URL indicada en Web Server Root como base para la ejecución de las aplicaciones. Esto permite ejecutar el applet en un ambiente más similar al que lo van a ejecutar los usuarios finales. No se pueden ejecutar reorganizaciones con esta configuración. 20

22 Web Browser Settings Si se marca la opción Use Default Browser, se ejecutarán los applets utilizando el browser que se tenga por defecto en el sistema. Si no se marca dicha opción, se puede ingresar el path del browser a utilizar. Adicionalmente, los JDK/SDK incluyen un programa llamado appletviewer que permite ejecutar applets. Por mas información sobre que hacer para ejecutar las aplicaciones como applet ver la sección Ejecución dentro de un web browser. Web Panel Execute Settings En esta sección se permite especificar en Web Server Root la URL que el navegador utilizará como base para la ejecución de los Web Panels. Compiler settings Compiler path Se especifica la ubicación del compilador Java a utilizar. Para el JDK de Sun el compilador se llama javac.exe y para el de SDK Microsoft jvc.exe. Ambos compiladores están ubicados en el subdirectorio BIN del directorio donde se instaló el JDK/SDK. Para el Jikes de IBM el compilador se llama jikes.exe y se encuentre en el directorio donde este se haya instalado. Normalemente se instala en el directorio jikes. Make Path Para compilar aplicaciones utilizando el compilador de Microsoft es necesario la utilización de un programa de make. Aquí se selecciona cual programa de make se desea usar. Con el SDK de Microsoft se distribuye uno llamado NMAKE, que es el que se recomienda usar. Sun no provee un programa de make, por lo que para la opción de compilar con el JDK de Sun se puede utilizar el NMAKE de otros proveedores, como ser el que provee el SDK de Microsoft. Si no se desea utilizar dicho programa de make, puede utilizarse uno que provee en forma gratuita la compañía Cygnus: Make. Se debe bajar el programa CDK.EXE e instalarlo. Entre otras utilidades se instalará un programa de Es posible que funcione bien con cualquier otro programa de make. Para la opción de compilar con el Jikes de IBM se sugiere utilizar el que provee el SDK de Microsoft. Customize Aquí se pueden especificar parámetros adicionales que se deseen pasar al compilador. 21

23 Para compilar con el JDK de Sun se recomienda usar el parámetro O que activa la optimización de código. Para el SDK de Microsoft, el parámetro /O hace lo mismo. Shared Settings Classpath Ubicación de las clases Java necesarias para la ejecución. El configurar mal esta opción es la principal razón por la que no compilen/ejecuten los programas generados. En caso de ejecutar como applet, no se toma en cuenta. Cuando se ejecuta como applet todas las clases necesarias deben estar al lado de la aplicación en el directorio del webserver donde se encuentra la aplicacion. El classpath tiene varias partes: 1. Debe indicarse donde están las clases de soporte del lenguaje java. Las clases en general se agrupan en un único archivo.zip o.jar. Para las versiones anteriores a la 1.2 del JDK de Sun están en \<Directorio del JDK>\lib\classes.zip. Para el SDK de Microsoft y para el JDK 1.2 de Sun, no es necesario configurar este valor, dado que sabe donde encontrar sus clases de soporte. 2. Debe indicarse donde están las clases de soporte de. Estas clases se copian al directorio del modelo, y están en un archivo llamado gxclassr.zip. 3. Debe indicarse el path actual, o sea. 4. Debe agregarse cualquier otro lugar en donde hayan clases que se deseen utilizar. En particular, el lugar donde están los drivers JDBC a utilizar, o las clases CORBA del producto que se esté utilizando. Los drivers JDBC a veces no se distribuyen compactados sino en una estructura de directorios, y en ese caso no se debe poner el.zip sino el directorio donde empieza la jerarquía de clases (consultar la documentación de cada driver JDBC). Por ejemplo: JDK de Sun: d:\jdk11\lib\classes.zip;gxclassr.zip;.; o d:\jdk11\lib\classes.zip;gxclassr.zip;d:\oracledriver\classes111.zip;.; En el último ejemplo se incluyen los drivers JDBC que están en el archivo classes111.zip del directorio oracledriver. SDK de Microsoft o JDK 1.2 de Sun gxclassr.zip;d:\oracledriver\classes111.zip;.; En caso de haber algo incorrecto con el seteo del class path se obtendrá al ejecutar un mensaje del estilo, can t find class xxxxx, donde xxxxx es el nombre de una clase valida para ser ejecutada, es decir esta disponible el xxxx.class e implementa la función externa main. Por el mismo motivo al compilar obtendremos un error del estilo: Package com. not found in import. y/o Superclass GXReorganization of class Reorganization not found. En caso de que se ejecute en Windows 95 puede dar el mensaje out of environment space. Si es así hay que agrandar el espacio de environment para ejecutar con esta opción. Para esto, modificar el config.sys de 22

24 modo que quede de la siguiente forma: Shell=<path del command.com> /p /e:<tamaño del environment> El path del command.com es en general c:\windows\command.com. El tamaño del environment depende de la cantidad de variables de entorno que se tengan. Si no hay ningún valor en el config.sys probar con /e:2048 funciona bien. Si hay algún valor, aumentarlo hasta que funcione bien. Ejecución desde fuera de Para ejecutar las aplicaciones generadas desde fuera del ambiente, hay que : Setear la variable de entorno CLASSPATH, tal como se setea cuando se ejecuta dentro de. Agregar al path el directorio donde se encuentre el intérprete, y el compilador Java que se desee usar. SDK de Microsoft Para compilar es necesario setear la variable de ambiente JAVAC al lugar donde está el compilador Java: SET JAVAC=C:\SDK3.2\BIN\JVC.EXE Para compilar, hay que ejecutar el comando: NMake f <nombre del programa principal>.mak Para ejecutar, se debe poner JVIEW <programa principal> Reorganización: El programa de la reorganización es Reorganization.java. Se debe compilar usando JVC Reorganization y luego ejecutarlo con Jview Reorganization. Luego de ejecutarla, realizar el copy model para actualizar el modelo. JDK de Sun Para compilar : si se utiliza el JDK 1.1 se debe ejecutar: javac depend <nombre del programa principal>.java si se utiliza JDK 1.2 se debe ejecutar: javac <nombre del programa principal>.java Para ejecutar, JAVA <nombre del programa principal> Para compilar una reorganización es necesario ejecutar JAVAC depend Reorganization.java Reorganización: Se debe compilar usando JAVAC Reorganization (agregando el parámetro -depend según la versión del JDK) y luego ejecutarlo con JAVA Reorganization. Luego de ejecutarla, realizar el copy model, para actualizar el modelo. Es posible compilar con un ambiente y ejecutar en el otro. Por información de como pasar parámetros a los programas GeneXus desde la línea de comandos ver en la sección 'Pasaje de parámetros externos'. 23

25 Ejecución dentro de un web browser El generador genera por cada objeto GeneXus main un archivo HTML que invoca a la aplicación generada. El CLASSPATH seteado en execution settings se ignora cuando ejecutamos en el browser, por lo que es necesario configurar correctamente el valor de la preference Additional Java Classes, tal como se explica en la Sección Significado de las Preferences/Additional Java Classes. Además hay que copiar al directorio donde se instalará la aplicación en el Web Server los siguientes archivos: En el caso de que se haya utilizado el Deployment Wizard, los archivos.cab,.jar y.html generados Estos archivos los transfiere automáticamente el Deployment Wizard En caso de que no se haya utilizado el Deployment Wizard, todos los *.class y *.htm y el archivo gxclassr.zip del directorio del modelo Archivos gxclassm.cab y gxclassn.jar que contienen las clases GeneXus. Estos archivos los transfiere automáticamente el Deployment Wizard En casode que no se hayan agregado los archivos de imágenes al.cab/.jar creado en el deployment wizard, estos archivos (*.bmp, *.jpg, *.gif) Archivo client.cfg Este archivo lo transfiere automáticamente el Deployment Wizard Si la aplicación se va a ejecutar en 2 capas, hay que copiar los drivers JDBC. Si estan dentro de un.zip, copiar el.zip y agregarlos en la preference 'Additional Java Classes'. Si están descomprimidos, copiar la estructura de directorios de modo que queden en un subdirectorio del directorio donde reside el web server. Para ejecutar las aplicaciones Java es necesario tener Netscape 4.06 o posterior, o Microsoft Internet Explorer 4 o superior con la máquina virtual o superior (ver en Anexo I dónde obtenerla). Como instalar automáticamente la Máquina Virtual de Microsoft Si se desea asegurar que el cliente tiene la última versión de la máquina virtual de Microsoft, se debe agregar lo siguiente al archivo.htm o.html que se vaya a utilizar como entrada a la aplicación: <OBJECT CLASSID="clsid:08B0E5C0-4FCB-11CF-AAA C608500" WIDTH=0 HEIGHT=0 CODEBASE="msjavx86.exe#Version=5,00,<build>,0"> </OBJECT> por ejemplo, si se requiere que el cliente tenga la versión build 3167: <OBJECT CLASSID="clsid:08B0E5C0-4FCB-11CF-AAA C608500" WIDTH=0 HEIGHT=0 CODEBASE="msjavx86.exe#Version=5,00,3167,0"> </OBJECT> Al ingresar a la página, si la versión que tiene instalada el usuario es menor a la requerida, se le solicitará autorización para instalar la nueva versión. En este ejemplo, el msjavx86.exe debe estar en el mismo directorio que el.htm. Si se desea, se puede poner una URL completa: <OBJECT CLASSID="clsid:08B0E5C0-4FCB-11CF-AAA C608500" WIDTH=0 HEIGHT=0 CODEBASE=" </OBJECT> 24

26 En siempre se encuentra la última versión de la VM, por lo que se puede utilizar dicha URL. El Deployment Wizard permite incluir este tag html automáticamente en el.html que se genera para la instalación de la aplicación. SIGNIFICADO DE LAS PREFERENCES A continuación se detallará el significado de las preferences específicas de Java, o que tienen un comportamiento particular. Las preferences relativas a la ejecución distribuída asi como las relativas a Web Panels se explicarán en la sección correspondiente. Reorganize Server Tables En todos los generadores C/S existe esta preference, que lo que hace es decirle al especificador que no es necesario generar información de reorganización para la tablas del servidor (los valores posibles son Yes/No). En el caso de Java, tiene un significado algo distinto, dado que aunque no se actualicen las tablas del servidor, deben actualizarse las GXDB++ del cliente. Por esta razón el especificador actuará como si fuera a crear las tablas, y el programa de reorganización no efectuará las operaciones en el servidor pero actualizará las GXDB++. No será necesario conectarse al servidor para realizar dicha operación. Es decir, se debe setear la preference en No si se tiene otro modelo que administra las tablas para que la reorganizaciones se hagan solo una vez. JDBC Log File Esta opción se puede utilizar para debugging de problemas con el DBMS o con el driver JDBC. En caso de que esté vacía, no se generará ningún tipo de log. Si se pone un nombre de archivo, en dicho archivo se generará un log con las operaciones JDBC realizadas. Por ahora existe un solo nivel de trace. Para que el log funcione efectivamente se deben utilizar las clases de debug, que están contenidas en el archivo gxclassd.zip, por lo que se debe cambiar el classpath de las preferencias de ejecución, de modo que en vez de gxclassr.zip diga gxclassd.zip. Maximum open cursors per connection Uno de los costos mas importantes en las operaciones JDBC es el de preparar las sentencias SQL. La preparación incluye la compilación y validación de la sintaxis de dicha sentencia por parte del servidor. Los programas generados para Java realizan un manejo inteligente de los cursores abiertos, de modo de que no vuelven a preparar cursores que ya fueron preparados. Para eso mantienen un pool de cursores preparados, que tiene un tamaño por defecto de 100 cursores. Si se desea cambiar este número, se puede cambiar el valor de esta preference. En caso de que se estén ejecutando las GXDB en el servidor, este número de cursores abiertos se mantendrá por cada cliente que se conecte al servidor de aplicaciones (verla sección de ejecución en múltiples capas mas adelante). Esta preference también es utilizada por el esquema de connection pooling (ver la sección sobre Connection 25

27 Pooling). SMTP Server (for mail functions) En el generador se implementaron las funciones de mail. Los mails se envían por el protocolo SMTP (no se soporta utilizar MAPI), y para poder hacerlo es necesario especificar que servidor de SMTP se va a utilizar. En caso de que no se especifique ninguno y se esté ejecutando la aplicación como un applet, se intentará utilizar el mismo servidor que cumple las funciones de servidor de web. Por mas información sobre el funcionamiento de las funciones de mail, ver la sección específica sobre el tema. Additional Java Classes En el.htm que se genera para cada objeto main, se especifica que las clases las debe ir a buscar a un archivo gxclassr.zip, que se copia al directorio del modelo. Este archivo tiene las clases compiladas sin información de debug y comprimidas, de forma que es el que se debe usar para el web. En caso de que se utilice algún driver JDBC que se distribuya en un.zip, debe agregarse dicho archivo en esta lista. Si se quiere agregar mas de uno, separarlos por,. Java Package Name Esta preference indica al generador en que package Java se quieren generar los programas. Esto es necesario especificarlo cuando se quiere instalar aplicaciones en los navegadores de los usuarios finales. La idea es que si dos proveedores distintos quieren instalar clases Java en la máquina de un usuario final, las clases tienen que tener nombres distintos. La forma de asegurar esto es mediante los Packages. En general, los packages tienen un nombre de la forma: <com>.<compañía>.<producto>, por ejemplo com.artech.siscli. Si se especifica un package, los programs fuente serán generados en un subdirectorio del directorio del modelo que refleje el nombre del package. Por ejemplo, en el caso anterior, los fuentes se generarán en el directorio com\artech\siscli del directorio del modelo. La compilación y ejecución toman en cuenta el valor de esta preference, por lo que es transparente para el usuario GeneXus. También es tomado en cuenta para generar el.htm que se utiliza para llamar a la aplicación como applet. Generate Makefiles Por defecto, cuando el generador termina de generar los objetos, recalcula todos los makefiles que se deben regenerar y los genera. Los makefiles a regenerar son los correspondientes a los objetos main en cuyo árbol de llamadas están los objetos generados. Además, luego de generar los makefiles de cada objeto main, se genera un makefile para el Developer Menu que permite que se compilen todos los objetos del modelo. En modelos muy grandes, tanto el cálculo de los makefiles a regenerar como la generación de los mismos puede demorar un tiempo considerable (un par de minutos). Para evitar este problema, se puede utilizar esta preference. Si se le pone el valor No, no regenera los makefiles al final de la generación. Obviamente en algunos casos es necesario regenerar los makefiles. Por ejemplo, si se agrega un objeto al modelo, o si agrega un call a un objeto que no estaba en el arbol de llamadas de los mains del objeto al que se agrega el call, o si se marca un objeto como main. En estos casos, se debe poner la preference en el valor 26

28 Yes para que se vuelvan a regenerar los makefiles. Tampoco es necesario generar los makefiles si se utiliza un compilador que no utliza un comando MAKE para compilar. En general es recomendable tener esta preference en el valor por defecto ("Yes"). JDBC Driver Aquí se debe poner el nombre del driver JDBC. Es case sensitive. La sintaxis de este setting para diferentes drivers fue descripta anteriormente en el detalle del uso de cada driver JDBC en la sección Instalación del Software necesario para acceso Cliente Servidor.. Si no se indica ningún valor en esta preference, se asume que se quiere utilizar el JDBC/ODBC Bridge. Database URL Aquí se debe poner la URL de la base de datos. Es case sensitive. La sintaxis de este setting para diferentes drivers fue descripta anteriormente en el detalle del uso de cada driver JDBC en la sección Instalación del Software necesario para acceso Cliente Servidor. Database Name En caso de conectarse a un AS/400 aqui se debe poner el nombre de la biblioteca. User Id Identificación del usuario para conectarse a la base de datos. Si se especifica un valor para esta preference no se solicitará el dialogo de login y se conectará directamente. Es importante tener en cuenta que es posible decompilar un fuente java para ver el valor de esta preference, por lo que debe utilizarse prudentemente. User Password Contraseña del usuario para conectarse a la base de datos. En caso de que la conexión se haga en dos capas, directamente desde el cliente, esta contraseña se guardará en el archivo client.cfg, que es accesible por el cliente, por lo que presenta un riesgo de seguridad. Si la conexión es en tres capas,. o sea, a través de un servidor de aplicaciones, la contraseña se encuentra en el server.cfg, y su valor no es accesible por el cliente. List of remote programs (JDBC) Esta preference permite especificar una lista de programas almacenados en la base de datos (stored procedures). Se deben especificar los nombres de los programas separados por espacios. Cuando el generador encuentra un call a un programa incluido en la lista, hace un call vía JDBC en vez de hacer un call normal. Si se está ejecutando en 3 capas, el call al programa almacenado se hace desde el servidor de aplicaciones, dado que no hay conexión directa entre el cliente y la base de datos. AS/400 Specific / Library List Aquí se debe especificar la lista de bibliotecas del AS/400. Si se especifica algún valor, se debe agregar siempre *LIBL, para no perder la lista de bibliotecas del usuario. 27

29 Field exit Indica la forma como se interpretan las teclas para navegar entre los diferentes controles de la pantalla. Los valores posibles son: Tab, Shift-Tab Si se selecciona este valor, para navegar por los controles se usan las teclas Tab y Shift+Tab, y para confirmar un nivel o ejecutar el evento Enter de un Work panel, se presiona la tecla Enter. Enter, Down Arrow, Up Arrow, Tab, Shift-Tab Si se selecciona este valor, con la tecla Enter se pasa al siguiente campo, menos en los botones que se ejecuta el evento asociado. Con las flechas se puede navegar por los controles,. Adicionalmente funciona el Tab y el Shift Tab para pasar al control siguiente/anterior. "+" Key, Down Arrow, Up Arrow, Tab, Shift-Tab El comportamiento es análogo al anterior, pero la tecla + pasa al siguiente campo en vez de la tecla Enter. Refresh Key Indica que tecla se utiliza para disparar el refresh de un Work panel. Show Form En todas las aplicaciones, se despliega la pantalla de un work panel/transacción antes de ejecutar el evento Start. Esto ocasiona que si, por ejemplo, en el evento Start se ocultan objetos en pantalla, se vea en primer lugar la pantalla tal como se diseñó, con todos los objetos, y luego se vea como se va ocultando cada uno, hasta que la pantalla quede como el desarrollador quiso. Si esta preference se pone en "After Start Event", primero se ejecuta el evento Start y luego se despliega la pantalla, evitando ese efecto. Si se pone el valor Before Start Event se deja el comportamiento habitual de las aplicaciones Genexus. El valor por defecto para Java es After Start Event. Default user interface Determina que biblioteca de clases se va a utilizar para el manejo de la interfaz de usuario. Las posibilidades son: Best possible (WFC, JFC, AWT) Windows Foundation Classes (WFC) Java Foundation Classes (JFC) Abstract Windowing Toolkit (AWT) Si se setea el valor Best Possible, en tiempo de ejecución se decidirá que biblioteca utilizar, intentando primero utilizar las WFC, en segundo lugar las JFC, y en tercer lugar las AWT. Por mas detalles sobre las diferencias de cada una de las opciones referirse a la sección Manejo de la interfaz de usuario. JFC Look & Feel En JFC, se puede especificar que Look and feel se quiere utilizar. Existen básicamente dos opciones. Usar un look and feel específico de la plataforma (que en Windows aparece como Windows, en Mac como Mac, etc.), o un look and feel igual para todas las plataformas. 28

30 Si se selecciona la opción Platform s Native L&F se utilizará el look and feel para Windows en Windows, para Mac en Mac, Motif en Solaris, etc. Si se selecciona la opción Cross platform L&F se utilizará el mismo look and feel en todas las plataformas. Use.GIFs instead of.bmps El formato.bmp es un formato muy práctico para aplicaciones locales, pero ineficiente para aplicaciones en Internet, dado que el tamaño de los archivos.bmp es mucho mayor al de los archivos.gif o.jpg. Para posibilitar la ejecución sin modificación de las aplicaciones actuales se implementó soporte para BMPs en el generador Java (no son soportados nativamente por Java). De todos modos, si se quiere poner en producción la aplicación, es necesario encontrar otra solución. Esta preference permite que el generador en vez de usar.bmps utilice.gifs. Los valores posibles son: Never Always If.GIF exists Se utilizan siempre.bmp Se utilizan siempre.gifs Si existe el.gif, se usa el.gif, sino el.bmp. Esta solución es la mas flexible pero es mas lenta, dado que debe chequear la existencia del.gif. Durante la prototipación, se puede usar cualquiera de los valores. Se recomienda que para la puesta en producción de la aplicación se conviertan los.bmp a.gif y se configure esta opción para que siempre use.gif. En Genexus es posible utilizar.jpg. Esta preference no tiene ningún efecto sobre los.jpg. Click to sort in subfile (Workpanel) Indica si al dar click en el título de las columnas del subfile este se ordena por el valor de dicha columna o no. Enabled Disabled Al dar click en la columna del subfile, se ordena Al dar click en la columna del subfile, no se ordena Color In Read-Only Fields Esta propiedad se implementó para que las aplicaciones puedan ser compatibles con las aplicaciones generadas con Foxpro/Visual Foxpro y Visual Basic. Original Grayed (Windows Default) Los campos deshabilitados o con noaccept se despliegan del mismo color que se definió en GeneXus. Los campos deshabilitados o con noaccept se despliegan en gris. 29

31 MANEJO DE LA INTERFAZ DE USUARIO En el mundo Java existen básicamente tres alternativas para el manejo de la interfaz de usuario: WFC, JFC y AWT. Veremos las ventajas y desventajas de cada una. Maquinas virtuales en las que está pre-instalado WFC JFC AWT Internet Explorer 4.0, con Ningun Todas versión de la Java VM a posterior a la Plataformas soportadas Windows Todas Todas Calidad de la multi-plataforma ( se No aplicable Buena Mala ve igual en todas las plataformas?) Capacidad de representar objetos Buena Buena Mala Genexus Performance Buena Regula r Regular El principal inconveniente de utilizar AWT es que en Windows 95, y usando el ambiente de Sun, los controles de edit tienen un margen a cada lado del texto, por lo que si en Genexus se especificó un edit de largo 5 caracteres, en el mismo largo con AWT se ven 3. Esto no pasa en Windows NT ni con JFC o WFC. Con AWT, si se pone un combobox en un subfile, al obtener el foco, el control queda mas alto que el tamaño de la fila del subfile, por lo que se superpone con la fila que está debajo. Esto es porque con AWT el combobox no puede tener un alto menor que un mínimo fijado por AWT. Si se desea utilizar JFC es necesario agregar al CLASSPATH el archivo swingall.jar que se distribuye con la instalación de las JFC. Actualmente la última versión liberada es la y es la que se recomienda utilizar. Para utilizar las WFC es necesario ejecutar las aplicaciones con el Java de Microsoft. A continuación se detalla una lista de diferencias en las características soportadas por cada alternativa de manejo de interfaz de usuario: AW T JFC WF C Propiedad Control Box en Work panels No No Si Propiedad Border Style en Work panels No No Si Propiedad Maximize Button en Work panels No No Si Propiedad Minimize Button en Work panels No No Si Propiedad Show in Taskbar en Work panels No No Si Fonts nativos de Windows No No Si Propiedades FontUnderline y FontStrikethru No No Si Controles de Edit que con Frame = None o Frame = Single No Si Si Aceleradores para los botones ( por ej. &Ok, &Cancel) No Si Si Acepta archivos.ico como ícono de los work panels No No Si Muestra correctamente GIF animados Si Si No Consideraciones acerca de WFC a) Soporta las teclas de función F1 F20 b) Si se tiene un form cuyo tamaño es mayor al de la pantalla, se hace scroll. Esto permite tener forms 30

32 de largo indefinido c) La propiedad.forecolor de los checkboxes tiene efecto solo para el caption del checkbox, no para el cuadrado del check ni la cruz. Esto implica que si se pone un checkbox en un subfile, como no tiene caption, la propiedad.forecolor no tenga ningún efecto. Consideraciones acerca de JFC a) Soporta las teclas de función F1 F12 b) Soporta Look & Feels intercambiables. Esto es, puede cambiarse la forma en que se dibujan los controles standard para que se parezcan a los de otra plataforma. Por mas información ver la preference JFC Look & Feel c) Si el usuario cambia el tamaño de un form, los controles ajustan su tamaño de forma que se mantenga la proporción de tamaños. d) A partir de la versión 1.1.1, en los captions de los Labels, botones y menuitems se puede incluir código HTML, por ejemplo: Label1.Caption = "<html> Label with <i>various <font color=blue>text styles<br> and a new line!</font></i>"; Consideraciones acerca de AWT a) Soporta las teclas de función F1 F12 b) Si el usuario cambia el tamaño de un form, los controles ajustan su tamaño de forma que se mantenga la proporción de tamaños. 31

33 LLAMADAS A PROCEDIMIENTOS EXTERNOS Llamadas a procedimientos Java no generados por GeneXus Es posible realizar llamadas a procedimientos Java no generados por. Existen dos características de Java que hacen que esta tarea sea algo mas engorrosa que en otros generadores. En primer lugar, en Java se escriben clases, y no se puede ejecutar una clase sino que hay que ejecutar un método particular de una clase. En segundo lugar, Java no pasa los parámetros por referencia, cosa que es necesaria para los procedimientos. Para solucionar el primer problema, siempre que haya un procedimiento externo, se llamará a un método execute, al que se le pasarán los parámetros necesarios. O sea, la clase que tenga el código externo debe tener un procedimiento definido como el siguiente: public void execute( <parametros>) { } y un constructor que reciba un parámetro entero public <nombre de la clase> (int remotehandle) { } Para el segundo problema, en las clases estándar de existen clases para cada tipo de datos primitivo Java, y los parámetros deben pasarse dentro de objetos de esas clases. Las clases se llaman GX <Nombre del Tipo>. Por ejemplo, si se quiere llamar a un procedimiento, y los parámetros son: &a = N(2) &b = N(4) &c = N(8) &d = D &e = C(10) en este caso el call que generará GeneXus será de la siguiente forma: // Defino los objetos auxiliares. Esto se hace una sola vez, en el momento de inicializar los // valores del programa generado GXByte _a = new GXByte(); GXShort _b = new GXShort(); GXInteger _c = new GXInteger(); GXDate _d = new GXDate(); GXString _e = new GXString(); // Guardo en los objetos auxiliares los contenidos de las variables a pasar. _a.setvalue(&a); _b.setvalue(&b); _c.setvalue(&c); _d.setvalue(&d); _e.setvalue(&e) 32

34 // Llamo al programa new pexterno(remotehandle).execute(_a, _b, _c, _d, _e); // Cargo en las variables los valores que hay dentro de los objetos. &a = _a.getvalue(); &b = _b.getvalue(); &c = _c.getvalue() &d = _d.getvalue(); &e = _e.getvalue() Para que la llamada funcione correctamente, el programa externo pexterno.java debe escribirse de la siguiente forma: public pexterno(int remotehandle) { } public void execute(gxbyte a, GXShort b, GXInteger c, GXDate d, GXString e) { (...) } La variable remotehandle tiene el identificador del proceso en el servidor. Se necesita poner siempre, aunque se ejecute en el cliente. Se puede especificar 0 en ese caso. La correspondencia entre los tipos GeneXus y los tipos "GX<Type>" de Java es la siguiente: Tipo GeneXus hasta N(2, 0) hasta N(4, 0) hasta N(9, 0) desde N(10, 0) hasta N(9, X), X > 0 desde N(10, X), X > 0 C(X) Date o DateTime Tipo Java GXByte GXShort GXInt GXLong GXFloat GXLong GXString GXDate En caso de que se pase un array como parámetro, la llamada se hará de la siguiente forma: new pexterno(remotehandle).execute(string [] p1) En este caso, se pasa un array de strings como parámetro. Observar que en este caso se usan los tipos nativos de Java y no los de Genexus (se usa String y no GXString). Esto es porque la forma que Java pasa los arrays como parámetro es equivalente al modo que los pasa GeneXus. Se asume que los programas externos están en clases con nombres escritos en minúsculas, por lo que, dado que los nombres de las clases en Java toman en cuenta mayúsculas y minúsculas, hay que nombrar a los programas externos con minúsculas. En los calls a procedimientos externos se asume que el procedimiento está en el mismo package del objeto generado. En caso de que se necesite llamar a métodos de objetos en otros packages, se puede utilizar el comando "java" o escribir un procedimiento en el package del código generado que invoque al método del objeto. 33

35 El call en GeneXus se escribe de la misma forma que siempre, o sea: call('pextern', <parametros>) Comando JAVA El comando Java tiene algunas diferencias con respecto a los comandos equivalentes en los otros generadores: Se pueden poner variables y atributos GeneXus dentro del comando, y el generador transformará dichos variables a los variables correspondientes en el programa generado. La sintaxis para hacerlo es la siguiente: java... [!&Variable!] java... [!Attributo!] O sea, hay que poner el nombre tal como se utiliza en Genexus, pero entre las cadenas [! y!]. Se pueden poner cualquier cantidad de variables / atributos en el mismo comando. Tiene las siguientes limitaciones : o No se pueden asignar atributos o No se pueden asignar variables que estén dentro de un subfile, si se está ejecutando dentro de un evento distinto a Start o Exit. o Las variables deben utilizarse en algún lugar del código Genexus. Si no se utiliza en ningún lugar, no se define la variable en la spec, por lo que no se puede obtener información de ésta. o Si se asigna una variable que está presente en la pantalla, no se refresca el valor de la misma. Esto es porque el generador, cada vez que se asigna una variable dentro del programa GeneXus, se encarga de generar el código necesario para refrescar el valor en pantalla, pero no lo hace si se asigna la variable dentro del comando Java. Para que se refresque el valor en pantalla hay que hacer lo siguiente: &Aux = &Vble java [&Aux] = dosomething(); &Vble = &Aux Se soporta un comando RaiseEvent que permite ejecutar un evento cualquiera. La sintaxis es la siguiente: por ejemplo: java [!RaiseEvent <Nombre del evento>!] java [!RaiseEvent enter!] java [!RaiseEvent Add Client!] Pasaje de parámetros externos Si se define como main un objeto con parámetros, los parámetros se le pasan en la command line; 34

36 java <objeto> parm1 parm2 parm3. Los parámetros de tipo Date o DateTime deben pasarse con el formato "YYYYMMDD" o "YYYYMMDDHHMMSS" respectivamente, por ejemplo: jview rinvoice Si se especifican menos parámetros de los definidos en el objeto GeneXus, se le asignará el valor nulo a los parámetros omitidos. No es posible pasar parámetros a un main si se ejecuta desde utilizando el Developer Menu En un applet, los parámetros se especifican en el archivo HTML con el tag: <PARAM NAME=<parametro> VALUE=<valor>> por ejemplo <PARAM NAME=P0 VALUE="1"> Los parámetros deben tener nombre P0, P1, P2,,PN. El generador genera un archivo.htm para cada main, y este archivo tiene la estructura para poner los parámetros. Por defecto todos los parámetros son nulos ( ). Llamadas a programas externos ( stored procedures ) En algunos casos, los generadores necesitan tener más información sobre los programas externos que la que tienen hoy. En particular, para los stored procedures del AS/400, en determinadas versiones del OS/400, es necesario saber en que lenguaje fue desarrollado el procedimiento a llamar. Una forma de definir que un objeto es un stored procedure, es poner el nombre de dicho objeto en la preference List of remote programs (JDBC). A partir del patch #1, se implementó otro mecanismo un poco mas sofisticado. La definición de programas externos se hará en un archivo llamado extprog.ini que debe estar en el directorio del modelo. Para el caso particular de los stored procedures del AS/400 debe definirse de la siguiente forma: [ExternalPrograms] Program1=UpdClients Program2=<..> [UpdClients] ProgramType=StoredProcedure ParmMode=in, inout, out [UpdClients.as400] Name=MYLIB.updcli Language=RPG ParmType=integer,integer,char 35

37 En este ejemplo en particular, se define un único programa externo llamado UpdClients. Para este programa se le dice que es de tipo StoredProcedure (luego se incorporarán mas tipos de programas externos) y se define el modo en que se pasan los parámetros en la entrada ParmMode. Aquí hay que poner una lista de valores separadas por coma, con un valor por cada parámetro del procedimiento. Los valores posibles son in, inout y out. Luego se puede definir información específica de cada procedimiento para cada DBMS. En particular para el AS/400 se puede definir el nombre del objeto (en este caso MYLIB.updcli), el lenguaje en que se desarrolló (en este caso RPG), y la lista de los tipos de datos con que está definido el objeto. Este mecanismo nos permite bastante mas flexibilidad que el anterior, dado que antes estabamos forzados a que todos los parámetros fueran de inout, que los programas estuvieran en las bibliotecas declaradas en las preferences, y que los tipos de los parametros fueran numeric y char. Ahora se puede llamar a cualquier procedimiento del AS/400. En versiones posteriores se extenderá la funcionalidad de esta nueva característica, para permitir definir propiedades específicas de otros DBMSs (por ejemplo el package en que están los stored procedures en Oracle), y de otros tipos de programas (por ejemplo, definir que determinado programa externo es un ejecutable). Ejecución de procedimientos almacenados en el AS/400 utilizando múltiples generadores por modelo Otra forma de ejecutar procedimientos almacenados (Cobol/RPGl) en el AS/400 es utilizando el mecanismo de múltiples generadores por modelo, indicando para cada objeto el generador que se quiere utilizar. Esto se podrá hacer desde la versión 6.1 Patch 3 de GeneXus. Para utilizar el mecanismo de múltiples generadores por modelo, es necesario tener como generador de la reorganización el generador Cobol o RPG, y como generador secundario (y si se desea, por defecto) el generador Java. Esto debe ser así porque los programas Cobol y RPG requieren que las tablas sean creadas por Cobol/RPG. Por otro lado, el generador Java necesita tener las GXDB++ siempre actualizadas, y la actualización se realiza en tiempo de creación / reorganización. La única solución actual es que luego de cada creación / reorganización se cambie el generador del modelo a Java, y se haga una creación de la base de datos con la preference Reorganize Server Tables = No, de modo que se creen las GXDB++ reflejando el estado actual del modelo. Luego de esto se debe volver a poner el generador Cobol/RPG como generador del modelo. Cualquiera sea la forma en que se indique los objetos a ejecutar remotamente, es necesario, una única vez, ejecutar la opción del Developer Menu 'Create AS/400 Stored Procedures', que está en el sub-menu de 'Utilities'. Esta opción solo aparece cuando hay algun procedimiento remoto definido. Al ejecutar esta opción se le indica al motor SQL del AS/400 que determinados procedimientos van a ser llamados vía JDBC. Debe ejecutarse cada vez que se agregue un nuevo programa remoto. En un futuro esto se hará automáticamente en tiempo de creación / reorganización de la base de datos. REORGANIZACIÓN Es necesario hacer una creación de la base de datos con Java, dado que luego de que esta se ejecuta correctamente se crean las clases de acceso a la base de datos (GXDB++) que los programas generados utilizan. Si no se desea crear la base de datos física, utilizar la preference Reorganize Server Tables = No. 36

38 ACTUALIZACIÓN DE LAS GXDB++ Las GXDB++ deben estar siempre sincronizadas con el estado del modelo GeneXus. La sincronización es automática y se efectúa cuando se ejecuta una reorganización. Sin embargo, hay algunos casos en los que GeneXus no genera una reorganización pero es necesario actualizar las GXDB++. En estos casos, actualmente no hay otra opción que cambiar la preference Reorganize Server Tables a No, y hacer una creación de la base de datos. Los casos en los que no se sincronizan automáticamente las GXDB++ son: Si se agrega o se cambia la definición de un Data View Si se hacen cambios en la estructura de subtipos que no impliquen reorganización PASAJE DE ARRAYS COMO PARÁMETROS Cuando se pasan arrays como parámetros, deben ser del mismo tipo java en el programa llamador y en el programa llamado. Por ejemplo, se puede pasar un array de N (1) si se recibe un N(2) (ambos son bytes Java), pero no se puede pasar un array de N(3) si se recibe un N(2) (el primero es un short Java). Esta restricción solo existe para los arrays. Para las variables, el generador se encarga de la conversión de tipos. IDENTIFICACION DE VERSIONES Con el generador Java se proveen algunos mecanismos para controlar si los números de versión del generador, los fuentes y las clases estándar coinciden. En el archivo WGEJAVA.DAT, la primer línea tiene la siguiente forma: =GJV00266.VER El número del final, en este caso el 266, indica la versión del generador. Este número se incrementa en cada armado del generador, por lo que siempre crece. Dentro de los.zip con las clases estándar (gxclassr.zip y gxclassd.zip) hay un archivo llamado version.txt que tiene como único contenido un número que debe coincidir con la versión indicada en el WGEJAVA.DAT El numero de versión del ejecutable del generador (wgejv32.exe), es de la forma NNN donde NNN es el mismo número que el indicado en el.dat. Para ver la versión del ejecutable, en el explorador de Windows presionar el botón derecho, seleccionar properties y luego la pestaña Version. El número aparecerá donde dice File Version. En el cabezal de los fuentes generados, existen una línea con la siguiente forma: Author: GeneXus Java Generator versión 266 en donde el último número coincide con el número de versión del.dat. Obviamente, para el correcto funcionamiento de la aplicación, todos los números de versión deben coincidir. 37

39 En tiempo de ejecución, el diálogo por defecto de la opción Acerca de del menú, despliega el número de versión del generador. REPORTES Los reportes se implementaron utilizando el Report Viewer. Ésto implica que actualmente solo se puede imprimir desde equipos Windows, tanto en el cliente como en el servidor. Si se ejecutan como applets, éstos no pueden ser main, sino que deben ser llamados desde un work panel Cuando se imprime a un archivo, el nombre del archivo es el mismo que la descripción del reporte que se está imprimiendo (si el reporte se llama Listado de Clientes, se imprimirá a un archivo llamado Listado de Clientes.gxr ). La funcionalidad de los reportes es la habitual, habiéndose implementado todas las funciones de los mismos. Esto es, se soportan todos los comandos GeneXus (MB, MT, NOSKIP, PRNCMD, etc.), la impresión en modo texto, la impresión a un archivo, las llamadas de un reporte a otro, etc. 38

40 WEBPANELS Por que Web Panels en Java? Existe un API especificada por Sun Microsystems llamada 'Java Servlet API' que define la forma para ejecutar lo equivalente a los Web Panels de GeneXus. Esta API define una arquitectura moderna y eficiente, que presenta algunas ventajas importantes con respecto a la ejecución con CGI que se utiliza en los Web Panels generados con Visual Basic, RPG o C/SQL. Las ventajas son básicamente las siguientes: Con CGI, cada vez que se ejecuta un Web Panel, se levanta un proceso en el servidor, se ejecuta, y se baja el proceso. Esto impone una carga considerable al servidor, en particular a aquellos en los que levantar un proceso tiene un costo alto. Los Servlets Java se cargan la primera vez que se ejecutan, y luego no se vuelven a cargar. Los Web Panels con CGI deben conectarse a la base de datos cada vez que se ejecutan. Los Servlets pueden mantener conexiones abiertas y utilizarlas a medida que las van necesitando Los Servlets ejecutan dentro de motores de Servlets que permiten administrar eficientemente el manejo de los recursos del servidor. Se pueden ejecutar en cualquier sistema operativo para el que haya disponible una máquina virtual Java y un servidor web que permita ejecutar Servlets (NT, Win95, AS/400, AIX, Linux, Macintosh, etc.). El soporte de Java para Servlets es bastante sofisticado, lo que hace sencillo agregar nueva funcionalidad a los Web Panels, como manejo de sesiones, compresión de páginas HTML en tiempo real, etc. Adicionalmente, se pueden aprovechar las ventajas del generador Java en los Web Panels : Utilizar un pool de conexiones a la base de datos. Distribuir la ejecución de la aplicación en múltiples capas. En las primeras pruebas de performance, los Web Panels Java son mas rápidos que los Web Panels Visual Basic, igual de rápidos que C cuando tienen muy poco procesamiento, pero mas lentos que C si tienen bastante procesamiento. Si se desea probar la performance de los Web Panels de una aplicación en particular, se puede utilizar el producto JMeter (ver en Anexo I dónde obtenerlo). Para ejecutarlo es necesario tener una máquina virtual Java y las Java Foundation Classes 1.1 o posteriores. Funcionalidad adicional disponible en Java Compresión de páginas Web Los Web Panels en Java pueden enviar la página HTML comprimida, de modo que sea descomprimida en tiempo real por el navegador. La compresión se realiza solo si el navegador indica que es capaz de decomprimirlo. Esta opción puede deshabilitarse con la preference 'Auto compress web pages', dado que es posible que algunos navegadores no reporten correctamente su capacidad para descomprimir las páginas, y no puedan desplegar correctamente las páginas. En las pruebas que hemos realizado, se ha comportado 39

41 correctamente con todos los navegadores. Manejo de sesiones Se implementan las siguientes procedimientos standard para el manejo de sesiones. Nombre Sintaxis Función Parámetros WebSessionId call('websessionid', &SessionId) Devuelve un identificador único para la sesión. Puede incluir números y letras en mayúscula o minúscula. Estos IDs se garantizan únicos durante la existencia de la sesión. Una vez que la sesión se termino, en teoría se podría volver a asignar el mismo numero a otra. Esto es importante porque si usa como ID clave en una tabla, hay que asegurarse que al comenzar la sesión no haya datos en esa tabla con ese ID. &Session C Identificador de la sesión. El largo no tenemos claro si es así, en Id (50) principio no está especificado el máximo, pero en ningún motor de servlets ha sido mas grande que 30. Nombre Sintaxis Función webputsessionvalue call('webputsessionvalue', &Clave, &Valor) Permite almacenar variables globales a la sesión. Cualquier otro web panel que esté dentro de la misma sesión puede obtener los valores guardados. Parámetros &Clave C Identificador del valor a guardar. Puede ser cualquier cadena de caracteres. No es sensible a mayúsculas/minúsculas. &Valor C Valor a almacenar. Tiene que ser de tipo carácter. Nombre Sintaxis Función WebGetSessionValue call('webgetsessionvalue', &Clave, &Valor) Permite recuperar el un valor almacenado en la sesión. En caso de que no se haya almacenado ningún valor con esa clave, devolverá el valor nulo de GeneXus. Parámetros &Clave C Identificador del valor guardado. No es sensible a mayúsculas/minúsculas. &Valor C Valor almacenado a recuperar. Requerimientos Para poder compilar los Web Panels generados con Java es necesario obtener el JavaServer Web Development Kit o posterior (ver en Anexo I dónde obtenerlo). Al instalar este producto, en el subdirectorio lib, se encontrará un fichero llamado servlet.jar, que debe incluirse en el CLASSPATH que se especifica en las opciones de ejecución. Para poder ejecutar los Servlets dentro de un servidor Web es necesario un servidor de web que soporte Servlets, o un motor de Servlets en caso de que el servidor de Web no lo soporte. Existen varios motores de servlets (ver en Anexo I dónde obtenerlos), de los cuales se han probado los siguientes: Jrun JavaServer Web Development Kit que provee un servidor de Servlets que se puede utilizar para prototipar los Web Panels. 40

42 Preferences Servlet Directory Cada servidor de Servlets necesita que los servlets compilados se pongan en un directorio específico. Ese directorio debe indicarse en esta preference, el mismo es relativo al cliente. Es necesario especificar este valor antes de generar, dado que se utiliza para la generación del makefile. Luego de compilar cada Web Panel, se copiará el archivo compilado al directorio especificado. Además de los.class se copiarán los ficheros.cfg, que contienen la información de configuración, por lo que si se modifica algún valor de las preferences es necesario volver a generar y compilar algún Web Panel. Cuando se modifica el valor de alguna preference y se genera un nuevo.cfg, para que tenga efecto es necesario reiniciar el servidor de Servlets. Images Directory Para poder utilizar archivos de imágenes en los Web Panels, es necesario copiarlos a un directorio que sea visible desde el servidor de web, y se debe especificar la dirección relativa o absoluta de dicho directorio en esta preference. Por ejemplo, se puede crear un directorio \Imágenes bajo el directorio raíz del servidor de web y copiar todas las imágenes necesarias a dicho directorio. Si no se indica nada, se buscará en la raíz del servidor web (directorio "/"). Auto compress web pages Indica si se intentan comprimir las páginas antes de enviarlas al cliente. El valor por defecto es "Yes". Se recomienda cambiar este valor en caso de encontrar alguna dificultad causada por la compresión de páginas. En caso contrario, se recomienda dejar el valor por defecto. Protocol specification Permite indicar el protocolo que va a utilizar el browser para comunicarse con el servidor al ejecutar Web Panels. Los valores posibles son: Unsecure (HTTP) Utiliza el protocolo HTTP para llamar a los Web Panels. Es el valor por defecto. Secure (HTTPS) Utiliza el protocolo HTTPS para llamar a los Web Panels. Do not specify No se indica en forma específica el protocolo a utilizar, el protocolo actual es utilizado. Se recomienda utilizar el valor Do not specify para obtener un código más versátil (puede correr con cualquier protocolo). De todos modos, hay algunos browsers (en general versiones viejas) que no soportan links sin especificar el protocolo. Sólo se puede utilizar HTTPS, si el protocolo es soportado por el servidor de web que se esté utilizando. Subfile Transparency Es una preference a nivel del modelo y una propiedad de los objetos de tipo Web Panel cuyo objetivo es asegurar la compatibilidad de esta versión con versiones anteriores de GeneXus. Los valores posibles se 41

43 detallan a continuación: Opaque Este es el valor por defecto para la preferencia del modelo. Indica que tanto las columnas como sus títulos tendrán los colores de fondo (BackColor) que se especificaron en GeneXus. Si se especifica este valor a nivel de preferencia de modelo, aplica a todos los Web Panels generados cuya propiedad correspondiente tenga el valor "Use model preference's value. Si se especifica este valor a nivel de un Web Panel determinado, aplica a dicho Web Panel independientemente del valor especificado en la preferencia correspondiente. Transparent Indica que tanto las columnas como sus títulos tendrán fondo (BackColor) transparente. Si se especifica este valor a nivel de preferencia de modelo, aplica a todos los Web Panels generados cuya propiedad correspondiente tenga el valor "Use model preference's value. Si se especifica este valor a nivel de un Web Panel determinado, aplica a dicho Web Panel independientemente del valor especificado en la preferencia correspondiente. Use model preference's value Este es el valor por defecto para la propiedad del objeto. Indica que se debe considerar el valor de la preferencia del modelo. Use Tables Para mejorar la alineación de los controles en una página Web se puede utilizar la preference denominada Use Tables, que habilita el uso de tablas HTML. Esta preference se encuentra tanto a nivel de modelo como a nivel de objeto, siendo los valores posibles Yes o No. El valor por defecto de la preference es Yes. Básicamente, las tablas HTML son como las utilizadas en Word, para alinear cualquier página web, se incluyen las imágenes, el texto, etc. dentro de las celdas, obteniendo el diseño deseado. Al habilitar esta preference se incluyen los controles del form diseñado en GeneXus, dentro de las celdas de la tabla, mejorando de esta forma la alineación de los Web Panels. Por más información sobre implementación y compatibilidad se recomienda leer el documento que se encuentra en: Include <PRE></PRE> Tags Mediante esta preference se puede controlar el código HTML enviado al browser, correspondiente al formato del contenido del form de un Web Panel. Estos tags se utilizan para indicar que lo que esté dentro de los mismos no debe ser formateado por el browser. Son generados por GeneXus cuando el valor dela preference Use Tables es No. Esta preference se encuentra también como propiedad a nivel de objeto. Los valores posibles de esta preference son Yes o No. El valor por defecto es Yes. El valor No, permite que el browser realice el formateo del código HTML enviado por GeneXus, es utilizado para desarrollar páginas que agregan código HTML. 42

44 Importante: Esta preference es ignorada si el valor de la preference 'Use Tables' está seteada en Yes. Include standard header Al ejecutar un Web Panel se visualiza un título seguido de una línea, este título también se muestra en la barra superior del browser que se está utilizando. El título mencionado, es por defecto la descripción del objeto. Con la preference Include standard header se indica si se va a generar el título del Web Panel o no. Esta preference se encuentra también como propiedad a nivel de objeto. Los valores posibles son Yes o No. El valor por defecto es Yes. Si se indica que el título no se debe generar (Valor No de la preference), se elimina en forma automática la línea, pero se mantiene la descripción que se muestra en la barra superior del browser. Include standard footer Al ejecutar un Web Panel generado por GeneXus se visualiza a continuación del contenido del form una línea de separación final. Se agregó una preference 'Include footer' que permite controlar la generación de dicha línea. Esta preference se encuentra también como propiedad a nivel de objeto. Los valores posibles son Yes o No. El valor por defecto es Yes. Consideraciones adicionales En la URL, para acceder a los Web Panels Java debe ponerse el nombre del objeto sin extensión. Por ejemplo, si defino un Web Panel llamado 'Test', en la URL debo poner Cuando en GeneXus se utiliza la función link, y dentro del link se hace referencia a una URL que termina con ".exe" y que empieza con "h", se supone que es una llamada a otro Web Panel, y se omite el ".exe". Si se ponen en el mismo servidor de Servlets aplicaciones de diferentes modelos, debe especificarse algún valor en la preference 'Package Name' de cada modelo (o mas específicamente, solo puede haber un modelo que no tenga un valor en dicha preference). Si se especifica algún valor en la preference 'Package Name', el generador creará automáticamente el subdirectorio debajo del directorio del servidor de Servlets que se especificó en la preference "Servlet Directory". Por ejemplo, si se especificó el valor "c:\jrun\servlets" en dicha preference, y en "Package Name" se puso "com.artech.test", se creará el directorio ccom\artech\test bajo c:\jrun\servlets. Si se especifica algún valor en la preference 'Package Name', los web panels pasarán a llamarse <package name> + "." + <nombre del objeto>. Por ejemplo, para ejecutar un web panel llamado 'hclients', si el valor de la preference 'Package Name' es 'com.artech.test', debe ponerse en la URL: Si se desea acortar el nombre, se puede mapear dicho objeto a otro nombre en el archivo servlet.properties del motor de servlets. Si se agrega la siguiente línea : 43

45 servlet.hclients.code=com.artech.test.hclients se podrá ejecutar el webpanel utilizando la URL Configuración con diferentes entornos JavaServer Web Development Kit 1.0 Junto con el JavaServer Web Development Kit 1.0 se distribuye un servidor de Servlets independiente (no se puede instalar como un componente de un servidor web existente). Este servidor debe ejecutarse invocando al script 'startserver' (o startserver.bat en Windows) que se encuentra en el directorio raíz de donde se instaló el producto. Antes de ejecutar el script es necesario editarlo para agregar en el CLASSPATH el archivo gxclassr.zip (de modo de que pueda ejecutar las aplicaciones generadas por GeneXus), además de los drivers JDBC y el resto de las clases adicionales que se necesiten. Para ejecutar los Web Panels, es necesario poner en la preference "Servlet Directory" el subdirectorio "webpages\web-inf\servlets" del directorio en el que se instaló el Java Servlet Development Kit. El directorio raíz para el web server es el subdirectorio web pages del directorio donde se instaló el producto. Si se desean utilizar imágenes (.GIF/.JPG) deben copiarse a ese directorio. Cuando se regenera un Web Panel y se vuelve a compilar, es necesario bajar y volver a subir el servidor de Servlets, dado que no detecta que se modificó el código compilado. Para eso se puede utilizar el script 'stopserver' (o stopserver.bat en Windows). Para ejecutar los web panels, es necesario poner la dirección del objeto GX> JRun Este producto se puede instalar sobre diversos servidores de web, existiendo versiones para todos los servidores de web importantes así como para Windows, Unix/Linux, Macintosh y Netware. Como ventaja importante para los usuarios GeneXus, recarga automáticamente los ficheros.class modificados, por lo que no es necesario reiniciarlo cuando se modifica un Web Panel. Está escrito en Java, por lo que puede utilizarse cualquier máquina virtual para ejecutarlo. En el momento de instalación pregunta con qué máquina virtual se desea ejecutar. Por defecto, es necesario poner el subdirectorio \servlets del directorio donde se instala el producto en la preference "Servlet Directory". El nombre de este directorio se puede cambiar con los utilitarios de configuración del Jrun (ver Figura 4). Para eso ejecutar el programa de administración que podemos visualizar en la Figura 3: Programa de Administración del JRunFigura 3. 44

46 Figura 3: Programa de Administración del JRun Seleccionar la opción 'jse'/'jrun Servlet Engine for...' y presionar el botón 'Service Config' pasando de esta forma a la pantalla que vemos en la Figura 4. 45

47 Figura 4: Configuración JRun - JSE General Settings En el campo 'Default Servlets Dir' se pueden agregar directorios donde encontrar a los servlets. No pueden existir dos servlets con el mismo nombre en diferentes directorios, dado que en ese caso no sabe cual ejecutar. Para ejecutar los web panels, es necesario poner la dirección del objeto GX>. Es necesario modificar la configuración del JRun para agregarle las clases de soporte Genexus. Eso se debe hacer en la sección General\Java, en el campo 'Java Classpath' (ver Figura 5). Hay que agregar el fichero gxclassr.zip, además del resto de las clases que se necesiten (drivers JDBC, etc). No es necesario agregar el jsdk.jar. 46

48 Figura 5: Configuración JRun - Service Manager Settings Por mas información sobre la configuración de este producto consultar la documentación del mismo. Limitaciones actuales El diálogo de ejecución no permite ejecutar Web Panels. Se podrá hacer desde la versión 6.1 Patch 1. 47

49 EJECUCIÓN EN MULTIPLES CAPAS La versión actual del generador permite generar aplicaciones que se ejecuten en diferentes capas, utilizando CORBA, DCOM y RMI como protocolos de comunicación entre ellas. El generador permite la ejecución remota de procedimientos y de las GXDB++. Esto ultimo implica que los accesos a la base de datos se ejecuten en un servidor, y la lógica de la aplicación en el cliente o en otro servidor. Definición de Locations Para definir en donde se ejecuta cada procedimiento remoto se utiliza la propiedad "Location" de los objetos (Object Information/Options). Para definir donde se ejecutan las GXDB++ se utiliza la preference "GXDB++ Location", que está en el grupo "Distributed Execution" de las preferences del modelo. El Location es un nombre arbitrario que permite identificar las ubicaciones lógicas (o sea, no son nombres de servidores físicos) en donde deben ejecutar los diferentes componentes. Luego un servidor de aplicaciones GeneXus que toma el rol de servidor de nombres se encarga de resolver que nombre corresponde a que servidor físico. Si a un objeto no se le define Location, se asume que se ejecuta en el location del llamador. Para decidir si una invocación es remota o local, el generador compara el Location donde se está ejecutando un proceso con el Location en que debe ejecutarse el proceso a invocar. Si es el mismo, la invocación es local, sino remota. Por ejemplo, supongamos que definimos un procedimiento llamado AddClient, y configuramos el Location de modo que ejecute en un location "Server1". Si ese procedimiento es llamado desde el cliente, la llamada debe ser remota, pero si es llamado desde otro procedimiento que se ejecuta en el mismo location "Server1", la llamada debe ser local. Análogamente, si tenemos configurado el modelo para que las GXDB++ se ejecuten en el location "Server1", un procedimiento que se ejecute en el cliente las utilizará de forma remota, pero un procedimiento que se ejecute en el location "Server1" lo hará en forma local. Preferences En la sección "Distributed Execution" de las preferences del modelo, se pueden configurar las siguientes opciones: Distributed Execution Valores posibles: "Never" Using Sun s RMI Using CORBA" Using DCOM" "Installed ORB (CORBA, DCOM, RMI)" 48

50 Esta preference indica si se desean generar aplicaciones en multiples capas, y en caso de que sea asi, que arquitectura de ejecución distribuida utilizar. Si se selecciona la opción "Never", se generarán aplicaciones en 2 capas, sin importar los Locations. Si se selecciona otra opción, se harán llamadas remotas cuando el objeto a llamar esté en un location diferente al del llamador. Se puede especificar que se desea usar siempre el mismo protocolo de ejecución distribuída, o que se puede dejar la decisión para tiempo de ejecución. Con la preference "Installed ORB", en tiempo de ejecución se intentará utilizar en primer lugar CORBA, en segundo lugar DCOM y en tercer lugar RMI. Para tener esta opción disponible es necesario que el servidor de aplicaciones soporte conexiones por múltiples protocolos (ver la sección sobre configuración del servidor de aplicaciones por mas información). GXDB++ Location Indica el nombre del Location en que se ejecutarán las GXDB++. Si está vacío, las GXDB++ serán locales, esto implica que si se ejecuta código que accede a base de datos desde el cliente, se necesitará un driver JDBC en el cliente. Automatic Remote Procedures Host El generador Java brinda la posibilidad de ejecutar automáticamente en el servidor todos los procedimientos que tienen acceso a la base de datos, sin necesidad de indicarlo uno por uno. Si esta preference no tiene ningún valor, los procedimientos se ejecutan remotos o locales de acuerdo al location de cada uno. Si tiene algún valor, los procedimientos que accedan a la base de datos se ejecutaran en el host que se indique. Esta preference no se puede utilizar si existe en la base de conocimiento algún procedimiento que accede a base de datos y que además llama a un workpanel, dado que el workpanel se ejecutaría en el servidor. Name Server Host Indica el nombre del host donde está el servidor de nombres. En la siguiente sección se explicará que función cumple este servidor. Si no se setea esta preference, se asume que el servidor de nombres está en la terminal corriente (localhost). ORB Connection timeout (seconds) Las aplicaciones clientes se conectan a un servidor de aplicaciones, el cual realiza conexiones a la base de datos. Esta opción permite configurar a los cuántos segundos sin actividad el servidor supone que la conexión con el cliente ha caído de forma anormal, y cierra dicha conexión. El servidor registra la actividad cada vez que este hace un requerimiento. En caso de que el cliente esté ejecutándose pero no haga llamadas directas al servidor, el cliente enviará un aviso al servidor indicándole que sigue en actividad. El valor por defecto son 5 minutos. Application Server Log File Indica un archivo en el que se guarda información de control de ejecución del servidor. Si se especifica STDOUT la información de log se despliega en la consola, o en el Event Log de Windows NT si se está ejecutando como servicio. Application Namespace Si se desean ejecutar dos modelos GeneXus diferentes en en un mismo servidor de aplicaciones, se puede especificar un namespace distinto para cada modelo para que el servidor de aplicaciones diferencie los objetos de cada modelo. Esto permite definir preferences distintas para cada modelo (drivers JDBC, etc) y que todos ejecuten en el mismo servidor de aplicaciones. 49

51 Arquitectura de las aplicaciones distribuidas Las aplicaciones generadas pueden ejecutarse en un esquema de múltiples servidores. Entre todos los servidores hay uno que tiene que asumir el rol de 'Servidor de Nombres'. Cada vez que un servidor de aplicaciones se levanta, se conecta con el servidor de nombres y informa que está levantado, y le dice cual es su nombre. El nombre del servidor de aplicaciones es el que se especifica en el Location. Cuando un cliente necesita conectarse con un servidor de aplicaciones que está en un Location dado, le pide al servidor de nombres una referencia a dicho servidor de aplicaciones, y luego se comunica directamente con éste. Esta arquitectura permite que en el diseño de la aplicación la única dirección IP física sea la del servidor de nombres. Solo cambiando este seteo puede modificarse el ambiente en que ejecuta la aplicación. A continuación se esquematiza el funcionamiento de una aplicación distribuída. Cada recuadro puede ejecutarse en un host distinto, o en el mismo. Client 2 3 Servidor de Nombres Application Server Application Server El funcionamiento es el siguiente: a) Se levanta el servidor de nombres en un host. b) Se levantan los servidores de aplicaciones en los hosts donde se vayan a ejecutar aplicaciones remotas. El servidor de nombres puede estar en el mismo host que un servidor de aplicaciones, pero solo debe ejecutarse un servidor de nombres. c) Los servidores de aplicaciones se registran con el servidor de nombres. Esto es lo que se indica con el numero (1) en la ilustración. d) El cliente se ejecuta, y por cada Location que vaya necesitando acceder, le pedirá al servidor de nombres una referencia al servidor de aplicaciones correspondiente. Esto es lo que indica el número (2). El número (3) indica la referencia al servidor de aplicaciones que devuelve el servidor de nombres. e) El cliente le solicita al servidor de aplicaciones referencias a los objetos que debe ejecutar remotamente, y los ejecuta. Esto es lo que indica el numero (4). Utilización de CORBA CORBA (Common Object Request Broker Architecture), es una arquitectura que permite la ejecución 50

52 distribuida de aplicaciones. Es un standard definido por una institución llamada Object Management Group (OMG, que está compuesta por varios fabricantes de software. Es una arquitectura multiplataforma, y que permite la integración de módulos escritos en diferentes lenguajes. Existen muchos productos en el mercado que permiten la utilización de CORBA con Java. Actualmente se ha probado el código generado utilizando dos productos: VisiBroker for Java 3.4, de Inprise Corp. ( ) JDK 1.2, de Sun Microsystems VisiBroker es un producto comercial, pero se puede obtener una licencia de prueba por 60 días. El JDK 1.2 es de distribución gratuita. VisiBroker es un producto más flexible y sólido. Dependiendo de las necesidades de cada cliente será conveniente la utilización de un producto u otro. En próximas versiones, el generador será probado con otros productos CORBA, de modo de que los usuarios tengan más opciones. Para levantar los procesos necesarios en el server, se provee un bat que lo hace para las dos implementaciones de CORBA soportadas. El bat se llama ORBSRV.BAT, se debe ejecutar en el directorio del modelo y se le debe pasar como primer parámetro "vb" si se quiere usar VisiBroker o "jdk12" si se quiere utilizar el JDK 1.2 y como segundo parámetro el nombre del Location en que se está ejecutando. El orbsrv.bat contiene al principio algunos SETs que se deben modificar para reflejar el lugar donde están instalados los productos CORBA: set JDK_HOME= <path de donde esta instalado el jdk a utilizar>, por ej: c:\jdk116 o c:\jdk12 set VB_HOME=<path de donde está instalado VisiBroker>, por ej: c:\visigenic\vbroker. set ADD_CP=<CLASSPATH de clases adicionales>, por ej: classes111.zip, si se quieren usar los drivers JDBC de Oracle. En el caso de VisiBroker, el bat levanta 3 procesos. En primer lugar un ejecutable llamado OSAGENT, que debe ejecutarse en alguno de los servidores de aplicaciones o de nombres. En segundo lugar, el servidor de nombres, y en tercer lugar el servidor de aplicaciones. Para el JDK 1.2, no es necesario el primer ejecutable, por lo que solo se levanta el servidor de nombres y el servidor de aplicaciones. Una vez que se ejecuta el servidor de aplicaciones, pueden ejecutarse las aplicaciones cliente. Si se vuelve a generar una aplicación cliente, es necesario bajar y volver a subir el servidor de aplicaciones, porque de otro modo seguiría utilizando la versión anterior del fuente, dado que Java carga las clases compiladas una sola vez, y si ya la tiene cargada no controla si hay una versión mas nueva para cargar. Actualmente, solo se puede bajar el servidor de aplicaciones cerrando la ventana DOS en la que ejecuta, o presionando Control+C en dicha ventana. En siguientes versiones se podrá hacer de forma mas amigable. Classpath En caso de utilizar VisiBroker hay que agregar al Classpath de las preferences de ejecución los archivos vbjapp.jar, vbjcosnm.jar y vbjorb.jar, que se encuentran en el subdirectorio LIB del directorio en donde se instaló el producto. 51

53 Utilización de RMI Para utilizar RMI no es necesario instalar ningún producto adicional, dado que está incluído en las clases Java standard. Si se quiere ejecutar con el SDK de Microsoft, es necesario utilizar el RMI de Sun, dado que Microsoft no distribuye RMI con su SDK. Para levantar el servidor RMI ver la sección Instalación/Ejecución del Servidor de Aplicaciones. Un detalle muy importante, es que para que el RMI funcione correctamente el cliente debe ser capaz de resolver el nombre del servidor a partir de su IP y viceversa. O sea, si se pone en la preference Name Server = , en el cliente debe poder resolverse que esa dirección corresponde al servidor, por ejemplo, myserver.com. Esta resolución de nombres la debería resolver el DNS, pero si no fuera así hay que agregarlo en el archivo HOSTS del directorio \WINDOWS en Windows 95/98 o en del directorio \WINNT\SYSTEM32\DRIVERS\ETC en Windows NT. Soporte para RMI con SDK de Microsoft Con el SDK de Microsoft no se distribuyen las clases necesarias para ejecutar aplicaciones con RMI. Para obtener las clases que soportan RMI con la maquina virtual de Microsoft, existen dos alternativas: Microsoft provee un.zip con las clases necesarias, se puede obtener en : ftp://ftp.microsoft.com/developr/msdn/unsup-ed/rmi.zip Es necesario agregar el archivo rmi.zip al CLASSPATH en el dialogo de ejecución de GeneXus. IBM provee un patch que permite utilizar RMI desde el Internet Explorer, y que para el que no es necesario modificar el CLASSPATH: Ninguna de estas dos alternativas permite instalar RMI en Internet Explorer de forma automática, o sea, requieren una instalación manual. Si se desea que las aplicaciones en Internet usen RMI y lo hagan con el Internet Explorer hay que crear un archivo.cab con una firma digital, con todos los permisos de ejecución dentro del Internet Explorer. Este archivo puede ser instalado automáticamente en el Internet Explorer. Para crear un archivo.cab con el soporte para RMI, se deben seguir los siguientes pasos: - Descomprimir el archivo rmi.zip obtenido del Ftp de Microsoft en un directorio cualquiera. - Ejecutar los comandos: por ejemplo: dubuild <nombre del.cab> <directorio donde se descomprimió> /d <Descripción> /i *.class /v <Versión> /s *.* signcode -j javasign.dll -jp low -spc <SPC file> -v <Key File> -n <Descripcion> <nombre del.cab> dubuild sunrmi.cab c:\rmi /d "Sun RMI" /i *.class /v 1,0,0,1 /s *.* signcode -j javasign.dll -jp low -spc "c:\credentials.spc" -v "c:\mykey.pvk" -n "Sun RMI" sunrmi.cab Los utilitarios dubuild y signcode están en el directorio bin\packsign del SDK 3.1, o en el directorio bin del SDK 3.2 de Microsoft. 52

54 El.CAB creado puede utilizarse en el Deployment Wizard para que se instale automáticamente en el equipo del cliente (por mas información, ver la sección sobre el Deployment Wizard). Utilización de DCOM DCOM solo se puede utilizar con la máquina virtual de Microsoft. En el subdirectorio GXJAVA del directorio donde está instalado GeneXus se distribuye una DLL llamada "GXDCOMJ.DLL". Esa DLL se registra automáticamente cuando se instalan las clases de GeneXus al ejecutar la aplicación como Applet en el Internet Explorer. Si se quiere ejecutar como Application, debe registrarse manualmente con el comando REGSVR32 gxdcomj.dll tanto en el cliente como en el servidor. Adicionalmente, es necesario ejecutar el utilitario en el servidor NT "DCOMCNFG" y en la sección "Default Properties" poner "Default Authentication Level = None", tal como se muestra en la Figura 6 Figura 6: Configuración de DCOM En próximas versiones del generador se soportará tener un control mas detallado de los mecanismos de seguridad de DCOM. Adicionalmente, cuando se instalan automáticamente las clases de GeneXus al ejecutar como applet, se modifica un seteo del registro del cliente que cambia el 'Default Autentication Level' a 'None'. Si es la primera vez que se instalan las clases de GeneXus, para que el cambio tenga efecto es necesario que el cliente reinicie su equipo, de otro modo no podrá conectarse al servidor de aplicaciones, salvo que esté conectado al mismo dominio, o que exista en el dominio del servidor una combinación usuario/password 53

55 idéntica a la del cliente. Esto es, si el cliente está conectado a un dominio NT1, y su usuario password son Genexus/Genexus, debe existir en el dominio del servidor un usuario Genexus con password Genexus. Configuración recomendada El esquema de ejecución distribuida de posee gran flexibilidad, y es conveniente utilizarla de forma de sacarle el mayor beneficio. Ejecución en Internet En un ambiente de ejecución en Internet, es recomendable ejecutar las GXDB++ en el servidor, así como todos los procedimientos que accedan a base de datos. Ejecutar las GXDB++ remotas tiene las siguientes ventajas: No hay conexión entre el cliente y el DBMS, por lo que no es necesario que se pueda acceder al DBMS desde Internet, con las ventajas desde el punto de vista de la seguridad que esto tiene. Todas las operaciones con el DBMS se hacen desde la misma conexión, por lo que se respetan las UTLs tal como fueron diseñadas en. Si no se ejecutaran las GXDB++ remotas, los procesos locales, que se ejecutan en el cliente, tendrían una conexión al DBMS, y los remotos otra, por lo que el commit/rollback funcionaria para cada conexión en particular. Por ejemplo, si se hace un commit en el proceso remoto, solo se está haciendo commit de lo que se actualizó en el server, pero no de lo que se actualizó en el cliente. Con las GXDB remotas, el commit toma en cuenta las modificaciones de ambos. Se permiten compartir conexiones mediante el mecanismo de connection pooling. En las próximas versiones del generador, las condiciones no optimizables de los for eachs serán resueltas por las GXDB++, por lo que solo viajarán por la red los registros necesarios. Ejecutar los procedimientos que acceden a la base de datos en el servidor, tiene la ventaja de que los datos no viajan por la red sino que se procesan en el servidor. En este esquema, con GXDB++ y procedimientos remotos, las GXDB++ remotas se utilizarían para la navegación en los eventos de los work panels y para los accesos que sean necesarios en las transacciones. Ejecución en red local En un ambiente de red local, tendrá mejor performance global el utilizar las GXDB++ locales, ejecutando en el servidor los procesos mas pesados, tal como se hace hoy con los generadores Visual Basic/Visual FoxPro y el generador C. La excepción a este caso sería si se necesita utilizar el connection pooling. En ese caso se deben ejecutar las GXDB++ en el server. El connection pooling es muy útil en redes locales con una cantidad de usuarios tal que el servidor de base de datos no pueda mantener una conexión con cada uno sin degradar su performance, o cuando se quiere adquirir menos licencias de uso de la base de datos que la cantidad de clientes de la aplicación. 54

56 INSTALACIÓN/EJECUCIÓN DEL SERVIDOR DE APLICACIONES Instalación del Servidor de Aplicaciones Cuando las aplicaciones se generan en múltiples capas, es necesario instalar en el Servidor de Aplicaciones, es el software que permite atender los requerimientos de los clientes. Estos requerimientos son las solicitudes de ejecución de aplicaciones remotas. A este software se le llama GeneXus Application Server. La instalación del mismo consiste en la copia de determinados archivos a un directorio del servidor en el cual va a correr el servidor de aplicaciones (por ejemplo: gxappsrv pero el nombre de este directorio puede ser cualquiera y en cualquiera de sus discos). Los archivos necesarios vienen con el generador y son los siguientes: Gxjvsrv.exe Gxclassr.zip Server.cfg de algún modelo Configuración del Servidor de Aplicaciones El servidor de aplicaciones lee su configuración desde un archivo de inicialización. El generador crea un archivo "server.cfg" que se puede utilizar para el servidor de aplicaciones, respetando las preferencias del modelo. Adicionalmente, existe un utilitario para configurar el servidor de aplicaciones, que lo que hace es grabar un archivo.cfg análogo al que crea el generador. El utilitario puede ser ejecutado desde la línea de comandos con el comando : <intérprete Java> com.genexus.serverconfig [<nombre del archivo.cfg>] Si no se especifica un archivo se intenta abrir el server.cfg del directorio corriente. Si no existe, se cargan valores por defecto. 55

57 Figura 7: Configuración Servidor Aplicaciones GeneXus - General 1 En la sección "General 1" (ver Figura 7) se despliegan los siguientes valores: Location Act as the Name Server Name Server Connection Timeout Enable Logging Log to console Log File Enable Remote Monitoring Location a la que representa el servidor de aplicaciones que se ejecutará en el servidor corriente. Por defecto se pone el valor de la preference " GXDB++ Location" del modelo. Indica si el servidor va a ser el servidor de nombres. Solo un servidor de todos los que se utilicen debe tener esta opción seleccionada. Por defecto, se asume que va a ser el servidor de nombres. Si no se marca la opción anterior, se solicita la dirección IP del servidor de nombres. Indica el tiempo en segundos en que un cliente puede estar inactivo antes de que el servidor asuma que debe ser desconectado automáticamente. El cliente, aunque no esté haciendo nada, avisa al servidor cada X tiempo que está activo, siendo este valor X una función del valor de esta preference. Indica que el servidor de aplicaciones generará un log de las operaciones que realice. Para que se genere Log se deben incluir en el classpath las clases de debug (gxclassd.zip) en vez de las de release (gxclassr.zip) Indica que el log se hará a consola. Si se ejecuta como servicio, el log irá en el "Event Viewer" de Windows NT. Si no se selecciona "Log to console", se puede indicar el nombre del archivo en que se generará el log. Indica si se permite que el servidor de aplicaciones sea monitoreado y administrado remotamente. En este caso, el servidor podría ser bajado desde cualquier equipo conectado a la red, lo que implica un riesgo de 56

58 Port seguridad importante. No se recomienda esta opción si el servidor está conectado a Internet y no está protegido por un firewall que bloquee el acceso al port seleccionado. Indica el port por el que se conecta el monitor del servidor de aplicaciones. Los botones de la parte inferior tienen la siguiente función: Save and Update Registry Settings Save Exit Graba el archivo.cfg, y en caso de que se utilice DCOM o que se haya indicado que se quiere instalar como servicio de NT, se actualizan las entradas necesarias en el registro de Windows. Esta opción está habilitada solo si se ejecuta con la máquina virtual de Microsoft. Graba el archivo.cfg. Termina la ejecución del programa de configuración. 57

59 Figura 8: Configuración Servidor Aplicaciones GeneXus - General 2 En la sección "General 2" (ver Figura 8) se despliegan los siguientes valores: SMTP Host Enabled server Protocols Protocol when client Indica el servidor de mail que utilizarán los procedimientos que usen las funciones de mail en el servidor. Indica que protocolos se desea que el servidor de aplicaciones sea capaz de utilizar. Se puede cualquier combinación de ellos. Especifica el protocolo con que debe llamar a otros servidores de aplicaciones. Lo utiliza si tiene que usar las GXDB++ remotas o si debe llamar a un procedimiento que reside en otro servidor de aplicaciones. 58

60 Figura 9: Configuración Servidor Aplicaciones GeneXus NT Service En la sección "NT Service" (ver Figura 9) se despliegan los siguientes valores: Install as an NT Service Startup Log On As Service EXE Path Indica si se desea que se instale el servidor de aplicaciones como un servicio NT. En caso que se desmarque esta opción y el servidor de aplicaciones ya estuviera instalado como servicio, se desinstalará. Indica si se desea que el servicio comience automáticamente cuando se reinicie NT, si hay que levantarlo manualmente o si está deshabilitado. Es equivalente a los valores que se pueden configurar en las propiedades de los servicios en el Panel de Control de Windows NT. Indica con que usuario se debe conectar a NT el servicio. Si se especifica System Account, las clases de las aplicaciones no pueden estar en directorios de red, dado que el usuario "System Account" no tiene permisos para acceder a recursos que no sean locales al sistema. Si es necesario acceder a directorios de red, se debe especificar un nombre de usuario/password con el que conectarse. Esto también se puede configurar en las propiedades de los servicios en el Panel de Control de Windows NT. Es importante poner el usuario con el formato Domain\User, de otro modo no se podrá crear el servicio. Indica el camino y nombre del ejecutable con el servicio a levantar. El nombre del ejecutable es "gxjvsrv.exe" y se distribuye en el directorio gxjava de donde se instala GeneXus. Se recomienda copiarlo a algún directorio del servidor de aplicaciones y apuntar esta preference a ese lugar. 59

61 Al presionar el botón "Save and Update Registry Settings" se actualizan los valores en NT, de modo de reflejar las preferencias indicadas, y adicionalmente se le dice al servicio que el archivo de configuración a utilizar es el archivo de configuración que se está editando en el momento. Este valor se puede cambiar en la clave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\gxjvsrv\ConfigurationFile del registro de Windows. Es necesario tener permisos de administrador para que la acción tenga éxito. Si el servicio ya está levantado, no se puede modificar el estado del mismo. O sea, si se quiere deshabilitar el servicio es necesario primero ir al Panel de Control de Windows NT, ir a la opción de "Servicios", buscar "Genexus Application Server" y presionar el botón "Parar". Para que el servicio funcione correctamente se deben, además, tener en cuenta las siguientes consideraciones: Se debe setear la variable CLASSPATH del entorno del NT, como System Variable, de modo que incluya las siguientes clases:!" Clases standard de Genexus (archivo gxclassr.zip que se encuentra en el directorio gxjava de Genexus o en el directorio del modelo)!" Si se configura el servicio con el protocolo RMI, se requiere el soporte para RMI, dado que se va a ejecutar usando la máquina virtual de Microsoft que no soporta RMI nativamente. Por información sobre como obtener este archivo (rmi.zip) consultar la sección sobre RMI.!" Si se configura el servicio con el protocolo CORBA, se requiere Soporte para CORBA. Análogamente al anterior, si se quiere usar CORBA es necesario incluir las clases de CORBA en el classpath. Si no se ha especificado ningún valor en la propiedad "Application Archive" en la configuración del Namespace, es necesario agregar el directorio o.jar con las clases del modelo. Una vez cambiada el valor de la variable CLASSPATH se debe reiniciar el sistema, dado que los servicios no ven ese cambio hasta que se reinicia. En caso contrario no se podrá levantar el servicio. Se debe tener la máquina virtual de Microsoft versión o posterior en el servidor. 60

62 Figura 10: Configuración Servidor Aplicaciones GeneXus - Namespaces En un servidor de aplicaciones pueden ejecutar simultáneamente varias aplicaciones GeneXus, cada una con su configuración de drivers JDBC, etc. Para diferenciar las aplicaciones, se utiliza el concepto de "Namespace". Un namespace es la definición de un conjunto de propiedades para una aplicación GeneXus que se ejecuta en el servidor. En esta pantalla (ver Figura 10) se pueden agregar, editar, renombrar y eliminar namespaces. 61

63 Figura 11: Namespace Configuration - General Information Cuando se agregan o editan namespaces se despliega una nueva pantalla (ver Figura 11) en la cual se presentan en la sección General Information los siguientes valores a especificar: GXDB++ Server/Client Application Archive / Directory Automatic Class Reloading Indica si este servidor va a ser un cliente o un servidor de GXDB++. Si va a ser un cliente, se debe especificar el location donde ejecutan las GXDB++ (esto implica que hay mas de un servidor de aplicaciones), y en la sección "Database Information" no se puede especificar ningún dato, dado que no se accede a la base de datos desde este servidor. Si se especifica "GXDB++ Server", no se solicita el ingreso de GXDB++ Location, y sí se solicitan datos en la sección "Database Information" Indica el.zip/.jar donde se encuentran las clases correspondientes al namespace, o sea, a la aplicación GeneXus. Esto se debe configurar si las clases de la aplicación no están en el CLASSPATH, sino puede queda vacío. Esta opción tiene sentido en caso de que se haya especificado algun valor en la propiedad anterior. Si se selecciona, el.jar puede ser modificado mientras está ejecutando el servidor de aplicaciones, y las modificaciones en dicho.jar serán visibles sin necesidad de reiniciarlo. Si no se selecciona, solo será posible actualizar el.jar si se baja el servidor de aplicaciones, o si se utiliza la opción 'Reset Namespace' del Application Server Monitor. La desventaja de seleccionar esta opción es que la carga de las clases demora mas, dado que no se mantiene el archivo de clases abierto, y se controla cada vez si la fecha de última modificación del archivo cambió (si 62

64 fue así, se liberan de memoria las clases cargadas, y se vuelven a cargar a medida que son necesarias). Las consecuencias de modificar el.jar mientras hay algún cliente conectado son imprevisibles, por lo que se recomienda que la esta opción se utilice solo en tiempo de desarrollo, con el fin de no tener que reiniciar el servidor de aplicaciones cada vez que se hace una modificación. 63

65 Figura 12: Namespace Configuration - Database Information En la sección "Database Information", se despliega una pantalla (ver Figura 12), en la cual los datos que se solicitan son equivalentes a las preferences de igual nombre. Hay algunas consideraciones: La preference "DBMS" se solicita porque es necesario que el servidor de aplicaciones conozca el DBMS con que se está ejecutando la aplicación. Esto no implica que si se cambia el valor de esta preference las aplicaciones generadas funcionen con otro DBMS. Este valor debe ser el mismo con el que se generó el modelo. En el caso de que se seleccione "Informix" se mostará un combo box a la izquierda que permitirá seleccionar el tipo de base de datos (ANSI, Logged o Not Logged). En el caso de que se seleccione "DB2/400" se pedirá que se ingrese la Default Library List. La password del usuario aún no se graba encriptada en el archivo de configuración. Si se indica que se desea llevar un log de la actividad JDBC, se debe ejecutar la aplicación con las clases de debug (gxclassd.zip) en vez de gxclassr.zip. La preference "Maximum open cursors per Connection" se utiliza también en el mecanismo de Connection Pooling para saber cuantas sentencias se pueden tener abiertas en una conexión del pool read-only. En algunos DBMS (por ejemplo Oracle) también se debe configurar este valor en el servidor El botón "Check Connection" intenta conectarse al DBMS con las preferences establecidas, e indica el resultado de esta operación. Si se presiona el botón "Import From" se permite importar la definición de un NameSpace de otro archivo.cfg. Dado que GeneXus siempre crea un.cfg que refleja las preferences del modelo, se puede importar directamente de dicho archivo. Si el archivo tiene un único NameSpace, se importan sus datos. Si tiene mas de uno, se presenta una lista de selección con los nombres de los NameSpaces y con doble click se 64

66 selecciona una (ver Figura 13). Figura 13: Namespace Configuration - Select Namespace Figura 14: Namespace Configuration - Pool Information En la sección Pool Information (ver Figura 14) se especifican los siguientes valores: Create all pool connections at startup Enable read/only pool Unlimited Indica si se desea que las conexiones del pool se creen todas al inicio del servidor de aplicaciones, o si, en caso contrario, se van creando a medida que se van necesitando. Indica si se desea habilitar el pool de conexiones read-only Indica si el tamaño del pool de conexiones es ilimitado. Si se selecciona esta opción, cuando se necesita una nueva conexión y todas las existentes están ocupadas, se crea una nueva. Si no se selecciona, la aplicación del cliente espera hasta obtener una conexión libre. Esta opción se puede especificar para cualquiera de 65

67 Pool Size los dos pools de conexiones indistintamente. En caso de que no se seleccione la opción "Unlimited", se debe indicar el tamaño máximo del pool de conexiones. Ejecución del Servidor de Aplicaciones desde la línea de comandos El servidor de aplicaciones puede no configurarse como un servicio NT sino ejecutarlo directamente desde la línea de comandos, lo que es necesario en ambientes no NT. Se debe ejecutar el comando: <intérprete java> com.genexus.applicationserver [<archivo de configuración]> por ejemplo: java com.genexus.applicationserver myconfig.cfg Si no se especifica ningún archivo de configuración, se asume "server.cfg". Para que el servidor funcione correctamente se deben debe setear la variable CLASSPATH de modo que incluya las siguientes clases: Clases standard de GeneXus (archivo gxclassr.zip que se encuentra en el directorio gxjava de GeneXus o en el directorio del modelo) Si se va a utilizar RMI con la máquina virtual de Microsoft, es necesario agregar el archivo rmi.zip. Por información sobre como obtener este archivo (rmi.zip) consultar la sección sobre RMI. Si se configura el servicio con el protocolo CORBA, se requiere Soporte para CORBA. Análogamente al anterior, si se quiere usar CORBA es necesario incluir las clases de CORBA en el classpath. Si no se ha especificado ningún valor en la propiedad "Application Archive" en la configuración del Namespace, es necesario agregar el directorio o.jar con las clases del modelo. 66

68 CONNECTION POOLING En las aplicaciones cliente/servidor tradicionales, se mantiene una conexión a la base de datos por cada cliente final, esto es, si tengo 100 clientes finales tendré 100 conexiones a la base de datos. Esto es aceptable para aplicaciones con un número de clientes relativamente pequeño, pero es inconveniente cuando la cantidad de clientes es grande, o impredecible (como en aplicaciones en Internet), por varias razones: La carga al servidor de base de datos es mayor cuanto más conexiones abiertas haya. En la mayoría de los DBMSs se debe comprar una licencia de uso por cada usuario conectado. No es óptimo, dado que la mayoría de las conexiones están sin hacer nada una parte importante del tiempo. La solución a estos problemas es permitir el compartir conexiones a la base de datos entre los diferentes clientes de la aplicación, de modo de que existan menos conexiones físicas a la base de datos que clientes. Esto es lo que se intenta resolver con el pool de conexiones. Desde la versión Beta 3 del generador Java, se soporta la utilización de un pool de conexiones en el servidor de aplicaciones, esto es, cuando la aplicación se ejecuta en múltiples capas. De todos modos, existe la posibilidad de seguir utilizando el esquema anterior, de una conexión por cliente. La idea general de un pool de conexiones, es que cada vez que un cliente necesita una conexión (esto es, cada vez que prepara un cursor, lo ejecuta, ejecuta una sentencia directamente, etc.), se la pide al connection pool. Esta conexión pertenece al cliente hasta que de algún modo se determina que no la necesita más, y en ese momento se le puede asignar la conexión a otro cliente. Si un cliente necesita una conexión y no existe ninguna disponible, se queda esperando hasta que alguna conexión se libere. La idea es que el tamaño máximo del pool es fijo, y que si una aplicación resulta tener muchos clientes y las conexiones siempre están todas ocupadas, simplemente los clientes notarán que la aplicación funcionará lentamente (dado que habitualmente tendrán que esperar por las conexiones), pero funcionará. En ese caso si se desea tener mejor performance general no hay mas remedio que aumentar el tamaño del pool. Un detalle importante, es que, obviamente, no se pueden compartir conexiones de usuarios distintos, por lo que los pools de conexiones son por usuario. Si todos los clientes se conectan con el mismo usuario, se podrán compartir óptimamente las conexiones. Sino, solo se podrán compartir entre los que tengan el mismo usuario. Otra ventaja es que las conexiones se mantienen abiertas, por lo que los clientes se ahorran el tiempo de conexión al DBMS al iniciar la aplicación. Esto no es muy importante en aplicaciones normales, pero lo es más en web panels. Las condiciones en las que se le puede quitar una conexión a un cliente son las siguientes: No tiene ningún cursor abierto No existe ninguna transacción incompleta (por incompleta se entiende con cambios pendientes sin confirmar) En los work panels de una aplicación GeneXus es muy normal tener carga a pedido. Mientras no se ha terminado de cargar el work panel, se mantiene un cursor abierto en el servidor de base de datos, para poder continuar la carga cuando sea necesario. Esto implicaría que no se le puede quitar una conexión a ningún cliente que esté ejecutando un work panel con carga a pedido. Como ésta es una tarea muy frecuente, las 67

69 conexiones estarían casi siempre ocupadas y el connection pool no tendría demasiado sentido. Para resolver este problema, se implementó un mecanismo por el cual las sentencias que necesiten actualizar la base de datos se manejarán en un pool de conexiones, y las que necesiten solamente leer, en otro. Esto es, existirán en el servidor dos pools de conexiones, uno para conexiones read-only y otro para conexiones read-write. El pool de conexiones read-only tiene la ventaja de que una misma conexión puede ser simultáneamente utilizada por mas de un cliente, dado que al no actualizar no hay problemas de que se mezclen las UTLs. De esta manera, si tuviera 10 clientes conectados con un work panel con carga a pedido, todos se podrían resolver con una única conexión a la base de datos. Ahora, consideremos el siguiente caso: New CliId = 1 CliName = Client #1 EndNew For Each Where CliId = 1 Msg( Client 1 ) EndFor Si el New se hace en una conexión, no se hace commit, y luego se lee en otra conexión, no se encontrarán los datos. Esto es, si se lee una conexión distinta a la que se escribe, el usuario no verá sus cambios hasta que se ejecute un commit. Leer los cambios para los que no se ha hecho un commit es algo habitual, pero hay muchos casos en los que no es necesario. Es muy raro, por ejemplo, que se quiera hacer un reporte de datos para los que no se hizo commit, y lo mismo suele pasar con los datos de un work panel. En las transacciones y en los procedimientos, por el contrario, es habitual necesitar acceder a datos para los que no se hizo commit. Para solucionar este problema se han agregado un conjunto de preferences a nivel del modelo y properties a nivel de objeto que permiten indicar que tipo de comportamiento se desea. Las preferences son las siguientes. Read uncommited user changes Transactions Workpanels Procedures Reports *Yes/No *No/Yes *Yes/No *No/Yes Cada uno de estos objetos tiene la siguiente property: Read uncommited user changes *Use model preferences' value/yes/no Los valores por defecto son los que están señalados con un *, y reflejan que para los procedimientos y transacciones se utilizará una conexión de read-write y para los workpanels y reports una conexión de readonly. Es posible cambiar el valor por defecto para todo el modelo o cambiarlo para un objeto en particular. En los casos en los que haya que realizar una operación de escritura a la base de datos y se haya puesto la preference en No, se utilizará una conexión de read-write para las operaciones que lo necesiten, y una read-only para los que no. Por ejemplo, supongamos que para el siguiente procedimiento se ha puesto la preference en No : 68

70 parm(cliid) &Total = 0 For Each &Total = &Total + InvTot EndFor For Each CliTot = &Total EndFor Este procedimiento calcula el total de facturas para un cliente y lo graba en el atributo CliTot del cliente. El primer For Each se realizará en una conexión read-only. El segundo For Each, dado que tiene que lockear el registro del cliente, se realizará en una conexión read-write, así como el update del cliente. Existe un conjunto adicional de preferences del modelo que permiten configurar el comportamiento del pool de conexiones: Maximum pool size Read-Only pool (default = 1) Read-Write pool (default = no limit) Si se especifica 0 en alguno de estos valores, no se utilizará dicho tipo de pool. Por ejemplo, si se pone 0 en Read-only pool todas las conexiones serán de read-write. Si se ponen ambos en 0 no habrá connection pooling. Create all pool connections at startup Esta opción permite indicar si se quiere que al comienzo de la ejecución del servidor de aplicaciones se creen todas las conexiones, o por el contrario se desea que se vayan creando a medida que se necesita. La ventaja de crearlas al comienzo es que se evita el tiempo de espera del cliente por una conexión. Actualmente esta opción no está funcionando, por lo que las conexiones se abren a medida que se necesitan. Maximum open cursors per connection Esta opción, (explicada en la sección Preferences), es utilizada además para determinar cuantos cursores abiertos puede tener una conexión de read-only. Esto es, las conexiones de read-only pueden ser utilizadas por múltiples conexiones simultáneamente, pero existe un límite en la cantidad de cursores que una conexión puede tener abierta, que se indica con esta preference. Por ejemplo, en Oracle el valor por defecto es

71 LDAP La utilización de un pool de conexiones es muy ventajosa, pero tiene un inconveniente, que es que obliga a que los usuarios se conecten a la base de datos con el mismo usuario para aprovecharlo al máximo. Si cada cliente se conecta con un usuario distinto de la base de datos, el pool de conexiones no cumple ninguna función, dado que no se pueden compartir conexiones de diferentes usuarios. Este hecho ocasiona tres inconvenientes: No se puede utilizar la base de datos como método de autentificación de los usuarios finales. Si necesito algun nivel de seguridad, tengo que implementarlo a nivel de la aplicación. La función userid('server') devuelve siempre el mismo usuario. Hay aplicaciones que utilizan el userid('server') para tomar decisiones, o realizar tareas de auditoría, y en este caso no les serviriía de mucho. No se pueden configurar los permisos de seguridad a nivel de la base de datos para cada cliente final. Los dos primeros problemas se pueden resolver si se utiliza algun mecanismo para autentificar los clientes, dado que el usuario con el que se autentificó podria usarse como valor de retorno de la función userid('server'). Para esto se utiliza LDAP. LDAP (Lightweight Directory Access Protocol) es un protocolo que permite conectarse con servidores de directorio que soporten LDAP, y realizar un conjunto de operaciones predefinidas. Una de estas operaciones es la de autentificación. Existen numerosos productos que soportan que sus catálogos de usuarios sean accedidos con LDAP, algunos ejemplos son Exchange, NT 2000, DB/2. Además existen 'Servidores de Directorios' que son productos que están diseñados para específicamente manejar catálogos de usuarios, como el Netscape Directory Server. En GeneXus existen varias preferences que nos permiten controlar la utilización de LDAP, que se describen a continuación. Para poder utilizar LDAP es necesario tener en el cliente las clases de soporte de JNDI (Java Naming and Directory Interface) y el LDAP Provider para JNDI. Se debe tener el jndi.jar que se distribuye con el JDNI, y los archivos ldap.jar, providerutil.jar y ldapbp.jar de la distribucion del LDAP Provider para JDNI. Ver en Anexo I donde obtener estos productos. Se puede utilizar las versiones superiores a 1.2. Preferences Autenticate users using LDAP - No/Yes Esta preference indica si se desea que a los usuarios se los autentifique utilizando LDAP. Los valores posibles son Yes/No y el valor por defecto es No. En caso de que se ponga 'Yes', la aplicación pedirá usuario/password que luego validará con el servidor LDAP. LDAP URL Aqui se debe indicar la URL donde encontrar el servidor LDAP. La forma de la URL depende del proveedor de servidores de directorios. Por ejemplo, para el servidor de Netscape, es de la forma: ldap://<server>:<port>/o=<domain> 70

72 por ejemplo: ldap://myserver.comt:389/o=artech.com.uy LDAP Autentication Method Los clientes LDAP pueden autentificarse con el servidor de diferentes formas. Estas formas determinan el modo en que se envia el usuario/password. El valor por defecto es "simple", que implica que el usuario/password se envian sin encriptación. Cada servidor de directorios soporta un conjunto de métodos. Consultar la documentación del proveedor. LDAP Principal Template Los usuarios LDAP tienen un nombre compuesto por una cantidad de atributos. En GeneXus se puede especificar la lista de atributos necesarios, indicando en donde se debe poner el nombre de usuario. Por ejemplo: uid=<user>, ou=administrators, ou=topologymanagement, o=netscaperoot indica que el identificador de usuario es todo lo anterior, y que el usuario solicitado por la pantalla de conexión de GX debe ponerse luego de uid=- Para cada servidor de directorios este valor puede ser diferente. Use LDAP user for userid('server') Indica si se desa utilizar el usuario LDAP con que se conectó el cliente como resultado de la función userid('server'). Los valores posibles son Yes o No. El valor por defecto es No. Lista de valores de las preferences para diferentes servidores LDAP Servidor LDAP Microsoft Exchange Netscape Directory Server 4.1 URL Ejemplo Authentication Principal Template ldap://myserver:389/o=artech Simple cn=<user> ldap://myserver:389/o=artech.com.uy Simple uid=<user>, ou=administrators, ou=topologymanagement, o=netscaperoot 71

73 INSTALACIÓN AUTOMÁTICA DE APLICACIONES EN EL CLIENTE Cuando se ejecutan las aplicaciones Java como applets, surge el problema de que el costo de bajar el código a ejecutar por el cliente es muy alto. En una intranet ésto no es un problema, pero sí lo es en Internet. Para intentar aliviar el problema, tanto Internet Explorer como Netscape proveen ciertas facilidades para que se pueda bajar el código de la aplicación al cliente y que luego se ejecute desde allí. Adicionalmente permiten tener un control de versiones mediante el cual si la versión que se desea ejecutar es posterior a la que está instalada en el cliente, se descarga e instala la versión más nueva. Para poder instalar el código en la máquina del cliente es necesario firmar digitalmente las clases, para lo que se debe obtener un object-signing certificate. Estos certificados son concedidos por Certificate Authorities, entre los que se encuentran: Verisign : Thawte : Los certificados son distintos para Netscape e Internet Explorer, por lo que hay que comprar uno para cada uno. También se pueden crear certificados para prueba, pero que no se pueden utilizar en Internet (en la sección "Cómo obtener certificados de prueba" se explica como crear estos certificados). Una aplicación GeneXus/Java tiene dos partes. Por un lado están las clases estándar de GeneXus, y por otro lado las de la aplicación generada. Con la versión actual del generador se proveen clases firmadas para Microsoft y para Netscape en los archivos gxclassm.cab y gxclassn.jar respectivamente. El.HTM que se genera (o el.html que genera el deployment wizard) para los programas main de GeneXus, se arma de modo que funcione en ambos casos Para la instalación de las aplicaciones generadas, se desarrolló el utilitario Deployment Wizard que permite empaquetar y firmar las clases así como crear los.html necesarios para la correcta ejecución tanto en Internet Explorer como en Netscape. Para firmar clases que funcionen correctamente con Netscape se debe obtener la versión 1.1 de la herramienta de Netscape para firmar código, que se encuentra en la siguiente URL: Los mecanismos utilizados para la instalación de código son el SmartUpdate en Netscape y el Package Manager en Internet Explorer. Estos mecanismos están disponibles a partir de las versiones 4.0 de ambos productos. En el caso de Netscape es posible deshabilitar esta opción, aunque por defecto está habilitada. Si se deshabilitara, se desplegará un mensaje al usuario final indicándole que debe habilitarlo. En Internet Explorer, si el nivel de seguridad para la zona está en Alto, no permite instalar software en el cliente. Debe estar en el valor medio o inferior ( medio es el valor por defecto). Si se tiene el valor alto, se desplegará el diálogo anunciando que se van a instalar las clases, pero no se llevará a cabo la instalación (no aparece ningún mensaje de error). Como obtener certificados de prueba Netscape Netscape almacena los certificados dentro de una base de datos que está en un archivo cert.db que se encuentra en el directorio del profile del usuario. Este directorio en general está en <Program 72

74 Files>\Netscape\Users\<Nombre del Profile>. Cuando se instala Netscape, se crea un profile Default con los valores por defecto. Para crear un certificado de prueba lo primero que hay que hacer es poner una password a la información de seguridad, que se habilita en la opción security info/passwords del menú de Netscape. Luego, salir del Netscape, y ejecutar el siguiente utilitario (ver en Anexo I dónde obtenerlo): signtool -d%id_loc% p%id_passwd% G%ID_NAME% donde : %ID_LOC% es el directorio donde está la información del profile (por ejemplo d:\program files\netscape\user\default. %ID_PASSWD% es la password definida en security info/passwords %ID_NAME% es el nombre del certificado de test que queremos crear Posteriormente se desplegará el siguiente mensaje: ********** About to sign directory using signtool *********** using certificate directory: d:\program files\netscape\users\default WARNING: Performing this operation while Communicator is running could cause corruption of your security databases. If Communicator is currently running, you should exit Communicator before continuing this operation. Enter y" to continue, or anything else to abort: Se debe presionar y para seguir, y se pedirá la siguiente información, que es toda opcional, puede dejarse en blanco: Enter certificate information. All fields are optional. Acceptable characters are numbers, letters, spaces, and apostrophes. certificate common name: organization: organization unit: state or province: country (must be exactly 2 characters): username: address: Luego se desplegará: generated public/private key pair certificate request generated certificate has been signed certificate "<Nombre del Certificado" added to database Exported certificate to x509.raw and x509.cacert. Esta operación crea un certificado de prueba en la base de datos de Netscape y dos archivos: x509.raw y x509.cacert que son necesarios para firmar el código. Internet Explorer Para crear un certificado de prueba para Internet Explorer es necesario ejecutar los siguiente comandos : makecert -sk <Nombre del Certificado> -n "CN=<Nombre del Usuario" <Nombre del Archivo>.CER 73

75 cert2spc <Nombre del Archivo>.CER <Nombre del Archivo>.SPC Donde: <Nombre del Certificado> es una palabra cualquiera <Nombre del Usuario> es un cadena de caracteres cualquiera <Nombre del Archivo> es un nombre de archivo válido Por ejemplo: makecert -sk "test" -n "CN=Juan Peres test.cer cert2spc test.cer test.spc Posteriormente, para habilitar que se puedan usar certificados de test en un PC, es necesario ejecutar: setreg 1 TRUE Todos estos utilitarios (makecert, cert2spc, setreg) se encuentran en el subdirectorio bin\packsign del SDK 3.1, o en el subdirectorio bin del SDK 3.2 de Microsoft. Deployment Wizard El Deployment Wizard es un utilitario que se incluye con el generador para facilitar la utilización de las aplicaciones generadas en diferentes ambientes, como navegadores, servidores de aplicaciones, etc. Todos los ambientes de ejecución Java soportan la distribución de conjuntos de clases Java empaquetadas en un único archivo. Estos archivos pueden ser.jar (que es básicamente equivalente a un.zip), y.cab (soportado solo por el Internet Explorer). Para ejecutar el wizard, se debe seleccionar la opción "GeneXus Deployment Wizard" del menú de "Utilities" del Developer Menu. El Developer Menu puede ejecutarse desde dentro de GeneXus a partir de la versión 6.0 Patch 9 o de la versión 6 Evolution I. En caso de tener una versión anterior de GeneXus puede invocarse ejecutando el siguiente comando desde el directorio del modelo: jview /cp:p gxclassr.zip com.genexus.developermenu Al ejecutarlo, se despliega la pantalla de la Figura

76 Figura 15: GeneXus Deployment Wizard 1/4 El Deployment Wizard consta de dos partes bien diferenciadas. En la primera se seleccionan los locations para los que se desea generar paquetes con las clases Java. En la lista de locations, además de los locations definidos en GeneXus, se incluye un location "<Client>", que incluye a todos los mains que se ejecutan desde el cliente (los que no tienen location definido). Una vez seleccionados los locations, se calculan automáticamente las clases necesarias para cada uno, y se permite agregar clases adicionales o archivos de imágenes. En la segunda parte, se pueden seleccionar diferentes "output processors", que a partir de la lista de clases definida para cada location, generan paquetes de diferentes características. Los output processors definidos en la versión actual del wizard son: Browser Deployment JAR Deployment IBM Win32 Native Compiler Permite crear paquetes que se puedan instalar automáticamente en los diferentes navegadores. Permite crear.jars con las clases necesarias para cada location. Esto se utiliza para crear los.jars necesarios en cada servidor de aplicaciones, o para crear un.jar con las clases necesarias en el cliente. Para crear.exes nativos de Windows usando el compilador de IBM. En la primer sección de la pantalla, se despliega la lista de locations definida en el modelo y se permiten seleccionar aquellas para las cuales se quieren generar clases empaquetadas. En el ejemplo, se han seleccionado todas las locations disponibles. La location "<Client>" se utiliza para especificar todos aquellos objetos que no tiene un location definido. 75

77 En la segunda sección de la pantalla se despliega la lista de objetos main disponibles en para las locations seleccionadas, y se permite seleccionar los mains para los que se desea generar paquetes de clases. En el ejemplo, se han seleccionado los dos objetos main disponibles. Al presionar el botón <Next> se despliega la pantalla de la Figura 16: Figura 16: GeneXus Deployment Wizard 2/4 En el combo con los locations se puede seleccionar cualquiera de los locations elegidos en el primer paso. Al cambiar el location seleccionado se cambia la lista de clases necesarias en el listbox que está debajo. Para cada location se pueden agregar objetos o imágenes con los botones Add images.. y Add objects.. respectivamente. Es posible con el botón Remove file eliminar los objetos o imágenes que hayan sido agregados manualmente. Al habilitar la opción de Add classes from file se permite seleccionar un archivo de texto que contenga una lista de nombres de objetos a cargar. El archivo debe tener un nombre de objeto por línea, por ejemplo: paddclie pdelclie pupdclie El objetivo de esta característica es que si se utilizan calls dinámicos, se construya un archivo con la lista de objetos que pueden ser llamados dinámicamente, y se agregue a la lista de clases necesarias en este paso. Al presionar el botón <Next> se despliega la pantalla de la Figura

78 Figura 17: GeneXus Deployment Wizard 3/4 Aquí se puede definir, para cada Location, el modo en que se quieren transferir los archivos que resulten de la ejecución del Deployment Wizard. Para cada Location se pueden especificar los siguientes valores: Transfer location files Location File Name Transfer Mode Target Directory Host User Password Indica si se desean transferir a algún lado los ficheros generados. Indica el nombre que se le pondrá a los archivos que se generen para ese location. La extensión dependerá de cada 'output processor'. Indica el modo de transferencia que se desea. Los modos posibles son 'FTP' y 'Copy'. Directorio al que se van a transferir los archivos. Nombre del servidor FTP al que se van a transferir los archivos. Nombre del usuario con el que se conectará al servidor FTP. Si no se pone nada se intentará una conexión anónima. Contraseña que se utilizará para conectarse al servidor FTP. Si no se indicó un valor en 'User' no es necesario especificar este valor. Al presionar el botón <Next> se despliega la pantalla de la Figura 18: 77

79 Figura 18: GeneXus Deployment Wizard 4/4 Aquí se pueden seleccionar los diferentes "output processors" que se desean ejecutar para las clases de los locations seleccionados. Al presionar el botón <Finish>, se invoca a cada output processor seleccionado en forma secuencial. Todos los valores ingresados en las diferentes opciones del wizard son almacenados en un fichero "deployment.ini" de modo que en la siguiente ejecución se recuerdan los valores ingresados. Si es el caso, se puede presionar el botón <Finish> en cualquier paso, para ejecutar directamente los output processors. Veremos a continuación los diferentes output processors: Browser Deployment Este output processor realiza las siguientes funciones : Empaquetar las clases seleccionadas en archivos JAR o CAB para su utilización con Netscape,o Internet Explorer respectivamente. Firmar digitalmente estos paquetes con un certificado digital. Crear, por cada objeto main seleccionado, un archivos.html que permita la instalación de los paquetes en clientes Netscape o Internet Explorer simultáneamente. Los requisitos previos para poder utilizar este output processor son: Si se desea firmar código para Netscape, es necesario tener la herramienta signtool de Netscape 78

80 Si se desea firmar código para Microsoft, es necesario tener el SDK de Microsoft para Java Tener certificados digitales para cada navegador que se desee utilizar. Para crear archivos.cab es necesario ejecutar el Deployment Wizard utilizando la máquina virtual de Microsoft. Si no se desea crear archivos.cab se puede utilizar cualquier máquina virtual. Si se proyecta instalar código en los ordenadores de los usuarios finales es necesario especificar algún valor en la preference package name porque de lo contrario los navegadores podrían tener problemas para cargar las clases. Si no especifico un package name, y tengo dos aplicaciones GeneXus instaladas en un navegador, ambas con un objeto pupdcli, el navegador no sabrá cual utilizar, pero si una está en un package com.artech.siscli y otra en un package com.artech.websac no tendrá problemas. Al iniciar, se muestra la pantalla de la Figura 19. Figura 19: Browser Deployment - Generación del.cab para IE Con el check box se puede indicar si se desea o no generar un CAB para el Internet Explorer. En caso de que se seleccione, se deben ingresar los datos necesarios para realizar la firma digital y algunas opciones adicionales. Los datos son los siguientes: Install Virtual Machine Indica si se desea que se instale automáticamente la máquina virtual de Microsoft en el equipo del cliente. En este caso el Internet Explorer controla la versión de la máquina virtual y si la requerida por la aplicación es posterior a la que tiene instalada el cliente, instala la versión nueva. Para indicar la versión requerida de la máquina virtual se puede marcar el 79

81 Install CAB dependencies Public credential file Key container name Private key file Signcode directory Security Level Timestamp CAB File Include GeneXus Classes GeneXus Model URL checkbox "Current" que indica que se debe instalar la versión que está instalada en el equipo en que se ejecuta el deployment wizard, o en caso contrario se puede especificar manualmente el número de versión Luego debe copiarse el archivo msjavx86.exe (que contiene la maquina virtual) en el mismo directorio del servidor web donde se encuentre la aplicación GeneXus. Permite agregar especificar los archivos.cab que sean necesarios para ejecutar la aplicación. Estos archivos deben estar firmados. Un ejemplo de un.cab que sea necesario es el soporte para RMI. Por información de como crear un.cab con el soporte para RMI ver la sección específica de RMI. Estos archivos deben copiarse en el mismo directorio del servidor web donde se encuentre la aplicación GeneXus. Archivo provisto por el proveedor de certificados digitales. Si se utiliza un certificado de test, poner aquí el archivo con extensión.spc que se creó con el utilitario cert2spc. En caso de que se utilice un certificado de test, se debe poner aquí el nombre del certificado que se utilizó en el parámetro sk del utilitario makecert. Archivo provisto por el proveedor de certificados digitales, con extensión.pvk. En caso de que se utilice un certificado de test, debe dejarse vacío. Path de la herramienta signcode de Microsoft. (Debe incluirse el nombre del ejecutable) Nivel de seguridad que necesita el applet para ejecutar. Al instalar el applet en la máquina del cliente, se le notificará de los permisos requeridos. High implica alta seguridad o sea, bajos permisos de ejecución. Low significa baja seguridad, o sea, altos permisos de ejecución. Permite certificar que el archivo fue firmado en determinado momento. Esto permite que si el certificado digital expira, el archivo siga siendo válido si fue firmado antes de que el certificado expirara. Para que funcione correctamente hay que tener acceso a Internet. Indica si se quieren instalar las clases estándar de GeneXus junto con la aplicación. Es la opción recomendada. Indica la URL base en donde se encuentran los.cab que necesita la aplicación para funcionar (estos pueden ser el.cab con las clases de GeneXus y los.cabs agregados manualmente). Es necesario indicarlo aquí porque debe indicarse dentro del.cab que se crea con las clases de la aplicación. Solo es necesario especificarla si se van a instalar.cabs adicionales o si se incluirán las clases GeneXus. Internet Explorer 5.0 soporta que la URL de los.cabs necesarios se pongan de forma relativa a la URL actual, por lo que si se deja vacío este valor, asumirá que los.cabs están en el mismo directorio que la aplicación GeneXus. DCOM Client Configuration: Permite que al instalar las clases de la aplicación en el cliente, se realice la configuración DCOM en el mismo. Las opciones de configuración se describen a continuación y son las que muestra la Figura 20 80

82 Figura 20: Browser Deployment - DCOM Client Configuration Update Client's DCOM Configuration Enable Connection-oriented TCP/IP Enable HTTP tunneling Make HTTP Tunneling the default protocol DCOM Authentication Mode Indica si se quiere modificar la configuración de DCOM del cliente o no. Si no se marca esta opción, los demas valores no se pueden ingresar. La comunicación via DCOM puede hacerse por varios protocolos. Uno de ellos es TCP/IP 'orientado a conexión', que implica que hay una conexión directa a un port no predeterminado del servidor para la conexión. Esta opción está habilitada por defecto en Win95 y NT, y es la recomendable si no hay ningún firewall/proxy entre el cliente y el servidor Otro protocolo por el que se puede hacer la comunicación DCOM es 'HTTP tunneling'. Este protocolo realiza la comunicación con el servidor utilizando el puerto 80, por lo que en general puede atravesar proxies/firewalls. Es necesario habilitarlo si hay firewalls/proxies entre clientes y servidor. Por mas información sobre como configurar DCOM para atravesar proxies/firewalls ver en el manual del generador DCOM intenta realizar la comunicación por cada protocolo, hasta encontrar uno que funcione. Por defecto, intenta conectarse con Connection- Oriented TCP/IP, y luego con HTTP. Si se setea esta opcion el orden es al revés. Conviene setearla si se está seguro que los clientes van a utilizar HTTP Tunneling Las opciones válidas son 'Connect' y 'None'. Si se pone 'Connect', DCOM validará el usuario para permitir la conexión. DCOM valida al usuario si el cliente está en el mismo dominio del servidor, o si el usuario/password con que se conectó el cliente corresponden a un usuario/password en el servidor. Si se pone 'None', se puede conectar cualquier cliente. Si se selecciona la opción de 'Update Client's DCOM Configuration', al instalar las clases de la aplicación se 81

83 ejecutará un programa llamado _dcomset.exe, que realizará los cambios que se especificaron. Si los valores de la configuración DCOM en el cliente coinciden con los aquí especificados, en programa no hace nada. Si no coinciden, los cambia y pide que se reinicie el equipo, dado que esto es necesario para que tengan efecto. Al presionar Next se despliega la pantalla de la Figura 21. Figura 21: Browser Deployment - Generación del.jar para Netscape Con el check box se puede indicar si se desea o no generar un JAR para Netscape. En caso de que se seleccione, se deben ingresar los datos necesarios para realizar la firma digital. Los datos son los siguientes: Install JAR dependencies Include GeneXus classes Profile directory Password Public certificate Se permite agregar una lista de.jars necesarios para que ejecute la aplicación. Por ejemplo, se puede agregar el archivo "swingall.jar", que tiene el soporte para JFC, para poder ejecutar aplicaciones con JFC dentro de Netscape. Estos.JAR no tienen porque estar firmados. Actualmente Netscape es muy lento para procesar.jars que tienen un archivo de "manifest" dentro. Es recomendable abrir los.jars con un utilitario para manejar.zips y eliminar el archivo manifest.mf. Indica si se desea que en el.html que se genere se incluya una referencia a las clases GeneXus de modo que estas se instalen además del paquete de clases con la aplicación. En general se debe marcar esta opción, a no ser que se esté seguro de que ya están correctamente instaladas en el equipo del cliente. Directorio de profile donde se encuentra el certificado Password ingresada en security info/passwords (ver instrucciones para generar certificados con Netscape). Nombre del certificado creado. Si se utilizó un certificado de test, se debe 82

84 SignTool directory poner el valor ingresado en el parámetro G del utilitario signtool Directorio donde se encuentra el utilitario signtool Al seleccionar Next se desplegará la pantalla de la Figura 22. Figura 22: Browser Deployment - Creación de Paquetes En el parámetro Package Name, se indica el nombre que se le quiere dar a los archivos, al que se agregará la extensión.jar y.cab. La versión consta de 4 números, y es lo que permite a los navegadores determinar cuando tienen que volver a instalar la aplicación. El checkbox "Autoincrement Version" permite indicarle al Wizard que cada vez que se ejecute auto-incremente en uno el último numero de la versión. En general este es el comportamiento deseado, dado que si no se cambia el número de la versión, los navegadores de los clientes no instalarán la nueva versión. Si por alguna razón se desea dejar el número anterior, hay que desmarcar esta opción. En Application Name se ingresa un nombre que en Netscape se utilizará como descripción de la aplicación, pero en Internet Explorer será la clave con la que comparará el número de versión, por lo que si se cambia el nombre, el Internet Explorer la instalará aunque sea la misma versión. Al presionar Finish se comenzarán a armar los paquetes, y se firmarán. Si se especificó que se desea crear un.cab, la herramienta de firmado de clases de Microsoft (signcode), no se está firmando con certificados de prueba, y se ingresó una password al crear el fichero.pvk, se desplegará un diálogo solicitando que se ingrese la contraseña asociada al certificado. Adicionalmente, se generará un archivo con extensión HTML para cada objeto main seleccionado en la primer pantalla. 83

85 JAR Deployment Este output processor permite crear un.jar para cada location, con todas las clases necesarias en cada una. Figura 23: JAR Deployment Se permiten seleccionar los locations para los que se desea generar un.jar (ver Figura 23), y al presionar botón "Build JAR" se crea un.jar para cada una. El nombre del.jar será el mismo que el del location ("client.jar" en el caso del location <Client>). Estos.JAR deberán ponerse en el CLASSPATH de cada máquina virtual en que se deseen ejecutar. IBM Win32 Native Java Compiler Este output processor permite crear ejecutables o "JLLs" nativas de Win32 a partir de las clases Java. Necesita el compilador nativo Win32 de IBM que es parte del Visual Age for Java 2.0 Enteprise Edition. Es necesario Windows NT para poder utilizar el compilador. Este producto crea ejecutables que solo ejecutan en Windows 95/98 o NT. Tiene dos tipos posible de salidas, o ejecutables (.EXEs) o bibliotecas (.JLLs). Para las aplicaciones cliente es necesario crear ejecutables, y para las del servidor, bibliotecas. Estas bibliotecas serán utilizadas luego por el servidor de aplicaciones. Es necesario además obtener las clases de GeneXus compiladas para este producto. Estas clases no se distribuyen con el generador, pero estarán disponibles en el servidor web de ARTech. También es necesario compilar a.jll las clases adicionales que necesite la aplicación. Por ejemplo, si se necesita que la aplicación utilice JFC, es necesario compilar el "swingall.jar" (que es el.jar donde se distribuyen las clases de JFC) a.jll. Lo mismo con los drivers JDBC. Para compilar un.jar a.jll es necesario ejecutar el siguiente comando: hpj -classpath swingall.jar -jll -o swingall.jll -O -nofollow swingall.jar 84

86 donde "swingall.jar" es el nombre del.jar. En este ejemplo, se crea una.jll con las clases JFC. Con el HPJ se distribuye un swingall.jll pero, en la versión actual corresponde a las JFC 1.0.3, y el generador necesita la versión 1.1. Al ejecutar el "output processor" se despliega la pantalla de la Figura 24: Figura 24: IBM Win32 Native Java Compiler Aquí se pueden seleccionar las opciones de compilación. Si los Runtime Checks se dejan marcados, las aplicaciones pueden ejecutar algo mas lentas pero en caso de algún error crítico no se producirán errores de protección general. Si se desmarcan, la performance puede ser mejor, pero pueden producirse errores de protección general. Las opción de Architecture permite seleccionar para que tipo de procesador se desea generar el código (x86, 486, Pentium o Pentium II), y la opción Tuning permite seleccionar para que procesador se desea optimizar el código (386, 486, Pentium, Pentium II o "Blend" que significa una optimización que funciona razonablemente bien en todos). Al presionar el botón <Build> se generará un.exe para cada main del cliente un.jll por cada location remoto. Los nombres serán los de los mains para los ejecutables del cliente, y los del location para las.jlls. La compilación puede demorar bastante. Una vez generados los ejecutables, para poder ejecutar la aplicación es necesario seguir los siguientes pasos: - Ejecutar el comando hpjdeploy.cmd del directorio BIN del compilador. El uso de dicho comando es : hpjdeploy <directorio> especificando en <directorio> el path donde se quiere instalar la aplicación. - Copiar los.exes y.jlls al dicho directorio - Setear la variable classpath de la siguiente forma: set classpath=<.jlls de la aplicación>;<.jlls con drivers JDBC>;gxclassr.jll;<JLL con JFC>;swingall.jar;gxclassr.zip es necesario agregar el swingall.jar y el gxclassr.zip al classpath para que se puedan encontrar recursos adicionales como archivos de properties e imágenes. 85

87 Transferencia de archivos Al finalizar cada output processor, se desplegará la pantalla de la Figura 25. Figura 25: Transferencia de archivos Esto permite seleccionar cada Location, ver los archivos que se van a transferir a cada una, y al presionar el botón <Transfer> se copiarán los ficheros de acuerdo al método de transferencia seleccionado (FTP o Copy). Ejecución en Internet a través de proxies Si vamos a publicar la aplicación Java en Internet podemos encontrarnos con clientes que necesiten accederla y se conecten a Internet a través de un servidor proxy. Este tipo de conexión presenta algunas complicaciones adicionales, dependiendo del protocolo de comunicaciones entre capas que se utilice. Ejecución con RMI Para la ejecución con RMI, es necesario que el proxy que utiliza el usuario final soporte el protocolo SOCKS y lo tenga habilitado en el puerto1080. Además, el usuario también debe tener correctamente configurado el acceso al servidor proxy con SOCKS en su navegador. Para el Internet Explorer la configuración se realiza desde Tools Internet Options Connections LAN Settings Proxy Server Avanced (ver Figura 26 ) y debe setearse lo siguiente: Desmarcar el check de Use the same proxy server for all protocols Poner al servicio de SOCKS en el puerto

88 Figura 26: Proxy Settings en Internet Explorer En el ejemplo el servidor proxy está en , y el servicio de SOCKS está en el puerto Los demás valores de puerto pueden estar en cualquier puerto, pero el de SOCKS tiene que ser Ejecución con DCOM Para que las aplicaciones DCOM es necesario habilitar el HTTP Tunneling en el servidor de Web, que debe ser Microsoft Internet Information Server 4.0 o superior. El HTTP Tunneling está disponible desde el Service Pack 4 de Windows NT 4.0. Existe mayor información en Internet sobre cómo hacer funcionar estos servicios. Ver en Anexo I Dónde obtener el software necesario? las URLs de estos sitios. Ejecución con CORBA Los fabricantes de productos CORBA proveen formas bastante evolucionadas para soportar clientes en Internet. En particular VisiBroker tiene un producto llamado GateKeeper que permite que accedan usuarios detrás de un proxy. Referirse a la documentación de este producto. 87

89 APPLICATION SERVER MONITOR El Application Server Monitor permite ver el estado del servidor de aplicaciones, así como realizar algunas tareas de administración, como el bajar el servidor de aplicaciones o desconectar a usuarios. El monitor puede ejecutarse desde la opción "Utilities" del Developer Menu, o desde la línea de comandos con la instrucción: <interprete java> com.genexus.gx.deployment.umonitor (el CLASSPATH debe estar configurado correctamente) Al ejecutarlo, se despliega la siguiente pantalla: Figura 27: GeneXus Application Server Monitor En Server/Port de debe poner la dirección del servidor de aplicaciones, y el puerto en donde se configuró para que escuche al monitor en el server (ver sección "Configuración del Servidor de Aplicaciones"). Los valores por defecto son "localhost" y "1999". Al presionar el botón <Connect> se conecta al servidor de aplicaciones, obtiene la lista de Namespaces, y los usuarios conectados al mismo. Los namespaces que se despliegan son solo aquellos a los que se conectó algún usuario alguna vez. Las columnas informan del número interno que se le asigna al cliente, el protocolo con que se conectaron, el 88

90 número de IP del cliente (solo con RMI), la fecha/hora de conexión y la cantidad de segundos sin actividad que estuvo el cliente. Si se marca la opción 'Automatic Refresh', la pantalla se refrescará automáticamente, pudiendo indicar el intervalo. Si se presiona el botón "ShutDown Application Server", se pedirá confirmación, y se bajará el servidor de aplicaciones. Si está ejecutando como servicio en NT, no se bajará. Cuando se quiere instalar una versión nueva de las clases de un namespace en el servidor, es necesario, antes de instalarlas, ejecutar la opción 'Reset Namespace'. Esto causa que todas las clases que estén cargadas del.jar anterior se descarguen, y se desconecten a todos los usuarios. El botón 'Disconnect User' permite desconectar al usuario seleccionado. Utilizar esta opción con cuidado, dado que al usuario que ha sido desconectado le cancelará la ejecución. Si se presiona el botón 'Read-Only Pool Information' se despliega la pantalla de la Figura 28. Figura 28: GX App. Monitor - Read-Only Pool Information En el combobox de arriba se permite elegir el usuario. Se mantiene un pool por usuario, por lo que si los usuarios se han conectado con usuarios diferentes, habrá uno por cada uno. Para cada conexión del pool se indica el ID de la conexión, y la cantidad de cursores abiertos en el momento. Con el botón <Disconnect> se puede cerrar una conexión. En caso de que esté siendo usada en el mismo momento, el cliente cancelará. Si no está siendo usada, la próxima vez que el cliente necesite una conexión creará una nueva. Los datos se refrescarán automáticamente dependiendo del valor del check 'Automatic Refresh' de la pantalla principal. Si se presiona el botón 'Read-Write Pool Information' se despliega la pantalla de la Figura 29 89

91 Figura 29: GX App. Monitor - Read-Write Pool Information En el combobox de arriba se permite elegir el usuario. Se mantiene un pool por usuario, por lo que si los usuarios se han conectado con usuarios diferentes, habrá uno por cada uno. Para cada conexión del pool se indica el ID de la conexión, el ID del usuario del servidor de aplicaciones (que corresponde al que está en la pantalla principal del monitor) que la utilizó por última vez, y un checkbox indicando si la conexión está siendo utilizada o no. Los datos se refrescarán automáticamente dependiendo del valor del check 'Automatic Refresh' de la pantalla principal. Con el botón <Disconnect> se puede cerrar una conexión. En caso de que esté siendo usada en el mismo momento, el cliente cancelará. Si no está siendo usada, la próxima vez que el cliente necesite una conexión creará una nueva. 90

92 FUNCIONES DE EXCEL Las funciones de Excel solo se soportan para la máquina virtual de Microsoft, y requieren Microsoft Excel 97 o Es necesario tener la versión o posterior de la máquina virtual de Microsoft (ver en Anexo I dónde obtenerla). Las funciones permiten tener múltiples hojas de cálculo abiertas y manejar indistintamente cada una de ellas. Para lograr esto, la función que crea o abre una hoja de cálculo devuelve un número que luego se utiliza en las llamadas a las otras funciones para indicarle a que hoja de cálculo se refiere la operación. Las funciones son las siguientes: GxXOpen Sintaxis: call('gxxopen', &XlsFileName, &XlsHandle) Esta función intenta abrir o crear la una hoja de cálculo Excel. Si Excel ya está ejecutando, la hoja de cálculo se abre en dicha instancia de Excel. Sino se crea una instancia nueva, que queda oculta hasta que se llama al comando GxXShow. El nombre de la primera hoja de la hoja de cálculo será "GeneXus Spreadsheet". Los parámetros son los siguientes: &XlsFileNa me &XlsHandle C Nombre de la hoja de cálculo a abrir o crear. Si no existe una hoja de cálculo con el nombre indicado, se crea. Si no es especifica el directorio en el nombre de la hoja de cálculo, se asume el directorio de la aplicación. Si no se especifica la extensión se asume ".xls". N Retorna un número que luego debe pasarse como parámetro al resto de las rutinas para indicarle a que hoja de cálculo se refiere. No hay un límite predeterminado de cantidad de hoja de cálculo abiertas (depende del límite que tenga Excel). GxXClose Sintaxis: call('gxxclose', &XlsHandle) Esta función cierra una hoja de cálculo Excel. Los parámetros son los siguientes: &XlsHandle N Indica el número de hoja de cálculo que se desea cerrar. GxXSave Sintaxis : call('gxxsave', &XlsHandle) Esta función graba una hoja de cálculo Excel. &XlsHandle N Indica el número de hoja de cálculo que se desea grabar. GxXClear Sintaxis : call('gxxclear', &XlsHandle) 91

93 Esta función borra el contenido de una hoja de cálculo Excel. &XlsHandle N Indica el número de hoja de cálculo a la que se desea borrar el contenido. GxXHide Sintaxis : call('gxxhide', &XlsHandle) Esta función oculta la instancia de Excel y la hoja de cálculo indicada con el número &XlsHandle. &XlsHandle N Indica el número de hoja de cálculo que se desea ocultar. GxXShow Sintaxis : call('gxxshow', &XlsHandle) Esta función hace visible la instancia de Excel, y la hoja de cálculo indicada con el número &XlsHandle &XlsHandle N Indica el número de hoja de cálculo que se desea mostrar. GxXGet Sintaxis : call('gxxget', &XlsHandle, &GXVal, &GXRow, &GXCol, &GXFont, &GXSize, &GXColor) Esta función obtiene el valor y las propiedades de una celda determinada. &XlsHandle N Indica el número de hoja de cálculo de la que se quiere obtener un valor. &GXVal An y Retorna el valor de la celda indicada, convertido al tipo que coincide con el tipo de la variable &GXVal &GXRow N Fila de la hoja de cálculo. El valor mínimo es 1. &GXCol N Columna de la hoja de cálculo. El valor mínimo es 1. &GXFont C Tipo de letra en la celda seleccionada &GXSize B Tamaño de la letra en la celda seleccionada &GXColor N Color en la celda seleccionada. GxXPut Sintaxis : call('gxxput', &XlsHandle, &GXVal, &GXRow, &GXCol, &GXFont, &GXSize, &GXColor) Esta función asigna a una valor y propiedades a una celda de una hoja de cálculo. &XlsHandle N Indica el número de hoja de cálculo de la que se quiere asignar un valor. &GXVal An y Valor que se quiere poner en la celda. Si en los primeros caracteres contiene la palabra "FORMULA:" se asume que el contenido a poner en la celda es la fórmula que se indica a continuación. &GXRow N Fila de la hoja de cálculo. El valor mínimo es 1. &GXCol N Columna de la hoja de cálculo. El valor mínimo es 1. &GXFont C Tipo de letra de la celda &GXSize B Tamaño de la letra de la celda &GXColor N Color de la celda seleccionada. 92

94 GxXType Sintaxis : call('gxxtype', &XlsHandle, &GXRow, &GXCol, &GXType) Esta función obtiene el tipo de datos del contenido de una celda de una hoja de cálculo. &XlsHandle N Indica el número de hoja de cálculo con la que se quiere operar. &GXRow N Fila de la hoja de cálculo. El valor mínimo es 1. &GXCol N Columna de la hoja de cálculo. El valor mínimo es 1. &GXType C Tipo del dato contenido en la celda indicada. Puede ser "D", "N", "C" o "U" para fecha, número, carácter o indefinido respectivamente. GxXlsCre Sintaxis: call("gxxlscre", &GXSSh, &GXRow, &GXCol, &GXTit(), &GXVisible, &GXTbl) Esta función permite crear una hoja de cálculo Excel y cargarle el valor de un subfile o una tabla. &GXSSh N Nombre de la hoja de cálculo que se quiere crear. Si una hoja de cálculo con este nombre fue cargada en la función GxXOpen, se utilizará dicha instancia de la hoja de cálculo. &GXRow N Fila superior de la tabla. El valor mínimo es 1. &GXCol N Columna izquierda de la tabla. El valor mínimo es 1. &GXTit() C Vector de caracteres con la lista de títulos de las columnas. &GXVisible N Indica si se desea mostrar la hoja de cálculo luego de cargarla. Si vale 0 no se mostrará, en caso contrario si. &GXTbl C Indica el nombre de la tabla a cargar, o "subfile" si se desea cargar el subfile. Actualmente solo se soporta la opción "subfile". Se pasarán a la hoja de cálculo solo las columnas del subfile que estén visibles. En caso de que la aplicación Java haya creado la instancia de Excel, la destruirá al termina de ejecutar. Si la instancia ya estaba creada, no será destruida. Estas funciones pueden ser utilizadas tanto desde Applications como desde Applets. 93

95 FUNCIONES DE MAIL El funcionamiento de las funciones de mail tiene algunas diferencias con respecto al de las aplicaciones generadas en Visual FoxPro y Visual Basic, dado que desde Java no se puede utilizar el soporte MAPI que provee Windows. Por esta razón, se utiliza nativamente el protocolo SMTP para enviar los mails. Las funciones de mail soportadas son las siguientes: GxMSend Sintaxis : call('gxmsend', &To, &CC, &BCC, &Subject, &Text, &Attach, &Login, &Window, &LoginName) Esta función permite enviar un mail. Sus parámetros son los siguientes: &To C Destinatario del mensaje. Puede especificarse mas de uno separados por ;, por ejemplo: test@artech.com.uy;soporte@artech.com.uy" &CC C Destinatarios a los que se enviará copia del mensaje. Se puede especificar mas de uno separándolos con ; &BCC C Destinatarios a los que se enviará copia ciega del mensaje, esto es, que no aparecerá en el cabezal del mensaje que se ha enviado el mensaje a dicha dirección. Se puede especificar mas de uno separándolos con ; &Subject C Tema del mensaje &Text C Texto del mensaje &Attach C Lista de archivos que se adjuntan. Puede especificarse mas de uno separados por ; &Login N Se ignora &Window N Indica si se abre o no una ventana para ingresar el mensaje manualmente. El valor 0 indica que se abre, y el 1 indica que no se abre. Esta opción funciona solamente si se está ejecutando la aplicación como un applet dado que de otro modo no se tiene acceso al diálogo de envío de mail del sistema. Para los valores sto y de ssubject se toman los especificados en dichas variables y los demás valores se ignoran. Esto es, si se especifica un texto para el mensaje y se llama a la función con el valor 0, y se está ejecutando como applet, no aparecerá el texto en el diálogo que se despliega. Esto es por una limitación &LoginNam e GxMSndB C de la URL mailto: de HTML. Dado que no existe el concepto de Login, este parámetro se utiliza como valor del atributo From del mensaje. Por ejemplo, si se especifica Juan Pérez <jperez@perez.com>, aparecerá dicho valor en el From mensaje enviado (algunos servidores SMTP no soportan esa sintaxis, por lo que solo se puede especificar la dirección: jperez@perez.com). Es obligatorio especificar este parámetro, dado que en caso contrario se produce un error al enviar el mail. Sintaxis : call('gxmsndb', &LoginName, &To, &Subject, &Text, &Window) &LoginNam e C Dado que no existe el concepto de Login, este parámetro se utiliza como valor del atributo From del mensaje. Por ejemplo, si se especifica Juan Pérez <jperez@perez.com>, aparecerá dicho valor en el From mensaje enviado (algunos servidores SMTP no soportan esa sintaxis, por lo que solo 94

96 se puede especificar la direccion: &To C Destinatario del mensaje. Puede especificarse mas de uno separados por ;, por ejemplo: test@artech.com.uy;soporte@artech.com.uy" &Subject C Tema del mensaje &Text C Texto del mensaje &Window N Indica si se abre o no una ventana para ingresar el mensaje manualmente. El valor 0 indica que se abre, y el 1 indica que no se abre. Esta opción funciona solamente si se está ejecutando la aplicación como un applet dado que de otro modo no se tiene acceso al diálogo de envío de mail del sistema. Para los valores sto y de ssubject se toman los especificados en dichas variables y los demás valores se ignoran. Esto es, si se especifica un texto para el mensaje y se llama a la función con el valor 0, y se está ejecutando como applet, no aparecerá el texto en el diálogo que se despliega. Esto es por una limitación de la URL mailto: de HTML. GxMLgin Sintaxis: call('gxmlgin', &LoginName) Dado que en SMTP no existe el concepto de Login, esta función no realiza ninguna operación. GxMLgout Sintaxis: call('gxmlgout') Dado que en SMTP no existe el concepto de Logout, esta función no realiza ninguna operación. En cambio para POP3 si realiza una operación para la desconexión y es necesario ejecutarla para finalizar una sesión POP3. gxmloginpop3 Sintaxis: call('gxmloginpop3', &Server, &User, &Password, &Delete, &NewMessages, &Timeout). Inicia una sesión POP3 para recibir mails. Los parámetros son los siguientes: &Server C Dirección del servidor POP3. Si se quiere acceder a un puerto distinto al 110 (que es el puerto por defecto de POP3) se puede especificar ":<puerto>" en el nombre del servidor. &User C Usuario con el que conectarse al servidor. &Password C Contraseña con la que conectarse al servidor &Delete N Indica si se desea borrar los mensajes luego de leerlos. Si vale 1, se borrarán luego de leerlos, si vale 0 se dejarán en el servidor. Indica si se quieren leer todos los mensajes o solo los nuevos. Si vale 1 se leerán los mensajes nuevos, si vale 0 se leerán todos los mensajes. &NewMessag N es &Timeout N Tiempo que se esperará por cualquier operación de red antes de dar error. Si se especifica 0, se esperará indefinidamente. Luego de loguearse a un servidor POP3 y leer los mensajes, es necesario realizar la desconexión, esto es ejecutar GxMLogout. En caso de que no se ejecute este logout puede suceder que en determinados servidores de mails no se pueda volver a conectar porque aun se está conectado. Por otro lado esta ejecución es necesaria para que se almacenen los valores seteados en las variables &Delete y &NewMessages, de lo contrario no serán tomadas en cuenta. 95

97 gxmreceive Sintaxis: call('gxmreceive', &From, &To, &CC, &Date, &Subject, &Text, &Attachments). Esta función devuelve los datos del siguiente mensaje no leído en la sesión actual (iniciada por gxmloginpop3). Si tiene attachments y se especificó un directorio para los attachments con gxmattachdir, éstos se graban a disco. Los parámetros son los siguientes: &From C Dirección originaria del mensaje. &To C Lista de destinatarios del mensaje, separados por ";" &CC C Lista de destinatarios a los que se les envió copia del mensaje, separados por ";" &Date D Fecha en la que fue enviado el mensaje &Subject C Tema del mensaje &Text C Texto del mensaje &Attachment s C gxmaddressformat Sintaxis: call('gxmaddressformat', &Value). Lista de archivos que se adjuntan. Se almacenarán en el directorio indicado en la función 'gxattachdir', o en el directorio corriente si no se ha llamado a esta función. La lista se separa por ";". En caso de que ya exista un fichero con el mismo nombre que el que se adjunta, se agrega al nombre un numero serial entre paréntesis. Por ejemplo, si se envía el fichero "sales.doc" y ya existe, se grabará con el nombre "sales (1).doc". Si el archivo adjunto no especifica un nombre, se grabara con un nombre único. Indica el formato con que devuelve las direcciones de correo la función gxmreceive. &Value N Si vale 0 se devolverá solo el nombre, si vale 1 se devolverá la dirección internet, y si vale 2 se devolverá una cadena de la forma "Nombre <nombre.com>". El valor por defecto es 2. Si alguna dirección consta solo de nombre o solo de dirección, se retornará dicho valor sin importar el valor que se especifique en esta función. gxmattachdir Sintaxis: call('gxmattachdir', &Directory). Indica el directorio en que se guardarán los archivos que se adjunten a los mensajes recibidos por la función 'gxmreceive'. Si no se llama a esta función, o se la llama con el valor "", se guardarán en el directorio de la aplicación. &Directory C Nombre del directorio gxmerror Sintaxis: call('gxmerror', &Value). Indica el código de error de la última operación. Se debe utilizar para determinar que no quedan 96

98 más mensajes para leer. &Value N Recibe el valor del último error. Si es 0 quiere decir que no hubo error. El SMTP host que se utiliza para enviar el mensaje es el especificado en la preference SMTP Host. En caso de que se ejecute como applet, por restricciones de seguridad, no se puede comunicar con un host que no sea el servidor de web del que bajó el applet, por lo que se utiliza dicho servidor como SMTP host. Los archivos que se adjuntan son enviados utilizando Mime y la codificación Base64. 97

99 FUNCIONES DE FTP Se han implementado las siguientes funciones para manejo de FTP : GxFTPCon Sintaxis: call('gxftpcon', &Host, &User, &Pwd) Esta función permite conectarse a un servidor FTP. Los parámetros son los siguientes: &Host C Dirección del servidor de FTP &User C Usuario con el que conectarse. Si está vacío se asume un login anónimo &Pwd C Password con la que conectarse GxFTPPut Sintaxis: call('gxftpput', &Source, &Target, &Mode) Permite transferir un archivo hacia el servidor FTP. Los parámetros son los siguientes: &Source C Nombre completo del archivo origen (con el path) &Target C Nombre del archivo destino. Si se deja vacío se asume el mismo nombre del archivo origen, en el directorio por defecto. Si se pone solo el directorio (terminando en \), se asume el mismo nombre de archivo. &Mode C Modo de transferencia. Puede ser 'A' (Ascii) o 'B' (Binario) GxFTPGet Sintaxis: call('gxftpget', &Source, &Target, &Mode) Permite transferir desde el servidor FTP. Los parámetros son los siguientes: &Source C Nombre completo del archivo origen (con el path) &Target C Nombre del archivo destino. Si se deja vacío se asume el mismo nombre del archivo origen, en el directorio por defecto. Si se pone solo el directorio (terminando en \), se asume el mismo nombre de archivo. &Mode C Modo de transferencia. Puede ser 'A' (ASCII) o 'B' (Binario) GxFTPStat Sintaxis: call('gxftpstat', &Msg) Permite obtener el texto descriptivo del último error ocurrido. Los parámetros son los siguientes: &Msg C Texto del último error GxFTPError Sintaxis: call('gxftperror', &ST) Permite determinar si en el último comando ocurrió algún error. 98

100 &ST N Indicador de error. Es 1 si hubo algún error, 0 en caso contrario. GxFTPDis Sintaxis: call('gxftpdis') Permite desconectarse del servidor FTP FUNCIONES DE TEXTO Archivos ASCII Delimitados Los archivos ASCII Delimitados son archivos de texto (modificables con prácticamente cualquier editor de textos) comunmente utilizados para transferir información entre diferentes aplicaciones. Este tipo de archivos puede ser creado con cualquier DBMS (Oracle, SQL Server, FoxPro, etc.) y presenta las siguientes características: a. Cada línea del archivo representa una fila (o registro) b. Los campos de cada línea están separados por algún delimitador c. Los campos alfanuméricos (Character o Varchar en GeneXus) pueden estar o no delimitados por comillas ( ). d. Los campos numéricos no contienen comas separadoras de miles y, el separador de decimales es el punto. El siguiente, es un ejemplo de un archivo delimitado generado a partir de una tabla con los campos CodCli, NomCli, CedCli, NacCli: 1,"Martín Flores", , ,"Josefina Fernández", , ,"Alberto Sarmiento", , ,"Ignacio Martínez",526866, ,"Manuel González", , ,"Dalmiro Schmit", , ,"Juan Beltrán",455310, Con GeneXus es posible leer este tipo de archivos. Para ello se proveen un conjunto de funciones que permiten abrir el archivo, leer cada registro, copiar el contenido de cada campo a variables o atributos de GeneXus y cerrar el archivo. Por ejemplo, para leer el archivo del ejemplo, el código sería semejante al siguiente: &i = dfropen( "clients.txt", 80,, ) do while dfrnext( ) = 0 &i = dfrgnum( &CliCod) &i = dfrgtxt( &CliNom ) &i = dfrgnum( &CliCId ) &i = dfrgdate( &CliFecNac, ymd, - ) enddo &i = dfrclose( ) Como se ve en el ejemplo, no existe un esquema de descripción del registro (orden de los campos) del archivo ASCII delimitado. El orden de los campos está dado por la secuencia en que se llaman a las 99

101 funciones dbrgnum, dbrgtxt o dbrgdate. Si la secuencia fuera incorrecta, los resultados son impredecibles. También es posible grabar registros. Esto se realiza en forma análoga a la lectura, mediante el uso de funciones. Por ejemplo, para grabar el archivo del ejemplo anterior, el código GeneXus sería el siguiente: &i = dfwopen( "clients.txt", ",", '"') for each defined by CliNom &i = dfwpnum( CliCod) &i = dfwptxt( CliNom ) &i = dfwpnum( CliCId ) &i = dfwpdate( &CliFecNac, ymd, - ) &I = dfwnext() endfor &i = dfwclose( ) Lectura de archivos ASCII delimitados La siguiente es la descripción detallada de las funciones que permiten acceder y procesar archivos ASCII delimitados. dfropen Abre un archivo de texto para su procesamiento. Es la primera función que hay que llamar para comenzar a leer un archivo de texto. Sintáxis: dfropen( <filename>[, <length>[, <fdel>[, <sdel>]]]) Parámetros: <filename> puede ser un atributo, variable o constante de tipo char. Su valor será considerado como el nombre del archivo a procesar. Puede o no contener especificaciones de directorio. Si no las tiene, será buscado en el directorio corriente. <length> puede ser un atributo, variable o constante de tipo numérico, opcional, que indica el tamaño máximo, en cantidad de caracteres, del registro a leer. Véase que los archivos ASCII delimitados tienen registros (líneas) de largo variable. Si se especifica, el valor debe corresponder a la cantidad máxima de caracteres que puede tener una línea. El valor por defecto es <fdel> puede ser un atributo, variable o constante de tipo character, opcional, que indica cual es el caracter delimitador entre campos. Si se quiere especificar el caracter de tabulación como separador, el valor de este parámetro debe ser el string \t. <sdel> puede ser un atributo, variable o constante de tipo character, opcional, que indica cual es el caracter delimitador de los campos strings. Sólo el primer carácter del valor del parámetro es considerado. Su valor, puede ser cualquier carácter que no aparezca en los textos. Su valor por defecto es el (comillas). Retorno: Esta función puede retornar alguno de los siguientes valores: 0 Operación satisfactoria. El archivo fue abierto. -1 Secuencia incorrecta. Ocurre cuando se llama más de una vez a esta función sin haber llamado 100

102 antes a la función dfrclose. Si está activado el trace, se verá el mensaje ADF0005 indicando este error. -2 Error de apertura. Ocurre cuando el archivo identificado por <filename> no ha podido abrirse. La causa puede ser identificada claramente habilitando el trace y buscando el mensaje con código ADF0001. Lo más común es que el archivo no exista. -8 Memoria insuficiente. Ocurre cuando no es posible reservar un buffer de <length> bytes. Si está activado el trace, se verá el mensaje ADF0007 indicando este error. dfrnext Lee el siguiente registro (línea) del archivo de texto delimitado. Sintáxis: dfrnext() Parámetros: No tiene Retorno: Esta función puede retornar alguno de los siguientes valores: 0 Operación satisfactoria. El registro fue leído. -1 Secuencia incorrecta. Ocurre cuando se llama a esta función antes de llamar a la función dfropen o la llamada a dfropen retornó un valor diferente de cero (error). -3 Error de lectura. Ocurre cuando se ha producido un error al leer una línea del archivo ASCII delimitado. La causa puede ser identificada claramente habilitando el trace y buscando el mensaje con código ADF Fin de datos. dfrgnum Lee un campo de tipo numérico de la línea actual (leída por dfrnext). Sintáxis: dfrgnum( <num>) Parámetros: <num> puede ser un atributo o variable de tipo numérico. En él, se almacenará el valor leído. Retorno: Esta función puede retornar alguno de los siguientes valores: 0 Operación satisfactoria. El campo fue leído. -1 Secuencia incorrecta. Ocurre cuando se llama a esta función antes de llamar a la función dfrnext o la última llamada a dfrnext retornó un valor diferente de cero (error). Si el trace está habilitado, se verá el mensaje ADF0004 o ADF Formato incorrecto. El número en el campo no tiene una forma correcta. La causa más común es que el campo que se pretende leer sea de otro tipo (character, date, etc.). Si el trace está habilitado, se verá el mensaje ADF0008. dfrgtxt Lee un campo de tipo character de la línea actual (leída por dfrnext). Sintáxis: dfrgtxt( <txt> [, <length>]) 101

103 Parámetros: <txt> puede ser un atributo o variable de tipo character o varchar. En él, se almacenará el valor leído. <length> puede ser un atributo, variable o constante de tipo numérico, opcional, que indica la cantidad máxima de caracteres a leer. Su valor, si se especifica, no debe exceder el tamaño definido para <txt>. En caso de omitirse, se asume el tamaño definido para el atributo o variable <txt>. Si éste parámetro excede el tamaño de <txt> los resultados son impredecibles. Retorno: Esta función puede retornar alguno de los siguientes valores: 0 Operación satisfactoria. El campo fue leído. -1 Secuencia incorrecta. Ocurre cuando se llama a esta función antes de llamar a la función dfrnext o la última llamada a dfrnext retornó un valor diferente de cero (error). Si el trace está habilitado, se verá el mensaje ADF0004 o ADF Formato incorrecto. El string en el campo no tiene una forma correcta. La causa más común es que el campo que se pretende leer sea de otro tipo (number, date, etc.). Si el trace está habilitado, se verá el mensaje ADF Overflow. Este es un warning que indica que el largo del string en el registro es mayor al máximo especificado (o asumido) en el parámetro <length>. El valor leído es truncado a <length> caracteres. dfrgdate Lee un campo de tipo date de la línea actual (leída por dfrnext). El valor de fecha leído no es ajustado de acuerto con la preference Year Limit. Sintáxis: dfrgdate( <date> [, <fmt> [, <sep>]]) Parámetros: <date> puede ser un atributo o variable de tipo date. En él, se almacenará el valor leído. <fmt> puede ser un atributo, variable o constante de tipo character, opcional, con, al menos, tres caracteres. Indica el formato que tiene la fecha en el campo a leer. Cada carácter del campo puede valer y, m o d. Su combinación genera el formato. Por ejemplo si el string contiene los caracteres ymd la fecha del campo a leer se asume (y valida) en formato Año, Mes, Día. Si, por el contrario el string contiene los caracteres dmy, la fecha del campo a leer se asume en formato Día, Mes, Año. Es importate notar que los caracteres deben estar en minúscula. El valor por defecto es ymd. <sep> puede ser un atributo, variable o constante de tipo character, cuyo valor debe tener, al menos, un caracter. Indica cuál es el separador de los elementos de una fecha. Los valores comunmente utilizados son /, - y.. El valor por defecto es -. Retorno: Esta función puede retornar alguno de los siguientes valores: 0 Operación satisfactoria. El campo fue leído. -1 Secuencia incorrecta. Ocurre cuando se llama a esta función antes de llamar a la función dfrnext o la última llamada a dfrnext retornó un valor diferente de cero (error). Si el trace está habilitado, se verá el mensaje ADF0004 o ADF Formato incorrecto. El string en el campo no tiene una forma correcta. La causa más común es que el campo que se pretende leer sea de otro tipo (number, date, etc.). -7 Fecha no válida. El valor encontrado en el campo no corresponde a una fecha válida. Normalmente 102

104 ocurre porque el formato (<fmt>) o el separador (<sep>) no corresponde a los existentes en el archivo. Si el trace está habilitado, se verá el mensaje ADF El parámetro <fmt> tiene un formato incorrecto. Si el trace está habilitado, se verá el mensaje ADF0012. dfrclose Cierra el archivo abierto por dfropen. Esta función debe ser llamada después de una llamada satisfactoria (sin error) a dfropen. Sintáxis: dfrclose() Parámetros: No tiene. Retorno: Esta función puede retornar alguno de los siguientes valores: 0 Operación satisfactoria. El archivo fue cerrado. -1 Secuencia incorrecta. Ocurre cuando se llama a esta función antes de llamar a la función dfropen o la última llamada a dfropen retornó un valor diferente de cero (error). Grabación de archivos ASCII delimitados La siguiente es la descripción detallada de las funciones que permiten grabar archivos ASCII delimitados. dfwopen Abre un archivo de texto para su procesamiento. Es la primera función que hay que llamar para comenzar a leer un archivo de texto. Sintáxis: dfwopen( <filename>[, <fdel>[, <sdel>]]]) Parámetros: <filename> puede ser un atributo, variable o constante de tipo char. Su valor será considerado como el nombre del archivo a procesar. Puede o no contener especificaciones de directorio. Si no las tiene, será creado en el directorio corriente. <fdel> puede ser un atributo, variable o constante de tipo character, opcional, que indica cual es el caracter delimitador entre campos. Si se quiere especificar el caracter de tabulación como separador, el valor de este parámetro debe ser el string \t. <sdel> puede ser un atributo, variable o constante de tipo character, opcional, que indica cual es el caracter delimitador de los campos strings. Sólo el primer carácter del valor del parámetro es considerado. Su valor, puede ser cualquier carácter que no aparezca en los textos. Su valor por defecto es el (comillas). Retorno: Esta función puede retornar alguno de los siguientes valores: 0 Operación satisfactoria. El archivo fue abierto. -1 Secuencia incorrecta. Ocurre cuando se llama más de una vez a esta función sin haber llamado antes a la función dfwclose. Si está activado el trace, se verá el mensaje ADF0005 indicando este 103

105 error. -2 Error de apertura. Ocurre cuando el archivo identificado por <filename> no ha podido abrirse. La causa puede ser identificada claramente habilitando el trace y buscando el mensaje con código ADF0001. Lo más común es que el archivo no exista. -8 Memoria insuficiente. Ocurre cuando no es posible reservar un buffer de <length> bytes. Si está activado el trace, se verá el mensaje ADF0007 indicando este error. dfwnext Graba el registro con los valores especificados por las llamadas anteriores a dfwptxt, dfwpnum, etc. en el archivo de texto delimitado. Sintáxis: dfwnext() Parámetros: No tiene Retorno: Esta función puede retornar alguno de los siguientes valores: 0 Operación satisfactoria. El registro fue leído. -1 Secuencia incorrecta. Ocurre cuando se llama a esta función antes de llamar a la función dfwopen o la llamada a dfwopen retornó un valor diferente de cero (error). -9 Error de grabación. Ocurre cuando se ha producido un error al grabar la línea en el archivo ASCII delimitado. La causa puede ser identificada claramente habilitando el trace y buscando el mensaje con código ADF0003. dfwpnum Graba un campo de tipo numérico en el registro actual del archivo ASCII delimitado. Sintáxis: dfwpnum( <num>, <dec>) Parámetros: <num> puede ser un atributo, variable o constante de tipo numérico. Su valor será el grabado en el campo correspondiente.. <dec> puede ser un atributo, variable o constante de tipo numérico, opcional, que indica la cantidad de decimales a especificar en el campo. Retorno: Esta función puede retornar alguno de los siguientes valores: 0 Operación satisfactoria. El campo fue grabado. -1 Secuencia incorrecta. Ocurre cuando se llama a esta función antes de llamar a la función dfwopen o la última llamada a dfwopen retornó un valor diferente de cero (error). Si el trace está habilitado, se verá el mensaje ADF0004. dfwptxt Graba un campo de tipo character en el registro actual del archivo ASCII delimitado. Sintáxis: dfwptxt( <txt> [, <length>]) 104

106 Parámetros: <txt> puede ser un atributo, variable o constante de tipo character. Su valor será el grabado en el campo correspondiente.. <length> puede ser un atributo, variable o constante de tipo numérico, opcional, que indica la cantidad máxima de caracteres a grabar. En caso de omitirse, se asume el tamaño definido para el parámetro <txt>. Retorno: Esta función puede retornar alguno de los siguientes valores: 0 Operación satisfactoria. El campo fue grabado. -1 Secuencia incorrecta. Ocurre cuando se llama a esta función antes de llamar a la función dfwopen o la última llamada a dfwopen retornó un valor diferente de cero (error). Si el trace está habilitado, se verá el mensaje ADF0004. dfwpdate Graba un campo de tipo date en el registro actual del archivo ASCII delimitado. Si tiene el valor nulo de GeneXus, se grabará la fecha "00/00/0000". Sintáxis: dfwpdate( <date> [, <fmt> [, <sep>]]) Parámetros: <date> puede ser un atributo o variable de tipo date. En él, se almacenará el valor leído. No puede ser una constante. <fmt> puede ser un atributo, variable o constante de tipo character, opcional, con, al menos, tres caracteres. Indica el formato que tiene la fecha en el campo a grabar. Cada carácter del campo puede valer y, m o d. Su combinación genera el formato. Por ejemplo si el string contiene los caracteres ymd la fecha del campo a grabar se asume en formato Año, Mes, Día. Si, por el contrario el string contiene los caracteres dmy, la fecha del campo a leer se asume en formato Día, Mes, Año. Es importate notar que los caracteres deben estar en minúscula. El valor por defecto es ymd. <sep> es un parámetro de tipo caracteres opcional con, al menos, un caracter. Indica cuál es el separador de los elementos de una fecha. Los valores comunmente utilizados son /, - y.. El valor por defecto es -. Retorno: Esta función puede retornar alguno de los siguientes valores: 0 Operación satisfactoria. El campo fue grabado. -1 Secuencia incorrecta. Ocurre cuando se llama a esta función antes de llamar a la función dfwopen o la última llamada a dfwopen retornó un valor diferente de cero (error). Si el trace está habilitado, se verá el mensaje ADF Formato incorrecto. El string en el campo no tiene una forma correcta. La causa más común es que el campo que se pretende leer sea de otro tipo (number, date, etc.). -10 El parámetro <fmt> tiene un formato incorrecto. Si el trace está habilitado, se verá el mensaje ADF0012. dfwclose Cierra el archivo abierto por dfwopen. Esta función debe ser llamada después de una llamada satisfactoria (sin error) a dfwopen. 105

107 Sintáxis: dfwclose() Parámetros: No tiene. Retorno: Esta función puede retornar alguno de los siguientes valores: 0 Operación satisfactoria. El archivo fue cerrado. -1 Secuencia incorrecta. Ocurre cuando se llama a esta función antes de llamar a la función dfwopen o la última llamada a dfwopen retornó un valor diferente de cero (error). Consideraciones sobre los archivos ASCII delimitados Sólo puede estar abierto un archivo ASCII delimitado en un momento específico. La función dfropen retornará un error si se la llama más de una vez sin haber llamado previamente a dfrclose. Es posible ignorar los campos del final de un registro al llamar a dfrnext cuando queden campos por leer. No es posible saltearse campos. Si se quiere leer el campo número 5 es necesario leer los 4 anteriores. Es posible leer registros con diferentes formatos como en el siguiente ejemplo: &i = dfropen( "invoices.txt", 80,, ) do while dfrnext( ) = 0 &i = dfrgtxt( &RecType) if &RecType = H &i = dfrgnum( &InvNum ) &i = dfrgdate( &InvDat, ymd, / )... else &i = dfrgnum( &PrdNum ) &i = dfrgnum( &InvQty)... endif enddo &i = dfrclose( ) 106

108 DEVELOPER MENU A partir de la versión 6.0 patch 9 y de la versión 6 Evolution I de GeneXus, al llamar al diálogo de ejecución de Java aparecerá una entrada con el nombre de Developer Menu, que tendrá una funcionalidad análoga a los Developer Menú de Visual Basic o Visual FoxPro. Si se compila el Developer Menú, se intentarán compilar todos los objetos GeneXus de la Base de Conocimiento con la que se está trabajando. Aunque no se compile, es posible ejecutarlo, con la salvedad de que no se podrán invocar los objetos GeneXus que no hayan sido compilados. En la versión actual, el Developer Menu solo se puede ejecutar como Application. Por esta razón, GeneXus lo ejecutará como Application aunque esté configurado para ejecutar como Applet, por lo que es necesario que esté bien ingresado el intérprete Java que se desea usar en el diálogo de ejecución. El diálogo del Developer Menú es el que se puede visualizar en la Figura 30. Figura 30: Developer Menu El funcionamiento es muy sencillo. En los EditBoxes de la parte superior se puede filtrar por partes del nombre o de la descripción de los objetos Genexus. Con los checkboxes se puede seleccionar con que tipo de objeto se desea trabajar (solo se puede seleccionar un tipo de objeto). Los valores de los filtros se guardan entre las diferentes ejecuciones del Developer Menu. 107

109 Desde la opción Utilities del menubar se puede invocar al Deployment Wizard y el utilitario para la configuración del servidor de aplicaciones. En la opción About del menubar, se despliega el diálogo About por defecto (ver Figura 31), que indica con tipo de interfaz de usuario se está ejecutando, protocolo de ejecución distribuida (o "JDBC" si se accede en 2 capas) y la versión del generador. Figura 31: "About" en el Dev. Menu CONSIDERACIONES ESPECIALES DE LA VERSIÓN ACTUAL DEL GENERADOR Características que no son soportadas aún Generación de HELP. Redundancias Funciones de gráficos Los common dialogs gxselprn, gxselfont y gxcalculate Las siguientes properties de objetos Work panels Allow user to cancel while loading Procedures Allow user to cancel processing Características soportadas por y no implementables en Java Con AWT, algunos colores de background de controles de Edit no funcionan correctamente, otros sí. Con AWT y WFC, los radio buttons y checkboxes son opacos, esto es, si se superponen a un área de color, el color del radiobutton será gris de todos modos. Debe setearse el fondo del radiobutton o checkbox de modo que sea el mismo que el color de fondo. La función Msg(<mensaje>, nowait), si se ejecuta dentro de un browser, despliega información en la barra de status del browser. Sino, despliega información en la consola. 108