InterSystems IRIS se basa en una arquitectura que separa la organización lógica de los datos (namespaces - espacios de nombres) de su ubicación física de almacenamiento (bases de datos). Comprender esta separación y la distinción entre espacios de nombres y bases de datos es fundamental para una gestión de datos eficaz, la seguridad y, especialmente, para compartir datos con alto rendimiento.

En este artículo, explicaré estos componentes fundamentales y ofreceré una guía práctica sobre cómo aprovechar los mapeos de globals para compartir estructuras de datos nativas (globals) entre diferentes entornos lógicos.

Bases de datos: la realidad física

Una base de datos representa la realidad física de dónde se almacenan los datos en el disco. Antes que nada, es un archivo en un sistema de archivos llamado IRIS.dat (por ejemplo, <carpeta de instalación>\mgr\user\IRIS.DAT). El tamaño máximo de este archivo es de 32 TB. Es el contenedor de todos los datos y del código. Las bases de datos son gestionadas por el núcleo de IRIS, que se encarga del caché, el registro en diario (journaling) y el registro de transacciones a nivel de archivo físico.

Al instalar el DBMS de InterSystems IRIS, se crean automáticamente las siguientes bases de datos:

También en versiones anteriores podíais definir vuestro servidor FHIR para aceptar solicitudes mediante OAuth 2.0 (por ejemplo, para un cliente SMART on FHIR), pero hoy en día, con la versión v2024.3, que se lanzó hace ya un tiempo, existe una nueva funcionalidad que permite hacerlo de forma más sencilla: el OAuth FHIR Client QuickStart.

Hay un patrón con el que me he encontrado varias veces en el que necesito usar un archivo o carpeta temporal y que se limpie en algún momento más adelante.

Lo natural aquí es seguir los patrones de "Robust Error Handling and Cleanup in ObjectScript" usando un try/catch/pseudo-finally o un objeto registrado para gestionar la limpieza en el destructor. %Stream.File* también tiene una propiedad “RemoveOnClose” que podéis activar… pero usadla con cuidado, porque podríais eliminar accidentalmente un archivo importante, y este indicador se reinicia al llamar a %Save(), así que tendréis que volver a ponerlo a 1 después de hacerlo.

Pero hay un caso complicado: imaginad que necesitáis que el archivo temporal sobreviva en un nivel de pila superior. Por ejemplo:

Hola,

Cuando abrimos un terminal en IRIS, entramos en el shell de ObjectScript. Dentro de este shell, podemos ejecutar comandos de IRIS, como:

En otras palabras, el comando ObjectScript se ejecuta en el shell actual. Pero siempre es bueno recordar que IRIS tiene otros shells.

Seguramente queríais usar la especificación OpenAPI (OAS) en formato JSON que utilizasteis para vuestra clase spec en el paquete iris-web-swagger-ui de IRIS.
La OAS generada por el método ##class(%REST.API).GetWebRESTApplication(...) es muy básica, sin descripciones de los parámetros ni de la estructura esperada de las respuestas.

Así que, después de crear vuestra aplicación REST a partir de una OAS, deberíais tener:

gj :: configExplorer es una nueva extensión de VS Code que se integra con Server Manager y aprovecha Structurizr para generar diagramas de configuración de vuestros servidores.

Aquí tenéis un breve video introductorio.

https://www.youtube.com/embed/WHkoZsg6P-A
[Este es un enlace integrado, pero no puede ver el contenido integrado directamente en el sitio porque rechazó las cookies que se necesitan para acceder a él. Para ver el contenido integrado, debe aceptar todas las cookies desde la Configuración de cookies]

Contexto

Por una variedad de razones, los usuarios pueden desear montar un volumen persistente en dos o más pods que abarquen varias zonas de disponibilidad. Un caso de uso de este tipo es poner a disposición de ambos miembros del espejo los datos almacenados fuera de IRIS en caso de una conmutación por error.

Desafortunadamente, las clases de almacenamiento integradas en la mayoría de las implementaciones de Kubernetes (ya sea en la nube o en las instalaciones) no ofrecen esta capacidad:

Muchas veces, al trabajar con datos FHIR, por ejemplo con IRIS For Health, resulta útil crear una operación FHIR personalizada. El estándar FHIR incluye un conjunto de operaciones definidas (como $everything), pero una operación personalizada es práctica cuando necesitáis añadir funcionalidades adicionales que van más allá del conjunto de operaciones estándar de FHIR.

Resumen

El proyecto typeorm-iris ofrece soporte experimental para integrar TypeORM con InterSystems IRIS, permitiendo a los desarrolladores interactuar con IRIS usando los conocidos decoradores y abstracciones de repositorio de TypeORM. Esto ofrece una experiencia de desarrollo más familiar para los desarrolladores de JavaScript y TypeScript que crean aplicaciones Node.js con IRIS como base de datos backend.

Aunque el proyecto implementa los puntos clave de integración con TypeORM y soporta operaciones básicas con entidades, aún no está probado a fondo ni es adecuado para entornos de producción.