#TrakCare

Mes clients me contactent régulièrement à propos du dimensionnement de la mémoire lorsqu'ils reçoivent des alertes indiquant que la mémoire libre est inférieure à un seuil ou lorsqu'ils constatent que la mémoire libre a soudainement diminué. Existe-t-il un problème? Leur application va-t-elle cesser de fonctionner parce qu'elle manque de mémoire pour exécuter les processus système et applicatifs? La réponse est presque toujours non, il est inutile de s'inquiéter. Mais cette réponse simple n'est généralement pas suffisante. Que se passe-t-il?

Considérez le graphique ci-dessous. Il montre le résultat de la métrique free dans vmstat. Il existe d'autres moyens d'afficher la mémoire libre d'un système, par exemple la commande free -m. Parfois, la mémoire libre disparaît progressivement au fil du temps. Le graphique ci-dessous est un exemple exagéré, mais il illustre bien ce qui se passe.

Comme vous pouvez le constater, vers 2 heures du matin, une partie de la mémoire est récupérée, puis chute soudainement à près de zéro. Ce système exécute l'application IntelliCare EHR sur la base de données InterSystems IRIS. Les informations vmstat proviennent d'un fichier HTML ^SystemPerformance qui collecte les métriques vmstat, iostat et plusieurs autres métriques système. Que se passe-t-il d'autre sur ce système ? Comme nous sommes en pleine nuit, je ne m'attends pas à ce qu'il se passe grand-chose à l'hôpital. Examinons iostat pour les volumes de la base de données.

On constate une augmentation soudaine des lectures au moment où la mémoire libre diminue. La baisse de la mémoire libre signalée correspond à un pic des lectures en gros blocs (taille de requête de 2048 Ko) indiqué dans iostat pour le disque de la base de données. Il s'agit très probablement d'un processus de sauvegarde ou d'une copie de fichiers. Bien sûr, corrélation n'est pas synonyme de causalité, mais cela vaut la peine d'être examiné et, en fin de compte, cela explique ce qui se passe.

Examinons d'autres résultats de ^SystemPerformance. La commande free -m est exécutée à la même fréquence que vmstat (par exemple, toutes les 5 secondes) et est accompagnée de la date et de l'heure, ce qui nous permet également de représenter graphiquement les compteurs dans free -m.

Les compteurs:

• Memtotal – Total de RAM physique.
• used – RAM activement utilisée (applications + système d'exploitation + cache).
• free – RAM complètement inutilisée.
• shared – Mémoire partagée entre les processus.
• buf/cache – RAM utilisée pour les tampons et le cache, récupérable si nécessaire.
• available – RAM disponible sans swap.
• swaptotal – Espace de swap total sur le disque.
• swapused – Espace de swap actuellement utilisé.
• swapfree – Espace de swap inutilisé.

Pourquoi la mémoire libre diminue-t-elle à 2 heures du matin?

• Les lectures séquentielles de grande taille remplissent le cache de page du système de fichiers, consommant temporairement de la mémoire qui apparaît comme "utilisée" dans free -m.
• Linux utilise de manière agressive la mémoire inexploitée pour la mise en cache des E/S afin d'améliorer les performances.
• Une fois la sauvegarde terminée (≈ 03h00), la mémoire est progressivement récupérée au fur et à mesure que les processus en ont besoin.
• Vers 6 heures du matin, l'hôpital commence à s'activer et la mémoire est utilisée pour IRIS et d'autres processus.

Une mémoire libre insuffisante ne constitue pas une pénurie, mais plutôt une utilisation de la mémoire "libre" par le système à des fins de mise en cache. Il s'agit d'un comportement normal sous Linux! Le processus de sauvegarde lit de grandes quantités de données, que Linux met agressivement en cache dans la mémoire tampon/cache. Le noyau Linux convertit la mémoire "libre" en mémoire "cache" afin d'accélérer les opérations d'E/S.

Résumé

Le cache du système de fichiers est conçu pour être dynamique. Si la mémoire est requise par un processus, elle sera immédiatement récupérée. Il s'agit d'un élément normal de la gestion de la mémoire sous Linux.

Les Huge Pages ont-elles un impact?

Pour optimiser les performances et réserver de la mémoire pour la mémoire partagée IRIS, la meilleure pratique pour les déploiements IRIS en production sur des serveurs dotés d'une mémoire importante consiste à utiliser les Huge Pages de Linux. Pour IntelliCare, j'utilise généralement 8 Go de mémoire par noyau et environ 75 % de la mémoire pour la mémoire partagée d'IRIS (tampons Routine et Global, GMHEAP et autres structures de mémoire partagée). La répartition de la mémoire partagée dépend des exigences de l'application. Vos exigences peuvent être complètement différentes. Par exemple, en utilisant ce rapport CPU/mémoire, 25 % suffisent-ils pour les processus IRIS et les processus du système d'exploitation de votre application?

InterSystems IRIS utilise l'E/S directe pour les fichiers de base de données et les fichiers journaux, ce qui contourne le cache du système de fichiers. Ses segments de mémoire partagée (globales, routines, gmheap, etc.) sont alloués à partir de Huge Pages.

• Ces pages immenses (huge pages) sont dédiées à la mémoire partagée IRIS et n'apparaissent pas comme "libres" ou "cache" dans free -m.
• Once allocated, huge pages are not available for filesystem cache or user processes.

Cela explique pourquoi les métriques free -m semblent "insuffisantes" même si la base de données IRIS elle-même ne manque pas de mémoire.

Comment la mémoire libre pour un processus est-elle calculée?

À partir de ce qui précède, dans free -m, les lignes pertinentes sont les suivantes:

• free – RAM totalement inutilisée.
• available – RAM encore utilisable sans échange.

La disponibilité est un bon indicateur: elle inclut la mémoire cache et les tampons récupérables, indiquant ce qui est réellement disponible pour les nouveaux processus sans échange. Quels processus? Pour plus d'informations, consultez InterSystems Data Platforms and Performance Part 4 - Looking at Memory . Voici une liste simple: système d'exploitation, autres processus d'application non-IRIS et processus IRIS.

Examinons un graphique de la sortie free -m.

Bien que la valeur de la mémoire libre (free) chute à près de zéro pendant la sauvegarde, la valeur de la mémoire disponible (available) reste beaucoup plus élevée (plusieurs dizaines de Go). Cela signifie que le système pourrait fournir cette mémoire aux processus si nécessaire.

A quel endroit apparaissent les pages immenses dans la mémoire libre?

Par défaut, free -m n'affiche pas directement les pages immenses. Pour les voir, vous avez besoin des entrées /proc/meminfo telles que HugePages_Total, HugePages_Free et Hugepagesize.

Puisque le système d'exploitation réserve des pages immenses au démarrage, elles sont effectivement invisibles pour free -m. Elles sont verrouillées et isolées du pool de mémoire général.

Résumé

• La "mémoire disponible" insuffisante constatée vers 02h00 est due au remplissage du cache de pages Linux par des lectures de sauvegarde. Il s'agit d'un comportement normal qui n'indique pas une pénurie de mémoire.
• Les pages immenses réservées à IRIS ne sont pas affectées et continuent à servir efficacement la base de données.
• La mémoire réellement disponible pour les applications est mieux mesurée par la colonne disponible, qui montre que le système dispose encore d'une marge suffisante.

Mais attendez, que se passe-t-il si je n'utilise pas les Huge Pages?

Généralement, on n'utilise pas les Huge Pages sur les systèmes non productifs ou à mémoire limitée. Les gains de performances des Huge Pages ne sont généralement pas significatifs en dessous de 64 Go, bien qu'il soit toujours recommandé d'utiliser les Huge Pages pour protéger la mémoire partagée IRIS.

A propos. J'ai vu des sites rencontrer des problèmes en allouant des pages immenses moins grandes que la mémoire partagée, ce qui oblige IRIS à essayer de démarrer avec des tampons globaux très petits ou à échouer au démarrage si memlock est utilisé (envisagez memlock=192 pour les systèmes de production).

Sans Huge Pages, les segments de mémoire partagée IRIS ( globales, routines, gmheap, etc.) sont alloués à partir de pages de mémoire normales du système d'exploitation. Cela apparaîtrait sous la mémoire "utilisée" dans free -m. Cela contribuerait également à réduire la mémoire "disponible", car cette mémoire ne peut pas être facilement récupérée.

• utilisée – Beaucoup plus élevée, reflétant la mémoire partagée IRIS + le noyau + d'autres processus.
• libre – Probablement moins suffisante, car plus de RAM est allouée en permanence à IRIS dans le pool régulier.
• buf/cache – Augmenterait toujours pendant les sauvegardes, mais la marge apparente pour les processus semblerait plus restreinte, car la mémoire IRIS se trouve dans le même pool.
• disponible – Plus proche de la véritable “mémoire libre + cache récupérable” moins la mémoire IRIS. Cela semblerait plus petit que dans votre configuration Huge Pages.

Alors, faut-il utiliser Huge Pages dans des systèmes de production?

OUI!

Pour la protection de la mémoire. La mémoire partagée IRIS est protégée contre:

• Remplacement en cas de sollicitation de la mémoire.
• Concurrence avec les opérations du système de fichiers telles que les sauvegardes et les copies de fichiers, comme nous l'avons vu dans cet exemple.

Autres remarques - trop profondément dans les détails...

Comment les données sont-elles collectées?

La commande utilisée dans ^SystemPerformance pour une collecte de 24 heures (17 280 secondes) avec des coches toutes les 5 secondes est la suivante:

free -m -s 5 -c 17280 | awk '{now=strftime(""%m/%d/%y %T""); print now "" "" $0; fflush()}' > ","/filepath/logs/20250315_000100_24hours_5sec_12.log

Bonjour, utilisateurs CCR des sites TrakCare !

L'équipe Certification d'InterSystems Learning Services développe actuellement un examen de certification InterSystems CCR EHR (aussi appelé TrakCare) Specialist. Nous sollicitons les commentaires de notre communauté afin de finaliser le contenu de l'examen.

Comment puis-je donner mon avis ? Répondez à notre enquête d'analyse des tâches (JTA) ! Nous vous présenterons une liste de tâches et vous les évaluerez en fonction de leur importance et d'autres facteurs.

InterSystems a corrigé un défaut qui provoque l'introduction d'enregistrements de base de données et de journaux non valides lors de l'utilisation d'une syntaxe $LIST spécifique. La probabilité de rencontrer ce défaut est très faible, mais les impacts opérationnels peuvent être importants.

Produits concernés

Salut la Communauté!

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

📺 Fluidifier le parcours patient via l'e-admission

Salut la communauté !

Nous avons le plaisir de vous inviter à la réunion annuelle du Club Utilisateurs TrakCare sur Paris.

➡️ Journée Club Utilisateurs TrakCare - PARIS 2024
🗓  Date : Jeudi 28 mars 2024
⌚️ Heure : de 9h à 17h30
📍 Lieu: Châteauform' City Monceau Rio, 4 Place Rio de Janeiro - 75008 Paris

Salut la Communauté!

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

📺 Introduction aux produits InterSystems

Bonjour à tous,

L'équipe de certification d'InterSystems Learning Services est en train de développer un examen axé sur la création et l'utilisation de rapports TrakCare, et nous avons besoin de la contribution de notre communauté InterSystems TrakCare. Votre contribution sera utilisée pour évaluer et établir le contenu de l’examen.

Comment puis-je apporter ma contribution ? Nous vous présenterons une liste de tâches professionnelles et vous les évaluerez en fonction de leur importance ainsi que d'autres facteurs.

Quel effort cela implique-t-il ? Il faut environ 10 à 15 minutes pour remplir le sondage.

Comment puis-je accéder à l'enquête ? Vous pouvez y accéder ici :

Spécialiste des rapports InterSystems TrakCare

InterSystems France recherche une/un apprenti(e) Product Specialist (chef de produit junior) pour faire évoluer notre SIH #TrakCare (gestion médicale et administrative). 

La compétence et la disponibilité de ses équipes prévalent pour toujours viser l’excellence dans la créativité des solutions proposées.

Principales missions

Étude et planificatio

• Roadmap : participation à la planification de l'édition internationale de TrakCare (Core) et de l’Edition française. Recueillir, synthétiser et classer par ordre de priorité les demandes réglementaires et des clients.

Localisation du produit

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

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

Bonjur la Communauté!

La date de quatrième épisode d'une serie "Les 30' InterSystems" est déjà connue !

📅  Date : mardi 24 janvier 2023
⏱  Heure : 13:00 Heure d'été d'Europe centrale
⌛️  Durée : 30 minutes

Suite de tests d’E/S PerfTools #Analytics #Caché #HealthShare #InterSystems IRIS #Open Exchange #TrakCare But Cette paire d’outils (RanRead et RanWrite) est utilisée pour générer des événements de lecture et d’écriture aléatoires dans une base de données (ou une paire de bases de données) afin de tester les opérations d’entrée/sortie par seconde (IOPS). Ils peuvent être utilisés conjointement ou séparément pour tester la capacité matérielle des E/S, valider les IOPS cibles et garantir des temps de réponse disque acceptables. Les résultats recueillis à partir des tests d’E/S varient d’une configuration à l’autre en fonction du sous-système d’E/S. Avant d’exécuter ces tests, assurez-vous que la surveillance correspondante du système d’exploitation et du niveau de stockage est configurée pour capturer les mesures de performances des E/S en vue d’une analyse ultérieure. La méthode suggérée consiste à exécuter l’outil Performance du système fourni avec IRIS. Veuillez noter qu’il s’agit d’une mise à jour d’une version précédente, qui peut être trouvée ici. Installation Téléchargez les outils PerfTools.RanRead.xml et PerfTools.RanWrite.xml depuis GitHub ici. Importez des outils dans l’espace de noms USER. UTILISATEUR> faire $system. OBJ. Load(« /tmp/PerfTools.RanRead.xml »,"ckf ») UTILISATEUR> faire $system. OBJ. Load(« /tmp/PerfTools.RanWrite.xml »,"ckf ») Exécutez la méthode Help pour afficher tous les points d’entrée. Toutes les commandes sont exécutées dans USER. USER> do ##class(PerfTools.RanRead). Aide() • do ##class(PerfTools.RanRead). Setup(Répertoire,DatabaseName,SizeGB,LogLevel) Crée une base de données et un espace de noms portant le même nom. Le niveau logarithmique doit être compris entre 0 et 3, où 0 correspond à « aucun » et 3 à « verbeux ». • do ##class(PerfTools.RanRead). Exécuter(Répertoire,Processus,Dénombrement,Mode) Exécutez le test d’E/S en lecture aléatoire. Le mode est 1 (par défaut) pour le temps en secondes, 2 pour les itérations, en référence au paramètre Count précédent • do ##class(PerfTools.RanRead). Stop() Termine toutes les tâches en arrière-plan. • do ##class(PerfTools.RanRead). Reset() Supprime les statistiques des exécutions précédentes. Ceci est important pour l’exécution entre les tests, sinon les statistiques des exécutions précédentes sont moyennées dans la version actuelle. • do ##class(PerfTools.RanRead). Purger(Répertoire) Supprime l’espace de noms et la base de données du même nom. • do ##class(PerfTools.RanRead). Export(Répertoire) Exporte un résumé de tous les tests de lecture aléatoire dans un fichier texte délimité par des virgules. USER> do ##class(PerfTools.RanWrite). Aide() • do ##class(PerfTools.RanWrite). Setup(Répertoire,NomBase de données) Crée une base de données et un espace de noms portant le même nom. • do ##class(PerfTools.RanWrite). Run(Répertoire,NumProcs,RunTime,HangTime,HangVariationPct,Longueur du nom global,Profondeur globale du nœud,Longueur globale du sous-nœud) Exécutez le test d’E/S en écriture aléatoire. Tous les paramètres autres que le répertoire ont des valeurs par défaut. • do ##class(PerfTools.RanWrite). Stop() Termine toutes les tâches en arrière-plan. • do ##class(PerfTools.RanWrite). Reset() Supprime les statistiques des exécutions précédentes. • do ##class(PerfTools.RanWrite). Purger(Répertoire) Supprime l’espace de noms et la base de données du même nom. • do ##class(PerfTools.RanWrite). Export(Directory) Exporte un résumé de tout l’historique des tests d’écriture aléatoire dans un fichier texte délimité par des virgules. Coup monté Créez une base de données vide (pré-développée) appelée RAN au moins deux fois la taille de la mémoire de l’hôte physique à tester. Assurez-vous que la taille du cache du contrôleur de stockage de la base de données vide est au moins quatre fois supérieure à celle du contrôleur de stockage. La base de données doit être plus grande que la mémoire pour garantir que les lectures ne sont pas mises en cache dans le cache du système de fichiers. Vous pouvez créer manuellement ou utiliser la méthode suivante pour créer automatiquement un espace de noms et une base de données. USER> do ##class(PerfTools.RanRead). Configuration(« /ISC/tests/TMP »,"RAN »,200,1) Répertoire créé /ISC/tests/TMP/ Création d’une base de données de 200 Go dans /ISC/tests/TMP/ Base de données créée dans /ISC/tests/TMP/ Remarque : On peut utiliser la même base de données pour RanRead et RanWrite, ou utiliser des bases séparées si l’intention de tester plusieurs disques à la fois ou à des fins spécifiques. Le code RanRead permet de spécifier la taille de la base de données, mais pas le code RanWrite, il est donc probablement préférable d’utiliser la commande RanRead Setup pour créer des bases de données prédimensionnées souhaitées, même si l’on utilisera la base de données avec RanWrite. Méthodologie Commencez avec un petit nombre de processus et des temps d’exécution de 30 à 60 secondes. Ensuite, augmentez le nombre de processus, par exemple commencez à 10 tâches et augmentez de 10, 20, 40, etc. Continuez à exécuter les tests individuels jusqu’à ce que le temps de réponse soit constamment supérieur à 10 ms ou que les IOPS calculées n’augmentent plus de manière linéaire. L’outil utilise la commande ObjectScript VIEW qui lit les blocs de base de données en mémoire , donc si vous n’obtenez pas les résultats attendus, tous les blocs de base de données sont peut-être déjà en mémoire. À titre indicatif, les temps de réponse suivants pour les lectures aléatoires de base de données de 8 Ko et 64 Ko (non mises en cache) sont généralement acceptables pour les baies entièrement flash : • Moyenne <= 2ms • Ne pas dépasser <= 5ms Courir Pour RanRead, exécutez la méthode Run en augmentant le nombre de processus et en prenant note du temps de réponse au fur et à mesure. Le principal moteur des IOPS pour RanRead est le nombre de processus. USER> do ##class(PerfTools.RanRead). Exécuter(« /ISC/tests/TMP »,5,60) Outil de performance d’E/S à lecture aléatoire InterSystems Processus RanRead 11742 créant 5 processus de travail en arrière-plan. RanReadJob préparé 11768 pour le parent 11742 RanReadJob préparé 11769 pour le parent 11742 RanReadJob préparé 11770 pour le parent 11742 RanReadJob préparé 11771 pour le parent 11742

RanReadJob préparé 11772 pour le parent 11742 Démarrer 5 processus pour le numéro de tâche RanRead 11742 maintenant!
Pour terminer l’exécution : faites ##class(PerfTools.RanRead). Stop() En attente de finir.................. Tâches en arrière-plan de lecture aléatoire terminées pour le parent 11742 Travail RanRead 5 processus de 11742 (62,856814 secondes) Temps de réponse moyen = 1,23 ms IOPS calculé pour la tâche RanRead 11742 = 4065 Le paramètre Mode de la commande Run utilise par défaut le mode 1, qui utilise le paramètre Count (60 dans l’exemple ci-dessus) comme secondes. Si vous définissez Mode sur 2, le paramètre Count est défini sur un nombre d’itérations par processus, donc s’il est défini sur 100 000, chacune des 5 tâches lira 100 000 fois dans la base de données. C’est le mode utilisé à l’origine par ce logiciel, mais les exécutions chronométrées permettent une coordination plus précise avec des outils de surveillance tels que System Performance, qui sont également chronométrés, et l’outil RanWrite . Pour RanWrite, exécutez la méthode Run en diminuant le paramètre Hangtime. Ce paramètre indique le temps d’attente entre les écritures en secondes et constitue le principal moteur d’IOPS pour RanWrite. On peut également augmenter le nombre de processus en tant que moteur pour IOPS. USER> do ##class(PerfTools.RanWrite). Exécuter(« /ISC/tests/TMP »,1,60,.001) Processus RanWrite 11742 créant 1 processus de travail en arrière-plan. Préparé RanWriteJob 12100 pour parent 11742 Démarrer 1 processus pour le numéro de tâche RanWrite 11742 maintenant! Pour terminer l’exécution : faites ##class(PerfTools.RanWrite). Stop() En attente de finir.................. Travaux d’écriture aléatoire en arrière-plan terminés pour le parent 11742 Les processus 1 de la tâche RanWrite 11742 (60 secondes) avaient un temps de réponse moyen = 0,912 ms IOPS calculé pour la tâche RanWrite 11742 = 1096 Les autres paramètres de RanWrite peuvent généralement être laissés à leurs valeurs par défaut en dehors de circonstances inhabituelles. Ces paramètres sont les suivants : - HangVariationPct : variance sur le paramètre hangtime, utilisée pour imiter l’incertitude ; c’est un pourcentage du paramètre précédent

• Longueur globale du nom : RanWrite choisit aléatoirement un nom global, et c’est la longueur de ce nom. Par exemple, s’il est défini sur 6, le Global peut ressembler à Xr6opg- Profondeur du nœud global et Longueur du sous-nœud global : le Global supérieur n’est pas celui qui est rempli. Ce qui est réellement rempli, ce sont des sous-nœuds, donc définir ces valeurs sur 2 et 4 donnerait une commande comme « set ^Xr6opg(« drb7 »,"xt8v ») = [value] ». Le but de ces deux paramètres et de la longueur du nom global est de s’assurer que le même global n’est pas défini encore et encore, ce qui entraînerait un minimum d’événements d’E/S Pour exécuter RanRead et RanWrite ensemble, au lieu de « do », utilisez la commande « job » pour les deux afin de les exécuter en arrière-plan. Résultats Pour obtenir les résultats simples pour chaque exécution enregistrés dans USER dans la table SQL PerfTools.RanRead et PerfTools.RanWrite, utilisez la commande Export pour chaque outil comme suit. Pour exporter le jeu de résultats dans un fichier texte délimité par des virgules (csv), exécutez la commande suivante : USER> do ##class(PerfTools.RanRead). Exporter(« /ISC/tests/TMP/ « ) Exportation du résumé de toutes les statistiques de lecture aléatoire vers /usr/iris/db/zranread/PerfToolsRanRead_20221023-1408.txt Terminé. Analyse Il est recommandé d’utiliser l’outil SystemPerformance intégré pour acquérir une véritable compréhension du système analysé. Les commandes de SystemPerformance doivent être exécutées dans l’espace de noms %SYS. Pour passer à cela, utilisez la commande ZN: UTILISATEUR> ZN « %SYS » Pour trouver des détails sur les goulots d’étranglement dans un système, ou si l’on a besoin de plus de détails sur la façon dont il fonctionne à ses IOPS cibles, il faut créer un profil SystemPerformance avec une acquisition de données à cadence élevée : %SYS> set rc=$$addprofile^SystemPerformance(« 5minhighdef »,"Un échantillonnage d’exécution de 5 minutes toutes les secondes »,1 300) Ensuite, exécutez ce profil (à partir de %SYS) et revenez immédiatement à USER et démarrez RanRead et/ou RanWrite en utilisant « job » plutôt que « do »: %SYS>set runid=$$run^SystemPerformance(« 5minhighdef ») %SYS> ZN « UTILISATEUR » USER> job ##class(PerfTools.RanRead). Exécuter(« /ISC/tests/TMP »,5,60) USER> job ##class(PerfTools.RanWrite). Exécuter(« /ISC/tests/TMP »,1,60,.001) On peut alors attendre la fin du travail SystemPerformance et analyser le fichier html résultant à l’aide d’outils tels que yaspe. Nettoyer Une fois l’exécution terminée des tests, supprimez l’historique en exécutant : %SYS> do ##class(PerfTools. RanRead). Reset() Vérifiez l’application associée sur InterSystems Open Exchange

Bonjur la Communauté!

Le troisième épisode d'une serie "Les 30' InterSystems" se passera bientôt !

📅  Date : mardi 29 novembre 2022
⏱  Heure : 13:00 Heure d'été d'Europe centrale
⌛️  Durée : 30 minutes

Bonjur la Communauté!

Le deuxième épisode d'une serie "Les 30' InterSystems" sera aujourd'hui !

📅  Date: mardi 18 octobre 2022

⏱  Heure: 13:00 Heure d'été d'Europe centrale

⌛️  Durée: 30 minutes

Bonjur la Communauté!

Nous sommes ravi de partager des nouvelles exceptionnelles avec vous tous! Mardi prochain une serie "Les 30' InterSystems" ferra de retour pour la troisième saison!

📅  Date: mardi 20 septembre 2022

⏱  Heure: 13:00 Heure d'été d'Europe centrale

⌛️  Durée: 30 minutes

Bonjour la communauté !

Cet article vise à donner un aperçu des webservices REST JSON développés pour TrakCare.

Ces webservices ont été développés dans le but de permettre aux utilisateurs d’accéder aux données de TrakCare depuis l’extérieur, notamment via des applications externes.

Ils sont développés en REST avec ObjectScript, et permettent d’accéder aux données via quatre modes :