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 local ou hébergé dans Azure à partir d’un workflow 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 pour 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 | Connecteur managé, qui apparaît dans la galerie de connecteurs sous Runtime>Partagé. 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 monolocataire et App Service Environment v3 (plans ASE v3 avec 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>Dans l’application et qui est basé sur le fournisseur de services. La version intégrée diffère des façons suivantes : - 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’une chaîne de connexion sans passerelle de données locale. - La version intégrée prend en charge l’authentification du 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 (workflows Consommation ou Standard) ou le connecteur intégré MQ (workflows Standard uniquement), le connecteur MQ prend en charge l’une des directions d’authentification suivantes ou les deux :
Authentification | Type d’application logique et connecteur MQ pris en charge | Process |
---|---|---|
Serveur uniquement (unidirectionnelle) |
- Consommation : managé uniquement - Standard : managé ou intégré |
Pour l’authentification du serveur, votre serveur MQ envoie un certificat de clé privée, de confiance publique ou non, à votre client d’application logique pour validation. Le connecteur MQ vérifie l'authenticité du certificat de serveur entrant par rapport aux certificats de clé publique, également appelés certificats de « signataire », en utilisant la validation de flux SSL .NET standard. L'application logique n'envoie pas de certificat client. |
Serveur-client (bidirectionnelle) |
- Consommation : non pris en charge - Standard : intégré uniquement |
Pour l’authentification du serveur, voir la ligne précédente. Pour l'authentification du client, le client de l'application logique envoie un certificat de clé privée à votre serveur MQ pour validation. Le serveur MQ valide également l'authenticité du certificat client entrant à 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 une 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 de confiance 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 d’authentification prise en charge Gérée Serveur uniquement (unidirectionnelle) Intégré - Serveur-client (bidirectionnelle)
- Serveur uniquement (unidirectionnelle)Validation de 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 jeux de caractères
Le connecteur MQ n’effectue pas de conversions de jeux de caractères et n’utilise pas le champ Format du message. Le connecteur copie uniquement les données qui apparaissent dans le champ de message, et envoie le message.
Le connecteur intégré MQ peut effectuer des conversions de jeux de caractères, mais uniquement lorsque le format de données est une chaîne. Si vous fournissez un ID de jeu de caractères différent (page de code), le connecteur tente de convertir les données dans la nouvelle page de code.
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é.
La ressource et le workflow d’application logique où 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, vérifiez que votre workflow commence par un déclencheur ou veillez à ajouter d’abord un déclencheur à votre workflow. Par exemple, vous pouvez utiliser le déclencheur Recurrence.
Pour utiliser un déclencheur à partir du connecteur intégré MQ, veillez à créer un flux de travail vierge.
Exigences en matière de certificats 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 de confiance à votre client d’application logique à des fins de validation. Serveur MQ local utilisant une 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 de confiance sur l’ordinateur local lors de 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 de n'importe quel plan WS*, vous pouvez ajouter des certificats publics, privés, personnalisés ou auto-signés au magasin de certificats de la machine locale. Cependant, si vous devez ajouter des certificats à la liste d'autorités de certification racine de confiance sur l'hôte de la machine virtuelle où s'exécute votre application logique standard, App Service exige que votre application logique s'exécute dans un environnement App Service Environment v3 (ASE) isolé avec un plan App Service pour Windows uniquement et un plan App Service basé sur l'ASE. Pour plus d'informations, reportez-vous à la section Certificats et environnement de service applicatif.
Authentification du serveur MQ
Le tableau suivant décrit les conditions préalables à l'obtention d'un certificat, en fonction de votre scénario :
Certificat du serveur MQ entrant Spécifications Certificat de clé privée publiquement fiable délivré par une autorité de certification fiable En général, votre application logique n'a pas besoin d'une autre configuration, car l'hôte de la machine virtuelle de votre application logique dispose généralement des certificats de clé publique nécessaires pour valider le certificat de clé privée du serveur MQ entrant. Pour vérifier que ces certificats de clé publique existent, suivez les étapes suivantes Afficher et confirmer les vignettes 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, effectuez ces étapes :
1. Recréez votre application logique Standard à l’aide d’un environnement ASE (Azure App Service Environment) v3 avec un plan App Service Windows uniquement et basé sur ASE.
2. Ajoutez manuellement les certificats de clé publique requis au Magasin des autorités de certification racines de confiance de l’hôte.Certificat de clé privée non reconnu publiquement, tel qu'un certificat auto-signé ou un certificat d'autorité de certification privée L’hôte de machine virtuelle de votre application logique n’aura pas les certificats de clé publique requis dans le Magasin des autorités de certification racines de confiance de l’hôte pour valider la chaîne de certificats du serveur MQ. Dans ce cas, suivez les étapes ci-dessous :
1. Recréez votre application logique Standard à l’aide d’un environnement ASE (Azure App Service Environment) v3 avec un plan App Service Windows uniquement et basé sur ASE.
2. Ajoutez manuellement les certificats de clé publique requis au Magasin des autorités de certification racines de confiance de l’hôte.
Pour plus d’informations, consultez la documentation suivante :
- Liaisons de certificats et App Service Environment
- Ajouter et gérer des certificats TLS/SSL dans Azure App ServiceAuthentification du client de l'application logique
Vous pouvez ajouter un certificat de clé privée à envoyer en tant que certificat client, puis spécifier la valeur de l'empreinte du certificat dans les détails de la connexion pour le connecteur intégré MQ. Pour plus d'informations, voir ajouter un certificat de clé privée.
Recommandation : Passez au serveur MQ 9.0 ou à une version ultérieure. En outre, sur votre serveur MQ, veillez à configurer le canal de connexion au serveur avec une suite de chiffrement correspondant à la spécification de chiffrement utilisée par votre connexion client, par exemple ANY_TLS12_OR_HIGHER. Pour plus d'informations, reportez-vous au point suivant concernant les exigences en matière de chiffrement.
Exigences relatives à la spécification du chiffrement
Le serveur MQ exige 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 sur lequel tourne le serveur MQ En fin de compte, la spécification de chiffrement utilisée par la connexion du client doit correspondre aux suites de chiffrement définies sur le canal de connexion du 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 Déclencheurs de connecteur intégré 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 workflows d’application logique :
- Workflows de consommation : Visual Studio Code
- Workflow 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 Actions de 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 vérifier que votre workflow renvoie les résultats attendus, exécutez votre workflow, puis passez en revue les résultats de l’historique des exécutions de votre workflow.
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 workflows d’application logique Standard pour le connecteur intégré MQ utilisant l’authentification serveur uniquement ou l’authentification serveur-client avec le chiffrement TLS (SSL).
Afficher et confirmer les empreintes pour les certificats de clé publique existants
Pour vérifier que les empreintes des certificats de clé publique requis existent sur l’hôte de machine virtuelle de votre application logique Standard dans le Magasin des autorités de certification racines de confiance, effectuez ces étapes pour exécuter le script PowerShell cert
à 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 Console de débogage Kudu, sélectionnez PowerShell.
Une fois la fenêtre PowerShell visible, à l’invite de commandes PowerShell, exécutez le script suivant :
dir cert:\localmachine\root
La 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 des autorités de certification racines de confiance sur cet hôte de machine virtuelle où votre application logique Standard s’exécute, effectuez ces étapes :
Dans le portail Azure, ouvrez votre ressource d’application logique Standard. Dans le menu de la ressource d’application logique, sous Paramètres, sélectionnez Paramètres TLS/SSL (classique).
Dans la page Paramètres TLS/SSL (classique), sélectionnez l’onglet Certificats de clé publique (.cer), puis Charger un 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, copiez la valeur de l’empreinte 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 du certificat que vous avez copiée. Si vous avez plusieurs valeurs d’empreinte 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 pour un certificat d’autorité de certification privée, le connecteur intégré MQ n’exécute aucune validation de certificat (telle que la vérification de la date d’expiration ou de la source du certificat). Si la validation SSL .NET standard échoue, le connecteur compare uniquement les valeurs d’empreinte transmises à la valeur contenue dans le paramètre WEBSITE_LOAD_ROOT_CERTIFICATES.
Si le certificat ajouté ne figure 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 des autorités de certification racines de confiance sur l’hôte de machine virtuelle où votre application logique Standard s’exécute, effectuez ces étapes :
Dans le portail Azure, ouvrez votre ressource d’application logique. Dans le menu de la ressource d’application logique, sous Paramètres, sélectionnez Paramètres TLS/SSL (classique).
Dans la page Paramètres TLS/SSL (classique), sélectionnez l’onglet Certificats de clé privée (.pfx), puis Charger un 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, copiez la valeur de l’empreinte 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 de l’empreinte du certificat que vous avez copiée.
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é ne figure 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 du certificat client, entrez la valeur d’empreinte précédemment copiée pour le certificat de clé privée, ce qui active l’authentification serveur-client (bidirectionnelle). Si vous n’entrez pas de valeur d’empreinte, le connecteur utilise l’authentification serveur uniquement (unidirectionnelle).
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 workflow utilise le connecteur managé MQ pour la connexion à votre serveur MQ local, vous pouvez observer 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 de confiance.
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 au serveur, mettez à jour la spécification de chiffrement pour qu'elle corresponde à la spécification de chiffrement du message d'événement.