Ce Template s'agit d'un modèle de l' application API REST construite avec ObjectScript dans Intersystems IRIS. Il dispose également d'une spécification OPEN API, peut être développé avec Docker et VSCode et peut être déployé en tant que module IPM.

Conditions préalables

Assurez-vous que vous avez installé git et Docker desktop.

Installation avec IPM

zpm:USER>install rest-api-template

Installation pour le développement

Créez votre référentiel à partir d'un modèle.

Clonez/git le dépôt dans n'importe quel répertoire local, par exemple comme indiqué ci-dessous (je montre ici tous les exemples liés à ce

Bonjour à la communauté,

Dans la première partie, nous avons décrit tous les packages, les bibliothèques utilisées et les services REST.  J'aimerais maintenant détailler un peu plus les services convertisseur et validateur.  Par défaut, OpenAPI-Suite envoie une requête HTTP  converter.swagger.io si a spécification est de version inférieure à 3.0 et une autre requête HTTP à validator.swagger.io pour simplifier la structure de la spécification.  

Bien que l'utilisation d'utilitaires en ligne soit pratique, dans certains cas, nous pourrions préférer avoir notre propre instance du convertisseur et du validateur.  Par exemple, si OpenAPI-Suite est mis à disposition sur un serveur dans une organisation pour les développeurs ObjectScript, il peut être préférable d'éviter les requêtes vers les services externes (confidentialité, éviter les limites de taux de demande,...).  Ceux-ci sont disponibles en images Docker, il suffit d'exécuter : 

docker run -d -p 8085:8080 --name swagger-converter swaggerapi/swagger-converter:latest
docker run -d -p 8086:8080 --name swagger-validator-v2 swaggerapi/swagger-validator-v2:latest

Salut la communauté,

J'aimerais vous présenter ma dernière application OpenAPI-Suite, c'est un ensemble d'outils permettant de générer du code ObjectScript à partir d'une specification OpenAPI version 3.0. L'application permet de:

• Générer les classes serveur REST.  C'est assez similaire au code généré par ^%REST, la valeur ajoutée est le support de la version 3.0.
• Générer les classes pour un client HTTP.
• Générer une production cliente (business services, business operation, business process, Ens.Request, Ens.Response).
• Disposer d'une interface web pour générer et télécharger le code ou générer et compiler directement sur le serveur.
• Convertir les spécifications de version 1.x, 2.x en version 3.0.

Aperçu

OpenAPI-Suite est divisée en plusieurs packages et utilise différentes bibliothèques de la communauté des développeurs ainsi que des services REST publics.  Vous pouvez voir sur le schéma ci-dessous, tous les packages développés et les bibliothèques et services web utilisés:
 

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

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

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

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

Pour créer votre serveur FHIR, il faut ajouter les instructions

Salut la communauté,

J’aimerais profiter de notre sujet sur la capture pour les Entrepôts de Données de Santé (EDS) pour vous présenter comment créer rapidement des clients HTTP SOAP et REST.  IRIS ainsi que des applications disponibles sur Open Exchange proposent des solutions permettant de les générer à partir d’un WSDL ou d’une spécification swagger.

Client SOAP

Pour créer un client SOAP, rien de plus simple, vous avez juste besoin du WSDL.  Un assistant est disponible depuis le Studio IRIS,  il permet de générer vos classes pour un client web service, mais également les business services et business operations si vous souhaitez le consommer avec le framework d'interopérabilité.

L'interopérabilité des soins de santé permet d'améliorer les soins aux patients, de réduire les coûts des prestataires de soins et de fournir une image plus précise aux prestataires. Cependant, avec un si grand nombre de systèmes différents, les données sont formatées de nombreuses manières différentes. De nombreuses normes ont été créées pour tenter de résoudre ce problème, notamment HL7v2, HL7v3 et CDA, mais toutes présentent des inconvénients.

FHIR (Fast Healthcare Interoperability Resources), ou Ressources rapides d'interopérabilité des soins de santé, est un nouveau format pour les

1. Fhir-client-net

Ceci est un client fhir simple en c# pour s'exercer avec les ressources fhir et les requêtes CRUD vers un serveur fhir.
Notez que pour la majeure partie, l'autocomplétion est activée.

GitHub

• 1. Fhir-client-net
• 2. Préalables
• 3. Installation
  • 3.1. Installation pour le développement
  • 3.2. Portail de gestion et VSCode
  • 3.3. Avoir le dossier ouvert à l'intérieur du conteneur
• 4. Serveur FHIR
• 5. Présentation pas à pas
  • 5.1. Partie 1
  • 5.2. Partie 2
  • 5.3. Partie 3
  • 5.4. Partie 4
  • 5.5. Conclusion de la présentation
• 7. Comment commencer le codage
• 8. Ce qu'il y a dans le référentiel
  • 8.1.

1. Fhir-client-python

Ceci est un client fhir simple en python pour s'exercer avec les ressources fhir et les requêtes CRUD vers un serveur FHIR.
Notez que pour la plupart, l'autocomplétion est activée, c'est la principale raison d'utiliser fhir.resources.

GitHub

• 1. Fhir-client-python
• 2. Préalables
• 3. Installation
  • 3.1. Installation pour le dévelopment
  • 3.2. Portail de gestion et VSCode
  • 3.3. Avoir le dossier ouvert à l'intérieur du conteneur
• 4. Serveur FHIR
• 5. Présentation pas à pas
  • 5.1. Partie 1
  • 5.2. Partie 2
  • 5.3. Partie 3
  • 5.4. Partie 4
  • 5.5. Conclusion de la présentation
• 6.

1. Fhir-client-java

Ceci est un client fhir simple en java pour s'exercer avec les ressources fhir et les requêtes CRUD vers un serveur fhir.
Notez que pour la majeure partie, l'autocomplétion est activée.

GitHub

• 1. Fhir-client-java
• 2. Préalables
• 3. Installation
  • 3.1. Installation pour le développement
  • 3.2. Portail de gestion et VSCode
  • 3.3. Avoir le dossier ouvert à l'intérieur du conteneur
• 4. Serveur FHIR
• 5. Présentation pas à pas
  • 5.1. Partie 1
  • 5.2. Partie 2
  • 5.3. Partie 3
  • 5.4. Partie 4
  • 5.5. Conclusion de la présentation
• 6. Comment commencer le codage
• 7. Ce qu'il y a dans le référentiel
  • 7.

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 :

• List : qui permet de récupérer un ensemble de données à partir d’un filtre (par exemple la liste d’épisodes pour un certain patient) ;
• Open : qui renvoie une donnée spécifique récupérée via son ID interne ou une

Dans le premier article de cette série, nous avons vu comment lire un "gros" volume de données dans le corps brut d'une méthode HTTP POST et l'enregistrer dans une base de données en tant que propriété de flux d'une classe. Le deuxième article explique comment enregistrer des fichiers et leurs noms dans un format JSON.

Examinons maintenant de plus près l'idée d'envoyer des fichiers volumineux par parties au niveau du serveur. Il existe plusieurs approches que nous pouvons utiliser pour y parvenir. Cet article traite de l'utilisation de l'en-tête Transfer-Encoding pour indiquer un transfert par blocs. La spécification HTTP/1.1 a introduit l'en-tête Transfer-Encoding, et RFC 7230, section 4.1 l'a décrit, mais il n'est pas mentionné dans la spécification HTTP/2. 

Dans le premier article de cette série, nous avons vu comment lire un "gros" volume de données dans le corps brut d'une méthode HTTP POST et l'enregistrer dans une base de données en tant que propriété de flux d'une classe. Voyons maintenant comment enregistrer de telles données et métadonnées au format JSON.

Malheureusement, Client REST avancé (Advanced REST Client) ne permet pas de composer des objets JSON avec des données binaires comme valeur d'une clé (ou peut-être que je n'ai simplement pas trouvé comment le faire), j'ai donc décidé d'écrire un client simple en ObjectScript pour

Une question a été posée dans la communauté des développeurs d'InterSystems concernant la possibilité de créer une interface TWAIN pour une application Caché. Il y a eu plusieurs suggestions intéressantes sur la façon d'obtenir des données d'un périphérique d'acquisition d'images sur un client Web vers un serveur, puis de stocker ces données dans une base de données 

Toutefois, pour mettre en œuvre l'une de ces suggestions, vous devez être en mesure de transférer des données d'un client Web vers un serveur de base de données et de stocker les données reçues dans une propriété de classe (ou une cellule de tableau, comme c'était le cas dans la question). Cette technique peut être utile non seulement pour transférer des données d'images provenant d'un périphérique TWAIN, mais aussi pour d'autres tâches telles que l'organisation d'une archive de fichiers, d'un partage d'images, etc. 

Ainsi, l'objectif principal de cet article est de montrer comment écrire un service RESTful pour obtenir des données du corps d'une commande HTTP POST, soit à l'état brut, soit enveloppées dans une structure JSON.

Dans cette série d'articles en trois parties, il est montré comment vous pouvez utiliser IAM pour ajouter simplement de la sécurité, selon les normes OAuth 2.0, à un service précédemment non authentifié déployé dans IRIS.

Dans la première partie, nous avons fourni des informations sur OAuth 2.0 ainsi que des définitions et des configurations initiales d'IRIS et d'IAM afin de faciliter la compréhension de l'ensemble du processus de sécurisation de vos services.

La deuxième partie discute et montre en détail les étapes nécessaires pour configurer IAM pour valider le jeton d'accès présent dans la

Dans cette série d'articles en trois parties, il est montré comment vous pouvez utiliser IAM pour ajouter simplement de la sécurité, selon les normes OAuth 2.0, à un service précédemment non authentifié déployé dans IRIS.

Dans la première partie, nous avons fourni des informations sur OAuth 2.0 ainsi que des définitions et des configurations initiales d'IRIS et d'IAM afin de faciliter la compréhension de l'ensemble du processus de sécurisation de vos services.

Cette partie va maintenant discuter et montrer en détail les étapes nécessaires pour configurer IAM pour valider le jeton d'accès

Introduction

Aujourd'hui, de nombreuses applications utilisent le cadre d'autorisation ouvert (OAuth) pour accéder aux ressources de toutes sortes de services de manière sûre, fiable et efficace. InterSystems IRIS est déjà compatible avec le cadre OAuth 2.0, en fait, il y a un excellent article dans la communauté concernant OAuth 2.0 et InterSystems IRIS dans le lien suivant ici.

Toutefois, avec l'avènement des outils de gestion des API, certaines organisations l'utilisent comme point unique d'authentification, empêchant les demandes non autorisées d'arriver aux services descendants et

InterSystems API Management (IAM) - c'est une nouvelle fonctionnalité de la plate-forme de données InterSystems IRIS, qui vous permet de surveiller, de contrôler et de gérer le trafic vers et à partir des API basées sur le Web au sein de votre infrastructure informatique. Au cas où vous l'auriez manqué, voici le lien vers l'annonce. Et voici un article expliquant comment commencer à travailler avec IAM.

Dans cet article, nous allons utiliser InterSystems API Management pour assurer l'équilibrage de charge d'une API.

Dans notre cas, nous avons 2 instances InterSystems IRIS avec /api/atelier REST API que nous voulons publier pour nos clients.

Il y a de nombreuses raisons différentes pour lesquelles nous pourrions vouloir faire cela, par exemple :

• Équilibrage de la charge pour répartir la charge de travail entre les serveurs.
• Déploiement bleu-vert : nous avons deux serveurs, l'un "prod", l'autre "dev" et nous pouvons vouloir passer de l'un à l'autre.
• Déploiement canary: nous pourrions publier la nouvelle version sur un seul serveur et y transférer 1% des clients.
• Configuration de haute disponibilité
• etc.

Introduction

Nous sommes à l'ère de l'économie multiplateforme et les API sont la "colle " de ce scénario numérique. Étant donné leur importance, les développeurs les considèrent comme un service ou un produit à consommer. Par conséquent, l'expérience d'utilisation est un facteur crucial de leur succès.

Afin d'améliorer cette expérience, des normes de spécification telles que la spécification OpenAPI (OAS) sont de plus en plus adoptées dans le développement des API RESTFul.

IRIS ApiPub - qu'est-ce que c'est ?

IRIS ApiPub est un projet de type code source ouvert Open Source dont l'objectif