HIPERGATETABLA DE CONTENIDO

1. Que es Hipergate.a. Que hace Hipergate único.

2. Modulos Funcionales.a. Modulos Funcionales Incluidos en el Producto Estándar.b. Funcionalidades Comunes para todos los Modulos.

3. Ventajas y Beneficios.4. Diseño y Tecnología.

a. Requisitos y Prioridades del Diseño.b. Lenguajes, Componentes y Plataformas Utilizados.c. Estructura interna.d. Servidor sin Estados.e. Separación de Datos por Clientes y Departamentos.f. Modelos de Seguridad.

5. Manual de Instalación para la versión 4.0.a. Para los Impacientes.b. Planificar la Instalación.c. Requisitos.d. Contenido del paquete de Distribución.e. Instalar y Configurar un Sitio Web de ejemplo.f. Instalar las Librerías.g. Crear la Base de Datos.h. Ejecutar el Asistente de Configuración.i. Configuración de Seguridad y Áreas de Trabajo.j. Pruebas de Conexión de Acceso.k. Configuración de Servlets.l. Usos de Múltiples instancias de Hipergate en el mismo Servidor.m. Incompatibilidades desconocidas.n. Descargas Adicionales.o. Herramientas de Administración.p. Instalación sobre JBoss.q. Apéndice 1: Propiedades de Hipergate.cnf.r. Apéndice 2: Carga Manual de la Base de Datos.s. Apéndice 3: Configuración de Granjas de Servidores.t. Apéndice 4: Librerías de Terceros.u. Apéndice 5: Librerías de Depuración.v. Apéndice 6: Notas para Recompilara los Fuentes.w. Como actualizarse de la versión 3.0 a la 4.0x. Diagnostico de Problemas.

1. Que es Hipergate:

hipergate es una suite de aplicaciones de código abierto basadas en web.

El propósito del conjunto de programas es cubrir un amplio rango de necesidades de tecnología de información en cualquier organización. Todas las aplicaciones se acceden desde Internet Explorer sin necesidad de descargar ningún software en el puesto cliente.

La suite tiene capacidad multi-entidad y puede utilizarse indistintamente para dar servicio a una empresa, a un grupo de empresas, o en modalidad ASP para alojar un número ilimitado de entidades cliente diferente.

a. Que hace Hipergate Único:

Es completamente gratuito. Es la única aplicación Open Source con una cobertura funcional tan amplia.

Funciona sobre múltiples bases de datos y sistemas operativos.

Tiene un diseño conceptual e implementación unitarios.

Es apropiado para su uso en modalidad ASP.

Es multi-idioma.

Dispone de una red de servicios profesionales de soporte.

Está bien documentado.

2. Módulos Funcionales:

a. Módulos funcionales incluidos en el producto estándar

Modulo de Herramientas Colaborativas y Trabajo en Grupo

Calendario y Agenda de Reuniones Compartida. Foros Libres y Moderados con múltiples grupos.

Área de Preguntas Frecuentes.

Directorio de Personal

Listado y Reserva de Salas y otros Recursos Compartidos

Modulo de Gestión de Contactos

BB.DD. de Clientes, Proveedores, Competidores y Partners. BB.DD. de contactos personales

Múltiples Direcciones por Contacto.

Gestión de Demarcaciones Territoriales (Delegaciones)

Gestión del Pipeline de Ventas (Oportunidades Comerciales)

Listas de Distribución de diversos tipos.

Carga Directa de Windows Address Book (Outlook Express)

Carga Directa de ficheros de Contactos.

Modulo de Gestión de Proyectos y Soporte a Incidencias

Árbol Jerárquico de Proyectos. Seguimiento de Tareas Pendientes.

Control de Averías e Incidencias.

Contratos de Mantenimiento con Clientes.

Modulo de Tienda Virtual

Múltiples Catálogos Independientes. Jerarquía ilimitada de Categorías de Productos.

Atributos Variables por Producto.

Gestión de Stock en múltiples almacenes.

Gestión de Pedidos.

Gestión de Facturación.

TPV Banesto.

TPV Banco Popular.

TPV BBVA.

Modulo de Producción de Contenidos

Plantillas para comunicación vía e-mail. Plantillas para websites.

Formularios electrónicos.

Plantillas para fax.

Inclusión de contenidos multimedia.

Gestión categorizada de contenidos.

Librería de portlets para la presentación de contenidos dinámicos.

Modulo de Envío Masivo de Correos Electrónicos

Gestión de envíos múltiples de e-mails a listas de distribución. Estadísticas de recepción de mensajes.

Biblioteca Corporativa

Disco Virtual 100% basado en Web. Seguridad por usuario basada en roles para los archivos.

Gestión e Indexación de propiedades de documentos OLE.

Enlaces Favoritos compartidos.

Importar/Exportar favoritos al PC cliente.

b. Funcionalidades Comunes para todos los módulos

Seguridad basada en roles

Múltiples dominios independientes de seguridad. Número ilimitado de usuarios y grupos de permisos.

Roles predefinidos listos para utilizar en las aplicaciones.

Seguridad a nivel de empresa y a nivel de departamento.

Integración con LDAP.

Gestión de datos jerárquicos

Tesauro geográfico. Tesauro lexicográfico.

Categorización de objetos.

Informes y Consultas

Herramienta de Consulta Guiada por Formulario. Volcados a Excel.

Consultas online en formato HTML.

Informes remitidos por e-mail.

Planificador de Tareas

Gestión de colas de procesos. Ejecutor multi-hilo en segundo plano.

3. Ventajas y Beneficios del Producto

hipergate es software de última generación; diseñado, programado y testeado con las herramientas y técnicas más modernas.

El CRM Java Libre más completo

Ningúte otro producto libre sobre plataforma Java ofrece un conjunto de funcionalidades tan amplio como hipergate.

Soporte en todas las plataformas y bases de datos comunes

hipergate funciona indistintamente sobre Linux o Windows, y sobre Oracle, SQL Server, PostgreSQL o MySQL.

Aplicaciones independientes pero sinérgicas

Cada aplicación de la suite puede funcionar de forma independiente o junto con las otras aplicaciones. Las aplicaciones pueden activarse o desactivarse en caliente de forma particular para cada cliente, empresa o departamento. Esto hace que el usuario final pueda contratar las aplicaciones que realmente necesita sin tener que comprar toda la solución como sucede con los paquetes de software actuales.

Solución Integral

hipergate está concebido y pensado tanto en profesionales independientes como en empresas, de manera que puedan derivar todos sus procesos informáticos hacia la plataforma. La suite está orientada a facilitar el trabajo diario, creando así una base de usuarios que utilicen el software constantemente.

Integración con Office

hipergate reconoce e indexa documentos Office, permite cargar y exportar datos a Outlook Express y generar consultas en formato Excel.

Entorno intuitivo y fácil de manejar

Cada aplicación es fácilmente accesible desde un menú principal de pestañas. El interface con el usuario está diseñado para ser homogéneo y de esta forma de fácil y rápido aprendizaje.

Auto-administrable por el usuario final

hipergate suministra un modelo de administración predefinido basado en 4 perfiles de usuario: administrador, superusuario, usuario e invitado; a los que se asocia unas operaciones que pueden hacer sobre su información de forma muy parecida a como funciona el sistema operativo.

El administrador de la instancia concreta.

Las facilidades de auto-administración sirven dos propósitos: 1º) reducir el coste de propiedad de la aplicación en el cliente y 2º) reducir el coste de mantenimiento si la plataforma se ofrece en modalidad ASP.

Registro rápido y a trabajar

Al usuario se le da opción de que pruebe la herramienta durante un periodo de tiempo. El usuario puede en cualquier momento contratar el uso de las aplicaciones hipergate mediante pago a través de Internet aunque también se dan opciones de otras formas de pago. Una vez realizado el pago el usuario puede empezar a trabajar con las aplicaciones contratadas.

4. Diseño y Tecnología:

a. Requisitos y Prioridades de Diseño

hipergate fue diseñado desde el principio como una suite orientada a dar un servicio de alta calidad a los clientes más exigentes.

Se fijaron una serie de requisitos y prioridades que el producto debía cumplir estrictamente.

Ergonomía y Usabilidad

La primera prioridad del producto es que cada parte proporcione una buena experiencia de usuario. Esto se consigue mediante:

arquitectura de información homogénea a través de todos los módulos. modelo conceptual sencillo.

fácil acceso a todas las funcionalidades.

tiempos de respuesta rápidos para todas las operaciones.

completitud en la gama de operaciones disponibles.

Alcance Funcional

La suite está pensada para cubrir el 80% de las necesidades más típicas de cada módulo funcional. En este apartado se prefirió la expansión horizontal del producto por múltiples módulos antes que fabricar unas pocas aplicaciones específicas de alta complejidad.

La filosofía del producto es que las empresas pequeñas y medianas obtengan prácticamente todas las funcionalidades necesarias para cada departamento y que las grandes dispongan de una base sólida para desarrollar extensiones propietarias.

Estabilidad

La suite es un producto pensado para tener disponibilidad 24x7. Cada nuevo módulo es meticulosamente testeado en sucesivos walkthroughts de código, pruebas de caja negra y pruebas de stress en condiciones críticas.

Escalabilidad

Durante todo el ciclo de desarrollo no se quiso sacrificar en ningún momento el rendimiento por la transportabilidad o la ampliación funcional del producto. El código está optimizado para hacer uso de las funcionalidades específicas de cada base de datos y plataforma sobre los que puede ejecutarse.

Una parte de la lógica de proceso emplea procedimientos almacenados PL/SQL, PL/pgSQL o Transact-SQL reescritos manualmente para aprovechar al máximo las opciones más avanzadas de cada SGBDR.

El código Java dispone de 3 modos de ejecución: 100% Java Puro, Unix y Win32, y, según se configure explota las llamadas atómicas de cada sistema operativo para obtener el mejor rendimiento.

La aplicación está diseñada en 3 capas: servidor web, servidor de aplicación y servidor de base de datos. El diseño hace énfasis en la capacidad para crear granjas y repartir la carga entre múltiples servidores.

Para reducir el consumo de memoria y aumentar la capacidad de servicio de cada servidor web, la aplicación funciona sin sesiones ni estados mantenidos en el lado servidor.

Por último, la suite incorpora un sofisticado sistema propietario de cache distribuido con la misión de mantener información local en los servidores web y reducir la sobrecarga de los nodos de la base de datos.

Tolerancia a Fallos

La aplicación puede configurarse para funcionar en clustering tanto con los servidores web como con la base de datos.

Mantenibilidad

La estructura del código se diseñó pensando en que resultase sencillo de mantener y de ampliar por programadores sin conocimientos profundos de los detalles del sistema. El modelo de objetos que aísla el modelo físico de la base de datos del modelo de la lógica de negocio proporciona un marco natural para hacer ampliaciones con una curva de aprendizaje suave. Muchas de las tareas rutinarias de codificación: generación de formularios, tablas de remonte, validación de datos, gestión de fechas, etc. ya están resueltas de forma estándar en componentes reutilizables.

Separación de datos entre clientes

hipergate comparte información de varios clientes en una misma base de datos para evitar una proliferación insostenible de bases de datos. No obstante, como requisito imprescindible para poder dar servicio ASP, la información de cada cliente puede extraerse limpiamente en cualquier momento de la base de datos compartida para hacer una copia de respaldo exclusiva del cliente o para instalarse en una instancia de base de datos dedicada.

Economía

La aplicación puede funcionar basada 100% en software libre con el propósito de eliminar casi por completo los costes de licencias.

Otro factor, es el uso racional de la CPU y el disco que se consideran recursos escasos.

Tecnología Estándar

Sólo se emplean componentes y tecnologías de uso muy común en el mercado. Además se aboga por el uso exclusivo de plataformas con respaldo explícito para su continuidad de las grandes empresas del sector.

Simplicidad

A pesar de su amplio alcance técnico y funcional, la suite está diseñada y codificada para ser muy simple parte por parte.

b. Lenguajes, Componentes y Plataformas Utilizados

Java y Tomcat

Todos los módulos de hipergate están escritos en 100% Java Puro. El software puede correr en cualquier versión de la máquina virtual desde la 1.1.8 a la 1.5.

La versión 1.0 de hipergate ha sido testeada sobre Tomcat 3.1.1a con Java 1.3, Tomcat 4.1.27 con Java 1.4 y Tomcat 5.5 con Java 1.5.

La máquina que aloje el servidor web debe ser Linux, BSD, Solaris, AIX o Windows 2000.

Componentes utilizados bajo licencias Open Source Jakarta Bean Scripting Framework 2.3 Jakarta POI 2.5

Jakarta ORO 2.0.8

Xerces2 XML Java Parser 2.6.2

Xalan XSLT Processor 2.6.2

Enterprise DT Ltd Java FTP Library 1.2.2

Componentes utilizados bajo licencia de SUN Microsystems Inc. JavaBeansTM Activation Framework 1.0.2 JavaMailTM 1.3.2

JavaTM Advanced Imaging 1.1.2

Otros Componentes Infomentum AppletFile 3.0 (opcional) DipuTree Java tree applet 3.0 (opcional)

Sistemas Gestores de Base de Datos Relacional Soportados

Oracle 9i, 10g Microsoft SQL Server 2000

PostgreSQL 7.3, 7.4

Servidor de Aplicaciones

El la persistencia objetos en base de datos, el módulo de cache distribuido y el planificador de tareas pueden instalarse separados del servidor web sobre JBoss 3.0.

c. Estructura Interna

Diseño multi-capa

El código de hipergate está dividido en 5 capas:

Capa 1: Código JavaScript ejecutado por el navegador cliente.

Capa 2: Páginas JSP servidas por el servlet runner (Tomcat)

Capa 3: Modelo abstracto de objetos Java, puede ejecutarse dentro de Tomcat o de forma separada sobre JBoss.

Capa 4: Scripts Java BeanShell.

Capa 5: Procedimientos almacenados en el SGBDR.

Esta división persigue alcanzar el mejor grado de escalabilidad y extensibilidad de la aplicación, con los objetivos de:

1. Realizar el máximo de validaciones y procesamiento en cliente para reducir el tráfico entre el navegador y el servidor web.

2. Separar la capa de presentación de la persistencia de objetos.

3. Proporcionar un API para todos los objetos de la aplicación.

4. Utilizar el máximo de código compilado y optimizado para el núcleo de librerías del sistema.

5. Externalizar la lógica de negocio en scripts de servidor que no requieran ser recompilados para ejecutarse.

6. Reducir el número de llamadas a la base de datos en aquellas operaciones que puedan ejecutarse de forma atómica dentro del gestor de base de datos.

d. Servidor sin estados

hipergate no utiliza sesisones ni estados mantenidos en el servidor.

Esto es una medida destinada a reducir el consumo de memoria y aumentar la escalabilidad en el servidor web.

Toda la información se mantiene mediante cookies de sesión almacenadas en el cliente.

Estas cookies sólo contienen un mínimo de información:

dominio de seguridad al que se está conectado área de trabajo a la que se está conectado

identificador único de del usuario conectado

token de acceso de sesión encriptado

Como no hay sesiones, no existe el concepto de identificador de la sesión actual. Toda la información de estado se transfiere de una página a otra mediante métodos GET o POST de HTTP.

Caches

El sistema utiliza un cache distribuido que permite almacenar información de la base de datos de forma local en los servidores web. Esto reduce el tráfico de red y aligera la carga sobre la base de datos.

Un controlador de cache se encarga de mantener la coherencia de los datos en instalación con múltiples servidores web funcionando de forma concurrente contra la misma base de datos.

e. Separación de datos por clientes y departamentos

Muchas aplicaciones que funcionan en modalidad ASP lo hacen replicando automáticamente un modelo de datos para cada una de las instancias cliente. La ventaja de este enfoque es que permite separar fácil y limpiamente los datos de cada cliente El inconveniente es que se genera una proliferación de bases de datos clónicas prácticamente imposibles de mantener a partir de cierto volumen de instancias.

En hipergate se ha seguido una aproximación híbrida al problema de la separación de datos: una única base de datos puede contener información de múltiples entidades cliente sin solapamientos, incluso, yendo un paso más lejos, la división de datos y permisos de acceso puede llegar a nivel departamental, consiguiendo que las personas de un departamento tengan acceso a un conjunto de datos y aplicaciones diferente de los de otro departamento.

Sin embargo, para mantener el requisito indispensable de la separación de datos por cliente, las utilidades de administración disponen de subrutinas para cortar y separar la información de un cliente en una base de datos aislada de uso exclusivo, incluso aunque dicha información se encontrase previamente almacenada en una base de datos compartida.

Dominios

Conceptualmente, el Dominio de hipergate es la unidad de mayor nivel de división de datos. Típicamente representa una entidad cliente completa, aunque otro uso común es usarlo como contenedor de usuarios individuales no adscritos a ninguna entidad (por ejemplo, profesionales independientes que contratan una cuenta de uso personal).

El uso principal de los dominio es establecer los límites de asignación de permisos para cada administrador. Así el administrador de una entidad cliente, puede crear nuevos usuarios o activar y desactivar aplicaciones dentro de su dominio, pero no puede ver ni alterar los datos de otras entidades clientes en dominios diferentes.

Áreas de Trabajo

Cada Dominio puede contener una o más Áreas de Trabajo. Las áreas de trabajo forman los compartimentos estancos de información.

Las áreas de trabajo suelen representar departamentos funcionales en las entidades cliente.

En un momento dado cada usuario sólo ve la información de aquella área de trabajo a la que está conectado con un rol determinado.

Por ejemplo, un vendedor podría ser usuario del área de trabajo del departamento de ventas, y, al mismo tiempo invitado del área de trabajo del departamento de soporte técnico. Este vendedor podría crear nuevas fichas de clientes o generar oportunidades comerciales en el área de trabajo de ventas, pero su nivel de privilegio en el área de trabajo de soporte sólo le permitiría ver las incidencias abiertas pendientes de resolución, sin posibilidad de modificarlas.

f. Modelo de Seguridad

hipergate implementa un modelo de seguridad a nivel de sesión basado en roles. El modelo maneja los siguientes conceptos:

Aplicación El producto funciona como un conjunto de aplicaciones interoperables. Se pueden

añadir o quitar aplicaciones sin afectar al funcionamiento del resto del sistema. En un momento dado, cada usuario tiene disponible un subconjunto de todas las aplicaciones y ejerce un rol en cada una de ellas en función de los grupos de permisos a los que pertenezca.

UsuarioSe permite crear un número ilimitado de usuarios cada uno con su propio conjunto de roles y clave de acceso.

Rol Se dispone de cuatro roles predefinidos más un quinto definible por entidad cliente: administrador, superusuario, usuario, invitado y variable.

Estos roles marcan lo que el usuario puede hacer en cada aplicación. Así, un usuario podría tener rol de Administrador en el módulo del Directorio de Personal y Rol de Invitado en el módulo de ventas. Esto le permitiría crear nuevas fichas de empleados, pero no crear nuevos clientes.

Cuenta Una cuenta es lo mismo que un contrato de uso con un cliente final. Existen 3 tipos de cuenta predefinidas: la cuenta corporativa, la cuenta profesional y la cuenta de sistema.

Las cuentas corporativas permiten un número arbitrario de usuarios y están asociadas a su propio dominio.

Las cuentas profesionales representan usuarios individuales que no pueden hacer uso de las funcionalidades de trabajo en equipo de la aplicación.

Las cuentas del sistema se usan por los operadores del ISP que proporcionan el servicio como un medio de administrar todos los dominios contratados con clientes.

DominioUn dominio representa un conjunto de usuarios que se administran de forma independiente. Cada dominio tiene uno o más administradores.

Área de Trabajo Cada dominio contiene una o varias áreas de trabajo. El área de trabajo es una

entidad que sirve para establecer la visibilidad de conjuntos de datos en la aplicación. Por ejemplo, supongamos que la entidad cliente es una empresa con dos delegaciones, una en Madrid y otra en Barcelona. Se desea que la creación y gestión de usuario esté centralizada en Barcelona y que los usuarios de cada sede vean sólo la agenda y el directorio de su localidad. En este caso se crearía un dominio para la empresa y un área de trabajo para cada delegación.

Grupo Cada usuario pertenece a uno a más grupos. Es posible definir un número arbitrario de grupos. Los grupos en si mismos no otorgan roles a los usuarios. Es preciso asignar un rol al grupo dentro de una aplicación y área de trabajo para que los usuario adquieran el rol deseado.

Diagrama ilustrativo del modelo de seguridad

Manual de Instalación para la Versión 4.0

a. Para los impacientes...1. Es preciso tener pre-instalado

o Java 1.6 (o superior)

o Tomcat 6.0.16 (o superior)

o PostgreSQL 8.x, Microsoft SQL Server 2005/DE or Oracle 10g/XE o MySQL 5.x.

Un tamaño inicial de 30Mb para la base de datos es más que suficiente para tareas de desarrollo.

2. Descargar y descomprimir hipergate-4.0.x-aa.zip en cualquier parte. 3. Copiar todos los archivos del directorio /web o /web al servidor web.

4. Copiar el directorio /storage en cualquier sitio fuera del árbol del servidor web.

5. Abrir la página http:// servidor : puerto /admin/setup.htm para iniciar el asistente de instalación.

6. Configurar /WEB-INF/web.xml (se puede hacer más tarde pero hasta que no esté hecho no funcionará el módulo de disco virtual)

7. (Opcional) Si se ha instalado hipergate en un directorio que no es el raíz del

dominio utilizado modificar el valor de la variable config.BaseUrl en el archivo /fckeditor/js/fck_config.js

b. Planificar la instalación

La instalación de hipergate consiste, básicamente, en copiar las páginas JSP y los archivos .jar en el servidor web y lanzar el asistente de web de instalación.

Para que hipergate funcione es necesario haber pre-instalado (al menos) Java 1.4, un contenedor de servlets (ej. Tomcat) y un gestor de base de datos.

Es importante pesar de antemano dónde se ubicarán los siguientes archivos:

La base de datos, en una unidad con espacio suficiente. Los .jar, de forma que no colisionen con otros ya instalados (por defecto en

WEB-INF/lib).

Las páginas JSP de hipergate.

Los directorios /storage y /web/workareas, que es donde se almacenan los archivos manejados por hipergate que no residen en la base de datos./storage y /web/workareas son dos directorios que pueden crecer indefinidamente según se suban archivos a la aplicación. La diferencia esencial entre /storage y /web es que los archivos de /storage no necesitan ser visibles por HTTP (aunque en la instalación por defecto lo son) mientras que los de /web deben colgar de una URL bajo el servidor web.

c. RequisitosSistema Operativo Linux o Windows

Preferentemente Linux (cualquier distro), Solaris o AIX. Se puede utilizar BSD pero es imprescindible que la plataforma seleccionada tenga soporte para una máquina virtual de Java 1.4.

JRE 1.6 hipergate 4 ha sido probado con la versión 1.6 de Sun JDK en distintas plataformas.

Contenedor de servlets/JSP El desarrollo inicial de hipergate se ha realizado con Apache Tomcat 6.0.16, y ha sido probado en otros servidores como Sun Web Server, Pramati, BEA WebLogic e IBM WebSphere.

Base de datos relacional hipergate soporta de forma nativa PostgreSQL 7.4/8.0, Microsoft SQL Server 2000/2005/DE, Oracle 9/10g/XE y MySQL 5.x. No existe soporte para MySQL 4.x, puesto que se utilizan procedimientos almacenados no soportados por esta base de datos.

Existen una serie de requisitos por cada gestor de base de datos utilizado con hipergate:

PostgreSQL PostgreSQL debe estar atendiendo peticiones por TCP/IP.El lenguaje plpgsql debe estar instalado en la instancia de BB.DD. antes de cargar el juego de datos inicial. Para ello, hay que ejecutar la siguiente sentencia utilizando el usuario administrador de la base de datos: createlang plpgsql nombre_bbdd. Se puede comprobar si el lenguaje está cargado lanzando la siguiente sentencia SQL: select lanname from pg_language;La base de datos debe ser creada con juego de caracteres UNICODE, de lo contrario se producirá el error SQLException 42P01 ERROR: no existe la relación k_x_app_workarea. Oracle 9 Por defecto, Oracle admite un máximo de 50 cursores abiertos por conexión. Este parámetro es incompatible con el funcionamiento de la instalación, que deja un cursor preparado por tabla. Por consiguiente, antes de crear la base de datos hay que abrir el archivo de configuración de la instancia de BB.DD. (initXXXX.ora) y poner la opción: "open_cursors=100" (como mínimo). Oracle XE Oracle XE usa por defecto el mismo puerto de administración que Tomcat, el 8080, si se ejecutan ambas aplicaciones en la misma máquina hay que cambiar el puerto para alguna de las dos. Microsoft SQL Server Es necesario activar el protocolo TCP/IP en el servidor. Para ello usar el programa SQL Server Client Network Utility.También es necesario activar la seguridad nativa de SQL Server, con la seguridad integrada en Windows no es suficiente.En algunos casos puede ser necesario configurar el parámetro ARITHABORT de SQL Server para que la carga inicial de BB.DD. funcione. Para ello, hay que conectarse a la base de datos master desde SQL Query Analyzer y ejecutar la sentencia: ALTER DATABASE nombre_bbdd SET ARITHABORT ON. De lo contrario, aparecerá el siguiente error mientras se realiza la carga inicial: "[SQLServer 2005 Driver for JDBC][SQLServer]INSERT failed because the following SET options have incorrect settings: 'ARITHABORT'".

d. Contenidos del paquete de distribución

El paquete de hipergate se distribuye en formato ZIP, y contien los siguientes subdirectorios:

bin: Librería estándar de hipergate. java: Código fuente de la librería de hipergate.

web-XX: Juego de páginas JSP con una aplicación de ejemplo.

storage: Contenidos de ejemplo del directorio de almacenamiento privado.

doc: Documentación adicional, licencias y referencia del API de hipergate.

database: Volcados binarios de la base de datos de ejemplo.

A continuación se presenta un detalle de los contenidos de los directorios web y

storage:

Contenidos del directorio web

Contenidos del directorio storage

e. Instalar y configurar un sitio web de ejemplo

La primera decisión a tomar es donde se ubicarán las páginas JSP de la aplicación. Debe tener configurado un motor de servlets/JSP en el servidor. Tome nota de la configuración y URLs donde instala las JSP, puesto que las necesitará más adelante en el Asistente de Instalación.

Se recomienda instalar hipergate justo debajo de la raiz del dominio utilizado,

como: http://localhost:8080/Si se desea instalar hipergate en un directorio por debajo del raiz, hay que modificar el valor de la variable config.BaseUrl en el archivo /fckeditor/js/fck_config.js

Instalación sobre Tomcat 6.0

Puede instalar una copia de Apache Tomcat en el directorio /opt/tomcat/, y configurarla para que escuche peticiones a través de HTTP en el puerto 8080 (configuración por defecto). Compruebe la siguiente línea en su archivo $CATALINA_HOME/conf/server.xml:

<Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8080" ... />

Puede crear un nuevo <Context> para hipergate o utilizar uno existente. Por ejemplo, puede copiar toda la rama web del paquete ZIP de hipergate al directorio $CATALINA_HOME/webapps/hipergate y configurar un nuevo <Context> en el archivo server.xml de la siguiente forma:

<Server port="8005" shutdown="SHUTDOWN" debug="0"> <Service name="Tomcat-Standalone"> <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8080" minProcessors="5" maxProcessors="75" enableLookups="true" redirectPort="8443" acceptCount="100" debug="0" connectionTimeout="20000" useURIValidationHack="false" disableUploadTimeout="true" /> <Host name="localhost" debug="0" appBase="$CATALINA_HOME/webapps/hipergate" unpackWARs="true" autoDeploy="true"> <Context path="" docBase="" debug="0" reloadable="true" crossContext="true"> <Logger className="org.apache.catalina.logger.FileLogger" prefix="hipergate_log." suffix=".txt" timestamp="true"/> </Context> </Host> </Engine> </Service></Server>

Archivos con juego de caracteres Unicode Los archivos fuente JSP de hipergate utilizan el juego de caracteres Unicode codificado como UTF-8.Es necesario indicar a Tomcat que debe esperar archivos fuente Unicode estableciendo el parámetro -Dfile.encoding=UTF-8 en la variable de entorno CATALINA_OPTS.Si no se especifica el parámetro file.encoding, es posible que se produzca un error del estilo org.apache.jasper.compiler.CompileException:

/common/desktop.jsp Cannot read file: ze file al arrancar la aplicación.

Servlets

hipergate incluye tres servlets para la descarga de archivos desde el directorio privado storage. Para recoger archivos desde la BB.DD. es necesario configurar una serie de entradas en el fichero web/WEB-INF/web.xml instalado.

Para cada unos de los servlets (HttpBinaryServlet, HttpBLOBServlet y HttpQueryServlet) hay que configurar los siguientes parámetros:

jdbcDriverClassName Establece el driver de acceso a BB.DD., igual que el parámetro driver de hipergate.cnf

jdbcURL Establece la cadena de conexión a la BB.DD., igual que el parámetro dburl de hipergate.cnf

dbUserName/dbUserPassword Establece el usuario y contraseña de acceso a la BB.DD., igual que los parámetros dbuser/dbpassword de hipergate.cnf

Los parámetros de conexión a la base de datos para los servlets del paquete com.knowgate.http (HttpBinaryServlet, HttpBLOBServlet y HttpQueryServlet) pueden especificarse en el archivo de /WEB-INF/web.xml o en el archivo /etc/hipergate.cnf. La informacion de web.xml es prioritaria sobre la de hipergate.cnf de modo que si ambas difieren se tomará como válida la de web.xml.

Los parámetros de web.xml pueden dejarse vacíos si se tiene una única instancia de la aplicación corriendo en el mismo servidor, pero es imprescindible rellenarlos si se tienen varias instancias de la aplicación corriendo en el mismo servidor contra bases de datos diferentes. Si no se encuentran parámetros de conexión en web.xml el servlet irá a buscarlos a hipergate.cnf y no a otros archivos de configuración como real.cnf o portal.cnf.

Por último, compruebe que la URL http://hostname:8080/login.html funciona correctamenente.

f. Instalar las librerías

El segundo paso es instalar las páginas y las librerías de hipergate en un directorio donde el motor de servlets pueda referenciarlas.Si tiene dudas acerca de cómo crear una aplicación web en su motor de servlets lea una de las siguientes guías de instalación.Las librerías JAR se colocan por defecto en el directorio $CATALINA_HOME/webapps/hipergate/WEB-INF/lib.Normalmente, no hay necesida de cambiarlas de sitio.Añadir las librerías al CLASSPATH no es suficiente, ya que la mayoría de los contenedores de servlets utilizan su propia estructura de directorios y cargadores de clases para buscar las librerías JAR.Usually there is no need to change them to another place.Tomcat utiliza el directorio $CATALINA_HOME/shared/lib para los JARs compartidos por todas las aplicaciones web.

Puede mover las librerías a shared/lib si tiene problemas para cargarlas desde WEB-INF/lib.

g. Crear una base de datos vacíaOracle 10g

1. Abrir una conexión a Oracle con SQL*Plus, SQL*Worksheet o Server Manager y ejecutar las sentencias:

CREATE TABLESPACE HIPERGATE4 DATAFILE 'C:\oraclexe\oradata\XE\hipergate4.dbf' SIZE 100M;

CREATE USER HIPERGATE IDENTIFIED BY HIPERGATE DEFAULT TABLESPACE HIPERGATE4 QUOTA UNLIMITED ON HIPERGATE4 QUOTA 0 ON SYSTEM;

GRANT CONNECT,CREATE SEQUENCE,CREATE SYNONYM,CREATE PUBLIC SYNONYM,DROP PUBLIC SYNONYM,CREATE PROCEDURE,CREATE VIEW,CREATE TABLE, CREATE TRIGGER TO HIPERGATE;

Microsoft SQL Server 2005 1. Asegurarse de que el servidor está configurado para aceptar

autentificación nativa.Si no se activa la seguridad nativa se obtendrán el error "Not associated with a trusted SQL Server connection" al intentar la conexión con SQL Server.

2. Habilitar el soporte de conexiones por TCP/IP.

3. Crear una nueva base de datos desde Microsoft SQL Server Management Studio.

4. Abrir SQL Query Analyzer, conectarse a la BB.DD. master y ejecutar:

ALTER DATABASE hipergate4 SET ARITHABORT ON

Notas sobre Microsoft SQL Server Desktop Engine Aunque hipergate puede correr sobre MSDE, no se recomienda para entornos de producción.Sin embargo, MSDE es fácil de instalar y puede ser útil para hacer demos en Windows 2000/XP.He aquí como proceder:

Obtener MSDE Release A de http://www.microsoft.com/sql/msde/downloads/default.asp.

Leer el archivo README incluido en MSDE sobre cómo instalarlo teniendo en cuenta que MSDE no está pensado para ser instalado manualmente por un humano.

Siguiendo las instrucciones de la sección 3.4.3 del README, ejecutar: setup SAPWD="AStrongPassword" INSTANCENAME="InstanceName" TARGETDIR="C:\MyInstanceFolder" DISABLENETWORKPROTOCOLS=1 SECURITYMODE=SQL. SAPWD es la clave de super usuario de la base de datos, el nombre de la instacia podrías ser HGOLTP2D y el directorio destino C:\MSSQL. Los últimos dos parámetros habilitan el soporte TCP/IP y la autentificación dual SQL Server+Windows

MSDE no incluye herramientas administrativas, de modo que es preciso conectarse al servidor de alguna de las siguiente maneras para crear la base de datos vacía:

- Instalar las herramientas cliente de SQL Server Standard/Enterprise. Se necesita el Enterprise Manager Snap-in para Microsoft Management Console. Esta es la forma más fácil de administrar MSDE, pero no es gratis. - o usar una herramienta de consulta SQL como WinSQL- o si se dispone de IIS y el SDK de .NET es posible utilizar Web Data Administrator.- o (puramente experimental) quizá exista una utilidad de línea de comando para restaurar el archivo .BAK distribuido con hipergate a una nueva base de datos.Habiendo instalado todo esto, configurar hiperate.cnf para usar el SAPWD, 127.0.0.1 como host y puerto 1433. Es posible iniciar y parar el servicio MSSQLServer usando el Panel de Control de Windows o "NET STAART/STOP" desde la línea de comandos.

PostgreSQL 8.0 1. Conectar al servidor de BB.DD. a través de SSH/Telnet, usando el

usuario administrador de la BB.DD. (postgres), y crear una nueva BB.DD. y un usuario:

# createdb -E UNICODE hipergate4# createuser knowgate# grant all on database hipergate4 to knowgate

2. Configurar PostgreSQL para que atienda peticiones por TCP/IP estableciendo los siguientes parámetros en el archivo postgresql.conf

tcpip_socket = truevirtual_host = '127.0.0.1'port = 5432

3. Activar el lenguaje PL/pgSQL. El PL/pgSQL debe estar activado antes de ejecutar el asistente de instalación o de cargar el modelo de datos manualmente. Si no se activa el PL/pgSQL antes de crear el modelo de datos, se producirá un error en la función k_sp_authenticate al intentar conectarse por primera vez y será necesario volver a crear el modelo de datos desde cero.

# createlang plpgsql hipergate4

4. Si se encuentran problemas de permisos accediendo al lenguaje c, hacer:

# update pq_language set lanpltrusted=true where lanname='c';# grant usage on language c to knowgate;

MySQL 5.x 1. Conectarse al servidor como root y ejecutar:

CREATE DATABASE hipergate4 CHARACTER SET utf8;CREATE USER knowgate IDENTIFIED BY 'knowgate';GRANT ALL PRIVILEGES ON *.* TO 'knowgate'@'%' IDENTIFIED BY 'knowgate';

Nótese que la base de datos debe estar creada con juego de caracteres UTF-8 y que no es suficiente con hacer un GRANT ALL PRIVILEGES ON knowgate.* ya que esto no otorga el privilegio

de SUPER que es requerido durante el proceso de creación inicial del modelo de datos para crear triggers.

h. Ejecutar el Asistente de Instalación

Para iniciar hipergate básicamente existen tres requisitos:

1. Tener las librerías (JARs) necesarios en su sitio (por defecto ya lo están en WEB-INF/lib).

2. Configurar las propiedades del archivo hipergate.cnf para inidicar a la aplicación a qué base de datos debe conectarse. hipergate.cnf se crea por defecto en el directorio /etc (o C:\WINNT en Windows) pero su ubicación puede cambiarse asignando el nombre del directorio donde se encuentre a la variable de entorno KNOWGATE_PROFILES

3. Tener creado el modelo de datos

El Asistente de Instalación que se encuentra en http:// servidor : puerto /admin/setup.htm Una vez finalizada su ejecución el asistente de instalación salta automáticamente a la pantalla de inicio de sesión de la aplicación.

i. Configuración de Seguridad y Áreas de Trabajo

Para crear nuevos Dominio, Áreas de Trabajo y Usuarios lea el Manual de Usuario. Se recomienda proteger el directorio /admin con autentificación básica del servidor web una vez finalizada la instalación inicial.

Es preciso dar permisos de escritura al usuario que ejecute el servidor web sobre el directorio /tmp o /C:\TEMP o cualquier otro que se designe como directorio temporal en el archivo hipergate.cnf.

j. Pruebas adicionales de conexión y acceso

Una vez cargada la base de datos, acceda a la siguiente URL: http://myserver/admin/test_connect.jsp?profile=hipergate. Si todo funcionó correctamente, aparecerá una pantalla con el driver y cadena de conexión JDCB y un mensaje de éxito.

Puede acceder a la aplicación de ejemplo a través de la URL: http://myserver/login.html. El sistema de carga de base de datos genera una serie de usuarios y contraseñas por defecto.

hipergate tiene dos dominios reservados con 5 usuarios que deben conservarse, aunque se recomienda cambiar su contraseña por defecto.

administrator@hipergate-system.com (password hipergate) Cuenta de administrador del sistema completo de hipergate. Gestiona los dominios, areas de trabajo y usuarios que pueden acceder a la aplicación a

nivel global. administrator@hipergate-model.com (password model, en minúsculas)

Cuenta de administrador del dominio modelo de la base de datos. Se utiliza para generar copias clónicas de los dominios.

superuser@hipergate-model.com (password model, en minúsculas) Cuenta de usuario avanzado del dominio modelo de la base de datos. Se utiliza para generar copias clónicas de los dominios.

user@hipergate-model.com (password model, en minúsculas) Cuenta de usuario ordinario del dominio modelo de la base de datos. Se utiliza para generar copias clónicas de los dominios.

guest@hipergate-model.com (password model, en minúsculas) Cuenta de usuario invitado del dominio modelo de la base de datos. Se utiliza para generar copias clónicas de los dominios. Este usuario no tiene permisos de escritura en la aplicación.

Adicionalmente, el proceso de instalación genera tres dominios de pruebas para que los usuarios puedan empezar a trabajar con la aplicación directamente. Cada dominio (test, demo y real) se puede emplear en los procesos de prueba, aceptación y producción de cambios en la aplicación.

[administrator|superuser|user|guest]@hipergate-test.com (password TEST, en mayúsculas)

[administrator|superuser|user|guest]@hipergate-demo.com (password DEMO, en mayúsculas)

[administrator|superuser|user|guest]@hipergate-real.com (password REAL, en mayúsculas)

k. Configuración de servlets

Tras ejecutar el Asistente de Instalación, es conveniente revisar el contenido del archivo /WEB-INF/web.xml para configurar los parámetros de los servlets del paquete com.knowgate.http.Deben estar creados los servlets: HttpBinaryServlet, HttpBlobServlet y HttpQueryServlet.Para ello agregar las siguientes líneas al archivo web.xml:

<servlet> <servlet-name>HttpBinaryServlet</servlet-name> <servlet-class>com.knowgate.http.HttpBinaryServlet</servlet-class>

<init-param> <param-name>jdbcDriverClassName</param-name> <param-value></param-value> </init-param> <init-param> <param-name>jdbcURL</param-name> <param-value></param-value> </init-param> <init-param> <param-name>dbUserName</param-name> <param-value></param-value>

</init-param> <init-param> <param-name>dbUserPassword</param-name> <param-value></param-value> </init-param> <init-param> <param-name>id_product</param-name> <param-value></param-value> </init-param>

<init-param> <param-name>id_location</param-name> <param-value></param-value> </init-param>

<init-param> <param-name>id_category</param-name> <param-value></param-value> </init-param>

<init-param> <param-name>id_user</param-name> <param-value></param-value> </init-param> </servlet>

<servlet> <servlet-name>HttpBLOBServlet</servlet-name> <servlet-class>com.knowgate.http.HttpBLOBServlet</servlet-class>

<init-param> <param-name>jdbcDriverClassName</param-name> <param-value></param-value> </init-param> <init-param> <param-name>jdbcURL</param-name> <param-value></param-value> </init-param> <init-param> <param-name>dbUserName</param-name> <param-value></param-value> </init-param> <init-param> <param-name>dbUserPassword</param-name> <param-value></param-value> </init-param> <init-param> <param-name>nm_table</param-name> <param-value></param-value> </init-param> <init-param> <param-name>nm_field</param-name> <param-value></param-value>

</init-param> <init-param> <param-name>pk_field</param-name> <param-value></param-value> </init-param> <init-param> <param-name>pk_value</param-name> <param-value></param-value> </init-param> <init-param> <param-name>bin_field</param-name> <param-value></param-value> </init-param> </servlet>

<servlet> <servlet-name>HttpQueryServlet</servlet-name> <servlet-class>com.knowgate.http.HttpQueryServlet</servlet-class>

<init-param> <param-name>jdbcDriverClassName</param-name> <param-value></param-value> </init-param> <init-param> <param-name>jdbcURL</param-name> <param-value></param-value> </init-param> <init-param> <param-name>dbUserName</param-name> <param-value></param-value> </init-param> <init-param> <param-name>dbUserPassword</param-name> <param-value></param-value> </init-param> <init-param> <param-name>queryspec</param-name> <param-value></param-value> </init-param> <init-param> <param-name>columnlist</param-name> <param-value>*</param-value> </init-param> <init-param> <param-name>where</param-name> <param-value></param-value> </init-param> <init-param> <param-name>orderby</param-name> <param-value></param-value> </init-param> <init-param> <param-name>showas</param-name>

<param-value>XLS</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>HttpBinaryServlet</servlet-name> <url-pattern>/servlet/HttpBinaryServlet</url-pattern> </servlet-mapping>

<servlet-mapping> <servlet-name>HttpBLOBServlet </servlet-name> <url-pattern>/servlet/HttpBLOBServlet</url-pattern> </servlet-mapping>

<servlet-mapping> <servlet-name>HttpQueryServlet</servlet-name> <url-pattern>/servlet/HttpQueryServlet</url-pattern> </servlet-mapping>

Configuración de múltiples instancias de hipergate en la misma máquina

Todos los parámetros por defecto de los servlets pueden dejarse en blanco excepto si se utilizan varias instancias de hipergate en la misma máquina, en cuyo caso es preciso especificar valores pordefecto de la siguiente forma:

jdbcDriverClassNameNombre de la clase Java del driver JDBC {org.postgresql.Driver | oracle.jdbc.driver.OracleDriver | com.microsoft.jdbc.sqlserver.SQLServerDriver}

jdbcURL URL de acceso a la base de datos (igual que la propiedad dburl del archivo cnf correspondiente)

dbUserName Usuario de base de datos (igual que la propiedad dbuser del archivo cnf correspondiente)

dbUserPassword Clave del Usuario (igual que la propiedad dbpassword del archivo cnf correspondiente)

l. Múltiples instancias de hipergate en el mismo servidor

Es posible utilizar varias instancias de hipergate corriendo contra diferentes bases de datos en el mismo servidor.Cada instancia requiere el uso de un archivo de propiedades propio igual que hipergate.cnf pero con nombre distinto.Todos los archivos de propiedades para todas las instancias deben colocarse en el mismo directorio, por defecto /etc o C:\WINNT o el que se especifique en la variable de entorno KNOWGATE_PROFILES.La versión pública de hipergate viene preparada para trabajar con 5 archivos de propiedades adicionales además de hipergate.cnf:demo.cnf, devel.cnf, portal.cnf, real.cnf y test.cnf.Para usar un archivo de propiedades diferente de hipergate.cnf hay que editar include de JSP situado en /web/methods/dbbind.jsp.Se debe reemplazar la clase com.knowgate.dataobjs.DBBind en dbbind.jsp por la

subclase apropiada para cada archivo de propiedades:

demo.cnf com.knowgate.dataobjs.DBDemodevel.cnf com.knowgate.dataobjs.DBDevelportal.cnf com.knowgate.dataobjs.DBPortalreal.cnf com.knowgate.dataobjs.DBRealtest.cnf com.knowgate.dataobjs.DBTest

Por consiguiente para utilizar el archivo de propiedades test.cnf el contenido de dbbind.jsp debe ser:<jsp:useBean id="GlobalDBBind" scope="application" class="com.knowgate.dataobjs.DBTest"/>

m. Incompatibilidades conocidas

Versión 4.0

El driver de PostgreSQL que se suministra con la build sólo sirve para la versión 8.3

El driver de Oracle que se suministra con la build sólo sirve para la versión 11g

El driver de SQL Server que se suministra con la build sólo sirve para el Service Pack 2 de SQL Server 2005

hipergate 4 no funciona con Microsoft SQL Server 7.0, aunque no es muy difícil modificarla para que funcione

hipergate 4 no funciona con versiones de MySQL anteriores a la 5.0 y no puede modificarse fácilemnte para que funcione

hipergate 4 no funciona con Oracle 8.

Java BeanShell 2.0b1 no es compatible con JBOSS 4.0. BeanShell se utiliza durante el proceso inicial de creación de la base de datos con ModelManager. Se puede usar hipergate con JBoss si se carga el modelo de datos con alguna de las exportaciones binarias.

n. Descargas Adicionales Drivers JDBC para PostgreSQL MySQL Connector/J 5.0

Drivers JDBC para Oracle

Oracle Instant Client

Microsoft SQL Server 2000 JDBC Driver SP3

Microsoft SQL Server 2005 JDBC Driver 1.1

o. Herramientas de Administración

Consulta SQL

Existe una herramienta de consulta directa por SQL contra la base de datos en /admin/sql.htm.Permite lanzar uno o varios comandos SQL con el delimitador seleccionado por el susuario y recoger el conjunto de resultados de una consulta.Esta utilidad se conecta por defecto siempre contra la base de datos especificada en hipergate.cnf y no en otros archivos de propiedades, de modo que tenga mucho cuidado en su uso cuando maneje varias instancias diferentes de hipergate en el mismo servidor ya que podría conectarse a la instancia equivocada.Se recomienda deshabilitar cualquer acceso a esta herramienta por parte de los usuarios finales.

Estado del pool de conexiones

Puede consultarse llamando a la página /admin/connectionpool.jsp

Valor de las variables de entorno

Pueden inspeccionarse llamando a la página /admin/environment.jsp

Valor de las cookies de sesión

Pueden leerse llamando a la página /admin/viewcookies.html

p. Instalación sobre JBossContribuido por Nam Tu nguyen

Usar el archivo etiquetado hipergate-xx-war.zip en vez de hipergate-xx-src.zip

Crear el modelo de datos usando un volcado binario en lugar de utilizando el Asistente de Instalación. Java BeanShell (necesario para ejecutar el asistente) no funciona bien sobre JBoss 4.0.

Configurar manualmente hipergate.cnf

Copiar los drivers JDBC y la librería hipergate-x.x.xx.jar a %JBOSS_HOME%/server/default/lib/

Crear una conexión para JBoss en %JBOSS_HOME%/server/default/deploy/

Hacer una copia de hsql-ds.xml for para la base de datos que se vaya a utilizar. Por ejemplo si es PostgreSQL podría ser postgre-ds.xml como:

<local-tx-datasource> <jndi-name>KnowgateDS</jndi-name> <connection-

url>jdbc:postgresql://127.0.0.1:5432/hgoltp8t</connection-url>

<!-- Clase del driver --> <driver-class>org.postgresql.Driver</driver-class> <!-- Usuario y Contraseña --> <user-name>knowgate</user-name> <password>knowgate</password> <security-domain>PostgreSqlDbRealm</security-domain> <metadata> <type-mapping>Postgre SQL</type-mapping> </metadata> </local-tx-datasource>

No se requiere un servicio, mbean, ni nada; tan sólo hay que modificar /default/conf/login-config.xml.

Copy hiperweb.war to /server/default/deploy Abrir http://localhost/hiperweb/

q. Apéndice 1: Propiedades de hipergate.cnf

El archivo hipergate.cnf contiene la siguiente información (NOTA, las variables $CATALINA_HOME no son válidas en este fichero, se utilizan por claridad):

# [Base de Datos]# Parámetros de conexión a la base de datosdriver=org.postgresql.Driverdburl=jdbc:postgresql://192.168.1.30:5432/testschema=dbuser=postgresdbpassword=postgres

# [Pool de conexiones] # Parámeteros que gobiernan el comportamiento del pool de conexiones de hipergatepoolsize=32maxconnections=100logintimeout=20connectiontimeout=60000connectionreaperdelay=30000

# [Acceso a Ficheros]# Directorio para archivos temporalestemp=/tmp

# Acceso a ficheros por parte del servidor# Modo de acceso a ficheros (PUREJAVA=0, UNIX=1, WINDOWS = 2)javamode=0

# URL raíz de la aplicación webwebserver=http://hostname:8080# URL raíz al servidor de imágenes opcionalimageserver=http://hostname:8080/images

# Protocolo, host, usuario y contraseña de acceso a los siguientes recursosfileprotocol=file://fileserver=localhostfileuser=filepassword=

# Directorio raíz de almacenamiento privadostorage=$CATALINA_HOME/webapps/storage

# Directorio para almacenar tareas de borradoshelldir=/tmp

# Directorio raíz de almacenamiento públicoworkareasput=$CATALINA_HOME/webapps/hipergate/workareas# URL raíz de almacenamiento públicoworkareasget=http://hostname:8080/workareas

# Tamaño máximo de fichero (bytes)maxfileupload=10485760

# [Miscelánea]# ¿Realizar validación XML de documentos?setXMLValidation=1

# Número de hilos del planificador de tareasmaxschedulerthreads=1

# [WebMail]# Poner los nombres de los protocolos en minúsculasmail.transport.protocol=smtpmail.store.protocol=pop3mail.incoming=pop3.yourserver.commail.outgoing=smtp.yourserver.commail.user=

# LDAPldapconnect=ldap://127.0.0.1:389/dc=hipergate,dc=orgldapuser=cn=Manager,dc=hipergate,dc=orgldappassword=managerldapclass=com.knowgate.ldap.LDAPNovell

A continuación se describe cada uno de los parámetros y su función

driver Nombre del driver JDBC, según se utilizaría en la función Class.forName:

org.postgresql.Driver (PostgreSQL) com.mysql.jdbc.Driver (MySQL)

oracle.jdbc.driver.OracleDriver (Oracle)

com.microsoft.jdbc.sqlserver.SQLServerDriver (SQL

Server 2000)

com.microsoft.sqlserver.jdbc.SQLServerDriver (SQL Server 2005)

dburl Cadena de conexión JDBC a la base de datos:

jdbc:postgresql://host_name:5432/nombre_bbdd (PostgreSQL)

jdbc:mysql://host_name/nombre_bbdd (MySQL)

jdbc:oracle:thin:@nombre_host:1521:oracle_sid (Oracle)

jdbc:microsoft:sqlserver://nombre_host:1433;SelectMethod=cursor;DatabaseName=nombre_bbdd (SQL Server 2000)

jdbc:sqlserver://nombre_host:1433;SelectMethod=cursor;DatabaseName=nombre_bbdd (SQL Server 2005)

La cadena de conexión contiene siempre al menos el nombre o direcció IP del servidor (host) el puerto y el nombre de la base de datos. Si el servidor web y la base de datos están en la misma máquina el host es "127.0.0.1" o "localhost".

schema Esquema de la base de datos. Puede ser el usuario propietario de las tablas.En PostgreSQL dejar este parámetro en blanco excepto si se experimentan problemas de acceso a la tabla sql_features en cuyo caso la propiedad schema debe ser public. Dejar en blanco también para MySQL.

dbo (SQL Server) HIPERGATE (Oracle)

public (PostgreSQL)

dbuser/dbpassword Usuario y contraseña de conexión a la BB.DD. via JDBC.

poolsize Número de conexiones que permanecerán abiertas en el pool en espera de ser utilizadas. Una conexión sólo puede permanecer en el pool sin ser utilizada por un máximo de 5 minutos. Tras este periodo de inactividad todas las conexiones no usadas se cierran y el tamaño del pool se reduce eventualmente a cero. El valor por defecto para este parámetro es 32.Si este parámetro se pone a cero, se deshabilita el pool y cada conexión se obtiene llamando directamente al método java.sql.DriverManager.getConnection().

maxconnections Número máximo absoluto de de conexiones que se pueden abrir contra la base de datos.

logintimeout Tiempo máximo de espera, en segundos, para obtener una conexión a la base de datos.El valor por defecto es 20.

temp Directorio temporal para la aplicación. En él se almacenan los archivos de subida (upload) y algunos archivos de generación temporal.

/tmp (Linux)

C:\\TEMP (Windows)

javamode Modo de trabajo con el sistema de ficheros del servidor. El modo 0 (PUREJAVA) accede al sistema de archivos a través del API de Java (java.io). Los modos 1 y 2 (UNIX y WINDOWS) utilizan comandos del sistema para realizar las mismas acciones. Mientras que el modo PUREJAVA mantiene la compatibilidad entre plataformas, los modos nativos proporcionan un acceso a ficheros mucho más eficaz.

En WebLogic bajo Windows se debe utilizar el modo PUREJAVA. webserver

URL completa a la raíz de la aplicación web. Se utiliza para componer las URLs relativas y absolutas a cada módulo de la aplicación.

http://server:port/webapp http://myserver:8080/

http://localhost:7001/hipergateWeb (ejemplo con WebLogic)

imageserver URL al servidor de imágenes opcional. Todas las imágenes estáticas de la aplicación (pantallas, iconos, etc) pueden ubicarse en un servidor separado, o dejarse en un subdirectorio dentro del mismo servidor.

http://images.mycompany.com/hipergate http://myserver:8080/images

http://localhost:7001/hipergateWeb/images (ejemplo con WebLogic)

fileprotocol hipergate puede acceder a los ficheros almacenados de distinas maneras: por FTP, NFS o directorios montados directamente en el servidor. En este parámetro se establece el protocolo de acceso al repositorio de ficheros.

file:// (ficheros locales) ftp:// (acceso por FTP)

nfs:// (acceso por NFS, no soportado)

fileserver Nombre del servidor que contiene el repositorio de ficheros. Esta opción solo es útil cuando el protocolo de acceso fileprotocol es distinto de file://.

localhost (ficheros locales) ftp-server.domain.com (acceso por FTP)

fileuser/filepassword Nombre de usuario y contraseña utilizados para el acceso a repositorios remotos. Actualmente solo se utiliza para acceso por FTP.

storage Directorio raíz de almacenamiento privado de usuarios, plantillas y scripts de ejecución SQL (QBF).

$CATALINA_HOME/webapps/storage /vol/1/hipergate_storage

C:\\bea\\weblogic81\\samples\\workshop\\hipergate\\storage (Windows 2000)

shelldir Algunos contenedores de servlets (sobre todo Tomcat) bloquean ficheros y directorios. Si desea eliminar una newsletter, website o cuenta de acceso hay que borrar todos los directorios relacionados con este objecto, pero Java impide este borrado y por tanto hay que crear una tarea que borre los directorios desde fuera del contendor de servlets. Para cada elemento a borrar, se añade una linea al fichero cleanup.txt con la ruta completa al directorio a borrar. Se puede crear un script que lea este fichero y borre cada directorio y añadirlo como una tarea programada (cronjob) o ejecutarlo cada vez que se rearranca el servicio.

/tmp $CATALINA_HOME/webapps/shell

C:\\BEA\\weblogic81\\samples\\workshop\\hipergate\\shell (Windows 2000)

workareasput Directorio raíz de almacenamiento público, visible a través de web. Puede estar dentro de la raíz del servidor web, o bien en otro directorio.

$CATALINA_HOME/webapps/hipergate/workareas /vol/1/hipergate_workareas

C:\\BEA\\weblogic81\\samples\\workshop\\hipergate\\hipergateWeb\\workareas (Windows 2000)

workareasget URL absoluta para acceder al directorio workareasput.

/workareas /hipergateWeb/workareas

maxfileupload Tamaño máximo (en bytes) de fichero que se permite subir a la aplicación

setXMLValidation Activar las trazas de validación de XML al fusionar las plantillas XSLT de los módulos webbuilder y mailings.

maxschedulerthreads Número máximo de hilos (threads) que arranca el planificador de ejecución.

mail.transport.protocol Transporte que se utilizará para enviar mensajes de correo electrónico (por defecto smtp)

mail.store.protocol Protocolo de almacenamiento de correo electrónico (por defecto pop3)

mail.incoming Servidor de recepción de correo POP3 (por defecto localhost)

mail.outgoing Servidor de envío de correo SMTP (por defecto localhost)

r. Apéndice 2: Carga manual de la base de datos

Creación de la base de datos con volcados binarios

En vez de utilizar el Asistente de Instalación es posible configurar el archivo hipergate.cnf manualmente e importar los volcados binarios del modelo de datos que hay en el directorio database/ de la distribución.

Oracle 10g/XE

1. Escribir la siguiente sentencia desde la línea de comandos:

IMP system/manager fromuser=HIPERGATE touser=HIPERGATE buffer=128000 commit=yes ignore=yes file=h4orclxe.dmp

Microsoft SQL Server 2005 1. Copiar h4mssql2005.bak a una unidad de disco local. 2. Hacer click con el botón derecho sobre la nueva BB.DD.,

seleccionar All Tasks -> Restore Database, seleccionar "From Device", añadir h4mssql2005.bak a la lista de dispositivos y hacer click en OK.

PostgreSQL 8.x 1. Crear una base de datos Unicode:

# createdb -E UNICODE hipergate4

Crear un nuevo usuario:

# createuser knowgate# grant all on database hipergate4 to knowgate

2. Restaurar la BB.DD. desde el fichero H3PGSQL8.DUMP:

# pg_restore -d hipergate4 h4pgsql83.backup

Si se encuentran problemas de permisos accediendo al lenguaje c, hacer:

# update pq_language set lanpltrusted=true where lanname='c';# grant usage on language c to knowgate;

Creación de la base de datos con la clase Java ModelManager

Para utilizar una base de datos primero debe comprobar que dispone del driver JDBC correspondiente y que lo ha configurado en el fichero hipergate.cnf.

La base de datos utilizada en el parámetro dburl debe estar creada y vacía antes de ser cargada. El proceso de carga de base de datos de hipergate utilizará los parámetros de conexión, usuario y contraseña disponibles en el fichero de configuración.

Para cargar la base de datos con el modelo básico de trabajo y un juego de datos de ejemplo, ejecute el siguiente comando (respetando mayúsculas y minúsculas):

java [-cp ...] com.knowgate.hipergate.datamodel.ModelManager /etc/hipergate.cnf create database

NOTA: Será necesario que en su variable de entorno CLASSPATH se encuentren

todas las librerías incluidas en la distribución de hipergate.El conjunto mínimo de librerías de las incluidas en la distribución para que funcione ModelManager es: beanshell.bsh-2.0b1.jar, ibm.bsf-2.2.jar, jakarta-oro-2.0.8.jar, xmlParserAPIs.jar, xercesImpl.jar. También hay que incluir el driver JDBC apropiado.

El siguiente script puede facilitar esta tarea. Cada vez que se ejecuta, busca todos los paquetes JAR en /opt/tomcat/webapps/hipergate/WEB-INF/lib/ y los añade al CLASSPATH (-cp) del comando java que se ejecuta al final:

#!/bin/sh

cp=`ls -1 /opt/tomcat/webapps/hipergate/WEB-INF/lib/*.jar | tr '\n' ':'`java -cp "$cp" com.knowgate.hipergate.datamodel.ModelManager $@

Puede guardar el anterior script en /usr/local/bin/modelmanager.sh, y ejecutar la sentencia modelmanager.sh create database.

s. Apéndice 3: Configuración de granjas de servidores

Introducción

hipergate puede funcionar instalado en granjas de servidores.

Cuando la aplicación funciona sobre varias máquinas en paralelo, es necesario habilitar el Coodinador de Cache Distribuido.

Cada servidor web de hipergate mantiene un cache local de información de acceso frecuente: claves de usuuente: claves de usuario, valores de remonte, opciones de menú, etc.

Si se ponen varios servidores web en pararelo existe la posibilidad de que uno de los servidores actualice en la base de datos información que está locamente cacheada en otro. Por este motivo es necesario instalar un coordinador de caches locales.

El coordinador en si mismo no almacena ninguna información, sino simplemente otorga tickets con fechas de caducidad a los caches locales para coordinarlos entre ellos. No es posible pasar información de un cache local a otro. Cuando se actualiza la información en un nodo, se marca como inválida para todos los demás y el resto deben re-cargarla de la base de datos.

El coordinador de cache se divide en dos partes: cliente y servidor.

La parte cliente está en el paquete com.knowgate.cache en hipergate.jar y es independiente del servidor que se utilice.

La parte servidor puede, a su vez, ser de dos tipos: HTTP o EJB.

Un coordinador HTTP utiliza uno de los servidores web en la granja para coordinar

al resto. Esta es la configuraci&oacut

Un coordinador EJB utiliza un servidor de aplicaciones como JBoss o WebLogic como servidor de tickets para los servidores web cliente.

Configuración del coordinador sobre un servidor HTTP

Cualquierna de los nodos en una granja de servidores hipergate puede actuar como coordinador del resto. Sólo puede haber un coordinador, si el coordinador cae, el resto de los nodos dejarán de funcionar.

Para habilitar el coordinador, abrir el archivo de propiedades appserver.cnf de cada nodo y poner:

threetiers=enabledjava.naming.provider.url=http://DIRECCION_IP:PUERTO/cache/server.jsp

Configuración del coordinador sobre un servidor EJB

La instalación del coordinador sobre un contenedor de EJBs es más compleja que directamente sobre un servidor web aunque también proporciona mejor rendimiento, escalabilidad y tolerancia a fallos.

Parte Cliente (servidores web)

Para utilizar JBoss es preciso instalar librerías adicionales en cada uno de los clientes

cachecoordinator-jboss30.jar apache.log4j.jar

jboss-3.0.common-client.jar

jboss-3.0.jnp-client.jar

sun.jndi.jar

Parte Servidor (JBoss)

En el archivo standardjboss.xml añadir:

<container-configuration><container-name>Singleton Stateless

SessionBean</container-name><call-logging>false</call-logging>

<container-invoker>org.jboss.proxy.ejb.ProxyFactory</container-invoker>

<container-interceptors>

<interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor>

<interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor>

<!-- BMT --><interceptor transaction = "Bean">

org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor</interceptor><interceptor transaction = "Bean"> org.jboss.ejb.plugins.TxInterceptorBMT</interceptor><interceptor transaction = "Bean" metricsEnabled

= "true"> org.jboss.ejb.plugins.MetricsInterceptor</interceptor><interceptor>

org.jboss.resource.connectionmanager.CachedConnectionInterceptor

</interceptor></container-interceptors><client-interceptors><home>

<interceptor>org.jboss.proxy.ejb.HomeInterceptor</interceptor>

<interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>

<interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>

<interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>

</home><bean>

<interceptor>org.jboss.proxy.ejb.StatelessSessionInterceptor</interceptor>

<interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>

<interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>

<interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>

</bean></client-interceptors><instance-

pool>org.jboss.ejb.plugins.StatelessSessionInstancePool</instance-pool>

<instance-cache/><persistence-manager/><transaction-manager/><container-pool-conf>

<MaximumSize>1</MaximumSize><MinimumSize>1</MinimumSize><strictMaximumSize>true</strictMaximumSize>

</container-pool-conf></container-configuration>

Arrancar JBoss y desplegar el archivo cachecoordinator-jboss30.jar. Para ello:

Copiar el JAR al directorio jboss/server/all/deploy, jboss/server/default/deploy o jboss/server/minimal/deploy

Abrir la consola de administración de JBoss (http://servidor:8080/jmx-console/

seleccionar el menú "MainDeployer" para desplegar el archivo cachecoordinator-jboss30.jar (ej. file://C:\jboss\server\all\deploy\cachecoordinator-jboss30.jar)

t. Apéndice 4: Librerías de tercerosJ2EE Client - 3.0

Contiene clases J2EE necesarias para el cache distribuido de hipergate

Xerces2 Java Parser 2.9.0 Parser XML de la Fundación Apache

Bean Scripting Framework - 2.4.0 Un conjunto de clases Java que proporcionan un lenguaje de scripting dentro de aplicaciones Java.

Jakarta POI - Java API To Access Microsoft Format Files - 2.5 Acceso a ficheros basados en el formato de Documento OLE 2 de Microsoft desde Java.

Jakarta Lucene - 1.4 Jakarta Lucene es un motor de indexación de alto rendimiento escrito en Java.

Java BeanShell - 2.0b4 BeanShell es un intérprete de código fuente de Java con características de scripting, escrito en Java.

Jakarta ORO 2.0.8 (sólo a partir de la versión 2.0) El proyecto OROMatcher fue cedido a The Apache Software Foundation y ahora es Jakarta ORO.

Sun JavaMail - 1.4.0 El API de JavaMail proporciona un conjunto de clases para el acceso a un sistema de correo.

Sun Java Advanced Imaging API - 1.1.3 Las librerías JAI de SUN proporcionan acceso a tratamiento de

imágenes en el lado del servidor sin emplear AWT Novell LDAP classes for Java(sólo a partir de la versión 2.0)

Las librerías LDAP de SUN proporicionan acceso a Novell eDirectory™, OpenLDAP u otros directorios basados en LDAP.

Sun JSR-168 Portlet API 1.0 (sólo desde la versión 2.1) JiBX XML binding 1.1.5

JiBX es un entorno de trabajo para manipular archivos XML usando objetos Java isomorfos.

u. Apéndice 5: Librerías de DepuraciónLa versión estándar de hipergate se distribuye con una librería de depuración llamada hipergate-debug.jar.Esta librería vuelca trazas detalladas de ejecución en el archivo /tmp/javatrc.txt (o C:\javatrc.txt en Windows).No se debe utilizar la versión de depuración en sistemas de producción final ya que pueden degradar el rendimiento o llenar el disco.

v. Apéndice 6: Notas para recompilar los fuentescom.oreilly.servlet.CacheHttpServlet: Cannot resolve symbol method getContentType() Para solucionar este error incluir la librería /lib/compile/servlet.jar al compilar el proyecto.

org.jibx.runtime.JiBXException: Unable to access binding information for class com.knowgate.hipergate.Menu Para solucionar este error hay que ejecutar el post-compilador de JiBX tras compilar normalmente el proyecto ejecutando: C:\JRE\bin\java -cp C:\JAR\bcel.jar;C:\JAR\jibx-bind-1.1.5.jar;C:\JAR\jibx-extras.jar;C:\JAR\xpp3.jar org.jibx.binding.Compile C:\knowgate\storage\xslt\schemas\menu-def-jixb.xml

w. Actualización desde la versión 3.0 a la 4.0

Para actualizar la versión 2.1 a la 3.0 efectuar los siguientes pasos : 1. Hacer una copia de respaldo de la base de datos y de las páginas JSP de la

3.0. 2. Descargar el archivo ZIP comprimido de la 3.0.

3. Instalar las páginsa JSP de la 3.0 en una nueva ubicación en el servidor web.

4. Cambiar todas las librerías del /WEB-INF/lib de la 3.0 por las de la 4.0 (excepto el driver JDBC que se esté usando).

5. El archivo hipergate.jar ya no viene dentro del directorio /WEB-INF/lib como en la 2.1, sino descomprimido en el directorio /WEB-INF/classes de la 3.0.

6. Apuntar la instancia de 3.0 a la misma base de datos de la 2.1 reutilizando el hipergate.cnf que ya existiese.

7. Abrir el asistente de instalación en http:// servidor /admin/setup.htm . El asistente detectará automáticamente la versión anterior y actualizará convenientemente el modelo de datos.

Actualización manual alternativa

Los scripts para alterar un modelo de datos de versión 2.1 y actualizarlo a la 3.0 se encuentran en /java/com/knowgate/hipergate/datamodel/updgrade/Hay que ejecutar el archivo 210-300.ddl para la base de datos correspondiente.Esto puede hacerse utilizando la clase com.knowgate.hipergate.datamodel.ModelManager desde la línea de comandos. java [-cp ...] com.knowgate.hipergate.datamodel.ModelManager /etc/hipergate.cnf upgrade 210 300

x. Diagnóstico de Problemas

JavaMail

com.sun.mail.smtp.SMTPAddressFailedException: 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)Este error suele ser debido a que el servidor de correo requiere autentificación al enviar.Ver http://forum.java.sun.com/thread.jspa?threadID=586817&tstart=0

com.sun.mail.smtp.SMTPAddressFailedException: 550 5.7.1 Unable to relay for ...Este error es debido a que la seguridad de servidor no permite hacer relay de correo.Ver http://java.sun.com/products/javamail/FAQ.html#norelay

No provider for SMTPEscribir el nombre del protocolo smtp en minúlas en la propiedad mail.transport.protocol de hipergate.cnf

MySQL

MessagingException Illegal mix of collations for operation 'UNION'Esto es debido a que la base de datos ha sido creada con juego de caracteres LATIN1 (u otro) en vez de UTF8.

Access denied; you need the SUPER privilege for this operationDurante la creación inicial del modelo de datos. Ejecutar el GRANT según se especifica en la sección de creación de usuarios para MySQL de esta guía.

PostgreSQL

Impossible to get connection to the database relation "sql_features" does not existPruebe a establecer la propiedad schema=public en hipergate.cnf.

SET AUTOCOMMIT TO OFF is no longer supportedLa versión del driver JDBC no coincide con la de la base de datos.

ERROR: function k_sp_autenticate("unknown", "unknown") does not exist. The authentication service is temporaly unavailable.Debe activar el lenguage PL/pgSQL ANTES de iniciar la creación del modelo de datos con el asistente de instalación.

SQL Server

FUNCTION dbo.k_sp_prj_cost does not existDesde una herramienta de consulta SQL volver a crear sobre el propietario adecuado (típicamente dbo o db_accessadmin) la función Transact/SQL k_sp_prj_cost cuyo código fuente puede encontrarse en java\com\knowgate\hipergate\datamodel\procedures\mssql\projtrack.ddl

General

Posted content length of XXX exceeds limit of YYYAumentar el valor en bytes de la propiedad maxfileupload en hipergate.cnf y reiniciar el servidor web para que coja los cambios.

Busque en los foros públicos para obtener información adicional sobre problemas con la instalación.