Herstellen einer Verbindung mit einem IBM MQ-Server über einen Workflow in Azure Logic Apps
Gilt für: Azure Logic Apps (Verbrauch + Standard)
In diesem Artikel wird gezeigt, wie Sie über einen Workflow in Azure Logic Apps mithilfe des MQ-Connectors auf einen von Azure gehosteten oder lokalen MQ-Server zugreifen. Anschließend können Sie automatisierte Workflows erstellen, die Nachrichten empfangen und senden, die auf Ihrem MQ-Server gespeichert sind. Ihr Workflow kann beispielsweise nach einer einzelnen Nachricht in einer Warteschlange suchen und dann andere Aktionen ausführen.
Der MQ-Connector bietet einen Wrapper um einen Microsoft MQ-Client, der alle Messaging-Funktionen umfasst, um mit einem Remote-MQ-Server über ein TCP/IP-Netzwerk zu kommunizieren. Dieser Connector definiert die Verbindungen, Vorgänge und Parameter, um den MQ-Client aufzurufen.
Unterstützte IBM WebSphere MQ-Versionen
- MQ 7.5
- MQ 8.0
- MQ 9.0, 9.1, 9.2 und 9.3
Technische Referenz für den Connector
Vom MQ-Connector gibt es verschiedene Versionen, die auf dem Typ der logischen Anwendung und der Hostumgebung basieren.
Logik-App | Environment | Verbindungsversion |
---|---|---|
Verbrauch | Mehrinstanzenfähige Azure Logic Apps and Integration Service Environment (ISE) | Verwalteter Connector, der im Designer unter der Bezeichnung Unternehmen (Enterprise) angezeigt wird. Dieser Connector stellt nur Aktionen und keine Trigger bereit. In lokalen MQ-Serverszenarien unterstützt der verwaltete Connector nur die Serverauthentifizierung mit TLS-Verschlüsselung (SSL). Weitere Informationen können Sie in der folgenden Dokumentation lesen: - Referenz zum verwalteten MQ-Connector - Verwaltete Connectors in Azure Logic Apps |
Standard | Azure Logic Apps mit einem Mandanten und App Service-Umgebung v3 (nur ASE v3 mit Windows-Plänen) | Verwalteter Connector, der im Connectorkatalog unter Runtime>Freigegeben erscheint, und der integrierte Connector, der im Connectorkatalog unter Runtime>In-App erscheint wird und auf einem Dienstanbieter basiert. Die integrierte Version unterscheidet sich wie folgt: – Die integrierte Version umfasst Aktionen und Trigger. – Der integrierte Connector kann direkt eine Verbindung mit einem MQ-Server herstellen und auf virtuelle Azure-Netzwerke zugreifen, indem ein Verbindungszeichenfolge ohne ein lokales Datengateway verwendet wird. – Die integrierte Version unterstützt sowohl die Serverauthentifizierung als auch die Serverclientauthentifizierung mit TLS-Verschlüsselung (SSL) für Daten während der Übertragung, nachrichtencodierung für sende- und empfangsvorgänge sowie azure virtual network integration. Weitere Informationen können Sie in der folgenden Dokumentation lesen: - Referenz zum verwalteten MQ-Connector - Referenz zum integrierten MQ-Connector - Integrierte Connectors in Azure Logic Apps |
Authentifizierung mit TLS(SSL)-Verschlüsselung
Je nachdem, ob Sie den verwalteten MQ-Connector (Verbrauchs- oder Standardworkflows) oder den integrierten MQ-Connector (nur Standardworkflows) verwenden, unterstützt der MQ-Connector eine oder beide der folgenden Authentifizierungsrichtungen:
Authentifizierung | Unterstützte Logik-App-Typ und MQ-Connector | Prozess |
---|---|---|
Nur Server (Unidirektionale) |
- Verbrauch: Nur verwaltet - Standard: Verwaltet oder integriert |
Für die Serverauthentifizierung sendet Ihr MQ-Server ein privates Schlüsselzertifikat, entweder öffentlich vertrauenswürdig oder nicht öffentlich vertrauenswürdig, an Ihren Logik-App-Client zur Überprüfung. Der MQ-Connector überprüft das Posteingangsserverzertifikat auf Authentizität für Öffentliche Schlüsselzertifikate, auch als "Signierer"-Zertifikate bezeichnet, mithilfe der standardmäßigen .NET SSL-Streamüberprüfung. Die Logik-App sendet kein Clientzertifikat. |
Serverclient (Bidirektionale Vorgehensweise) |
- Verbrauch: Nicht unterstützt - Standard: Nur integriert |
Informationen zur Serverauthentifizierung finden Sie in der vorherigen Zeile. Für die Clientauthentifizierung sendet der Logik-App-Client zur Überprüfung ein privates Schlüsselzertifikat an Ihren MQ-Server. Der MQ-Server überprüft das eingehende Clientzertifikat auf Authentizität auch mithilfe eines öffentlichen Schlüsselzertifikats. |
Hinweise zu Zertifikaten für private Schlüssel und öffentliche Schlüssel
Das Zertifikat, das eine Überprüfung erfordert, ist immer ein privates Schlüsselzertifikat. Das zertifikat, das zum Ausführen der Überprüfung verwendet wird, ist immer ein Öffentliches Schlüsselzertifikat.
Ein öffentlich vertrauenswürdiges privates Schlüsselzertifikat wird von einer anerkannten Zertifizierungsstelle ausgestellt. Ein nicht öffentlich vertrauenswürdiges privates Schlüsselzertifikat umfasst selbstsignierte, private Zertifizierungsstelle und ähnliche Zertifikate.
Um ein vom MQ-Server gesendetes privates Schlüsselzertifikat zu überprüfen, verwendet der MQ-Connector öffentliche Schlüsselzertifikate, die in der Regel auf dem virtuellen Computerhost Ihrer Logik-App im vertrauenswürdigen Zertifizierungsstellenspeicher (Trusted Root Certification Authorities, CA) des Hosts vorhanden sind.
Wenn der Host jedoch nicht über alle erforderlichen Öffentlichen Schlüsselzertifikate verfügt oder ihr MQ-Server ein nicht öffentlich vertrauenswürdiges privates Schlüsselzertifikat sendet, müssen Sie zusätzliche Schritte ausführen. Weitere Informationen finden Sie unter Voraussetzungen.
Um das private Schlüsselzertifikat eines Clients zu überprüfen, das von Ihrer Standardlogik-App gesendet wird, verwendet der MQ-Server öffentliche Schlüsselzertifikate, die im Zertifikatspeicher Ihres MQ-Servers vorhanden sind. Informationen zum Hinzufügen eines zertifikats privaten Schlüssels für Ihre Logik-App, die als Clientzertifikat verwendet werden soll, finden Sie unter Hinzufügen eines Zertifikats mit privatem Schlüssel.
Begrenzungen
Authentifizierung mit TLS(SSL)-Verschlüsselung
MQ-Verbinder Unterstützte Authentifizierungsrichtung Verwaltet Nur Server (unidirektionale Methode) Integriert - Server-Client (bidirektionale)
- Nur Server (unidirektionale)Serverzertifikatüberprüfung
Der integrierte MQ-Connector überprüft weder das Ablaufdatum des Serverzertifikats noch die Zertifikatkette.
Zeichensatzkonvertierungen
Der verwaltete MQ-Connector verwendet weder Zeichensatzkonvertierungen noch das Feld "Format" der Nachricht. Der Connector kopiert nur die Daten, die im Nachrichtenfeld angezeigt werden, und sendet die Nachricht weiter.
Der integrierte MQ-Verbinder kann Zeichensatzkonvertierungen vornehmen, jedoch nur, wenn das Datenformat eine Zeichenfolge ist. Wenn Sie eine andere Zeichensatz-ID (Codepage) angeben, versucht der Connector, die Daten in die neue Codepage zu konvertieren.
Der MQ-Connector unterstützt keine segmentierten Nachrichten.
Weitere Informationen finden Sie in der Referenz zum verwalteten MQ-Connector oder der Referenz zum integrierten MQ-Connector.
Voraussetzungen
Ein Azure-Konto und ein Azure-Abonnement. Wenn Sie nicht über ein Azure-Abonnement verfügen, können Sie sich für ein kostenloses Azure-Konto registrieren.
Um eine Verbindung mit einem lokalen MQ-Server herzustellen, müssen Sie das lokale Datengateway auf einem Server in Ihrem Netzwerk installieren. Für eine ordnungsgemäße Funktionsweise des MQ-Connectors muss der Server, auf dem sich das lokale Datengateway befindet, auch über .NET Framework 4.6 verfügen.
Nachdem Sie das Gateway installiert haben, müssen Sie auch eine Datengateway-Ressource in Azure erstellen. Der MQ-Connector verwendet diese Ressource für den Zugriff auf Ihren MQ-Server. Weitere Informationen finden Sie unter Einrichten der Datengatewayverbindung.
Hinweis
In den folgenden Szenarien benötigen Sie das Gateway nicht:
- Ihr MQ-Server ist öffentlich oder in Azure verfügbar.
- Sie verwenden den integrierten MQ-Connector, nicht den verwalteten Connector.
Die Logik-App-Ressource und der Workflow, an der Sie auf Ihren MQ-Server zugreifen möchten.
Um den verwalteten MQ-Connector mit dem lokalen Datengateway zu verwenden, muss Ihre Logik-App-Ressource denselben Speicherort wie Ihre Gatewayressource in Azure verwenden.
Um den verwalteten MQ-Connector zu verwenden, der keine Trigger bereitstellt, stellen Sie sicher, dass Ihr Workflow mit einem Trigger beginnt oder Sie dem Workflow zuerst einen Trigger hinzufügen. Sie können beispielsweise den Wiederholungstrigger verwenden.
Um einen Trigger aus dem integrierten MQ-Connector zu verwenden, stellen Sie sicher, dass Sie mit einem leeren Workflow beginnen.
Zertifikatanforderungen für die Authentifizierung mit SSL-Verschlüsselung (TLS)
MQ-verwalteter Connector
MQ-Server Anforderungen Azure-gehosteter MQ-Server Der MQ-Server muss ein privates Schlüsselzertifikat senden, das von einer vertrauenswürdigen Zertifizierungsstelle zur Überprüfung an Ihren Logik-App-Client ausgestellt wird. Lokaler MQ-Server mit lokalem Datengateway Um ein nicht öffentlich vertrauenswürdiges privates Schlüsselzertifikat wie ein selbstsigniertes oder privates Zertifizierungsstellenzertifikat zu senden, müssen Sie das Zertifikat dem Speicher für vertrauenswürdige Stammzertifizierungsstellen (Trusted Root Certification Authorities, CA) auf dem lokalen Computer mit der lokalen Installation des Datengateways hinzufügen. Für diese Aufgabe können Sie den Windows Certificate Manager (certmgr.exe) verwenden. MQ integrierter Verbinder
Standardlogik-Apps verwenden Azure-App Dienst als Hostplattform und zum Verarbeiten von Zertifikaten. Für Standardlogik-Apps für jeden WS*-Plan können Sie dem Zertifikatspeicher des lokalen Computers öffentliche, private, benutzerdefinierte oder selbstsignierte Zertifikate hinzufügen. Wenn Sie jedoch Zertifikate zum vertrauenswürdigen Stammzertifizierungsstellenspeicher auf dem Host für virtuelle Computer hinzufügen müssen, auf dem Ihre Standardlogik-App ausgeführt wird, erfordert App Service, dass Ihre Logik-App in einem isolierten App Service-Umgebung v3 (ASE) mit einem Nur-Windows- und einem ASE-basierten App Service-Plan ausgeführt wird. Weitere Informationen finden Sie unter "Zertifikate" und "App Service-Umgebung".
MQ-Serverauthentifizierung
In der folgenden Tabelle werden die Zertifikatvoraussetzungen basierend auf Ihrem Szenario beschrieben:
Eingehendes MQ-Serverzertifikat Anforderungen Öffentlich vertrauenswürdiges privates Schlüsselzertifikat, das von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde In der Regel benötigt Ihre Logik-App keine andere Einrichtung, da der Host des virtuellen Computers Ihrer Logik-App in der Regel über die erforderlichen Zertifikate für öffentliche Schlüssel verfügt, um das private Schlüsselzertifikat des eingehenden MQ-Servers zu überprüfen. Um zu überprüfen, ob diese Zertifikate für öffentliche Schlüssel vorhanden sind, führen Sie die Schritte zum Anzeigen und Bestätigen von Fingerabdrucken für vorhandene Öffentliche Schlüsselzertifikate aus.
Wenn der Host des virtuellen Computers nicht über alle erforderlichen Zertifikate für öffentliche Schlüssel verfügt, um das private Schlüsselzertifikat des eingehenden MQ-Servers und alle Verkettungszertifikate zu überprüfen, führen Sie die folgenden Schritte aus:
1. Erstellen Sie Ihre Standardlogik-App mithilfe einer Azure-App Service Environment v3 (ASE) mit einem Windows-only- und ASE-basierten App Service-Plan neu.
2. Fügen Sie die erforderlichen Zertifikate für öffentliche Schlüssel manuell zum vertrauenswürdigen Stammzertifizierungsstellenspeicher des Hosts hinzu.Nicht öffentlich vertrauenswürdiges Zertifikat für private Schlüssel, z. B. ein selbstsigniertes oder privates Zertifizierungsstellenzertifikat Der Virtuelle Computerhost Ihrer Logik-App verfügt nicht über die erforderlichen Zertifikate für öffentliche Schlüssel im Trusted Root CA Store des Hosts, um die Zertifikatkette des MQ-Servers zu überprüfen. Führen Sie in diesem Fall die folgenden Schritte aus:
1. Erstellen Sie Ihre Standardlogik-App mithilfe einer Azure-App Service Environment v3 (ASE) mit einem Windows-only- und ASE-basierten App Service-Plan neu.
2. Fügen Sie die erforderlichen Zertifikate für öffentliche Schlüssel manuell zum vertrauenswürdigen Stammzertifizierungsstellenspeicher des Hosts hinzu.
Weitere Informationen finden Sie in der folgenden Dokumentation:
- Zertifikatbindungen und die App Service-Umgebung
- Hinzufügen und Verwalten von TLS/SSL-Zertifikaten in Azure App ServiceLogik-App-Clientauthentifizierung
Sie können ein privates Schlüsselzertifikat hinzufügen, das als Clientzertifikat gesendet werden soll, und dann den Fingerabdruckwert des Zertifikats in den Verbindungsdetails für den integrierten MQ-Connector angeben. Weitere Informationen finden Sie unter Hinzufügen eines Zertifikats mit privatem Schlüssel.
Empfehlung: Upgrade auf MQ Server 9.0 oder höher. Stellen Sie außerdem auf Ihrem MQ-Server sicher, dass Sie den Serververbindungskanal mit einer Verschlüsselungssuite einrichten, die der von Ihrer Clientverbindung verwendeten Chiffrespezifikation entspricht, z. B. ANY_TLS12_OR_HIGHER. Weitere Informationen finden Sie im nächsten Element zu Denchiffreanforderungen.
Anforderungen an die Verschlüsselungsspezifikation
Der MQ-Server erfordert, dass Sie die Verschlüsselungsspezifikation für Verbindungen definieren, die TLS(SSL)-Verschlüsselung verwenden. Diese Verschlüsselungsspezifikation muss mit den Verschlüsselungssammlungen übereinstimmen, die vom Betriebssystem unterstützt, ausgewählt und verwendet werden, in dem der MQ-Server ausgeführt wird. Letztendlich muss die von der Clientverbindung verwendete Chiffrespezifikation mit den Verschlüsselungssammlungen übereinstimmen, die auf dem Serververbindungskanal auf dem MQ-Server eingerichtet sind.
Weitere Informationen finden Sie unter Probleme bei der Verbindung und Authentifizierung.
Hinzufügen eines MQ-Triggers (nur Standard-Logik-App)
Die folgenden Schritte gelten nur für Logik-App-Standardworkflows, die Trigger verwenden können, die vom integrierten MQ-Connector bereitgestellt werden. Der verwaltete MQ-Connector beinhaltet keine Trigger.
Diese Schritte verwenden das Azure-Portal, doch mit der entsprechenden Azure Logic Apps-Erweiterung können Sie auch Visual Studio Code verwenden, um einen Logic App-Standardworkflow zu erstellen.
Öffnen Sie im Azure-Portal den leeren Logik-App-Workflow im Designer.
Führen Sie diese allgemeinen Schritte aus, um den gewünschten MQ-Trigger hinzuzufügen. Weitere Informationen finden Sie unter integrierten MQ-Verbindertriggern.
Stellen Sie die erforderlichen Informationen bereit, um Ihre Verbindung zu authentifizieren. Wählen Sie Erstellen, wenn Sie fertig sind.
Wenn das Triggerinformationsfeld angezeigt wird, geben Sie die erforderlichen Informationen für Ihren Trigger an.
Wenn Sie fertig sind, speichern Sie Ihren Workflow. Wählen Sie auf der Symbolleiste des Designers Speichern aus.
Fügen Sie eine MQ-Aktion hinzu
Ein Logik-App-Verbrauchsworkflow kann nur den verwalteten MQ-Connector verwenden. Ein Logik-App-Standardworkflow kann jedoch den verwalteten MQ-Connector und den integrierten MQ-Connector verwenden. Jede Version verfügt über mehrere Aktionen. Beispielsweise verfügen sowohl Versionen verwalteter als auch integrierter Connectors über eigene Aktionen, um eine Nachricht zu durchsuchen.
Verwaltete Connectoraktionen: Diese Aktionen werden in einem Logik-App-Verbrauchs- oder -Standardworkflow ausgeführt.
Integrierte Connectoraktionen: Diese Aktionen werden in einem Logik-App-Standardworkflow ausgeführt.
In den folgenden Schritte wird das Azure-Portal verwendet. Mit der entsprechenden Azure Logic Apps-Erweiterung können Sie aber auch die folgenden Tools verwenden, um Logik-App-Workflows zu erstellen:
Logik-App-Workflows für den Verbrauch: Visual Studio oder Visual Studio Code
Standard-Logik-App-Workflows: Visual Studio Code
Öffnen Sie im Azure-Portal den Logik-App-Workflow im Designer.
Führen Sie diese allgemeinen Schritte aus, um die gewünschte MQ-Aktion hinzuzufügen. Weitere Informationen finden Sie unter MQ-Connectoraktionen.
Stellen Sie die erforderlichen Informationen bereit, um Ihre Verbindung zu authentifizieren. Wählen Sie Erstellen, wenn Sie fertig sind.
Wenn das Aktionsinformationsfeld angezeigt wird, geben Sie die erforderlichen Informationen für Ihre Aktion an.
Wenn Sie fertig sind, speichern Sie Ihren Workflow. Wählen Sie auf der Symbolleiste des Designers Speichern aus.
Testen Ihres Workflows
Um zu überprüfen, ob Ihr Workflow die erwarteten Ergebnisse zurückgibt, führen Sie Den Workflow aus, und überprüfen Sie dann die Ausgaben aus dem Ausführungsverlauf des Workflows.
Ausführen Ihres Workflows
Verbrauchs-Logik-App: Wählen Sie in der Symbolleiste des Workflow-Designers Trigger ausführen>ausführen aus.
Standard-Logik-App: Wählen Sie im Menü „Workflowressource“ Übersicht aus. Wählen Sie in der Symbolleiste des Bereichs Übersicht die Option Trigger ausführen>Ausführen aus.
Nach Abschluss der Ausführung zeigt der Designer den Ausführungsverlauf des Workflows zusammen mit dem Status für jeden Schritt an.
Erweitern oder wählen Sie den Schritt aus, um die Eingaben und Ausgaben für jeden Schritt zu überprüfen, der bereits ausgeführt (nicht übersprungen) wurde.
Um weitere Eingabedetails zu überprüfen, wählen Sie Rohdateneingaben anzeigen aus.
Um weitere Ausgabedetails zu überprüfen, wählen Sie Rohdatenausgaben anzeigen aus. Wenn Sie IncludeInfo auf true festlegen, werden weitere Ausgabeinformationen eingeschlossen.
Anzeigen und Hinzufügen von Zertifikaten für die Authentifizierung mit TLS-Verschlüsselung (SSL)
Die folgenden Informationen gelten nur für Standardlogik-App-Workflows für den integrierten MQ-Connector mithilfe der Server-only- oder Server-Client-Authentifizierung mit TLS-Verschlüsselung (SSL).
Anzeigen und Bestätigen von Fingerabdrucks für vorhandene Zertifikate mit öffentlichem Schlüssel
Um zu überprüfen, ob die Fingerabdrucke für die erforderlichen Zertifikate für öffentliche Schlüssel auf dem virtuellen Computerhost Ihrer Standardlogik-App im Trusted Root CA Store vorhanden sind, führen Sie die folgenden Schritte aus, um das cert
PowerShell-Skript aus dem Ressourcenmenü der Standardlogik-App auszuführen.
Öffnen Sie im Azure-Portal Ihre Ressource vom Typ „Logic App (Standard)“. Wählen Sie im Ressourcenmenü der Logik-App unter "Entwicklungstools" die Option "Erweiterte Tools>wechseln" aus.
Wählen Sie im Menü "Kudu Debuggen" die Option "PowerShell" aus.
Führen Sie nach dem Anzeigen des PowerShell-Fensters an der PowerShell-Eingabeaufforderung das folgende Skript aus:
dir cert:\localmachine\root
Im PowerShell-Fenster werden die vorhandenen Fingerabdrucke und Beschreibungen aufgeführt, z. B.:
Hinzufügen eines Zertifikats für öffentliche Schlüssel
Führen Sie die folgenden Schritte aus, um dem vertrauenswürdigen Stammzertifizierungsstellenspeicher auf diesem virtuellen Computerhost ein Öffentliches Schlüsselzertifikat hinzuzufügen, auf dem Ihre Standardlogik-App ausgeführt wird:
Öffnen Sie im Azure-Portal Ihre Ressource vom Typ „Logic App (Standard)“. Wählen Sie im Ressourcenmenü der Logik-App unter Einstellungen TLS/SSL-Einstellungen (klassisch) aus.
Wählen Sie auf der Seite TLS/SSL-Einstellungen (klassisch) die Registerkarte "Public Key Certificates (.cer)" und dann " Öffentliches Schlüsselzertifikat hochladen" aus.
Geben Sie im daraufhin geöffneten Bereich "Öffentliche Schlüsselzertifikat hinzufügen" einen Namen ein, um das Zertifikat zu beschreiben. Suchen und wählen Sie die Zertifikatdatei für öffentliche Schlüssel (CER) aus. Wählen Sie die Option Hochladen aus, wenn Sie fertig sind.
Nachdem Sie das Zertifikat aus der Spalte "Fingerabdruck " hinzugefügt haben, kopieren Sie den Fingerabdruckwert des Zertifikats.
Wählen Sie im Ressourcenmenü der Logik-App die Option "Konfiguration" aus.
Wählen Sie auf der Registerkarte Anwendungseinstellungen die Option Neue Anwendungseinstellung aus. Fügen Sie eine neue Anwendungseinstellung namens WEBSITE_LOAD_ROOT_CERTIFICATES hinzu, und geben Sie den Zuvor kopierten Fingerabdruckwert des Zertifikats ein. Wenn Mehrere Zertifikatfingerabdruckwerte vorhanden sind, müssen Sie jeden Wert durch ein Komma (,) trennen.
Weitere Informationen finden Sie unter Bearbeiten von Host- und App-Einstellungen für Standardlogik-Apps in Azure Logic Apps mit einem Mandanten.
Hinweis
Wenn Sie einen Fingerabdruck für ein privates Zertifizierungsstellenzertifikat angeben, führt der integrierte MQ-Connector keine Zertifikatüberprüfung aus, z. B. das Überprüfen des Ablaufdatums oder der Quelle des Zertifikats. Wenn die standardmäßige .NET SSL-Überprüfung fehlschlägt, vergleicht der Connector nur einen Fingerabdruckwert, der mit dem Wert in der einstellung WEBSITE_LOAD_ROOT_CERTIFICATES übergeben wird.
Wenn das hinzugefügte Zertifikat nicht in der Liste der Zertifikate für öffentliche Schlüssel angezeigt wird, wählen Sie auf der Symbolleiste "Aktualisieren" aus.
Hinzufügen eines zertifikats privaten Schlüssels
Führen Sie die folgenden Schritte aus, um dem Host der vertrauenswürdigen Stammzertifizierungsstelle auf dem Host ihrer Standardlogik-App ein privates Schlüsselzertifikat hinzuzufügen:
Öffnen Sie Ihre Logik-App-Ressource im Azure-Portal. Wählen Sie im Ressourcenmenü der Logik-App unter Einstellungen TLS/SSL-Einstellungen (klassisch) aus.
Wählen Sie auf der Seite TLS/SSL-Einstellungen (klassisch) die Registerkarte "Private Key Certificates (.pfx)" und dann " Zertifikat hochladen" aus.
Suchen Und wählen Sie im daraufhin geöffneten Bereich "Private Key Certificate (.pfx)" die Datei für private Schlüsselzertifikate (PFX) aus, und geben Sie dann das Zertifikatkennwort ein. Wählen Sie die Option Hochladen aus, wenn Sie fertig sind.
Nachdem Sie das Zertifikat aus der Spalte "Fingerabdruck " hinzugefügt haben, kopieren Sie den Fingerabdruckwert des Zertifikats.
Wählen Sie im Ressourcenmenü der Logik-App die Option "Konfiguration" aus.
Wählen Sie auf der Registerkarte Anwendungseinstellungen die Option Neue Anwendungseinstellung aus. Fügen Sie eine neue Anwendungseinstellung namens WEBSITE_LOAD_CERTIFICATES hinzu, und geben Sie den Zuvor kopierten Fingerabdruckwert des Zertifikats ein.
Weitere Informationen finden Sie unter Bearbeiten von Host- und App-Einstellungen für Standardlogik-Apps in Azure Logic Apps mit einem Mandanten.
Wenn das hinzugefügte Zertifikat nicht in der Liste der privaten Schlüsselzertifikate angezeigt wird, wählen Sie auf der Symbolleiste "Aktualisieren" aus.
Wenn Sie eine Verbindung mit dem integrierten MQ-Verbinder erstellen, wählen Sie im Verbindungsinformationsfeld tls verwenden aus.
Geben Sie in der Client Cert Thumbprint-Eigenschaft den zuvor kopierten Fingerabdruckwert für das zertifikat für private Schlüssel ein, der die Server-Client-Authentifizierung (bidirektionale) Authentifizierung ermöglicht. Wenn Sie keinen Fingerabdruckwert eingeben, verwendet der Connector die servergeschützte Authentifizierung (unidirektionale Authentifizierung).
Behandeln von Problemen
Fehler beim Durchsuchen oder Empfangen von Aktionen
Wenn Sie eine Aktion zum Durchsuchen oder Empfangen für eine leere Warteschlange ausführen, schlägt die Aktion mit den folgenden Headerausgabe fehl:
Probleme bei der Verbindung und Authentifizierung
Wenn Ihr Workflow den verwalteten MQ-Connector zum Herstellen einer Verbindung mit Ihrem lokalen MQ-Server verwendet, wird möglicherweise die folgende Fehlermeldung angezeigt:
"MQ: Could not Connect the Queue Manager '<queue-manager-name>': The Server was expecting an SSL connection."
Der MQ-Server muss ein Zertifikat bereitstellen, das von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wird.
Für den MQ-Server muss eine Verschlüsselungsspezifikation zur Verwendung mit TLS-Connectors definiert werden. Aus Sicherheitsgründen und um die besten Sicherheitssammlungen zu verwenden, sendet das Windows-Betriebssystem jedoch eine Reihe unterstützter Verschlüsselungsspezifikationen.
Das Betriebssystem, unter dem der MQ-Server ausgeführt wird, wählt die zu verwendenden Suiten aus. Damit die Konfiguration übereinstimmen kann, müssen Sie das MQ-Server-Setup so ändern, dass die Verschlüsselungsspezifikation der in der TLS-Aushandlung ausgewählten Option entspricht.
Wenn Sie den Verbindungsaufbau versuchen, protokolliert der MQ-Server eine Ereignismeldung, dass der Verbindungsversuch nicht erfolgreich war, da am MQ-Server die falsche Verschlüsselungsspezifikation verwendet wurde. Die Ereignismeldung enthält die Verschlüsselungsspezifikation, die der MQ-Server aus der Liste ausgewählt hat. Aktualisieren Sie in der Konfiguration des Serververbindungskanals die Verschlüsselungsspezifikation so, dass sie der Verschlüsselungsspezifikation in der Ereignismeldung entspricht.