Es un componente de InterSystems IRIS que proporciona solicitudes HTTP para la plataforma de datos de Intersystems IRIS.
Documentos de apoyo: Puerta de enlace web de Intersystems para servicios web
He creado un nuevo stack de Docker con WebGateway e IRIS for Health 2025.1. He mapeado los puertos de WebGateway de la siguiente manera:
Puedo acceder al portal IRIS a través del 8743 sin problemas.
También he creado un repositorio FHIR y puedo acceder a él a través del puerto 8743.
Las versiones recientes de IRIS contienen varios cambios que afectan a la instalación y condiguración de la herramienta OpenSource WebTerminal.
En este articulo, vamos a ver los pasos de instalación, y aprender a buscar y resolver los errores del WebGateway paso a paso.
Esta guía de instalación se ha realizado con la versiones siguientes, las más recientes soportadas a fecha de marzo de 2025:
IAM - InterSystems API Manager es una gran herramienta para monitorear vuestro tráfico. Si estáis intentando usarla en vuestro clúster de Kubernetes, es posible que hayáis intentado hacer un despliegue similar a este:
Recientemente, necesitaba ejecutar WebGateway en un puerto adicional, pero con una novedad: este puerto debería publicar solo una aplicación web.
Al principio, pensé en configurar WebGateway para permitir solo aplicaciones web específicas (~urls), pero la configuración de WebGateway depende de la configuración de Apache:
LoadModule csp_module_sa "/opt/webgateway/bin/CSPa24.so"
CSPModulePath "/opt/webgateway/bin/"
CSPConfigPath "/opt/webgateway/bin/"csp-log-tutorial
Aseguraos de tener git instalado.
Creé una carpeta git dentro del directorio mgr de IRIS. Hice clic derecho en la carpeta git y elegí "Git Bash Here" en el menú contextual.
git clone https://github.com/oliverwilms/csp-log-tutorial.git
Clonad mi repositorio de GitHub csp-log-tutorial si queréis probarlo vosotros mismos.
Mi equipo trabaja con contenedores IRIS que se ejecutan en la plataforma de contenedores Red Hat OpenShift (Kubernetes) en AWS. Implementamos tres pods con el WebGateway que reciben solicitudes a través de un Balanceador de carga de red (Network Load Balancer). Las solicitudes se procesan en una producción de Interoperabilidad que se ejecuta en tres pods de computación. Usamos una producción como banco de mensajes que se ejecuta en pods de datos replicados (mirrored) como un lugar para revisar todos los mensajes procesados por cualquier pod de computación.
Probamos nuestras interfaces usando pods de alimentación para enviar muchos mensajes de solicitud al Balanceador de carga de red. Enviamos 100 000 mensajes y probamos cuánto tiempo llevaría procesar todos los mensajes en el banco de mensajes y registrar las respuestas en los alimentadores. El recuento de mensajes almacenados en el banco de mensajes y las respuestas recibidas por los alimentadores coinciden con el número de mensajes entrantes.
Recientemente nos pidieron que probáramos la tolerancia ante fallos de los pods y de la Zona de Disponibilidad. Borramos pods individuales con o sin fuerza y periodo de gracia. Simulamos un fallo en la zona de disponibilidad al negar todo el tráfico entrante y saliente a una subred (una de las tres zonas de disponibilidad) a través de la consola de AWS mientras los alimentadores envían muchos mensajes de solicitud al Balanceador de carga de red. Ha sido bastante difícil contabilizar todos los mensajes enviados por los alimentadores.
El otro día, mientras un alimentador enviaba 5 000 mensajes, simulamos el fallo de la Zona de disponibilidad. El alimentador recibió 4 933 respuestas. El banco de mensajes almacenó 4 937 mensajes.
Almacenamos access.log y CSP.log en el directorio de datos de los pods de WebGateway. Añadimos esta línea al Dockerfile de nuestra imagen de WebGateway:
RUN sed -i 's|APACHE_LOG_DIR=/var/log/apache2|APACHE_LOG_DIR=/irissys/data/webgateway|g' /etc/apache2/envvars
Configuramos el Nivel de Registro de Eventos (Event Log Level) en Web Gateway en Ev9r.!
Creé los subdirectorios data0, data1 y data2 para nuestros tres pods de webgateway. Copié los archivos CSP.log y access.log de nuestros tres pods de webgateway almacenados en volúmenes persistentes:
){kind=link}
oc cp iris-webgateway-0:/irissys/data/webgateway/access.log data0/access.log
oc cp iris-webgateway-1:/irissys/data/webgateway/access.log data1/access.log
oc cp iris-webgateway-2:/irissys/data/webgateway/access.log data2/access.log
oc cp iris-webgateway-0:/irissys/data/webgateway/CSP.log data0/CSP.log
oc cp iris-webgateway-1:/irissys/data/webgateway/CSP.log data1/CSP.log
oc cp iris-webgateway-2:/irissys/data/webgateway/CSP.log data2/CSP.log
Termino con tres subdirectorios, cada uno conteniendo archivos access.log y CSP.log.
Contamos el número de solicitudes procesadas en cualquier pod de webgateway usando este comando:
cat access.log | grep InComingOTW | wc -l
Contamos el número de solicitudes y respuestas registradas en CSP.log usando este comando:
cat CSP.log | grep InComingOTW | wc -l
Normalmente esperamos el doble de líneas en CSP.log en comparación con access.log. A veces encontramos más líneas en CSP.log que el doble esperado de líneas en access.log. Recuerdo haber visto menos líneas de las esperadas en CSP.log en comparación con lo que había en access.log al menos una vez. Sospechamos que esto se debió a una respuesta 500 registrada en access.log, que no se registró en CSP.log, correctamente porque el pod de webgateway se terminó.
Creé las clases persistentes otw.wgw.apache y otw.wgw.csp para importar líneas desde access.log y CSP.log. access.log contiene una línea por solicitud e incluye el estado de la respuesta. CSP.log contiene líneas separadas para solicitudes y respuestas.
Abrid el terminal de IRIS e importad las clases en el directorio src desde el repositorio csp-log-tutorial que habíamos clonado anteriormente:
Set src="C:\InterSystems\IRISHealth\mgr\git\csp-log-tutorial\src"
Do $system.OBJ.LoadDir(src,"ck",,1)
Si no tenéis vuestro propio archivo CSP.log para analizar, podéis importar el que se proporciona en el repositorio csp-log-tutorial:
Set pFile="C:\InterSystems\IRISHealth\mgr\git\csp-log-tutorial\wg2_20230314_CSP.log"
Do ##class(otw.wgw.csp).ImportMessages(pFile,.pLines,.pFilter,1)
pLines y pFilter son parámetros de salida que no son tan importantes en este momento. pImport controla si el Extent se elimina antes de importar los datos.
Después de importar los datos podemos ejecutar consultas SQL como esta:
SELECT count(*) FROM otw_wgw.csp where wgEvent='WebGateway.ProcessRequest'
Si el recuento devuelto es un número impar, indica que hay un desajuste entre las solicitudes y las respuestas.
Podemos ejecutar la siguiente consulta para identificar los nombres de archivo en las solicitudes que no tienen una respuesta coincidente:
select zFilename, count(*) from otw_wgw.csp group by zFilename having count(*) = 1
Tened en cuenta que utilizo el método CalcFilename para establecer la propiedad zFilename antes de guardar una línea importada del archivo CSP.log.
También incluí un archivo access.log de muestra, que podemos importar así: Si no tenéis vuestro propio archivo CSP.log para analizar, podéis importar el que se proporciona en el repositorio csp-log-tutorial:
Set pFile="C:\InterSystems\IRISHealth\mgr\git\csp-log-tutorial\wg2_20230314_access.log"
Do ##class(otw.wgw.apache).ImportMessages(pFile,.pLines,.pFilter,1)
Podemos ejecutar esta consulta para obtener el recuento de mensajes relacionados con este tutorial:
SELECT count(*) FROM otw_wgw.apache where Text like '%tutorial%'
Me gustaría combinar los datos de las tablas apache y csp y posiblemente incluir datos recogidos de los pods de computación.
Creo que puedo utilizar los datos de access.log para determinar cuándo hubo una interrupción en un pod de webgateway.
¡Hola Comunidad!
Compartimos con vosotros un nuevo vídeo con subtítulos en español, que explica los pasos necesarios para actualizar InterSystems IRIS, InterSystems IRIS for Health o HealthShare Health Connect desde una versión que utiliza un servidor web privado de InterSystems a una versión que utiliza un servidor web estándar de la industria, independiente de la instancia.
El vídeo muestra el proceso usando InterSystems IRIS en un entorno Ubuntu. Se puede seguir el mismo proceso para los otros productos, y en cualquier sistema operativo basado en Linux o Unix.
En el ejemplo, se tienen tres instancias de InterSystems IRIS en funcionamiento: mirror1 y mirror2, que son dos instancias en réplica síncrona (failover o sync mirror) y 1 instancia de réplica asíncrona (async mirror).
¡Esperamos que os resulte útil!
⏯ Cómo migrar una configuración mirror fuera del Servidor Web Privado en Linux o Unix
¡Hola Comunidad!
Compartimos con vosotros un nuevo vídeo con subtítulos en español, que explica los pasos necesarios para actualizar InterSystems IRIS, InterSystems IRIS for Health o HealthShare Health Connect desde una versión que utiliza un servidor web privado de InterSystems a una versión que utiliza un servidor web estándar de la industria, independiente de la instancia.
El vídeo muestra el proceso usando InterSystems IRIS en un entorno Ubuntu. Se puede seguir el mismo proceso para los otros productos, y en cualquier sistema operativo basado en Linux o Unix.
¡Esperamos que os resulte útil!
⏯ Cómo migrar una instancia fuera del Servidor Web Privado en Linux o Unix
Se pueden configurar páginas de error individuales para los siguientes mensajes de error/respuestas del Web Gateway:
Los ajustes se realizan en la pantalla Administración del Portal de Gestión ([Administración] > [Configuración] > [Gestión del Web Gateway] > [Configuración] > [Parámetros predeterminados]).
¡Hola Comunidad!
Hemos grabado el webinar que hicimos ayer y lo hemos subido al canal de YouTube de la Comunidad de Desarrolladores en español. Si os perdisteis el webinar o lo queréis volver a ver con más detalle, ya está disponible la grabación!
¡Hola desarrolladores!
Os invitamos a un nuevo webinar en español: "Descubriendo los secretos del Web Gateway de InterSystems", el jueves 29 de junio, a las 4:00 PM (CEST).
Es posible que ya hayáis oído que, a partir de las versiones de IRIS y HealthShare HealthConnect 2023.2, se va a eliminar de la instalación por defecto el Apache Server interno por lo que será necesario contar con un servidor de aplicaciones externo como puede ser Apache Server o NGINX.
En este artículo voy a proceder a realizar la instalación de un HealthShare HealthConnect 2023.1 para que funcione con un Apache Server pre-instalado. Para ello utilizaré una máquina virtual sobre la que he instalado un Ubuntu 22.04.
¡Hola Comunidad!
En este artículo configuraremos mediante programación un Apache Web Gateway con Docker, utilizando:
Utilizaremos dos imágenes: una para el Web Gateway y la segunda para la instancia de IRIS.
Todos los archivos necesarios están disponibles en este repositorio de GitHub.
Comencemos clonando el proyecto de git:
git clone https://github.com/lscalese/docker-webgateway-sample.git
cd docker-webgateway-sample
Para evitar problemas con los permisos, el sistema necesita un usuario y un grupo:
Es necesario para compartir archivos de certificados con los contenedores. Si no existen en tu sistema, simplemente ejecútalos:
sudo useradd --uid 51773 --user-group irisowner
sudo groupmod --gid 51773 irisowner
sudo useradd –user-group www-data
En este ejemplo, utilizaremos tres certificados:
Para generarlos, está disponible un script listo para usarse.
Sin embargo, hay que personalizar el asunto del certificado; simplemente edita el archivo gen-certificates.sh.
Esta es la estructura del argumento OpenSSL subj:
Se pueden cambiar estos valores.
# sudo is needed due chown, chgrp, chmod ...
sudo ./gen-certificates.sh
Si todo está bien, deberías ver dos nuevos directorios ./certificados/ y ~/webgateway-apache-certificados/ con certificados:
| Archivo | Contenedor | Descripción |
|---|---|---|
| ./certificates/CA_Server.cer | webgateway,iris | Certificado del servidor de autoridad |
| ./certificates/iris_server.cer | iris | Certificado para la instancia de IRIS (utilizado para el cifrado de la comunicación mirror y de webgateway) |
| ./certificates/iris_server.key | iris | Clave privada relacionada |
| ~/webgateway-apache-certificates/apache_webgateway.cer | webgateway | Certificado para el servidor web de apache |
| ~/webgateway-apache-certificates/apache_webgateway.key | webgateway | Clave privada relacionada |
| ./certificates/webgateway_client.cer | webgateway | Certificado para cifrar la comunicación entre webgateway e IRIS |
| ./certificates/webgateway_client.key | webgateway | Clave privada relacionada |
Ten en cuenta que si hay certificados autofirmados, los navegadores web mostrarán alertas de seguridad. Obviamente, si tienes un certificado emitido por una autoridad certificadora, puedes utilizarlo en vez de uno autofirmado (especialmente para el certificado del servidor de Apache).
Echa un vistazo a los archivos de la configuración.
Puedes ver un archivo CSP.INI en el directorio webgateway-config-files.
Será introducido en la imagen, pero el contenido puede ser modificado durante el tiempo de ejecución.
Considera este archivo como una plantilla.
En este ejemplo, los siguientes parámetros se sobrescribirán cuando se inicie el contenedor:
Consulta startUpScript.sh para más información. A grandes rasgos, la sustitución se realiza con la línea de comandos sed.
Además, este archivo contiene la configuración SSL\TLS para asegurar la comunicación con la instancia de IRIS:
SSLCC_Certificate_File=/opt/webgateway/bin/webgateway_client.cer
SSLCC_Certificate_Key_File=/opt/webgateway/bin/webgateway_client.key
SSLCC_CA_Certificate_File=/opt/webgateway/bin/CA_Server.cer
Estas líneas son importantes. Debemos asegurarnos de que los archivos del certificado estarán disponibles para el contenedor.
Lo haremos más tarde en el archivo docker-compose con un volumen.
Se trata de un archivo de configuración de Apache. Permite utilizar el protocolo HTTPS y redirige las llamadas HTTP a HTTPS.
Los archivos del certificado y la clave privada se configuran en este archivo:
SSLCertificateFile /etc/apache2/certificate/apache_webgateway.cer
SSLCertificateKeyFile /etc/apache2/certificate/apache_webgateway.key
Para nuestra instancia de IRIS, configuramos únicamente los requisitos mínimos para permitir la comunicación de SSL\TLS con el Web Gateway; esto incluye:
%SuperServerPara facilitar la configuración, se utiliza config-api con un archivo de configuración JSON sencillo.
{
"Security.SSLConfigs": {
"%SuperServer": {
"CAFile": "/usr/irissys/mgr/CA_Server.cer",
"CertificateFile": "/usr/irissys/mgr/iris_server.cer",
"Name": "%SuperServer",
"PrivateKeyFile": "/usr/irissys/mgr/iris_server.key",
"Type": "1",
"VerifyPeer": 3
}
},
"Security.System": {
"SSLSuperServer":1
},
"Security.Services": {
"%Service_WebGateway": {
"ClientSystems": "172.16.238.50;127.0.0.1;172.16.238.20"
}
}
}
No es necesario realizar ninguna acción. La configuración se cargará automáticamente al iniciar el contenedor.
ARG IMAGEWEBGTW=containers.intersystems.com/intersystems/webgateway:2021.1.0.215.0
FROM ${IMAGEWEBGTW}
ADD webgateway-config-files /webgateway-config-files
ADD buildWebGateway.sh /
ADD startUpScript.sh /
RUN chmod +x buildWebGateway.sh startUpScript.sh && /buildWebGateway.sh
ENTRYPOINT ["/startUpScript.sh"]
De forma predeterminada, el punto de entrada es /startWebGateway, pero necesitamos realizar algunas operaciones antes de iniciar el servidor web. Recuerda que nuestro archivo CSP.ini es una plantilla, y necesitamos cambiar algunos parámetros (IP, puerto, administrador del sistema) durante el arranque. startUpScript.sh realizará estos cambios y después ejecutará el script del punto de entrada inicial /startWebGateway.
Antes de iniciar los contenedores, se debe modificar el archivo docker-compose.yml:
**SYSTEM_MANAGER** debe estar configurado con la IP autorizada para tener acceso a Web Gateway Managementhttps://localhost/csp/bin/Systems/Module.cxw Básicamente, es tu dirección IP (Puede ser una lista separada por comas).
**IRIS_WEBAPPS** debe configurarse con la lista de tus aplicaciones CSP. La lista está separada por espacios, por ejemplo: IRIS_WEBAPPS=/csp/sys /swagger-ui. De forma predeterminada, solo se expone /csp/sys.
Los puertos 80 y 443 están mapeados. Adáptalos a otros puertos si ya se utilizan en tu sistema.
version: '3.6'
services:
webgateway:
image: tls-ssl-webgateway
container_name: tls-ssl-webgateway
networks:
app_net:
ipv4_address: 172.16.238.50
ports:
# change the local port already used on your system.
- "80:80"
- "443:443"
environment:
- IRIS_HOST=172.16.238.20
- IRIS_PORT=1972
# Replace by the list of ip address allowed to open the CSP system manager
# https://localhost/csp/bin/Systems/Module.cxw
# see .env file to set environement variable.
- "SYSTEM_MANAGER=${LOCAL_IP}"
# the list of web apps
# /csp allow to the webgateway to redirect all request starting by /csp to the iris instance
# You can specify a list separate by a space : "IRIS_WEBAPPS=/csp /api /isc /swagger-ui"
- "IRIS_WEBAPPS=/csp/sys"
volumes:
# Mount certificates files.
- ./volume-apache/webgateway_client.cer:/opt/webgateway/bin/webgateway_client.cer
- ./volume-apache/webgateway_client.key:/opt/webgateway/bin/webgateway_client.key
- ./volume-apache/CA_Server.cer:/opt/webgateway/bin/CA_Server.cer
- ./volume-apache/apache_webgateway.cer:/etc/apache2/certificate/apache_webgateway.cer
- ./volume-apache/apache_webgateway.key:/etc/apache2/certificate/apache_webgateway.key
hostname: webgateway
command: ["--ssl"]
iris:
image: intersystemsdc/iris-community:latest
container_name: tls-ssl-iris
networks:
app_net:
ipv4_address: 172.16.238.20
volumes:
- ./iris-config-files:/opt/config-files
# Mount certificates files.
- ./volume-iris/CA_Server.cer:/usr/irissys/mgr/CA_Server.cer
- ./volume-iris/iris_server.cer:/usr/irissys/mgr/iris_server.cer
- ./volume-iris/iris_server.key:/usr/irissys/mgr/iris_server.key
hostname: iris
# Load the IRIS configuration file ./iris-config-files/iris-config.json
command: ["-a","sh /opt/config-files/configureIris.sh"]
networks:
app_net:
ipam:
driver: default
config:
- subnet: "172.16.238.0/24"
Ejecutamos el build e iniciamos:
docker-compose up -d --build
Los contenedores tls-ssl-iris y tls-ssl-webgateway deben iniciarse.
Abre la página http://localhost. Serás redirigido automáticamente a https://localhost.
Los navegadores muestran alertas de seguridad. Este es el comportamiento habitual con un certificado autofirmado, acepta el riesgo y continua.
Abre https://localhost/csp/bin/Systems/Module.cxw y prueba la conexión con el servidor. 
Abre https://localhost/csp/sys/utilhome.csp
¡Excelente! ¡El ejemplo del Web Gateway funciona!
En el artículo anterior construimos un entorno mirror, pero faltaba el Web Gateway. Ahora podemos solucionar eso.
Un nuevo repositorio iris-miroring-with-webgateway está disponible, incluyendo el Web Gateway y algunas mejoras más:
Consulta el archivo README.md del repositorio para ejecutar un entorno como este:
En el Centro de Soporte Internacional (WRC), con frecuencia los clientes se ponen en contacto con nosotros porque su Web Gateway no puede publicar páginas web. En este artículo explicaré el motivo más frecuente por el que pueden producirse estos errores; y también explicaré algunas herramientas que se pueden utilizar para solucionar el problema. Esta explicación se centra en el Web Gateway que enlaza con las instancias de InterSystems IRIS, pero la misma explicación debería aplicar también a la CSP Gateway que enlaza con instancias de Caché.
El problema:
En el Centro de Soporte Internacional (WRC), con frecuencia los clientes plantean preguntas sobre la configuración de un nuevo Web Gateway, en el que el Portal de Administración se carga a medias, pero no muestra imágenes. En este artículo explicaré por qué se produce este error, así como la forma de solucionarlo. Mi explicación se centra en el Web Gateway que enlaza con las instancias de InterSystems IRIS, pero la misma explicación debería aplicar también a la CSP Gateway que enlaza con instancias de Caché.
El problema:
¡Hola Comunidad!
La mayor parte de las comunicaciones servidor-cliente en la web se basan en una estructura de solicitud y respuesta. El cliente envía una solicitud al servidor y el servidor responde a esta solicitud. El protocolo WebSocket ofrece un canal bidireccional de comunicación entre un servidor y un cliente, lo que permite a los servidores enviar mensajes a los clientes sin antes haber recibido una solicitud. Por más información sobre el protocolo WebSocket y su implementación en InterSystems IRIS, vea los siguientes enlaces: