Was sind Connectors in Azure Logic Apps
Wenn Sie einen Workflow mithilfe von Azure Logic Apps erstellen, können Sie einen Connector verwenden, um ohne das Schreiben von Code mit Daten, Ereignissen und Ressourcen in anderen Apps, Diensten und Systemen sowie auf anderen Plattformen zu arbeiten. Ein Connector stellt einen oder mehrere vordefinierte Vorgänge bereit, die Sie als Schritte in Ihrem Workflow verwenden.
Bei einem Connector ist jeder Vorgang entweder eine Triggerbedingung, die einen Workflow startet, oder eine nachfolgende Aktion, die eine bestimmte Aufgabe ausführt, sowie Eigenschaften, die Sie konfigurieren können. Während viele Connectors sowohl Trigger als auch Aktionen umfassen, bieten einige Connectors nur Trigger, während andere nur Aktionen bereitstellen.
In Azure Logic Apps stehen Connectors entweder in einer integrierten Version, verwalteten Version oder beidem zur Verfügung. Viele Connectors erfordern in der Regel, dass Sie zuerst eine Verbindung mit dem zugrunde liegenden Dienst oder System herstellen und konfigurieren. Auf diese Weise können Sie den Zugriff auf ein Benutzerkonto authentifizieren. Wenn kein Connector für den Dienst oder das System verfügbar ist, auf den bzw. das Sie zugreifen möchten, können Sie eine Anforderung mithilfe des generischen HTTP-Vorgangssenden oder einen benutzerdefinierten Connector erstellen.
Diese Übersicht enthält eine grundlegende Einführung in Connectors und ihre allgemeine Funktionsweise. Weitere Informationen zu Connectors finden Sie in der folgenden Dokumentation:
- Dokumentation zu Power Platform- und Azure Logic Apps-Connectors
- Übersicht über integrierte Connectors für Azure Logic Apps
- Verwaltete Connectors in Azure Logic Apps
- Referenz für verwalteten Connectors in Azure Logic Apps
Integrierte Connectors im Vergleich zu verwalteten Connectors
In Azure Logic Apps sind Connectors entweder integriert oder verwaltete. Einige Connectors umfassen beide Versionen. Die verfügbaren Versionen hängen davon ab, ob Sie einen Logik-App-Verbrauchsworkflow erstellen, der in Azure Logic Apps-Instanzen mit mehreren Mandanten ausgeführt wird, oder einen Logik-App-Standardworkflow, der in Azure Logic Apps-Instanzen mit einem Mandanten ausgeführt wird. Weitere Informationen zu Logik-App-Ressourcentypen finden Sie im Abschnitt zu den Unterschieden zwischen den Ressourcentypen und Hostumgebungen.
Integrierte Connectors sind so konzipiert, dass sie direkt und nativ in Azure Logic Apps ausgeführt werden.
Verwaltete Connectors werden von Microsoft in Azure bereitgestellt, gehostet und verwaltet. Verwaltete Connectors stellen hauptsächlich einen Proxy oder einen Wrapper für eine API bereit, die der zugrunde liegende Dienst oder das zugrunde liegende System für die Kommunikation mit Azure Logic Apps verwendet.
In einem Verbrauchsworkflow werden verwaltete Connectors basierend auf ihrem Preisniveau im Designer unter den Bezeichnungen Standard oder Enterprise angezeigt.
In einem Standardworkflow werden alle verwalteten Connectors im Designer unter der Bezeichnung Azure angezeigt.
Weitere Informationen finden Sie in der folgenden Dokumentation:
Auslöser
Ein Trigger gibt die Bedingung an, die erfüllt werden soll, bevor der Workflow gestartet werden kann. Zudem ist der Trigger immer der erste Schritt in jedem Workflow. Jeder Trigger folgt zudem einem bestimmten Auslösemuster, das steuert, wie der Trigger Ereignisse überwacht und darauf reagiert. In der Regel folgt ein Trigger entweder einem Abrufmuster oder einem Pushmuster. Manchmal sind beide Triggerversionen verfügbar.
Abfragetrigger überprüfen regelmäßig einen bestimmten Dienst oder ein bestimmtes System nach einem bestimmten Zeitplan, um nach neuen Daten oder einem bestimmten Ereignis zu suchen. Wenn neue Daten verfügbar sind oder das spezifische Ereignis eintritt, erstellen diese Trigger eine neue Instanz Ihres Workflows und führen sie aus. Diese neue Instanz kann dann die Daten verwenden, die als Eingabe übergeben werden.
Hinweis
Bei Connectors, die von Microsoft verwaltet, gehostet und in Azure ausgeführt werden, verwenden Abruftrigger nur die Werte Intervall und Frequenz zum Berechnen der nächsten Serie. Sie verwenden nicht die erweiterten Planungsoptionen (z. B. Zu diesen Stunden und An diesen Tagen). Diese Optionen funktionieren nur mit integrierten Abruftriggern, die direkt mit der Azure Logic Apps-Runtime ausgeführt werden (z. B. den Triggern Serie, Gleitendes Fenster und HTTP).
Die Trigger Push bzw. Webhook lauschen auf neue Daten oder darauf, dass ein Ereignis ohne Abruf erfolgt. Wenn neue Daten verfügbar sind oder das Ereignis eintritt, erstellen diese Trigger eine neue Instanz Ihres Workflows und führen sie aus. Diese neue Instanz kann dann die Daten verwenden, die als Eingabe übergeben werden.
Angenommen, Sie möchten einen Workflow erstellen, der ausgeführt wird, wenn eine Datei auf Ihren FTP-Server hochgeladen wird. Als ersten Schritt in Ihrem Workflow können Sie den FTP-Trigger namens Wenn eine Datei hinzugefügt oder geändert wird hinzufügen, der einem Abrufmuster folgt. Anschließend geben Sie den Zeitplan an, mit dem regelmäßig überprüft werden soll, ob Uploadereignisse vorliegen.
Wenn der Trigger ausgelöst wird, übergibt der Trigger in der Regel Ereignisausgaben für nachfolgende Aktionen, auf die verwiesen werden soll und die verwendet werden sollen. Für das FTP-Beispiel gibt der Trigger automatisch Informationen aus (z. B. den Dateinamen und den Pfad). Sie können den Trigger auch so einrichten, dass er den Dateiinhalt enthält. Um diese Daten zu verarbeiten, müssen Sie Ihrem Workflow Aktionen hinzufügen.
Aktionen
Eine Aktion gibt eine auszuführende Aufgabe an und wird immer als nachfolgender Schritt im Workflow angezeigt. Sie können mehrere Aktionen in Ihrem Workflow verwenden. Beispielsweise können Sie den Workflow mit einem SQL Server-Trigger starten, der auf neue Kundendaten in einer SQL-Datenbank überprüft. Nach dem Trigger kann Ihr Workflow eine SQL Server-Aktion verwenden, die die Kundendaten abruft. Nach dieser SQL Server-Aktion kann Ihr Workflow eine andere Aktion verwenden, die die Daten verarbeitet (z. B. eine Datenvorgangsaktion, die eine CSV-Tabelle erstellt).
Verbindungsberechtigungen
Vor dem Erstellen oder Verwalten von Logik-App-Ressourcen, Workflows und deren Verbindungen benötigen Sie bei einem Logik-App-Verbrauchsworkflow bestimmte Berechtigungen. Weitere Informationen zu diesen Berechtigungen finden Sie unter Zugriff auf Logik-App-Vorgänge.
Erstellung, Konfiguration und Authentifizierung von Verbindungen
Bevor Sie die Vorgänge eines Connectors in Ihrem Workflow verwenden können, ist bei vielen Connectors zuerst das Herstellen einer Verbindung mit dem Zieldienst oder -system erforderlich. Um eine Verbindung über den Workflow-Designer zu erstellen, müssen Sie Ihre Identität mit Kontoanmeldeinformationen und manchmal anderen Verbindungsinformationen authentifizieren.
Bevor Ihr Workflow beispielsweise auf Ihr Office 365 Outlook-E-Mail-Konto zugreifen und damit arbeiten kann, müssen Sie eine Verbindung mit diesem Konto autorisieren. Für einige integrierte Connectors und verwaltete Connectors können Sie eine verwaltete Identität für die Authentifizierung einrichten und verwenden, anstatt Ihre Anmeldeinformationen anzugeben.
Obwohl Sie Verbindungen in einem Workflow erstellen, sind diese Verbindungen eigentlich separate Azure-Ressourcen mit eigenen Ressourcendefinitionen. Führen Sie zum Überprüfen dieser Verbindungsressourcendefinitionen die folgenden Schritte aus, je nachdem, ob Sie über einen Verbrauchs- oder Standardworkflow verfügen:
Verbrauch
Informationen zum Anzeigen und Verwalten dieser Verbindungen im Azure-Portal finden Sie unter Anzeigen von Verbindungen für Verbrauchsworkflows im Azure-Portal.
Informationen zum Anzeigen und Verwalten dieser Verbindungen in Visual Studio finden Sie unter Verwalten von Verbrauchsworkflows mit Visual Studio. Laden Sie zudem Ihre Logik-App-Ressource aus Azure in Visual Studio.
Weitere Informationen zu Verbindungsressourcendefinitionen für Verbrauchsworkflows finden Sie unter Verbindungsressourcendefinitionen.
Standard
Unter Anzeigen von Verbindungen wird erläutert, wie Sie diese Verbindungen im Azure-Portal anzeigen und verwalten können.
Informationen zum Anzeigen und Verwalten dieser Verbindungen in Visual Studio Code finden Sie unter Verwalten bereitgestellter Logik-Apps in Visual Studio Code. Die Datei connections.json enthält die erforderliche Konfiguration für die von Connectors erstellten Verbindungen.
Verbindungssicherheit und -Verschlüsselung
Verbindungskonfigurationsdetails wie Serveradresse, Benutzername und Kennwort, Anmeldeinformationen und Geheimnisse werden verschlüsselt und in der sicheren Azure-Umgebung gespeichert. Diese Informationen können nur in logischen Anwendungsressourcen und von Clients verwendet werden, die über Berechtigungen für die Verbindungsressource verfügen, was durch verknüpfte Zugriffsprüfungen erzwungen wird. Verbindungen, die Microsoft Entra ID Open Authorization (Microsoft Entra ID OAuth) verwenden (z. B. Office 365, Salesforce und GitHub), erfordern, dass Sie sich anmelden, aber Azure Logic Apps speichert nur Zugriffs- und Aktualisierungstokens als Geheimnisse, nicht als Anmeldeinformationen.
Hergestellte Verbindungen können solange auf den Zieldienst oder das Zielsystem zugreifen, wie der Dienst oder das System dies zulässt. Bei Diensten, die Microsoft Entra ID OAuth-Verbindungen verwenden (z. B. Office 365 und Dynamics), aktualisiert Azure Logic Apps die Zugriffstoken unbegrenzt. Bei anderen Diensten gibt es unter Umständen eine zeitliche Begrenzung für die Verwendung eines Tokens durch Logic Apps, nach der eine Aktualisierung erforderlich ist. Durch einige Aktionen (z. B. Ändern des Kennworts) werden alle Zugriffstoken ungültig.
Hinweis
Wenn Ihre Organisation den Zugriff auf bestimmte Ressourcen über Connectors in Azure Logic Apps nicht zulässt, können Sie mithilfe von Azure Policy die Möglichkeit zum Erstellen solcher Verbindungen blockieren.
Weitere Informationen zum Schützen von Logik-App-Workflows und -Verbindungen finden Sie unter Schützen des Zugriffs und der Daten für Workflows in Azure Logic Apps.
Firewallzugriff für Verbindungen
Falls Sie eine Firewall verwenden, die Datenverkehr beschränkt, und Ihr Logik-App-Workflow über diese Firewall kommunizieren muss, müssen Sie die Firewall so einrichten, dass der Zugriff sowohl für die eingehenden als auch die ausgehenden IP-Adressen zulässig ist, die von der Logic Apps-Plattform oder -Runtime in der Azure-Region Ihres Logik-App-Workflows genutzt werden.
Wenn Ihre Workflows auch verwaltete Connectors verwenden (z. B. den Office 365-Outlook-Connector oder SQL-Connector) oder benutzerdefinierte Connectors verwenden, muss Ihre Firewall auch den Zugriff für alle verwalteten ausgehenden IP-Adressen für Connectors in der Azure-Region Ihrer Logik-App-Ressource zulassen. Weitere Informationen finden Sie unter Firewallkonfiguration.
Benutzerdefinierte Connectors und APIs
Bei Verbrauchsworkflows für Azure Logic Apps-Instanzen mit mehreren Mandanten können Sie Swagger- oder SOAP-basierte APIs aufrufen, die nicht als sofort einsatzbereite Connectors verfügbar sind. Sie können auch benutzerdefinierten Code ausführen, indem Sie benutzerdefinierte API-Apps erstellen. Weitere Informationen finden Sie in der folgenden Dokumentation:
Swagger- oder SOAP-basierte benutzerdefinierte Connectors für Verbrauchsworkflows
Erstellen Sie einen Swagger- oder SOAP-basierten benutzerdefinierten Connector, der diese APIs für jeden Logik-App-Verbrauchsworkflow in Ihrem Azure-Abonnement verfügbar macht.
Wenn Sie Ihren benutzerdefinierten Connector für alle Benutzer in Azure öffentlich verfügbar machen möchten, können Sie den Connector für die Microsoft-Zertifizierung einreichen.
Bei Standardworkflows für Azure Logic Apps-Instanzen mit einem Mandanten können Sie benutzerdefinierte integrierte Connectors erstellen, die nativ ausgeführt werden, auf dem Dienstanbieter basieren und für alle Logik-App-Standardworkflows verfügbar sind. Weitere Informationen finden Sie in der folgenden Dokumentation:
Bekannte Probleme
Die folgende Tabelle enthält bekannte Probleme im Zusammenhang mit Connectors in Azure Logic Apps:
Fehlermeldung | Beschreibung | Lösung |
---|---|---|
Error: BadGateway. Client request id: '{GUID}' |
Dieser Fehler tritt auf, wenn Sie die Tags für eine Logik-App-Ressource aktualisieren, bei der mindestens eine Verbindung die Microsoft Entra ID OAuth-Authentifizierung nicht unterstützt (z. B. SFTP und SQL führen zu einer Unterbrechung dieser Verbindungen). | Um dieses Verhalten zu vermeiden, sollten Sie diese Tags nicht aktualisieren. |