Se connecter à un serveur IBM MQ depuis un workflow dans Azure Logic Apps
S’applique à : Azure Logic Apps (Consommation + Standard)
Cet article explique comment accéder à un serveur MQ hébergé par Azure ou local à partir d’un flux de travail dans Azure Logic Apps à l’aide du connecteur MQ. Vous pouvez ensuite créer des workflows automatiques qui reçoivent et envoient des messages stockés sur votre serveur MQ. Par exemple, votre workflow peut rechercher un seul message dans une file d’attente, puis exécuter d’autres actions.
Le connecteur MQ fournit un wrapper autour d’un client Microsoft MQ, qui inclut toutes les fonctionnalités de messagerie à communiquer avec un serveur MQ distant sur un réseau TCP/IP. Ce connecteur définit les connexions, les opérations et les paramètres pour appeler le client MQ.
Versions prises en charge d’IBM WebSphere MQ
- MQ 7.5
- MQ 8.0
- MQ 9.0, 9.1, 9.2 et 9.3
Référence technique du connecteur
Le connecteur MQ a différentes versions, en fonction du type d’application logique et de l’environnement hôte.
| Application logique | Environnement | Version de connexion |
|---|---|---|
| Consommation | Azure Logic Apps multilocataire et environnement de service d’intégration (ISE) | Connecteur managé, qui s’affiche dans le concepteur sous l’étiquette Entreprise. Ce connecteur fournit seulement des actions, et non pas des déclencheurs. Dans les scénarios de serveur MQ local, le connecteur managé prend uniquement en charge l’authentification du serveur avec le chiffrement TLS (SSL). Pour plus d’informations, consultez la documentation suivante : - Informations de référence sur les connecteurs managés MQ - Connecteurs managés dans Azure Logic Apps |
| Standard | Azure Logic Apps à locataire unique et App Service Environment v3 (ASE v3 avec des plans Windows uniquement) | Le connecteur managé apparaissant dans la galerie de connecteurs sous Runtime>partagé, ainsi que le connecteur intégré qui apparaît dans la galerie de connecteurs sous Runtime>In-App et est basé sur le fournisseur de services. La version intégrée diffère de la manière suivante : - La version intégrée inclut des actions et des déclencheurs. - Le connecteur intégré peut se connecter directement à un serveur MQ et accéder à des réseaux virtuels Azure à l’aide d’un chaîne de connexion sans passerelle de données locale. - La version intégrée prend en charge l’authentification serveur et l’authentification serveur-client avec le chiffrement TLS (SSL) pour les données en transit, l’encodage des messages pour les opérations d’envoi et de réception et l’intégration du réseau virtuel Azure. Pour plus d’informations, consultez la documentation suivante : - Informations de référence sur les connecteurs managés MQ - Informations de référence sur les connecteurs intégrés MQ - Connecteurs intégrés dans Azure Logic Apps |
Authentification avec chiffrement TLS (SSL)
Selon que vous utilisez le connecteur managé MQ (flux de travail Consommation ou Standard) ou le connecteur intégré MQ (flux de travail Standard uniquement), le connecteur MQ prend en charge l’une ou l’autre des instructions d’authentification suivantes :
| Authentification | Type d’application logique pris en charge et connecteur MQ | Processus |
|---|---|---|
| Serveur uniquement (unidirectionnel) |
- Consommation : géré uniquement - Standard : géré ou intégré |
Pour l’authentification du serveur, votre serveur MQ envoie un certificat de clé privée, approuvé publiquement ou non approuvé publiquement, à votre client d’application logique à des fins de validation. Le connecteur MQ valide le certificat de serveur entrant pour l’authenticité par rapport aux certificats de clé publique, également appelés certificats « signataires », à l’aide de la validation standard du flux SSL .NET. L’application logique n’envoie pas de certificat client. |
| Client serveur (bidirectionnel) |
- Consommation : non prise en charge - Standard : intégré uniquement |
Pour l’authentification du serveur, consultez la ligne précédente. Pour l’authentification du client, le client d’application logique envoie un certificat de clé privée à votre serveur MQ pour validation. Le serveur MQ valide également le certificat client entrant pour l’authenticité à l’aide d’un certificat de clé publique. |
Remarques sur les certificats de clé privée et de clé publique
Le certificat qui nécessite la validation est toujours un certificat de clé privée. Le certificat utilisé pour effectuer la validation est toujours un certificat de clé publique.
Un certificat de clé privée approuvé publiquement est émis par une autorité de certification reconnue. Un certificat de clé privée non approuvé publiquement inclut une autorité de certification privée auto-signée, une autorité de certification privée et des certificats similaires.
Pour valider un certificat de clé privée envoyé à partir de votre serveur MQ, le connecteur MQ utilise des certificats de clé publique qui existent généralement sur l’hôte de machine virtuelle de votre application logique dans le Magasin des autorités de certification racines approuvées de l’hôte.
Toutefois, si l’hôte n’a pas tous les certificats de clé publique requis ou si votre serveur MQ envoie un certificat de clé privée non approuvé publiquement, vous devez effectuer des étapes supplémentaires. Pour plus d’informations, consultez Prérequis.
Pour valider le certificat de clé privée d’un client envoyé à partir de votre application logique Standard, le serveur MQ utilise des certificats de clé publique qui existent dans le magasin de certificats de votre serveur MQ. Pour ajouter un certificat de clé privée à utiliser pour votre application logique en tant que certificat client, consultez Ajouter un certificat de clé privée.
Limites
Authentification avec chiffrement TLS (SSL)
Connecteur MQ Direction de l’authentification prise en charge Gérée Serveur uniquement (unidirectionnel) Intégré - Serveur-client (bidirectionnel)
- Serveur uniquement (unidirectionnel)Validation du certificat de serveur
Le connecteur intégré MQ ne valide pas la date d’expiration du certificat de serveur ni la chaîne de certificats.
Conversions de jeu de caractères
Le connecteur managé MQ n’effectue aucune conversion de jeu de caractères ni n’utilise le champ Format du message. Le connecteur copie uniquement les données qui s’affichent dans le champ de message et envoie le message le long.
Le connecteur intégré MQ peut effectuer des conversions de jeu de caractères, mais uniquement lorsque le format de données est une chaîne. Si vous fournissez un AUTRE ID de jeu de caractères (page de codes), le connecteur tente de convertir les données en nouvelle page de codes.
Le connecteur MQ ne prend pas en charge les messages segmentés.
Pour plus d’informations, consultez la référence du connecteur managé MQ ou la référence du connecteur intégré MQ.
Prérequis
Un compte et un abonnement Azure. Si vous n’avez pas d’abonnement Azure, inscrivez-vous pour bénéficier d’un compte Azure gratuit.
Pour vous connecter à un serveur MQ local, vous devez installer la passerelle de données locale sur un serveur au sein de votre réseau. Pour que le connecteur MQ fonctionne, le serveur sur lequel vous installez la passerelle de données locale doit également avoir .NET Framework 4.6 installé.
Après avoir installé la passerelle, vous devez également créer une ressource de passerelle de données dans Azure. Le connecteur MQ utilise cette ressource pour accéder à votre serveur MQ. Pour plus d’informations, consultez Configurer la connexion à la passerelle de données.
Remarque
Vous n’avez pas besoin de la passerelle dans les scénarios suivants :
- Votre serveur MQ est disponible publiquement ou disponible dans Azure.
- Vous allez utiliser le connecteur intégré MQ, et non le connecteur managé.
Ressource d’application logique et flux de travail dans lesquels vous souhaitez accéder à votre serveur MQ.
Pour utiliser le connecteur managé MQ avec la passerelle de données locale, votre ressource d’application logique doit utiliser le même emplacement que votre ressource de passerelle dans Azure.
Pour utiliser le connecteur managé MQ, qui ne fournit aucun déclencheur, assurez-vous que votre flux de travail commence par un déclencheur ou que vous ajoutez d’abord un déclencheur à votre flux de travail. Par exemple, vous pouvez utiliser le déclencheur Recurrence.
Pour utiliser un déclencheur à partir du connecteur intégré MQ, veillez à commencer par un flux de travail vide.
Conditions requises pour l’authentification avec le chiffrement TLS (SSL)
Connecteur managé MQ
Serveur MQ Spécifications Serveur MQ hébergé par Azure Le serveur MQ doit envoyer un certificat de clé privée émis par une autorité de certification approuvée à votre client d’application logique pour validation. Serveur MQ local à l’aide de la passerelle de données locale Pour envoyer un certificat de clé privée non approuvé publiquement, tel qu’un certificat d’autorité de certification auto-signé ou privé, vous devez ajouter le certificat au magasin des autorités de certification racines approuvées (CA) sur l’ordinateur local avec l’installation de la passerelle de données locale. Pour cette tâche, vous pouvez utiliser le Gestionnaire de certificats Windows (certmgr.exe). Connecteur intégré MQ
Les applications logiques standard utilisent Azure App Service comme plateforme hôte et pour gérer les certificats. Pour les applications logiques standard sur n’importe quel plan WS*, vous pouvez ajouter des certificats publics, privés, personnalisés ou auto-signés au magasin de certificats de l’ordinateur local. Toutefois, si vous devez ajouter des certificats au Magasin d’autorité de certification racine approuvé sur l’hôte de machine virtuelle où votre application logique standard s’exécute, App Service nécessite que votre application logique s’exécute dans un environnement App Service isolé v3 (ASE) avec un plan App Service basé sur Windows uniquement et un plan App Service basé sur ASE. Pour plus d’informations, consultez Certificats et App Service Environment.
Authentification du serveur MQ
Le tableau suivant décrit les prérequis du certificat, en fonction de votre scénario :
Certificat de serveur MQ entrant Spécifications Certificat de clé privée approuvé publiquement émis par une autorité de certification approuvée En règle générale, votre application logique n’a pas besoin d’une autre configuration, car l’hôte de la machine virtuelle de votre application logique a généralement les certificats de clé publique requis pour valider le certificat de clé privée du serveur MQ entrant. Pour case activée que ces certificats de clé publique existent, suivez les étapes pour afficher et confirmer les empreintes numériques des certificats de clé publique existants.
Si l’hôte de machine virtuelle n’a pas tous les certificats de clé publique requis pour valider le certificat de clé privée du serveur MQ entrant et les certificats de chaînage, procédez comme suit :
1. Recréez votre application logique standard à l’aide d’un environnement Azure App Service Environment v3 (ASE) avec un plan App Service basé sur Windows uniquement et ASE.
2. Ajoutez manuellement les certificats de clé publique requis au magasin d’autorité de certification racine approuvé de l’hôte.Certificat de clé privée non approuvé publiquement, tel qu’un certificat d’autorité de certification auto-signé ou privé L’hôte de la machine virtuelle de votre application logique n’aura pas les certificats de clé publique requis dans le magasin d’autorité de certification racine approuvé de l’hôte pour valider la chaîne de certificats du serveur MQ. Dans ce cas, procédez comme suit :
1. Recréez votre application logique standard à l’aide d’un environnement Azure App Service Environment v3 (ASE) avec un plan App Service basé sur Windows uniquement et ASE.
2. Ajoutez manuellement les certificats de clé publique requis au magasin d’autorité de certification racine approuvé de l’hôte.
Pour plus d’informations, consultez la documentation suivante :
- Liaisons de certificat et environnement App Service
- Ajouter et gérer des certificats TLS/SSL dans Azure App ServiceAuthentification du client d’application logique
Vous pouvez ajouter un certificat de clé privée à envoyer en tant que certificat client, puis spécifier la valeur d’empreinte numérique du certificat dans les détails de connexion du connecteur intégré MQ. Pour plus d’informations, consultez ajouter un certificat de clé privée.
Recommandation : Effectuez une mise à niveau vers le serveur MQ 9.0 ou version ultérieure. En outre, sur votre serveur MQ, veillez à configurer le canal de connexion au serveur avec une suite de chiffrement qui correspond à la spécification de chiffrement utilisée par votre connexion cliente, par exemple, ANY_TLS12_OR_HIGHER. Pour plus d’informations, consultez l’élément suivant sur les exigences de chiffrement.
Spécifications de chiffrement requises
Le serveur MQ nécessite que vous définissiez la spécification de chiffrement pour les connexions qui utilisent le chiffrement TLS (SSL). Cette spécification de chiffrement doit correspondre aux suites de chiffrement prises en charge, choisies et utilisées par le système d’exploitation où le serveur MQ s’exécute. En fin de compte, la spécification de chiffrement utilisée par la connexion cliente doit correspondre aux suites de chiffrement configurées sur le canal de connexion serveur sur le serveur MQ.
Pour plus d’informations, consultez Problèmes de connexion et d’authentification.
Ajouter un déclencheur MQ (application logique standard uniquement)
Les étapes suivantes sont uniquement applicables aux workflows d’application logique standard, qui peuvent utiliser des déclencheurs fournis par le connecteur intégré MQ. Le connecteur managé MQ n’inclut aucun déclencheur.
Ces étapes utilisent le portail Azure, mais avec l’extension Azure Logic Apps appropriée, vous pouvez également utiliser Visual Studio Code pour créer des workflows d’application logique standard.
Sur le Portail Azure, ouvrez votre workflow d’application logique vide dans le concepteur.
Suivez ces étapes générales pour ajouter le déclencheur intégré MQ souhaité. Pour plus d’informations, consultez les déclencheurs de connecteur intégrés MQ.
Fournissez les informations requises pour authentifier votre connexion. Sélectionnez Créer lorsque vous avez terminé.
Lorsque la zone d’informations sur le déclencheur s’affiche, fournissez les informations requises pour votre déclencheur.
Lorsque vous avez terminé, enregistrez votre flux de travail. Dans la barre d’outils du Concepteur, sélectionnez Enregistrer.
Ajouter une action MQ
Un workflow d’application logique Consommation ne peut utiliser que le connecteur managé MQ. En revanche, un workflow d’application logique standard peut utiliser le connecteur managé MQ et le connecteur intégré MQ. Chaque version a plusieurs actions. Par exemple, les versions managée et intégrée du connecteur ont leurs propres actions pour rechercher un message.
Actions du connecteur managé : ces actions s’exécutent dans un flux de travail d’application logique Consommation ou Standard.
Actions de connecteur intégré : ces actions s’exécutent uniquement dans un flux de travail d’application logique Standard.
Les étapes suivantes utilisent le portail Azure, mais avec l’extension Azure Logic Apps appropriée, vous pouvez également utiliser les outils suivants pour créer des flux de travail d’application logique :
Flux de travail d’application logique de consommation : Visual Studio ou Visual Studio Code
Flux de travail d’application logique standard : Visual Studio Code
Dans le portail Azure, ouvrez le flux de travail de votre application logique dans le concepteur.
Suivez ces étapes générales pour ajouter l’action MQ souhaitée. Pour plus d’informations, consultez les actions du connecteur MQ.
Fournissez les informations requises pour authentifier votre connexion. Sélectionnez Créer lorsque vous avez terminé.
Lorsque la zone d’informations sur l’action s’affiche, fournissez les informations requises pour votre action.
Lorsque vous avez terminé, enregistrez votre flux de travail. Dans la barre d’outils du Concepteur, sélectionnez Enregistrer.
Tester votre workflow
Pour case activée que votre flux de travail retourne les résultats attendus, exécutez votre flux de travail, puis passez en revue les sorties de l’historique d’exécution de votre flux de travail.
Exécutez votre workflow.
Application logique de consommation : dans la barre d’outils du concepteur de workflow, sélectionnez Exécuter>l’exécution du déclencheur.
Application logique standard : dans le menu des ressources de workflow, sélectionnez Vue d’ensemble. Dans la barre d’outils du volet Vue d’ensemble, sélectionnez Exécuter le déclencheur>Exécuter.
Une fois l’exécution terminée, le concepteur affiche l’historique des exécutions du workflow ainsi que l’état de chaque étape.
Pour passer en revue les entrées et les sorties de chaque étape exécutée (non ignorée), développez ou sélectionnez l’étape.
Pour examiner d’autres détails d’entrée, sélectionnez Afficher les entrées brutes.
Pour examiner d’autres détails de sortie, sélectionnez Afficher les sorties brutes. Si vous définissez IncludeInfo sur true, une sortie plus détaillée est incluse.
Afficher et ajouter des certificats pour l’authentification avec le chiffrement TLS (SSL)
Les informations suivantes s’appliquent uniquement aux flux de travail d’application logique standard pour le connecteur intégré MQ à l’aide de l’authentification serveur uniquement ou du client serveur avec le chiffrement TLS (SSL).
Afficher et confirmer les empreintes pour les certificats de clé publique existants
Pour case activée que les empreintes des certificats de clé publique requises existent sur l’hôte de machine virtuelle de votre application logique Standard dans le Magasin d’autorité de certification racine approuvée, procédez comme suit pour exécuter le cert script PowerShell à partir du menu de ressources de votre application logique Standard.
Dans le portail Azure, ouvrez votre ressource d’application logique Standard. Dans le menu des ressources de l’application logique, sous Outils de développement, sélectionnez Outils avancés>Go.
Dans le menu de la console Kudu Debug, sélectionnez PowerShell.
Une fois la fenêtre PowerShell affichée, à partir de l’invite de commandes PowerShell, exécutez le script suivant :
dir cert:\localmachine\rootLa fenêtre PowerShell répertorie les empreintes et descriptions existantes, par exemple :
Ajouter un certificat de clé publique
Pour ajouter un certificat de clé publique au magasin d’autorité de certification racine approuvé sur cet hôte de machine virtuelle où votre application logique standard s’exécute, procédez comme suit :
Dans le portail Azure, ouvrez votre ressource d’application logique Standard. Dans le menu des ressources de l’application logique, sous Paramètres, sélectionnez les paramètres TLS/SSL (classique) .
Dans la page paramètres TLS/SSL (classique), sélectionnez l’onglet Certificats de clé publique (.cer), puis chargez le certificat de clé publique.
Dans le volet Ajouter un certificat de clé publique (.cer) qui s’ouvre, entrez un nom pour décrire le certificat. Recherchez et sélectionnez le fichier de certificat de clé publique (.cer). Une fois que vous avez terminé, sélectionnez Charger.
Après avoir ajouté le certificat, à partir de la colonne Empreinte numérique, copiez la valeur de l’empreinte numérique du certificat.
Dans le menu des ressources de l’application logique, sélectionnez Configuration.
Sous l’onglet Paramètre d’application, sélectionnez Nouveau paramètre d’application. Ajoutez un nouveau paramètre d’application nommé WEBSITE_LOAD_ROOT_CERTIFICATES, puis entrez la valeur de l’empreinte numérique du certificat que vous avez copiée précédemment. Si vous avez plusieurs valeurs d’empreinte numérique de certificat, veillez à séparer chaque valeur par une virgule (,).
Pour plus d’informations, consultez Modifier les paramètres de l’hôte et de l’application pour les applications logiques standard dans Azure Logic Apps monolocataire.
Remarque
Si vous spécifiez une empreinte numérique pour un certificat d’autorité de certification privée, le connecteur intégré MQ n’exécute aucune validation de certificat, par exemple case activée la date d’expiration ou la source du certificat. Si la validation SSL .NET standard échoue, le connecteur compare uniquement les valeurs d’empreinte numérique transmises par rapport à la valeur du paramètre WEBSITE_LOAD_ROOT_CERTIFICATES .
Si le certificat ajouté n’apparaît pas dans la liste des certificats de clé publique, dans la barre d’outils, sélectionnez Actualiser.
Ajouter un certificat de clé privée
Pour ajouter un certificat de clé privée au Magasin d’autorité de certification racine approuvé sur l’hôte de machine virtuelle sur lequel votre application logique standard s’exécute, procédez comme suit :
Dans le portail Azure, ouvrez votre ressource d’application logique. Dans le menu des ressources de l’application logique, sous Paramètres, sélectionnez les paramètres TLS/SSL (classique) .
Dans la page paramètres TLS/SSL (classique), sélectionnez l’onglet Certificats de clé privée (.pfx), puis sélectionnez Charger le certificat.
Dans le volet Ajouter un certificat de clé privée (.pfx) qui s’ouvre, recherchez et sélectionnez le fichier de certificat de clé privée (.pfx), puis entrez le mot de passe du certificat. Une fois que vous avez terminé, sélectionnez Charger.
Après avoir ajouté le certificat, à partir de la colonne Empreinte numérique, copiez la valeur de l’empreinte numérique du certificat.
Dans le menu des ressources de l’application logique, sélectionnez Configuration.
Sous l’onglet Paramètre d’application, sélectionnez Nouveau paramètre d’application. Ajoutez un nouveau paramètre d’application nommé WEBSITE_LOAD_CERTIFICATES, puis entrez la valeur d’empreinte numérique du certificat que vous avez copiée précédemment.
Pour plus d’informations, consultez Modifier les paramètres de l’hôte et de l’application pour les applications logiques standard dans Azure Logic Apps monolocataire.
Si le certificat ajouté n’apparaît pas dans la liste des certificats de clé privée, dans la barre d’outils, sélectionnez Actualiser.
Lorsque vous créez une connexion à l’aide du connecteur intégré MQ, dans la zone d’informations de connexion, sélectionnez Utiliser TLS.
Dans la propriété Empreinte numérique du certificat client, entrez la valeur d’empreinte numérique précédemment copiée pour le certificat de clé privée, qui active l’authentification server-client (bidirectionnel). Si vous n’entrez pas de valeur d’empreinte numérique, le connecteur utilise l’authentification serveur uniquement (unidirectionnel).
Résoudre les problèmes
Échecs avec des actions de navigation ou de réception
Si vous exécutez une action de navigation ou de réception sur une file d’attente vide, l’action échoue avec les sorties d’en-tête suivantes :
Problèmes de connexion et d’authentification
Lorsque votre flux de travail utilise le connecteur managé MQ pour vous connecter à votre serveur MQ local, vous pouvez obtenir l’erreur suivante :
"MQ: Could not Connect the Queue Manager '<queue-manager-name>': The Server was expecting an SSL connection."
Le serveur MQ doit fournir un certificat émis par une autorité de certification approuvée.
Le serveur MQ requiert la définition de la spécification de chiffrement à utiliser pour les connexions TLS. Toutefois, à des fins de sécurité et pour inclure les meilleures suites de sécurité, le système d’exploitation Windows envoie un ensemble de spécifications de chiffrement prises en charge.
Le système d’exploitation sur lequel le serveur MQ s’exécute choisit les suites à utiliser. Pour que la configuration corresponde, vous devez modifier le programme d’installation du serveur MQ afin que la spécification de chiffrement corresponde à l’option choisie dans la négociation TLS.
Lorsque vous essayez la connexion, le serveur MQ enregistre un message d’événement qui indique que la tentative de connexion a échoué, car le serveur MQ a utilisé la mauvaise spécification de chiffrement. Le message d’événement contient la spécification de chiffrement que le serveur MQ a choisie dans la liste. Dans la configuration du canal de connexion de serveur, mettez à jour la spécification de chiffrement pour qu’elle corresponde à la spécification de chiffrement dans le message d’événement.