Nouvelle publication

Rechercher

Article
· Mai 13 3m de lecture

Actualizar versión IRIS en contenedor docker

No sé a vosotros, pero a mi me ha pasado varias veces que creo un contenedor Docker (me gusta hacerlo con un docker-compose.yml, me resulta más ordenado 😊) con una versión de IRIS, voy haciendo mis pruebas y llega un día en el que la licencia de ese contenedor ya no es válida, y no funciona...

Si os ha pasado, puede que alguno de vosotros, igual que yo, haya pensado "pues con subir la versión de IRIS en el docker-compose/Dockerfile, suficiente". Pues... no 😅 Al hacerlo, da problemas y no arranca bien el contenedor.

Así que, pregunté a InterSystems (gracias @Wojciech Czyz por tu ayuda!!) sobre cómo sería el proceso de actualización de versión en contenedores. Y aquí os dejo una guía paso a paso de cómo hacerlo.

NOTA: Esta guía también es válida si se necesita subir de versión el contenedor en el que estamos trabajando por nuevas funcionalidades o lo que se quiera. Es decir, no es necesario tener que esperar a que el contenedor no arranque para actualizar 😉


Paso a paso

1. Parar la instancia de IRIS (que no el contenedor)

Con el contenedor de IRIS en marcha, accedemos a la instancia de IRIS a través del terminal de docker y la paramos.

  1. Primero, consultamos la lista de contenedores que tenemos en marcha:
    docker ps
  2. Buscamos el nombre del contenedor de IRIS:
  3. Ejecutamos la siguiente instrucción para abrir un terminal dentro del contenedor:
    docker exec -it irishealth sh
  4. Cuando veamos el símbolo $ estaremos dentro:
  5. Escribimos:
    iris stop IRIS
  6. Pulsamos Intro en todas las opciones que aparecen (es decir, dejamos los valores por defecto):
  7. Pulsamos CMD+D para salir de este terminal
  8. Si volvemos a ejecutar:
    docker ps
  9. Veremos que el contenedor sigue en marcha:
  10. Pero no entra al portal:

 

2. Parar el stack de contenedores

Con la instancia de IRIS parada, ahora, paramos el stack de contenedores.

  1. Paramos todos los contenedores que tenemos en marcha con la siguiente instrucción:
    docker stop $(docker ps -q)
  2. Comprobamos que están parados con:
    docker ps
  3. Si tenemos más contenedores en marcha, podemos pararlos por nombre:
    docker stop <nombre_contenedor>

3. Borrar contenedores

Tenemos que posicionarnos en la carpeta donde tenemos el docker-compose.yml de IRIS:

Ejecutamos la siguiente instrucción desde terminal:

docker-compose down

4. Subir versión

Editamos el archivo docker-compose.yml y aumentamos la versión de IRIS, tanto del propio IRIS como del webgaeway (si lo tenemos).

En este caso, editaremos los archivos Dockerfile de las carpetas irishealth y webgateway, subiendo la versión de la 2024.2 a la 2024.3:

5. Levantar contenedor

Posicionados en la carpeta donde tenemos el docker-compose.yml de IRIS, construimos los contenedores:

docker-compose build

Esto descarga las nuevas versiones y construye todo lo necesario:

 

Después, levantamos todo:

docker-compose up

6. Comprobar progreso de actualización

Si en el terminal vemos que el contenedor de IRIS se ha quedado en la siguiente línea:

Tendremos que comprobar si realmente se está actualizando la versión.

  1. Ejecutamos la siguiente instrucción para abrir un terminal dentro del contenedor:
    docker exec -it irishealth sh
  2. Cuando veamos el símbolo $ estaremos dentro:
  3. Escribimos:
    iris list
  4. Veremos lo siguiente:

Esto significa que se está actualizando. Tendremos que esperar un rato hasta que termine (le cuesta varios minutos actualizarse).

Podemos ir ejecutando la misma instrucción cada cierto tiempo, hasta que veamos lo siguiente:

En el terminal donde hemos lanzado el docker-compose up, veremos lo siguiente:

7. Reiniciar contenedor

Cuando haya terminado, accedemos al portal y comprobamos que tenemos la nueva versión instalada:

Ahora vamos a reiniciar el contenedor.

  1. Primero paramos la ejecución de la instrucción que tenemos en marcha con CMD + C.
  2. Ejecutamos la siguiente instrucción desde el terminal:
    docker-compose up -d
1 Comment
Discussion (1)1
Connectez-vous ou inscrivez-vous pour continuer
Annonce
· Mai 13

Concurso de Interoperabilidad de Salud Digital y FHIR de InterSystems 2025

Hola desarrolladores,

Nos complace anunciar el nuevo concurso de programación en línea de InterSystems dedicado a todo lo relacionado con la salud:

🏆 Concurso de Interoperabilidad de Salud Digital y FHIR de InterSystems 🏆

Duración: 12 de mayo - 1 de junio de 2025

Beca total: $12,000


The topic

Develop any interoperability FHIR solution or Healthcare Interoperability solution or a solution that helps to develop or/and maintain interoperability solutions using InterSystems IRIS for Health, Health Connect, or FHIR server.  

General Requirements:

  1. An application or library must be fully functional. It should not be an import or a direct interface for an already existing library in another language (except for C++, there you really need to do a lot of work to create an interface for IRIS). It should not be a copy-paste of an existing application or library.
  2. Accepted applications: new to Open Exchange apps or existing ones, but with a significant improvement. Our team will review all applications before approving them for the contest.
  3. The application should work either on IRIS Community Edition or IRIS for Health Community Edition. Both could be downloaded as host (Mac, Windows) versions from Evaluation site, or can be used in a form of containers pulled from InterSystems Container Registry or Community Containers: intersystemsdc/iris-community:latest or intersystemsdc/irishealth-community:latest .  
  4. The application should be Open Source and published on GitHub or GitLab.  
  5. The README file to the application should be in English, contain the installation steps, and contain either the video demo or/and a description of how the application works.
  6. Only 3 submissions from one developer are allowed.

NB. Our experts will have the final say in whether the application is approved for the contest or not based on the criteria of complexity and usefulness. Their decision is final and not subject to appeal.

 

El concurso

Desarrollar cualquier solución de interoperabilidad FHIR o solución de interoperabilidad de salud, o una solución que ayude a desarrollar y/o mantener soluciones de interoperabilidad utilizando InterSystems IRIS for Health, Health Connect o el servidor FHIR.

Requisitos generales:

  1. La aplicación o biblioteca debe ser completamente funcional. No debe ser una importación ni una interfaz directa para una biblioteca ya existente en otro lenguaje (excepto en C++, donde realmente necesitaréis hacer mucho trabajo para crear una interfaz para IRIS). No debe ser una copia o pegado de una aplicación o biblioteca existente.
  2. Aplicaciones aceptadas: nuevas aplicaciones en Open Exchange o aplicaciones existentes, pero con una mejora significativa. Nuestro equipo revisará todas las aplicaciones antes de aprobarlas para el concurso.
  3. La aplicación debe funcionar en IRIS Community Edition o IRIS for Health Community Edition. Ambas pueden descargarse como versiones de host (Mac, Windows) desde el sitio de Evaluación o pueden usarse en forma de contenedores obtenidos desde el InterSystems Container Registry o Community Containers: intersystemsdc/iris-community:latest o intersystemsdc/irishealth-community:latest.
  4. La aplicación debe ser Open Source y publicada en GitHub o GitLab.
  5. El archivo README de la aplicación debe estar en inglés, contener los pasos de instalación y contener una demo en video y/o una descripción de cómo funciona la aplicación.
  6. Solo se permiten 3 envíos por desarrollador.

Nota: Nuestros expertos tendrán la última palabra sobre si la aplicación es aprobada para el concurso o no, basándose en los criterios de complejidad y utilidad. Su decisión es final y no susceptible de apelación.

Premios

1. Nominación de Expertos: un jurado especialmente seleccionado determinará a los ganadores.

🥇 1er lugar - $5,000 

🥈 2do lugar - $2,500 

🥉 3er lugar - $1,000

🏅 4to lugar - $500

🏅 5to lugar - $300

🌟 6-10 posiciones - $100

2. Ganadores de la Comunidad: aplicaciones que reciban la mayor cantidad de votos en total.

🥇 1er lugar - $1,000 

🥈 2do lugar - $600 

🥉 3er lugar - $300

🏅 4to lugar - $200

🏅 5to lugar - $100

❗ Si varios participantes obtienen la misma cantidad de votos, todos serán considerados ganadores y el premio en efectivo se dividirá entre los ganadores.
❗ Los premios en efectivo solo se otorgan a aquellos que puedan verificar su identidad. Si hay alguna duda, los organizadores se pondrán en contacto y solicitarán información adicional sobre el/los participante(s).

 

¿Quién puede participar?

Cualquier miembro de la Comunidad de Desarrolladores, excepto los empleados de InterSystems (se permiten contratistas de ISC). ¡Crea una cuenta!

Los desarrolladores pueden formar equipos para crear una aplicación colaborativa. Se permiten de 2 a 5 desarrolladores por equipo.

No olvidéis resaltar a los miembros de vuestro equipo en el archivo README de vuestra aplicación – perfiles de usuario de DC.

Fechas importantes:
🛠 Fase de desarrollo y registro de la aplicación:

  • 12 de mayo de 2025 (00:00 EST): Comienza el concurso.
  • 25 de mayo de 2025 (23:59 EST): Fecha límite para enviar aplicaciones.

✅ Período de votación:

  • 26 de mayo de 2025 (00:00 EST): Comienza la votación.
  • 1 de junio de 2025 (23:59 EST): Fin de la votación.

Nota: Los desarrolladores pueden mejorar sus aplicaciones durante todo el período de registro y votación.

    Recursos útiles

    ✓ Documentación:

    ✓ Herramientas:

    • Clinfhir - Herramienta de visualización y desarrollo FHIR.

    ✓ Ejemplos de aplicaciones:

    ✓ Cursos online:

    ✓ Vídeos:

    ✓ Para principiantes en IRIS:

    ✓ Para principiantes en ObjectScript Package Manager (IPM):

    ✓ Cómo enviar vuestra aplicación al concuso:

    ¿Necesitáis ayuda?

    Uníos al canal del concurso en el servidor de Discord de InterSystems o hablad con nosotros en los comentarios de esta publicación.

    Estamos esperando VUESTRO proyecto – ¡uníos a nuestro maratón de código para ganar!


    Al participar en este concurso, aceptáis las condiciones del mismo que se detallan aquí. Leedlas con atención antes de continuar.

    Discussion (0)1
    Connectez-vous ou inscrivez-vous pour continuer
    Article
    · Mai 13 2m de lecture

    Contenedor de IRIS con una huella mínima

    A veces, los clientes necesitan una instancia pequeña de IRIS para hacer algo en la nube y luego apagarla, o necesitan cientos de contenedores (es decir, uno por usuario final o uno por interfaz) con cargas de trabajo pequeñas. Este ejercicio surgió para ver cuán pequeña podría ser una instancia de IRIS. Para este ejercicio, nos centramos en cuál es la menor cantidad de memoria que podemos configurar para una instancia de IRIS. ¿Conocéis todos los parámetros que afectan la memoria asignada por IRIS?

    Configuración de memoria

    Estos son los distintos bloques que afectan la asignación de memoria por parte de IRIS y sus parámetros correspondientes:

    • Buffers globales (32 MB) => El mínimo parece ser 32 MB para bases de datos de 8k
    • Buffers de rutinas (26 MB) => El mínimo teórico según la documentación es 430 buffers x 64k por buffer, lo que equivale a aproximadamente 26 MB, y en la práctica también es 26 MB
    • Buffers de journaling (16 MB) => En teoría y en la práctica, el mínimo para un sistema Unicode es 16 MB (8 MB para sistemas de 8 bits)
    • Descriptores de buffer (3 MB) => Parece ser de 3 MB, no se puede ajustar
    • gmheap (16 MB) => El mínimo es 256 páginas x 64k por página = 16 MB (configurado en bytes en el CPF = 16384)
    • ECP (1 MB) => Hay un par de parámetros en el CPF que controlan esto: MaxServerConn y MaxServers. Incluso con MaxServerConn=0 y MaxServers=0, el mínimo sigue siendo 1 MB porque IRIS asigna memoria a esas estructuras independientemente de si usas ECP o no. Con MaxServerConn=1 y MaxServers=2, el valor predeterminado es 5 MB
    • Varios (15 MB) => Según mis pruebas, el mínimo parece ser 15 MB. No pude reducirlo más.

    Con todos estos ajustes configurados de esta manera, los parámetros del CPF se verían de la siguiente forma:

    globals=0,0,32,0,0,0
    routines=0,0,0,0,0,26
    jrnbufs=16
    gmheap=16384
    MaxServerConn=0
    MaxServers=0

    Entonces, si configuras IRIS con estos parámetros (yo usé IRIS 2024.1) en el archivo CPF, se puede esperar que el total mínimo de memoria asignada por IRIS al iniciar (excluyendo los procesos de usuario) sea de 111 MB. Podéis ver la memoria asignada por IRIS en el archivo messages.log.

     

     

    Bueno, lo sé, debe haber algún redondeo involucrado porque si sumas todos los valores individuales obtienes 109 MB, pero en el archivo messages.log se informa como 111 MB.

    Durante este proceso, también descubrimos que los contenedores de IRIS no podían asignar páginas grandes (Huge Pages), lo cual fue reportado y corregido en versiones posteriores por InterSystems.

    Por cierto, este artículo también puede servir como una guía general para aprender sobre los diferentes parámetros de memoria que se pueden ajustar dentro de IRIS para obtener un mejor rendimiento.

    ¡Espero que os haya gustado!

    Discussion (0)1
    Connectez-vous ou inscrivez-vous pour continuer
    Article
    · Mai 13 2m de lecture

    Using %System.Monitor.LineByLine together with %SYS.MONLBL to analyze your code

    I'm sure most of you are familiar with utility %SYS.MONLBL that is crucial when analysing code performance bottlenecks. It allows you to select a number of routines that you want to monitor at runtime and also specify what process(es) you want to watch. BUT, what if you do not know exactly, what process would execute your code? This is true with many web based (CSP/REST) applications today. You want to minimize the resource utilization on your production system that needs analysis. So, how about doing a small tweak?

    1. Define an INC file with these macros:

    #define START(%level) try { ##continue 
    s zzroutine=$p($view(-1,-3),"^",6) ##continue 
    if ##class(%Monitor.System.LineByLine).IsActive(zzroutine)=0 { ##continue $$$ThrowOnError(##class(%Monitor.System.LineByLine).Start($lfs(zzroutine),$lfs(##class(%Monitor.System.LineByLine).GetMetrics(%level)),$lb($job))) ##continue } ##continue 
    h 1 ##continue 
    } catch (e) { ##continue
     d BACK^%ETN ##continue 
    } 
    
    #define PAUSE s sc=##class(%Monitor.System.LineByLine).Pause()

    2. in your class, or routine, identify a place you want to monitor and put these two macros to start collecting data and pausing collection, like in this example:

    $$$START(2)   // use 1 or 2 here
    
    // code of your application here
    
    $$$PAUSE

    Whenever you run this code (method of a class or routine) this would try to start %SYS.MONLBL for this particular class or routine and process.

    Once your code is finished, you can simply go to terminal in the namespace where your application runs and call d ^%SYS.MONLBL. As START macro started monitor, it is still running and you can easily collect your performance data, optionally together with source code. Do not forget to stop monitor, once you have collected your data!

    If you need to collect data for more routines, you can easily modify  the START macro to allow for manual entry of routines list to analyze.

    Hope you find this little tweak useful!

    2 Comments
    Discussion (2)2
    Connectez-vous ou inscrivez-vous pour continuer
    Annonce
    · Mai 13

    FHIR France Meetup #13

    Hello Community!

    We're excited to announce that the FHIR France Meetup is making a comeback... in person at SantExpo 2025!

    📅 Dates: May 21, 2025, starting at 7:00 PM

    📌 Location: Halles d'Issy - Biltoki, 1 Rue Rouget de Lisle, Issy-les-Moulineaux, Paris, France

    Meetup FHIR France #13 : PARIS

    Program:

    • 7:00 p.m.: Welcome of participants
    • 7:30 p.m. – 9:00 p.m.: Presentations and discussions:
      • "How do the FHIR APIs of the ANS Multi-Terminology Server (SMT) help manage Europe's terminological artifacts?" by Abdelali BOUSSADI and Yohann POIRON (Agence du Numérique en Santé)
      • "The Advantages and Benefits of the Toulouse University Hospital's FHIR Platform: From Frameworks to Architecture" by Paul ORTEGA and Christian COUDER (CHU de Toulouse)
      • "Intelligent Querying with FHIR – OWL – LLM" by @Yann de Cambourg (Synodis), Guillaume POULERIGUEN (ftprod), Vincent HENRY (Jarod Knowledge Science)
      • "Predicting and Preventing Life-Saving Emergencies with HL7 FHIR" by Quentin FRANCOIS (PREVIA MEDICAL)
    • after 9:00 p.m.: Cocktail and Networking

    Registration

    The event is free, but places are limited. Please register via the official Meetup page:

    👉 Register here 👈

    This meetup is an excellent opportunity to discover concrete FHIR use cases, connect with experts, and strengthen the French-speaking community around healthcare interoperability.

    We hope to see you there!

    Discussion (0)1
    Connectez-vous ou inscrivez-vous pour continuer