À titre d'exemple d'application en Java fonctionnant avec le dialecte Hibernate pour IRIS, je souhaitais utiliser l'application RealWorld et j'ai trouvé une réalisation pour Quarkus. L'application RealWorld est un exemple d'application proche d'une application réelle, avec des tests déjà préparés pour le backend. La plupart des exemples de réalisations sont à retrouver ici

L'exemple d'application RealWorld est souvent appelé « Wikipédia pour la création d'applications full-stack ». Il sert de prototype standardisé que les développeurs peuvent utiliser pour créer des applications à l'aide de divers langages et frameworks de programmation. L'application fournit un cas d'utilisation réel en imitant une plate-forme de blogs, avec des fonctionnalités telles que l'authentification des utilisateurs, la gestion des profils, la publication d'articles et les commentaires. Avec un ensemble complet de spécifications, y compris une documentation d'API backend prête à l'emploi et des conceptions frontend, il permet aux développeurs de voir comment les mêmes exigences fonctionnelles sont mises en œuvre dans différentes piles technologiques. L'exemple RealWorld est largement utilisé comme outil d'apprentissage et comme référence pour comparer diverses technologies.

Quarkus

Quarkus est un framework Java open source natif de Kubernetes, conçu pour GraalVM et HotSpot. Créé dans le but d'améliorer l'environnement cloud natif moderne, il réduit considérablement l'empreinte et le temps de démarrage des applications Java. Quarkus est connu pour sa philosophie « privilégiant le conteneur », permettant aux développeurs de créer des applications légères et performantes en mettant l'accent sur l'architecture des microservices. Cette flexibilité en a fait un choix populaire pour les organisations cherchant à passer à des plates-formes sans serveur ou basées sur le cloud, combinant des modèles de programmation impératifs et réactifs. Qu'il s'agisse d'une application Web traditionnelle ou d'un système complexe de microservices, Quarkus fournit une plate-forme robuste pour créer des logiciels évolutifs et maintenables.

Salut la Communauté!

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

📺 Qu'est-ce que le standard FHIR ?

Rubrique FAQ InterSystems

Vous pouvez définir des pages d'erreur individuelles en fonction des différents types de messages d'erreur ou de réponses système de la passerelle Web :

• erreur de serveur 
• serveur occupé
• serveur indisponible
• délai d'attente du serveur
• connexion fermée

Les paramètres sont définis sur l'écran Gestion de passerelle Web ([Portail d'Administration] > [Administration système] > [Configuration] > [Gestion de passerelle Web] > [Configuration] > [Default Parameters]).

Dans la section "Error Pages" du menu "Default Parameters", indiquez le nom de fichier de la page html à afficher ou l'URL vers laquelle rediriger la réponse lorsqu'une erreur se produit.

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.

Ci-dessous figure une liste de certains des utilitaires disponibles dans InterSystems IRIS.

Cliquez sur le nom de chaque utilitaire dans le tableau ci-dessous pour obtenir des informations détaillées sur l'utilitaire.

<td>
  Aperçu
</td>

<td>
  Exécution d'opérations de sauvegarde et de restauration
</td>

<td>
  Gestion des bases de données, y compris la création, la modification et la suppression de bases de données
</td>

<td>
  Vérification de la concordance du contenu des deux fichiers IRIS.DAT
</td>

<td>
  Détermination de la taille des bases de données
</td>

<td>
  Capture des données globales d'une base de données vers une autre base de données ou un autre espace de noms
</td>

<td>
  Vérification des globales temporaires utilisées dans la base de données IRISTEMP
</td>

<td>
  Une simple comparaison du contenu des deux globales
</td>

<td>
  Vérification de la taille des données de chaque globale dans l'espace de noms
</td>

<td>
  Vérification de l'intégrité structurelle d'un ensemble de bases de données ou d'un sous-ensemble de globales dans une base de données
</td>

<td>
  Affichage d'une liste de processus. Des informations détaillées sur chaque processus peuvent également être affichées et arrêtées.
</td>

<td>
  Configuration de la journalisation
</td>

<td>
  Affichage et suppression des informations de verrouillage en cours d'utilisation
</td>

<td>
  Enregistrement continu des informations du compteur d'accès global dans un fichier en unités de cycles d'échantillonnage
</td>

<td>
  Exécution des opérations de configuration, de gestion et d'état de la mise en miroir
</td>

<td>
  Surveillance des journaux de messages (messages.log) afin de générer des notifications ou d'envoyer des courriels
</td>

<td>
  Exécution de la configuration et de la maintenance des données essentielles au bon fonctionnement de la sécurité d'IRIS.
</td>

<td>
  Affichage d'une liste de processus (référence uniquement).
</td>

<td>
  Diffusion des informations du journal des erreurs internes d'IRIS enregistrées dans une partie de la mémoire partagée.
</td>

<td>
  IRIS recueille des informations sur l'état des processus en cours d'utilisation, la mémoire partagée, etc.
</td>

<td>
  Collecte de données détaillées sur les performances d'IRIS et de la plate-forme sur laquelle l'instance fonctionne.
</td>

<td>
  Planification et gestion des tâches.
</td>

※Tous les utilitaires doivent être exécutés dans l'espace de noms %SYS, à l'exception des utilitaires avec %.
※Portail de gestion : indique les fonctions cibles qui peuvent être exécutées à partir du portail de gestion.
※★En cliquant sur le nom de l'utilitaire, la description se trouve dans la documentation du produit (certains ne sont pas répertoriés).
 

★^BACKUP

Processus de sauvegarde et de restauration.
L'utilitaire ^BACKUP comporte les éléments de menu suivants.

%SYS>do^BACKUP) Backup                                        // Exécution des sauvegardes de la base de données2) Restore ALL                                   // Restauration de toutes les bases de données3) Restore Selected or Renamed Directories       // Restauration des répertoires sélectionnés ou renommés4) Edit/Display List of Directories for Backups  // Modification/affichage de la liste des répertoires5) Abort Backup                                  // Annulation de la sauvegarde6) Display Backup volume information             // Affichage des informations sur le volume de sauvegarde7) Monitor progress of backup or restore         // Contrôle de la progression de la sauvegarde ou de la restauration

Portail de gestion :
Fonctionnement du système > Sauvegarde

【Pour référence】
Les sauvegardes de bases de données(InterSystems Symposia 2014)
La différence entre la sauvegarde accumulative et la sauvegarde différentielle.
Comment effectuer des sauvegardes sans arrêter une instance en cours d'exécution ?
Comment sauvegarder une base de données
 

★^DATABASE

La gestion des bases de données, y compris la création, la modification et la suppression des bases de données, s'effectue à l'aide de cette fonction. L'utilitaire ^DATABASE comporte les éléments de menu suivants

%SYS>do^DATABASE1) Create a database                    // Création d'une base de données2) Edit a database                      // Modification des attributs des bases de données existantes.3) List databases                       // Affichage de la liste de bases de données4) Delete a database                    // Suppression de la base de données existante5) Mount a database                     // Montage de la base de données6) Dismount a database                  // Démontage de la base de données.7) Compact globals in a database        // Compression des données globales de la base de données. Cette fonction est limitée aux versions disponibles (※).8) Show free space for a database       // Affichage de l'espace libre disponible dans la base de données9) Show details for a database          // Affichage d'informations détaillées sur la base de données spécifiée10) Recreate a database                  // Création d'une nouvelle base de données vide basée sur les paramètres d'une base de données existante11) Manage database encryption           // Gestion du cryptage de la base de données.12) Return unused space for a database   // Libération de l'espace inutilisé dans la base de données13) Compact free space in a database     // Compression de l'espace libre dans la base de données. Cette fonction est limitée aux versions disponibles (※).14) Defragment a database                // Défragmentation de la base de données. Cette fonction est limitée aux versions disponibles(※).15) Show background database tasks       // Affichage des tâches de base de donnéesde référence

※Limitation：Veuillez noter que les fonctions de compression et de défragmentation peuvent ne pas être disponibles en fonction de votre version.
　　　　Pour plus d'informations, voir.

Portail de gestion :
Administration du système > Configuration > Configuration du système > Base de données 

【Pour référence】
Comment compresser le fichier de la base de données
Comment créer des espaces de noms et des bases de données à l'aide du terminal ou de l'API ?
Comment monter/démonter la base de données par programmation ?
 

★^DATACHECK

Vérification de la concordance du contenu des deux fichiers IRIS.DAT.

【Pour référence】
Comment comparer plusieurs globales ou routines dans deux bases de données ?
 

★^DBSIZE

Mesure de la taille de la base de données.
Par exemple, elle est utilisé pour calculer l'espace disque nécessaire à une sauvegarde juste avant de l'effectuer. 

【Pour référence】
Comment estimer la taille de la sauvegarde pour les sauvegardes en ligne
 

★^GBLOCKCOPY

Les données globales d'une base de données sont copiées dans une autre base de données ou un autre espace de noms.
Dans ce cas, la taille supplémentaire (la taille libérée par Kill) n'est pas copiée, ce qui permet de réduire la taille de la base de données.

【Pour référence】
[FAQ] Comment réduire la taille du fichier de base de données IRIS.DAT ?
 

★^GETPPGINFO

Affichage des noms de tous les globales privés du processus en cours et l'espace qui leur est alloué en blocs.

【Pour référence】
Comment identifier les globales temporaires qui consomment de l'espace dans la base de données IRISTEMP ?
Qu'est-ce que globale privé du processus
 

★^%GCMP

Comparaison du contenu pour voir s'il y a des différences entre les deux globales.

【Pour référence】
Comment comparer le contenu de deux globales ?
 

★^%GSIZE

Vérification de la taille des données de chaque globale dans l'espace de noms.

Portail de gestion :
Administration du système > Configuration > Base de données locale > Globale

【Pour référence】
Comment trouver la taille des données pour chaque globale ?
Signification de chaque élément sorti via ^%GSIZE
 

★^INTEGRIT

Vérification de l'intégrité structurelle d'un ensemble de bases de données ou d'un sous-ensemble de globales dans une base de données.

Portail de gestion :
Fonctionnement du système > Base de données > Contrôle d'intégrité
 

★^JOBEXAM

Affichage d'une liste de processus. Il est également possible d'afficher les détails de chaque processus et de l'arrêter.

Portail de gestion :
Fonctionnement du système > Processus
 

★^JOURNAL

Configuration de la journalisation.
L'utilitaire ^JOURNAL comporte les éléments de menu suivants

%SYS>do^JOURNAL1) Begin Journaling (^JRNSTART)             // Démarrage de journalisation2) Stop Journaling (^JRNSTOP)               // Arrêt de journalisation3) Switch Journal File (^JRNSWTCH)          // Commutation des fichiers du journal4) Restore Globals From Journal (^JRNRESTO) // Restauration des fichiers du journal5) Display Journal File (^JRNDUMP)          // Affichage des fichiers du journal6) Purge Journal Files (PURGE^JOURNAL)      // Suppression du fichier du journal7) Edit Journal Properties (^JRNOPTS)       // Modification des options du journal8) Activate or Deactivate Journal Encryption (ENCRYPT^JOURNAL())    // Activer ou désactiver le cryptage du journal9) Display Journal status (Status^JOURNAL)  // Affichage de l'état actuel du journal10) -not available-
11) -not available-
12) Journal catch-up for mirrored databases (MirrorCatchup^JRNRESTO) // Rattrapage du journal pour les bases de données mises en miroir13) -not available-

Portail de gestion :
Administration du système > Configuration > Configuration du système > Paramètres du journal
Fonctionnement du système > Journaux  

★^LOCKTAB

Affichage et suppression des informations de verrouillage actuellement utilisées.

Portail de gestion :
Fonctionnement du système > Verrouillage 

【Pour référence】
Comment obtenir des informations sur le verrouillage au sein d'un programme
 

★^mgstat

Enregistrement continu des informations du compteur sur l'accès global à un fichier en unités de cycles d'échantillonnage (la valeur par défaut est de 2 secondes).
^mgstat est également exécuté lors de l'exécution de l'utilitaire ^SystemPerformance et fait partie du rapport de performance HTML.

【Pour référence】
GUI basée sur Grafana pour mgstat (outil de surveillance du système InterSystems Caché / Ensemble / HealthShare).
 

★^MIRROR

Les fonctions de configuration, de gestion et d'état de la mise en miroir.

Portail de gestion :
Administration du système > Configuration > Paramètres du miroir

【Pour référence】
Exemple de configuration HA et DR avec mise en miroir de la base de données
Performance 101
Synchroniqation et conditions de suppression des fichiers miroir du journal
À propos de la fonction de mise en miroir

★^MONMGR

Contrôle du journal des messages (messages.log) de l'instance IRIS afin de détecter les alertes signalées par le système et de générer des notifications (alert.log) ou d'envoyer des courriers électroniques.

【Pour référence】
Comment faire pour que le journal des messages (messages.log) envoie un courriel avec une sévérité de 2 ou supérieure ?
 

★^SECURITY

Cette fonction permet de configurer et de maintenir les données essentielles au bon fonctionnement de la sécurité d'IRIS.
L'utilitaire ^SECURITE comporte les éléments de menu suivants.

%SYS>do^SECURITY1) User setup                     // Affichage, ajout et modification de la configuration utilisateur2) Role setup                     // Affichage, ajout et modification de la configuration des rôles3) Service setup                  // Affichage ou modification de la configuration du service4) Resource setup                 // Affichage, ajout et modification de la configuration des ressources.5) Application setup              // Affichage, ajout et modification des configurations de l'application.6) Auditing setup                 // Affichage et exportation des journaux d'audit8) SSL configuration setup        // Affichage, ajout et modification des configurations SSL9) Mobile phone service provider setup  // Affichage ou modification des configurations des fournisseurs de services de téléphonie mobile10) OpenAM Identity Services setup      // Configuration du service OpenAM ID11) Encryption key setup          // Configuration et gestion des fichiers de clés de cryptage des bases de données12) System parameter setup        // Navigation et modification des paramètres de sécurité de l'ensemble du système13) X509 User setup               // Affichage, ajout et modification des informations d'identification X.509 utilisées pour la sécurité des services web14) KMIP server setup             // Gestion et configuration des serveurs KMIP (le protocole d'interopérabilité de gestion des clés)15) Exit

Portail de gestion :
Administration du système > Sécurité

【Pour référence】
Les applications CSP/REST ne se connectent pas. Comment faut-il procéder pour résoudre ce problème ?
Conseils sur l'exportation et l'importation des paramètres de sécurité
 

★^%SS

Liste des informations sur l'état de chaque processus actif dans le système actuel ( fonction de référence uniquement).
Pour obtenir des informations détaillées sur chaque processus ou pour mettre fin à un processus, utilisez ^JOBEXAM.

Portail de gestion :
Fonctionnement du système > Processus
 

★^SYSLOG

Sortie des informations du journal des erreurs internes d'IRIS qui sont enregistrées dans une partie de la mémoire partagée.
Ce journal peut contenir des informations de diagnostic importantes en cas de problèmes avec le système.

1. La méthode d'exécution est la suivante

USER>zn"%SYS"%SYS>do^SYSLOG
Device:   // Appuyez sur "Enter" ou saisissez le chemin du fichier de sortie
Right margin: 80 =>   // Appuyez sur "Enter"
Show detail? No => Yes   // Appuyez sur "Yes" + <"Enter">
InterSystems IRIS System Error Log printed on May 192023 at 11:53 AM
--------------------------------------------------------
Printing the last 8 entries out of 8 total occurrences.
Err   Process    Date/Time           Mod Line  Routine            Namespace
3     30848      05/19/202309:01:02AM 911304 BF0+1373^SYS.Datab %SYS
:

※L'erreur ci-dessus est Err = 3, il s'agit donc d'une erreur du système d'exploitation "Le chemin d'accès spécifié est introuvable".
Err n'est pas nécessairement une erreur du système d'exploitation. Veuillez contacter notre centre d'assistance pour plus d'informations.

C:\>net helpmsg 3
Le chemin d'accès spécifié est introuvable.

2. Les informations SYSLOG étant stockées dans la mémoire partagée, elles sont perdues lors de l'arrêt d'IRIS.
   En définissant les paramètres de configuration IRIS suivants, les informations du journal des erreurs internes sont enregistrées dans messages.log lorsque IRIS est arrêté.

   Portail de gestion :
   Administration du système > Configuration > Paramètres supplémentaires > Compatibilité 
      ShutDownLogErrors  Faux (par défaut) -> Vrai
    

【Pour référence】
syslog - Ce que cela représente et ce que cela signifie
 

★^SystemCheck

IRIS recueille des informations sur l'état des processus en cours d'utilisation, la mémoire partagée, etc.
En cas de problème, il faut d'abord obtenir ces informations de diagnostic (^SystemCheck).
※Dans Caché/Ensemble, le nom de l'utilitaire était ^Buttons.

La méthode d'exécution est la suivante

%SYS>do^SystemCheck
Diagnostic Report Build # 087 Evidence Logging Tool

Cet outil de reporting fournit les informations nécessaires pour InterSystems
L'assistance technique est en mesure d'analyser la plupart des problèmes. Veuillez envoyer le fichier résultant avec
chaque nouveau problème envoyé à l'assistance technique.

Cette procédure prendra environ 5 minutes. Veuillez faire preuve de patience.

Continuer (Y)? y    // Appuyer sur Enter ou "oui"(y)
Signaler les informations spécifiques à l'interopérabilité ? [Non] n    //Appuyer sur Non (n)
Collecte d'informations, veuillez ne pas interrompre ce processus.

Veuillez attendre environ 30 secondes pour%SS les instantanés.
Veuillez attendre environ 1 minute pourles instantanés "irisstat".

Collecte des informations GloStat en cours.
Veuillez attendre environ 1 minute and 40 secondes.

Envoyez les fichiers suivants par FTP à ISC Support :
c:\intersystems\iris\mgr\***202208260909.html in text mode - 579,486 bytes
%SYS>
// \mg.*La partie *** dépendra de la licence utilisée

Si vous ne pouvez pas ouvrir le terminal parce que le système est bloqué ou pour une autre raison, exécutez IRISHung.cmd (IRISHung.sh pour les systèmes Linux) à partir de l'invite de commande Windows.
Après quelques minutes, le fichier IRISHung_mmss.html sera généré sous <IRIS répértoire d'installation>\mgr.

C:\>cd /intersystems/iris/bin    // \bin 
C:\InterSystems\IRIS\bin>IRISHung.cmd

Nom complet du répertoire InterSystems IRIS : C:\InterSystems\IRIS    // Saisissez le répertoire d'installation d'IRIS.
Écrire des informations à "C:\InterSystems\IRIS\Mgr\IRISHung_mmss.html"
Veuillez patienter...

Fichier du journal enregistré à :
"C:\InterSystems\IRIS\Mgr\IRISHung_mmss.html"
La taille du fichier est de ***** octets

C:\InterSystems\IRIS\bin>

【Pour référence】
Guide de dépannage d'InterSystems IRIS - Collecte d'informations (^Comment utiliser SystemCheck/IRISHung)
※P.7 (1). Exécution de rapports de diagnostic (^SystemCheck).

[Comment collecter des informations lorsqu'un problème survient (IRIS / IRIS for Health / UCR eds.)

★^SystemPerformance

Collecte de données détaillées sur les performances des instances IRIS et des plates-formes sur lesquelles elles s'exécutent.
※Dans Caché/Ensemble, le nom de l'utilitaire était ^pButtons.

【Pour référence】
InterSystems: plates-formes de données et performances - Partie 1
InterSystems: plates-formes de données et performances - Partie 2 
InterSystems: plates-formes de données et performances - Partie 3: accent sur la CPU

★^TASKMGR

Planification et gestion de tâches telles que la suppression des journaux et les sauvegardes automatiques.

Portail de gestion :
Fonctionnement du système > Tâches

【Pour référence】
Méthode de notification par courrier électronique en cas d'erreur lors du démarrage d'une tâche

Les méthodes écrites en ObjectScript peuvent utiliser des arguments de type " passage par référence " pour renvoyer des informations à l'appelant. Python ne supporte pas les arguments de type " passage par référence ", donc Python intégré dans IRIS ne les supporte pas non plus. Voilà, c'est la fin de cet article, j'espère qu'il vous a plu 😉 Mais attendez, et le Rock & Roll Classic ?

En fait, puisque les valeurs retournées dans les arguments de méthode peuvent être utiles, cet article montre plusieurs façons de procéder, entre ObjectScript et Python intégré. Commençons donc par l'exemple le plus simple : l'appel d'une méthode ObjectScript qui dispose déjà d'un argument Python de type " passage par référence ". Voici la méthode :

ClassMethod Sum(a as %Integer, b as %Integer, Output sum as %Integer)
{
	set sum = a + b
}

Il est facile de l'appeler à partir d'ObjectScript. Il vous suffit de ne pas oublier de mettre un "." avant le troisième argument.

USER>set x = 4, y = 5
USER>do ##class(Simple.Demo).Sum(x, y, .z)
USER>write z
9

Mais vous n'êtes pas ici pour cela. Et si vous l'appeliez depuis Python ? Il faut créer un objet de référence spécial en utilisant iris.ref() et le fournir comme troisième argument. Vous ne devez pas placer un "." avant le troisième argument. (Notez que je démarre le shell Python au moyen de :py, un alias pour la fonction do $system.Python.Shell(), une fonction qui mérite un article de la communauté des développeurs pour elle-même).

USER>:py

Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
Type quit() or Ctrl-D to exit this shell.
>>> x = 4
>>> y = 5
>>> z = iris.ref(0)
>>> z
<iris.ref object at 0xffff164ca3b0>

>>> iris.cls("Simple.Demo").Sum(x, y, z)
>>> z.value
9

Vous trouverez ici de la documentation sur iris.ref().

Ensuite, examinons quelques façons de permettre à une méthode Python intégré de renvoyer des valeurs dans ses arguments. Pour ces exemples, nous utiliserons des structures JSON qui peuvent être passées dans la méthode et modifiées. Après le retour de la méthode, puisque ces structures sont des références d'objet, toute modification est visible pour l'appelant. Pour JSON, Python supporte les structures dict et list, tandis qu'IRIS supporte les structures %DynamicObject et %DynamicArray. **Important : **il n'y a aucune conversion automatique des structures JSON d'ObjectScript vers les structures JSON de Python (ou vice versa) lorsqu'elles sont passées autour.

Ces options permettent plusieurs combinaisons possibles :

• À partir de Python, créer un dict ou une liste Python et les passer dans la méthode.
• À partir d'ObjectScript, créer un dict ou une liste Python et les passer dans la méthode.
• À partir de Python, créer un %DynamicObject/%DynamicArray IRIS et le passer dans la méthode.
• À partir d'ObjectScript, créer un %DynamicObject/%DynamicArray IRIS et le passer dans la méthode.

C'est parti pour le rock & roll !

Beatles() est une méthode Python qui renvoie une dict et une liste

/// modifier et renvoyer un dict et une liste
ClassMethod Beatles(membersdict As %SYS.Python, memberslist As %SYS.Python) [ Language = python ]
{
	membersdict['member1'] = 'John'
	memberslist.append('John')
	membersdict['member2'] = 'Paul'
	memberslist.append('Paul')
	membersdict['member3'] = 'George'
	memberslist.append('George')
	membersdict['member4'] = 'Ringo'
	memberslist.append('Ringo')
}

Voici un exemple d'appel à partir de Python :

USER>:py

Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
Tapez quit() ou Ctrl-D pour quitter ce shell.
>>> d = {}
>>> l = []
>>> iris.cls("Simple.Demo").Beatles(d, l)
>>> d
{'member1': 'John', 'member2': 'Paul', 'member3': 'George', 'member4': 'Ringo'}
>>> l
['John', 'Paul', 'George', 'Ringo']

Voici un exemple d'appel à partir d'ObjectScript, en passant un dict vide et une liste vide créée en appelant des méthodes de Builtins() :

USER>set d = ##class(%SYS.Python).Builtins().dict()        
USER>set l = ##class(%SYS.Python).Builtins().list()
USER>do ##class(Simple.Demo).Beatles(d, l)
USER>zwrite d
d=7@%SYS.Python  ; {'member1': 'John', 'member2': 'Paul', 'member3': 'George', 'member4': 'Ringo'}  ; <oref>
USER>zwrite l
l=2@%SYS.Python  ; ['John', 'Paul', 'George', 'Ringo']  ; <oref>

Voici quelques documents sur l'utilisation des dicts et des lists à partir d'ObjectScript.

Who() est une méthode Python qui renvoie un %DynamicObject et un %DynamicArray.

/// modifier et renvoyer un %DynamicObject et un %DynamicArray
ClassMethod Who(membersObject As %DynamicObject, membersArray As %DynamicArray) [ Language = python ]
{
	import iris

	membersObject._Set('member1','Roger')
	membersArray._Push('Roger')
	membersObject._Set('member2','Pete')
	membersArray._Push('Pete')
	membersObject._Set('member3','John')
	membersArray._Push('John')
	membersObject._Set('member4','Keith')
	membersArray._Push('Keith')
}

Voici un exemple d'appel à partir de Python, en passant un %DynamicObject vide et un %DynamicArray vide créés en utilisant iris.cls() pour appeler _New(), et en affichant leur contenu à l'aide du %JSON.Formatter :

USER>:py

Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
Tapez quit() ou Ctrl-D pour quitter ce shell.
>>> f = iris.cls("%JSON.Formatter")._New()
>>> o = iris.cls("%DynamicObject")._New()
>>> a = iris.cls("%DynamicArray")._New()
>>> o
<iris.%Library.DynamicObject object at 0xffff165c0210>
>>> a
<iris.%Library.DynamicArray object at 0xffff165c0360>
>>> f.Format(o)
{
}
>>> f.Format(a)
[
]
>>> iris.cls("Simple.Demo").Who(o, a)
>>> f.Format(o)
{
  "member1":"Roger",
  "member2":"Pete",
  "member3":"John",
  "member4":"Keith"
}
>>> f.Format(a)
[
  "Roger",
  "Pete",
  "John",
  "Keith"
]

Voici un exemple d'appel à partir d' ObjectScript:

USER>set o = {}, a = []
USER>do ##class(Simple.Demo).Who(o, a)
USER>zwrite o
o={"member1":"Roger","member2":"Pete","member3":"John","member4":"Keith"}  ; <dynamic object="">
USER>zwrite a
a=["Roger","Pete","John","Keith"]  ; <dynamic array="">

Voici quelques documents sur les objets/tableaux dynamiques.

Puisque je vois que certains parmi vous agitent les lumières de leurs téléphones portables d'avant en arrière en demandant un rappel, je vais vous dire une dernière chose : le passage d'un %DynamicObject dans une méthode Python est utile pour une autre raison, qui n'est pas liée au passage par référence. Cela vous permet d'appeler une méthode Python qui accepte des arguments nommés. Lisez tout cela ici !

Le code source de l'article est disponible à l'adresse suivante : https://github.com/antonum/ha-iris-k8s 

Dans l'article précédent, nous avons expliqué comment configurer IRIS sur un cluster k8s avec une haute disponibilité, basée sur le stockage distribué, au lieu de la mise en miroir traditionnelle. À titre d'exemple, cet article utilisait le cluster Azure AKS. Dans cet article, nous poursuivons l'exploration des configurations de haute disponibilité sur k8s. Cette fois, basée sur Amazon EKS (service Kubernetes géré par AWS) et incluant une option pour effectuer la sauvegarde et la restauration de la base de données, basée sur Kubernetes Snapshot.

Installation

Passons tout de suite au travail. Tout d'abord, vous devez disposer d'un compte AWS et des outils AWS CLI,kubectl et eksctl. Pour créer le nouveau cluster, exécutez la commande suivante :

eksctl create cluster \
--name my-cluster \
--node-type m5.2xlarge \
--nodes 3 \
--node-volume-size 500 \
--region us-east-1

Cette commande prend ~15 minutes, elle déploie le cluster EKS et en fait un cluster par défaut pour votre outil kubectl. Vous pouvez vérifier le déploiement en exécutant :

kubectl obtenir les noeuds
NOM                                              ÉTAT    RÔLES            AGE   VERSION
ip-192-168-19-7.ca-central-1.compute.internal    Prêt    <néant>   18d   v1.18.9-eks-d1db3c
ip-192-168-37-96.ca-central-1.compute.internal   Prêt    <néant>   18d   v1.18.9-eks-d1db3c
ip-192-168-76-18.ca-central-1.compute.internal   Prêt    <néant>   18d   v1.18.9-eks-d1db3c

L'étape suivante consiste à installer le moteur de stockage distribué Longhorn.

kubectl créer l'espace de nom longhorn-system
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.0/deploy/iscsi/longhorn-iscsi-installation.yaml --namespace longhorn-system
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml --namespace longhorn-system

Et enfin, l'IRIS lui-même :

kubectl apply -f https://github.com/antonum/ha-iris-k8s/raw/main/tldr.yaml

À ce stade, vous aurez un cluster EKS entièrement fonctionnel avec le stockage distribué Longhorn et le déploiement IRIS installé. Vous pouvez revenir à l'article précédent et tenter de causer toutes sortes de dommages au cluster et au déploiement d'IRIS, juste pour voir comment le système se répare de lui-même. Consultez la section Simuler la défaillance section.

Bonus n° 1 IRIS en ARM

IRIS EKS et Longhorn sont tous deux compatibles avec l'architecture ARM. Nous pouvons donc déployer la même configuration en utilisant les instances AWS Graviton 2, basées sur l'architecture ARM.

Il suffit de changer le type d'instance pour les nœuds EKS en famille 'm6g' et l'image IRIS en ARM.

eksctl créer cluster \
--name my-cluster-arm \
--node-type m6g.2xlarge \
--nodes 3 \
--node-volume-size 500 \
--region us-east-1

tldr.yaml

conteneurs:
#- image: store/intersystems/iris-community:2020.4.0.524.0
- image: store/intersystems/irishealth-community-arm64:2020.4.0.524.0
name: iris

Ou utilisez simplement :

kubectl apply -f https://github.com/antonum/ha-iris-k8s/raw/main/tldr-iris4h-arm.yaml

Et voilà ! Vous avez obtenu votre cluster IRIS Kubernetes, fonctionnant sur la plateforme ARM.

Bonus n°2 - Sauvegarde et restauration

Une partie souvent négligée de l'architecture niveau production est la capacité de créer des sauvegardes de votre base de données et de les restaurer rapidement et/ou de les cloner en cas de besoin.

Dans Kubernetes, la façon la plus courante de le faire est d'utiliser des instantanés de volumes persistants (Persistent Volume Snapshots).

Tout d'abord, vous devez installer tous les composants k8s requis :

#Installer CSI Snapshotter et CRDs

kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl apply -n kube-system -f https://github.com/kubernetes-csi/external-snapshotter/raw/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml
kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml

Ensuite, configurez les informations d'identification du seau S3 pour Longhorn (voir instructions détaillées):

#Le godet s3 cible de la sauvegarde Longhorn et les informations d'identification à utiliser par Longhorn pour accéder à ce godet.
#Voir https://longhorn.io/docs/1.1.0/snapshots-and-backups/backup-and-restore/set-backup-target/ pour les instructions d'installation manuelle
longhorn_s3_bucket=longhorn-backup-123xx #le nom du godet doit être unique au niveau global, à moins que vous ne souhaitiez réutiliser des sauvegardes et des informations d'identification existantes.
longhorn_s3_region=us-east-1
longhorn_aws_key=AKIAVHCUNTEXAMPLE
longhorn_aws_secret=g2q2+5DVXk5p3AHIB5m/Tk6U6dXrEXAMPLE

La commande suivante reprend les variables d'environnement de l'étape précédente et les utilise pour configurer la sauvegarde Longhorn.

#configurer la cible de sauvegarde Longhorn et les informations d'identification

cat <<EOF | kubectl apply -f -
apiVersion: longhorn.io/v1beta1
kind: Setting
metadata:
 name: backup-target
 namespace: longhorn-system
value: "s3://$longhorn_s3_bucket@$longhorn_s3_region/" # la cible de sauvegarde ici
---
apiVersion: v1
kind: Secret
metadata:
 name: "aws-secret"
 namespace: "longhorn-system"
 labels:
data:
 # echo -n '<secret>' | base64
 AWS_ACCESS_KEY_ID: $(echo -n $longhorn_aws_key | base64)
 AWS_SECRET_ACCESS_KEY: $(echo -n $longhorn_aws_secret | base64)
---
apiVersion: longhorn.io/v1beta1
 kind: Setting
metadata:
 name: backup-target-credential-secret
 namespace: longhorn-system
value: "aws-secret" # nom secret de la sauvegarde ici
EOF

Cela peut sembler compliqué, mais cela indique en fait à Longhorn d'utiliser un godet S3 spécifique avec les informations d'identification spécifiées pour stocker le contenu des sauvegardes.

Voilà, c'est fait ! Si vous allez maintenant dans l'interface utilisateur de Longhorn, vous pourrez créer des sauvegardes, les restaurer, etc.

Voici un petit rappel sur la façon de se connecter à l'interface utilisateur Longhorn :

kubectl get pods -n longhorn-system
# noter le nom complet du pod pour le pod 'longhorn-ui-...'
kubectl port-forward longhorn-ui-df95bdf85-469sz 9000:8000 -n longhorn-system

Cela permettrait de transférer le trafic vers Longhorn UI sur votre site http://localhost:9000.

Sauvegarde/restauration programmatique

Effectuer une sauvegarde et une restauration via l'interface utilisateur Longhorn peut être une première étape suffisante - mais nous ferons un pas en avant et effectuerons la sauvegarde et la restauration de manière programmatique, en utilisant les API Snapshot de k8s.

Tout d'abord, l'instantané lui-même. iris-volume-snapshot.yaml

apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
  name: iris-longhorn-snapshot
spec:
  volumeSnapshotClassName: longhorn
  source:
    persistentVolumeClaimName: iris-pvc

Cet instantané de volume fait référence au volume source 'iris-pvc' que nous utilisons pour notre déploiement IRIS. Il suffit donc de l'appliquer pour lancer immédiatement le processus de sauvegarde.

C'est une bonne idée d'exécuter la fonction de Gel/Dégel du démon d'écriture d'IRIS avant/après l'instantané.

#Gel du démon d'écriture
echo "Gel du démon d'écriture d'IRIS"
kubectl exec -it -n $namespace $pod_name -- iris session iris -U%SYS "##Class(Backup.General).ExternalFreeze()"
status=$?
if [[ $status -eq 5 ]]; then
 echo "IRIS WD EST CONGELÉ, exécution de la sauvegarde"
 kubectl apply -f backup/iris-volume-snapshot.yaml -n $namespace
elif [[ $status -eq 3 ]]; then
 echo "ÉCHEC DU GEL DE L'IRIS WD"
fi
#Dégel du démon d'écriture
kubectl exec -it -n $namespace $pod_name -- iris session iris -U%SYS "##Class(Backup.General).ExternalThaw()"

Le processus de restauration est assez simple. Il s'agit essentiellement de créer un nouveau PVC et de spécifier l'instantané comme source.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: iris-pvc-restored
spec:
  storageClassName: longhorn
  dataSource:
    name: iris-longhorn-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Il suffit ensuite de créer un nouveau déploiement, basé sur ce PVC. Regardez ce script de test dans un référentiel github qui se déroulerait de manière séquentielle :

• Créer un nouveau déploiement d'IRIS
• Ajouter des données à IRIS
• Geler le démon d'écriture, prendre un instantané, dégeler le démon d'écriture
• Créer un clone du déploiement d'IRIS, basé sur l'instantané.
• Vérifier que toutes les données sont toujours présentes

À ce stade, vous aurez deux déploiements IRIS identiques, l'un étant un clone par sauvegarde de l'autre.

Profitez-vous-en bien !

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>.

Le nuage Amazon Web Services (AWS) offre un large éventail de services d'infrastructure, tels que des ressources de calcul, des options de stockage et des réseaux, qui sont fournis comme un service public : à la demande, disponibles en quelques secondes, avec une tarification à l'usage. De nouveaux services peuvent être mis à disposition rapidement, sans dépenses d'investissement initiales. Les entreprises, les start-ups, les petites et moyennes entreprises et les clients du secteur public peuvent ainsi accéder aux éléments de base dont ils ont besoin pour répondre rapidement à l'évolution des exigences commerciales.

Updated: 2-Apr, 2021 

L'aperçu et les détails suivants sont fournis par Amazon et peuvent être consultés à l'adresse suivante

ici.

Aperçu

Infrastructure globale d'AWS

L'infrastructure du cloud AWS est construite autour de régions et de AZ (zones de disponibilité). Une région est un emplacement physique dans le monde où nous avons plusieurs zones de disponibilité. Les zones de disponibilité sont constituées d'un ou plusieurs centres de données distincts, chacun doté d'une alimentation, d'une mise en réseau et d'une connectivité redondantes, hébergés dans des installations séparées. Ces zones de disponibilité vous offrent la possibilité d'exploiter des applications et des bases de données de production qui sont plus hautement disponibles, plus tolérantes aux pannes et plus évolutives qu'il ne serait possible de le faire à partir d'un seul centre de données.

Les détails de l'infrastructure mondiale d'AWS sont disponiblesici.

Sécurité et conformité d'AWS

La sécurité dans le cloud computing ressemble beaucoup à la sécurité de vos centres de données sur site, mais sans les coûts de maintenance des installations et du matériel. Dans le cloud, vous n'avez pas à gérer de serveurs physiques ou de dispositifs de stockage. En revanche, vous utilisez des outils de sécurité logiciels pour surveiller et protéger le flux d'informations entrant et sortant de vos ressources en cloud.

Le cloud AWS permet un modèle de responsabilité partagée. Alors qu'AWS gère la sécurité du cloud, vous êtes responsable de la sécurité dans le cloud. Cela signifie que vous gardez le contrôle de la sécurité que vous choisissez de mettre en œuvre pour protéger votre propre contenu, votre plate-forme, vos applications, vos systèmes et vos réseaux, comme vous le feriez dans un centre de données sur site.

Les détails de la sécurité du cloud AWS peuvent être trouvés ici .

L'infrastructure informatique qu'AWS fournit à ses clients est conçue et gérée conformément aux meilleures pratiques de sécurité et à diverses normes de sécurité informatique.  Vous trouverez une liste complète des programmes d'assurance auxquels AWS se conforme ici .

AWS Cloud Plate-forme

AWS se compose many de services en nuage que vous pouvez utiliser dans des combinaisons adaptées aux besoins de votre entreprise ou de votre organisation. La sous-section suivante présente les principaux services AWS par catégorie qui sont couramment utilisés avec les déploiements d'InterSystems IRIS. Il existe de nombreux autres services disponibles et potentiellement utiles pour votre application spécifique.  N'hésitez pas à les rechercher si nécessaire.

Pour accéder aux services, vous pouvez utiliser l'AWS Management Console, l'interface de ligne de commande ou les kits de développement logiciel SDK (Software Development Kits).

<th>
  Détails
</th>

<td>
  Les détails de l'AWS Management Console sont disponibles ici.
</td>

<td>
  Les détails de l'Interface de ligne de commande AWS sont disponibles ici.
</td>

<td>
  Les détails des kits de développement logiciel SDK (Software Development Kits) sont disponibles ici.
</td>

<td>
  De nombreuses options sont disponibles : Les détails d'Amazon Elastic Cloud Computing (EC2) sont disponibles ici Les détails d'Amazon EC2 Container Service (ECS) sont disponibles ici Les détails d'Amazon EC2 Container Registry (ECR) sont disponibles ici Les détails d'Amazon Auto Scaling sont disponibles ici
</td>

<td>
  De nombreuses options sont disponibles : Les détails d'Amazon Elastic Block Store (EBS) sont disponibles ici Les détails d'Amazon Simple Storage Service (S3) sont disponibles ici Les détails d'Amazon Elastic File System (EFS) sont disponibles ici
</td>

<td>
  De nombreuses options sont disponibles. Les détails d'Amazon Virtual Private Cloud (VPC) sont disponibles ici Les détails d'Amazon Elastic IP Addresses sont disponibles ici Les détails d'Amazon Elastic Network Interfaces sont disponibles ici Les détails d'Amazon Enhanced Networking pour Linux sont disponibles ici Les détails d'Amazon Elastic Load Balancing (ELB) sont disponibles ici Les détails d'Amazon Route 53 sont disponibles ici
</td>

Exemples d'architectures InterSystems IRIS

Dans le cadre de cet article, des exemples de déploiement d'InterSystems IRIS pour AWS sont fournis comme point de départ pour le déploiement de votre application spécifique. Ils peuvent être utilisés comme ligne directrice pour de nombreuses possibilités de déploiement.  Cette architecture de référence démontre des options de déploiement très robustes, allant des plus petits déploiements aux charges de travail massivement évolutives pour les besoins de calcul et de données.  

Les options de haute disponibilité et de reprise après sinistre sont abordées dans ce document, ainsi que d'autres opérations système recommandées.  Il est prévu que ces dernières soient modifiées par l'individu pour soutenir les pratiques standard et les politiques de sécurité de son organisation.

InterSystems est à votre disposition pour toute discussion ou question sur les déploiements d'InterSystems IRIS basés sur AWS pour votre application spécifique.

Architectures de référence exemplaires

Les architectures exemplaires suivantes fournissent plusieurs configurations différentes avec des capacités et des possibilités croissantes. Considérez ces exemples de petit développement / production / production importante / production avec des clusters shards qui montrent la progression depuis une configuration modeste pour les efforts de développement jusqu'à des solutions massivement évolutives avec une haute disponibilité appropriée entre les zones et une reprise après sinistre multirégionale. En outre, un exemple d'architecture utilisant les nouvelles capacités de sharding d'InterSystems IRIS Data Platform pour les charges de travail hybrides avec traitement massivement parallèle des requêtes SQL.

Configuration du petit développement

Dans le présent exemple, une configuration minimale est utilisée pour illustrer un environnement de développement de petite taille capable de prendre en charge jusqu'à 10 développeurs et 100 Go de données.  Il est facile de prendre en charge un plus grand nombre de développeurs et de données stockées en changeant simplement le type d'instance de la machine virtuelle et en augmentant le stockage du ou des volumes EBS, le cas échéant.

Cela permet de soutenir les efforts de développement et de se familiariser avec les fonctionnalités d'IRIS d'InterSystems, ainsi qu'avec la création et l'orchestration de conteneurs Docker, si nécessaire.  La haute disponibilité avec la mise en miroir des bases de données n'est généralement pas utilisée avec une petite configuration, mais elle peut être ajoutée à tout moment si la haute disponibilité est nécessaire.  

Diagramme exemplaire de petite configuration

Le diagramme exemplaire de la Figure 2.1.1-a ci-dessous illustre le tableau des ressources de la Figure 2.1.1-b.  Les passerelles incluses ne sont que des exemples et peuvent être adaptées en fonction des pratiques réseau standard de votre organisation.  

Figure-2.1.1-a: Architecture exemplaire de petits développements

Les ressources suivantes dans le VPC AWS sont provisionnées comme une petite configuration minimale.  Les ressources AWS peuvent être ajoutées ou supprimées le cas échéant.  

Ressources AWS pour petites configurations

Un exemple de ressources AWS de petite configuration (Small Configuration AWS) est fourni ci-dessous dans le tableau suivant.

Une sécurité du réseau appropriée et des règles de pare-feu doivent être envisagées pour empêcher tout accès indésirable au VPC.  Amazon fournit les meilleures pratiques en matière de sécurité réseau pour commencer, qui sont disponibles : ici

https://docs.aws.amazon.com/vpc/index.html#lang/en_us

https://docs.aws.amazon.com/quickstart/latest/vpc/architecture.html#best-practices

Si votre politique de sécurité exige des instances VM réellement internes, vous devrez configurer manuellement un proxy NAT sur votre réseau et une route correspondante pour que les instances internes puissent atteindre l'Internet. Il est important de noter que vous ne pouvez pas vous connecter à une instance VM entièrement interne directement en utilisant SSH. Pour vous connecter à de telles machines internes, vous devez configurer une instance de bastion qui possède une adresse IP externe, puis la traverser par un tunnel. Un hôte bastion peut être provisionné pour fournir le point d'entrée externe dans votre VPC.  

Les détails de l'utilisation des bastion hosts sont disponibles : ici

https://aws.amazon.com/blogs/security/controlling-network-access-to-ec2-instances-using-a-bastion-server/

https://docs.aws.amazon.com/quickstart/latest/linux-bastion/architecture.html

Configuration de production

Dans cet exemple, une configuration plus importante est traîtée comme exemple de configuration de production qui incorpore la capacité de mise en miroir de la base de données InterSystems IRIS pour prendre en charge la haute disponibilité et la reprise après sinistre.

Cette configuration comprend une paire de serveurs de base de données InterSystems IRIS en miroir synchrone répartis entre deux zones de disponibilité dans la région 1 pour un basculement automatique, et un troisième membre miroir asynchrone DR dans la région 2 pour une reprise après sinistre dans le cas peu probable où une région AWS entière serait hors ligne. 

DLes détails d'une région multiple avec la connectivité Multi-VPC sont disponibles ici.

InterSystems Arbiter et le serveur ICM sont déployés dans une troisième zone séparée pour plus de résilience.  L'exemple d'architecture comprend également un ensemble de serveurs Web facultatifs à charge équilibrée pour prendre en charge une application Web.  Ces serveurs Web et la passerelle InterSystems Gateway peuvent être mis à l'échelle indépendamment selon les besoins.

Diagramme exemplaire de la configuration de la production

Le diagramme exemplaire de la Figure 2.2.1-a illustre le tableau des ressources de la Figure 2.2.1-b.  Les passerelles incluses ne sont que des exemples et peuvent être adaptées en fonction des pratiques réseau standard de votre organisation.  

Figure 2.2.1-a : Architecture de production exemplaire avec haute disponibilité et reprise après sinistre

Les ressources suivantes au sein du AWS VPC sont recommandées au minimum pour supporter une charge de travail de production pour une application web.  Les ressources AWS peuvent être ajoutées ou supprimées selon les besoins.

Production Configuration AWS Resources

Un exemple de configuration de production des ressources AWS est fourni dans le tableau suivant.

Configuration de production importante

Dans cet exemple, une configuration massivement évolutive est fournie en étendant la capacité d'InterSystems IRIS pour introduire également des serveurs d'applications utilisant le protocole ECP (Enterprise Cache Protocol) d'InterSystems afin de permettre une évolution horizontale massive des utilisateurs.  Un niveau de disponibilité encore plus élevé est inclus dans cet exemple car les clients ECP préservent les détails de la session même en cas de basculement d'une instance de base de données.  Plusieurs zones de disponibilité AWS sont utilisées avec des serveurs d'application basés sur ECP et des membres miroirs de base de données déployés dans plusieurs régions.  Cette configuration est capable de prendre en charge des dizaines de millions d'accès à la base de données par seconde et plusieurs téraoctets de données.  

Diagramme exemplaire de la configuration de la production

Le schéma exemplaire de la Figure 2.3.1-a illustre le tableau des ressources de la Figure 2.3.1-b.  Les passerelles incluses ne sont que des exemples, et peuvent être ajustées en fonction des pratiques réseau standard de votre organisation.  

Cette configuration comprend une paire de miroirs de basculement, quatre clients ECP ou plus (serveurs d'application) et un ou plusieurs serveurs Web par serveur d'application. Les paires de miroirs de base de données à basculement sont réparties entre deux zones de disponibilité AWS différentes dans la même région pour la protection du domaine de défaillance, avec le serveur InterSystems Arbiter et ICM déployé dans une troisième zone distincte pour une résilience supplémentaire.  

La reprise après sinistre s'étend à une deuxième région AWS et à une ou plusieurs zones de disponibilité, comme dans l'exemple précédent.  Plusieurs régions DR peuvent être utilisées avec plusieurs cibles de membres miroirs DR Async si nécessaire.

Figure 2.3.1-a : Architecture exemplaire de la production importante avec serveurs d'application ECP.

Les ressources suivantes au sein du projet AWS VPC sont recommandées au minimum pour prendre en charge un cluster shard. Les ressources AWS peuvent être ajoutées ou supprimées selon les besoins.  

Ressources AWS pour une configuration de la production importante

Un exemple de la configuration de la production importante des ressources AWS est fourni dans le tableau suivant.

Configuration de la production avec InterSystems IRIS Sharded Cluster

Dans cet exemple, une configuration horizontale pour les charges de travail hybrides avec SQL est fournie en incluant les nouvelles capacités d'InterSystems IRIS Sharded Cluster pour fournir une mise à l'échelle horizontale massive des requêtes et des tables SQL sur plusieurs systèmes.  Les détails d'InterSystems IRIS Sharded Cluster et de ses capacités sont présentés plus en détail dans la section 9 de cet article.

Diagramme de configuration exemplaire de production avec InterSystems IRIS Sharded Cluster

Le diagramme exemplaire de la Figure 2.4.1-a illustre la table des ressources de la Figure 2.4.1-b.  Les passerelles incluses ne sont que des exemples et peuvent être adaptées en fonction des pratiques réseau standard de votre organisation.  

Cette configuration comprend quatre paires de miroirs comme nœuds de données.  Chacune des paires de miroirs de base de données à basculement est répartie entre deux zones de disponibilité AWS différentes dans la même région pour la protection du domaine de défaillance, avec InterSystems Arbiter et le serveur ICM déployés dans une troisième zone distincte pour une résilience supplémentaire. 

Cette configuration permet à toutes les méthodes d'accès à la base de données d'être disponibles à partir de n'importe quel nœud de données du cluster.  Les données des grandes tableaux SQL sont physiquement réparties sur tous les nœuds de données pour permettre une parallélisation massive du traitement des requêtes et du volume de données.  La combinaison de toutes ces fonctionnalités permet de supporter des charges de travail hybrides complexes, telles que des requêtes SQL analytiques à grande échelle et l'ingestion simultanée de nouvelles données, le tout au sein d'une seule plate-forme de données InterSystems IRIS.

Figure 2.4.1-a : Exemple de configuration de production avec un Sharded Cluster à haute disponibilité

Notez que dans le diagramme ci-dessus et dans la colonne "type de ressource" du tableau ci-dessous, le terme "EC2" est un terme AWS représentant une instance de serveur virtuel AWS comme décrit plus en détail dans la section 3.1 de ce document. Il ne représente ni n'implique l'utilisation de "nœuds de calcul" dans l'architecture de cluster décrite au chapitre 9.

Les ressources suivantes au sein du VPC AWS sont recommandées au minimum pour prendre en charge un Sharded Cluster.  Les ressources AWS peuvent être ajoutées ou supprimées si nécessaire.  

Production avec des ressources de Sharded Cluster Configuration AWS/span>

Un exemple de la configuration de la production avec des ressources de Sharded Cluster Configuration AWS est fourni dans le tableau suivant.

Introduction aux Cloud Concepts

Amazon Web Services (AWS) fournit un environnement cloud riche en fonctionnalités pour l'infrastructure en tant que service (IaaS), entièrement capable de prendre en charge tous les produits InterSystems, y compris la prise en charge de DevOps basée sur les conteneurs avec la nouvelle plate-forme de données InterSystems IRIS. Il faut veiller, comme pour toute plateforme ou modèle de déploiement, à prendre en compte tous les aspects d'un environnement tels que les performances, la disponibilité, les opérations système, la haute disponibilité, la reprise après sinistre, les contrôles de sécurité et autres procédures de gestion.  Cet article couvre les trois principaux composants de tous les déploiements de cloud computing : Le calcul, le stockage et la mise en réseau.

Moteurs de calcul (machines virtuelles)

Dans AWS EC2, plusieurs options sont disponibles pour les ressources du moteur de calcul avec de nombreuses spécifications de CPU et de mémoire virtuelles et des options de stockage associées.  Il convient de noter qu'au sein d'AWS EC2, les références au nombre de vCPU dans un type de machine donné équivalent à un vCPU, soit un hyper-thread sur l'hôte physique au niveau de la couche hyperviseur.  

Dans le cadre de ce document, les types d'instance m5* et r5* EC2 seront utilisés et sont les plus largement disponibles dans la plupart des régions de déploiement AWS.  Cependant, l'utilisation d'autres types d'instance spécialisés tels que : x1* avec une très grande mémoire sont d'excellentes options pour les très grands ensembles de données de travail conservant des quantités massives de données en mémoire cache, ou i3* avec un stockage d'instance local NVMe.  Les détails de l'accord de niveau de service (SLA) d'AWS sont disponibles ici.

Stockage sur disque

Le type de stockage le plus directement lié aux produits InterSystems est celui des types de disques persistants, mais le stockage local peut être utilisé pour des niveaux de performance élevés si les restrictions de disponibilité des données sont comprises et prises en compte. Il existe plusieurs autres options telles que S3 (buckets) et Elastic File Store (EFS), mais elles sont plus spécifiques aux exigences d'une application individuelle qu'au fonctionnement de la plate-forme de données IRIS d'InterSystems.  

Comme la plupart des autres fournisseurs de cloud computing, AWS impose des limites à la quantité de stockage persistant qui peut être associée à un moteur de calcul individuel.  Ces limites incluent la taille maximale de chaque disque, le nombre de disques persistants attachés à chaque moteur de calcul, et le nombre d'IOPS par disque persistant avec un plafond global d'IOPS par instance de moteur de calcul.  En outre, des limites d'IOPS sont imposées par Go d'espace disque, de sorte qu'il est parfois nécessaire de provisionner davantage de capacité disque pour atteindre le taux d'IOPS requis.  

Ces limites peuvent se modifier au fil du temps et doivent être confirmées avec AWS, le cas échéant.

Il existe trois types de stockage persistant pour les volumes de disque : EBS gp2 (SSD), EBS st1 (HDD) et EBS io1 (SSD).  Les disques EBS gp2 standard sont plus adaptés aux charges de travail de production qui nécessitent des IOPS prévisibles à faible latence et un débit plus élevé. Les disques Persistent standard constituent une option plus économique pour les charges de travail de type développement, test ou archive hors production.  

Les détails sur les différents types de disques et leurs limitations sont disponibles ici.

Mise en réseau VPC

Le réseau de cloud privé virtuel (VPC) est fortement recommandé pour prendre en charge les divers composants de la plate-forme de données InterSystems IRIS, tout en fournissant les contrôles de sécurité réseau appropriés, les diverses passerelles, le routage, les attributions d'adresses IP internes, l'isolation des interfaces réseau et les contrôles d'accès.  Un exemple de VPC sera détaillé dans les exemples fournis dans ce document. 

Les détails de la mise en réseau VPC et des pare-feu sont disponibles ici.

Aperçu du Cloud privé virtuel (VPC)

Les détails d'AWS VPC sont disponibles ici.

Dans la plupart des grands déploiements en nuage, plusieurs VPC sont provisionnés afin d'isoler les différents types de passerelles des VPC applicatifs et de profiter du peering VPC pour les communications entrantes et sortantes. Il est fortement recommandé de consulter votre administrateur réseau pour obtenir des détails sur les sous-réseaux autorisés et les règles de pare-feu de votre entreprise. Le peering VPC n'est pas abordé dans ce document.

Dans les exemples fournis dans ce document, un seul VPC avec trois sous-réseaux sera utilisé pour fournir une isolation réseau des différents composants pour une latence et une bande passante prévisibles et une isolation de sécurité des différents composants d'InterSystems IRIS.  

Network Gateway and Subnet Definitions

Deux passerelles sont fournies dans l'exemple de ce document pour prendre en charge la connectivité Internet et la connectivité VPN sécurisée.  Chaque accès d'entrée doit être doté de règles de pare-feu et de routage appropriées afin de garantir une sécurité adéquate pour l'application.  Les détails sur la façon d'utiliser les Tableaux VPC Route sont disponibles ici.

Trois sous-réseaux sont utilisés dans les exemples d'architectures fournis, dédiés à l'utilisation de la plate-forme de données IRIS d'InterSystems.  L'utilisation de ces sous-réseaux et interfaces réseau distincts permet une flexibilité dans les contrôles de sécurité et la protection et la surveillance de la bande passante pour chacun des trois composants majeurs ci-dessus.  Les détails de la création d'instances de machines virtuelles avec plusieurs interfaces réseau sont disponibles ici.

Les sous-réseaux inclus dans ces exemples :

5. User Space Network pour les utilisateurs connectés et les requêtes
5. Shard Network pour les communications entre les noeuds shards
5. Réseau miroir pour une haute disponibilité utilisant la réplication synchrone et le basculement automatique des nœuds de données individuels.  

Équilibreurs de charge internes

La plupart des fournisseurs de cloud computing IaaS ne sont pas en mesure de fournir une adresse IP virtuelle (VIP) qui est généralement utilisée dans les conceptions de basculement automatique de base de données. Pour remédier à ce problème, plusieurs des méthodes de connectivité les plus couramment utilisées, en particulier les clients ECP et les passerelles Web, sont améliorées dans InterSystems IRIS afin de ne plus dépendre des capacités VIP, ce qui les rend sensibles aux miroirs et automatiques.  

Connectivity methods such as xDBC, direct TCP/IP sockets, or other direct connect protocols, require the use of a VIP-like address. To support those inbound protocols, InterSystems database mirroring technology makes it possible to provide automatic failover for those connectivity methods within AWS using a health check status page called  <span class="Characteritalic" style="font-style:italic">mirror_status.cxw </span> to interact with the load balancer to achieve VIP-like functionality of the load balancer only directing traffic to the active primary mirror member, thus providing a complete and robust high availability design within AWS.  

Les détails de l'équilibreur de charge Elastic Load Balancer (ELB) d'AWS sont disponibles ici.

Figure 4.2-a : Basculement automatique sans adresse IP virtuelle

Les détails de l'utilisation d'un équilibreur de charge pour fournir une fonctionnalité de type VIP sont disponibles ici.  

Sample VPC Topology

En combinant tous les composants, l'illustration suivante de la Figure 4.3-a présente la disposition d'un VPC avec les caractéristiques suivantes :

• Exploitation de plusieurs zones au sein d'une région pour une haute disponibilité
• Fourniture deux régions pour la reprise après sinistre
• Utilisation de plusieurs sous-réseaux pour la ségrégation du réseau
• Intégration de passerelles distinctes pour la connectivité VPC Peering, Internet et VPN
• Utilisation d'un équilibreur de charge en nuage pour le basculement IP des membres du miroir

Veuillez noter que dans AWS, chaque sous-réseau doit résider entièrement dans une zone de disponibilité et ne peut pas s'étendre sur plusieurs zones.  Ainsi, dans l'exemple ci-dessous, la sécurité du réseau ou les règles de routage doivent être correctement définies.  Plus de détails sur les sous-réseaux AWS VPC sont disponibles ici.

Figure 4.3-a : Exemple de topologie de réseau VPC

Aperçu du stockage persistant

Comme indiqué dans l'introduction, il est recommandé d'utiliser les volumes AWS Elastic Block Store (EBS), et plus particulièrement les types de volumes EBS gp2 ou les plus récents gp3.  Les volumes EBS gp3 sont recommandés en raison des taux d'IOPS en lecture et en écriture plus élevés et de la faible latence requise pour les charges de travail des bases de données transactionnelles et analytiques.  Les disques SSD locaux peuvent être utilisés dans certaines circonstances, mais il faut savoir que les gains de performance des disques SSD locaux s'accompagnent de certains compromis en termes de disponibilité, de durabilité et de flexibilité.  

Les détails de la persistance des données du SSD local sont disponibles ici pour comprendre les événements de quand les données du SSD local sont préservées et quand elles ne le sont pas.

LVM PE Striping

Comme d'autres fournisseurs cloud, AWS impose de nombreuses limites au stockage, tant en termes d'IOPS que de capacité d'espace et de nombre de dispositifs par instance de machine virtuelle.  Consultez la documentation d'AWS pour connaître les limites actuelles, qui peuvent être disponibles ici .

Avec ces limites, le striping LVM devient nécessaire pour maximiser l'IOPS au-delà de celui d'un seul périphérique disque pour une instance de base de données.  Dans les exemples d'instances de machine virtuelle fournis, les dispositions de disque suivantes sont recommandées.  Les limites de performance associées aux disques persistants SSD peuvent être disponibles ici . 

Figure 5.1-a : Exemple d'allocation de groupe de volumes LVM

Les avantages du striping LVM permettent de répartir les charges de travail IO aléatoires sur un plus grand nombre de périphériques de disque et d'hériter des files d'attente de disque.  Vous trouverez ci-dessous un exemple d'utilisation du striping LVM avec Linux pour le groupe de volumes de la base de données.  Cet exemple utilise quatre disques dans une bande PE LVM avec une taille d'étendue physique (PE) de 4 Mo.  Il est également possible d'utiliser des tailles PE plus importantes si nécessaire.

• Étape 1 : Créez des disques persistants standard ou SSD selon vos besoins
• Etape 2 : L'ordonnanceur IO est NOOP pour chacun des disques en utilisant "lsblk -do NAME,SCHED"
• Etape 3 : Identifier les périphériques de disque en utilisant "lsblk -do KNAME,TYPE,SIZE,MODEL"
• Étape 4 : Créer un groupe de volumes avec de nouveaux périphériques de disque
  • vgcreate s 4M <vg name>  <liste de tous les disques qui viennent d'être créés>
  Étape 4 : Créer un groupe de volumes avec de nouveaux périphériques de disque
  • example: <span style="color:#c0392b;"><i>vgcreate -s 4M vg_iris_db /dev/sd[h-k]</i></span>
• Étape 4 : Créer un volume logique
  • lvcreate n <lv name> -L <size of LV> -i <number of disks in volume group> -I 4MB <vg name>
  • example: <i>lvcreate -n lv_irisdb01 -L 1000G -i 4 -I 4M vg_iris_db</i>
• Étape 5 : Créer un système de fichiers
  • mkfs.xfs K <périphérique de volume logique>
  • example: <i>mkfs.xfs -K /dev/vg_iris_db/lv_irisdb01</i>
• Étape 6 : Monter le système de fichiers
  • éditer /etc/fstab avec les entrées de montage suivantes
    • /dev/mapper/vg_iris_db-lv_irisdb01    /vol-iris/db    xfs defaults 0 0
    • mount /vol-iris/db

En utilisant le tableau ci-dessus, chacun des serveurs InterSystems IRIS aura la configuration suivante avec deux disques pour SYS, quatre disques pour DB, deux disques pour les journaux primaires et deux disques pour les journaux alternatifs.

Figure 5.1-b : Configuration InterSystems IRIS LVM

Pour la croissance, LVM permet d'étendre les périphériques et les volumes logiques lorsque cela est nécessaire, sans interruption.  Consultez la documentation de Linux sur les meilleures pratiques pour la gestion continues et l'expansion des volumes LVM.

Provisionnement

La nouveauté avec InterSystems IRIS est InterSystems Cloud Manager (ICM).  ICM exécute de nombreuses tâches et offre de nombreuses options pour le provisionnement d'InterSystems IRIS Data Platform. ICM est fourni sous la forme d'une image Docker qui comprend tous les éléments nécessaires au provisionnement d'une solution robuste basée sur le cloud AWS. 

ICM supporte actuellement le provisionnement sur les plateformes suivantes :

• Amazon Web Services avec GovCloud (AWS / GovCloud)
• Google Cloud Plate-forme (GCP)
• Microsoft Azure Resource Manager, avec l'administration (ARM / MAG)
• VMware vSphere (ESXi)

ICM et Docker peuvent fonctionner à partir d'un poste de travail de bureau ou d'un ordinateur portable, ou encore à partir d'un modeste serveur de "provisionnement" et d'un référentiel centralisé.  

Le rôle d'ICM dans le cycle de vie des applications est le suivant : Définir -> Approvisionner -> Déployer -> Gérer

Les détails de l'installation et de l'utilisation de la GIC avec Docker sont disponibles ici.

Container Monitoring

ICM comprend deux dispositifs de surveillance de base pour les déploiements basés sur des conteneurs: Rancheret Weave Scope.  Ni l'un ni l'autre ne sont déployés par défaut, et doivent être spécifiés dans le fichier defaults à l'aide du champ Monitor.  Les détails de la surveillance, de l'orchestration et de la planification avec ICM sont disponibles ici.

Une présentation de Rancher et une documentation sont disponibles ici.

Une présentation de Weave Scope et une documentation sont disponibles ici.

Haute disponibilité

La mise en miroir des bases de données InterSystems offre le plus haut niveau de disponibilité dans tout environnement en nuage.  AWS n'offre aucune garantie de disponibilité pour une seule instance EC2, la mise en miroir de bases de données est donc un niveau de base de données requis qui peut également être couplé à l'équilibrage de charge et aux groupes d'auto-évaluation.  

Les sections précédentes ont abordé la manière dont un équilibreur de charge en nuage fournira un basculement automatique de l'adresse IP pour une capacité de type IP virtuelle (VIP) avec une mise en miroir de la base de données.  L'équilibreur de charge cloud utilise mirror_status.cxwla page d'état du bilan de santé mentionnée précédemment dans la section Internal Load Balancers. Il existe deux modes de mise en miroir des bases de données : synchrone avec basculement automatique et asynchrone.  Dans cet exemple, la mise en miroir synchrone avec basculement automatique sera couverte.  Les détails de la mise en miroir sont disponibles ici.

La configuration de mise en miroir la plus élémentaire est une paire de membres miroirs à basculement dans une configuration contrôlée par un arbitre.  L'arbitre est placé dans une troisième zone au sein de la même région afin d'éviter que des pannes potentielles de la zone de disponibilité n'affectent à la fois l'arbitre et l'un des membres miroirs.

Il existe de nombreuses façons de configurer le mirroring spécifiquement dans la configuration du réseau.  Dans cet exemple, nous allons utiliser les sous-réseaux définis précédemment dans Network Gateway et Subnet Definitions sections de ce document.  Des exemples de schémas d'adresses IP seront fournis dans une section suivante. Pour les besoins de cette section, seules les interfaces réseau et les sous-réseaux désignés seront représentés.

Figure 7-a : Exemple de configuration miroir avec arbitre

Reprise après sinistre

La mise en miroir des bases de données InterSystems étend la capacité de haute disponibilité pour prendre également en charge la reprise après sinistre vers une autre région géographique AWS afin de soutenir la résilience opérationnelle dans le cas peu probable où une région AWS entière serait mise hors ligne.  La manière dont une application doit supporter de telles pannes dépend de l'objectif de temps de récupération (RTO) et des objectifs de point de récupération (RPO).  Ceux-ci fourniront le cadre initial de l'analyse nécessaire à la conception d'un plan de reprise après sinistre approprié.  Le lien suivant fournit un guide des éléments à prendre en compte lors de l'élaboration d'un plan de reprise après sinistre pour votre application.  https://aws.amazon.com/disaster-recovery/

Mise en miroir asynchrone des bases de données

La mise en miroir des bases de données InterSystems IRIS Data Platform offre des fonctionnalités robustes pour la réplication asynchrone des données entre les zones de disponibilité et les régions AWS afin de soutenir les objectifs RTO et RPO de votre plan de reprise après sinistre.  Les détails des membres de la mise en miroir asynchrone sont disponibles ici.

Comme dans la section précédente sur la haute disponibilité, un équilibreur de charge cloud fournira un basculement automatique d'adresse IP pour une capacité d'IP virtuelle (de type VIP) pour la mise en miroir asynchrone DR également en utilisant la même mirror_status.cxwpage d'état de contrôle de santé mentionnée précédemment dans la section d'Équilibreurs de charge internes. 

Dans cet exemple, la mise en miroir de basculement asynchrone DR sera couverte ainsi que l'introduction du service AWS Route53 DNS pour fournir aux systèmes ascendants et aux postes de travail clients une adresse DNS unique, quelle que soit la zone de disponibilité ou la région dans laquelle votre déploiement InterSystems IRIS fonctionne. 

Les détails de AWS Route53 sont disponibles ici.

Figure 8.1-a: Sample DR Asynchronous Mirroring with AWS Route53

Dans l'exemple ci-dessus, les adresses IP de l'équilibreur de charge Elastic Load Balancer (ELB) des deux régions qui sont en tête des instances InterSystems IRIS sont fournies à Route53, et ce dernier ne dirigera le trafic que vers le membre miroir qui est le miroir primaire actif, quelle que soit la zone de disponibilité ou la région où il se trouve.

Cluster Sharded

IInterSystems IRIS comprend un ensemble complet de fonctionnalités permettant de faire évoluer vos applications, qui peuvent être appliquées seules ou en combinaison, selon la nature de votre charge de travail et les défis de performance spécifiques auxquels elle fait face. L'une d'entre elles, le sharding, répartit les données et leur cache associé sur plusieurs serveurs, ce qui permet de faire évoluer les performances des requêtes et de l'ingestion de données de manière flexible et peu coûteuse, tout en maximisant la valeur de l'infrastructure grâce à une utilisation très efficace des ressources. Un cluster sharded InterSystems IRIS peut offrir des avantages significatifs en termes de performances pour une grande variété d'applications, mais surtout pour celles dont la charge de travail comprend un ou plusieurs des éléments suivants :

• L'ingestion de données à haut volume ou à grande vitesse, ou une combinaison de ces éléments.
• Des ensembles de données relativement importants, des requêtes qui renvoient de grandes quantités de données, ou les deux.
• Les requêtes complexes qui effectuent de grandes quantités de traitement de données, comme celles qui analysent beaucoup de données sur disque ou qui impliquent un travail de calcul important.

Chacun de ces facteurs influence à lui seul le gain potentiel du sharding, mais l'avantage peut être renforcé lorsqu'ils se combinent. Par exemple, la combinaison de ces trois facteurs (grandes quantités de données ingérées rapidement, grands ensembles de données et requêtes complexes qui récupèrent et traitent beaucoup de données) fait de la plupart des charges de travail analytiques actuelles de très bons candidats pour le sharding.

Notez que ces caractéristiques sont toutes liées aux données ; la fonction principale d'InterSystems IRIS sharding est de s'adapter au volume de données. Cependant, un cluster sharded peut également inclure des fonctionnalités qui évoluent en fonction du volume d'utilisateurs, lorsque les charges de travail impliquant certains ou tous ces facteurs liés aux données connaissent également un volume de requêtes très élevé de la part d'un grand nombre d'utilisateurs. Le sharding peut également être combiné à une mise à l'échelle verticale.

Aperçu opérationnel

Au cœur de l'architecture sharded se trouve le partitionnement des données et de leur cache associé sur plusieurs systèmes. Un cluster sharded partitionne physiquement les grandes tableaux de base de données horizontalement - c'est-à-dire par ligne - sur plusieurs instances InterSystems IRIS, appelées nœuds de données, tout en permettant aux applications d'accéder de manière transparente à ces tableaux par le biais de n'importe quel nœud et de continuer à voir l'ensemble des données comme une seule union logique. Cette architecture offre trois avantages :

• Parallel processing

Les requêtes sont exécutées en parallèle sur les nœuds de données, les résultats étant fusionnés, combinés et renvoyés à l'application en tant que résultats complets de la requête par le nœud auquel l'application s'est connectée, ce qui améliore considérablement la vitesse d'exécution dans de nombreux cas.

• Mise en cache partitionnée

Chaque nœud de données dispose de son propre cache, dédié à la partition de données de la table sharded qu'il stocke, plutôt que le cache d'une instance unique desservant l'ensemble des données, ce qui réduit considérablement le risque de déborder du cache et de forcer des lectures sur disque dégradant les performances.

• Chargement parallèle

Les données peuvent être chargées sur les nœuds de données en parallèle, ce qui réduit les conflits de cache et de disque entre la charge de travail d'ingestion et la charge de travail d'interrogation et améliore les performances des deux.

Les détails du cluster sharded InterSystems IRIS sont disponibles ici.

Éléments du sharding et types d'instance

Un cluster sharded se compose d'au moins un nœud de données et, si nécessaire pour des performances spécifiques ou des exigences de charge de travail, d'un nombre optionnel de nœuds de calcul. Ces deux types de nœuds offrent des blocs de construction simples présentant un modèle de mise à l'échelle simple, transparent et efficace.

Data Nodes

Les nœuds de données stockent les données. Au niveau physique, les données du tableau sharded[1]sont réparties sur tous les nœuds de données du cluster et les données du tableau non sharded sont physiquement stockées sur le premier nœud de données uniquement. Cette distinction est transparente pour l'utilisateur, à l'exception peut-être du fait que le premier nœud pourrait avoir une consommation de stockage légèrement plus élevée que les autres, mais cette différence devrait devenir négligeable, car les données du tableau sharded dépassent généralement les données du tableau non sharded d'au moins un ordre de grandeur. 

Les données des tableaux sharded peuvent être rééquilibrées dans le cluster si nécessaire, généralement après l'ajout de nouveaux nœuds de données. Cette opération permet de déplacer des "seaux" de données entre les nœuds afin d'obtenir une distribution plus ou moins égale des données.

Au niveau logique, les données des tableaux non shardés et l'union de toutes les données des tableaux shardés sont visibles depuis n'importe quel nœud, de sorte que les clients verront l'ensemble des données, quel que soit le nœud auquel ils se connectent. Les métadonnées et le code sont également partagés entre tous les nœuds de données.

Le diagramme d'architecture de base d'un cluster sharded se compose simplement de nœuds de données qui apparaissent uniformément dans le cluster. Les applications clientes peuvent se connecter à n'importe quel nœud et percevront les données comme si elles étaient locales.

Figure 9.2.1-a : Diagramme de base d'un cluster sharded

---

[1]Par commodité, le terme “données de tableau sharded” est utilisé dans l'ensemble du document pour représenter les donnée “d'étendue” pour tout modèle de données prenant en charge le sharding qui est marqué comme sharded. Les termes “données de tableau non sharded” et “données non sharded” sont utilisés pour représenter les données qui se trouvent dans une étendue shardable non marquée comme telle ou pour un modèle de données qui ne prend simplement pas encore en charge le sharding.

Nœuds de calcul

Pour les scénarios avancés nécessitant de faibles latences, potentiellement en contradiction avec un afflux constant de données, des nœuds de calcul peuvent être ajoutés afin de fournir une couche de mise en cache transparente pour le traitement des requêtes. 

Les nœuds de calcul stockent les données en cache. Chaque nœud de calcul est associé à un nœud de données pour lequel il met en cache les données du tableau sharded correspondant et, en plus de cela, il met également en cache les données du tableau non sharded si nécessaire, pour satisfaire les requêtes. 

Figure 9.2.2-a : Cluster shared avec nœuds de calcul

Comme les nœuds de calcul ne stockent physiquement aucune donnée et qu'ils sont destinés à prendre en charge l'exécution de requêtes, leur profil matériel peut être adapté à ces besoins, par exemple en privilégiant la mémoire et le processeur et en limitant le stockage au strict minimum. L'ingestion est transmise aux nœuds de données, soit directement par le pilote (xDBC, Spark), soit implicitement par le code du gestionnaire de sharding lorsque le code d'application "nu" s'exécute sur un nœud de calcul.

Illustrations de cluster sharded

Le déploiement d'un cluster sharded peut se faire de différentes manières. Les diagrammes de haut niveau suivants sont fournis pour illustrer les modèles de déploiement les plus courants.  Ces diagrammes n'incluent pas les passerelles et les détails du réseau et se concentrent uniquement sur les composants du cluster sharded.

Cluster sharded de base

Le schéma suivant représente le cluster sharded le plus simple avec quatre nœuds de données déployés dans une seule région et dans une seule zone.  Un équilibreur de charge AWS Elastic Load Balancer (ELB) est utilisé pour distribuer les connexions des clients à l'un des nœuds du cluster sharded 

Figure 9.3.1-a: Basic Sharded Cluster 

Dans ce modèle de base, il n'y a pas de résilience ou de haute disponibilité au-delà de ce que AWS fournit pour une seule machine virtuelle et son stockage SSD persistant attaché.  Deux adaptateurs d'interface réseau distincts sont recommandés pour assurer à la fois l'isolation de la sécurité du réseau pour les connexions client entrantes et l'isolation de la bande passante entre le trafic client et les communications du cluster sharded.

Cluster Sharded de base avec haute disponibilité

Le diagramme suivant représente le cluster sharded le plus simple avec quatre nœuds de données miroir déployés dans une seule région et divisant le miroir de chaque nœud entre les zones.  Un équilibreur de charge AWS est utilisé pour distribuer les connexions des clients à l'un des nœuds du cluster sharded.  

La haute disponibilité est assurée par l'utilisation de la mise en miroir des bases de données InterSystems, qui maintient un miroir répliqué de manière synchrone dans une zone secondaire de la région.

Trois adaptateurs d'interface réseau distincts sont recommandés pour assurer à la fois l'isolation de la sécurité du réseau pour les connexions client entrantes et l'isolation de la bande passante entre le trafic client, les communications du cluster sharded et le trafic du miroir synchrone entre les paires de nœuds.

Figure 9.3.2-a : Cluster sharded de base avec haute disponibilité 

Ce modèle de déploiement introduit également un arbitre miroir tel que celui décrit dans une section précédente de cet article.

Cluster sharded avec des nœuds de calcul séparés

Le diagramme suivant développe le cluster sharded pour une concurrence massive entre les utilisateurs et les requêtes avec des nœuds de calcul séparés et quatre nœuds de données. Le pool de serveurs Cloud Load Balancer contient uniquement les adresses des nœuds de calcul.  Les mises à jour et l'ingestion de données continueront d'être effectuées directement sur les nœuds de données, comme auparavant, afin de maintenir des performances à très faible latence et d'éviter les interférences et l'encombrement des ressources entre les charges de travail de requête/analyse provenant de l'ingestion de données en temps réel. 

Grâce à ce modèle, l'allocation des ressources peut être affinée pour la mise à l'échelle des calculs/requêtes et de l'ingestion de manière indépendante, ce qui permet d'optimiser les ressources là où elles sont nécessaires, en "juste à temps", et de conserver une solution économique mais simple, au lieu de gaspiller inutilement des ressources pour la mise à l'échelle des calculs ou des données.  

Les nœuds de calcul se prêtent à une utilisation très simple du regroupement automatique AWS (alias Autoscaling) pour permettre l'ajout ou la suppression automatique d'instances d'un groupe d'instances géré en fonction de l'augmentation ou de la diminution de la charge. L'autoscaling fonctionne en ajoutant des instances à votre groupe d'instances lorsqu'il y a plus de charge (upscaling), et en supprimant des instances lorsque le besoin d'instances diminue (downscaling).

Les détails de la mise à l'échelle automatique d'AWS ssont disponibles ici.

Figure 9.3.3-a : Cluster Sharded avec des nœuds de calcul et de données séparés

L'auto-scaling aide les applications basées sur le cloud à gérer de manière élégante les augmentations de trafic et réduit les coûts lorsque le besoin en ressources est moindre. Il suffit de définir la politique et l'auto-mesureur effectue une mise à l'échelle automatique en fonction de la charge mesurée.

Opérations de sauvegarde

Il existe de multiples options pour les opérations de sauvegarde.  Les trois options suivantes sont viables pour votre déploiement AWS avec InterSystems IRIS. 

TLes deux premières options, détaillées ci-dessous, intègrent une procédure de type instantané qui implique la suspension des écritures de la base de données sur le disque avant la création de l'instantané, puis la reprise des mises à jour une fois l'instantané réussi.

Les étapes de haut niveau suivantes sont suivies pour créer une sauvegarde propre en utilisant l'une ou l'autre des méthodes instantanées :

• Pause des écritures dans la base de données via un appel de la base de données External Freeze API.
• Créez des instantanés de l'OS + des disques de données.
• Reprendre les écritures de la base de données via l'appel External Thaw API..
• Sauvegarde des archives de l'installation vers un emplacement de sauvegarde

Les détails de External Freeze/Thaw API sont disponibles ici.

La troisième option est la sauvegarde en ligne InterSystems.  Il s'agit d'une approche d'entrée de gamme pour les petits déploiements avec un cas d'utilisation et une interface très simples.  Cependant, à mesure que la taille des bases de données augmente, les sauvegardes externes avec la technologie des instantanés sont recommandées comme meilleure pratique, avec des avantages tels que la sauvegarde des fichiers externes, des temps de restauration plus rapides et une vue des données et des outils de gestion à l'échelle de l'entreprise.  

Des étapes supplémentaires, telles que les contrôles d'intégrité, peuvent être ajoutées périodiquement pour garantir une sauvegarde propre et cohérente.

Le choix de l'option à utiliser dépend des exigences et des politiques opérationnelles de votre organisation. InterSystems est à votre disposition pour discuter plus en détail des différentes options.

Sauvegarde des instantanés de l'AWS Elastic Block Store (EBS)

Les opérations de sauvegarde peuvent être réalisées à l'aide de l'API de ligne de commande AWS CLI et des capacités API ExternalFreeze/Thaw d'InterSystems. Cela permet une véritable résilience opérationnelle 24 heures sur 24, 7 jours sur 7, et l'assurance de sauvegardes régulières et propres.  Les détails de la gestion, de la création et de l'automatisation des snapshots AWS EBS sont disponibles à l'adresse suivante ici.

Instantanés du Logical Volume Manager (LVM)

Il est également possible d'utiliser un grand nombre d'outils de sauvegarde tiers disponibles sur le marché en déployant des agents de sauvegarde individuels dans la VM elle-même et en exploitant les sauvegardes au niveau des fichiers conjointement avec les instantanés du Logical Volume Manager (LVM).

L'un des principaux avantages de ce modèle est la possibilité d'effectuer des restaurations au niveau des fichiers des machines virtuelles basées sur Windows ou Linux.  Il convient de noter que, comme AWS et la plupart des autres fournisseurs de cloud IaaS ne fournissent pas de bandes magnétiques, tous les référentiels de sauvegarde sont sur disque pour l'archivage à court terme et peuvent exploiter un stockage à faible coût de type blob ou bucket pour la rétention à long terme (LTR).  Si vous utilisez cette méthode, il est fortement recommandé d'utiliser un produit de sauvegarde qui prend en charge les technologies de déduplication afin d'utiliser le plus efficacement possible les référentiels de sauvegarde sur disque.

Quelques exemples de ces produits de sauvegarde ayant une prise en charge dans le cloud incluent, sans y être limités, sont les suivants :  Commvault, EMC Networker, HPE Data Protector et Veritas Netbackup.  InterSystems ne valide ni n'approuve un produit plutôt qu'un autre. 

Sauvegarde en ligne

Pour les petits déploiements, la fonction intégrée de sauvegarde en ligne Online Backup est également une option viable.  Cet utilitaire de sauvegarde en ligne des bases de données InterSystems sauvegarde les données dans les fichiers de base de données en capturant tous les blocs dans les bases de données, puis écrit la sortie dans un fichier séquentiel. Ce mécanisme de sauvegarde propriétaire est conçu pour ne pas causer de temps d'arrêt aux utilisateurs du système de production. Les détails de la sauvegarde en ligne sont disponibles ici.

Dans AWS, une fois la sauvegarde en ligne terminée, le fichier de sortie de la sauvegarde et tous les autres fichiers utilisés par le système doivent être copiés vers un autre emplacement de stockage en dehors de cette instance de machine virtuelle.  Le stockage de type "Bucket/Object" est une bonne désignation pour cela. 

Il existe deux options pour utiliser un bucket AWS Single Storage Space (S3).  

• Utilisez les AWS CLIscripting APIs directement pour copier et manipuler les fichiers de sauvegarde en ligne (et autres fichiers non liés à la base de données) nouvellement créés
  • Les détails sont disponibles ici.
• Montez un volume Elastic File Store (EFS) et utilisez-le de la même manière qu'un disque persistant à faible coût.
  • Les détails de l'EFS sont disponibles ici.

InterSystems annonce la fin de la maintenance de Zen Reports à partir d'Intersystems IRIS et IRIS for Health 2025.1. Cela fait suite à l'avis de dépréciation émis lors de l'introduction d'InterSystems IRIS en 2018 et à l'inclusion ultérieure d'InterSystems Reports en 2020 pour fournir une fonctionnalité de rapport de remplacement. Un aperçu de la chronologie est:

Mars 2018.   InterSystems IRIS 2018.1 :  Annonce de l'abandon de Zen Reports, livraison continue pour assurer la continuité des applications existantes

Les systèmes de bases de données ont des exigences de sauvegarde très spécifiques qui, dans les déploiements d'entreprise, nécessitent une réflexion et une planification préalables. Pour les systèmes de bases de données, l'objectif opérationnel d'une solution de sauvegarde est de créer une copie des données dans un état équivalent à celui de l'arrêt de l'application en douceur.  Les sauvegardes cohérentes avec les applications répondent à ces exigences et Caché fournit un ensemble d'API qui facilitent l'intégration avec des solutions externes pour atteindre ce niveau de cohérence des sauvegardes.

Ces API sont ExternalFreeze et ExternalThaw. ExternalFreeze met temporairement en pause les écritures sur le disque et pendant cette période, Caché commet les changements en mémoire. Pendant cette période, l'opération de sauvegarde doit se terminer et être suivie d'un appel à ExternalThaw. Cet appel engage les démons d'écriture à écrire sur le disque la mise à jour du pool tampon global (cache de la base de données) et reprend les opérations normales des démons d'écriture de la base de données Caché. Ce processus est transparent pour les processus utilisateur de Caché.  Les méthodes spécifiques de la classe API sont les suivantes :

##Class(Backup.General).ExternalFreeze()

##Class(Backup.General).ExternalThaw()

Ces API, associées à la nouvelle capacité d'Azure Backup à exécuter un script avant et après l'exécution d'une opération d'instantané, fournissent une solution de sauvegarde complète pour les déploiements de Caché sur Azure. La [capacité de script pré/post d'Azure Backup] (https://azure.microsoft.com/en-us/blog/announcing-application-consistent-backup-for-linux-vms-using-azure-backup) est actuellement disponible uniquement sur les VM Linux.

Conditions préalables

Au niveau le plus élevé, vous devez effectuer trois étapes avant de pouvoir sauvegarder une VM à l'aide d'Azure Backup:

1. Create a Recovery Services vault
2. Install has the latest version of the VM Agent.
3. Check network access to the Azure services from your VM. 

L'espace de stockage Recovery Services gère les objectifs de sauvegarde, les politiques et les éléments à protéger. Vous pouvez créer une voûte de Recovery Services via le portail Azure ou via un script utilisant PowerShell.  Azure Backup nécessite une extension qui s'exécute dans votre VM, est contrôlée par l'agent Linux VM et la dernière version de l'agent est également nécessaire.  L'extension interagit avec les points d'extrémité HTTPS externes d'Azure Storage et de la voûte Recovery Services.  L'accès sécurisé à ces services depuis la VM peut être configuré à l'aide d'un proxy et de règles réseau dans un groupe de sécurité Azure Network Security Group. 

Vous trouverez plus d'informations sur ces étapes dans la section Préparez votre environnement pour sauvegarder les machines virtuelles déployées par Resource Manager.

La Configuration du pré-scripting et post-scripting

La possibilité d'appeler un script avant et après l'opération de sauvegarde est incluse dans la dernière version de l'extension Azure Backup (Microsoft.Azure.RecoveryServices.VMSnapshotLinux). Pour plus d'informations sur l'installation de l'extension, veuillez consulter [la documentation détaillée des fonctionnalités] (https://docs.microsoft.com/en-us/azure/backup/backup-azure-linux-app-consistent).

Par défaut, l'extension inclut des exemples de pré-scripts et post-scripts situés dans votre VM Linux à l'adresse suivante :

/var/lib/waagent/Microsoft.Azure.RecoveryServices.VMSnapshotLinux-1.0.9110.0/main/tempPlugin

Et doit être copié aux emplacements suivants respectivement.

/etc/azure/prescript.sh
/etc/azure/postScript.sh

Vous pouvez également télécharger le modèle de script à partir de GitHub.

Pour Caché, le script prescript.sh où un appel à l'API ExternalFreeze peut être implémenté et le postScript.sh doivent contenir l'implémentation qui exécute ExternalThaw.

Voici un exemple d'implémentation de prescript.sh pour Caché.

#!/bin/bash
# les variables utilisées pour retourner l'état du script
success=0
error=1
warning=2
status=$success
log_path="/etc/preScript.log"#path of log file
printf  "Logs:\n" > $log_path# TODO: Replace <CACHE INSTANCE> with the name of the running instance
csession <CACHE INSTANCE> -U%SYS "##Class(Backup.General).ExternalFreeze()" >> $log_path
status=$?if [ $status -eq 5 ]; then
echo "SYSTEM IS FROZEN"
printf  "SYSTEM IS FROZEN\n" >> $log_pathelif [ $status -eq 3 ]; then
echo "SYSTEM FREEZE FAILED"
printf  "SYSTEM FREEZE FAILED\n" >> $log_path
status=$error
csession <CACHE INSTANCE> -U%SYS "##Class(Backup.General).ExternalThaw()"
fi

exit $status

Voici un exemple d'implémentation de postScript.sh pour Caché.

#!/bin/bash
# les variables utilisées pour retourner l'état du script
success=0
error=1
warning=2
status=$success
log_path="/etc/postScript.log"#path of log file
printf  "Logs:\n" > $log_path# TODO: Replace <CACHE INSTANCE> with the name of the running instance
csession <CACHE INSTANCE> -U%SYS "##class(Backup.General).ExternalThaw()"
status=$?
if [ $status req 5]; then
echo "SYSTEM IS UNFROZEN"
printf  "SYSTEM IS UNFROZEN\n" >> $log_pathelif [ $status -eq 3 ]; then
echo "SYSTEM UNFREEZE FAILED"
printf  "SYSTEM UNFREEZE FAILED\n" >> $log_path
status=$error
fi
exit $status

Exécution d'une sauvegarde

Dans le portail Azure, vous pouvez déclencher la première sauvegarde en naviguant vers le service de restauration. Veuillez considérer que le temps d'instantané de la VM devrait être de quelques secondes indépendamment de la première sauvegarde ou des sauvegardes suivantes. Le transfert de données de la première sauvegarde prendra plus de temps mais le transfert de données commencera après l'exécution du post-script pour dégeler la base de données et ne devrait pas avoir d'impact sur le temps entre le pré-script et le post-script.

Il est fortement recommandé de restaurer régulièrement votre sauvegarde dans un environnement de non-production et [d'effectuer des contrôles d'intégrité de la base de données] (http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_integrity#GCDI_integrity_verify_utility) pour garantir l'efficacité de vos opérations de protection des données.

Pour plus d'informations sur le déclenchement de la sauvegarde et d'autres sujets tels que la planification de la sauvegarde, veuillez consulter Sauvegarde des machines virtuelles Azure dans une voûte Recovery Services.  

###         

Bonjour à la communauté,
Dans cet article, je vais démontrer l'utilisation d'Embedded Python, nous allons couvrir les sujets suivants :

• 1-Aperçu d'Embedded Python
• 2-Utilisation d'Embedded Python
  • 2.1- Utilisation d'une bibliothèque Python à partir d'ObjectScript
  • 2.2- Appel des API d'InterSystems à partir de Python
  • 2.3- Utilisation conjointe d'ObjectScript et de Python
• 3-Utilisation des fonctions intégrées de python
• 4-Modules et bibliothèques Python 
• 5-Les cas d'utilisation d'Embedded Python
  • 5.1- Impression d'un PDF en utilisant la bibliothèque Python Reportlab
  • 5.2- Création d'un code QR à l'aide de la bibliothèque Python Qrcode
  • 5.3- Obtention de la localisation GEO à l'aide de la bibliothèque Python Folium
  • 5.4- Générer et marquer des emplacements sur une carte interactive en utilisant biblithèque** **Python Folium
  • 5.5- Analyse de données à l'aide de la biblithèque Python Pandas

  ---

• 6-Résumé

Commençons donc par un aperçu

1-Aperçu d'Embedded Python

Python intégré est une fonctionnalité de la plateforme de données InterSystems IRIS qui permet aux développeurs Python d'obtenir un accès complet et direct aux données et aux fonctionnalités d'InterSystems IRIS.

InterSystems IRIS est livré avec un puissant langage de programmation intégré appelé ObjectScript qui est interprété, compilé et exécuté à l'intérieur de la plate-forme de données.

Comme ObjectScript s'exécute dans le contexte d'InterSystems IRIS, il a un accès direct à la mémoire et aux appels de procédure de la plate-forme de données.

Python intégré est une extension du langage de programmation Python qui permet l'exécution du code Python dans le contexte du processus InterSystems IRIS.

Comme ObjectScript et Python opèrent tous deux sur la même mémoire objet, on peut dire que les objets Python ne se contentent pas d'émuler des objets ObjectScript, mais qu'ils sont des objets ObjectScript.

La coégalité de ces langages signifie qu'il est possible de choisir le langage le plus approprié pour le travail, ou le langage que l'on est le plus à l'aise à utiliser pour écrire des applications.

2-Utilisation d'Embedded Python

Lorsque vous utilisez Python intégré, vous pouvez écrire votre code selon trois modalités différentes.

2.1 - Utilisation d'une bibliothèque Python à partir d'ObjectScript

Tout d'abord, vous pouvez écrire un fichier .py ordinaire et l'appeler à partir du contexte IRIS d'InterSystems. Dans ce cas, la plateforme de données lancera le processus Python et vous permettra d'importer un module appelé IRIS, qui attache automatiquement le processus Python au noyau IRIS et vous donne accès à toutes les fonctionnalités d'ObjectScript à partir du contexte de votre code Python.

2.2 - Appel des API d'InterSystems à partir de Python

Deuxièmement, vous pouvez écrire du code ObjectScript ordinaire et instancier un objet Python à l'aide du paquet %SYS.Python. Ce paquet ObjectScript vous permet d'importer des modules et des bibliothèques Python, puis de travailler avec cette base de code à l'aide de la syntaxe ObjectScript.
Le paquet %SYS.Python permet aux développeurs ObjectScript sans aucune connaissance de Python d'utiliser le riche écosystème des bibliothèques Python dans leur code ObjectScript.

2.3 - Utilisation conjointe d'ObjectScript et de Python

Troisièmement, vous pouvez créer une définition de classe InterSystems et écrire des méthodes en Python. Tout appel à cette méthode lancera l'interpréteur Python. Cette méthode a l'avantage de remplir le mot-clé self de ce bloc de code Python d'une référence à l'instance de la classe qui le contient. En outre, en utilisant Python pour écrire des méthodes de classe dans les classes InterSystems, vous pouvez facilement mettre en œuvre des méthodes qui gèrent différents événements de saisie de données en SQL, tels que l'ajout d'une nouvelle ligne à un tableau.
Cela permet également de développer rapidement des procédures stockées personnalisées en Python.

Comme vous pouvez le constater, Python intégré vous permet de choisir le langage de programmation le mieux adapté à la tâche sans compromettre les performances.

3-Utilisation des fonctions intégrées de python

L'interpréteur Python a un certain nombre de fonctions et de types intégrés qui sont toujours disponibles. Ils sont répertoriés ici par ordre alphabétique.

<td>
  E enumerate() eval() exec()   F filter() float() format() frozenset()   G getattr() globals()   H hasattr() hash() help() hex()   I id() input() int() isinstance() issubclass() iter()
</td>

<td>
  L len() list() locals()   M map() max() memoryview() min()   N next()   O object() oct() open() ord()   P pow() print() property()        
</td>

<td>
  R range() repr() reversed() round()   S set() setattr() slice() sorted() staticmethod() str() sum() super()   T tuple() type()   V vars()   Z zip()   _ __import__()
</td>

****Utilisation des fonctions intégrées de python

Pour utiliser les fonctions intégrées de Python, nous avons besoin d'importer "builtins", puis nous pouvons invoquer la fonction

set builtins = ##class(%SYS.Python).Import("builtins")

La fonction print() de Python est en fait une méthode du module intégré, de sorte que vous pouvez maintenant utiliser cette fonction à partir d'ObjectScript :

USER>do builtins.print("hello world!")
hello world!

USER>set list = builtins.list()

USER>zwrite list
list=5@%SYS.Python  ; []  ; 

De même, la méthode help() permet d'obtenir de l'aide sur l'objet liste.

USER>do builtins.help(list)
L'aide sur l'objet liste:
classe list(object)
 |  list(iterable=(), /)
 |
 |  Séquence mutable intégrée.
 |
 |  Si aucun argument n'est donné, le constructeur crée une nouvelle liste vide.
 |  L'argument doit être un itérable s'il est spécifié.
 |
 |  Les méthodes définies ici :
 |
 |  __add__(self, value, /)
 |      Renvoi de la valeur+self.
 |
 |  __contains__(self, key, /)
 |      Renvoi de la clé dans self.
 |
 |  __delitem__(self, key, /)
 |      Suppression de la [clé] self.

## 

4-Modules et bibliothèques Python

Certains modules ou bibliothèques python sont installés par défaut et déjà disponibles. La fonction help("module") permet de visualiser ces modules :

 

Installation d'un module ou d'une bibliothèque python

Outre ces modules, python a des centaines de modules ou de bibliothèques, qui peuvent être consultés sur pypi.org( L' Indice de Paquet Python (PyPI) est un dépôt de logiciels pour le langage de programmation Python).

Si nous avons besoin d'autres bibliothèques, nous devons les installer à l'aide de la commande intersystems irispip.

Par exemple, Pandas est une bibliothèque d'analyse de données en python. La commande suivante utilise le programme d'installation de paquets irispip pour installer pandas sur un système Windows :

C:\InterSystems\IRIS\bin>irispip install --target C:\InterSystems\IRIS\mgr\python pandas

Veuillez noter que C:\NInterSystems sera remplacé par le répertoire d'installation d'Intersystems.
 

5-Les cas d'utilisation d'Embedded Python

5.1-Impression d' un PDF en utilisant la bibliothèque Python Reportlab

Nous devons installer la bibliothèque Reportlab à l'aide de la commande irispip, puis créer une fonction objectcript.

Compte tenu de l'emplacement d'un fichier, la méthode ObjectScript suivante, intitulée CreateSamplePDF(), crée un exemple de fichier PDF et l'enregistre à cet emplacement.

Class Demo.PDF
{

ClassMethod CreateSamplePDF(fileloc As%String) As%Status
{
    set canvaslib = ##class(%SYS.Python).Import("reportlab.pdfgen.canvas")
    set canvas = canvaslib.Canvas(fileloc)
    do canvas.drawImage("C:\Sample\isc.png", 150, 600)
    do canvas.drawImage("C:\Sample\python.png", 150, 200)
    do canvas.setFont("Helvetica-Bold", 24)
    do canvas.drawString(25, 450, "InterSystems IRIS & Python. Perfect Together.")
    do canvas.save()
}

}

La première ligne de la méthode importe le fichier canvas.py du sous-paquet pdfgen de ReportLab. La deuxième ligne de code instancie un objet Canvas et procède ensuite à l'appel de ses méthodes, de la même manière qu'elle appellerait les méthodes de n'importe quel objet IRIS d'InterSystems.

Vous pouvez ensuite appeler la méthode de la manière habituelle : 

do ##class(Demo.PDF).CreateSamplePDF("C:\Sample\hello.pdf")

Le PDF suivant est généré et enregistré à l'emplacement spécifié :

5.2-Création d'un code QR à l'aide de la bibliothèque Python Qrcode Library

Pour générer un code QR, nous devons installer la bibliothèque Qrcode en utilisant la commande irispip, puis en utilisant le code ci-dessous, nous pouvons générer un code QR:

5.3-Obtention de la localisation GEO à l'aide de la bibliothèque Python Folium

Pour obtenir des données géographiques, nous devons installer la bibliothèque Folium à l'aide de la commande irispip, puis créer la fonction de script objet ci-dessous :

Class dc.IrisGeoMap.Folium Extends%SwizzleObject
{

// Fonction d'impression de la latitude, de la longitude et des détails de l'adresse ClassMethod GetGeoDetails(addr As%String) [ Language = python ]
{
    from geopy.geocoders import Nominatim
    geolocator = Nominatim(user_agent="IrisGeoApp")
    try:
    	location = geolocator.geocode(addr)
    	print("Location:",location.point)
    	print("Address:",location.address)
    	point = location.point
    	print("Latitude:", point.latitude)
    	print("Longitude:", point.longitude)
    except:
    	print("Not able to find location")
}
}

Connectez-vous au terminal IRIS et exécutez le code suivant

do ##class(dc.IrisGeoMap.Folium).GetGeoDetails("Cambridge MA 02142")

Le résultat sera le suivant ::

  ********

5.4-Générer et marquer des emplacements sur une carte interactive en utilisant biblithèque Python Folium

Nous utiliserons la même bibliothèque Python Folium pour générer et marquer des emplacements sur une carte interactive, la fonction de script objet ci-dessous fera le travail souhaité :

ClassMethod MarkGeoDetails(addr As%String, filepath As%String) As%Status [ Language = python ]
{
    import folium
    from geopy.geocoders import Nominatim

    geolocator = Nominatim(user_agent="IrisGeoMap")
    #split address in order to mark on the map
    locs = addr.split(",")
    if len(locs) == 0:
    	print("Veuillez saisir l'adresse")
    elif len(locs) == 1:
    	location = geolocator.geocode(locs[0])
    	point = location.point
    	m = folium.Map(location=[point.latitude,point.longitude], tiles="OpenStreetMap", zoom_start=10)
    else:
    	m = folium.Map(location=[20,0], tiles="OpenStreetMap", zoom_start=3)

    for loc in locs:
    	try:
    		location = geolocator.geocode(loc)
    		point = location.point
    		folium.Marker(
	    			location=[point.latitude,point.longitude],
	    	  		popup=addr,
	    		).add_to(m)    		
    	except:
    		print("Impossible de trouver l'emplacement : ",loc)

    map_html = m._repr_html_()
    iframe = m.get_root()._repr_html_()
    fullHtml = """

        	    

        	         """
    fullHtml = fullHtml + iframe            
    fullHtml = fullHtml + """                                             
       	        
        	    
    """try:
    	f = open(filepath, "w")
    	f.write(fullHtml)
    	f.close()
    except:
    	print("Impossible d'écrire dans un fichier")
}

Connectez-vous au terminal IRIS et invoquez la fonction MarkGeoDetails

Nous invoquerons la fonction MarkGeoDetails() de la classe dc.IrisGeoMap.Folium.
La fonction nécessite deux paramètres :

1. location/locations(Nous pouvons passer plusieurs lieux en ajoutant "," entre les deux)
2. fichier HTML de trajet

Exécutons la commande suivante pour marquer Cambridge MA 02142, NY, Londres, UAE, Jeddah, Lahore, et Glasgow sur la carte et l'enregistrer en tant que fichier "irisgeomap_locations.html".

do ##class(dc.IrisGeoMap.Folium).MarkGeoDetails("Cambridge MA 02142,NY,London,UAE,Jeddah,Lahore,Glasgow","d:\irisgeomap_locations.html")

Le code ci-dessus génère le fichier HTML interactif suivant********:********

##

  ********

5.5-Analyse de données à l'aide de la biblithèque Python Pandas

Nous devons installer la bibliothèque Pandas à l'aide de la commande irispip, puis nous pouvons utiliser le code ci-dessous pour visualiser les données.
******** ********

6-Résumé

Python intégré d'InterSystems (IEP) est une fonctionnalité puissante qui vous permet d'intégrer du code Python de manière transparente dans vos applications InterSystems. Grâce à IEP, vous pouvez exploiter les nombreuses bibliothèques et cadres disponibles en Python pour améliorer la fonctionnalité de vos applications InterSystems. Dans cet article, nous allons explorer les fonctionnalités et les avantages clés d'IEP.

IEP est mis en œuvre sous la forme d'un ensemble de bibliothèques qui vous permettent d'interagir avec des objets Python et d'exécuter du code Python à partir d'applications InterSystems. Il s'agit d'un moyen simple et efficace d'intégrer du code Python dans vos applications InterSystems, ce qui vous permet d'effectuer des analyses de données, de l'apprentissage automatique, du traitement du langage naturel et d'autres tâches qui peuvent être difficiles à mettre en œuvre dans ObjectScript d'InterSystems.

L'un des principaux avantages de l'utilisation d'IEP est qu'il permet de faire le lien entre les mondes de Python et d'InterSystems. Il est ainsi facile d'utiliser les points forts des deux langages pour créer des applications puissantes qui combinent le meilleur des deux mondes.

IEP permet également d'étendre les fonctionnalités de vos applications InterSystems en exploitant les capacités de Python. Cela signifie que vous pouvez tirer parti du grand nombre de bibliothèques et de cadres disponibles en Python pour effectuer des tâches qui pourraient être difficiles à mettre en œuvre dans ObjectScript d'InterSystems.

Python intégré d'InterSystems offre un moyen puissant d'étendre les fonctionnalités de vos applications InterSystems en exploitant les capacités de Python. En intégrant du code Python dans vos applications InterSystems, vous pouvez profiter du grand nombre de bibliothèques et de cadres disponibles dans Python pour effectuer des tâches complexes qui pourraient être difficiles à mettre en œuvre dans ObjectScript d'Intersystems.

Merci!

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.

Aperçu général

En passant d'IRIS objectScript à Python, on s'aperçoit qu'il existe des différences syntaxiques fascinantes.

L'une d'entre elles concerne la manière dont Python renvoie des tuples à partir d'une méthode à décompression automatique.

En fait, il s'agit d'une méthode qui renvoie plusieurs valeurs. Quelle invention géniale :)

out1, out2 = some_function(in1, in2)

ObjectScript a une autre approche avec les paramètres ByRef et Output.

Do ##class(some_class).SomeMethod(.inAndOut1, in2, .out2)

Où:

• inAndOut1 représente ByRef
• out2 représente Output

Le point initiale (".") devant le nom de la variable passe ByRef et pour Output.

Le but de cet article est de décrire comment l'utilitaire communautaire PyHelper a été amélioré pour donner une façon pythonique de tirer parti des paramètres ByRef et Output. Il donne accès à %objlasterror et a une approche pour la gestion des types Python None.
 

Exemple ByRef

L'invocation normale pour python intégré serait :

oHL7=iris.cls("EnsLib.HL7.Message")._OpenId('er12345')

Lorsque cette méthode ne parvient pas à s'ouvrir, la variable "oHL7" est une chaîne vide.
Dans la signature de cette méthode, il y a un paramètre d'état qui est disponible pour le script de l'objet qui donne une explication du problème exact.
Par exemple :

• L'enregistrement peut ne pas exister
• L'enregistrement ne peut être ouvert dans le mode d'accès simultané exclusif par défaut ("1"), pendant un timeout.

ClassMethod %OpenId(id As %String = "", concurrency As %Integer = -1, ByRef sc As %Status = {$$$OK}) As %ObjectHandle

La méthode TupleOut peut aider à renvoyer la valeur de l'argument sc dans un contexte python.
 

> oHL7,tsc=iris.cls("alwo.PyHelper").TupleOut("EnsLib.HL7.Message","%OpenId",['sc'],1,'er145999', 0)
> oHL7
''
> iris.cls("%SYSTEM.Status").DisplayError(tsc)
ERROR #5809: Objet à charger introuvable, classe 'EnsLib.HL7.Message', ID 'er145999'1
```

La liste ['sc'] contient un seul élément dans ce cas. Elle peut retourner plusieurs valeurs ByRef, et dans l'ordre spécifié. Ce qui est utile pour décompresser automatiquement vers les variables python prévues.

La gestion des paramètres de sortie (Output) en cas d'exemple

Code Python :

> oHL7=iris.cls("EnsLib.HL7.Message")._OpenId('145')
> oHL7.GetValueAt('<%MSH:9.1')
''

La chaîne renvoyée est vide, mais est-ce parce que l'élément est effectivement vide OU parce que quelque chose s'est mal passé ?
Dans le script objet, il existe également un paramètre de sortie d'état (pStatus) auquel il est possible d'accéder pour déterminer cette condition.

Code script objet :

> write oHL7.GetValueAt("<%MSH:9.1",,.pStatus)
''
> Do $System.Status.DisplayError(pStatus)
ERROR <Ens>ErrGeneral: Aucun segment n'a été trouvé lors du trajet '<%MSH'

Avec TupleOut, la fonctionnalité équivalente peut être atteinte en renvoyant et en décompressant à la fois la valeur de retour de la méthode ET le paramètre de sortie d'état.

Code Python :

> hl7=iris.cls("EnsLib.HL7.Message")._OpenId(145,0)
> val, status = iris.cls("alwo.PyHelper").TupleOut(hl7,"GetValueAt",['pStatus'],1,"<&$BadMSH:9.1")
> val==''
True
> iris.cls("%SYSTEM.Status").IsError(status)
1
> iris.cls("%SYSTEM.Status").DisplayError(status)
ERROR <Ens>ErrGeneral: Aucun segment n'a été trouvé lors du trajet '<&$BadMSH'1

Variable spéciale %objlasterror

Dans ObjectScript, il est possible d'accéder à des variables de pourcentage dans le cadre d'une méthode.
Dans certains cas, il est utile de détecter la variable spéciale %objlasterror ou d'y accéder après avoir appelé une API CORE ou une API de tiers.
La méthode TupleOut permet d'accéder à %objlasterror, comme si elle avait été définie en tant que paramètre de sortie, lors de l'invocation de méthodes à partir de Python.

> del _objlasterror

> out,_objlasterror=iris.cls("alwo.PyHelper").TupleOut("EnsLib.HL7.Message","%OpenId",['%objlasterror'],1,'er145999', 0)

> iris.cls("%SYSTEM.Status").DisplayError(_objlasterror)
ERROR #5809: Objet à charger introuvable, classe 'EnsLib.HL7.Message', ID 'er145999'1

Quand "None" n'est pas une chaîne

TupleOut traite les références python "None" comme objectscript "undefined". Cela permet aux paramètres d'être définis par défaut et aux méthodes de se comporter de manière cohérente.
C'est important, par exemple, dans le cas de %Persistent::%OnNew, où la méthode %OnNew n'est pas déclenchée lorsque "None" est fourni comme valeur initiale "initvalue", alors qu'elle serait déclenchée si une chaîne vide était fournie.

En objectscript, l'implémentation pourrait être la suivante :

do oHL7.myMethod("val1",,,"val2")

Notez l'absence de variables entre les virgules.

TupleOut facilite le même comportement avec :

Python:

iris.cls("alwo.PyHelper").TupleOut(oHL7,"myMethod",[],0,"val1",None,None,"val2")

Une autre façon d'envisager la question est d'avoir une implémentation du code d'invocation en une seule ligne, qui se comporte de manière flexible en fonction de la configuration préalable des variables :

Object Script:

set arg1="val1"
kill arg2
kill arg3
set arg4="val2"
do oHL7.myMethod(.arg1, .arg2, .arg3, .arg4)

TupleOut facilite le même comportement avec :

Python:

arg1="val1"
arg2=None
arg3=None
arg4="val2"
iris.cls("alwo.PyHelper").TupleOut(oHL7,"myMethod",[],0,arg1,arg2,arg3,arg4)

Liste et dictionnaires

Lors de la gestion des paramètres d'entrée, de ByRef et Output, TupleOut utilise la correspondance automatique de PyHelper entre: l les listes IRIS et les listes Python
les tableaux IRIS et les tableaux Python
Il prend soin de toujours utiliser des chaînes pour représenter les clés du dictionnaire lorsqu'il passe des tableaux IRIS aux types Dict de Python.

Conclusion

J'espère que cet article contribuera à inspirer de nouvelles idées et discussions sur les idées et suggestions relatives à Python intégré.

J'espère aussi qu'il encouragera à explorer la flexibilité d'IRIS, qui peut facilement s'adapter à de nouveaux défis.

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 à tous !

Je partage avec vous un outil d'ingestion de données que nous avons utilisé dans certains projets.

DataPipe est un framework d'interopérabilité pour l'ingestion de données dans InterSystems IRIS de manière flexible. Il vous permet de recevoir des données de sources externes, de normaliser et de valider les informations et enfin d'effectuer toutes les opérations dont vous avez besoin avec vos données.

Modèle

En premier lieu, vous devez définir un modèle. Un modèle est simplement une classe qui s'étend à partir de DataPipe.Model où vous devez implémenter quelques méthodes :

Dans le modèle, vous spécifiez comment vous allez sérialiser / désérialiser les données, comment vous les normalisez et les validez et enfin quelle opération vous voulez effectuer avec vos données une fois qu'elles sont normalisées et validées.

Here you can find a full example of a DataPipe model.

Composants d'interopérabilité

Après avoir défini le modèle, vous pouvez ajouter les composants dont vous avez besoin à une production d'interopérabilité.

Vous devez mettre en place un processus d'ingestion qui doit comprendre les éléments suivants :

• La transformation Input > InboxAttributes où vous spécifiez comment extraire les attributs qui décrivent vos données d'entrée. Ces attributs peuvent être utilisés pour rechercher les données traitées.
• La transformation Input > Model où vous implémentez comment convertir les données entrantes dans votre modèle DataPipe.

Les autres composantes sont déjà préconstruites dans DataPipe. Vous avez un exemple de production ici.

DatapipeUI

Il existe également une interface utilisateur que vous pouvez utiliser pour gérer les données que vous ingérez dans le système.

Déploiement

Pour le déployer, vous avez besoin d'une instance IRIS d'InterSystems, où vous installez DataPipe (et RESTForms2 pour les API REST) et une application web externe (UI) qui interagira avec cette instance.

Si vous êtes intéressé et que vous souhaitez jeter un coup d'œil et tester cette solution, vous trouverez toutes les informations nécessaires dans le lien Open Exchange.

Bonjour à tous, 

Nous voici de nouveau réunis. Nouvelle année, nouveau concours, nouveau projet, vieilles raisons.

Triple barre oblique "Triple Slash" est dans la place" !

1999, c'était l'année où j'ai appris à coder, mon premier "IF", mon premier "Bonjour le monde"

Je me souviens encore de mon professeur expliquant à tout le monde dans cette classe le simple "while" et comment nous pouvons déterminer si une condition spécifique a été atteinte @Renato Banzai vous en souvenez vous ? Le professeur Barbosa, quel homme unique.   

Depuis lors, j'aime l'idée de coder, de transformer des idées en projets, en quelque chose d'utile. Mais nous savons tous que pour créer quelque chose, nous devons nous assurer que cela fonctionne ; nous ne nous contentons pas de créer mais nous testons si cela fonctionne et si cela continue à fonctionner si nous ajoutons quelque chose de nouveau.

Et pour être honnête avec chacun d'entre vous, créer des tests, c'est ennuyeux. Du moins pour moi, mais si vous aimez le faire, je n'ai rien contre vous.

En utilisant une mauvaise analogie, je peux dire que la création de méthodes d'essai est comme le nettoyage de votre maison ou le repassage de vos vêtements. C'est ennuyeux, mais c'est nécessaire si vous voulez quelque chose de mieux.  

En gardant cela à l'esprit, pourquoi ne pas créer un moyen meilleur et plus facile pour les tests ? 

Ainsi, inspirés par le style elixir style and in et par cette idée d' InterSystems Ideas (Merci @Evgeny Shvarov)! Nous avons essayé d'améliorer le processus de test et de le transformer à nouveau en une tâche agréable.

Nous simplifions le %UnitTest et pour vous montrer comment utiliser TripleSlash pour créer vos tests unitaires, utilisons un exemple simple.

Disons que vous avez la classe et la méthode suivantes, pour lesquelles vous souhaitez écrire un test unitaire :

Class dc.sample.ObjectScript
{
ClassMethod TheAnswerForEverything() As%Integer
{

   Set a = 42Write"Bonjour le monde !",!

   Write"C'est InterSystems IRIS avec la version ",$zv,!

   Write"L'heure actuelle est : "_$zdt($h,2)

   Return a

}
}

Comme vous pouvez le constater, la méthode TheAnswerForEverything() ne fait que retranscrire le nombre 42. Indiquons donc dans la documentation de la méthode comment TripleSlash doit créer un test unitaire pour cette méthode :

/// Une méthode simple à des fins de tests./// /// /// Ecrivez ##class(dc.sample.ObjectScript).Test()/// 42/// ClassMethod TheAnswerForEverything() As%Integer
{
    ...
}

Les tests unitaires doivent être entourés de la balise <exemple></exemple>. Vous pouvez ajouter tout type de documentation, mais tous les tests doivent être contenus dans une telle balise.

Maintenant, démarrez une session de terminal IRIS, allez dans l'espace de noms IRISAPP créez une instance de la classe Core en passant le nom de la classe (ou son nom de paquet pour toutes ses classes) et exécutez ensuite la méthode Execute() :

USER>ZN"IRISAPP"
IRISAPP>Do##class(iris.tripleSlash.Core).%New("dc.sample.ObjectScript").Execute()

TripleSlash interprétera ceci comme "Étant donné le résultat de la méthode Test(), affirme qu'il est égal à 42". Ainsi, une nouvelle classe sera créée dans le test unitaire :

Class iris.tripleSlash.tst.ObjectScript Extends%UnitTest.TestCase
{

Method TestTheAnswerForEverything()
{
    Do$$$AssertEquals(##class(dc.sample.ObjectScript).TheAnswerForEverything(), 42)
}

}

Ajoutons maintenant une nouvelle méthode pour tester les autres moyens permettant d'indiquer à TripleSlash comment écrire vos tests unitaires.

Class dc.sample.ObjectScript
{

ClassMethod GuessTheNumber(pNumber As%Integer) As%Status
{
    Set st = $$$OKSet theAnswerForEveryThing = 42Try {
        Throw:(pNumber '= theAnswerForEveryThing) ##class(%Exception.StatusException).%New("Sorry, wrong number...")
    } Catch(e) {
        Set st = e.AsStatus()
    }

    Return st

}

}

Comme vous pouvez le constater, la méthode GuessTheNumber() attend un nombre, renvoie $$$OK uniquement si le nombre 42 est transmis ou une erreur pour toute autre valeur. Il faut donc indiquer dans la documentation de la méthode comment TripleSlash doit créer un test unitaire pour cette méthode :

/// Une autre méthode simple à des fins de test./// /// /// Exécutez ##class(dc.sample.ObjectScript).GuessTheNumber(42)/// $$$OK/// Do ##class(dc.sample.ObjectScript).GuessTheNumber(23)/// $$$NotOK/// ClassMethod GuessTheNumber(pNumber As%Integer) As%Status
{
    ...
}

Exécutez à nouveau la méthode Execute() et vous verrez une nouvelle méthode de test dans la classe de test unitaire iris.tripleSlash.tst.ObjectScript:

Class iris.tripleSlash.tst.ObjectScript Extends%UnitTest.TestCase
{

La méthode TestGuessTheNumber()
{

    Do$$$AssertStatusOK(##class(dc.sample.ObjectScript).GuessTheNumber(42))
    Do$$$AssertStatusNotOK(##class(dc.sample.ObjectScript).GuessTheNumber(23))
}

}

Actuellement, les assertions suivantes sont disponibles : $$$AssertStatusOK, $$$AssertStatusNotOK et $$$AssertEquals. 

TripleSlash nous permet de générer des tests à partir d'exemples de code trouvés dans les descriptions de méthodes. Il vous permet de faire d'une pierre deux coups, en améliorant la documentation de vos classes et en créant l'automatisation des tests. 

Remerciements

Une fois encore, nous vous remercions pour tout le soutien de la communauté dans chacune des applications que nous créons.

Si vous avez trouvé notre application intéressante et avez apporté votre contribution, veuillez voter pour iris-tripleslash et nous aider dans cette aventure !

Mise à jour des plates-formes prises en charge par InterSystems, février 2023

Bienvenue à la toute première Mise à jour des Plates-formes prises en charge ! Nous recevons souvent des questions sur les changements récents et à venir dans la liste des plates-formes et des frameworks pris en charge par la plate-forme de données IRIS d'InterSystems. Cette mise à jour vise à partager les changements récents ainsi que nos meilleures connaissances actuelles sur les changements à venir, mais prévoir l'avenir est une affaire délicate et ceci ne doit pas être considéré comme une véritable feuille de route.

Nous prévoyons de publier ce type de mise à jour tous les trois mois environ, puis de procéder à une réévaluation au bout d'un an. Si vous trouvez cette mise à jour utile, faites-le nous savoir ! Nous apprécierions également toute suggestion visant à l'améliorer.

Une fois cela dit, passons à la mise à jour...

Systèmes d'exploitation de production et architectures de CPU pour IRIS

Red Hat Enterprise Linux

Ubuntu

SUSE Linux

Oracle Linux

Microsoft Windows

AIX

Conteneurs

Systèmes d'exploitation et Architectures de CPU pour IRIS Development

MacOS

CentOS

Systèmes d'exploitation de production et architectures de CPU pour Caché et Ensemble

Documentation sur les plates-formes prises en charge par InterSystems

La documentation des Plates-formes prises en charge par InterSystems est la source de la liste définitive des technologies prises en charge.

… et c'est tout, les gars. Encore une fois, s'il y a quelque chose de plus que vous aimeriez savoir, n'hésitez pas à nous le signaler.

InterSystems met périodiquement à jour ses politiques et pratiques en matière de publication de logiciels afin de s'adapter aux besoins des clients.

Nous sommes en train de modifier notre cadence de publication des mises à jour afin d'être plus prévisibles pour les clients et les partenaires, et de modifier quelques autres aspects.

Cet article résume la cadence de publication de nos produits "Data Platforms" (Plateformes de données) et les changements récents qui y ont été apportés, et vous annonce quelques nouvelles mises à jour.

Pourquoi changer ?

• Nos clients acceptent plus rapidement nos nouvelles versions.
• Les problèmes de sécurité sont plus fréquents, notamment dans les bibliothèques de tiers.
• Nos clients demandent des dates de livraison plus prévisibles.

Qu'est-ce qui n'a pas changé ? Rappel de notre cadence de publication des fonctionnalités

InterSystems utilise une cadence de publication de fonctionnalités à deux flux avec InterSystems IRIS depuis 2018 (voir l' annonce originale original announcement). Nous fournissons :

• Livraison continue (CD) des versions—Ces versions permettent d'accéder rapidement aux nouvelles fonctionnalités et sont idéales pour le développement et le déploiement d'applications qui sont continuellement mises à jour et peuvent bénéficier immédiatement des nouvelles fonctionnalités. On l'appelle parfois le "train rapide".
• Les versions de maintenance prolongée (EM)—ces versions sont moins fréquentes que les versions de livraison continue mais elles apportent la stabilité accrue des versions de maintenance. Elles sont idéales pour les grandes applications d'entreprise où la facilité d'obtenir des correctifs dans les versions de maintenance est plus importante que d'obtenir un accès précoce aux nouvelles fonctionnalités. On l'appelle parfois le train lent.

Les versions EM sont faciles à identifier car leur numéro de version est YYYY.1 (par exemple 2022.1 ou 2023.1). Les versions CD auront un numéro de version de la forme YYYY.2, YYYY.3 etc.

Il y a un an, nous avons fait évoluer notre cadence, en ajoutant des kits pour les versions CD et en ajoutant HealthShare Health Connect dans ces trains de versions aux côtés d'InterSystems IRIS et d'InterSystems IRIS for Health. ( Voir la mise à jour février 2022). Quelques restrictions sur les versions CD du train rapide restent en vigueur : il n'y a pas de mises à jour de maintenance ou de sécurité ; il n'y a pas de conversion sur place à partir de Caché ou Ensemble ; et le chemin de mise à jour pour une version CD est limité à la version CD suivante ou à la version EM suivante.

Les versions de fonctionnalités (EM et CD) passent par une phase de prévisualisation au cours de laquelle les clients peuvent télécharger et utiliser les nouvelles versions, afin de se préparer à la sortie de la nouvelle version. Les prévisualisations sont un moment idéal pour fournir des commentaires et des tests afin de s'assurer que votre application fonctionne bien avec la nouvelle version. À partir de la version 2022.2, nous avons commencé à mettre à jour les prévisualisations toutes les deux semaines, toujours le mercredi.

Les réactions à la cadence de publication et à ces mises à jour ont été très positives, et nous avons pu gérer la cadence de publication à deux flux tout en maintenant une très haute qualité.

Mises à jour des plateformes

Les clients adoptent de nouveaux systèmes d'exploitation beaucoup plus rapidement, notamment dans le cloud. Nous avons modifié notre cadence en conséquence. En 2022, nous avons commencé à ajouter la prise en charge de nouveaux systèmes d'exploitation dans les versions de maintenance. La version 2022.1.1 a ajouté la prise en charge d'Ubuntu 22.04 et la version 2022.1.2 celle de RHEL 9. Cette approche signifie que les clients peuvent adopter de nouveaux systèmes d'exploitation beaucoup plus tôt.

Les changements de sécurité sont plus fréquents, en particulier pour les bibliothèques communes fournies avec ces systèmes d'exploitation, comme OpenSSL. Avec notre version 2022.1, nous avons commencé à utiliser les bibliothèques OpenSSL du système d'exploitation, afin que les clients puissent se tenir au courant des mises à jour de sécurité via leur système d'exploitation. Cela signifie également la compilation et l'emballage de kits séparés pour chaque version majeure d'un système d'exploitation Linux. Nous limitons ces kits à deux versions majeures dans chaque version EM. Si nous introduisons une nouvelle prise en charge du système d'exploitation dans une version de maintenance, nous ne supprimerons pas les versions antérieures, de sorte qu'il peut y avoir trois ensembles de kits ; cela est réduit à deux avec la prochaine version EM. Par exemple, la version 2022.1.2 comporte trois ensembles de kits Red Hat (RHEL 7, RHEL 8 et RHEL 9) ; la version 2022.1.3 comportera les mêmes ensembles de kits, mais la version 2023.1.0 ne comportera que les kits RHEL 8 et RHEL 9.

Comme les changements de plateforme s'accélèrent, nous voulons donner aux clients une visibilité sur ce qui se prépare. Nous avons introduit une "mise à jour des plateformes" trimestrielle sous forme de bulletin d'information ; vous pouvez lire le premier numéro sur la communauté des développeurs. Veuillez nous faire part de vos commentaires sur le format, l'horizon temporel, etc.

Maintenance et mises à jour de sécurité

Nous continuons à fournir des mises à jour de maintenance sur InterSystems IRIS pendant deux ans, ainsi que des mises à jour de maintenance sur Caché et Ensemble (voir Version minimale prise en charge). Outre les mises à jour de maintenance, nous fournissons des corrections de sécurité.

Nous faisons référence à la suite de versions qui mettent à jour une version EM, sur tous les produits et plateformes associés, comme un flux. Par exemple, 2021.1.0, 2021.1.1, 2021.1.2 est un flux, tandis que 2022.1.0, 2022.1.1, 2022.1.2 est un autre flux. Cela signifie que nous fournissons des versions de maintenance pour trois flux (l'EM le plus récent et les EM précédents d'InterSystems IRIS, d'InterSystems IRIS for Health et de Health Connect, ainsi que Caché et Ensemble, qui constitue son propre flux).

À partir d'avril 2023, InterSystems fournira des corrections de sécurité pour les versions actuelles et les versions des trois dernières années d'InterSystems IRIS, ainsi que pour la dernière version de maintenance de Caché. Cela signifie que les corrections de sécurité sont fournies pour deux flux supplémentaires au-delà des mises à jour de maintenance (cinq flux au total). Par exemple, en 2024, InterSystems fournira des corrections de sécurité pour les versions InterSystems IRIS 2021.1.x, 2022.1.x, 2023.1.x, ainsi que pour la version 2024.1.x alors en vigueur ; InterSystems fournira également des corrections de sécurité pour Caché 2018.1.x. 

Nous avons récemment amélioré notre politique de traitement des vulnérabilités de sécurité pour tenir compte du volume plus important de problèmes de sécurité que nous constatons, dont la plupart sont de gravité faible ou moyenne (voir Politique de traitement des vulnérabilités de sécurité mise à jour). Nous incluons désormais des mises à jour de sécurité dans chaque version. Les informations sur les problèmes de gravité élevée et critique font l'objet d'un embargo (pour éviter de fournir des informations qui pourraient être utilisées pour exploiter des brèches de sécurité) jusqu'à ce que ces problèmes soient traités dans tous les flux pris en charge - à ce moment-là, nous émettons une alerte de sécurité avec les détails des vulnérabilités qui ont été traitées.

Des versions de maintenance prévisibles

Les clients nous disent qu'ils apprécient de recevoir régulièrement des mises à jour logicielles et qu'ils veulent être en mesure de faire des plans en fonction de la date à laquelle ils peuvent les attendre. Nous sommes en train d'officialiser notre calendrier de publication des mises à jour, comme suit :

Nous avons publié une version de maintenance pour le flux InterSystems IRIS 2022.1 le 18 janvier (voir notre annonce de la version 2022.1.2). Nous prévoyons de publier des versions de maintenance pour le flux InterSystems IRIS 2021.1 et le flux Caché et Ensemble 2018.1 le 28 février.

En 2023, nous prévoyons une version EM (2023.1) et deux versions CD (2023.2 et 2023.3). Une fois que 2023.1.0 est généralement disponible (GA), il devient le flux IRIS d'InterSystems le plus récent, et 2022.1 devient le flux précédent.

Suppression des versions précédentes de la CMR (mais pas de l'ICR)

Parce que nos sorties sont devenues plus fréquentes et que nous publions plus de kits (un par version majeure de Linux OS), le nombre de versions disponibles sur le site de distribution de logiciels du CMR a considérablement augmenté et est devenu déroutant pour certains clients. Nous adoptons une nouvelle pratique consistant à retirer régulièrement les anciennes versions de chaque flux du site de distribution.

• Seule la version la plus récente du CD sera visible - parce que 2022.3 est maintenant généralement disponible, nous retirerons les images 2022.2 à la fin du mois de février.
• Seule la version de maintenance la plus récente par flux sera visible - 2022.1.1 a été supprimée lors de la publication de 2022.1.2. Cela permet d'éviter le problème des clients qui installent par erreur des logiciels présentant des problèmes de sécurité connus.

Les versions précédentes sont disponibles sur demande. Nous suggérons également aux clients qui standardisent une version unique pour de nombreux sites de conserver leur propre copie du kit pour cette version. Pour garantir l'intégrité, tous les kits et conteneurs sont signés ; les fichiers checksum et les fichiers de signature PGP sont téléchargeables sur le site de distribution du CMR.

Nous travaillons de manière différente avec les conteneurs publiés sur l'InterSystems Container Repository (ICR), car les clients utilisent généralement des versions spécifiques dans les pipelines CI/CD. Nous ne supprimerons pas les anciennes images de l'ICR avant qu'elles aient deux ans. Nous recommandons aux clients de maintenir leurs pipelines CI/CD à jour, et la rétroaction que nous recevons est celui qu'ils font.

Engagement envers la réussite du client

Tous les changements décrits dans cet article ont été effectués dans le but d'aider les clients à réussir. Nous sommes à l'écoute des préoccupations de nos clients concernant les problèmes de sécurité, l'adoption de la plate-forme, les mises à jour de maintenance et la cadence des versions, et nous modifions les choses en fonction de ces rétroactions. N'hésitez pas à nous contacter pour nous faire part de vos commentaires et suggestions !

InterSystems a corrigé un problème qui pouvait empêcher InterSystems IRIS® et Caché de tirer parti des pages volumineuses pour la mémoire partagée sous Windows, même si ces produits signalent que des pages volumineuses sont allouées. Cela peut avoir des effets néfastes sur les performances du système.

Le problème résulte d'un changement dans Windows 10 qui nécessite la modification d'InterSystems IRIS® et de Caché. Notez que ce problème affecte également tous les produits InterSystems basés sur InterSystems IRIS® ou Caché. Le problème se produit sur les versions suivantes de Windows :

Introduction

Dans un article précédent, j'ai abordé les modèles d'exécution des tests unitaires via le gestionnaire de paquets ObjectScript. Cet article va un peu plus loin, en utilisant les actions GitHub pour piloter l'exécution des tests et la création de rapports. Le cas d'utilisation qui nous motive est l'exécution du CI pour l'un de mes projets Open Exchange, AppS.REST (voir l'article d'introduction à ce projet ici). Vous pouvez voir l'implémentation complète dont les extraits de cet article ont été tirés sur GitHub ; elle pourrait facilement servir de modèle pour l'exécution de l'IC pour d'autres projets utilisant le gestionnaire de paquets ObjectScript.

Les fonctionnalités dont la mise en œuvre a été démontrée comprennent :

• Compilation et test d'un paquet ObjectScript
• Rapport sur la mesure de la couverture des tests (en utilisant le paquet TestCoverage) via codecov.io
• Téléchargement d'un rapport sur les résultats des tests en tant qu'artefact de comppilation.

L'environnement de compilation

Il existe une documentation complète sur les actions GitHub ici. Dans le cadre de cet article, nous nous contenterons d'explorer les aspects présentés dans cet exemple.

Un flux de travail dans les actions GitHub est déclenché par un ensemble configurable d'événements et consiste en un certain nombre de tâches qui peuvent être exécutées séquentiellement ou en parallèle. Chaque tâche comporte un ensemble d'étapes - nous allons entrer dans le détail des étapes de notre exemple d'action plus tard. Ces étapes consistent en références à des actions disponibles sur GitHub, ou peuvent simplement être des commandes shell. Un extrait du modèle initial de notre exemple ressemble à ceci :

# Flux de travail d'intégration continue
name: CI

# Contrôle le moment où l'action sera exécutée. Déclenche le flux de travail sur les événements push ou pull request
# événements dans toutes les branches
on: [push, pull_request]

# Un flux de travail est composé d'une ou plusieurs tâches qui peuvent être exécutées séquentiellement ou en parallèle.
jobs:
  # Ce flux de travail contient une seule tâche appelé "build".
  build :
    # Le type d'exécuteur sur lequel le travail sera exécuté
    runs-on : ubuntu-latest

    env:
    # Variables d'environnement utilisables tout au long de la tâche de "compilation", par exemple dans les commandes au niveau du système d'exploitation.
package: apps.rest
    container_image : intersystemsdc/iris-community:2019.4.0.383.0-zpm
    # D'autres éléments seront abordés plus tard...

    # Les étapes représentent une séquence de tâches qui seront exécutées dans le cadre du travail.
     steps:
          # Ceux-ci seront montrés plus tard...

Dans cet exemple, un certain nombre de variables d'environnement sont utilisées. Pour appliquer cet exemple à d'autres paquets utilisant le gestionnaire de paquets ObjectScript, la plupart d'entre elles n'auront pas besoin d'être modifiées, alors que certaines le seront.

    env:
      # ** POUR UN USAGE GÉNÉRAL, IL FAUDRA PROBABLEMENT CHANGER : **
      package: apps.rest
      container_image: intersystemsdc/iris-community:2019.4.0.383.0-zpm

      # ** POUR UN USAGE GÉNÉRAL, IL FAUDRA PEUT-ÊTRE CHANGER : **
      build_flags: -dev -verbose # Télécharger en mode -dev pour obtenir le code de test unitaire préchargé
      test_package: UnitTest

      # ** POUR UN USAGE GÉNÉRAL, IL NE FAUDRA PAS CHANGER : **
      instance: iris
      # Remarque : la valeur test_reports est dupliquée dans la variable d'environnement test_flags.
      test_reports: test-reports
      test_flags: >-
       -verbose -DUnitTest.ManagerClass=TestCoverage.Manager -DUnitTest.JUnitOutput=/test-reports/junit.xml
       -DUnitTest.FailuresAreFatal=1 -DUnitTest.Manager=TestCoverage.Manager
       -DUnitTest.UserParam.CoverageReportClass=TestCoverage.Report.Cobertura.ReportGenerator
       -DUnitTest.UserParam.CoverageReportFile=/source/coverage.xml

Si vous voulez adapter cela à votre propre paquet, il suffit de déposer votre propre nom de paquet et votre image de conteneur préférée (doit inclure zpm - voir https://hub.docker.com/r/intersystemsdc/iris-community). Vous pourriez également vouloir changer le paquet de tests unitaires pour qu'il corresponde à la convention de votre propre paquet (si vous devez charger et compiler les tests unitaires avant de les exécuter pour gérer toutes les dépendances de chargement/compilation ; j'ai eu quelques problèmes bizarres spécifiques aux tests unitaires pour ce paquet, donc cela pourrait même ne pas être pertinent dans d'autres cas).

Le nom de l'instance et le répertoire test_reports ne devraient pas être modifiés pour d'autres utilisations, et les test_flags fournissent un bon ensemble de valeurs par défaut - ils permettent de faire en sorte que les échecs des tests unitaires signalent l'échec de la compilation, et gèrent également l'exportation des résultats des tests au format jUnit et un rapport de couverture de code.

Étapes de compilation

Vérification des référentiels GitHub

Dans notre exemple de motivation, deux dépôts doivent être vérifiés - celui qui est testé, et aussi mon fork de Forgery (parce que les tests unitaires en ont besoin).

    # Vérifie ce référentiel sous $GITHUB_WORKSPACE, afin que votre tâche puisse y accéder.
    - uses: actions/checkout@v2

    # Il faut aussi vérifier le timleavitt/forgery jusqu'à la version officielle installable via ZPM
    - uses: actions/checkout@v2
      with:
        repository: timleavitt/forgery
        path: forgery

$GITHUB_WORKSPACE est une variable d'environnement très importante, représentant le répertoire racine où tout cela fonctionne. Du point de vue des permissions, vous pouvez faire à peu près tout ce que vous voulez dans ce répertoire ; ailleurs, vous pouvez rencontrer des problèmes.

Exécution du conteneur IRIS d'InterSystems

Après avoir configuré un répertoire où nous finirons par placer nos rapports de résultats de tests, nous allons exécuter le conteneur InterSystems IRIS Community Edition (+ZPM) pour notre compilation.

    - name: Run Container
      run: |
        # Créer le répertoire test_reports pour partager les résultats des tests avant l'exécution du conteneur.
        mkdir $test_reports
        chmod 777 $test_reports
        # Lancer l'instance InterSystems IRIS
        docker pull $container_image
        docker run -d -h $instance --name $instance -v $GITHUB_WORKSPACE:/source -v $GITHUB_WORKSPACE/$test_reports:/$test_reports --init $container_image
        echo halt > wait
        # Attendez que l'instance soit prête
        until docker exec --interactive $instance iris session $instance < wait; do sleep 1; done

Il y a deux volumes partagés avec le conteneur - l'espace de travail GitHub (pour que le code puisse être chargé ; nous y rapporterons également des informations sur la couverture des tests), et un répertoire séparé où nous placerons les résultats des tests jUnit.

Après la fin de "docker run", cela ne signifie pas que l'instance est complètement démarrée et prête à être commandée. Pour attendre que l'instance soit prête, nous continuerons à essayer d'exécuter une commande "halt" via la session iris ; cela échouera et continuera à essayer une fois par seconde jusqu'à ce que cela réussisse (éventuellement), indiquant que l'instance est prête.

Installation des bibliothèques liées aux tests

Pour notre cas d'utilisation motivant, nous utiliserons deux autres bibliothèques pour les tests - TestCoverage et Forgery. TestCoverage peut être installé directement via le Community Package Manager ; Forgery (actuellement) doit être chargé via zpm "load" ; mais les deux approches sont valables.

    - name: Install TestCoverage
      run: |
        echo "zpm \"install testcoverage\":1:1" > install-testcoverage
        docker exec --interactive $instance iris session $instance -B < install-testcoverage
        # Solution aux problèmes de permissions dans TestCoverage (création d'un répertoire pour l'exportation des sources)
        chmod 777 $GITHUB_WORKSPACE

    - name: Install Forgery
      run: |
        echo "zpm \"load /source/forgery\":1:1" > load-forgery
        docker exec --interactive $instance iris session $instance -B < load-forgery

L'approche générale consiste à écrire les commandes dans un fichier, puis à les exécuter en session IRIS. Le ":1:1" supplémentaire dans les commandes ZPM indique que la commande doit quitter le processus avec un code d'erreur si une erreur se produit, et s'arrêter à la fin si aucune erreur ne se produit ; cela signifie que si une erreur se produit, elle sera signalée comme une étape de compilation ayant échoué, et nous n'avons pas besoin d'ajouter une commande "halt" à la fin de chaque fichier.

Compilation et test du paquet

Enfin, nous pouvons effectivement compiler et exécuter des tests pour notre paquet. C'est assez simple - remarquez l'utilisation des variables d'environnement $build_flags/$test_flags que nous avons définies plus tôt.

    # Exécute un ensemble de commandes en utilisant l'exécuteur runners
    - name: Build and Test
      run: |
        # Exécution de compilation
        echo "zpm \"load /source $build_flags\":1:1" > build
        # Le paquet de test est compilé en premier comme solution de contournement pour certains problèmes de dépendance.
        echo "do \$System.OBJ.CompilePackage(\"$test_package\",\"ckd\") " > test
        # Exécution des tests
        echo "zpm \"$package test -only $test_flags\":1:1" >> test
        docker exec --interactive $instance iris session $instance -B < build && docker exec --interactive $instance iris session $instance -B < test && bash <(curl -s https://codecov.io/bash)

Cela suit le même schéma que nous avons vu, écrire des commandes dans un fichier puis utiliser ce fichier comme entrée de la session iris.

La dernière partie de la dernière ligne télécharge les résultats de la couverture du code sur codecov.io. Super facile !

Téléchargement des résultats des tests unitaires

Supposons qu'un test unitaire échoue. Il serait vraiment ennuyeux de devoir revenir en arrière dans le journal de compilation pour trouver ce qui n'a pas fonctionné, bien que cela puisse toujours fournir un contexte utile. Pour nous faciliter la vie, nous pouvons télécharger nos résultats formatés par jUnit et même exécuter un programme tiers pour les transformer en un joli rapport HTML.

    # Générer et télécharger le rapport HTML xUnit
    - name: XUnit Viewer
      id: xunit-viewer
      uses: AutoModality/action-xunit-viewer@v1
      if: always()
      with:
        # Avec -DUnitTest.FailuresAreFatal=1, un test unitaire qui échoue fera échouer la compilation avant ce point.
        # Cette action pourrait autrement mal interpréter notre sortie de style xUnit et faire échouer la compilation même si
        # tous les tests sont passés.
        fail: false
    - name: Atacher le rapport
      uses: actions/upload-artifact@v1
      if: always()
      with:
        name: ${{ steps.xunit-viewer.outputs.report-name }}
        path: ${{ steps.xunit-viewer.outputs.report-dir }}

Ces informations sont principalement tirées du fichier readme à l'adresse https://github.com/AutoModality/action-xunit-viewer.

Le résultat final

Si vous voulez voir les résultats de ce flux de travail, regardez :

Les journaux pour le job CI sur intersystems/apps-rest (y compris les artefacts de compilation) : https://github.com/intersystems/apps-rest/actions?query=workflow%3ACI
Rapports de couverture de test : https://codecov.io/gh/intersystems/apps-rest

N'hésitez pas à me faire savoir si vous avez des questions !

Chez InterSystems, nous croyons en la divulgation responsable des vulnérabilités de sécurité récemment découvertes. Nous fournissons des informations opportunes à nos clients, tout en les gardant hors de la portée des personnes susceptibles d'en faire un mauvais usage. Nous comprenons également que chaque client a des exigences différentes liées à la résolution des problèmes de sécurité.

Alors que nous commençons 2023, nous avons apporté deux changements importants à notre approche des corrections des failles de sécurité que je voudrais souligner :

Intersystems IRIS for Health offre un excellent support pour la norme sectorielle FHIR. Les principales caractéristiques sont :

1. Serveur FHIR
2. Base de données FHIR
3. API REST et ObjectScript pour les opérations CRUD sur les ressources FHIR (patient, questionnaire, vaccins, etc.)

Cet article explique comment utiliser chacune de ces fonctionnalités, et présente un front-end angulaire permettant de créer et d'afficher des ressources FHIR de type Quiz.

Étape 1 - Déploiement de votre serveur FHIR à l'aide d'InterSystems IRIS for Health

Pour créer votre serveur FHIR, il faut ajouter les instructions suivantes dans le fichier iris.script ( à partir de : https://openexchange.intersystems.com/package/iris-fhir-template)

    zn "HSLIB"
    set namespace="FHIRSERVER"
    Set appKey = "/fhir/r4"
    Set strategyClass = "HS.FHIRServer.Storage.Json.InteractionsStrategy"
    set metadataPackages = $lb("hl7.fhir.r4.core@4.0.1")
    set importdir="/opt/irisapp/src"

    //Install a Foundation namespace and change to it
    Do ##class(HS.HC.Util.Installer).InstallFoundation(namespace)
    zn namespace

    // Install elements that are required for a FHIR-enabled namespace
    Do ##class(HS.FHIRServer.Installer).InstallNamespace()

    // Install an instance of a FHIR Service into the current namespace
    Do ##class(HS.FHIRServer.Installer).InstallInstance(appKey, strategyClass, metadataPackages)

    // Configure FHIR Service instance to accept unauthenticated requests
    set strategy = ##class(HS.FHIRServer.API.InteractionsStrategy).GetStrategyForEndpoint(appKey)
    set config = strategy.GetServiceConfigData()
    set config.DebugMode = 4
    do strategy.SaveServiceConfigData(config)

    zw ##class(HS.FHIRServer.Tools.DataLoader).SubmitResourceFiles("/opt/irisapp/fhirdata/", "FHIRServer", appKey)

    do $System.OBJ.LoadDir("/opt/irisapp/src","ck",,1)

    zn "%SYS"
    Do ##class(Security.Users).UnExpireUserPasswords("*")

    zn "FHIRSERVER"
    zpm "load /opt/irisapp/ -v":1:1

    //zpm "install fhir-portal"
    halt

En utilisant la classe utilitaire HS.FHIRServer.Installer, vous pouvez créer votre serveur FHIR.

Étape 2 - Utilisez l'API FHIR REST ou ObjectScript pour lire, mettre à jour, supprimer et trouver des données FHIR

Je préfère utiliser la classe ObjectScript HS.FHIRServer.Service pour faire toutes les opérations CRUD.

Pour obtenir toutes les données FHIR provenant d'un type de ressource (comme le questionnaire) :

/// Retreive all the records of questionnaire
ClassMethod GetAllQuestionnaire() As %Status
{

    set tSC = $$$OK
    Set %response.ContentType = ..#CONTENTTYPEJSON
    Set %response.Headers("Access-Control-Allow-Origin")="*"

    Try {
        set fhirService = ##class(HS.FHIRServer.Service).EnsureInstance(..#URL)
        set request = ##class(HS.FHIRServer.API.Data.Request).%New()
        set request.RequestPath = "/Questionnaire/"
        set request.RequestMethod = "GET"
        do fhirService.DispatchRequest(request, .pResponse)
        set json = pResponse.Json
        set resp = []
        set iter = json.entry.%GetIterator()
        while iter.%GetNext(.key, .value) { 
          do resp.%Push(value.resource)
        }
        
        write resp.%ToJSON()    
    } Catch Err {
        set tSC = 1
        set message = {}
        set message.type= "ERROR"
        set message.details = "Error on get all questionnairies"       
    }
    
    Quit tSC
}

Pour obtenir un élément de données spécifique du référentiel de données FHIR (comme une occurrence de questionnaire) :

/// Retreive a questionnaire by id
ClassMethod GetQuestionnaire(id As %String) As %Status
{

    set tSC = $$$OK
    Set %response.ContentType = ..#CONTENTTYPEJSON
    Set %response.Headers("Access-Control-Allow-Origin")="*"

    Try {
        set fhirService = ##class(HS.FHIRServer.Service).EnsureInstance(..#URL)
        set request = ##class(HS.FHIRServer.API.Data.Request).%New()
        set request.RequestPath = "/Questionnaire/"_id
        set request.RequestMethod = "GET"
        do fhirService.DispatchRequest(request, .pResponse)
        write pResponse.Json.%ToJSON()    
    } Catch Err {
        set tSC = 1
        set message = {}
        set message.type= "ERROR"
        set message.details = "Error on get the questionnaire"       
    }
    
    Quit tSC
}

Pour créer une nouvelle occurrence de ressource FHIR (comme un nouveau questionnaire) :

/// Create questionnaire
ClassMethod CreateQuestionnaire() As %Status
{
  set tSC = $$$OK
  Set %response.ContentType = ..#CONTENTTYPEJSON
  Set %response.Headers("Access-Control-Allow-Origin")="*"

  Try {
    set fhirService = ##class(HS.FHIRServer.Service).EnsureInstance(..#URL)
    set request = ##class(HS.FHIRServer.API.Data.Request).%New()
    set request.RequestPath = "/Questionnaire/"
    set request.RequestMethod = "POST"
    set data = {}.%FromJSON(%request.Content)
    set data.resourceType = "Questionnaire"
    set request.Json = data
    do fhirService.DispatchRequest(request, .response)
    write response.Json.%ToJSON()
  } Catch Err {
    set tSC = 1
    set message = {}
    set message.type= "ERROR"
    set message.details = "Error on create questionnaire"
  }
  
  Return tSC
}

Pour mettre à jour une ressource FHIR (comme un questionnaire) :

/// Update a questionnaire
ClassMethod UpdateQuestionnaire(id As %String) As %Status
{
  set tSC = $$$OK
  Set %response.ContentType = ..#CONTENTTYPEJSON
  Set %response.Headers("Access-Control-Allow-Origin")="*"

  Try {
    set fhirService = ##class(HS.FHIRServer.Service).EnsureInstance(..#URL)
    set request = ##class(HS.FHIRServer.API.Data.Request).%New()
    set request.RequestPath = "/Questionnaire/"_id
    set request.RequestMethod = "PUT"
    set data = {}.%FromJSON(%request.Content)
    set data.resourceType = "Questionnaire"
    set request.Json = data
    do fhirService.DispatchRequest(request, .response)
    write response.Json.%ToJSON()
  }Catch Err {
    set tSC = 1
    set message = {}
    set message.type= "ERROR"
    set message.details = "Error on update questionnaire"
  }
  Return tSC
}

Pour supprimer un occurrence de ressource FHIR (comme un questionnaire) :

/// Delete a questionnaire by id
ClassMethod DeleteQuestionnaire(id As %String) As %Status
{

    set tSC = $$$OK
    Set %response.ContentType = ..#CONTENTTYPEJSON
    Set %response.Headers("Access-Control-Allow-Origin")="*"

    Try {
        set fhirService = ##class(HS.FHIRServer.Service).EnsureInstance(..#URL)
        set request = ##class(HS.FHIRServer.API.Data.Request).%New()
        set request.RequestPath = "/Questionnaire/"_id
        set request.RequestMethod = "DELETE"
        do fhirService.DispatchRequest(request, .pResponse)
    } Catch Err {
        set tSC = 1
        set message = {}
        set message.type= "ERROR"
        set message.details = "Error on delete the questionnaire"       
    }
    
    Quit tSC
}

Comme vous pouvez le voir, pour créer, il faut utiliser POST, pour mettre à jour, il faut utiliser PUT, pour supprimer, il faut utiliser DELETE et pour lancer une requête, il faut utiliser le verbe GET.

Étape 3 - Créez un client en Angular pour utiliser votre application de serveur FHIR.

J'ai créé une application angulaire en utilisant PrimeNG et en installant le paquet npm install --save @types/fhir. Ce paquet a tous les types FHIR mappé à TypeScript.

Classe de contrôleur en Angular :

import { Component, OnInit, ViewEncapsulation } from '@angular/core';
import { ActivatedRoute, Router } from '@angular/router';
import { Period, Questionnaire } from 'fhir/r4';
import { ConfirmationService, MessageService, SelectItem } from 'primeng/api';
import { QuestionnaireService } from './questionnaireservice';

const QUESTIONNAIREID = 'questionnaireId';

@Component({
    selector: 'app-questionnaire',
    templateUrl: './questionnaire.component.html',
    providers: [MessageService, ConfirmationService],
    styleUrls: ['./questionnaire.component.css'],
    encapsulation: ViewEncapsulation.None
})
export class QuestionnaireComponent implements OnInit {

    public questionnaire: Questionnaire;
    public questionnairies: Questionnaire[];
    public selectedQuestionnaire: Questionnaire;
    public questionnaireId: string;
    public sub: any;
    public publicationStatusList: SelectItem[];
    
    constructor(
        private questionnaireService: QuestionnaireService,
        private router: Router,
        private route: ActivatedRoute,
        private confirmationService: ConfirmationService,
        private messageService: MessageService){
            this.publicationStatusList = [
                {label: 'Draft', value: 'draft'},
                {label: 'Active', value: 'active'},
                {label: 'Retired', value: 'retired'},
                {label: 'Unknown', value: 'unknown'}
            ]
        }

    ngOnInit() {
        this.reset();
        this.listQuestionnaires();
        this.sub = this.route.params.subscribe(params => {

            this.questionnaireId = String(+params[QUESTIONNAIREID]);

            if (!Number.isNaN(this.questionnaireId)) {
                this.loadQuestionnaire(this.questionnaireId);
            }
        });
    }

    private loadQuestionnaire(questionnaireId) {
        this.questionnaireService.load(questionnaireId).subscribe(response => {
            this.questionnaire = response;
            this.selectedQuestionnaire = this.questionnaire;
            if(!response.effectivePeriod) {
                this.questionnaire.effectivePeriod = {};
            }
        }, error => {
            console.log(error);
            this.messageService.add({ severity: 'error', summary: 'Error', detail: 'Error on load questionnaire.' });
        });
    }


    public loadQuestions() {
        if(this.questionnaire && this.questionnaire.id) {
            this.router.navigate(['/question', this.questionnaire.id]);
        } else {
            this.messageService.add({ severity: 'warn', summary: 'Warning', detail: 'Choose a questionnaire.' });
        }
    }

    private listQuestionnaires() {
        this.questionnaireService.list().subscribe(response => {
            this.questionnairies = response;
            this.reset();
        }, error => {
            console.log(error);
            this.messageService.add({ severity: 'error', summary: 'Error', detail: 'Error on load the questionnaries.' });
        });
    }

    public onChangeQuestionnaire() {
        if (this.selectedQuestionnaire && !this.selectedQuestionnaire.id) {
            this.messageService.add({ severity: 'warn', summary: 'Warning', detail: 'Select a questionnaire.' });
        } else {
            if(this.selectedQuestionnaire && this.selectedQuestionnaire.id) {
                this.loadQuestionnaire(this.selectedQuestionnaire.id);
            }
        }
    }

    public reset() {
        this.questionnaire = {};
        this.questionnaire.effectivePeriod = {};
    }


    public save() {

        if(this.questionnaire.id && this.questionnaire.id != "") {
            this.questionnaireService.update(this.questionnaire).subscribe(
                (resp) => {
                    this.messageService.add({
                        severity: 'success',
                        summary: 'Success', detail: 'Questionnaire saved.'
                    });
                    this.listQuestionnaires()
                    this.loadQuestionnaire(this.questionnaire.id);
                },
                error => {
                    console.log(error);
                    this.messageService.add({
                        severity: 'error',
                        summary: 'Error', detail: 'Error on save the questionnaire.'
                    });
                }
            );
        } else {
            this.questionnaireService.save(this.questionnaire).subscribe(
                (resp) => {
                    this.messageService.add({
                        severity: 'success',
                        summary: 'Success', detail: 'Questionnaire saved.'
                    });
                    this.listQuestionnaires()
                    this.loadQuestionnaire(resp.id);
                },
                error => {
                    console.log(error);
                    this.messageService.add({
                        severity: 'error',
                        summary: 'Error', detail: 'Error on save the questionnaire.'
                    });
                }
            );
        }
        
    }
    
    public delete(id: string) {

        if (!this.questionnaire || !this.questionnaire.id) {
            this.messageService.add({ severity: 'warn', summary: 'Warning', detail: 'Select a questionnaire.' });
        } else {
            this.confirmationService.confirm({
                message: 'Do you confirm?',
                accept: () => {
                    this.questionnaireService.delete(id).subscribe(
                        () => {
                            this.messageService.add({ severity: 'success', summary: 'Success', detail: 'Questionnaire deleted.' });
                            this.listQuestionnaires();
                            this.reset();
                        },
                        error => {
                            console.log(error);
                            this.messageService.add({ severity: 'error', summary: 'Error', detail: 'Error on delete questionnaire.' });
                        }
                    );
                }
            });
        }
    }
   
}

Fichier HTML Angular

Name
Title
Date
Status
Publisher
Start Period
End Period
Description

Classe de Service Angular

import { Injectable } from '@angular/core';
import { HttpClient, HttpHeaders } from '@angular/common/http';
import { Observable } from 'rxjs';
import { environment } from 'src/environments/environment';
import { take } from 'rxjs/operators';
import { Questionnaire } from 'fhir/r4';

@Injectable({
  providedIn: 'root'
})
export class QuestionnaireService {

  private url = environment.host2 + 'questionnaire';

  constructor(private http: HttpClient) { }

  public save(Questionnaire: Questionnaire): Observable {
    return this.http.post(this.url, Questionnaire).pipe(take(1));
  }

  public update(Questionnaire: Questionnaire): Observable {
    return this.http.put(`${this.url}/${Questionnaire.id}`, Questionnaire).pipe(take(1));
  }

  public load(id: string): Observable {
    return this.http.get(`${this.url}/${id}`).pipe(take(1));
  }

  public delete(id: string): Observable {
    return this.http.delete(`${this.url}/${id}`).pipe(take(1));
  }

  public list(): Observable {
    return this.http.get(this.url).pipe(take(1));
  }

}

Step 4 - Application in action

1. Aller à l'application https://openexchange.intersystems.com/package/FHIR-Questionnaires.

2. Clone/git dépose le dépôt dans n'importe quel répertoire local.

$ git clone https://github.com/yurimarx/fhir-questions.git

3. Ouvrir le terminal dans ce répertoire et exécutez :

$ docker-compose up -d

4. Ouvrir l'application web : http://localhost:52773/fhirquestions/index.html

Voici quelques illustrations :

Bonjour aux développeurs d'InterSystems !

Récemment, j'ai mis à jour le modèle FHIR dev template afin qu'il publie maintenant un paquet IPM fhir-server permettant de faire de la configuration du serveur FHIR d'InterSystems une procédure manuelle, automatique ou programmatique triviale d'une seule commande.

Découvrez ci-dessous comment vous pouvez en bénéficier.

TLDR

USER>zpm "install fhir-server"

Tous les détails ci-dessous.

Configuration du serveur InterSystems FHIR sans IPM 

Bien sûr, vous pouvez configurer le serveur InterSystems FHIR sans utiliser le gestionnaire de paquets IPM. Vous avez le choix :

1. Vous pouvez configurer un serveur FHIR en nuage et l'essayer pendant plusieurs jours en suivant les instructions suivantes. Il s'agira d'un serveur FHIR d'InterSystems dans le nuage AWS.

2. Vous pouvez configurer le serveur FHIR d'InterSystems en exécutant InterSystems IRIS for Health en suivant les étapes suivantes.

3. Vous pouvez également cloner git le dépôt de ce modèle et l'exécuter dans un répertoire cloné :

$ docker-compose up -d

pour que le serveur FHIR d'InterSystems fonctionne sur votre ordinateur portable.

Ce que je suggère dans l'article est le point 2 où vous pouvez sauter toutes les étapes manuelles et avoir le serveur FHIR en marche sur un ordinateur portable IRIS soit dans Docker soit dans l'OS hôte.

**Configuration du serveur FHIR avec IPM **

AVIS DE NON-RESPONSABILITÉ ! Les étapes décrites ci-dessous se rapportent à une instance d'IRIS for Health récemment installée ou à une utilisation avec des images Docker. Le paquet crée un nouvel espace de noms et une nouvelle application Web, ce qui pourrait nuire à la configuration précédente.

IPM est l'acronyme anglais pour InterSystems Package manager, précédemment connu sous le nom de ZPM. Vérifiez que [IPM-client est installé] (https://openexchange.intersystems.com/package/InterSystems-Package-Manager-1). Vous pouvez le vérifier en exécutant la commande zpm dans le terminal IRIS et en obtenant le résultat suivant :

IRISAPP>zpm     

=============================================================================
|| Welcome to the Package Manager Shell (ZPM).                             ||
|| Enter q/quit to exit the shell. Enter ?/help to view available commands ||
=============================================================================
zpm:IRISAPP>

Vous aurez besoin d'IRIS for Health pour les versions 2022.x et plus récentes.  

Comment exécuter iris for health sur votre ordinateur portable ?

Exécution d'une opération hôte

Téléchargez la version la plus récente d'IRIS for Health sur le [site d'évaluation d'InterSystems] (https://evaluation.intersystems.com/Eval/index.html) qui correspond à votre plate-forme (Windows, Mac, Linux) et installez-la. Installez ZPM. Voici un exemple :

USER>zn "%SYS" d ##class(Security.SSLConfigs).Create("z") s r=##class(%Net.HttpRequest).%New(),r.Server="pm.community.intersystems.com",r.SSLConfiguration="z" d r.Get("/packages/zpm/latest/installer"),$system.OBJ.LoadStream(r.HttpResponse.Data,"c")

Exécution d'une version docker

Appelez votre terminal pour le lancement :

docker run --rm --name iris4h -d --publish 9091:1972 --publish 9092:52773 intersystemsdc/irishealth-community

Puis lancez le terminal :

docker exec -it iris4h iris session IRIS

Installation du serveur FHIR

Après avoir fait fonctionner IRIS sur l'hôte ou simplement dans le terminal IRIS :

USER>zpm "install fhir-server"

Cela installera le serveur FHIR dans l'espace de noms FHIRSERVER avec des paramètres :

Set appKey = "/fhir/r4"
Set strategyClass = "HS.FHIRServer.Storage.Json.InteractionsStrategy"
set metadataPackages = $lb("hl7.fhir.r4.core@4.0.1")

Set metadataConfigKey = "HL7v40"

L'API REST FHIR sera disponible ici : http://yourserver/fhir/r4.

Il ajoutera également quelques données synthétiques.

Comment comprendre que le serveur fonctionne ?

Pour tester la version hôte :

http://localhost:52773/fhir/r4/metadata

Pour tester la version docker :

http://localhost:9092/fhir/r4/metadata

zpm installe également l'interface utilisateur simple qui est disponible à l'adresse suivante : yourserver/fhirUI/FHIRAppDemo.html.

Et vous verrez apparaître quelque chose comme ceci (avec le patient id=1 entré) :

Comment ça marche ?

En fait, vous pouvez observer ce qui est installé avec ce module ZPM dans le scénario suivant following module.xml. On peut voir qu'il importe du code, installe l'application frontale de démonstration fhirUI, exécute le script de post-installation, qui appelle la méthode suivante. Le script de la méthode effectue la configuration du serveur FHIR.

Installation programmatique du serveur FHIR

Vous pouvez également l'installer de manière programmatique en utilisant la commande suivante :

set sc=$zpm("install fhir-server")

Joyeux codage FHIR !

Voulez-vous être sûr que vos transformations de données fonctionnent comme prévu avec une seule commande ? Et que diriez-vous d'écrire des tests unitaires pour vos transformations de données de manière simple et rapide ? 

Les transformations de données sont généralement très présentes lorsqu'on parle d'interopérabilité. Ces transformations de données sont utilisées pour convertir les données entre différents systèmes ou applications dans votre code, et elles ont donc un rôle très important à jouer.

Les stratégies de test

Après avoir examiné le concept de la [Pyramide de tests] (https://martinfowler.com/bliki/TestPyramid.html) et certains [articles] (https://medium.com/@timothy.cochran/test-pyramid-the-key-to-good-automated-test-strategy-9f3d7e3c02d5) à ce sujet, on peut se faire une idée rapide du fait qu'il est préférable de disposer d'une base solide de tests automatisés de bas niveau moins coûteux que de tester uniquement l'interface utilisateur.

Dans un contexte d'interopérabilité, j'ai constaté dans plusieurs projets qu'il vaut vraiment la peine d'investir un peu d'effort dans l'écriture de tests unitaires de transformation de données, surtout lorsque nous traitons différents scénarios (par exemple HL7, messages personnalisés, etc.). Cela nous permettra d'être sûrs que notre logique de transformation de données fonctionne comme prévu après l'introduction de nouveaux changements. Même après la résolution d'un problème avec une transformation de données, nous pouvons facilement créer un nouveau test avec le message qui a causé le problème, de sorte que nous sommes sûrs de ne pas obtenir la même erreur à l'avenir.  

Un petit assistant qui utilise le cadre %UnitTest

Pour vous aider à écrire et à exécuter des tests de transformation de données, je partage un exemple qui utilise le cadre [IRIS %UnitTest framework] (https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=TUNT_preface). L'objectif est de vous permettre de définir des ensembles différents de messages d'entrée et de messages de sortie correspondants prévus pour chaque transformation de données à tester, en tant que fichiers texte externes.

Supposons que vous vouliez créer des tests unitaires pour une transformation de données appelée Sample.Health.a31ToPatient, alors vous devez procéder comme suit :

1. Créez une nouvelle classe étendue DataTransformTestCase. Définissez le paramètre <TestDirectory> comme le répertoire dans lequel vous allez stocker vos tests de transformation de données.

2. Dans votre <TestDirectory>, créez un sous-répertoire appelé  Sample.Health.a31ToPatient. Ce sous-répertoire stockera les ensembles d'entrées et de sorties attendues que vous souhaitez tester dans la transformation de données.

3. Dans le sous-répertoire Sample.Health.a31ToPatient is faut ajouter les messages d'entrée et la sortie attendue comme .in.txt and .out.txt.

4. Lancez vos tests ! Vous pouvez voir les résultats dans le portail %UnitTest Framework dans IRIS. Si vous obtenez une erreur, le fichier *.gen.txt sera généré, afin que vous puissiez comparer la sortie réelle à la sortie attendue et voir ce qui ne va pas.   

Lancez l'exemple vous-même !

Vous pouvez télécharger, lancer l'exemple et lire plus de détails dans Open Exchange.

Les systèmes EHR (Electronic Health Record) sont modélisés dans un format/structure propriétaire et ne sont pas basés sur des modèles du marché tels que FHIR ou HL7. Certains de ces systèmes peuvent interopérer des données dans un format propriétaire pour FHIR et d'autres modèles de marché, mais pas tous. InterSystems dispose de deux plateformes capables d'interopérer des formats propriétaires pour ceux du marché : InterSystems HealthShare Connect et InterSystems IRIS for Health. La fonctionnalité de transformation (DTL - Data Transformation Language) de ces plateformes peut recevoir des données dans n'importe quel format, structure ou canal de communication (CSV, JSON, XML, et autres via FTP, File, HTTP, etc.) et les transformer directement en formats du marché (FHIR, CDA, HL7, etc.). Cependant, InterSystems dispose d'un format intermédiaire appelé SDA (Summary Document Architecture) qui est utilisé par ces plateformes pour générer sans effort des FHIR STU, R3, R4, HL7v2, HL7v3, etc. En outre, lorsqu'elles sont au format SDA, les données de santé peuvent être conservées dans le RCU HealthShare. Ainsi, le format propriétaire/personnel est d'abord transformé en SDA, puis les données peuvent être automatiquement converties dans n'importe quel format du marché, ainsi que sauvegardées dans HealthShare. Dans cet article, nous allons vous montrer comment transformer des données propriétaires/personnalisées en SDA à l'aide d'IRIS for Health. L'exemple de données que nous avons utilisé a été généré par le projet de génération de données en masse SYNTHEA (https://synthea.mitre.org/downloads). Nous allons convertir 1000 patients d'un fichier CSV en SDA, en utilisant les fonctions d'interopérabilité d'IRIS for Health.

Application de soutien aux articles – custom2sda

Installation de l'application d'exemple qui sera utilisée avec cet article en suivant les instructions :

Si vous voulez installer en utilisant ZPM :

1. Ouvrez le Namespace IRIS avec l'interopérabilité activée.
2. Ouvrez le Terminal et appelez : USER>zpm "install custom2sda"

Si vous voulez installer en utilisant Docker :

1. Clonez Git et tirez le repo dans n'importe quel répertoire local :

$ git clone https://github.com/yurimarx/custom2sda.git

2. Ouvrez le terminal dans ce répertoire et exécutez :

$ docker-compose build

3. Lancez le conteneur IRIS avec votre projet :

$ docker-compose up -d

4. Ouvrez la production (http://localhost:52775/csp/healthshare/user/EnsPortal.ProductionConfig.zen?PRODUCTION=customsda.CustomToSDAProduction) et la lancez. (utilizateur _SYSTEM et le mot de passe SYS). Elle lira le fichier patients.csv et le convertira en SDA.

Créer une carte d'enregistrement CSV pour obtenir les données personnalisées/propriétaires

Dans l'étape précédente, vous avez exécuté la production qui a lu le fichier patients.csv et l'a transformé en SDA. Maintenant nous allons faire la même chose avec patients2.csv. Nous pourrions profiter de la production actuelle, mais je voudrais montrer comment créer tout à partir de zéro. Donc, arrêtez cette production, et faisons ce qui suit.

1.    Allez au portail de gestion (http://localhost:52775/csp/sys/%25CSP.Portal.Home.zen?$NAMESPACE=USER, assurez-vous que vous êtes dans l'espace de noms de l'utilisateur).
2.    Créer un CSV Mapper pour le fichier patients2.csv. Interopérabilité > Build > CSV Record Wizard (Assistant d'enregistrement CSV) :

Remarque : sélectionnez CRLF pour Record Terminator (terminateur d'enregistrement)

3.    Cliquez sur "Create RecordMap" pour ouvrir l'interface utilisateur de Record Mapper et modifiez le nom de la classe cible en customsda.Patients2RecordMap.Record :

4.    Sélectionnez BIRTHPLACE et définissez MAXLEN=200 dans le champ Paramètres du type de données. Par défaut, tous les champs %String contiennent 50 caractères, mais BIRTHPLACE et ADDRESS ont besoin de plus d'espace. Faites de même pour le champ ADDRESS :

5.    Cliquez sur le bouton "Save" (Enregistrer) et sur le bouton "Generate" (Générer). Acceptez les options par défaut et cliquez sur Ok pour générer les classes RecordMap.

6.    Cliquez sur "Interoperability" (Interopérabilité) pour passer aux tâches suivantes:

Créer la transformation de données de Custom à SDA

Il est temps d'utiliser le DTL pour construire visuellement la carte de transformation de Custom à SDA.

1.    Cliquez sur Interoperability" > Build > Data Transformations (transformation de données) > Go :

2.    Vous pouvez voir le Data Transformation Builder ici. Cliquez sur le bouton "New" (Nouveau) :

3.    Dans Data Transformation Wizard (Assistant de transformation des données), changez le Package en customsda, et le Name en PatientDTL2 :

4.    À ce stade, nous allons définir la classe de la source. Cliquez sur l'icône de la loupe près du champ "Source Class" :

5.    Cliquez sur Message Classes > customsda > Patients2RecordMap > Record :

6.    À ce stade, la classe "Source Class" devrait ressembler à ceci :

7.    Dans la section Target Type, sélectionnez XML et acceptez Target Class avec la valeur EnsLib.EDI.XML.Document :

8.    Sélectionnez l'icône de la loupe près du Type de document cible et cliquez sur Document XML > SDA3_schema > Container :

Remarque 1 : Le conteneur est l'élément racine de tous les éléments SDA, comme Patient.

Remarque 2 : pour que SDA3_schema soit disponible, les actions suivantes sont nécessaires :
Copier SDA3_schema.xsd dans votre système de fichiers local :

Importez le schéma XSD de SDA3 :

9.    Maintenant, lorsque la source et la cible sont configurées, cliquez sur le bouton OK :

10.    Les champs source et cible sont maintenant disponibles pour le mappage visuel :

11.    Pour créer une transformation, vous devez faire glisser le cercle du champ source et le déposer dans la flèche du champ cible, ligne par ligne.

12.    Dans la section Actions, vous pouvez voir les résultats obtenus :

13.    Après avoir mappé tous les champs, votre liste d'actions ressemblera à ceci :

Remarque : pour les propriétés avec (), vous devez définir l'index car ces propriétés peuvent avoir plus d'un élément. Dans cet exemple, nous n'avons qu'une seule adresse, donc target.{Patient.Addresses(1)….} est configuré avec 1.

14.    Cliquez sur le bouton "Save" (enregistrer) et sur le bouton "Compile" (compiler).

15.    Enfin, cliquez sur le raccourci "Interoperability" pour accéder au menu d'Interoperability :

Créer la production de l'interopérabilité (Interoperability Production), le dernier artefact pour compléter notre travail !

Les productions sont les mécanismes utilisés pour automatiser efficacement les flux d'intégration. Il est temps de créer notre production pour transformer les données des patients du fichier patients2.csv en SDA.

1.    Cliquez sur Interoperability > List > Productions :

2.    Cliquez sur le bouton "New" :

3.    Définissez Customsda sur Package, Patients2Production sur Production Name et Production Type sur Generic. Cliquez sur Ok :

4.    Nous avons maintenant la configuration de production :

5.    Cliquez sur le bouton "Plus" près de "Services" :

Remarque : Les services sont les composants utilisés par les productions pour obtenir des données sources.

6.    Configurez la classe "Service Class" avec la valeur EnsLib.RecordMap.Service.FileService, et le nom du service "Service Name" comme PatientCSVService, et cochez "Enable Now" :

7.    Sélectionnez PatientCSVService et configurez l'onglet Paramètres avec les valeurs

  et cliquez sur "Apply" (appliquer):
●    Chemin du fichier : /opt/user/data/
●    Spécification du fichier : patients2.csv
●    Carte d'enregistrement : Patients2RecordMap
●    Noms des configurations cibles : PatientProcess

8.    Cliquez sur le bouton "Plus" situé près des Opérations :

Remarque : Les opérations sont des composants de production utilisés pour écrire/persister des données sur une cible (bases de données, systèmes, API, services Web, FTP, fichier, etc.)

9.    Configurez l'Opération avec les valeurs suivantes :
●    Classe d'Opération : EnsLib.EDI.XML.Operation.FileOperation
●    Nom d'Opération : PatientSDAOperation
●    Cochez Enable Now

10.    Sélectionnez PatientSDAOperation et définissez la valeur /opt/user/data/ comme chemin de fichier, puis cliquez sur le bouton "Apply" :

11.    Cliquez sur le bouton "Plus" à côté de "Processes" (Processus) :

Remarque : les processus sont le composant de production permettant de coordonner le flux de données.

12.    Configurez le processus métier avec les valeurs suivantes :
●    Classe du processus métier: EnsLib.MsgRouter.RoutingEngine
●    Nom de règle de routage : customsda.PatientRouterRule2
●    Nom du processus métier: PatientProcess
●    Cochez Enable Now

13.    Jusqu'à présent, nous avons créé tous les composants :

14.    Sélectionnez PatientProcess et allez à l'onglet "Settings" > icône de loupe près de "Business Rule Name" (Nom de règle de routage) :

15.    Maintenant, nous allons configurer la règle de routage "Routing Rule" dans l'éditeur de règles "Rule Editor" :

16.    Faites un double-clic sur le composant de contrainte et configurez la Source avec PatientCSVService et la Classe de message avec customsda.Patients2RecordMap.Record :

17.    Actuellement, nous avons configuré la source et la cible :

18.    Sélectionnez le composant de règle et cliquez sur le bouton "Green Plus" :

19.    Sélectionnez Send (Envoyer) pour créer le composant When (Quand) :

20.    Sélectionnez le composant "When", cliquez sur le bouton "Green Plus", puis sélectionnez le composant "Send" :

21.    Vous êtes censé voir l'image affichée ci-dessous sur votre écran :

22.    Faites un double-clic sur le composant cible et définissez les éléments de configuration sur PatientSDAOperation, puis cliquez sur le bouton OK :

23.    Faites un double-clic sur le composant de transformation et définissez "Transforms" sur customsda.PatientDTL2, puis cliquez sur OK :

24.    Maintenant, vous avez vos définitions de règles prêtes :

25.    Cliquez sur le bouton "Save" et allez au menu "Interoperability" :

26.    Allez à Interoperability > List > Productions :

27.    Sélectionnez Patients2Production et cliquez sur le bouton "Open" :

28.    Nous allons lancer notre nouvelle production ! Cliquez sur le bouton "Start" :

29.    Sélectionnez PatentProcess et allez à l'onglet "Messages" pour voir les résultats (messages) :

30.    Cliquez sur un message pour voir un diagramme de séquence "Sequence Diagram" avec les résultats de la transformation :

Comme vous pouvez le constater, il s'agit d'un processus de glisser-déposer facile et entièrement visuel, qui transforme les messages personnalisés en SDA ou en d'autres formats. Pour en savoir plus, consultez les liens ci-dessous :

1.    Création d'intégrations FHIR de base avec InterSystems IRIS for Health : https://learning.intersystems.com/course/view.php?id=1959&ssoPass=1
2.    Découvrez HealthShare pour les développeurs et les intégrateurs de systèmes : https://learning.intersystems.com/course/view.php?id=26&ssoPass=1
3.    Création d'intégrations métier avec InterSystems IRIS https://learning.intersystems.com/course/view.php?id=1437&ssoPass=1
4.    Création d'intégrations de base HL7 avec InterSystems: https://learning.intersystems.com/course/view.php?id=1350&ssoPass=1