#SOAP

Salut les gars,

Il y a quelques jours, un client m'a contacté avec le souhait d'améliorer son application existante, qui utilise les services SOAP afin de partager la même autorisation avec sa nouvelle API d'application basée sur REST. Comme leur nouvelle application utilise OAuth2, le défi était clair : comment transmettre le token d'accès avec la requête SOAP au serveur.

Après avoir passé du temps sur Google, il s'est avéré que l'un des moyens possibles d'y parvenir consistait à ajouter un élément d'en-tête supplémentaire à l'enveloppe SOAP, puis à s'assurer que l'implémentation du WebService fait ce qui est nécessaire pour valider le jeton d'accèsю

Il y a souvent des questions concernant la configuration idéale du Serveur Web HTTPD Apache pour HealthShare.  Le contenu de cet article décrit la configuration initiale recommandée du serveur Web pour tout produit HealthShare. 

APour commencer, la version 2.4.x (64 bits) d'Apache HTTPD est recommandée.  Des versions antérieures comme 2.2.x sont disponibles, mais la version 2.2 n'est pas recommandée pour les performances et l'évolutivité de HealthShare.

Configuration d'Apache

Module API Apache sans NSD {#ApacheWebServer-ApacheAPIModulewithoutNSD}

HealthShare requiert l'option d'installation Apache API Module without NSD. La version des modules liés dynamiquement dépend de la version d'Apache :

• CSPa24.so (Apache Version 2.4.x)

La configuration de Caché Server Pages dans le fichier Apache httpd.conf doit être effectuée par l'installation de HealthShare qui est détaillée plus loin dans ce document. Cependant, la configuration peut être effectuée manuellement. Pour plus d'informations, veuillez consulter le guide de configuration d'Apache dans la documentation d'InterSystems : Recommended Option: Apache API Module without NSD (CSPa24.so)

Recommandations concernant le module multiprocesseur d'Apache (MPM) {#ApacheWebServer-ApacheMulti-ProcessingModule(MPM)Recommendations}

Apache Prefork MPM Vs. Worker MPM {#ApacheWebServer-ApachePreforkMPMVs.WorkerMPM}

Le serveur web HTTPD Apache est livré avec trois modules multiprocesseurs (MPM) : Prefork, Worker et Event.  Les MPM sont responsables de la liaison avec les ports réseau de la machine, de l'acceptation des requêtes et de l'envoi de fils pour traiter ces requêtes. Par défaut, Apache est généralement configuré avec le MPM Prefork, qui n'est pas adapté à des charges de travail importantes en termes de transactions ou d'utilisateurs simultanés.

Pour les systèmes de production HealthShare, le MPM Apache Worker doit être activé pour des raisons de performance et d'évolutivité. Worker MPM est préféré pour les raisons suivantes :

• Prefork MPM utilise plusieurs processus enfants avec un fil d'exécution chacun et chaque processus gère une connexion à la fois. Lorsque Prefork est utilisé, les demandes simultanées souffrent car, comme chaque processus ne peut traiter qu'une seule demande à la fois, les demandes sont mises en attente jusqu'à ce qu'un processus serveur se libère. De plus, afin d'évoluer, il faut plus de processus enfants Prefork, ce qui consomme des quantités importantes de mémoire.
• Worker MPM utilise plusieurs processus enfants avec de nombreux fils d'exécution chacun. Chaque fil d'exécution gère une connexion à la fois, ce qui favorise la concurrence et réduit les besoins en mémoire. Worker gère mieux la concurrence que Prefork, car il y aura généralement des fils d'exécution libres disponibles pour répondre aux demandes au lieu des processus Prefork à un seul fil d'exécution qui peuvent être occupés.

Paramètres MPM pour Apache Worker {#ApacheWebServer-ApacheWorkerMPMParameters}

En utilisant des fils d'exécution pour servir les demandes, Worker est capable de servir un grand nombre de demandes avec moins de ressources système que le serveur basé sur le processus Prefork. 
Les directives les plus importantes utilisées pour contrôler le MPM de Worker sont ThreadsPerChild qui contrôle le nombre de fils d'exécution déployés par chaque processus enfant et MaxRequestWorkers qui contrôle le nombre total maximum de fils d'exécution pouvant être lancés.
Les valeurs recommandées de la directive commune Worker MPM sont détaillées dans le tableau ci-dessous :

<th>
  Valeur recommandée
</th>

<th>
  Commentaires
</th>

<td>
  Nombre maximal d'utilisateurs simultanés de HealthShare Clinical Viewer, ou des quatre autres composants de HealthShare, fixé à la somme de toutes les tailles de pool de services commerciaux entrants pour toutes les productions d'interfaces définies. * Note : Si toutes les inconnues au moment de la configuration commencent par une valeur de '1000'
</td>

<td>
    MaxRequestWorkers fixe la limite du nombre de demandes simultanées qui seront servies, c'est-à-dire qu'il restreint le nombre total de fils d'exécution qui seront disponibles pour servir les clients. Il est important que MaxRequestWorkers soit défini correctement car s'il est trop faible, les ressources seront gaspillées et s'il est trop élevé, les performances du serveur seront affectées. Notez que lorsque le nombre de connexions tentées est supérieur au nombre de travailleurs, les connexions sont placées dans une file d'attente. La file d'attente par défaut peut être ajustée avec la directive ListenBackLog.  
</td>

<td>
  250
</td>

<td>
    MaxSpareThreads traite les threads inactifs à l'échelle du serveur. S'il y a trop de threads inactifs dans le serveur, les processus enfants sont tués jusqu'à ce que le nombre de threads inactifs soit inférieur à ce nombre. L'augmentation du nombre de threads inutilisés par rapport à la valeur par défaut permet de réduire les risques de réactivation des processus.  
</td>

<td>
  75
</td>

<td>
    MinSpareThreads traite les fils d'exécution inactifs à l'échelle du serveur. S'il n'y a pas assez de fils d'exécution libres dans le serveur, des processus enfants sont créés jusqu'à ce que le nombre de fils d'exécution libres soit supérieur à ce nombre. En réduisant le nombre de fils d'exécution inutilisés par rapport à la valeur par défaut, on réduit les risques de réactivation des processus.  
</td>

<td>
  MaxRequestWorkers divisé par ThreadsPerChild
</td>

<td>
    Valeur maximale de MaxRequestWorkers pour la durée de vie du serveur. ServerLimit est une limite stricte du nombre de processus enfants actifs, et doit être supérieure ou égale à la directive MaxRequestWorkers divisée par la directive ThreadsPerChild. Avec worker, n'utilisez cette directive que si vos paramètres MaxRequestWorkers et ThreadsPerChild nécessitent plus de 16 processus serveur (valeur par défaut).  
</td>

<td>
  20
</td>

<td>
    La directive StartServers définit le nombre de processus de serveur enfant créés au démarrage. Comme le nombre de processus est contrôlé dynamiquement en fonction de la charge, il y a généralement peu de raisons d'ajuster ce paramètre, sauf pour s'assurer que le serveur est prêt à gérer un grand nombre de connexions dès son démarrage.  
</td>

<td>
  25
</td>

<td>
    Cette directive définit le nombre de threads créés par chaque processus enfant, 25 par défaut. Il est recommandé de conserver la valeur par défaut car l'augmenter pourrait conduire à une dépendance excessive vis-à-vis d'un seul processus.  
</td>

Pour plus d'informations, veuillez consulter la documentation relative à la version d'Apache concernée :

• Apache 2.4 Directives communes de MPM

Exemple de configuration MPM du travailleur Apache 2.4 {#ApacheWebServer-ExampleApache2.4WorkerMPMConfiguration}

Cette section explique comment configurer Worker MPM pour un serveur Web RHEL7 Apache 2.4 nécessaire pour prendre en charge jusqu'à 500 utilisateurs simultanés de TrakCare.

1. Vérifiez d'abord le MPM en utilisant la commande suivante :
2. Modifiez le fichier de configuration /etc/httpd/conf.modules.d/00-mpm.conf selon les besoins, en ajoutant et en supprimant le caractère de commentaire # afin que seuls les modules Worker MPM soient chargés. Modifiez la section Worker MPM avec les valeurs suivantes dans le même ordre que ci-dessous :
3. Redémarrer Apache
4. Après avoir redémarré Apache avec succès, validez les processus worker en exécutant les commandes suivantes. Vous devriez voir quelque chose de similaire à ce qui suit confirmant le processus httpd.worker :

Renforcement d'Apache {#ApacheWebServer-ApacheHardening}

Modules requis pour Apache {#ApacheWebServer-ApacheRequiredModules}

L'installation du paquetage officiel d'Apache activera par défaut un ensemble spécifique de modules Apache. Cette configuration par défaut d'Apache chargera ces modules dans chaque processus httpd. Il est recommandé de désactiver tous les modules qui ne sont pas nécessaires à HealthShare pour les raisons suivantes :

• réduire l'empreinte du processus du démon httpd.
• réduire le risque d'un défaut de segmentation dû à un module malveillant.
• réduire les vulnérabilités en matière de sécurité.

Le tableau ci-dessous détaille les modules Apache recommandés pour HealthShare. Tout module qui ne figure pas dans la liste ci-dessous peut être désactivé :

Désactivation des modules

Les modules inutiles doivent être désactivés pour renforcer la configuration qui réduira les vulnérabilités de sécurité. Le client est responsable de la politique de sécurité du serveur web. Au minimum, les modules suivants doivent être désactivés.

Apache SSL/TLS {#ApacheWebServer-ApacheSSL/TLS}

Pour protéger les données en transit, assurer la confidentialité et l'authentification, InterSystems recommande que toutes les communications TCP/IP entre les serveurs et les clients de HealthShare soient cryptées avec SSL/TLS, et InterSystems recommande également d'utiliser HTTPS pour toutes les communications entre le navigateur client des utilisateurs et la couche serveur web de l'architecture proposée.   Veillez à consulter les politiques de sécurité de votre organisation pour vous assurer de la conformité à toute exigence de sécurité spécifique de votre organisation. 

Le client est responsable de la fourniture et de la gestion des certificats SSL/TLS. Si vous utilisez des certificats SSL, ajoutez le module ssl_ (mod_ssl.so).

Paramètres supplémentaires de durcissement d'Apache {#ApacheWebServer-AdditionalHardeningApacheParameters}

Pour renforcer la configuration d'Apache, apportez les modifications suivantes au fichier httpd.conf :

• TraceEnable doit être désactivé pour éviter les problèmes potentiels de traçage intersites.

• ServerSignature doit être désactivé afin que la version du serveur web ne soit pas affichée.

Paramètres de configuration supplémentaires d'Apache {#ApacheWebServer-SupplementalApacheConfigurationParameters}

Keep-Alive {#ApacheWebServer-Keep-Alive}

Le paramètre Apache Keep-Alive permet d'utiliser la même connexion TCP pour la communication HTTP au lieu d'ouvrir une nouvelle connexion pour chaque nouvelle demande, c'est-à-dire que Keep-Alive maintient une connexion persistante entre le client et le serveur. Lorsque l'option Keep-Alive est activée, l'amélioration des performances provient de la réduction de l'encombrement du réseau, de la réduction de la latence des requêtes ultérieures et de la diminution de l'utilisation du CPU causée par l'ouverture simultanée de connexions. L'option Keep-Alive est activée par défaut et la norme HTTP v1.1 stipule qu'elle doit être présumée activée.

Cependant, l'activation de la fonction Keep-Alive présente des inconvénients : Internet Explorer doit être IE10 ou supérieur pour éviter les problèmes de délai d'attente connus avec les anciennes versions d'IE. De même, les intermédiaires tels que les pare-feu, les équilibreurs de charge et les proxies peuvent interférer avec les "connexions TCP persistantes" et entraîner une fermeture inattendue des connexions.  

Lorsque vous activez la fonction "Keep-Alive", vous devez également définir le délai d'attente de cette fonction. Le délai d'attente par défaut pour Apache est trop faible et doit être augmenté pour la plupart des configurations, car des problèmes peuvent survenir en cas de rupture des requêtes AJAX (c'est-à-dire hyperevent). Ces problèmes peuvent être évités en s'assurant que le délai d'attente du serveur est supérieur à celui du client.  En d'autres termes, c'est le client, et non le serveur, qui devrait fermer la connexion.  Des problèmes surviennent - principalement dans IE mais dans une moindre mesure dans d'autres navigateurs - lorsque le navigateur tente d'utiliser une connexion (en particulier pour un POST) dont il s'attend à ce qu'elle soit ouverte. 

Voir ci-dessous les valeurs recommandées de KeepAlive et KeepAliveTimeout pour un serveur Web HealthShare.

Pour activer KeepAlive dans Apache, apportez les modifications suivantes au fichier httpd.conf :

Psserelle CSP {#ApacheWebServer-CSPGateway}

Pour le paramètre CSP Gateway KeepAlive, laissez la valeur par défaut No Action car le statut KeepAlive est déterminé par les titres de la réponse HTTP pour chaque requête.

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é.

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.

Pourtant, les mesures que nous devons prendre sont assez similaires.

Conditions préalables

• 2 instances InterSystems IRIS
• L'instance InterSystems API Managemen  

Allons-y

Voici ce que nous devons faire :

1. Créer un flux ascendant.

Un flux ascendant représente un nom d'hôte virtuel et peut être utilisé pour équilibrer la charge des demandes entrantes sur plusieurs services (cibles). Par exemple, un flux ascendant nommé service.v1.xyz recevrait des demandes pour un service dont l'hôte est service.v1.xyz. Les requêtes pour ce service seront envoyées par procuration aux cibles définies dans l'amont.

Un flux ascendant comprend également un vérificateur de santé, qui peut activer et désactiver les cibles en fonction de leur capacité ou de leur incapacité à répondre aux demandes.

Pour commencer :

• Ouvrir le portail d'administration IAM
• Allez dans Workspaces
• Choisissez votre espace de travail
• Ouvrez les flux ascendants (Upstreams)
• Cliquez sur le bouton "New Upstream"

Après avoir cliqué sur le bouton "New Upstream", vous verrez apparaître un formulaire où vous pourrez saisir quelques informations de base sur le flux ascendant (il y a beaucoup d'autres propriétés) :

Saisissez nom - il s'agit d'un nom d'hôte virtuel que nos services utiliseraient. Il n'est pas lié aux enregistrements DNS. Je recommande de lui attribuer une valeur inexistante pour éviter toute confusion. Si vous voulez en savoir plus sur les autres propriétés, consultez la documentation. Sur la capture d'écran, vous pouvez voir que j'ai nommé de manière imaginative le nouveau flux ascendant comme myupstream.  

2. Créer des cibles.

Les cibles sont des serveurs backend qui exécutent les requêtes et renvoient les résultats au client. Allez dans Upstreams et cliquez sur le nom du flux ascendant que vous venez de créer (et NON sur le bouton de mise à jour) :

Vous verrez toutes les cibles existantes (aucune jusqu'à présent) et le bouton "Nouvelle cible". Cliquez dessus :

Ensuite, définissez une cible dans le nouveau formulaire. Seuls deux paramètres sont disponibles :

• cible - hôte et port du serveur backend
• Pondération - priorité relative donnée à ce serveur (plus de pondération - plus de demandes sont envoyées à cette cible)

J'ai ajouté deux cibles :

3. Créer un service

A présent que nous avons notre flux ascendant, nous devons lui envoyer des requêtes.  Pour cela, nous utilisons Service.
Les entités Service, comme leur nom l'indique, sont des abstractions de chacun de vos services en amont. Des exemples de services seraient un microservice de transformation des données, une API de facturation, etc. Nous allons créer un service ciblant notre instance IRIS, allez dans Services et cliquez sur le bouton "Nouveau service" :

Définissez les valeurs suivantes :

Conservez les valeurs par défaut pour tout le reste (y compris le port : 80).

Après avoir créé le service, vous le verrez dans une liste de services. Copiez l'ID du service quelque part, nous en aurons besoin plus tard.

4. Créer un itinéraire

Les Itinéraires définissent les règles permettant de répondre aux demandes des clients. Chaque Itinéraire est associé à un Service, et un Service peut avoir plusieurs Itinéraires associés. Chaque demande correspondant à un Itinéraire donné sera transmise par proxy au Service qui lui est associé.

La combinaison des Itinéraires et des Services (et la séparation des préoccupations entre eux) offre un mécanisme de routage puissant avec lequel il est possible de définir des points d'entrée très fins dans l'IAM menant à différents services en amont de votre infrastructure.

Maintenant, créons un itinéraire. Allez dans le menu Routes et appuyez sur le bouton "New Route".

Définissez les valeurs dans le formulaire de création de l'Itinéraire :

Et c'est fini !

Envoyez une requête à http://localhost:8000/api/atelier/ (notez la barre oblique à la fin) et elle sera servie par l'un de nos deux backends.  

Conclusion

IAM offre une infrastructure de gestion des API hautement personnalisable, permettant aux développeurs et aux administrateurs de prendre le contrôle de leurs API.  

Liens

• Documentation
• IAM Announcement 
• Working with IAM article

Question

Quelle fonctionnalité souhaitez-vous voir configurée avec IAM ?