検索

質問
· 2025年10月8日

Web interface for maintaining custom lookup classes (SQL) in HealthShare

Hi Team, 

Can I please check if anyone has built a simple web interface for maintaining custom SQL lookup class.   

We have a simple persistent class in HealthShare which is used for storing Pathology test codes. Test codes in this lookup class is used for message filtering and applying additional logic when processing pathology results/orders. 

We want to make this class available to external users from pathology (not the usual management portal users) to maintain so that they can add/edit/delete test codes as required. 

Has anyone implemented something similar to expose the HealthShare SQL class via web page or App or something?

Thank you for your help. 

2 Comments
ディスカッション (2)2
続けるにはログインするか新規登録を行ってください
お知らせ
· 2025年10月8日

September Article Bounty: Community Spotlight

It’s time to bring some spotlight to the authors and participants of our September Article Bounty! A big thank-you to everyone who took part💙

Special shout-out to those who took the time to write brand-new articles and share their expertise (each received 5,000 points 🎉):

@Robert Cemper >> "IRIS in Docker for beginners"
@sween  >> "IKO Plus: Stretched Cross Regional IrisCluster with Tailscale on Google Cloud Platform"
@Ariel Glikman >> "High Availability IAM"
@Pietro Di Leo >> "Running InterSystems IRIS with Docker: A Step-by-Step Guide - Part 1: From the Basics to Custom Dockerfile"
@Guilherme Tonelotti  >> "Create a JDBC connection with Mysql Cache"
@Vachan C Rannore >> "From "Oops" to "Aha!" - Avoiding Beginner Mistakes in ObjectScript"

And also to those who joined the challenge and helped us in the search for interesting articles (each received 30 points 🙌):

@Roger Merchberger 
@Marcelo Witt 
@Padmaja Konduru 
@Cole Wennerholm Wennerholm

👏 Thank you for your effort, creativity, and willingness to share knowledge.

And the good news is… the new Article Bounty is already waiting for you on Global Masters! Don’t miss the chance to take part and earn rewards this month.

ディスカッション (0)1
続けるにはログインするか新規登録を行ってください
記事
· 2025年10月8日 1m read

Cómo visualizar las configuraciones de vuestro servidor InterSystems usando Structurizr

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.

Al usar la API Nativa de InterSystems IRIS para Node.js se evita la necesidad de instalar cualquier código de soporte en los servidores. Esta elección tecnológica también le permite participar en el concurso actual de la Comunidad de Desarrolladores.

La versión inicial se centra en dos aspectos de la configuración del servidor:

  • Espacios de nombres y bases de datos
  • Conectividad ECP

Se agradecen las sugerencias sobre qué añadir a continuación, así como cualquier comentario general.

ディスカッション (0)1
続けるにはログインするか新規登録を行ってください
お知らせ
· 2025年10月8日

Es hora de votar en el concurso de InterSystems sobre .Net, Java, Python y JavaScript.

Hola, comunidad:

¡Ha llegado la hora de votar! Emitid vuestros votos por las mejores aplicaciones en nuestro concurso de InterSystems sobre .Net, Java, Python y JavaScript:

🔥 VOTAD POR LAS MEJORES APPS 🔥

¿Cómo votar? Los detalles aquí abajo

Nominación de expertos:

Un jurado experimentado de InterSystems elegirá las mejores aplicaciones para nominarlas a los premios en la categoría de Nominación de Expertos.

Nominación de la comunidad:

Todos los miembros activos de la Comunidad de Desarrolladores que tengan el estado “trusted” en su perfil pueden votar en la Nominación de la Comunidad. Para comprobar vuestro estado, haced clic en vuestra foto de perfil en la esquina superior derecha, y lo veréis debajo de vuestra imagen. Para convertiros en miembros de confianza, debéis participar al menos una vez en la Comunidad.

¡Voto ciego!

El número de votos de cada aplicación estará oculto para todos. Publicaremos la clasificación en la sección de comentarios de esta publicación a diario. Los expertos pueden votar en cualquier momento, por lo que es posible que las posiciones cambien drásticamente en el último momento. Lo mismo se aplica a los puntos extra.

El orden de los proyectos en la página del concurso se determinará según el momento en que se hayan enviado las aplicaciones, apareciendo más arriba las presentaciones más tempranas.

P. D. No olvidéis suscribiros a esta publicación (haced clic en el icono de la campana) para recibir notificaciones de nuevos comentarios.

Para participar en la votación, necesitáis:

  1. Iniciar sesión en Open Exchange – sirve con las mismas credenciales de la Comunidad de Desarrolladores. 
  2. Hacer alguna contribución válida en la Comunidad de Desarrolladores – responder o hacer preguntas, escribir un artículo o publicar aplicaciones en Open Exchange – y podréis votar. Consultad esta publicación sobre las opciones para hacer contribuciones útiles a la Comunidad de Desarrolladores.

Si cambiáis de opinión, podéis cancelar vuestra elección y dar vuestro voto a otra aplicación.

¡Apoyad la aplicación que más os guste!


Nota: Los participantes del concurso pueden corregir errores y mejorar sus aplicaciones durante la semana de votación, así que aseguraos de suscribiros a las actualizaciones de las aplicaciones

ディスカッション (0)1
続けるにはログインするか新規登録を行ってください
ディスカッション
· 2025年10月8日

What strategy do you use to maintain different settings of Interoperability Productions across DEV, TEST, and PROD environments?

I know the next ones:

1. Place all different settings in environment variables. You have a different .env file for each environment, and you must add some code to Production for reading and setting these values. It's good for deploying into containers, but challenging for management when we have a large production. I mean, we have many settings that can vary depending on the environment: active flag, pool size, timeouts, and so on. Not only endpoints.

2. My own case. A deployment script that saves Production settings before pulling from git the current state of Production, and restores the start settings after. In this way, each environment has those settings that were set in the Management Portal last time. The Production class is controlled by git (it keeps the default settings for added elements). Needs additional code for deployment as minus. And the content of Productions should be the same in all environments (like in the first solution, however).

3. Default Settings - official way to solve this problem, as I understand it. Not tried it, can say nothing... Is somebody using it? Does it work, useful?

4. Different production classes for each environment, I mean: TestProd.cls, DevProd.cls, etc. Not tried it yet, but it looks easy, no need for additional code, can be different content in Productions. Its obvious disadvantage: you must configure each item twice (or more times) for each Production.

What do you use? I skipped something? I would like to invite you to take part in the discussion.

10 Comments
ディスカッション (10)3
続けるにはログインするか新規登録を行ってください