He encontrado este artículo: https://community.intersystems.com/post/no-access-control-allow-origin-h...

Es lo que me pasa a mi desde mi aplicación web (quitando el error del webgateway, que me da que simplemente la descripción no es correcta).

Revisando el usuario CSPSystem, le he asignado el rol de la base de datos donde está el repositorio FHIR, y sigue sin funcionar, pero si le asigno el rol %All, funciona. Así que algún permiso me falta con este usuario, no consigo averiguar cuál...

Nada, sigue igual.

He hecho otra prueba: he creado un servicio Rest que solamente devuelve un hola mundo, le he añadido los orígenes y tal como en el otro servicio, y éste sí funciona:

A este servicio le he añadido el parámetro del cors:

Parameter HandleCorsRequest As %Integer = 1;

Así que he revisado la clase del servicio de FHIR (HS.FHIRServer.RestHandler), a ver si tiene esto, y lo tiene también. Es más, he comparado incluso el código de la versión 2025.1 con la versión 2024.3, a ver si es que en algún sitio hay algo distinto, pero son iguales.

No entiendo qué pasa 😢

Las llamadas son https:

Creo que tengo algo mal configurado, pero no sé exactamente dónde... El error dice que es un error de protocolo entre el webgateway y la instancia de IRIS. Lo que no entiendo es por qué no me sale ese error cuando accedo al portal de IRIS a través del gateway, o cuando llamo al repositorio FHIR a través de Postman (y también del webgateway)... Puede ser que tenga algo mal configurado en el repositorio FHIR? O en el webgateway?

Esta es la config del webgateway:

Esta la configuración del superservidor:

Y el repositorio FHIR tiene todo por defecto, excepto el Service Config Name:

Estoy segura que es problema de CORS, pero tengo definido el origen permitido en la aplicación web del servicio Rest, igual que con el otro stack de Docker, es lo que no entiendo...

Esto es lo que veo en el webgateway, con los logs puestos en EV9:

>>> local-time="Mon Jun 9 10:31:43 2025" wg-build="RT 2501.1849 (linux/apapi:srv=2.4.58/apr=1.7.2/apu=1.6.3/mpm=worker)" wg-log-level=9 when="2025-06-09 10:31:43.321" level=DEBUG2 event=WebGateway.ProcessRequest pid=29 thread-id=281473464725792 csp-connection-no=2 csp-server="LOCAL" csp-server-pid=1386 csp-request-id=4 csp-session-id=G9je2ZjMCj csp-remote-addr=192.168.65.1 csp-page="OPTIONS /hyperobjects/fhir/r4/metadata"
HTTP Request
OPTIONS /hyperobjects/fhir/r4/metadata?_format=json HTTP/1.1
Host: yyyyy.cysnet.net:8743
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Accept: */*
Access-Control-Request-Method: GET
Access-Control-Request-Headers: authorization
Origin: https://xxxxx.cysnet.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Sec-Fetch-Dest: empty
Referer: https://xxxxx.cysnet.net/
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: es,en-US;q=0.9,en;q=0.8


>>> local-time="Mon Jun 9 10:31:43 2025" wg-build="RT 2501.1849 (linux/apapi:srv=2.4.58/apr=1.7.2/apu=1.6.3/mpm=worker)" wg-log-level=1 when="2025-06-09 10:31:43.326" level=WARNING event=WebGateway.Interrupt pid=29 thread-id=281473464725792 csp-connection-no=2 csp-server="LOCAL" csp-server-pid=1386 csp-request-id=4
Interrupt InterSystems IRIS Process and Close the Connection
Protocol Error between the Web Gateway and InterSystems IRIS (request_id=4; response_id=0).

Así es como tengo configurada la aplicación del servicio rest:

Y así el CSP.conf:

# CSP config file

CSPModulePath "${ISC_PACKAGE_INSTALLDIR}/bin/"
CSPConfigPath "${ISC_PACKAGE_INSTALLDIR}/bin/"

# Serve everything via Web Gateway. Conveniently,
# we needn't worry about sharing this container with non-IRIS applications.
<Location />
    CSP On
</Location>

<Directory />
    Options MultiViews FollowSymLinks
    AllowOverride None
    Require all granted
    <FilesMatch "\.(log|ini|pid|exe|so)$">
        Require all denied
    </FilesMatch>
</Directory>

# SSL SECTION #
# Enable SSL/TLS (https://) on the Apache web server.
# The user is responsible for providing valid SSL certificates.
LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so
LoadModule headers_module /usr/lib/apache2/modules/mod_headers.so
<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile "/webgateway-shared/certificates/xxxxx.crt"
    SSLCertificateKeyFile "/webgateway-shared/certificates/xxxxx.key"
    # Header add ACCESS-CONTROL-ALLOW-ORIGIN "*"
</VirtualHost>

# Redirect Help links
Redirect /csp/docbook/ http://docs.intersystems.com/irislatest/csp/docbook/

No había visto ese artículo, pero más o menos es lo que he seguido. No he instalado zpm-registry en una instancia de IRIS que ya teníamos, sino que he levantado un contenedor nuevo, con la versión community.

Nuestro caso es que trabajamos para clientes que tienen IRIS, cada uno el suyo, pero tenemos librerías comunes que utilizamos en estos clientes. Mi idea era levantar un registry propio para nuestra compañía, en la que tener estas librerías disponibles para cualquier cliente, y en caso de que cada cliente lo necesite, levantar en sus instancias su registry privado.

Entiendo, entonces, que lo ideal es tener el registry levantado en la instancia de IRIS que ya tengamos, y no utilizar un contenedor aparte con una versión Community. Es así?

Hola @Luis Angel Pérez Ramos! 

No veo el link al artículo, quizá te refieras a alguno de estos? 

• https://community.intersystems.com/post/why-docker-ipm-and-objectscript-...
• https://community.intersystems.com/post/installing-objectscript-solution...

De todas formas, mi pregunta va sobre tener nuestro propio repositorio IPM, privado. Es decir, crear nuestro propio registro. Lo he conseguido hacer en local, la verdad es que con la template que hay en el github de la comunidad ha sido muy fácil. Pero a la hora de tenerlo disponible para toda la compañía y empezar a subir nuestras propias librerías, antes de arrancarlo con la versión que hay ahora, etc, quería saber si es conveniente crearlo en una versión IRIS enterprise, o vale con que sea una IRIS Community.

Gracias!

La cookie llega, conseguimos leerla con esta instrucción:

 Set tokenCookie = httpRequest.GetCookie("SessionToken")

El nombre es inventado, no sé si quizá esté ahí el problema... O si se debe generar una cabecera o alguna historia para que funcione.

Lo que no sabemos es qué hacer una vez leída la cookie y obtenido el token.

¡Gracias Luis Ángel! Si he entendido bien lo que me recomiendas, sería utilizar el tipo de dato PosixTime en lugar del TimeStamp y crearle un índice normal, no? Pero el rendimiento no sería bueno, por lo que comentabas al comienzo, de que los valores no son únicos, verdad? O en este caso no haría falta índice? (lo probaré de todas formas 😉)