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 aus einem Workflow in Azure Logic Apps mit dem MQ-Connector auf einen in Azure gehosteten oder einen 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 mit alle Messagingfunktionalitäten zur Kommunikation mit einem MQ-Remoteserver über ein TCP/IP-Netzwerk umfasst. Dieser Connector definiert die Verbindungen, Vorgänge und Parameter zum Aufrufen des MQ-Clients.
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 | Azure Logic Apps mit mehreren Mandanten | Verwalteter Connector, der im Connectorkatalog unter Runtime>Freigegeben angezeigt wird. Dieser Connector stellt nur Aktionen und keine Trigger bereit. In Szenarien mit lokalem MQ-Server unterstützt der verwaltete Connector nur die Authentifizierung per Server mit TLS-Verschlüsselung (SSL). Weitere Informationen finden Sie in der folgenden Dokumentation: - Referenz zum verwalteten MQ-Connector - Verwaltete Connectors in Azure Logic Apps |
Standard | Einzelmandanteninstanz von Azure Logic Apps und App Service-Umgebung v3 (ASE v3 nur 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 und auf einem Dienstanbieter basiert Die integrierte Version unterscheidet sich wie folgt: – Die integrierte Version umfasst Aktionen und Trigger. - Der integrierte Connector kann sich direkt mit einem MQ-Server verbinden und auf virtuelle Azure-Netzwerke zugreifen, indem eine Verbindungszeichenfolge ohne lokales Datengateway verwendet wird. - Die integrierte Version unterstützt Serverauthentifizierung und Serverclientauthentifizierung mit TLS (SSL) für in Übertragung begriffene Daten, Nachrichtencodierung für Sende- und Empfangsvorgänge sowie Integration virtueller Azure-Netzwerke. Weitere Informationen finden Sie in der folgenden Dokumentation: - Referenz zum verwalteten MQ-Connector - Referenz zum integrierten MQ-Connector - Integrierte Connectors in Azure Logic Apps |
Authentifizierung mit TLS-Verschlüsselung (SSL)
Je nachdem, ob Sie den verwalteten MQ-Connector (Verbrauchs- oder Standard-Workflows) oder den integrierten MQ-Connector (nur Standard-Workflows) verwenden, unterstützt der MQ-Connector eine oder beide der folgenden Authentifizierungsrichtungen:
Authentifizierung | Unterstützter Logik-App-Typ und MQ-Connector | Prozess |
---|---|---|
Nur Server (unidirektional) |
- Verbrauch: Nur verwaltet - Standard: Verwaltet oder integriert |
Bei der Server-Authentifizierung sendet Ihr MQ-Server ein Zertifikat mit privatem Schlüssel, das entweder öffentlich vertrauenswürdig oder nicht öffentlich vertrauenswürdig ist, zur Validierung an Ihren Logic-App-Client. Der MQ Connector prüft das eingehende Serverzertifikat auf Authentizität anhand von Zertifikaten mit öffentlichem Schlüssel, die auch als "Signer"-Zertifikate bezeichnet werden, indem er die standardmäßige .NET SSL-Stream-Validierung verwendet. Die Logik-App sendet kein Client-Zertifikat. |
Server-Client (bidirektional) |
- Verbrauch: Nicht unterstützt - Standard: Nur integriert |
Informationen zur Serverauthentifizierung finden Sie in der vorherigen Zeile. Für die Client-Authentifizierung sendet der Logic-App-Client ein Zertifikat mit privatem Schlüssel zur Validierung an Ihren MQ-Server. Der MQ-Server prüft das eingehende Client-Zertifikat auch mit einem öffentlichen Schlüsselzertifikat auf Authentizität. |
Hinweise zu privaten und öffentlichen Schlüsselzertifikaten
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 Zertifikate, private Zertifizierungsstellenzertifikate und ähnliche Zertifikate.
Um ein von Ihrem MQ-Server gesendetes privates Schlüsselzertifikat zu überprüfen, verwendet der MQ-Connector öffentliche Schlüsselzertifikate, die in der Regel auf dem VNet-Host Ihrer Logik-App im Speicher vertrauenswürdiger Stammzertifizierungsstellen vorhanden sind.
Wenn der Host jedoch nicht über alle erforderlichen öffentlichen Schlüsselzertifikate verfügt oder der 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 Standard-Logik-App gesendet wird, verwendet der MQ-Server öffentliche Schlüsselzertifikate, die im Zertifikatspeicher Ihres MQ-Servers vorhanden sind. Informationen zum Hinzufügen eines privaten Schlüsselzertifikats für Ihre Logik-App, die als Clientzertifikat verwendet werden soll, finden Sie unter Hinzufügen eines privaten Schlüsselzertifikats.
Begrenzungen
Authentifizierung mit TLS-Verschlüsselung (SSL)
MQ-Connector Unterstützte Authentifizierungsrichtung Verwaltet Nur Server (unidirektional) Integriert - Server-Client (bidirektional)
- Nur Server (unidirektional)Überprüfung des Serverzertifikats
Der integrierte MQ-Connector überprüft weder das Ablaufdatum des Serverzertifikats noch die Zertifikatkette.
Konvertierungen von Zeichensätzen
Der verwaltete MQ-Connector nimmt weder Konvertierungen von Zeichensätzen vor noch verwendet er das Feld Format der Nachricht. Der Connector kopiert nur die Daten im Nachrichtenfeld und übermittelt diese Nachricht.
Der integrierte MQ-Connector 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.
Zum Herstellen einer Verbindung mit einem lokalen MQ-Server 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, in dem Sie auf Ihren MQ-Server zugreifen möchten.
Wenn Sie den verwalteten MQ-Connector mit dem lokalen Datengateway verwenden möchten, muss Ihre Logik-App-Ressource denselben Speicherort wie Ihre Gatewayressource in Azure verwenden.
Wenn Sie den verwalteten MQ-Connector verwenden möchten, der keine Trigger bereitstellt, stellen Sie sicher, dass Ihr Workflow mit einem Trigger beginnt oder dass Sie Ihrem Workflow zuerst einen Trigger hinzufügen. Sie können beispielsweise den Wiederholungstrigger verwenden.
Um einen Trigger vom integrierten MQ Connector zu verwenden, müssen Sie mit einem leeren Workflow beginnen.
Zertifikatanforderungen für die Authentifizierung mit SSL-Verschlüsselung (TLS)
Verwalteter MQ-Connector
MQ-Server Anforderungen In Azure-gehosteter MQ-Server Der MQ-Server muss ein privates Schlüsselzertifikat, das von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wird, zur Überprüfung an Ihren Logik-App-Client senden. Lokaler MQ-Server mit lokalem Datengateway Um ein nicht öffentlich vertrauenswürdiges privates Schlüsselzertifikat wie ein selbstsigniertes Zertifikat oder ein privates Zertifizierungsstellenzertifikat zu senden, müssen Sie das Zertifikat dem Speicher vertrauenswürdiger Stammzertifizierungsstellen auf dem lokalen Computer mit der Installation des lokalen Datengateways hinzufügen. Für diese Aufgabe können Sie den Windows-Zertifikat-Manager (certmgr.exe) verwenden. Integrierter MQ-Connector
Standardlogik-Apps verwenden Azure App Service als Hostplattform und zum Verarbeiten von Zertifikaten. Für Standard-Logikanwendungen auf einem WS*-Plan können Sie öffentliche, private, benutzerdefinierte oder selbst signierte Zertifikate zum lokalen Zertifikatspeicher des Computers hinzufügen. Wenn Sie jedoch Zertifikate zum Trusted Root CA Store auf dem virtuellen Computer-Host hinzufügen müssen, auf dem Ihre Standard-Logik-App ausgeführt wird, erfordert App Service, dass Ihre Logik-App in einer isolierten App Service-Umgebung v3 (ASE) mit einem Windows-only und einem ASE-basierten App Service-Plan ausgeführt wird. Weitere Informationen finden Sie unter Zertifikate und die App Service-Umgebung.
MQ-Serverauthentifizierung
Die folgende Tabelle beschreibt die Voraussetzungen für das Zertifikat, je nach Ihrem Szenario:
Eingehendes MQ-Serverzertifikat Anforderungen Öffentlich vertrauenswürdiges Privatschlüssel-Zertifikat, ausgestellt von einer vertrauenswürdigen Zertifizierungsstelle In der Regel benötigt Ihre Logik-Anwendung keine weiteren Einstellungen, da der Host der virtuellen Maschine Ihrer Logik-Anwendung in der Regel über die erforderlichen öffentlichen Schlüsselzertifikate verfügt, um das private Schlüsselzertifikat des eingehenden MQ-Servers zu validieren. Um zu überprüfen, ob diese öffentlichen Schlüsselzertifikate existieren, folgen Sie den Schritten Ansicht und Bestätigung der Miniaturabdrücke für bestehende öffentliche Schlüsselzertifikate.
Wenn der VM-Host nicht über alle erforderlichen öffentlichen Schlüsselzertifikate 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 Standard-Logik-App mithilfe von Azure App Service-Umgebung v3 (ASE) mit ASE-basierten App Service-Plan nur für Windows neu.
2. Fügen Sie die erforderlichen öffentlichen Schlüsselzertifikate manuell zum Speicher vertrauenswürdiger Stammzertifizierungsstellen des Hosts hinzu.Nicht öffentlich vertrauenswürdiges privates Schlüsselzertifikat, wie z. B. ein selbstsigniertes oder privates CA-Zertifikat Der VM-Host der Logik-App verfügt nicht über die erforderlichen öffentlichen Schlüsselzertifikate im Speicher vertrauenswürdiger Stammzertifizierungsstellen 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 Standard-Logik-App mithilfe von Azure App Service-Umgebung v3 (ASE) mit ASE-basierten App Service-Plan nur für Windows neu.
2. Fügen Sie die erforderlichen öffentlichen Schlüsselzertifikate manuell zum Speicher vertrauenswürdiger Stammzertifizierungsstellen des Hosts hinzu.
Weitere Informationen finden Sie in der folgenden Dokumentation:
- Zertifikatsbindungen und die App Service Umgebung
- Hinzufügen und Verwalten von TLS/SSL-Zertifikaten in Azure App ServiceLogic App Client-Authentifizierung
Sie können ein Zertifikat mit privatem Schlüssel hinzufügen, das als Client-Zertifikat gesendet werden soll, und dann den Thumbprint-Wert des Zertifikats in den Verbindungsdetails für den integrierten MQ-Connector angeben. Weitere Informationen finden Sie unter Zertifikat eines privaten Schlüssels hinzufügen.
Empfehlung: Upgraden auf MQ Server 9.0 oder höher. Stellen Sie zudem sicher, dass Sie auf Ihrem MQ-Server den Server-Verbindungskanal mit einer Verschlüsselungssuite einrichten, die mit der von Ihrer Verschlüsselungssuite verwendeten VerschlüsselungssuiteSpezifikation übereinstimmt, zum Beispiel ANY_TLS12_OR_HIGHER. Weitere Informationen finden Sie im nächsten Punkt zu den Verschlüsselungsanforderungen.
Anforderungen an die Verschlüsselungsspezifikation
Der MQ-Server erfordert, dass Sie die Verschlüsselungsspezifikation für Verbindungen festlegen, die TLS (SSL)-Verschlüsselung verwenden. Diese Cipher-Spezifikation muss mit den Cipher-Suites übereinstimmen, die von dem Betriebssystem, auf dem der MQ-Server läuft, unterstützt, ausgewählt und verwendet werden. Letztendlich muss die von der Client-Verbindung verwendete Chiffrierspezifikation mit den Chiffriersuiten übereinstimmen, die im Server-Verbindungskanal 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 integrierten MQ-Trigger hinzuzufügen. Weitere Informationen finden Sie unter Trigger für integrierte MQ-Connectors.
Geben Sie die erforderlichen Informationen zum Authentifizieren Ihrer Verbindung an. 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.
Geben Sie die erforderlichen Informationen zum Authentifizieren Ihrer Verbindung an. 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 Ihren Workflow aus, und überprüfen Sie dann die Ausgaben aus dem Ausführungsverlauf Ihres 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 Standard-Logik-App-Workflows für den integrierten MQ-Connector mit reiner Serverauthentifizierung oder mit Serverclientauthentifizierung mit TLS-Verschlüsselung (SSL).
Anzeigen und Bestätigen von Fingerabdrücken für vorhandene öffentliche Schlüsselzertifikate
Um zu überprüfen, ob die Fingerabdrücke für die erforderlichen öffentlichen Schlüsselzertifikate auf dem VM-Host Ihrer Standard-Logik-App im Speicher vertrauenswürdiger Stammzertifizierungsstellen vorhanden sind, führen Sie die folgenden Schritte aus, um das cert
-PowerShell-Skript aus dem Ressourcenmenü der Standard-Logik-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>Los aus.
Wählen Sie im Menü der Debugging-Konsole von Kudu die Option PowerShell aus.
Führen Sie nach dem Öffnen des PowerShell-Fensters an der PowerShell-Eingabeaufforderung das folgende Skript aus:
dir cert:\localmachine\root
Im PowerShell-Fenster werden die vorhandenen Fingerabdrücke und Beschreibungen aufgeführt, z. B.:
Hinzufügen eines öffentlichen Schlüsselzertifikats
Führen Sie die folgenden Schritte aus, um dem Speicher vertrauenswürdiger Stammzertifizierungsstellen auf dem VM-Host, auf dem Ihre Standard-Logik-App ausgeführt wird, in ein öffentliches Schlüsselzertifikat hinzuzufügen:
Öffnen Sie im Azure-Portal Ihre Ressource vom Typ „Logic App (Standard)“. Wählen Sie im Menü Ihrer Logik-App-Ressource unter Einstellungen die Option TLS/SSL-Einstellungen (klassisch) aus.
Wählen Sie auf der Seite TLS/SSL-Einstellungen (klassisch) die Registerkarte Öffentliche Schlüsselzertifikate (CER) und dann Öffentliches Schlüsselzertifikat hochladen aus.
Geben Sie im daraufhin geöffneten Bereich Öffentliches Schlüsselzertifikat (CER) hinzufügen einen Namen ein, um das Zertifikat zu beschreiben. Suchen Sie nach der Datei für das öffentliche Schlüsselzertifikat(.cer), und wählen Sie sie aus. Wählen Sie die Option Hochladen aus, wenn Sie fertig sind.
Nachdem Sie das Zertifikat hinzugefügt haben, kopieren Sie aus der Spalte Fingerabdruck den Fingerabdruckwert des Zertifikats.
Wählen Sie im Menü der Logik-App-Ressource 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 Fingerabdruckwert des Zertifikats ein, den Sie zuvor kopiert haben. Wenn mehrere Zertifikatfingerabdruckwerte vorhanden sind, müssen Sie die einzelnen Werte durch ein Komma (,) trennen.
Weitere Informationen finden Sie unter Bearbeiten von Einstellungen für Hosts und Apps für Standard-Logik-Apps in Azure Logic Apps-Instanzen mit einem einzelnen Mandanten.
Hinweis
Wenn Sie einen Fingerabdruck für ein privates Zertifizierungsstellenzertifikat angeben, führt der integrierte MQ-Connector keine Zertifikatüberprüfung aus, d. h. er überprüft beispielsweise nicht das Ablaufdatum oder die Quelle des Zertifikats. Wenn die standardmäßige .NET-SSL-Überprüfung fehlschlägt, vergleicht der Connector nur übergebene Fingerabdruckwerte mit dem Wert in der Einstellung WEBSITE_LOAD_ROOT_CERTIFICATES.
Wenn das hinzugefügte Zertifikat nicht in der Liste der öffentlichen Schlüsselzertifikate angezeigt wird, wählen Sie auf der Symbolleiste Aktualisieren aus.
Hinzufügen eines privaten Schlüsselzertifikats
Führen Sie die folgenden Schritte aus, um dem Speicher vertrauenswürdiger Stammzertifizierungsstellen auf dem VM-Host, auf dem Ihre Standard-Logik-App ausgeführt wird, in ein privates Schlüsselzertifikat hinzuzufügen:
Öffnen Sie Ihre Logik-App-Ressource im Azure-Portal. Wählen Sie im Menü Ihrer Logik-App-Ressource unter Einstellungen die Option TLS/SSL-Einstellungen (klassisch) aus.
Wählen Sie auf der Seite TLS/SSL-Einstellungen (klassisch) die Registerkarte Private Schlüsselzertifikate (pfx) und dann Zertifikat hochladen aus.
Suchen Sie im daraufhin geöffneten Bereich Privates Schlüsselzertifikat (PFX) hinzufügen nach der Datei für das private Schlüsselzertifikat (PFX), und wählen Sie sie aus, und geben Sie dann das Zertifikatkennwort ein. Wählen Sie die Option Hochladen aus, wenn Sie fertig sind.
Nachdem Sie das Zertifikat hinzugefügt haben, kopieren Sie aus der Spalte Fingerabdruck den Fingerabdruckwert des Zertifikats.
Wählen Sie im Menü der Logik-App-Ressource 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 Fingerabdruckwert des Zertifikats ein, den Sie zuvor kopiert haben.
Weitere Informationen finden Sie unter Bearbeiten von Einstellungen für Hosts und Apps für Standard-Logik-Apps in Azure Logic Apps-Instanzen mit einem einzelnen 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 Eigenschaft Fingerabdruck des Clientzertifikats den zuvor kopierten Fingerabdruckwert für das private Schlüsselzertifikat ein. Dadurch wird die Serverclientauthentifizierung (bidirektional) ermöglicht. Wenn Sie keinen Fingerabdruckwert eingeben, verwendet der Connector die reine Serverauthentifizierung (unidirektional).
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 Connector verwendet, um eine Verbindung mit dem lokalen MQ-Server herzustellen, 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 Server-Verbindungskanals die Verschlüsselungsspezifikation, damit sie mit der Verschlüsselungsspezifikation in der Ereignismeldung übereinstimmt.