Nova postagem

Pesquisar

Artigo
· Fev. 20 2min de leitura

Celebrating a True Educator of the Developer Community

Among the numerous authors of the InterSystems Developer Community, some members stand out for their dedication and lasting impact. One such member is @Mihoko Iijima, whose journey with InterSystems spans over two decades. From her early experiences with Caché to her deep involvement in the Developer Community, she has continuously contributed to knowledge-sharing and collaboration, shaping the experience for fellow developers.

🤩 Let's take a closer look at Mihoko's journey with InterSystems technology and our Developer Community...

Mihoko's journey with InterSystems began in the early 2000s when she first worked with Caché 3.2.1. She joined InterSystems Japan in 2003 and became an active member of the Developer Community in 2015. Over the years, Mihoko has witnessed significant technological changes, including the launch of InterSystems IRIS, which broadened her knowledge in areas like machine learning and containerization.

One of Mihoko’s most memorable projects involved developing a web application interface, an experience that provided a foundation for her future career. Taking on responsibilities from customer interactions to configuration and testing, she gained invaluable skills that she applies to her work today. As a trainer at InterSystems, she faced challenges such as technical failures during training. Thanks to support from colleagues, she developed strategies to troubleshoot issues efficiently and enhance training sessions.

Mihoko’s involvement with the Developer Community began with a ZenMojo training course. She and her colleague, @Megumi Kakechi, saw value in sharing their experiences, leading them to post questions and solutions in the Community. This initiative grew into active participation in the Japanese Developer Community, where Mihoko contributed to the FAQ system, helped manage contests, and promoted events.

Seeing her articles translated into different languages and receiving international feedback has been especially rewarding for Mihoko. She believes that even with language barriers, developers worldwide share common challenges and goals. Her advice to newcomers is simple: start by engaging with content, whether through likes, questions, or articles - every contribution is important.

Outside of work, Mihoko pursues her passion for karate, working toward a black belt while participating in competitions.

We are immensely grateful for Mihoko's unwavering support of the Developer Community. Her journey reflects dedication, adaptability, and a commitment to learning, making a lasting impact on everyone she (virtually) meets. Here's to Mihoko - a true champion of the Developer Community, whose journey inspires us all to strive for more and embrace the future with learning and collaboration.

👏 Let's all congratulate Mihoko and thank her for her contributions to InterSystems and our Developer Community! 

13 Comments
Discussão (13)6
Entre ou crie uma conta para continuar
Pergunta
· Fev. 20

Automatizar tarefa de extração de dados

Prezados, é possivel automatizar tarefas de extração de dados no caché?

Ex: Gerar uma tarefa que executa diariamente uma consulta e armazena os dados em um arquivo csv. 

6 Comments
Discussão (6)2
Entre ou crie uma conta para continuar
Pergunta
· Fev. 20

MAXSTRING error on conversion to JSON in FHIR R4 DTL

I'm working on FHIR project and using this code to convert an incoming request to FHIR 

Method OnRequest(request As HS.FHIRServer.Interop.Request, Output response As HS.FHIRServer.Interop.Response) As %Status

{

    #dim tSC As %Status = $$$OK

    Try {

        // Process incoming request

       

        set stream = ##class(HS.SDA3.QuickStream).%OpenId(request.QuickStreamId)

        set bundle = ##class(HS.FHIR.DTL.vR4.Model.Resource.Bundle).FromJSON(stream,"vR4")

 



It's working ok but when I include a realistic PDF in a FHIR Binary resource (contained in the Bundle) I get a MAXSTRING error. 

Looking at the documentation for HS.FHIR.DTL.vR4.Model.Resource.Binary, I wondering if MAXLEN setting for data is missing and data MAXLEN = 50. 
 

Property contentType As %String(MAXLEN = 1000000, XMLNAME = "contentType", XMLPROJECTION = "ATTRIBUTE") [ Required ];

Property data As %Binary(XMLNAME = "data", XMLPROJECTION = "ATTRIBUTE");


 

9 Comments
Discussão (9)2
Entre ou crie uma conta para continuar
InterSystems Oficial
· Fev. 20

Alerte : les requêtes SQL renvoient des résultats erronés

19 février 2025 – Alerte : les requêtes SQL renvoient des résultats erronés

InterSystems a corrigé deux problèmes pouvant entraîner le renvoi de résultats erronés par un petit nombre de requêtes SQL. De plus, InterSystems a corrigé une incohérence dans la gestion des types de données date/heure qui peut entraîner des résultats différents, inattendus, mais corrects, pour les applications existantes qui s'appuient sur le comportement antérieur et incohérent.

DP-436825 : les requêtes SQL avec jointure latérale peuvent renvoyer des résultats erronés

Le premier problème (DP-436825) affecte uniquement les requêtes SQL qui utilisent une jointure latérale, implicitement ou explicitement, sur une instance configurée avec une limite de mémoire par processus non par défaut (paramètre « bbsiz » dans le fichier .cpf). Une nouvelle installation d'InterSystems IRIS a une valeur bbsiz par défaut de -1 (il n'y a donc pas de limite de mémoire), tandis qu'une mise à niveau à partir d'une version plus ancienne conserverait le paramètre précédent. Lorsqu'une telle requête utilise l'exécution parallélisée au moment de l'exécution, y compris les cas où le système utilise l'exécution parallélisée, la requête peut renvoyer des résultats incorrects. Ce problème affecte les versions 2023.3, 2024.1.0, 2024.1.1, 2024.1.2, 2024.2 et 2024.3 des produits suivants :

  • Plateforme de données InterSystems IRIS®
  • InterSystems IRIS® for Health
  • HealthShare® Health Connect

Le problème affecte également d'autres produits InterSystems basés sur les produits ci-dessus, notamment HealthShare® Unified Care Record et Suite : Version 2024.2 Bien que le dossier de soins unifié et la suite n'utilisent pas de requêtes SQL qui utilisent une jointure latérale dans le code du produit, les clients HealthShare qui effectuent une mise à niveau vers HealthShare 2024.2 avec une limite de mémoire par processus non par défaut qui écrivent également leurs propres requêtes SQL qui utilisent une jointure latérale peuvent être affectés.

Pour éviter ce problème, utilisez l'une des trois options suivantes :

  • Supprimez la limite de mémoire par processus en définissant le paramètre bbsiz sur -1.
  • Utilisez le mot clé %NOPARALLEL dans les requêtes qui incluent une jointure latérale.
  • Désactivez temporairement le mode adaptatif pour l'instance, ce qui évite le traitement parallèle automatique des requêtes éligibles.

Tout cela garantit que la requête renvoie des résultats corrects. La correction de ce défaut est identifiée comme DP-436825 et sera incluse dans toutes les futures versions du produit à partir de 2024.1.3 et 2025.1.0. Elle est également disponible via une distribution ad hoc.

DP-436998 : requêtes SQL avec tri inversé par %ID entrant dans une boucle sans fin

Le deuxième problème (DP-436998) affecte les requêtes SQL qui classent par ID de ligne décroissant et dans lesquelles l'ID de ligne est un entier positif (compatible bitmap) et en particulier, les circonstances spécifiques aux données. Dans ces conditions, la requête peut entrer dans une boucle sans fin et continuer à renvoyer le même ensemble de résultats jusqu'à ce qu'elle soit abandonnée. Ce problème affecte les versions 2022.2, 2022.3, 2023.x et 2024.x des produits suivants :

  • Plateforme de données InterSystems IRIS®
  • InterSystems IRIS® for Health
  • HealthShare® Health Connect

Il affecte également d'autres produits InterSystems basés sur les produits ci-dessus, notamment HealthShare® Unified Care Record and Suite : Version 2024.1 et version 2024.2. Bien que le dossier de soins unifié et la suite n'utilisent pas de requêtes SQL avec tri inversé par %ID dans le code produit, les clients HealthShare 2024.1 et HealthShare 2024.2 qui écrivent leurs propres requêtes SQL avec tri inversé par %ID peuvent être concernés. La correction de ce défaut est identifiée comme DP-436998. Elle sera incluse dans toutes les futures versions de produits à partir de 2023.1.6, 2024.1.3 et 2025.1.0. Elle est également disponible via une distribution ad hoc.

DP-436633 : Requêtes SQL comparant les valeurs DATE et TIMESTAMP

InterSystems a récemment corrigé une incohérence dans la manière dont les valeurs DATE et TIMESTAMP sont comparées à l'aide des opérateurs <=, > et BETWEEN. Cette correction modifie les résultats de comparaisons de date et d'heure particulières. Le comportement mis à jour a été introduit dans la version 2023.3 de :

  • Plateforme de données InterSystems IRIS®
  • InterSystems IRIS® for Health
  • HealthShare® Health Connect

Elle affecte également d'autres produits InterSystems basés sur les produits ci-dessus, notamment HealthShare® Unified Care Record and Suite : Version 2024.2.

Elle s'applique à toutes les versions ultérieures.

Avec le comportement mis à jour, les valeurs DATE sont converties en une valeur TIMESTAMP avant la comparaison. Cela est conforme à la norme SQL qui consiste à convertir le type de données le moins précis en type de données le plus précis.

Par exemple, avec le nouveau comportement (conforme à la norme), un prédicat de requête « MyTimeStamp > MyDate » est évalué à FAUX lorsque les valeurs de ces champs correspondent à la même date de calendrier, sauf lorsque MyTimestamp correspond exactement à minuit. Auparavant, le comportement n'était entièrement conforme à la norme que lorsque le champ MyTimeStamp était défini avec le format %PosixTime et renvoyait des résultats non conformes dans certains cas lors de l'utilisation de %Timestamp ou de certaines combinaisons de fonctions et variables spéciales.

Pour garantir des comparaisons prévisibles, InterSystems recommande d'utiliser des fonctions CAST explicites, en particulier lors de l'utilisation d'instructions CASE ou de fonctions SQL telles que GETDATE(), NVL() et IFNULL(), où le type résultant peut ne pas être évident.

 

Pour aider à évaluer les instructions affectées par le changement de comportement, InterSystems a introduit un avertissement dans le plan de requête et un indicateur système facultatif pour que ces instructions génèrent une erreur lors de l'exécution. L'activation de l'indicateur peut être utile lors des tests de régression du code d'application et peut offrir un filet de sécurité supplémentaire pour les requêtes utilisateur lors de l'exécution. Cette fonctionnalité d'information est identifiée comme DP-436633 et sera incluse dans toutes les futures versions du produit à partir de 2024.1.4 et 2025.1.0.

Informations complémentaires

Si vous subissez l'impact de ce défaut, contactez le Worldwide Response Center (WRC) pour obtenir de l'aide.

Discussão (0)0
Entre ou crie uma conta para continuar
Artigo
· Fev. 20 3min de leitura

Configurando la replicación o Mirroring para productos de Health Share

Es posible que hayáis notado que, para configurar un mirror en InterSystems IRIS for Health™ y HealthShare® Health Connect, hay un requisito especial. En este artículo, quiero guiaros paso a paso por el proceso.

Esto supone que ya habéis configurado el segundo miembro de conmutación por error y habéis confirmado un estado exitoso de dicho miembro en el monitor del mirror:

Paso 1: Activad el usuario HS_Services (en el servidor de respaldo y en el principal).

 

Paso 2: Cambiad al espacio de nombres HSSYS y dirigíos a Interoperabilidad > Configurar > Credenciales. Introducid la contraseña para vuestro usuario HS_Services predefinido (en el servidor de respaldo y en el principal).

Paso 3: Programad la tarea de lanzamiento del Monitor de Duplicación (en el servidor de respaldo y en el principal). Hacedlo ejecutando lo siguiente desde el terminal de IRIS en el espacio de nombres HSSYS:

HSSYS>do ##class(HS.Util.Mirror.Task).Schedule("HSSYS")

Confirmad que se ha programado correctamente y que está configurado para ejecutarse cada cinco minutos:

Paso 4: Añadid la base de datos HSSYS a la duplicación en el servidor principal. Id a Administración del Sistema > Configuración > Configuración del Sistema > Bases de Datos Locales. Seleccionad "Añadir al Mirror" y escoged HSSYS.

Paso 5: Desmontad HSSYS de los servidores principal y de respaldo. Id a Operación del Sistema > Bases de Datos, seleccionad HSSYS y escoged "Desmontar".

Paso 6: Copiad el archivo HSSYS IRIS.DAT del servidor principal al directorio adecuado de HSSYS en el servidor de respaldo.

Aseguraos de que los permisos sean los adecuados. Deberíais ver algo como esto:

-rw-rw---- 1 irisowner irisowner 22020096 Jan 12 15:26 IRIS.DAT

Si no veis esto, modificadlo con chown y chmod para que sea así.

Paso 7: Montad la base de datos en el servidor principal. Id a Operación del Sistema > Bases de Datos, seleccionad HSSYS y escoged "Montar". Elegid "¿Iniciar la sincronización del mirror?" pero no seleccionéis "Solo lectura".

Paso 8: Montad la base de datos en el servidor de respaldo. Id a Operación del Sistema > Bases de Datos, seleccionad HSSYS y escoged "Montar". No seleccionéis "Solo lectura". No habrá la opción de "Iniciar la sincronización de la duplicación".

Paso 9: En vuestro servidor de respaldo, abrid el Monitor de Duplicación (Operación del Sistema > Monitor de Mirror). Ahora deberíais ver HSSYS añadida a vuestra lista de bases de datos duplicadas. Pero tenéis que hacer clic en "Activar" para que se inicie la sincronización.

Después de unos segundos, vuestro servidor de respaldo debería estar "Sincronizado".

HSSYS ya está duplicada.

Y deberíais ver el Agente del Monitor de Mirror en ejecución (Salud > Agente del Monitor de Mirror).

Paso 10: Configurad el Nombre de Host de la Red en el servidor principal (Inicio > Salud > Asistente de Instalación).

El Nombre de Host de la Red debe estar configurado con el VIP de la duplicación (o la entrada DNS para el VIP de la duplicación).

Paso 11: Configurad la Comunicación Segura.

Paso 12 (opcional): Configurad la Fundación.

Recordad activar vuestro Namespace una vez que esté creado.

Dado que seleccionamos Base de Datos de Mirror, deberíais verla en vuestras Bases de Datos de Mirror en el Monitor de Mirror.

El requisito adicional de duplicación para productos de Healthshare ya está completo, y al probar una conmutación por error, vemos que ambos servidores están sincronizados según el Agente del Monitor de Mirror.

Ahora podéis configurar vuestros Puntos de conexión FHIR y ver cómo las bases de datos de recursos (R) y historial de recursos (V) se duplican automáticamente.

2 Comments
Discussão (2)1
Entre ou crie uma conta para continuar