Bonjour,

Table des matières

1. Objectif de l'article
2. Les conteneurs : définition et pertinence dans le cadre d'IRIS
    2.1 Les conteneurs et les images en quelques mots
    2.2 Avantages des conteneurs pour les développeurs
    2.3 Pourquoi IRIS fonctionne bien avec Docker
3. Conditions préalables
4. Installation de l'image InterSystems IRIS
    4.1 Utilisation de Docker Hub
    4.2 Extraction de l'image
5. Exécution de l'image InterSystems IRIS
    5.1 Démarrage d'un conteneur IRIS
    5.2 Vérification de l'état des conteneurs
    5.3 Exécution de code dans le terminal conteneur
    5.4 Accès au portail de gestion IRIS
    5.5 Connexion du conteneur à VS Code
    5.6 Arrêt ou suppression du conteneur
    5.7 Configuration d'un mot de passe spécifique avec un montage de type bind
    5.8 Utilisation de volumes %SYS durables
     5.8.1 Contenu stocké sous %SYS durable
     5.8.2 Comment activer %SYS durable
6. Utilisation de Docker Compose
    6.1 Exemple d'utilisation de l'outil Docker Compose
    6.2 Exécution de Docker Compose
7. Utilisation d'un fichier Dockerfile pour l'exécution d'un code source personnalisé
    7.1 Exemple de fichier Dockerfile
    7.2 Exemple de Docker Compose
    7.3 Compréhension des couches, du balisage des images et de la différence entre le temps de compilation et le temps d'exécution
    7.4 Code source et script d'initialisation
    7.5 Création de l'image avec le fichier Dockerfile
    7.6 Exécution d'instructions dans le terminal IRIS conteneurisé
8. Conclusion et suite

Cet article présente une introduction à la programmation Python dans le contexte d'IRIS.

Avant toute chose, je vais aborder un sujet important : Fonctionnement de Python. Cela vous aidera à comprendre certains problèmes et certaines limites que vous pourriez rencontrer lorsque vous utilisez Python dans IRIS.

Tous les articles et exemples sont disponibles dans ce dépôt git: iris-python-article

Fonctionnement de Python

Langage interprété

Python est un langage interprété, ce qui signifie que le code est exécuté ligne par ligne lors de l'exécution, même lorsque vous importez un script.

Je sais que ceux qui découvrent VS Code, Git, Docker, FHIR et d'autres outils peuvent parfois avoir des difficultés à configurer l'environnement. J'ai donc décidé de rédiger un article qui explique étape par étape l'ensemble du processus de configuration afin de faciliter les premiers pas.

Je vous serais très reconnaissant de bien vouloir laisser un commentaire à la fin de cet article pour me faire savoir si les instructions étaient claires, s'il manquait quelque chose ou si vous avez d'autres suggestions qui pourraient être utiles.

La configuration comprend:

✅ VS Code – Éditeur de code
✅ Git – Système de contrôle de version
✅ Docker – Lancement d'une instance de la communauté IRIS for Health
✅ Extension VS Code REST Client – Pour l'exécution de requêtes API FHIR
✅ Python – Pour l'écriture de scripts basés sur FHIR
✅ Jupyter Notebooks – Pour les tâches liées à l'IA et au FHIR

Avant de commencer: Vérifiez que vous disposiez des privilèges d'administrateur sur votre système.

Outre la lecture du guide, vous pouvez également suivre les étapes décrites dans les vidéos:

Pour Windows

<iframe allowfullscreen="" frameborder="0" height="360" src="https://www.youtube.com/embed/IyvuHbxCwCY" width="640"></iframe>

Cela fait un moment que je n'ai pas publié d'article sur Embedded Git sur la Communauté des développeurs, et j'aimerais faire le point sur l'énorme quantité de travail que nous avons accompli cette année et sur la direction que nous allons prendre ensuite.

Contexte

Si vous créez des solutions sur IRIS et que vous souhaitez utiliser Git, c'est parfait ! Utilisez simplement VSCode avec un dépôt git local et transmettez vos modifications sur le serveur : c'est aussi simple que cela.

Mais que se passe-t-il si :

L'équipe de développement d'extensions VS Code recherche des bêta-testeurs pour fournir des commentaires sur une refonte proposée du flux de travail d'édition côté client. La liste complète des modifications se trouve dans la description de la GitHub pull request. Voici les points saillants :

Bienvenue dans le prochain chapitre de ma série CI/CD, où nous discutons des approches possibles vers le développement de logiciels avec les technologies InterSystems et GitLab. Aujourd'hui, nous reprenons la discussion sur l'interopérabilité, et plus particulièrement sur le suivi de vos déploiements d'interopérabilité. Si vous ne l'avez pas encore fait, configurez Alerte pour toutes vos productions d'interopérabilité afin de recevoir des alertes sur les erreurs et l'état de la production dans son ensemble.

Le paramètre de délais d'inactivité Inactivity Timeout est commun pour tous les hôtes métier d'interopérabilité (Interoperability Business Hosts). Un hôte métier possède le statut Inactif lorsqu'il n'a reçu aucun message pendant le nombre de secondes spécifié dans le champ de délai d'inactivité " Inactivity Timeout ". La fonction de surveillance de la production " Monitor Service " examine périodiquement l'état des services et des opérations métier au sein de la production et marque les éléments comme étant inactifs s'ils n'ont rien fait pendant le délai d'inactivité. La valeur par défaut est 0 (zéro). Si ce paramètre est 0, l'hôte métier ne sera jamais marqué comme Inactif, quelle que soit la durée de son inactivité.

Ce paramètre est extrêmement utile, car il génère des alertes qui, associées aux alertes configurées, permettent de signaler les problèmes de production en temps réel. Le fait que l'élément "Business Host" soit inactif signifie qu'il peut y avoir des problèmes de production, d'intégration ou de connectivité réseau qui nécessitent d'être examinés. Cependant, le Business Host ne peut avoir qu'un seul paramètre constant pour le délai d'inactivité, ce qui peut générer des alertes inutiles pendant les périodes connues de faible trafic : nuits, week-ends, vacances, etc. Dans cet article, je décrirai plusieurs approches pour la mise en œuvre dynamique des délais d'inactivité (Inactivity Timeout). Bien que je fournisse un exemple fonctionnel (qui fonctionne actuellement en production pour l'un de nos clients), cet article est plutôt un guide pour votre propre mise en œuvre dynamique des délais d'inactivité, donc ne considérez pas la solution proposée comme la seule alternative.

Bienvenue dans le prochain chapitre de ma série CI/CD, où nous discutons des approches possibles vers le développement de logiciels avec les technologies InterSystems et GitLab.

Aujourd'hui, parlons d'interopérabilité.

Problème

Lorsque vous avez une production d'interopérabilité active, vous avez deux flux de processus distincts : une production active qui traite les messages et un flux de processus CI/CD qui met à jour le code, la configuration de la production et les paramètres par défaut du système.

De toute évidence, le processus CI/CD affecte l'interopérabilité. Mais il y a des questions :

• Que se passe-t-il exactement lors d'une mise à jour ?
• Que devons-nous faire pour minimiser ou éliminer les temps d'arrêt de la production lors d'une mise à jour ?

Dans cette série d'articles, j'aimerais présenter et discuter de plusieurs approches possibles pour le développement de logiciels avec les technologies d'InterSystems et GitLab. J'aborderai des sujets tels que:

• Git 101
• Flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD
• Pourquoi des conteneurs?
• Infrastructure de conteneurs
• CD utilisant des conteneurs

Dans cette série d'articles, j'aimerais présenter et discuter de plusieurs approches possibles pour le développement de logiciels avec les technologies d'InterSystems et GitLab. J'aborderai des sujets tels que:

• Git 101
• Flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD

Dans cette série d'articles, j'aimerais présenter et discuter de plusieurs approches possibles pour le développement de logiciels avec les technologies d'InterSystems et GitLab. J'aborderai des sujets tels que:

• Git 101
• Flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD

Dans cette série d'articles, j'aimerais présenter et discuter de plusieurs approches possibles pour le développement de logiciels avec les technologies d'InterSystems et GitLab. J'aborderai des sujets tels que:

• Git 101
• Le flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD

Tout le monde dispose d'un environnement de test.

Certains ont la chance de disposer d'un environnement totalement séparé pour la production.

-- Inconnu

.

Dans cette série d'articles, j'aimerais présenter et discuter de plusieurs approches possibles pour le développement de logiciels avec les technologies d'InterSystems et GitLab. J'aborderai des sujets tels que:

• Git 101
• Git flow (processus de développement)
• Installation de GitLab
• Flux de travail GitLab WorkFlow
• GitLab CI/CD
• CI/CD avec des conteneurs

Bonjour à la communauté,
Dans cet article, je vais présenter mon application iris-mlm-explainer

Il s'agit d'un modèle de base pour un environnement de développement permettant de travailler avec ObjectScript dans InterSystems IRIS. Il vous aide à éditer, compiler, commettre/pousser, déboguer et tester votre code ObjectScript. Il aide également à conditionner votre application en tant que module installable avec IPM. Le modèle est compatible avec Embedded Python.

Description

Ce référentiel fournit un environnement de développement prêt à l'emploi pour coder de manière productive avec ObjectScript d'InterSystems. Ce modèle: