#HealthShare

La nouveauté de la version 2023.3 (d'InterSystems IRIS for Health) est une fonctionnalité permettant d'effectuer une validation basée sur le profil FHIR.

 (*)

Dans cet article, je vais fournir un aperçu de base de cette fonctionnalité.

Si FHIR est important pour vous, vous devriez absolument essayer cette nouvelle fonctionnalité, alors poursuivez votre lecture.

InterSystems FAQ rubric

Si le système ne s'arrête pas pendant 24 heures, les anciens fichiers journaux seront supprimés à 0h30 selon les « Paramètres de suppression des fichiers journaux ».

Une cause possible pour laquelle des fichiers journaux restants sont plus anciens que les « Paramètres de suppression des fichiers journaux » est que certaines transactions restent ouvertes.

Dans ce cas, vous pourrez supprimer le fichier journal en recherchant les processus exécutant les transactions et en finalisant les transactions.

Health Data De-Identifier est disponible via InterSystems' Early Access Program afin de vous donner un aperçu de ce sur quoi nous travaillons. Ce document vous expliquera comment vous inscrire.

Pour en savoir plus: Health Data De-ID Early Access Program

1. Accéder evaluation.intersystems.com. Si vous disposez déjà d'informations d'identification, passez à l'étape 7.

2. Créer un nouveau compte en cliquant sur Register for a new account.

3. Remplissez toutes les informations requises et enregistrez.

4. Vous recevrez un email avec la confirmation et le token d'accès.

5. Fournissez le token d'accès reçu par e-mail.

6. Choisissez un mot de passe.

7. Envoyer un courriel à deidevaluation@intersystems.com demander l'accès (cliquez sur le lien pour un accès rapide). Il est important de demander l'accès pour le même e-mail que vous avez utilisé lors du processus d'inscription.

8. Une fois que vous avez reçu la confirmation de votre inscription, connectez-vous à evaluation.intersystems.com et cliquez sur Télécharger les programmes d'accès anticipé.

9. Sélectionner Health Data De-Identifier. Assurez-vous de lire et d'accepter les Conditions d'utilisation de l'accès anticipé puis cliquez sur Download All.

InterSystems FAQ rubric

Les définitions de classe créées par les utilisateurs sont stockées dans des classes de définition de classe. Ils peuvent être utilisés pour obtenir une liste de définitions de classe à partir d'un programme.

Remarque : Les classes de définition de classe font référence à toutes les classes contenues dans le package %Dictionary.

Dans l'exemple de code ci-dessous, une liste de définitions de classe est obtenue à l'aide de la commande query Summary de la  classe %Dictionary.ClassDefinitionQuery.

Nous revoilà avec un article lié au Mirroring !

Dans l'article précédent, nous avons vu comment configurer un Miroir entre deux instances IRIS, l'une agissant comme un nœud actif et l'autre comme un nœud passif. Ce système de mise en miroir fonctionne sur le transfert d'un fichier journal qui maintient à jour en permanence l'instance qui fonctionne comme un nœud passif, mais que se passe-t-il si, en raison d'un échec de communication ou d'autorisations du fichier journal, celui-ci n'est pas transféré correctement ?

Salut la Communauté!

Profitez de regarder la nouvelle vidéo pour découvrir les plateformes de données InterSystems IRIS et InterSystems IRIS for Health, les familles de produits HealthShare et InterSystems TrakCare. 

📺 Introduction aux produits InterSystems

Dans le monde du Big Data, la sélection du bon format de fichier est cruciale pour un stockage, un traitement et une analyse efficaces des données. Avec la quantité massive de données générées chaque jour, le choix du format approprié peut avoir un impact considérable sur la vitesse, le coût et la précision des tâches de traitement des données. Il existe plusieurs formats de fichiers disponibles, chacun avec son propre ensemble d'avantages et d'inconvénients, ce qui rend complexe le choix de celui à utiliser. Certains des formats de fichiers Big Data populaires incluent CSV, JSON, Avro, ORC et

InterSystems FAQ rubric

Il n'est pas nécessaire de recompiler les routines après la mise à niveau de la version, mais comme la mise à jour de la version écrase %SYS, les routines au format INT et OBJ créées par l'utilisateur (*.INT,*.OBJ) dans %SYS seront supprimées. Par conséquent, vous devez être prudent.

Les routines MAC, INT et OBJ portant les noms suivants ne sont pas supprimées.

%Z*.INT, %z*.INT, Z*.INT,z*.INT
%Z*.OBJ, %z*.OBJ, Z*.OBJ,z*.OBJ

Veuillez noter que les classes/CSP doivent être compilées après la mise à niveau.

Bonjour les développeurs,

Commencez à regarder notre dernière vidéo sur InterSystems Developers YouTube:

⏯ North West London Integrated Care System Go Live with Health Connect Cloud @ Global Summit 2023

InterSystems FAQ rubric

Si plusieurs produits InterSystems sont installés sur le même système, la dernière version du pilote ODBC InterSystems parmi les produits installés restera enregistrée dans le gestionnaire de pilotes.

Vous pouvez passer à n'importe quel pilote en modifiant l'entrée de la registry ci-dessous.

Veuillez noter que l'exécution de RegFiles.bat ne modifie pas le pilote ODBC.

L'entrée de la registry est la suivante.

HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\InterSystems ODBC35 key Driver
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\InterSystems ODBC35 key Setup

Rubrique Questions fréquentes (FAQ) d'InterSystems

Pour les routines (*.mac)

Vous pouvez masquer la source en exportant/important uniquement le fichier *.obj généré après la compilation du programme source.

L'exemple d'exécution de la commande spécifie EX1Sample.obj et EX2Sample.obj, qui sont générés par la compilation de EX1Sample.mac et EX2Sample.mac, comme cibles d'exportation et les exporte dans le deuxième fichier argument.

Après avoir changé d'espace de noms, j'utilise le fichier XML exporté pour effectuer l'importation.

Nous sommes ravis d'annoncer le dernier ajout à notre programme d'accès anticipé (EAP - Early Access Program) : l'outil - the Health Data De-ID.

L'outil désidentifiera les données cliniques structurées conformément au HIPAA Safe Harbor et permettra une réidentification si nécessaire. Il utilise le format canonique SDA d'InterSystems qui est utilisé pour toutes nos transformations standards d'un format à un autre, telles que HL7 en CDA, HL7 en FHIR, etc. Cet outil utilise des transformations XSLT pour de meilleures performances. De fait, il fournit des méthodes d'assistance qui permettent un ajustement plus facile des règles de désidentification prêtes à l'emploi pour lesquelles vous n'avez pas besoin d'être un expert XSLT.

Health Data De-ID fonctionne sur n'importe quel produit InterSystems, d'InterSystems IRIS for Health à Health Connect en passant par Unified Care Record.

Vous pouvez rejoindre le programme d'accès anticipé ici - Inscription au programme d'accès anticipé au désidentification des données de santé. Nous avons besoin de vos commentaires, alors n'hésitez pas à nous contacter tout au long du processus ou si vous avez des questions.

InterSystems a corrigé deux défauts concernant la connectivité. Ces défauts et leurs corrections sont indépendants les uns des autres.

Cette alerte les concerne tous les deux, car il existe des versions intermédiaires contenant les deux corrections.

Les deux défauts affectent uniquement les versions 2019.1.4 et 2020.1.4 de :

• InterSystems IRIS®
• InterSystems IRIS for Health™
• HealthShare® Health Connect

Salut,

Je suis vraiment nouveau sur le sujet de JWT, alors s'il vous plaît, veuillez pardonner mon ignorance.

Le Trust pour lequel je travaille actuellement souhaite créer un cadre dans lequel ils peuvent créer des services API REST, au sein de HealthConnect, et y accorder l'accès à l'aide de l'autorisation de jeton Web JSON et des porteurs de jetons. Cela serait similaire à la manière dont le Trust se connecte actuellement à d'autres API REST, à savoir : DocMan Connect et GOV.UK Notify.

Je reçois généralement des plaintes de nos clients concernant l'actualisation automatique des pages Web BPL et DTL. C'est un problème courant parmi les utilisateurs débutants, mais pour les développeurs expérimentés aussi, ils oublient d'enregistrer les modifications régulièrement et automatiquement la page Web est rechargée, perdant tout le travail effectué.

Bonjour la communauté,

je vous invite à regarder la nouvelle vidéo sur InterSystems Developers YouTube:

⏯ How to Configure Firewall Rules in Health Connect Cloud

Salut Developer Community,

Je télécharge un fichier Excel xlsx à partir du Web à l'aide de la méthode ci-dessous et je l'enregistre au format xlsx. Comment puis-je convertir et enregistrer un format xlsx au format csv ?

InterSystems a corrigé deux défauts.

Le premier défaut peut entraîner le blocage d'un serveur d'applications ECP. Ce défaut ne concerne que les processeurs ARM et IBM Power ; il est présent dans les versions 2022.1.2 et 2022.1.3 d'InterSystems IRIS®, InterSystems IRIS for Health™ et HealthShare® Health Connect. La correction est identifiée comme DP-423661. Le défaut est corrigé dans toutes les versions futures.

Le besoin de créer des services REST permettant d'accéder aux informations présentes dans IRIS / HealthConnect est l'un des besoins les plus courants de nos clients. L'avantage de ces services REST est la possibilité de développer des interfaces utilisateurs personnalisées avec les technologies les plus récentes en profitant de la fiabilité et de la performance d'IRIS dans le back-end.

Dans l'article d'aujourd'hui, nous allons créer pas à pas un service web qui nous permettra à la fois de stocker des données dans notre base de données et de les consulter ultérieurement. De plus, nous allons le faire en configurant une production qui nous permettra de contrôler le flux de messages que nous recevons à tout moment et de contrôler ainsi son bon fonctionnement.

Avant de commencer, sachez simplement que vous avez tout le code disponible sur Open Exchange pour que vous puissiez le répliquer autant de fois que nécessaire, et que le projet est configuré dans Docker, en utilisant la communauté IRIS afin que vous n'ayez rien d'autre à faire que de le déployer.

Bien! Commençons donc!

Préparation de l'environnement

Avant de commencer la configuration du service REST, nous devons préparer notre environnement de développement, savoir quelles informations nous allons recevoir et ce que nous allons en faire. Pour cet exemple, nous avons décidé de recevoir des données de la personne dans le format JSON suivant :

{
    "PersonId": 1,
    "Name": "Irene",
    "LastName": "Dukas",
    "Sex": "Female",
    "Dob": "01/04/1975"
}

Comme l'un des objectifs est de stocker les informations que nous recevons, nous allons créer une classe Objectscript qui nous permettra d'enregistrer les informations dans notre IRIS. Comme vous pouvez le constater, les données sont assez simples, donc la classe n'aura pas beaucoup de complications :

Class WSTEST.Object.Person Extends%Persistent
{

/// ID of the personProperty PersonId As%Integer;/// Name of the personProperty Name As%String;/// Lastname of the personProperty LastName As%String;/// Sex of the personProperty Sex As%String;/// DOB of the personProperty Dob As%String;
Index PersonIDX On PersonId [ PrimaryKey ];
}

Parfait, nous avons déjà défini notre classe et nous pouvons commencer à nous en servir.

Création de notre point de terminaison

Maintenant que nous avons défini la classe de données avec laquelle nous allons travailler, il est temps de créer notre classe Objectscript qui fonctionnera comme un point de terminaison qui sera appelé depuis notre front-end. Voyons étape par étape la classe d'exemple que nous avons dans notre projet :

Class WSTEST.Endpoint Extends%CSP.REST
{
Parameter HandleCorsRequest = 0;
XData UrlMap [ XMLNamespace = "https://www.intersystems.com/urlmap" ]
{
<Routes>
<Route Url="/testGet/:pid" Method="GET" Call="TestGet" />
<Route Url="/testPost" Method="POST" Call="TestPost" />
</Routes>
}
ClassMethod OnHandleCorsRequest(url As%String) As%Status
{
set url = %request.GetCgiEnv("HTTP_REFERER")
set origin = $p(url,"/",1,3) // origin = "http(s)://origin.com:port"// here you can check specific origins// otherway, it will allow all origins (useful while developing only)do%response.SetHeader("Access-Control-Allow-Credentials","true")
do%response.SetHeader("Access-Control-Allow-Methods","GET,POST,PUT,DELETE,OPTIONS")
do%response.SetHeader("Access-Control-Allow-Origin",origin)
do%response.SetHeader("Access-Control-Allow-Headers","Access-Control-Allow-Origin, Origin, X-Requested-With, Content-Type, Accept, Authorization, Cache-Control")
quit$$$OK
}
// Class method to retrieve the data of a person filtered by PersonIdClassMethod TestGet(pid As%Integer) As%Status
{
Try {
Do##class(%REST.Impl).%SetContentType("application/json")
If '##class(%REST.Impl).%CheckAccepts("application/json") Do##class(%REST.Impl).%ReportRESTError(..#HTTP406NOTACCEPTABLE,$$$ERROR($$$RESTBadAccepts)) Quit// Creation of BS instanceset status = ##class(Ens.Director).CreateBusinessService("WSTEST.BS.PersonSearchBS", .instance)
    <span class="hljs-comment">// Invocation of BS with pid parameter</span>
    <span class="hljs-keyword">set</span> status = instance.OnProcessInput(pid, .response)
   	<span class="hljs-keyword">if</span> <span class="hljs-built_in">$ISOBJECT</span>(response) {
        <span class="hljs-comment">// Sending person data to client in JSON format</span>
    	<span class="hljs-keyword">Do</span> <span class="hljs-keyword">##class</span>(<span class="hljs-built_in">%REST.Impl</span>).<span class="hljs-built_in">%WriteResponse</span>(response.<span class="hljs-built_in">%JSONExport</span>())
	}
    
} <span class="hljs-keyword">Catch</span> (ex) {
    <span class="hljs-keyword">Do</span> <span class="hljs-keyword">##class</span>(<span class="hljs-built_in">%REST.Impl</span>).<span class="hljs-built_in">%SetStatusCode</span>(<span class="hljs-string">"400"</span>)
    <span class="hljs-keyword">Do</span> <span class="hljs-keyword">##class</span>(<span class="hljs-built_in">%REST.Impl</span>).<span class="hljs-built_in">%WriteResponse</span>(ex.DisplayString())
    <span class="hljs-keyword">return</span> {<span class="hljs-string">"errormessage"</span>: <span class="hljs-string">"Client error"</span>}
}
<span class="hljs-keyword">Quit</span> <span class="hljs-built_in">$$$OK</span>
}
// Class method to receive person data to persist in our databaseClassMethod TestPost() As%Status
{
Try {
Do##class(%REST.Impl).%SetContentType("application/json")
If '##class(%REST.Impl).%CheckAccepts("application/json") Do##class(%REST.Impl).%ReportRESTError(..#HTTP406NOTACCEPTABLE,$$$ERROR($$$RESTBadAccepts)) Quit// Reading the body of the http call with the person dataset bodyJson = %request.Content.Read()
    <span class="hljs-comment">// Creation of BS instance</span>
    <span class="hljs-keyword">set</span> status = <span class="hljs-keyword">##class</span>(Ens.Director).CreateBusinessService(<span class="hljs-string">"WSTEST.BS.PersonSaveBS"</span>, .instance)
   	<span class="hljs-keyword">#dim</span> response <span class="hljs-keyword">as</span> <span class="hljs-built_in">%DynamicObject</span>
    <span class="hljs-comment">// Invocation of BS with person data</span>
    <span class="hljs-keyword">set</span> status = instance.OnProcessInput(bodyJson, .response)
    
    <span class="hljs-keyword">if</span> <span class="hljs-built_in">$ISOBJECT</span>(response) {
        <span class="hljs-comment">// Returning to the client the person object in JSON format after save it</span>
        <span class="hljs-keyword">Do</span> <span class="hljs-keyword">##class</span>(<span class="hljs-built_in">%REST.Impl</span>).<span class="hljs-built_in">%WriteResponse</span>(response.<span class="hljs-built_in">%JSONExport</span>())
    }
    
} <span class="hljs-keyword">Catch</span> (ex) {
    <span class="hljs-keyword">Do</span> <span class="hljs-keyword">##class</span>(<span class="hljs-built_in">%REST.Impl</span>).<span class="hljs-built_in">%SetStatusCode</span>(<span class="hljs-string">"400"</span>)
    <span class="hljs-keyword">Do</span> <span class="hljs-keyword">##class</span>(<span class="hljs-built_in">%REST.Impl</span>).<span class="hljs-built_in">%WriteResponse</span>(ex.DisplayString())
    <span class="hljs-keyword">return</span> {<span class="hljs-string">"errormessage"</span>: <span class="hljs-string">"Client error"</span>}
}
<span class="hljs-keyword">Quit</span> <span class="hljs-built_in">$$$OK</span>
}
}

Ne vous inquiétez pas si cela vous semble impossible à comprendre, voyons les parties les plus pertinentes de notre cours :

Déclaration de classe :

Class WSTEST.Endpoint Extends%CSP.REST

Comme vous pouvez le voir, notre classe WSTEST.Endpoint élargit %CSP.REST, ce qui est nécessaire pour pouvoir utiliser la classe en tant que point de terminaison.

Définition des chemins :

XData UrlMap [ XMLNamespace = "https://www.intersystems.com/urlmap" ]
{
<Routes>
	<Route Url="/testGet/:pid" Method="GET" Call="TestGet" />
	<Route Url="/testPost" Method="POST" Call="TestPost" />
</Routes>
}

Dans cet extrait de code, nous déclarons les chemins qui peuvent être appelés à partir de notre front-end.

Comme vous voyez, nous avons deux chemins déclarés, le premier sera un appel GET dans lequel nous recevrons le paramètre pid que nous utiliserons pour rechercher des personnes par leur identifiant et qui sera géré par la méthode de classe TestGet. Le second appel sera de type POST, dans lequel nous recevrons les informations sur la personne que nous devons enregistrer dans notre base de données et qui seront traitées par la méthode de classe TestPost.

Examinons les deux méthodes :

Récupération des données de la personne :

ClassMethod TestGet(pid As%Integer) As%Status
{
    Try {
        Do##class(%REST.Impl).%SetContentType("application/json")
        If '##class(%REST.Impl).%CheckAccepts("application/json") Do##class(%REST.Impl).%ReportRESTError(..#HTTP406NOTACCEPTABLE,$$$ERROR($$$RESTBadAccepts)) Quit// Creation of BS instanceset status = ##class(Ens.Director).CreateBusinessService("WSTEST.BS.PersonSearchBS", .instance)

        // Invocation of BS with pid parameterset status = instance.OnProcessInput(pid, .response)
       	if$ISOBJECT(response) {
            // Sending person data to client in JSON formatDo##class(%REST.Impl).%WriteResponse(response.%JSONExport())
		}
        
    } Catch (ex) {
        Do##class(%REST.Impl).%SetStatusCode("400")
        Do##class(%REST.Impl).%WriteResponse(ex.DisplayString())
        return {"errormessage": "Client error"}
    }
    Quit$$$OK
}

Dans cette méthode, vous pouvez voir comment nous avons déclaré dans notre méthode de classe la réception de l'attribut pid que nous utiliserons dans la recherche ultérieure. Bien que nous aurions pu effectuer la recherche directement à partir de cette classe, nous avons décidé de le faire à l'intérieur d'une production pour pouvoir contrôler chacune des opérations, c'est pourquoi nous créons une instance du service métier Business Service WSTEST.BS.PersonSearchBS à laquelle nous appelons plus tard sa méthode OnProcessInput avec le pid reçu. La réponse que nous recevrons sera de type WSTEST.Object.PersonSearchResponse que nous transformerons en JSON avant de l'envoyer au requérant.

Conservation des données de la personne :

ClassMethod TestPost() As%Status
{
    Try {
        Do##class(%REST.Impl).%SetContentType("application/json")
        If '##class(%REST.Impl).%CheckAccepts("application/json") Do##class(%REST.Impl).%ReportRESTError(..#HTTP406NOTACCEPTABLE,$$$ERROR($$$RESTBadAccepts)) Quit// Reading the body of the http call with the person dataset bodyJson = %request.Content.Read()
        
        // Creation of BS instanceset status = ##class(Ens.Director).CreateBusinessService("WSTEST.BS.PersonSaveBS", .instance)
       	#dim response as%DynamicObject// Invocation of BS with person dataset status = instance.OnProcessInput(bodyJson, .response)
        
        if$ISOBJECT(response) {
            // Returning to the client the person object in JSON format after save itDo##class(%REST.Impl).%WriteResponse(response.%JSONExport())
	    }
        
    } Catch (ex) {
        Do##class(%REST.Impl).%SetStatusCode("400")
        Do##class(%REST.Impl).%WriteResponse(ex.DisplayString())
        return {"errormessage": "Client error"}
    }
    Quit$$$OK
}

Comme dans le cas précédent, nous aurions pu sauvegarder notre objet personne directement à partir de cette classe, mais nous avons décidé de le faire à partir d'une opération métier "Business Operation" qui sera appelée à partir du service métier "Business Service" WSTEST.BS.PersonSaveBS.

Comme vous pouvez le voir dans le code, nous récupérons les informations envoyées par le client dans l'appel POST en lisant le flux figurant dans %request.Content. La chaîne obtenue sera ce que nous transmettrons au Business Service..

Publication de notre point de terminaison

Pour ne pas allonger cet article, nous allons ignorer les explications relatives à la production, vous pouvez consulter le code directement dans le projet OpenExchange. La production que nous avons configurée est la suivante :

Nous avons deux services commerciaux déclarés, l'un pour recevoir les demandes de recherche et l'autre pour les demandes de stockage des données de la personne. Chacun d'entre eux invoquera une opération métier Business Operation appropriée.

Très bien, révisons ce que nous avons configuré dans notre projet :

• 1 classe de point de terminaison qui recevra les requêtes des clients (WSTest.Endpoint).
• 2 services métier "Business Services" qui seront appelés à partir de notre classe de point de terminaison (**WSTest.BS.PersonSaveBS **et WSTest.BS.PersonSearchBS).
• 2 opérations métier "Business Operations" chargées d'effectuer la recherche et l'enregistrement des données (**WSTest.BS.PersonSaveBS **et WSTest.BS.PersonSearchBS).
• 4 classes pour envoyer et recevoir des données au sein de la production qui s'étendent de Ens.Request et Ens.Response (WSTest.Object.PersonSearchRequest, WSTest.Object.PersonSaveRequest, **WSTest.Object.PersonSearchResponse **y WSTest.Object.PersonSaveResponse).

Il ne nous reste plus qu'une dernière étape pour mettre en service notre service web, c'est sa publication. Pour ce faire, nous allons accéder à l'option du portail de gestion Administration du système --> Sécurité -> Applications -> Applications Web

Nous verrons une liste de toutes les applications Web configurées dans notre instance :

Créons notre application web :

Examinons les points à configurer :

• Nom : Nous allons définir la route à utiliser pour faire les invocations à notre service, pour notre exemple ce sera /csp/rest/wstest
• Espace de noms : l'espace de noms sur lequel le service web travaillera, dans ce cas nous avons créé WSTEST dans lequel nous avons configuré notre production et nos classes.
• Activer l'application : activer le service web pour qu'il puisse recevoir des appels.
• Activer - REST : En sélectionnant REST, nous indiquons que ce service web est configuré pour recevoir des appels REST. En sélectionnant REST, nous devons définir la classe de distribution qui sera notre classe de terminaison WSTEST.Endpoint.
• Méthodes d'authentification autorisées : la configuration de l'authentification de l'utilisateur qui fait l'appel au service web. Dans ce cas, nous avons défini que l'authentification se fait par mot de passe, donc dans notre Postman nous configurerons le mode d'autorisation de base dans lequel nous indiquerons le nom d'utilisateur et le mot de passe. Nous pouvons définir l'utilisation de l'authentification JWT qui est très utile car elle n'expose pas les données de l'utilisateur et le mot de passe dans les appels REST, si vous êtes intéressé à plonger dans JWT, vous pouvez consulter [cet article] (https://community.intersystems.com/post/creating-rest-api-jwt-authentication-objectscript).

Une fois que nous avons fini de configurer notre application web, nous pouvons lancer quelques tests au moyen de Postman et en important le fichier WSTest.postman_collection.json présent dans le projet.

Test de notre point de terminaison

Une fois que tout est configuré dans notre projet et que la production a démarré, nous pouvons lancer quelques tests sur notre service web. Nous avons configuré superuser en tant qu'utilisateur requérant, de sorte que nous n'aurons pas de problèmes pour sauvegarder et récupérer des données. Dans le cas de l'utilisation d'un autre utilisateur, nous devons nous assurer qu'il a les rôles nécessaires assignés ou que nous les assignons dans l'onglet Rôles de l'application de la définition de notre application web.

Commençons par enregistrer une personne dans notre base de données :

Nous avons obtenu un 200, il semble donc que tout se soit bien passé, vérifions le message en production :

Tout s'est bien passé, le message avec le JSON a été correctement reçu dans BS et a été enregistré avec succès dans BO.

Essayons maintenant de récupérer les données de notre cher Alexios Kommenos :

Bingo ! Voici notre Alexios, avec toutes les informations le concernant. Vérifions le message en production :

Très bien, tout fonctionne comme il faut. Comme vous l'avez vu, il est très facile de créer un service web REST dans IRIS, vous pouvez utiliser ce projet comme base pour vos futurs développements et si vous avez des questions, n'hésitez pas à laisser un commentaire.

InterSystems a corrigé un défaut qui entraînait une utilisation accrue de la mémoire de processus.

Plus précisément, l'augmentation de la consommation de mémoire de la partition de processus locale se produit lors de l'exécution de $Order,  $Query, ou Merge sur des variables locales. Bien que cela n'ait aucun impact négatif sur la plupart des environnements en cours d'exécution, les environnements prenant en charge un grand nombre de processus ou limitant étroitement la mémoire maximale par processus pourraient être affectés. Certains processus peuvent rencontrer des erreurs <STORE>.

Salut la Communauté!

Profitez de regarder la nouvelle vidéo sur la chaîne Youtube d'InterSystems France :

📺 DeepDocs - Apprendre avec les patients

Il y a souvent des questions concernant la configuration idéale du Serveur Web HTTPD Apache pour HealthShare.  Le contenu de cet article décrit la configuration initiale recommandée du serveur Web pour tout produit HealthShare. 

APour commencer, la version 2.4.x (64 bits) d'Apache HTTPD est recommandée.  Des versions antérieures comme 2.2.x sont disponibles, mais la version 2.2 n'est pas recommandée pour les performances et l'évolutivité de HealthShare.

Configuration d'Apache

Module API Apache sans NSD {#ApacheWebServer-ApacheAPIModulewithoutNSD}

HealthShare requiert l'option d'installation Apache API Module without NSD. La version des modules liés dynamiquement dépend de la version d'Apache :

• CSPa24.so (Apache Version 2.4.x)

La configuration de Caché Server Pages dans le fichier Apache httpd.conf doit être effectuée par l'installation de HealthShare qui est détaillée plus loin dans ce document. Cependant, la configuration peut être effectuée manuellement. Pour plus d'informations, veuillez consulter le guide de configuration d'Apache dans la documentation d'InterSystems : Recommended Option: Apache API Module without NSD (CSPa24.so)

Recommandations concernant le module multiprocesseur d'Apache (MPM) {#ApacheWebServer-ApacheMulti-ProcessingModule(MPM)Recommendations}

Apache Prefork MPM Vs. Worker MPM {#ApacheWebServer-ApachePreforkMPMVs.WorkerMPM}

Le serveur web HTTPD Apache est livré avec trois modules multiprocesseurs (MPM) : Prefork, Worker et Event.  Les MPM sont responsables de la liaison avec les ports réseau de la machine, de l'acceptation des requêtes et de l'envoi de fils pour traiter ces requêtes. Par défaut, Apache est généralement configuré avec le MPM Prefork, qui n'est pas adapté à des charges de travail importantes en termes de transactions ou d'utilisateurs simultanés.

Pour les systèmes de production HealthShare, le MPM Apache Worker doit être activé pour des raisons de performance et d'évolutivité. Worker MPM est préféré pour les raisons suivantes :

• Prefork MPM utilise plusieurs processus enfants avec un fil d'exécution chacun et chaque processus gère une connexion à la fois. Lorsque Prefork est utilisé, les demandes simultanées souffrent car, comme chaque processus ne peut traiter qu'une seule demande à la fois, les demandes sont mises en attente jusqu'à ce qu'un processus serveur se libère. De plus, afin d'évoluer, il faut plus de processus enfants Prefork, ce qui consomme des quantités importantes de mémoire.
• Worker MPM utilise plusieurs processus enfants avec de nombreux fils d'exécution chacun. Chaque fil d'exécution gère une connexion à la fois, ce qui favorise la concurrence et réduit les besoins en mémoire. Worker gère mieux la concurrence que Prefork, car il y aura généralement des fils d'exécution libres disponibles pour répondre aux demandes au lieu des processus Prefork à un seul fil d'exécution qui peuvent être occupés.

Paramètres MPM pour Apache Worker {#ApacheWebServer-ApacheWorkerMPMParameters}

En utilisant des fils d'exécution pour servir les demandes, Worker est capable de servir un grand nombre de demandes avec moins de ressources système que le serveur basé sur le processus Prefork. 
Les directives les plus importantes utilisées pour contrôler le MPM de Worker sont ThreadsPerChild qui contrôle le nombre de fils d'exécution déployés par chaque processus enfant et MaxRequestWorkers qui contrôle le nombre total maximum de fils d'exécution pouvant être lancés.
Les valeurs recommandées de la directive commune Worker MPM sont détaillées dans le tableau ci-dessous :

<th>
  Valeur recommandée
</th>

<th>
  Commentaires
</th>

<td>
  Nombre maximal d'utilisateurs simultanés de HealthShare Clinical Viewer, ou des quatre autres composants de HealthShare, fixé à la somme de toutes les tailles de pool de services commerciaux entrants pour toutes les productions d'interfaces définies. * Note : Si toutes les inconnues au moment de la configuration commencent par une valeur de '1000'
</td>

<td>
    MaxRequestWorkers fixe la limite du nombre de demandes simultanées qui seront servies, c'est-à-dire qu'il restreint le nombre total de fils d'exécution qui seront disponibles pour servir les clients. Il est important que MaxRequestWorkers soit défini correctement car s'il est trop faible, les ressources seront gaspillées et s'il est trop élevé, les performances du serveur seront affectées. Notez que lorsque le nombre de connexions tentées est supérieur au nombre de travailleurs, les connexions sont placées dans une file d'attente. La file d'attente par défaut peut être ajustée avec la directive ListenBackLog.  
</td>

<td>
  250
</td>

<td>
    MaxSpareThreads traite les threads inactifs à l'échelle du serveur. S'il y a trop de threads inactifs dans le serveur, les processus enfants sont tués jusqu'à ce que le nombre de threads inactifs soit inférieur à ce nombre. L'augmentation du nombre de threads inutilisés par rapport à la valeur par défaut permet de réduire les risques de réactivation des processus.  
</td>

<td>
  75
</td>

<td>
    MinSpareThreads traite les fils d'exécution inactifs à l'échelle du serveur. S'il n'y a pas assez de fils d'exécution libres dans le serveur, des processus enfants sont créés jusqu'à ce que le nombre de fils d'exécution libres soit supérieur à ce nombre. En réduisant le nombre de fils d'exécution inutilisés par rapport à la valeur par défaut, on réduit les risques de réactivation des processus.  
</td>

<td>
  MaxRequestWorkers divisé par ThreadsPerChild
</td>

<td>
    Valeur maximale de MaxRequestWorkers pour la durée de vie du serveur. ServerLimit est une limite stricte du nombre de processus enfants actifs, et doit être supérieure ou égale à la directive MaxRequestWorkers divisée par la directive ThreadsPerChild. Avec worker, n'utilisez cette directive que si vos paramètres MaxRequestWorkers et ThreadsPerChild nécessitent plus de 16 processus serveur (valeur par défaut).  
</td>

<td>
  20
</td>

<td>
    La directive StartServers définit le nombre de processus de serveur enfant créés au démarrage. Comme le nombre de processus est contrôlé dynamiquement en fonction de la charge, il y a généralement peu de raisons d'ajuster ce paramètre, sauf pour s'assurer que le serveur est prêt à gérer un grand nombre de connexions dès son démarrage.  
</td>

<td>
  25
</td>

<td>
    Cette directive définit le nombre de threads créés par chaque processus enfant, 25 par défaut. Il est recommandé de conserver la valeur par défaut car l'augmenter pourrait conduire à une dépendance excessive vis-à-vis d'un seul processus.  
</td>

Pour plus d'informations, veuillez consulter la documentation relative à la version d'Apache concernée :

• Apache 2.4 Directives communes de MPM

Exemple de configuration MPM du travailleur Apache 2.4 {#ApacheWebServer-ExampleApache2.4WorkerMPMConfiguration}

Cette section explique comment configurer Worker MPM pour un serveur Web RHEL7 Apache 2.4 nécessaire pour prendre en charge jusqu'à 500 utilisateurs simultanés de TrakCare.

1. Vérifiez d'abord le MPM en utilisant la commande suivante :
2. Modifiez le fichier de configuration /etc/httpd/conf.modules.d/00-mpm.conf selon les besoins, en ajoutant et en supprimant le caractère de commentaire # afin que seuls les modules Worker MPM soient chargés. Modifiez la section Worker MPM avec les valeurs suivantes dans le même ordre que ci-dessous :
3. Redémarrer Apache
4. Après avoir redémarré Apache avec succès, validez les processus worker en exécutant les commandes suivantes. Vous devriez voir quelque chose de similaire à ce qui suit confirmant le processus httpd.worker :

Renforcement d'Apache {#ApacheWebServer-ApacheHardening}

Modules requis pour Apache {#ApacheWebServer-ApacheRequiredModules}

L'installation du paquetage officiel d'Apache activera par défaut un ensemble spécifique de modules Apache. Cette configuration par défaut d'Apache chargera ces modules dans chaque processus httpd. Il est recommandé de désactiver tous les modules qui ne sont pas nécessaires à HealthShare pour les raisons suivantes :

• réduire l'empreinte du processus du démon httpd.
• réduire le risque d'un défaut de segmentation dû à un module malveillant.
• réduire les vulnérabilités en matière de sécurité.

Le tableau ci-dessous détaille les modules Apache recommandés pour HealthShare. Tout module qui ne figure pas dans la liste ci-dessous peut être désactivé :

Désactivation des modules

Les modules inutiles doivent être désactivés pour renforcer la configuration qui réduira les vulnérabilités de sécurité. Le client est responsable de la politique de sécurité du serveur web. Au minimum, les modules suivants doivent être désactivés.

Apache SSL/TLS {#ApacheWebServer-ApacheSSL/TLS}

Pour protéger les données en transit, assurer la confidentialité et l'authentification, InterSystems recommande que toutes les communications TCP/IP entre les serveurs et les clients de HealthShare soient cryptées avec SSL/TLS, et InterSystems recommande également d'utiliser HTTPS pour toutes les communications entre le navigateur client des utilisateurs et la couche serveur web de l'architecture proposée.   Veillez à consulter les politiques de sécurité de votre organisation pour vous assurer de la conformité à toute exigence de sécurité spécifique de votre organisation. 

Le client est responsable de la fourniture et de la gestion des certificats SSL/TLS. Si vous utilisez des certificats SSL, ajoutez le module ssl_ (mod_ssl.so).

Paramètres supplémentaires de durcissement d'Apache {#ApacheWebServer-AdditionalHardeningApacheParameters}

Pour renforcer la configuration d'Apache, apportez les modifications suivantes au fichier httpd.conf :

• TraceEnable doit être désactivé pour éviter les problèmes potentiels de traçage intersites.

• ServerSignature doit être désactivé afin que la version du serveur web ne soit pas affichée.

Paramètres de configuration supplémentaires d'Apache {#ApacheWebServer-SupplementalApacheConfigurationParameters}

Keep-Alive {#ApacheWebServer-Keep-Alive}

Le paramètre Apache Keep-Alive permet d'utiliser la même connexion TCP pour la communication HTTP au lieu d'ouvrir une nouvelle connexion pour chaque nouvelle demande, c'est-à-dire que Keep-Alive maintient une connexion persistante entre le client et le serveur. Lorsque l'option Keep-Alive est activée, l'amélioration des performances provient de la réduction de l'encombrement du réseau, de la réduction de la latence des requêtes ultérieures et de la diminution de l'utilisation du CPU causée par l'ouverture simultanée de connexions. L'option Keep-Alive est activée par défaut et la norme HTTP v1.1 stipule qu'elle doit être présumée activée.

Cependant, l'activation de la fonction Keep-Alive présente des inconvénients : Internet Explorer doit être IE10 ou supérieur pour éviter les problèmes de délai d'attente connus avec les anciennes versions d'IE. De même, les intermédiaires tels que les pare-feu, les équilibreurs de charge et les proxies peuvent interférer avec les "connexions TCP persistantes" et entraîner une fermeture inattendue des connexions.  

Lorsque vous activez la fonction "Keep-Alive", vous devez également définir le délai d'attente de cette fonction. Le délai d'attente par défaut pour Apache est trop faible et doit être augmenté pour la plupart des configurations, car des problèmes peuvent survenir en cas de rupture des requêtes AJAX (c'est-à-dire hyperevent). Ces problèmes peuvent être évités en s'assurant que le délai d'attente du serveur est supérieur à celui du client.  En d'autres termes, c'est le client, et non le serveur, qui devrait fermer la connexion.  Des problèmes surviennent - principalement dans IE mais dans une moindre mesure dans d'autres navigateurs - lorsque le navigateur tente d'utiliser une connexion (en particulier pour un POST) dont il s'attend à ce qu'elle soit ouverte. 

Voir ci-dessous les valeurs recommandées de KeepAlive et KeepAliveTimeout pour un serveur Web HealthShare.

Pour activer KeepAlive dans Apache, apportez les modifications suivantes au fichier httpd.conf :

Psserelle CSP {#ApacheWebServer-CSPGateway}

Pour le paramètre CSP Gateway KeepAlive, laissez la valeur par défaut No Action car le statut KeepAlive est déterminé par les titres de la réponse HTTP pour chaque requête.

Nos clients ont souvent besoin de configurer HealthShare HealthConnect et IRIS en mode haute disponibilité.

D'autres moteurs d'intégration sur le marché sont souvent présentés comme ayant des configurations de "haute disponibilité", mais ce n'est pas vraiment le cas. En général, ces solutions fonctionnent avec des bases de données externes et donc, si celles-ci ne sont pas configurées en haute disponibilité, lorsqu'un crash de la base de données se produit ou que la connexion à celle-ci est perdue, l'ensemble de l'outil d'intégration devient inutilisable.

Dans le cas des solutions InterSystems, ce problème n'existe pas, car la base de données fait partie intégrante des outils eux-mêmes. Et comment InterSystems a-t-il résolu le problème de la haute disponibilité ? Par des configurations absconses qui pourraient nous entraîner dans une spirale d'aliénation et de folie ? NON ! Chez InterSystems, nous avons écouté et pris en compte vos plaintes (comme nous essayons toujours de le faire ;) ) et nous avons mis la fonction mirroring (mise en miroir) à la disposition de tous nos utilisateurs et développeurs.

Mirroring

Comment fonctionne le Miroir ? Le concept lui-même est très simple. Comme vous le savez déjà, IRIS et HealthShare fonctionnent avec un système de journalisation qui enregistre toutes les opérations de mise à jour des bases de données de chaque instance. Ce système de journalisation est celui qui nous aide à récupérer les instances sans perte de données après un crash. Ces fichiers journaux sont envoyés entre les instances configurées en miroir, ce qui permet aux instances configurées en miroir d'être mises à jour en permanence.

Architecture

Décrivons brièvement l'architecture d'un système configuré en miroir :

• Deux instances configurées en mode basculement :
  • Nœud actif : reçoit toutes les opérations régulières de lecture/écriture.
  • Nœud passif : en mode lecture, il reçoit de manière synchrone toutes les modifications produites dans le nœud actif.
• 0-14 instances asynchrones : autant d'instances asynchrones que vous souhaitez utiliser; elles peuvent être de deux types :
  • DR async (reprise après sinistre) : nœuds en mode lecture qui ne font pas partie du basculement, bien qu'ils puissent être transférés manuellement. Si tel est le cas, ils pourraient être automatiquement transférés vers le nœud principal en cas de défaillance des deux autres nœuds de basculement. La mise à jour de vos données se fait en mode asynchrone, leur fraîcheur n'est donc pas garantie.
  • Reporting Asyncs (rapports asynchrones) : Nœuds mis à jour de manière asynchrone pour une utilisation dans des tâches de BI ou d'exploration de données. Ils ne peuvent pas être transférés vers le basculement car des écritures peuvent être effectuées sur les données.
• ISCAgent : Installé sur chaque serveur où se trouve une instance. Il sera chargé de surveiller l'état des instances de ce serveur. C'est un autre moyen de communication entre les Serveurs Miroirs en plus de la communication directe.
• Arbiter : il s'agit d'un ISCAgent installé indépendamment par rapport aux serveurs qui composent le Miroir et qui permet d'augmenter la sécurité et le contrôle des bascules au sein de celui-ci en surveillant les ISCAgents installés et les instances d'IRIS/HealthShare. Son installation n'est pas obligatoire.

Il s'agirait du fonctionnement d'un Miroir formé par un basculement avec seulement deux nœuds :

Avertissement préalable

Le projet associé à cet article n'a pas de licence active permettant la configuration du miroir. Si vous voulez l'essayer, envoyez-moi un email directement ou ajoutez un commentaire en bas de l'article et je vous contacterai.

Déploiement dans Docker

Pour cet article, nous allons mettre en place un petit projet dans Docker qui nous permet de mettre en place 2 instances de basculement avec un Arbiter. Par défaut, les images IRIS disponibles pour Docker ont l'ISCAgent déjà installé et configuré, nous pouvons donc sauter cette étape. Il sera nécessaire de configurer le projet associé à l'article à partir d'un code Visual Studio, car cela nous permettra de travailler plus confortablement avec les fichiers du serveur par la suite.

Voyons quelle forme aurait notre docker-compose.yml :

version:'3.3'services:  arbiter:      container_name:arbiter      hostname:arbiter      image:containers.intersystems.com/intersystems/arbiter:2022.1.0.209.0      init:true      command:        -/usr/local/etc/irissys/startISCAgent.sh2188  mirrorA:    image:containers.intersystems.com/intersystems/iris:2022.1.0.209.0    container_name:mirrorA    depends_on:      -arbiter    ports:    -"52775:52773"    volumes:    -./sharedA:/shared    -./install:/install    -./management:/management    command:      --check-capsfalse      --key/install/iris.key      -a/install/installer.sh    environment:    -ISC_DATA_DIRECTORY=/shared/durable    hostname:mirrorA  mirrorB:    image:containers.intersystems.com/intersystems/iris:2022.1.0.209.0    container_name:mirrorB    depends_on:      -arbiter      -mirrorA    ports:    -"52776:52773"    volumes:    -./sharedB:/shared    -./install:/install    -./management:/management    command:      --check-capsfalse      --key/install/iris.key      -a/install/installer.sh    environment:    -ISC_DATA_DIRECTORY=/shared/durable    hostname:mirrorB

Nous pouvons remarquer que nous avons défini 3 conteneurs :

• Arbiter : il correspond à l'ISCAgent (même si l'image s'appelle Arbiter) qui sera déployé pour contrôler les instances IRIS qui formeront le Mirror Failover (basculement miroir). Au démarrage du conteneur, il exécutera un fichier shell qui démarrera l'ISCAgent écoutant sur le port 2188 du conteneur.
• mirrorA : conteneur dans lequel l'image IRIS v.2022.1.0.209 sera déployée et que nous configurerons ultérieurement en tant que nœud de basculement primaire.
• mirrorB : conteneur dans lequel l'image IRIS v.2022.1.0.209 sera déployée et que nous configurerons ultérieurement en tant que nœud de basculement secondaire.

Lorsque nous exécutons la commande docker-compose up -d, les conteneurs définis seront déployés dans notre Docker, et cela devrait ressembler à ceci dans notre Docker Desktop (si nous le faisons à partir de Windows).

Configuration du miroir.

Avec nos conteneurs déployés, nous allons procéder à l'accès aux instances que nous allons configurer en miroir, la première sera à l'écoute sur le port 52775 (mirrorA) et la seconde sur 52776 (mirrorB). L'utilisateur et le mot de passe d'accès seront superuser / SYS

Du fait que les instances sont déployées dans Docker, nous aurons deux options pour configurer les IP de nos serveurs. La première est d'utiliser directement le nom de nos conteneurs dans la configuration (ce qui est le plus simple) ou de vérifier les IP que Docker a attribuées pour chaque conteneur (en ouvrant la console et en exécutant un ifconfig qui renvoie l'IP attribuée). Pour des raisons de clarté, nous utiliserons pour l'exemple les noms que nous avons donnés à chaque conteneur comme adresse de chacun au sein de Docker.

Tout d'abord, nous allons configurer l'instance que nous utiliserons comme nœud actif du basculement (FailOver). Dans notre cas, ce sera ce que nous avons appelé mirrorA.

La première étape consistera à activer le service de mise en miroir, ce qui nous permettra d'accéder au menu de mise en miroir à partir du portail de gestion : Administration du système --> Configuration --> Paramètres du miroir --> Activer le miroirService et cochez la case Service activé :

Une fois le service activé, nous pouvons commencer à configurer notre nœud actif. Après avoir activé le service, vous pourrez voir que de nouvelles options ont été activées dans le menu Miroir :

Dans ce cas, comme nous n'avons pas de configuration de miroir déjà créée, nous devons en créer une nouvelle avec l'option Créer un miroir. Lorsque nous accédons à cette option, le portail de gestion ouvrira une nouvelle fenêtre à partir de laquelle nous pourrons configurer notre miroir :

Examinons de plus près chacune des options :

• Nom du miroir : le nom avec lequel nous identifierons notre miroir. Pour notre exemple, nous l'appellerons MIRRORSET. ** Nécessite le SSL/TLS** : pour notre exemple, nous ne configurerons pas de connexion utilisant le SSL/TLS, bien que dans les environnements de production, il serait plus que pratique d'éviter que le fichier journal soit partagé sans aucun type d'encryptage entre les instances. Si vous souhaitez configurer cette connexion, vous avez tous les renseignements nécessaires à l'adresse URL de la documentation.
• Use Arbiter : cette option n'est pas obligatoire, mais elle est fortement recommandée, car elle ajoute une couche de sécurité à notre configuration de miroir. Pour notre exemple, nous la laisserons cochée et nous indiquerons l'IP dans laquelle nous avons notre Arbiter en cours d'exécution. Pour notre exemple, l'IP sera dans le nom du conteneur arbiter.
• User Virtual IP : dans les environnements Linux/Unix, cette option est très intéressante car elle nous permet de configurer une IP virtuelle pour notre nœud actif qui sera géré par notre miroir. Cette IP virtuelle doit appartenir au même sous-réseau que les nœuds de basculement. Le fonctionnement de l'IP virtuelle est très simple, en cas de défaillance du nœud actif le miroir configurera automatiquement l'IP virtuelle sur le serveur où se trouve le nœud passif à promouvoir. De cette manière, la promotion du nœud passif en nœud actif sera complètement transparente pour les utilisateurs, puisqu'ils continueront à être connectés à la même IP, même si elle sera configurée sur un serveur différent. Si vous souhaitez en savoir plus sur l'IP virtuelle, vous pouvez consulter cette URL de la documentation.

Le reste de la configuration peut être laissé tel quel. Sur le côté droit de l'écran, nous verrons les renseignements relatifs à ce nœud dans le miroir :

• Nom du membre du miroir : nom de ce membre du miroir, par défaut il prendra le nom du serveur avec le nom de l'instance.
• Superserver Address : Adresse IP du super-serveur de ce nœud, dans notre cas, mirrorA.
• Port de l'agent : port dans lequel l'agent ISCAgent correspondant à ce nœud a été configuré. Par défaut 2188.

Une fois les champs nécessaires configurés, nous pouvons procéder à la sauvegarde du miroir. Nous pouvons vérifier comment la configuration s'est déroulée à partir du moniteur du miroir (Opération du système --> Moniteur du miroir).

Parfait, nous avons notre miroir nouvellement configuré. Comme vous pouvez le constater, seul le nœud actif que nous venons de créer apparaît. Très bien, allons donc ajouter notre nœud passif dans le Failover. Nous accédons au portail de gestion mirrorB et au menu Mirror Settings. Comme nous l'avons déjà fait pour l'instance mirrorA, nous devons activer le service Mirror. Nous répétons l'opération et dès que les options du menu seront mises à jour, nous choisirons Join as Failover (Rejoindre en tant que basculement).

Nous avons ici l'écran de connexion au miroir. Expliquons brièvement la signification de chacun des champs :

• Nom du miroir : nom que nous avons donné au miroir au moment de sa création, dans notre exemple MIRRORSET.
• Adresse de l'agent sur l'autre système : IP du serveur où l'ISCAgent du nœud actif est déployé, pour nous ce sera mirrorA.
• Port de l'agent : port d'écoute de l'ISCAgent du serveur dans lequel nous avons créé le miroir. Par défaut 2188.
• Nom de l'instance IRIS d'InterSystems : le nom de l'instance IRIS sur le nœud actif. Dans ce cas, il coïncide avec celui du nœud passif, IRIS.

Après avoir enregistré les données du miroir, nous aurons la possibilité de définir les renseignements relatifs au nœud passif que nous sommes en train de configurer. Examinons à nouveau les champs que nous pouvons configurer pour le nœud passif :

• Nom du membre du miroir : nom que le nœud passif prendra dans le miroir. Par défaut, il est formé par le nom du serveur et de l'instance. Superserver Address : Adresse IP du super-serveur dans notre nœud passif. Dans ce cas mirrorB.
• Port de l'agent** : port d'écoute de l'agent ISCAgent installé sur le serveur du nœud passif que nous sommes en train de configurer. Par défaut 2188. SSL/TLS Requirement : non configurable dans cet exemple, nous n'utilisons pas SSL/TLS. Adresse privée du miroir : Adresse IP du nœud passif. Comme nous l'avons vu, lors de l'utilisation de Docker, nous pouvons utiliser le nom du conteneur mirrorB. Adresse de l'agent : Adresse IP du serveur où l'ISCAgent est installé. Même chose que précédemment, mirrorB.

Nous enregistrons la configuration comme nous l'avons indiqué et nous retournons au moniteur du miroir pour vérifier que nous avons tout configuré correctement. Nous pouvons visualiser le moniteur du nœud actif dans miroirA et du nœud passif dans miroirB. Examinons les différences entre les deux instances.

Moniteur miroir sur le nœud actif mirrorA :

Moniteur du miroir sur le nœud passif mirrorB:

Comme vous pouvez le constater, les renseignements affichés sont similaires, il s'agit essentiellement de changer l'ordre des membres du basculement. Les options sont également différentes, examinons-en quelques-unes :

• Nœud actif mirrorA :
  • Set No Failover (Configurer pas de basculement) : empêche l'exécution du basculement dans le cas d'un arrêt de l'une des instances qui en font partie.
  • Demote other member (Démonter l'autre membre) : Supprime l'autre membre du basculement (dans ce cas mirrorB) de la configuration du miroir.
• Nœud passif mirrorB :
  • Stop Mirror On This Member (Supprimer le miroir sur ce membre) : arrête la synchronisation du miroir sur le membre de basculement (ici mirrorB) : Arrête la synchronisation du miroir sur le nœud passif de basculement.
  • Demote To DR Member (Rétrograder vers le membre DR) : rétrograde ce nœud de la partie du basculement avec sa synchronisation en temps réel vers le mode de reprise après sinistre en mode asynchrone.

Parfait, nous avons déjà nos nœuds configurés, voyons maintenant la dernière étape de notre configuration. Nous avons à décider quelles tableaux feront partie du miroir et à le configurer sur les deux nœuds. Si vous regardez le README.md du projet Open Exchange associé à cet article, vous verrez que nous configurons et déployons deux applications que nous utilisons habituellement pour la formation. Ces applications sont déployées automatiquement lorsque nous démarrons les conteneurs Docker et que les NAMESPACES et les bases de données sont créés par défaut.

La première application est celle de l'entreprises COMPANY qui nous permet de sauvegarder les dossiers des entreprises et la seconde est PHONEBOOK qui nous permet d'ajouter des contacts personnels liés aux entreprises enregistrées, ainsi que des clients.

Ajoutons une entreprise :

Nous allons maintenant créer un contact personnel pour l'entreprise précédente :

Les données relatives à l'entreprise seront enregistrées dans la base de données COMPANY et les données relatives au contact dans PERSONAL, les deux bases de données étant mappées de manière à être accessibles à partir de l'espace de noms PHONEBOOK. Si nous vérifions les tableaux dans les deux nœuds, nous verrons que dans mirrorA nous avons les données de l'entreprise et du contact, mais que dans mirrorB il n'y a toujours rien, ce qui est logique.

Les entreprises enregistrées dans mirrorA:

Très bien, procédons à la configuration des bases de données sur notre miroir. Pour ce faire, depuis notre nœud actif (miroirA), nous accédons à l'écran d'administration des bases de données locales (Administrateur système --> Configuration --> Configuration du système --> Bases de données locales) et nous cliquons sur l'option Ajouter au miroir, nous devons sélectionner dans la liste toutes les bases de données que nous voulons ajouter et lire le message qui s'affiche à l'écran :

Une fois les bases de données ajoutées au miroir à partir du nœud actif, nous avons à faire une sauvegarde de celles-ci ou à copier les fichiers de base de données (IRIS.dat) et à les restaurer sur le nœud passif. Si vous décidez de faire une copie directe des fichiers IRIS.dat, gardez à l'esprit que vous devez figer les écritures dans la base de données à copier, vous pouvez voir les commandes nécessaires dans l'URL de la documentation. Dans notre exemple, il ne sera pas nécessaire de faire une pause, puisque personne d'autre que nous n'écrit dans la base de données.

Avant d'effectuer cette copie des fichiers de la base de données, vérifions l'état du miroir à partir du moniteur du nœud actif :

Examinons le nœud passif :

Comme nous pouvons le voir, depuis le nœud passif nous sommes informés que bien que nous ayons 3 bases de données configurées dans le miroir, la configuration n'a pas encore été faite. N'oublions pas que nous devons démonter les bases de données du nœud passif pour pouvoir effectuer la copie et pour cela nous accéderons depuis le portail de gestion à Configuration du système --> Bases de données et en accédant à chacune d'entre elles nous procéderons à leur démontage.

Parfait ! Bases de données démontées. Accédons au code du projet associé à l'article depuis Visual Studio Code et constatons que nous avons les dossiers où se trouvent les installations IRIS, sharedA pour mirrorA et sharedB pour mirrorB. Accédons aux dossiers où se trouvent les bases de données COMPANY, CUSTOMER et PERSONAL (/sharedA/durable/mgr) et procédons à la copie du fichier IRIS.dat de chaque base de données dans le miroir vers les répertoires appropriés du miroirB (/sharedB/durable/mgr).

Une fois la copie terminée, nous montons à nouveau les bases de données mirrorB et vérifions l'état des bases de données configurées à partir du moniteur du miroir mirrorB :

Bingo ! Notre miroir a reconnu les bases de données et il ne nous reste plus qu'à les activer et les mettre à jour. Pour ce faire, nous allons cliquer sur l'action Activer puis sur Catchup (Rattraper), qui apparaîtra après l'activation. Voyons ce qu'il en est :

PParfait, nos bases de données sont déjà correctement configurées en miroir, si nous consultons la base de données COMPANY nous devrions voir l'enregistrement que nous avons enregistré depuis mirrorA auparavant :

Il est évident que notre base de données COMPANY a l'enregistrement que nous avons saisi précédemment dans mirrorA, nous avons copié l'ensemble de la base de données après tout. Ajoutons une nouvelle société à partir de miroirA que nous appellerons "Une autre société" et interrogeons à nouveau le tableau de la base de données COMPANY :

Le voici. Nous aurons juste à nous assurer que nos bases de données configurées en miroir sont en mode lecture seule pour le nœud passif mirrorB :

Et les voici ! en mode R pour la lecture. Bon, nous avons déjà notre miroir configuré et nos bases de données synchronisées. Dans le cas où nous aurions des productions en cours, ce ne serait pas un problème puisque le miroir se charge automatiquement de les gérer, en les démarrant dans le nœud passif en cas de chute dans le nœud actif.

Merci beaucoup à tous ceux qui ont atteint ce stade ! C'était long, mais j'espère que cela vous sera utile.

InterSystems a corrigé un défaut pouvant entraîner la corruption des bases de données et des fichiers journaux sur les systèmes AIX avec IBM POWER8 ou des processeurs POWER ultérieurs. Ce défaut peut être déclenché uniquement lorsque le chiffrement de la base de données ou du journal est utilisé.

Pour déclencher ce défaut, les conditions suivantes sont requises :

Exemple d'utilisation de la base de données FHIR d'InterSystems IRIS for Health pour effectuer de modèles ML via InterSystems IRIS IntegratedML

Description

IntegratedML est une fonctionnalité intéressante pour former/tester et déployer des modèles ML. FHIR est un standard puissant pour l'interopérabilité des informations de santé. Ce projet vise à montrer comment utiliser les outils IRIS/IRIS for Health, par exemple les transformations DTL pour préparer les données FHIR à l'application de modèles ML dans IntegratedML. Voici quelques applications potentielles des idées présentées dans ce projet :

En discutant avec un de mes amis, spécialiste du Machine Learning @Renato Banzai , il a évoqué l'un des plus grands défis pour les entreprises aujourd'hui : le déploiement du ML/IA dans des environnements réels.

InterSystems IRIS propose la solution "IntegratedML". IntegratedML est une fonctionnalité très utile pour entraîner, tester et déployer des modèles de ML/IA.

La partie la plus difficile dans la création de ML/IA est de faire le traitement des données, de les nettoyer et de les rendre fiables.

C'est là que nous pouvons tirer parti de la puissante norme FHIR !

L'idée du projet montre comment nous pouvons créer/entraîner/valider des modèles MI/IA avec FHIR et les utiliser avec des données provenant de différentes sources.

InterSystems a corrigé un défaut pouvant entraîner une instabilité du client ECP (Enterprise Cache Protocol) dans de rares cas.

Le défaut existe dans les produits suivants et dans toutes les offres InterSystems basées sur ceux-ci.

Les versions concernées sont 2022.1.x, 2022.2 et 2022.3 :

InterSystems IRIS®

InterSystems IRIS for Health™

HealthShare® Connexion Santé

La version concernée est 2022.2 (uniquement pour les clients déployant ECP) :

InterSystems HealthShare®

InterSystems a corrigé un défaut qui pouvait amener une requête SQL à renvoyer des résultats incorrects.

Le défaut existe dans les produits suivants et dans toutes les offres InterSystems basées sur ceux-ci.

Les versions concernées sont 2021.2, 2022.1.x, 2022.2 et 2022.3 :

InterSystems IRIS®

InterSystems IRIS for Health™

HealthShare® Connexion Santé

La version impactée est 2022.2 :

InterSystems HealthShare®

Bonjour la communauté !

Existe-t-il un moyen en objectscript de récupérer tous les noms de propriétés d'un message HL7 ?

Par exemple, j'ai un message HL7 :