Nouvelle publication

#InterSystems IRIS

0

InterSystems IRIS est une plateforme complète de données
InterSystems IRIS vous offre tout le nécessaire pour capturer, partager, comprendre et agir sur la ressource le plus précieuse de votre entreprise : vos données.
En tant que plateforme complète, InterSystems IRIS élimine la nécessité d'intégrer plusieurs technologies de développement. Les applications nécessitent moins de code, moins de ressources système et moins de maintenance.

Les architectures de données modernes utilisent des solutions de capture, transformation, déplacement et chargement de données en temps réel pour construire des lacs de données, des entrepôts analytiques et des référentiels de big data. Cela permet l'analyse de données provenant de diverses sources sans impacter les opérations qui les utilisent. Pour y parvenir, il est essentiel d'établir un flux de données continu, évolutif, élastique et robuste. La méthode la plus répandue pour cela passe par la technique CDC (Change Data Capture). Le CDC surveille la production de petits ensembles de données, capture automatiquement ces données et les transmet à un ou plusieurs destinataires, y compris les référentiels de données analytiques. L'avantage majeur est l'élimination du délai J+1 dans l'analyse, car les données sont détectées à la source dès qu'elles sont produites, puis répliquées vers la destination.

Cet article démontrera les deux sources de données les plus courantes pour les scénarios CDC, à la fois comme source et comme destination. Pour la source de données (origine), nous explorerons le CDC dans les bases de données SQL et les fichiers CSV. Pour la destination des données, nous utiliserons une base de données en colonnes (un scénario typique de base de données analytique haute performance) et un topic Kafka (une approche standard pour le streaming de données vers le cloud et/ou vers plusieurs consommateurs de données en temps réel).

 

Aperçu

Cet article fournit un exemple pour le scénario d'interopérabilité suivant:

 

Open Exchange app
2 1
0 17

Vous envoyez une requête HTTP et recevez une erreur HTTP, mais accompagnée d'une page d'erreur HTML inattendue… Que se passe-t-il ? 🤔

Par exemple, vous avez peut-être essayé de lire une ressource FHIR (par exemple, /Patient/123) et vous obtenez une erreur 404, alors qu'avec d'autres identifiants de patient, vous recevez bien la ressource. La page existe donc bel et bien… Pourquoi obtenez-vous une erreur 404 ? 🙄

La réponse à ces questions est liée au comportement du serveur web IIS face aux erreurs.

IIS propose trois options d'affichage des erreurs :

  • Afficher uniquement les pages d'erreur personnalisées
  • Afficher les erreurs serveur détaillées
  • Pour les requêtes locales, afficher les erreurs détaillées ; pour les requêtes distantes, afficher les pages d'erreur personnalisées.

1 0
0 22

Introduction

Dans cet article, nous explorerons différentes approches permettant d'étendre et de personnaliser le comportement des routeurs de messages d'interopérabilité intégrés à InterSystems IRIS (et IRIS Health).

Les routeurs de messages remplissent l'une des fonctions essentielles de l'intégration d'applications d'entreprise (EAI) et font partie des processus métier les plus fréquemment utilisés dans les productions d'interopérabilité.

Après un bref aperçu des classes de routeurs de messages intégrés dans InterSystems IRIS et IRIS for Health, cet article expliquera comment améliorer leurs capacités afin d'obtenir des résultats spécifiques, sans avoir à développer un processus métier à partir de zéro.

Une mise en garde s'impose : la plupart de ces techniques impliquent de remplacer les méthodes de l'implémentation actuelle des classes de routeurs de messages dans IRIS Data Platform et IRIS for Health 2025.x. Elles peuvent ne pas s'appliquer à d'autres versions antérieures ou futures.

Le référentiel GitHub qui accompagne cet article contient une collection d'exemples simples, minimalistes et volontairement abstraits illustrant les techniques abordées.

Nous vous invitons à nous faire part de vos avis, commentaires et retours constructifs!

0 0
0 8

J'ai rencontré à plusieurs reprises un cas où j'ai besoin d'utiliser un fichier/dossier temporaire et de le supprimer ultérieurement.

La solution la plus naturelle consiste alors à suivre les recommandations de "Robust Error Handling and Cleanup in ObjectScript" avec un bloc try/catch/pseudo-finally ou un objet enregistré pour gérer le nettoyage dans le destructeur. %Stream.File* possède également une propriété RemoveOnClose que vous pouvez définir, mais avec précaution, car vous pourriez supprimer accidentellement un fichier important. De plus, cette propriété est réinitialisée par les appels à %Save(), vous devrez donc la remettre à 1 après chaque utilisation.

Il existe cependant un cas particulier : supposons que vous ayez besoin que le fichier temporaire subsiste dans la pile d'exécution. Par exemple :

0 0
0 6