Recherche

Salut la communauté, Rejoignez-nous pour notre atelier et nos démonstrations pendant Supply Chain Event 2022 ! 📅 Dates : 15 - 16 novembre Démonstrations d'InterSystems IRIS for Supply Chain. Choisissez celles qui vous intéressent. Atelier InterSystems - Talan - Voies Navigables de France 📄 Sujet : Comment construire une tour de contrôle nouvelle génération à la fois collaborative, résiliente, prescriptive et descriptive ? 🗓️ Date : 15 novembre⏱ Heure : 14h00 📍 Lieu : salle 3 Au programme : 14h00 - 14h15La Supply Chain au coeur d'une pluralité d'enjeux géopolitiques, politiques et environnementauxDavid Haverlant, Directeur Senior Retail / CPG/ Luxe, Talan 14h15 - 14h30Comment évoluer vers un modèle de pilotage par la donnée ?Benoit Hollebecq, Responsable Transformation Numérique, VNF 14h30 - 14h45 : Comment combiner analyse prédictive et prescriptive ? Venez le découvrir au travers d'une démonstration InterSystems IRIS for Supply Chain@Sylvain.Guilbaud, Expert InterSystems IRIS Data Platform 👉 Inscrivez-vous ici 👈 Démonstrations sur notre stand 🗓️ Date : 15 novembre⏱ Heure : 11h30 📍 Intervenant : @Sylvain.Guilbaud, Expert InterSystems IRIS Data platform, InterSystems France * Comment améliorer la visibilité de l’état de la production manufacturière ?* Comment régler les problèmes opérationnels de manière proactive 🗓️ Date : 15 novembre⏱ Heure : 16h30 📍 Intervenant : @Sylvain.Guilbaud, Expert InterSystems IRIS Data platform, InterSystems France * Comment capturer vos données opérationnelles en continu et en temps réel provenant de l’ensemble de votre écosystème ?* Comment augmenter le degré d’automatisation de vos process grâce à l’intelligence artificielle et l’apprentissage automatique ? 🗓️ Date : 16 novembre⏱ Heure : 11h30 📍 Intervenant : @Sylvain.Guilbaud, Expert InterSystems IRIS Data platform, InterSystems France * Comment tirer parti de l’analyse prédictive et prescriptive pour passer d’un mode réactif à un mode proactive ?* Comment comprendre l’impact des signaux de votre écosystème sur votre chaîne d’approvisionnement ? 🗓️ Date : 16 novembre⏱ Heure : 14h45 📍 Intervenant : @Sylvain.Guilbaud, Expert InterSystems IRIS Data platform, InterSystems France * Comment bénéficiez d’une visibilité en temps réel des niveaux de stocks ?* Comment visualiser les indicateurs en temps réel ? Plus d'info ici. Inscrivez-vous pour le Supply Chain Event ici. Nous avons hâte de vous retrouver !

Je suis heureux d'annoncer une étape importante dans le cycle de vie du gestionnaire de packages ObjectScript, ZPM. Le gestionnaire de packages offre aux développeurs la possibilité de regrouper soigneusement le code ObjectScript, les paramètres de configuration du déploiement et les informations de version de manière pratique. Au cours des dernières années, il a considérablement évolué pour devenir une partie intégrante de nombreux workflows de développement. l s'est avéré si important qu'InterSystems a décidé de l'utiliser pour empaqueter nos propres composants, et cela nous a conduit à la décision de déplacer le référentiel GitHub de la communauté vers notre référentiel d'entreprise, et de le renommer InterSystems Package Manager (IPM). IPM sera toujours open source. Les membres de la communauté pourront examiner le code et soumettre des demandes d'extraction. Mais ce changement nous donne la possibilité d'assurer la sécurité du logiciel d'une manière que nous ne pourrions pas avec des non-employés pouvant apporter des modifications directement à la base de code. Et un niveau accru de sécurité et de confiance est essentiel avec un logiciel qui peut installer du code à côté de vos données. Alors, s'il vous plaît, célébrez la vie de ZPM avec moi, accueillez la naissance d'IPM et remerciez les contributeurs -- en particulier @Nikolay.Soloviev et @Dmitry.Maslennikov, qui a une fois de plus fait preuve d'une compréhension incroyable des besoins des développeurs, associée aux compétences et au dévouement pour créer un excellent logiciel ! --- https://github.com/intersystems/ipm

Bonjour aux développeurs d'InterSystems ! Récemment, j'ai mis à jour le modèle [FHIR dev template](https://openexchange.intersystems.com/package/iris-fhir-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](https://docs.intersystems.com/services/csp/docbook/DocBook.UI.Page.cls?KEY=FAS_intro#FAS_setup). 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](https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI.Page.cls?KEY=HXFHIR_SERVER_INSTALL). 3. Vous pouvez également cloner git [le dépôt de ce modèle](https://github.com/intersystems-community/iris-fhir-template) 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](https://openexchange.intersystems.com/package/InterSystems-Package-Manager-1), 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](https://github.com/intersystems-community/iris-fhir-template/blob/master/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](https://github.com/intersystems-community/iris-fhir-template/blob/master/src/fhirtemplate/Setup.cls). 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 !

Salut la communauté, Nous sommes heureux de vous inviter au prochain webinaire de lancement du concours d'outils de développement InterSystems. Dans ce webinaire, nous vous montrerons certains des principes généraux et des problèmes de résolution des problèmes liés à la santé des femmes, ainsi que de partager de bonnes idées pour votre inspiration. Date et heure : lundi, 23 janvier – 12H00 EST | 18H00 CET Intervenants : 🗣 @Raj.Singh5479, InterSystems Product Manager 🗣 @Dean.Andrews2971, InterSystems Head of Developer Relations 🗣 @Evgeny.Shvarov, InterSystems Developer Ecosystem Manager >> Inscrivez-vous ici <<

Salut les développeurs, Merci beaucoup de rester avec la communauté de développeurs d'InterSystems pour une année de plus ! Jour après jour, notre équipe essaie de le rendre meilleur et plus utile pour chacun de nos 12 000 + membres ! Nous aimerions savoir à quel point la communauté de développeurs vous est utile à ce stade. Veuillez prendre quelques instants pour nous dire ce que vous en pensez et ce qui pourrait être amélioré : 👉🏼 Enquête annuelle 2022 de la communauté de développeurs d'InterSystems 👈🏼 Remarque : L'enquête prendra moins de 5 minutes. Et vos commentaires sont également les bienvenus dans la section des commentaires de ce post. Nous sommes impatients de connaître vos opinions ! 😉

> La fonction en tant que service (FaaS) est une catégorie de services de cloud computing qui fournit une plate-forme permettant aux clients de développer, d'exécuter et de gérer des fonctionnalités d'application sans la complexité de la construction et de la maintenance de l'infrastructure généralement associée au développement et au lancement d'une application. Construire une application selon ce modèle est une façon de réaliser une architecture "sans serveur", et est généralement utilisé lors de la construction d'applications microservices.   > > > Wikipedia > FaaS est une approche extrêmement populaire pour exécuter des charges de travail dans le cloud, permettant aux développeurs de se concentrer sur l'écriture du code. Cet article vous montrera comment déployer les méthodes d'InterSystems IRIS selon l'approche FaaS. ## Installation de Kubernetes Tout d'abord, installez **Kubernetes 1.16**. Il y a beaucoup de guides disponibles donc je ne vais pas les copier ici, mais j'utilise [minicube](https://minikube.sigs.k8s.io/docs/handbook/config/). Avec minicube pour lancer kubernetes, il suffit d'exécuter la commande suivante : minikube start --kubernetes-version=v1.16.1 ##   ## Installation de kubeless Ensuite, nous allons installer [kubeless](https://github.com/vmware-archive/kubeless). kubeless est un environnement sans serveur natif de Kubernetes qui vous permet de déployer de petits morceaux de code sans vous soucier de la plomberie de l'infrastructure sous-jacente. Il exploite les ressources de Kubernetes pour fournir une mise à l'échelle automatique, un routage API, une surveillance, un dépannage, etc. kubectl create ns kubeless kubectl create -f https://github.com/kubeless/kubeless/releases/download/v1.0.8/kubeless-v1.0.8.yaml kubectl get pods -n kubeless La sortie devrait ressembler à ceci : > NAME READY STATUS RESTARTS AGE > kubeless-controller-manager-666ffb749-26vhh 3/3 Running 0 83s Vous devez également installer un client kubeless (sur la même instance que celle où vous avez kubectl). Vous pouvez l'obtenir [ici](https://github.com/vmware-archive/kubeless/releases). L'installation sur Linux est aussi simple : sudo install kubeless /usr/local/bin/kubeless   ## Test kubeless Tout d'abord, déployons une simple fonction Python pour vérifier le fonctionnement de kubeless. Create _test.py_: def hello(event, context): return event['data'] Pour en savoir plus sur l'environnement des fonctions, consultez [cette documentation](https://github.com/vmware-archive/kubeless/blob/master/docs/kubeless-functions.md). En général, les fonctions acceptent deux arguments - l'événement et le contexte avec les données suivantes : event: data: # Event data foo: "bar" # The data is parsed as JSON when required event-id: "2ebb072eb24264f55b3fff" # Event ID event-type: "application/json" # Event content type event-time: "2009-11-10 23:00:00 +0000 UTC" # Timestamp of the event source event-namespace: "kafkatriggers.kubeless.io" # Event emitter extensions: # Optional parameters request: ... # Reference to the request received response: ... # Reference to the response to send # (specific properties will depend on the function language) context: function-name: "pubsub-nodejs" timeout: "180" runtime: "nodejs6" memory-limit: "128M"    Maintenant nous pouvons déployer notre fonction hello en spécifiant notre fichier avec une fonction et un runtime : kubeless function deploy hello --runtime python3.7 --from-file test.py --handler test.hello kubeless function ls hello Et testons-les : kubeless function call hello --data 'Hello world!' Vous devriez recevoir _Hello World!_ comme réponse.   ## Ajout de la configuration IRIS Ensuite, nous devons ajouter un gestionnaire de fonction IRIS d'InterSystems, pour ce faire, ouvrez la configuration de kubeless pour modifier : kubeless get-server-config kubectl get -n kubeless configmaps -o yaml > configmaps.yaml kubectl edit -n kubeless configmaps Ajoutez cette entrée au tableau runtime-images et enregistrez : {"ID": "iris","depName": "","fileNameSuffix": ".cls","versions": [{"images": [{"image": "eduard93/kubeless-iris-runtime:latest","phase": "runtime"}],"name": "iris2022.1","version": "2022.1"}]} Relancez le contrôleur kubeless pour que les changements prennent effet. kubectl delete pod -n kubeless -l kubeless=controller   ## Construction et publication de la fonction IRIS CRD Maintenant, écrivons notre première fonction dans IRIS d'InterSystems : Class User.Test { ClassMethod hi(event, context) As %Status { if $isObject(event) { write event.Text + event.Text } else { write "HELLO FROM IRIS" } quit $$$OK } } Ensuite, nous devons construire une fonction CRD : Voici notre modèle :   function.yaml apiVersion: kubeless.io/v1beta1 kind: Function metadata:   name: !name!   namespace: default spec:   runtime: iris2022.1   timeout: "180"   handler: !handler!   deps: ""   function-content-type: text   deployment:     spec:       template:         spec:           securityContext:             runAsUser: 51773             runAsGroup: 51773   function: | Nous avons besoin de remplir le suivant : * _name_ : nom de la fonction (pour kubeless) * _handler_ : class.name_method (pour InterSystems IRIS) * _function body_ : ajouter à la fin (n'oubliez pas les tabulations !)   function_demo.yaml apiVersion: kubeless.io/v1beta1 kind: Function metadata: name: iris-demo namespace: default spec: runtime: iris2022.1 timeout: "180" handler: User_Test.hi deps: "" function-content-type: text deployment: spec: template: spec: securityContext: runAsUser: 51773 runAsGroup: 51773 function: | Class User.Test { ClassMethod hi(event, context) As %Status { if $isObject(event) { write event.Text + event.Text } else { write "HELLO FROM IRIS" } quit $$$OK } } Ceci peut être facilement automatisé. Sous Linux, exécutez : sed 's/!name!/iris-demo/; s/!handler!/User_Test.hi/' function.yaml > function_demo.yaml sed 's/^/ /' User.Test.cls >> function_demo.yaml Et sous Windows (PowerShell): Get-Content function.yaml | ForEach-Object { $_ -replace "!handler!", "User_Test.hi" -replace "!name!", "iris-demo" } | Set-Content function_demo.yaml " " + [string]((Get-Content User.Test.cls) -join "`r`n ") | Add-Content function_demo.yaml Maintenant nous devons publier notre CRD dans kubeless : kubectl apply -f function_demo.yaml   ## Test de la fonction IRIS Tout d'abord, vérifions que la fonction est déployée et disponible ( la première fois, cela peut prendre quelques minutes) : kubeless function ls Et maintenant, faites un appel : kubeless function call iris-demo --data '{"Text":123}' Si vous êtes sous Windows, appelez la fonction comme ceci (de même pour tous les autres appels avec des guillemets échappés) : kubeless function call iris-demo --data '{\"Text\":123}' De toute façon, la réponse devrait être _456_ puisque _123_ est un numéro.   ## L'accès HTTP kubeless offre également un accès HTTP. Pour le tester, utilisez la commande kubectl proxy : kubectl proxy -p 8081 Ensuite, envoyez cette requête en utilisant votre client API REST préféré : GET http://localhost:8081/api/v1/namespaces/default/services/iris-demo:http-function-port/proxy/ {"Text":111} Voici comment cela se présente dans Postman : .png)   Ensuite, il s'agit de le publier sur l'internet. Il y a deux approches. Il est préférable de configurer ingress comme décrit [ici](https://github.com/vmware-archive/kubeless/blob/master/docs/http-triggers.md). En outre, vous pouvez patcher le service de fonction : kubectl get svc kubectl patch svc iris-demo -p '{"spec": {"type": "LoadBalancer"}}' kubectl get svc   ## Nettoyage Pour supprimer une fonction déployée, faites un appel : kubectl delete -f function_demo.yaml   ## Conclusion Bien qu'il s'agisse sans aucun doute d'une preuve de concept et non d'une solution de production, cette approche démontre qu'il est possible d'exécuter des charges de travail IRIS d'InterSystems en utilisant l'approche FaaS sans serveur.   ## Liens * [Minicube](https://minikube.sigs.k8s.io/docs/handbook/config/) * [Kubeless](https://github.com/vmware-archive/kubeless) * [InterSystems IRIS runtime](https://github.com/eduard93/kubeless-iris-runtime)

Bonjour la communauté, Je suis heureux de partager avec vous la nouvelle que InterSystems IRIS est nommé «Exemplaire» et se positionne dans le haut du classement du Ventana Research Data Platforms Value Index 2023 ! Selon le nouveau rapport d'analystes, la plateforme de gestion de données InterSystems IRIS devance Microsoft, SAP, AWS et Google dans le classement général. Ventana Research Data Platforms Value Index 2023 fournit une vue indépendante et globale de la capacité de treize fournisseurs à proposer une combinaison de charges de travail opérationnelles et analytiques avec un seul ou plusieurs produits de plateforme de données. Dans le rapport, InterSystems IRIS se classe troisième dans l'ensemble, et deuxième dans les catégories « Expérience produit », « Facilité d'utilisation » et « Adaptabilité ». Matt Aslett, Vice-Président et Directeur de Recherche chez Ventana Research, a déclaré : En tant que plateforme de gestion de données basé sur le cloud, InterSystems IRIS peut réduire la nécessité de mettre en œuvre et d'intégrer plusieurs technologies, ce qui se traduit par moins de code, moins de ressources système et moins de maintenance. Je recommande aux organisations qui migrent vers le cloud et qui recherchent une plateforme pour fournir une vue cohérente, précise et en temps réel de leurs données d'entreprise d'évaluer InterSystems. Le succès d'InterSystems reflète sa capacité à fournir des capacités analytiques et opérationnelles natives dans un seul et même produit. La plateforme de gestion de données InterSystems IRIS offre des capacités intégrées de gestion de base de données haute performance, d'interopérabilité et d'analyse, et élimine la nécessité de copier les données d'une base opérationnelle vers une base analytique distincte. Pour voir le rapport, veuillez suivre le lien. C'est top !

Bonjur la Communauté! La date de cinqième épisode d'une serie "Les 30' InterSystems" est déjà connue ! 📅 Date : mardi 21 février 2023⏱ Heure : 13:00 Heure d'été d'Europe centrale⌛️ Durée : 30 minutes Pour le 5e web-épisode de la 3e saison des 30' InterSystems, nous vous présenterons la coordination des intervenants Ville-Hôpital et notamment : Quels services pour la médecine de ville ? Comment coordonner les patients, acteurs du social, sanitaire et médico-social ? Comment améliorer le suivi des patients à domicile ? Intervenants : 👩‍💻 @Florence.Cureau, Ingénieure Avant-Vente HealthShare👩‍💻 Hervé Rivière, Directeur Médical >> INSCRIVEZ-VOUS ICI << Marquez le calendrier! Nous avons hâte de vous voir là-bas!

Bonjur la Communauté! La date de 6ème épisode d'une serie "Les 30' InterSystems" est déjà connue ! 📅 Date : mardi 21 mars 2023⏱ Heure : 13:00 Heure d'été d'Europe centrale⌛️ Durée : 30 minutes Pour le 6e web-épisode de la 3e saison des 30' InterSystems, nous vous présenterons les évolutions réglementaires pour le PMSI 2023, ainsi que les évolutions sur les urgences, notamment les forfaits pédiatriques et régime des mines. Intervenants : 👩‍💻 Nicolas Vossaert, Spécialiste Produit Senior👩‍💻 Isabelle De Monteil, Spécialiste Produit >> INSCRIVEZ-VOUS ICI << Marquez le calendrier! Nous avons hâte de vous voir là-bas!

Salut la Communauté! Profitez de regarder la nouvelle vidéo sur le moyen de se connecter aux InterSystems Cloud Services à partir de votre application .NET à l'aide de l'InterSystems ADO.NET Managed Provider. 📺 Connexion aux InterSystems Cloud Services avec .NET Cette vidéo est doublée grâce à l'intelligence artificielle (IA). N'oubliez pas à partager vos réflexions et impressions dans des commentaires après avoir regardé cette vidéo ! Abonnez-vous à la chaîne Youtube d'InterSystems France pour plus de vidéos et restez à l'écoute !

Salut la Communauté! Profitez de regarder la nouvelle vidéo sur le moyen de se connecter aux InterSystems Cloud Services à partir de votre application Java à l'aide du pilote JDBC InterSystems. 📺 Connexion aux InterSystems Cloud Services avec Java Cette vidéo est doublée grâce à Bard, l'intelligence artificielle de Google (IA). N'oubliez pas à partager vos réflexions et impressions dans des commentaires après avoir regardé cette vidéo ! Abonnez-vous à la chaîne Youtube d'InterSystems France pour plus de vidéos et restez à l'écoute !

InterSystems annonce la disponibilité générale d'InterSystems IRIS, InterSystems IRIS for Health et HealthShare Health Connect 2025.1. La version 2025.1 de la plateforme de données InterSystems IRIS®, InterSystems IRIS® for HealthTM et HealthShare® Health Connect est désormais disponible. Il s'agit d'une version en maintenance prolongée. Points forts de la version Cette nouvelle version propose plusieurs nouvelles fonctionnalités et améliorations, notamment : 1. Fonctionnalités avancées de recherche vectorielle Un nouvel index ANN (Approximate Nearest Neighbor) basé sur disque accélère considérablement les requêtes de recherche vectorielle, générant des réponses en moins d'une seconde sur des millions de vecteurs. Pour en savoir plus, accédez à l'exercice suivant : Vectorisation et recherche de texte avec InterSystems SQL. 2. Business Intelligence améliorée Analyse automatique des dépendances dans la création et la synchronisation de cubes IRIS BI, garantissant la cohérence et l'intégrité des dépendances complexes des cubes. 3. Gestion SQL et des données améliorée Introduction de la syntaxe de pagination SQL standard (LIMIT... OFFSET..., OFFSET... FETCH...). Nouvelle commande LOAD SQL pour une importation groupée simplifiée des instructions DDL. Commandes ALTER TABLE améliorées pour une conversion fluide entre les présentations en lignes et en colonnes. 4. Opérations de base de données optimisées Taille des enregistrements de journal réduite pour une efficacité accrue. Compactage plus rapide des bases de données, notamment pour les bases de données contenant de nombreuses chaînes volumineuses. Automatisation accrue lors de l'ajout de nouvelles bases de données à un miroir. Nouvel utilitaire de ligne de commande pour les tâches de gestion ECP. 5. Conformité de sécurité renforcée Prise en charge des bibliothèques cryptographiques conformes aux normes FIPS 140-3. 6. Interface utilisateur d'interopérabilité modernisée Inscrivez-vous à une configuration de production et à un éditeur DTL repensés, avec intégration du contrôle de source, compatibilité VS Code, filtrage amélioré, affichages en panneaux fractionnés, et bien plus encore. Consultez cet article de la communauté des développeurs pour plus d'informations sur la manière de participer et de nous faire part de vos commentaires. 7. Fonctionnalités étendues pour le secteur de la santé Ingestion et planification FHIR en masse efficaces, incluant les contrôles d'intégrité et la gestion des ressources. Accès FHIR en masse et opérations de recherche FHIR optimisés. 8. Nouvelles fonctionnalités pour l'expérience développeur Prise en charge de Python intégré dans l'éditeur DTL, permettant aux développeurs expérimentés d'exploiter plus efficacement la plateforme InterSystems. Regardez la vidéo suivante pour en savoir plus : Utilisation d'Embedded Python intégré dans les éditeurs BPL et DTL. 9. Observabilité améliorée avec OpenTelemetry Introduction des fonctionnalités de traçage dans IRIS pour une observabilité détaillée des requêtes web et des performances des applications. N'hésitez pas à partager vos commentaires au sein de la communauté des développeurs afin que nous puissions développer ensemble un meilleur produit. Documentation Des détails sur toutes les fonctionnalités mises en avant sont disponibles via les liens ci-dessous : Documentation et notes de version d'InterSystems IRIS 2025.1. Documentation et notes de version d'InterSystems IRIS for Health 2025.1. Documentation et notes de version de Health Connect 2025.1. Consultez également la liste de contrôle des impacts de la mise à niveau pour un aperçu clair et compréhensible de tous les changements à prendre en compte lors de la mise à niveau vers cette version. Veuillez noter qu'InterSystems IRIS 2025.1 introduit un nouveau format de fichier journal, incompatible avec les versions précédentes et imposant donc certaines limitations aux configurations de miroirs mixtes. Consultez la documentation correspondante pour plus de détails. Programmes d'accès anticipé (PAE) De nombreux PAE sont disponibles dès maintenant. Consultez cette page et inscrivez-vous auprès des personnes intéressées. Télécharger le logiciel Comme d'habitude, les versions de maintenance étendue (MAE) sont fournies avec des packages d'installation classiques pour toutes les plateformes prises en charge, ainsi que des images de conteneurs au format Docker. Packages d'installation classiques Les packages d'installation sont disponibles sur la page InterSystems IRIS du WRC pour InterSystems IRIS et InterSystems IRIS for Health, ainsi que sur la page HealthShare du WRC pour Health Connect. Les kits sont également disponibles sur le site web des services d'évaluation. Disponibilité et informations sur les packages Cette version est fournie avec des packages d'installation classiques pour toutes les plateformes prises en charge, ainsi que des images de conteneurs au format Docker. Pour une liste complète, consultez le document « Plateformes prises en charge ». Le numéro de build de cette version de maintenance étendue est 2025.1.0.223.0. Les images de conteneurs sont disponibles sur l'InterSystems Container Registry. Les conteneurs sont étiquetés « 2025.1 » et « latest-em ».

Salut les développeurs, Nous aimerions vous inviter à participer à notre prochain concours dédié à la création des solutions d'IA/ML qui utilisent Cloud SQL pour travailler avec les données : 🏆 Concours InterSystems IRIS Cloud SQL et IntegratedML 🏆 Durée: du 3 avril au 23 avril 2023 Prix: $13,500! Le sujet 💡 Concours InterSystems IRIS Cloud SQL et IntegratedML 💡 Dans ce concours, nous nous attendons à voir des applications full-stack, frontend ou backend qui utilisent InterSystems IRIS Cloud SQL pour travailler avec des données et utiliseront éventuellement son option IntegratedML pour créer des solutions IA/ML. Votre application peut être une bibliothèque, un package, un outil ou toute solution SQL ou/et IA/ML qui utilise InterSystems IRIS SQL Cloud sur un backend. En gros, nous vous invitons à utiliser InterSystems IRIS dans ce concours en tant que moteur 100% SQL avec une option AutoML via l'offre IntegratedML. Ici, vous pouvez obtenir des informations sur le produit InterSystems IRIS Cloud SQL ainsi que sur la fonctionnalité IntegratedML. Exigences générales : Applications acceptées : nouvelles applications Open Exchange ou existantes, mais avec une amélioration significative. Notre équipe examinera toutes les candidatures avant de les approuver pour le concours. L'application doit fonctionner sur InterSystems IRIS Community Edition ou IRIS for Health Community Edition ou IRIS Advanced Analytics Community Edition. Types d'applications qui correspondent : UI-frameworks, IDE, gestion de base de données, surveillance, outils de déploiement, etc. L'application doit être Open Source et publiée sur GitHub. Le fichier README de l'application doit être en anglais, contenir les étapes d'installation et contenir la vidéo de démonstration ou/et une description du fonctionnement de l'application. Un développeur peut participer au concours avec un maximum de 3 applis. Prix du concours : 1. Nomination d'experts – les gagnants seront sélectionnés par l'équipe d'experts d'InterSystems : 🥇 1ère place - $5,000 🥈 2e place - $3,000 🥉 3e place - $1,500 🏅 4e place - $750 🏅 5e place - $500 🌟 6-10e places - $100 2. Lauréats de la communauté – les candidatures qui recevront le plus de votes au total : 🥇 1ère place - $750 🥈 2e place - $500 🥉 3e place - $250 ✨ Badges Global Masters pour tous les gagnants sont inclus ! Remarque : Si plusieurs participants obtiennent le même nombre de votes, ils sont tous considérés comme gagnants et le prix en argent est partagé entre les gagnants. Délais importants : 🛠 Phase de développement et d'enregistrement de l'application : 3 avril 2023 (00 h 00 HNE) : début du concours 16 avril 2023 (23 h 59 HNE) : date limite de soumission ✅ Période de vote : 17 avril 2023 (00 h 00 HNE) : début du vote. 23 avril 2023 (23 h 59 HNE) : fin des votes. Remarque : Les développeurs peuvent améliorer leurs applications tout au long de la période d'inscription et de vote. Qui peut participer ? Tout membre de la communauté de développeurs, à l'exception des employés d'InterSystems (sous-traitants ISC autorisés). Créer un compte ! 👥 Les développeurs peuvent s'associer pour créer une application collaborative. Autorisé de 2 à 5 développeurs dans une équipe. N'oubliez pas de mettre en surbrillance les membres de votre équipe dans le README de votre application - les profils d'utilisateurs DC. Ressources utiles : ✓ Documentation : InterSystems IRIS Cloud SQL InterSystems IRIS Cloud IntegratedML ✓ Outils : irissqlcli - terminal python SQL pour InterSystems IRIS Connect to IRIS Cloud SQL: irissqlcli -h your-iris-cloud-sql-server -p 1972 -u SQLAdmin -n USER -W DBeaver - Outil de base de données basé sur SQL DBeaver et IRIS ✓ Exemples d'application : iris-cloud-sql-demo ✓ Matériel d'apprentissage en ligne : Connect to InterSystems IRIS Cloud SQL via Python, C++, Java, .NET ✓ Comment soumettre votre application au concours : How to publish an application on Open Exchange How to submit an application for the contest Besoin d'aide? Rejoignez le canal du concours sur le serveur Discord d'InterSystems ou parlez avec nous dans le commentaire de ce post. Nous avons hâte de voir vos projets! Bonne chance 👍 En participant à ce concours, vous acceptez les conditions du concours énoncées ici. Veuillez les lire attentivement avant de continuer.

InterSystems s'engage à fournir une expérience de développement de haute qualité, y compris un excellent IDE (Integrated Developer Experience). Au cours des dernières années, nous avons fait évoluer les outils ObjectScript de Visual Studio Code en parallèle avec notre IDE de longue date, InterSystems Studio. Il y a eu plus de 46 000 téléchargements du plug-in VSCode-ObjectScript, et les commentaires des développeurs indiquent qu'il s'agit d'une excellente expérience de développement, et maintenant supérieure à InterSystems Studio. Avec notre version 2023.2, nous désapprouvons InterSystems Studio (obsolète désigne une fonctionnalité ou une technologie qu'InterSystems ne développe plus activement et pour laquelle de meilleures options existent). Nous continuerons à maintenir, publier et prendre en charge InterSystems Studio pendant un certain temps, et nous apprécions qu'il s'agisse toujours d'un outil important pour certains clients. Cependant, les clients doivent être informés que nous n'y investissons pas. Nous nous concentrons sur VSCode. J'ai apprécié toutes les contributions des clients au fur et à mesure que nous développons notre écosystème d'extensions VS Code, en les gardant open source tout en offrant un support complet et en maintenant des cycles de publication réguliers et rapides. Alors que nous poursuivons ce voyage, j'ai hâte de continuer à entendre vos commentaires, idées et code. N'hésitez pas à commenter ci-dessous ou à m'envoyer un message direct. Comme toujours, votre voix joue un rôle majeur dans ce processus important.

Les entreprises doivent développer et gérer leurs infrastructures informatiques mondiales rapidement et efficacement tout en optimisant et en gérant les coûts et les dépenses d'investissement. Les services de calcul et de stockage Amazon Web Services (AWS) et Elastic Compute Cloud (EC2) couvrent les besoins des applications les plus exigeantes basées sur Caché en fournissant une infrastructure informatique mondiale très robuste. L'infrastructure Amazon EC2 permet aux entreprises de provisionner rapidement leur capacité de calcul et/ou d'étendre rapidement et de manière flexible leur infrastructure sur site existante dans le cloud. AWS fournit un riche ensemble de services et des mécanismes robustes, de niveau entreprise, pour la sécurité, la mise en réseau, le calcul et le stockage. AAmazon EC2 est au cœur d'AWS. Une infrastructure de cloud computing qui prend en charge une variété de systèmes d'exploitation et de configurations de machines (par exemple, CPU, RAM, réseau). AWS fournit des images de machines virtuelles (VM) préconfigurées, appelées Amazon Machine Images ou AMI, avec des systèmes d'exploitation hôtes comprenant diverses distributions et versions de Linux® et de Windows. Ils peuvent avoir des logiciels supplémentaires utilisés comme base pour les instances virtualisées fonctionnant dans AWS. Vous pouvez utiliser ces AMI comme points de départ pour installer ou configurer des logiciels, des données et d'autres éléments supplémentaires afin de créer des AMI spécifiques aux applications ou aux charges de travail.  Comme pour toute plate-forme ou tout modèle de déploiement, il faut veiller à prendre en compte tous les aspects d'un environnement applicatif, tels que les performances, la disponibilité, les opérations et les procédures de gestion.  Ce document traite des spécificités de chacun des domaines suivants. * **• Installation et configuration du réseau.** Cette section couvre la configuration du réseau pour les applications basées sur Caché dans AWS, y compris les sous-réseaux pour prendre en charge les groupes de serveurs logiques pour les différentes couches et rôles dans l'architecture de référence. * **• Installation et configuration du serveur.** Cette section couvre les services et les ressources impliqués dans la conception des différents serveurs pour chaque couche. Il comprend également l'architecture pour la haute disponibilité à travers les zones de disponibilité. * **• Sécurité.** Cette section aborde les mécanismes de sécurité dans AWS, notamment la manière de configurer l'instance et la sécurité du réseau pour permettre un accès autorisé à la solution globale ainsi qu'entre les couches et les instances. * **• Déploiement et gestion.** Cette section fournit des détails sur la décompression, le déploiement, la surveillance et la gestion.  # Scénarios d'architecture et de déploiement Ce document présente plusieurs architectures de référence au sein d'AWS à titre d'exemples pour fournir des applications robustes, performantes et hautement disponibles basées sur les technologies InterSystems, notamment Caché, Ensemble, HealthShare, TrakCare, et les technologies embarquées associées telles que DeepSee, iKnow, CSP, Zen et Zen Mojo. Pour comprendre comment Caché et les composants associés peuvent être hébergés sur AWS, examinons d'abord l'architecture et les composants d'un déploiement typique de Caché et explorons quelques scénarios et topologies courants. ## Revue d'Architecture Caché La plate-forme de données d'InterSystems évolue en permanence pour fournir un système de gestion de base de données avancé et un environnement de développement rapide d'applications permettant de réaliser des percées dans le traitement et l'analyse de modèles de données complexes et de développer des applications Web et mobiles. Il s'agit d'une nouvelle génération de technologie de base de données qui offre de multiples modes d'accès aux données. Les données sont uniquement décrites dans un dictionnaire de données intégré unique et sont instantanément disponibles en utilisant l'accès aux objets, le SQL ¬haute performance et l'accès multidimensionnel puissant - qui peuvent tous accéder simultanément aux mêmes données. La Figure-1 présente les niveaux de composants et les services disponibles dans l'architecture de haut niveau Caché. Ces niveaux généraux s'appliquent également aux produits InterSystems TrakCare et HealthShare. **_Figure 1 : Niveaux de composants de haut niveau_**  ## Scénarios de déploiement courants There are numerous combinations possible for deployment, however in this document two scenarios will be covered; a hybrid model and complete cloud hosted model.  ### Hybrid Model Dans ce scénario, une entreprise souhaite exploiter à la fois les ressources d'entreprise sur site et les ressources AWS EC2 pour la reprise après sinistre, les imprévus de maintenance interne, les initiatives de replatformage ou l'augmentation de la capacité à court ou à long terme, le cas échéant. Ce modèle peut offrir un niveau élevé de disponibilité pour la continuité des activités et la reprise après sinistre pour un ensemble de membres miroir de basculement sur site.  La connectivité pour ce modèle dans ce scénario est basée sur un tunnel VPN entre le déploiement sur site et la ou les zones de disponibilité AWS pour présenter les ressources AWS comme une extension du centre de données de l'entreprise. Il existe d'autres méthodes de connectivité telles que AWS Direct Connect. Cependant, cela n'est pas couvert dans le cadre de ce document. Vous trouverez plus de détails sur AWS Direct Connect [ici](https://aws.amazon.com/directconnect/). Les détails de la configuration de cet exemple d'Amazon Virtual Private Cloud (VPC) pour soutenir la reprise après sinistre de votre centre de données sur¬ site peuvent être trouvés [ici](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario4.html). _**Figure 2 : Modèle hybride utilisant AWS VPC pour la reprise après sinistre sur site**_  L'exemple ci-dessus montre une paire de miroirs de basculement fonctionnant dans votre centre de données sur site avec une connexion VPN à votre VPC AWS. Le VPC illustré fournit plusieurs sous-réseaux dans des zones de disponibilité doubles dans une région AWS donnée. Il existe deux membres miroirs asynchrones de reprise après sinistre (DR) (un dans chaque zone de disponibilité) pour assurer la résilience.   ### Modèle hébergé dans le cloud Dans ce scénario, votre application basée sur le Cache, y compris les couches de données et de présentation, est entièrement conservée dans le cloud AWS en utilisant plusieurs zones de disponibilité au sein d'une même région AWS. Les mêmes modèles de tunnel VPN, AWS Direct Connect et même de connectivité Internet pure sont disponibles. **_Figure 3 : Modèle hébergé dans le cloud prenant en charge la totalité de la charge de travail de production_**  L'exemple de la Figure-3 ci-dessus présente un modèle de déploiement permettant de prendre en charge un déploiement de production complet de votre application dans votre VPC. Ce modèle s'appuie sur des zones de disponibilité doubles avec une mise en miroir de basculement synchrone entre les zones de disponibilité, ainsi que sur des serveurs Web à charge équilibrée et des serveurs d'applications associés en tant que clients ECP. Chaque niveau est isolé dans un groupe de sécurité distinct pour les contrôles de sécurité du réseau. Les adresses IP et les plages de ports ne sont ouvertes que selon les besoins de votre application. # Ressources de stockage et de calcul ## Stockage Plusieurs types d'options de stockage sont disponibles. Aux fins de cette architecture de référence, les volumes _Amazon Elastic Block Store_ (Amazon EBS) et _Amazon EC2 Instance Store_ (également appelés drives éphémères) sont examinés pour plusieurs cas d'utilisation possibles. Des détails supplémentaires sur les différentes options de stockage peuvent être trouvés [ici](https://aws.amazon.com/whitepapers/storage-options-aws-cloud/) et [ici](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html). ### Elastic Block Storage (EBS) EBS fournit un stockage durable au niveau des blocs à utiliser avec les instances Amazon EC2 (machines virtuelles) qui peuvent être formatées et montées comme des systèmes de fichiers traditionnels sous Linux ou Windows. Plus important encore, les volumes constituent un stockage hors instance qui persiste indépendamment de la durée de vie d'une seule instance Amazon EC2, ce qui est important pour les systèmes de base de données. En outre, Amazon EBS offre la possibilité de créer des instantanés ponctuels des volumes, qui sont conservés dans Amazon S3. Ces instantanés peuvent être utilisés comme point de départ pour de nouveaux volumes Amazon EBS, et pour protéger les données pour une durabilité à long terme. Le même instantané peut être utilisé pour instancier autant de volumes que vous le souhaitez. Ces instantanés peuvent être copiés entre les régions AWS, ce qui facilite l'exploitation de plusieurs régions AWS pour l'expansion géographique, la migration des centres de données et la reprise après sinistre. Les tailles des volumes Amazon EBS vont de 1 Go à 16 To, et sont alloués par incréments de 1 Go. Au sein d'Amazon EBS, il existe trois types différents : Volumes magnétiques, Usage général (SSD) et IOPS provisionnés (SSD). Les sous-sections suivantes fournissent une brève description de chaque type. ### Volumes magnétiques Les volumes magnétiques offrent un stockage rentable pour les applications dont les exigences d'I/O sont modérées ou en rafale. Les volumes magnétiques sont conçus pour fournir une centaine d'opérations d'entrée/sortie par seconde (IOPS) en moyenne, avec une capacité optimale à atteindre des centaines d'IOPS. Les volumes magnétiques sont également bien adaptés à une utilisation en tant que volumes de démarrage, où la capacité d'éclatement permet des temps de démarrage d'instance rapides. ### Usage général (SSD) Les volumes à usage général (SSD) offrent un stockage rentable, idéal pour un large gamme de charges de travail. Ces volumes fournissent des latences inférieures à 10 millisecondes, avec la capacité d'émettre en rafale jusqu'à 3 000 IOPS pendant de longues périodes, et une performance de base de 3 IOPS/Go jusqu'à un maximum de 10 000 IOPS (à 3 334 Go). Levolumes à usage général (SSD) peuvent varier de 1 Go à 16 To. ### IOPS provisionnés (SSD) Les volumes IOPS provisionnés (SSD) sont conçus pour offrir des performances élevées et prévisibles pour les charges de travail à forte intensité d'I/O, telles que les charges de travail de base de données qui sont sensibles aux performances de stockage et à la cohérence du débit d'I/O à accès aléatoire. Vous spécifiez un taux d'IOPS lors de la création d'un volume, et Amazon EBS fournit alors des performances à moins de 10 % de l'IOPS provisionné pendant 99,9 % du temps sur une année donnée. Un volume IOPS provisionné (SSD) peut avoir une taille comprise entre 4 Go et 16 To, et vous pouvez provisionner jusqu'à 20 000 IOPS par volume. Le rapport entre les IOPS provisionnés et la taille du volume demandé peut être de 30 maximum ; par exemple, un volume de 3 000 IOPS doit avoir une taille d'au moins 100 Go. Les volumes provisionnés IOPS (SSD) ont une limite de débit de 256 KB pour chaque IOPS provisionné, jusqu'à un maximum de 320 MB/seconde (à 1 280 IOPS). Les architectures présentées dans ce document utilisent des volumes EBS, car ils sont mieux adaptés aux charges de travail de production qui nécessitent des opérations d'entrée/sortie par seconde (IOPS) et un débit prévisibles à faible latence. Il faut faire attention lors de la sélection d'un type de VM particulier car tous les types d'instance EC2 ne peuvent pas avoir accès au stockage EBS. Note: Les volumes Amazon EBS étant des périphériques connectés au réseau, les autres I/O réseau effectuées par une instance Amazon EC2, ainsi que la charge totale sur le réseau partagé, peuvent affecter les performances des volumes Amazon EBS individuels. Pour permettre à vos instances Amazon EC2 d'utiliser pleinement les IOPS provisionnées sur un volume Amazon EBS, vous pouvez lancer certains types d'instances Amazon EC2 en tant qu'instances optimisées Amazon EBS.  Des détails sur les volumes EBS peuvent être trouvés [ici](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html). ### Stockage d'instance EC2 (drives éphémères) Le stockage d'une instance EC2 consiste en un bloc de stockage sur un disque préconfiguré et préattaché sur le même serveur physique qui héberge votre instance Amazon EC2 en fonctionnement. La taille du stockage sur disque fourni varie selon le type d'instance Amazon EC2. Dans les familles d'instances Amazon EC2 qui fournissent le stockage d'instance, les instances plus grandes ont tendance à fournir des volumes de stockage d'instance à la fois plus nombreux et plus importants. Il existe des familles d'instances Amazon EC2 optimisées pour le stockage (I2) et le stockage dense (D2) qui fournissent ¬un stockage d'instance à usage spécial, destiné à des cas d'utilisation spécifiques. Par exemple, les instances I2 fournissent un stockage d'instance très rapide sauvegardé par SSD, capable de prendre en charge plus de 365 000 IOPS en lecture aléatoire et 315 000 IOPS en écriture, et offrent des modèles de tarification économiquement intéressants. Contrairement aux volumes EBS, le stockage n'est pas permanent et ne peut être utilisé que pendant la durée de vie de l'instance, et ne peut être détaché ou attaché à une autre instance. Le stockage d'instance est destiné au stockage temporaire d'informations qui changent continuellement. Dans le domaine des technologies et des produits InterSystems; des éléments tels que l'utilisation d'Ensemble ou de Health Connect en tant qu' Enterprise Service Bus (ESB), les serveurs d'applications utilisant le protocole ECP (Enterprise Cache Protocol) ou les serveurs Web avec CSP Gateway seraient d'excellents cas d'utilisation pour ce type de stockage et les types d'instances optimisées pour le stockage, ainsi que l'utilisation d'outils de provisionnement et d'automatisation pour rationaliser leur efficacité et soutenir l'élasticité. Les détails sur les volumes de l'Instance store sont disponibles [ici](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html). ## Calcul ### Instances EC2 Il existe de nombreux types d'instances disponibles qui sont optimisés pour divers cas d'utilisation. Les types d'instance comprennent des combinaisons variables de CPU, de mémoire, de stockage et de capacités réseau, ce qui permet d'innombrables combinaisons pour adapter les ressources nécessaires à votre application. Dans le cadre de ce document, les types d'instances _Usage Général M4_ d'Amazon EC2 seront référencés comme des moyens de dimensionner un environnement. Ces instances offrent des capacités de volume EBS et des optimisations. Des alternatives sont possibles en fonction des besoins en capacité et des modèles de tarification de votre application. Les instances M4 sont la dernière génération d'instances _Usage Général_: Cette famille offre un équilibre entre les ressources de calcul, de mémoire et de réseau, et constitue un bon choix pour de nombreuses applications. Les capacités vont de 2 à 64 CPU virtuels et de 8 à 256 Go de mémoire avec une bande passante EBS dédiée correspondante. En plus des types d'instances individuelles, il existe également des classifications à plusieurs niveaux telles que les Hôtes dédiés, les Instances ponctuelles, les Instances réservées et les Instances dédiées, chacune avec des degrés variables de prix, de performance et d'isolation. Confirmer la disponibilité et les détails des instances actuellement disponibles [ici](https://aws.amazon.com/ec2/instance-types/). # Disponibilité et opérations ## Équilibrage de la Charge du serveur Web/App Des serveurs web externes et internes à charge équilibrée peuvent être nécessaires pour votre application basée sur Caché. Les équilibreurs de charge externes sont utilisés pour l'accès par Internet ou WAN (VPN ou Direct Connect) et les équilibreurs de charge internes sont potentiellement utilisés pour le trafic interne. AWS Elastic Load Balancing fournit deux types d'équilibreurs de charge : l'équilibreur de charge Application load balancer et l'équilibreur de charge Classic Load balancer. ### Équilibreur de charge Classic Load Balancer L'Équilibreur de charge Classic Load Balancer achemine le trafic en fonction des informations au niveau de l'application ou du réseau et est idéal pour un équilibrage de charge simple du trafic sur plusieurs instances EC2 nécessitant une haute disponibilité, une mise à l'échelle automatique et une sécurité robuste. Les détails et caractéristiques spécifiques sont disponibles [ici](https://aws.amazon.com/elasticloadbalancing/classicloadbalancer/). ### Équilibreur de charge Application Load Balancer Un équilibreur de charge Application Load Balancer est une option d'équilibrage de charge pour le service Elastic Load Balancing qui fonctionne au niveau de la couche applicative et vous permet de définir des règles de routage basées sur le content entre plusieurs services ou conteneurs fonctionnant sur une ou plusieurs instances Amazon EC2. De plus, il existe un support pour WebSockets et HTTP/2. Les détails et caractéristiques spécifiques sont disponibles [ici](https://aws.amazon.com/elasticloadbalancing/applicationloadbalancer/). ### Exemple L'exemple suivant définit un ensemble de trois serveurs web, chacun d'entre eux se trouvant dans une zone de disponibilité distincte afin de fournir les niveaux de disponibilité les plus élevés. Les équilibreurs de charge des serveurs Web doivent être configurés avec _Sticky Sessions_ pour prendre en charge la possibilité d'attribuer les sessions des utilisateurs à des instances EC2 spécifiques à l'aide de cookies. Le trafic sera acheminé vers les mêmes instances à mesure que l'utilisateur continue d'accéder à votre application.  Le schéma suivant de la Figure-4 présente un exemple simple de l'équilibreur de charge Classic Load Balancer dans AWS. **_Figure 4 : Exemple d'équilibreur de charge Classic Load Balancer_**  ## Mise en miroir de base de données Lors du déploiement d'applications basées sur Caché sur AWS, la fourniture d'une haute disponibilité pour le serveur de base de données Caché nécessite l'utilisation d'une mise en miroir synchrone de la base de données afin de fournir une haute disponibilité dans une région AWS primaire donnée et potentiellement d'une mise en miroir asynchrone de la base de données pour répliquer les données vers une mise en veille prolongée dans une région AWS secondaire pour la reprise après sinistre en fonction de vos exigences en matière de contrats de niveau de service de disponibilité. Un miroir de base de données est un regroupement logique de deux systèmes de base de données, appelés membres de basculement, qui sont des systèmes physiquement indépendants reliés uniquement par un réseau. Après avoir arbitré entre les deux systèmes, le miroir désigne automatiquement l'un d'entre eux comme système primaire ; l'autre membre devient automatiquement le système de sauveguarde. Les postes de travail clients externes ou d'autres ordinateurs se connectent au miroir par l'intermédiaire de l'IP virtuelle (VIP) du miroir, qui est spécifiée lors de la configuration de la mise en miroir. Le miroir VIP est automatiquement lié à une interface sur le système principal du miroir.  Note: Dans AWS, il n'est pas possible de configurer le VIP miroir de manière traditionnelle, une solution alternative a donc été conçue. Cependant, la mise en miroir est prise en charge sur tous les sous-réseaux. La recommandation actuelle pour le déploiement d'un miroir de base de données dans AWS consiste à configurer trois instances (primaire, de sauvegarde, arbitre) dans le même VPC à travers trois zones de disponibilité différentes. Ainsi, à tout moment, AWS garantit la connectivité externe d'au moins deux de ces VM avec un SLA de 99,95 %. Cela permet une isolation et une redondance adéquates des données de la base de données elle-même. Les détails sur les accords de niveau de service AWS EC2 sont disponibles [ici](https://aws.amazon.com/ec2/sla/). Il n'y a pas de limite supérieure rigide sur la latence du réseau entre les membres de basculement. **L'impact de l'augmentation de la latence dépend de l'application.** Si le temps aller-retour entre les membres de basculement est similaire au temps de service d'écriture au disque, aucun impact n'est attendu. La durée d'aller-retour peut toutefois poser problème lorsque l'application doit attendre que les données deviennent durables (ce que l'on appelle parfois la synchronisation du journal). Les détails de la mise en miroir de la base de données et de la latence du réseau sont disponibles [ici](http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GHA_mirror#GHA_mirror_set_bp_netwk_latency). ### Adresse IP virtuelle et basculement automatique La plupart des fournisseurs de cloud IaaS n'ont pas la capacité de fournir une adresse IP virtuelle (VIP) généralement utilisée dans les conceptions de basculement de base de données. Pour y remédier, plusieurs des méthodes de connectivité les plus couramment utilisées, notamment les clients ECP et les passerelles CSP Gateways, ont été améliorées dans Caché, Ensemble et HealthShare afin de ne plus dépendre des capacités VIP, ce qui les rend compatibles avec les miroirs.  Les méthodes de connectivité telles que xDBC, les sockets TCP/IP directs, ou d'autres protocoles de connexion directe, nécessitent toujours l'utilisation d'un VIP. Pour y remédier, la technologie de mise en miroir des bases de données d'InterSystems permet de fournir un basculement automatique pour ces méthodes de connectivité au sein d'AWS en utilisant des API pour interagir avec un équilibreur de charge élastique (ELB) d'AWS afin d'obtenir une fonctionnalité de type VIP, offrant ainsi une conception de haute disponibilité complète et robuste au sein d'AWS.  En outre, AWS a récemment introduit un nouveau type d'ELB appelé "Application Load Balancer". Ce type d'équilibreur de charge s'exécute à la Couche 7 et prend en charge le routage basé sur le contenu et les applications qui s'exécutent dans des conteneurs. Le routage basé sur le contenu est particulièrement utile pour les projets de type Big Data qui utilisent un déploiement de données partitionnées ou de partage de données.  Tout comme avec Virtual IP, il s'agit d'un changement brusque de la configuration du réseau et n'implique aucune logique applicative pour informer les clients existants connectés au membre miroir primaire défaillant qu'un basculement a lieu. Selon la nature de la défaillance, ces connexions peuvent être interrompues à cause de la défaillance elle-même, à cause d'un dépassement de délai ou d'une erreur de l'application, à cause du nouveau primaire qui force l'ancienne instance primaire à s'arrêter, ou à cause de l'expiration du timer TCP utilisé par le client. Par conséquent, les utilisateurs peuvent être amenés à se reconnecter et à se loguer. Le comportement de votre application déterminerait ce comportement. Des détails sur les différents types d'ELB disponibles sont disponibles [ici](https://aws.amazon.com/elasticloadbalancing/). #### **Méthode d'appel d'une instance AWS EC2 vers AWS Elastic Load Balancer** Dans ce modèle, l'ELB peut avoir un pool de serveurs défini avec des membres miroir de basculement et potentiellement des membres miroir asynchrones DR avec une seule des entrées actives qui est le membre miroir primaire actuel, ou seulement un pool de serveurs avec une seule entrée du membre miroir actif.  _**Figure 5 : Méthode API pour interagir avec Elastic Load Balancer (interne)**_  Lorsqu'un membre miroir devient le membre miroir primaire, un appel API est émis depuis votre instance EC2 vers l'AWS ELB pour ajuster/instruire l'ELB du nouveau membre miroir primaire.  _**Figure 6 : Basculement vers le membre miroir B à l'aide de l'API pour l'équilibreur de charge**_  Le même modèle s'applique à la promotion d'un membre miroir asynchrone DR dans le cas où les membres miroirs primaire et de sauveguarde deviennent indisponibles. _**Figure-7: Promotion du miroir asynchrone du DR vers le primaire en utilisant l'API vers l'équilibreur de charge**_  Conformément à la procédure DR standard recommandée, dans la Figure-6 ci-dessus, la promotion du membre DR implique une décision humaine en raison de la possibilité de perte de données due à la réplication asynchrone. Cependant, une fois cette mesure prise, aucune mesure administrative n'est requise sur ELB. Il achemine automatiquement le trafic une fois que l'API est appelée pendant la promotion. #### **Détails de l'API** Cette API pour appeler la ressource AWS load balancer est définie dans AZMIRROR routine spécifiquement dans le cadre de l'appel de procédure:   `<strong><em>$$CheckBecomePrimaryOK^ZMIRROR()</em></strong>` Dans cette procédure, insérez la logique ou les méthodes API que vous avez choisi d'utiliser à partir d' AWS ELB REST API, de Command Line Interface, etc. Un moyen efficace et sécurisé d'interagir avec ELB est de recourir aux rôles AWS Identity and Access Management (IAM) afin de ne pas avoir à distribuer des informations d'identification à long terme à une instance EC2. Le rôle IAM fournit des autorisations temporaires que Caché peut utiliser pour interagir avec AWS ELB. Des détails sur l'utilisation des rôles IAM attribués à vos instances EC2 sont disponibles [ici](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html). #### Méthode de sondage de l'équilibreur de charge AWS Elastic Load Balancer Une méthode de sondage utilisant la page CSP Gateway _mirror_status.cxw_ disponible en 2017.1 peut être utilisée comme méthode de sondage dans le moniteur de santé ELB pour chaque membre miroir ajouté au pool de serveurs ELB. Seul le miroir primaire répondra 'SUCCESS', dirigeant ainsi le trafic réseau uniquement vers le membre primaire actif du miroir.  Pour être ajoutée à AZMIROIR; cette méthode ne nécessite aucune logique . Veuillez noter que la plupart des dispositifs de réseau d'équilibrage de charge ont une limite sur la fréquence d'exécution de la vérification de l'état. En général, la fréquence la plus élevée n'est pas inférieure à 5 secondes, ce qui est généralement acceptable pour prendre en charge la plupart des accords de niveau de service en matière de disponibilité. Une requête HTTP pour la ressource suivante testera l'état de membre miroir de la configuration LOCAL Cache. **_ `/csp/bin/mirror_status.cxw`_** Dans tous les autres cas, le chemin d'accès à ces demandes d'état miroir doit mener au serveur de cache et à l'espace de noms appropriés en utilisant le même mécanisme hiérarchique que celui utilisé pour demander des pages CSP réelles. Exemple : Pour tester l'état du miroir de la configuration desservant les applications dans le chemin /csp/user/ path: **_ `/csp/user/mirror_status.cxw`_** Note: Une licence CSP n'est pas consommée en invoqueant une vérification de l'état du miroir. Selon que l'instance cible est le membre primaire actif ou non, le Gateway renvoie l'une des réponses CSP suivantes: **** Succès (Est le membre primaire)** ===============================    HTTP/1.1 200 OK    Content-Type: text/plain    Connection: close    Content-Length: 7    SUCCESS **** Échec (N'est pas le membre primaire)** ===============================    HTTP/1.1 503 Service Unavailable    Content-Type: text/plain    Connection: close    Content-Length: 6    FAILED **** Échec (Le serveur cache ne prend pas en charge la requête _Mirror_Status.cxw_)** ===============================    HTTP/1.1 500 Internal Server Error    Content-Type: text/plain    Connection: close    Content-Length: 6    FAILED Les figures suivantes présentent les différents scénarios d'utilisation de la méthode de sondage. _**Figure 8 : Sondage auprès de tous les membres du miroir**_  Comme le montre la Figure-8 ci-dessus, tous les membres miroirs sont opérationnels, et seul le membre miroir primaire renvoie "SUCCESS" à l'équilibreur de charge, et donc le trafic réseau sera dirigé uniquement vers ce membre miroir. _**Figure 9 : Basculement vers le membre miroir B en utilisant le sondage**_  Le diagramme suivant illustre la promotion d'un ou plusieurs membres miroir asynchrones DR dans le pool équilibré en charge, ce qui suppose généralement que le même dispositif réseau d'équilibrage de charge dessert tous les membres miroir (les scénarios de répartition géographique sont traités plus loin dans cet article). Conformément à la procédure DR standard recommandée, la promotion du membre DR implique une décision humaine en raison de la possibilité de perte de données due à la réplication asynchrone. Cependant, une fois cette mesure prise, aucune mesure administrative n'est requise sur ELB. Il découvre automatiquement le nouveau primaire. **_Figure-10: Basculement et promotion du membre miroir asynchrone DR à l'aide du sondage_**  ## Sauvegarde et Restauration Plusieurs options sont disponibles pour les opérations de sauvegarde. Les trois options suivantes sont viables pour votre déploiement AWS avec les produits InterSystems. Les deux premières options 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 dde 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 d'instantané :: * Pause des écritures dans la base de données via l'appel Freeze API de la base de données. * Créez des instantanés du système d'exploitation + des disques de données. * Resume Caché écrit via l'appel de Thaw API base de données. * Sauvegarde des archives de l'installation vers un emplacement de sauvegarde Des étapes supplémentaires, telles que les contrôles d'intégrité, peuvent être ajoutées à intervalles réguliers pour garantir une sauvegarde propre et cohérente. Les points de décision sur l'option à utiliser dépendent des exigences opérationnelles et des politiques de votre organisation. InterSystems est à votre disposition pour discuter plus en détail des différentes options. ### Instantanés EBS Les instantanés EBS sont des moyens très rapides et efficaces de créer un instantané ponctuel sur le stockage Amazon S3 hautement disponible et à moindre coût. Les instantanés EBS ainsi que les capacités InterSystems External Freeze et Thaw API permettent 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. Il existe de nombreuses options pour automatiser le processus en utilisant les services fournis par AWS, tels que Amazon CloudWatch Events ou des solutions tierces disponibles sur le marché, telles que Cloud Ranger ou N2W Software Cloud Protection Manager, pour n'en citer que quelques-unes. En outre, vous pouvez créer par programmation votre propre solution de sauvegarde personnalisée en utilisant les appels API directs par AWS. Des détails sur la façon d'exploiter les API sont disponibles [ici](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html) et [ici](http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateSnapshot.html). Note: InterSystems n'approuve ni ne valide explicitement aucun de ces produits tiers. Les tests et la validation sont du ressort du client. ### Instantanés de Logical Volume Manager Il est également possible d'utiliser de nombreux outils de sauvegarde tiers disponibles sur le marché en déployant des agents de sauvegarde individuels dans le VM lui-même et en exploitant les sauvegardes au niveau des fichiers en conjonction avec les instantanés LVM (Logical Volume Manager) de Linux ou VSS (Volume Shadow Copy Service) de Windows. L'un des principaux avantages de ce modèle est la possibilité d'effectuer des restaurations au niveau des fichiers des instances basées sur Linux et Windows. Quelques points à noter avec cette solution : étant donné qu'AWS et la plupart des autres fournisseurs de cloud IaaS ne fournissent pas de bandes, tous les référentiels de sauvegarde sont sur disque pour l'archivage à court terme et ont la possibilité d'exploiter le stockage Amazon S3 à faible coût et éventuellement Amazon Glacier pour la rétention à long terme (LTR). Il est fortement recommandé, si vous utilisez cette méthode, d'utiliser un produit de sauvegarde qui supporte les technologies de déduplication afin d'utiliser les référentiels de sauvegarde sur disque de la manière la plus efficace possible. Quelques exemples de ces produits de sauvegarde avec prise en charge du cloud incluent, sans s'y limiter : Commvault, EMC Networker, HPE Data Protector et Veritas Netbackup.  Note: InterSystems n'approuve ni ne valide explicitement aucun de ces produits tiers. Les tests et la validation sont du ressort du client. ### Caché Online Backup Pour les petits déploiements, la fonction intégrée Caché Online Backup est également une option viable. L'utilitaire de sauvegarde en ligne des bases de données d'InterSystems sauvegarde les données dans les fichiers des bases 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 causer aucun temps d'arrêt aux utilisateurs du système de production.  Dans AWS, une fois la sauvegarde en ligne terminée, le fichier de sortie de sauvegarde et tous les autres fichiers utilisés par le système doivent être copiés dans un EC2 agissant comme un partage de fichiers (CIFS/NFS). Ce processus doit être scripté et exécuté dans la machine virtuelle. La sauvegarde en ligne est l'approche d'entrée de gamme pour les petits sites souhaitant mettre en œuvre une solution de sauvegarde à faible coût. 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. ## Reprise après sinistre Lors du déploiement d'une application basée sur Caché sur AWS, il est recommandé que les ressources de secours, notamment le réseau, les serveurs et le stockage, se trouvent dans une région AWS différente ou, au minimum, dans des zones de disponibilité distinctes. La quantité de capacité requise dans la région DR AWS désignée dépend des besoins de votre organisation. Dans la plupart des cas, 100 % de la capacité de production est nécessaire en cas de fonctionnement en mode DR, mais une capacité moindre peut être fournie jusqu'à ce qu'une plus grande quantité soit nécessaire en tant que modèle élastique. Une capacité moindre peut prendre la forme d'un nombre réduit de serveurs Web et d'applications, voire d'un type d'instance EC2 plus petit pour le serveur de base de données. Lors de la promotion, les volumes EBS sont rattachés à un type d'instance EC2 plus important.  La mise en miroir asynchrone de la base de données est utilisée pour répliquer en continu les instances EC2 de la région DR AWS. La mise en miroir utilise les journaux des transactions de la base de données pour répliquer les mises à jour sur un réseau TCP/IP d'une manière qui a un impact minimal sur les performances du système primaire. Il est fortement recommandé de configurer la compression et le cryptage des fichiers de journal avec ces membres miroirs asynchrones DR. Tous les clients externes sur l'Internet public qui souhaitent accéder à l'application seront acheminés via Amazon Route53 en tant que service DNS supplémentaire. Amazon Route53 est utilisé comme commutateur pour diriger le trafic vers le centre de données actif actuel. Amazon Route53 remplit trois fonctions principales: * **• Enregistrement de domaine** – Amazon Route53 vous permet d'enregistrer des noms de domaine tels que example.com. * **• Service DNS (Domain Name System)** – Amazon Route53 traduit les noms de domaines amis comme www.example.com en adresses IP comme 192.0.2.1 Amazon Route53 répond aux requêtes DNS en utilisant un réseau mondial de serveurs DNS faisant autorité, ce qui réduit la latence. * **• Vérification de la santé** – Amazon Route53 envoie des requêtes automatisées sur Internet à votre application pour vérifier qu'elle est joignable, disponible et fonctionnelle. Les détails de ces fonctions sont disponibles [ici](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html). Aux fins de ce document, le basculement DNS et la vérification de l'état de Route53 seront discutés. Les détails de la surveillance de l'état de santé et du basculement DNS sont disponibles [ici](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html) et [ici](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html). Route53 fonctionne en effectuant des requêtes régulières à chaque point de terminaison, puis en vérifiant la réponse. Si un point de terminaison ne fournit pas de réponse valide. Il n'est plus inclus dans les réponses DNS, qui renverront un autre point d'accès disponible. De cette façon, le trafic des utilisateurs est éloigné des points d'extrémité défaillants et dirigé vers les points d'extrémité disponibles. En utilisant les méthodes ci-dessus, le trafic ne sera autorisé que vers une région spécifique et un membre miroir spécifique. Ceci est contrôlé par la définition du points d'extrémité qui est une page mirror_status.cxw discutée précédemment dans cet article et présentée à partir du Gateway CSP d'InterSystems. Seul le membre primaire du miroir rapportera "SUCCESS" comme un HTTP 200 de la vérification de santé. Le diagramme suivant présente à un niveau élevé la stratégie de routage de basculement. Les détails de cette méthode et d'autres sont disponibles [ici](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html). _**Figure 11 : Stratégie de routine de basculement Amazon Route53**_  À tout moment, une seule des régions fera un rapport en ligne sur la base de la surveillance des points d'extrémité. Cela garantit que le trafic ne circule que dans une région à la fois. Aucune étape supplémentaire n'est nécessaire pour le basculement entre les régions puisque la surveillance des points de terminaison détectera que l'application dans la région AWS primaire désignée est hors service et que l'application est maintenant en ligne dans la région AWS secondaire. Cela s'explique par le fait que le membre miroir asynchrone DR a été promu manuellement au rang de primaire, ce qui permet à la passerelle CSP de signaler HTTP 200 au point de contrôle d'Elastic Load Balancer. Il existe de nombreuses alternatives à la solution décrite ci-dessus, et elles peuvent être personnalisées en fonction des exigences opérationnelles et des accords de niveau de service de votre organisation. ## Vérification Amazon CloudWatch est disponible pour fournir des services de vérification pour toutes vos ressources du cloud AWS et vos applications. Amazon CloudWatch peut être utilisé pour collecter et suivre les métriques, collecter et surveiller les fichiers journaux, définir des alarmes et réagir automatiquement aux changements dans les ressources AWS. Amazon CloudWatch peut contrôler les ressources AWS telles que les instances Amazon EC2  ainsi que les mesures personnalisées générées par vos applications et services, et tous les fichiers journaux que vos applications génèrent. Vous pouvez utiliser Amazon CloudWatch pour obtenir une visibilité à l'échelle du système sur l'utilisation des ressources, les performances des applications et la santé opérationnelle. Les détails sont disponibles [ici](https://aws.amazon.com/cloudwatch/). Provisionnement Automatisé Il existe aujourd'hui de nombreux outils disponibles sur le marché, notamment Terraform, Cloud Forms, Open Stack et CloudFormation d'Amazon. L'utilisation de ces outils et le couplage avec d'autres outils tels que Chef, Puppet, Ansible et d'autres peuvent fournir une infrastructure complète en tant que code prenant en charge DevOps ou simplement le démarrage de votre application d'une manière complètement automatisée. Les détails d'Amazon CloudFormation sont disponibles [ici](https://aws.amazon.com/cloudformation/%C2%A0%C2%A0). # Connectivité Réseau En fonction des exigences de connectivité de votre application, plusieurs modèles de connectivité sont disponibles, utilisant soit Internet, soit un VPN, soit un lien dédié utilisant Amazon Direct Connect. La méthode à choisir dépend de l'application et des besoins de l'utilisateur. L'utilisation de la bande passante pour chacune des trois méthodes varie, et il est préférable de vérifier avec votre représentant AWS ou Amazon Management Console pour confirmer les options de connectivité disponibles pour une région donnée. # Sécurité Il convient d'être prudent lorsque l'on décide de déployer une application dans un fournisseur public de cloud IaaS. Les politiques de sécurité standard de votre organisation, ou les nouvelles politiques développées spécifiquement pour le cloud, doivent être suivies pour maintenir la conformité de votre organisation en matière de sécurité. Vous devrez également comprendre la souveraineté des données, qui est pertinente lorsque les données d'une organisation sont stockées en dehors de son pays et sont soumises aux lois du pays dans lequel les données résident. Les déploiements en nuage comportent le risque supplémentaire que les données se trouvent désormais en dehors des centres de données des clients et du contrôle de sécurité physique. L'utilisation d'un cryptage de base de données et de journaux InterSystems pour les données au repos (bases de données et journaux) et les données en vol (communications réseau) avec un cryptage AES et SSL/TLS respectivement est fortement recommandée. Comme pour toute gestion de clé de cryptage, des procédures appropriées doivent être documentées et suivies conformément aux politiques de votre organisation afin de garantir la sécurité des données et d'empêcher tout accès indésirable aux données ou toute violation de la sécurité. Amazon fournit une documentation complète et des exemples pour fournir un environnement d'exploitation hautement sécurisé pour vos applications basées sur Caché. Assurez-vous de consulter l'IAM (Identity Access Management) pour les différents sujets de discussion qui sont disponibles [ici](https://aws.amazon.com/security/). # Exemples de diagrammes d'architecture Le diagramme ci-dessous illustre une installation typique de Caché offrant une haute disponibilité sous la forme d'une mise en miroir des bases de données (basculement synchrone et DR asynchrone), de serveurs d'applications utilisant ECP et de plusieurs serveurs Web à charge équilibrée. ## Exemple de TrakCare Le diagramme suivant illustre un déploiement typique de TrakCare avec plusieurs serveurs Web à charge équilibrée, deux serveurs d'impression comme clients ECP et une configuration miroir de la base de données. L'adresse IP virtuelle est utilisée uniquement pour la connectivité non associée à ECP ou au CSP Gateway. Les clients ECP et le CSP Gateway sont compatibles avec le miroir et ne nécessitent pas de VIP. Si vous utilisez Direct Connect, il existe plusieurs options, notamment les circuits multiples et l'accès multirégional, qui peuvent être activées pour les scénarios de reprise après sinistre. Il est important de travailler avec le(s) fournisseur(s) de télécommunications pour comprendre les scénarios de haute disponibilité et de reprise après sinistre qu'ils prennent en charge. L'exemple de diagramme d'architecture de référence ci-dessous inclut la haute disponibilité dans la région active ou principale et la reprise après sinistre dans une autre région AWS si la région AWS principale n'est pas disponible. Également dans cet exemple, les miroirs de base de données contiennent l'espace de noms TrakCare DB, TrakCare Analytics et Integration namespace dans cet ensemble de miroirs unique. _**Figure-12 : Diagramme d'Architecture de référence AWS TrakCare - Architecture physique**_  En outre, le diagramme suivant montre une vue plus logique de l'architecture avec les produits logiciels de haut niveau associés installés et leur finalité fonctionnelle. _**Figure-13 : Diagramme d'Architecture de référence AWS TrakCare - Architecture logique**_  ## Exemple de HealthShare Le diagramme suivant présente un déploiement typique de HealthShare avec plusieurs serveurs Web équilibrés en termes de charge, avec plusieurs produits HealthShare, notamment Information Exchange, Patient Index, Personal Community, Health Insight et Health Connect. Chacun de ces produits respectifs comprend une paire de miroirs de base de données pour une haute disponibilité dans plusieurs zones de disponibilité. L'adresse IP virtuelle est utilisée uniquement pour la connectivité non associée à ECP ou au CSP Gateway. Les CSP Gateways utilisées pour les communications de services Web entre les produits HealthShare sont sensibles aux miroirs et ne nécessitent pas de VIP. L'exemple de diagramme d'architecture de référence ci-dessous inclut la haute disponibilité dans la région active ou principale et la reprise après sinistre dans une autre région AWS si la région principale n'est pas disponible.  _**Figure-14: Diagramme d'Architecture de référence AWS HealthShare - Architecture physique**_  En outre, le diagramme suivant montre une vue plus logique de l'architecture avec les produits logiciels de haut niveau associés installés, les exigences et méthodes de connectivité, et leur finalité fonctionnelle. _**Figure-15: Diagramme d'Architecture de référence AWS HealthShare - Architecture logique**_  #