Download a. Requisitos y Prioridades de Diseño

HIPERGATE
TABLA 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.0
x. 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.
Usuario
Se 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.
Dominio
Un 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. Requisitos
Sistema 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ía
Oracle 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 = true
virtual_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.
[email protected] (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.
[email protected] (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.
[email protected] (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.
[email protected] (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.
[email protected] (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>
<servletclass>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>
<servletclass>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>
<servletclass>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:
Nombre de la clase Java del driver JDBC
jdbcDriverClassName {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.DBDemo
devel.cnf com.knowgate.dataobjs.DBDevel
portal.cnf com.knowgate.dataobjs.DBPortal
real.cnf
com.knowgate.dataobjs.DBReal
test.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"
class="com.knowgate.dataobjs.DBTest"/>
scope="application"
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 JBoss
Contribuido por Nam Tu nguyen


















Usar el archivo etiquetado hipergate-xx-war.zip en vez de hipergate-xxsrc.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> <connectionurl>jdbc:postgresql://127.0.0.1:5432/hgoltp8t</connectionurl>
<!-- 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 datos
driver=org.postgresql.Driver
dburl=jdbc:postgresql://192.168.1.30:5432/test
schema=
dbuser=postgres
dbpassword=postgres
# [Pool de conexiones]
# Parámeteros que gobiernan el comportamiento del pool de
conexiones de hipergate
poolsize=32
maxconnections=100
logintimeout=20
connectiontimeout=60000
connectionreaperdelay=30000
# [Acceso a Ficheros]
# Directorio para archivos temporales
temp=/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 web
webserver=http://hostname:8080
# URL raíz al servidor de imágenes opcional
imageserver=http://hostname:8080/images
# Protocolo, host, usuario y contraseña de acceso a los
siguientes recursos
fileprotocol=file://
fileserver=localhost
fileuser=
filepassword=
# Directorio raíz de almacenamiento privado
storage=$CATALINA_HOME/webapps/storage
# Directorio para almacenar tareas de borrado
shelldir=/tmp
# Directorio raíz de almacenamiento público
workareasput=$CATALINA_HOME/webapps/hipergate/workareas
# URL raíz de almacenamiento público
workareasget=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 tareas
maxschedulerthreads=1
# [WebMail]
# Poner los nombres de los protocolos en minúsculas
mail.transport.protocol=smtp
mail.store.protocol=pop3
mail.incoming=pop3.yourserver.com
mail.outgoing=smtp.yourserver.com
mail.user=
# LDAP
ldapconnect=ldap://127.0.0.1:389/dc=hipergate,dc=org
ldapuser=cn=Manager,dc=hipergate,dc=org
ldappassword=manager
ldapclass=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

com.microsoft.sqlserver.jdbc.SQLServerDriver (SQL
Server 2000)
Server 2005)
dburl
Cadena de conexión JDBC a la base de datos:

jdbc:postgresql://host_name:5432/nombre_bbdd



jdbc:mysql://host_name/nombre_bbdd (MySQL)
jdbc:oracle:thin:@nombre_host:1521:oracle_sid (Oracle)
jdbc:microsoft:sqlserver://nombre_host:1433;SelectMe
thod=cursor;DatabaseName=nombre_bbdd (SQL Server 2000)
(PostgreSQL)

jdbc:sqlserver://nombre_host:1433;SelectMethod=curso
r;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\\s
torage (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\\s
hell (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\\h
ipergateWeb\\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=enabled
java.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>
<containerinvoker>org.jboss.proxy.ejb.ProxyFactory</container-invoker>
<container-interceptors>
<interceptor>org.jboss.ejb.plugins.LogInterceptor</inter
ceptor>
<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</interc
eptor>
<interceptor>org.jboss.proxy.SecurityInterceptor</interc
eptor>
<interceptor>org.jboss.proxy.TransactionInterceptor</int
erceptor>
<interceptor>org.jboss.invocation.InvokerInterceptor</in
terceptor>
</home>
<bean>
<interceptor>org.jboss.proxy.ejb.StatelessSessionInterce
ptor</interceptor>
<interceptor>org.jboss.proxy.SecurityInterceptor</interc
eptor>
<interceptor>org.jboss.proxy.TransactionInterceptor</int
erceptor>
<interceptor>org.jboss.invocation.InvokerInterceptor</in
terceptor>
</bean>
</client-interceptors>
<instancepool>org.jboss.ejb.plugins.StatelessSessionInstancePool</instanc
e-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\cachecoordinatorjboss30.jar)
t. Apéndice 4: Librerías de terceros
J2EE 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ón
La 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 fuentes
com.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-bind1.1.5.jar;C:\JAR\jibx-extras.jar;C:\JAR\xpp3.jar
org.jibx.binding.Compile C:\knowgate\storage\xslt\schemas\menudef-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 SMTP
Escribir 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 operation
Durante 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 exist
Pruebe a establecer la propiedad schema=public en hipergate.cnf.
SET AUTOCOMMIT TO OFF is no longer supported
La 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 exist
Desde 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 YYY
Aumentar 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.