Informationen zu Connectors in Azure Logic Apps

Wenn Sie Workflows mithilfe von Azure Logic Apps erstellen, können Sie mit Connectors schnell und einfach auf Daten, Ereignisse und Ressourcen in anderen Apps, Diensten, Systemen, Protokollen und Plattformen zu zugreifen – häufig ohne Code zu schreiben. Ein Connector bietet vordefinierte Vorgänge, die Sie als Schritte in Ihren Workflows verwenden können. Azure Logic Apps bietet Hunderte von Connectors, die Sie verwenden können. Wenn kein Connector für die Ressource verfügbar ist, auf die Sie zugreifen möchten, können Sie den generischen HTTP-Vorgang verwenden, um mit dem Dienst zu kommunizieren, oder Sie können einen benutzerdefinierten Connector erstellen.

Diese Übersicht enthält eine grundlegende Einführung in Connectors und ihre allgemeine Funktionsweise.

Was sind Konnektoren?

Technisch gesehen stellen viele Connectors einen Proxy oder Wrapper um eine API herum bereit, den der zugrunde liegende Dienst für die Kommunikation mit Azure Logic Apps verwendet. Dieser Connector stellt Vorgänge zur Verfügung, die Sie in Ihren Workflows zum Ausführen von Aufgaben verwenden. Ein Vorgang ist entweder als Trigger oder Aktion verfügbar, dessen/deren Eigenschaften Sie konfigurieren können. Einige Trigger und Aktionen erfordern auch, dass Sie zuerst eine Verbindung mit dem zugrunde liegenden Dienst oder System herstellen und konfigurieren, damit Sie z. B. den Zugriff auf ein Benutzerkonto authentifizieren können. Weitere grundlegende Informationen finden Sie unter Übersicht über Connectors für Azure Logic Apps, Microsoft Power Automate und Microsoft Power Apps.

Informationen zu den gängigeren und häufig verwendeten Connectors in Azure Logic Apps finden Sie in den folgenden Dokumentationen:

Trigger

Ein Trigger gibt das Ereignis an, das den Workflow startet, und ist immer der erste Schritt in einem Workflow. Jeder Trigger folgt zudem einem bestimmten Auslösemuster, das steuert, wie der Trigger Ereignisse überwacht und darauf reagiert. Normalerweise folgt ein Trigger dem Abrufmuster oder Pushmuster, manchmal ist ein Trigger jedoch in beiden Versionen 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.

  • Pushtrigger 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.

Beispielsweise können Sie einen Workflow erstellen, der etwas auslöst, wenn eine Datei auf Ihren FTP-Server hochgeladen wird. Als ersten Schritt in Ihrem Workflow können Sie den FTP-Trigger mit dem Namen Wenn eine Datei hinzugefügt oder geändert wird verwenden, welcher dem Abrufmuster folgt. Sie können dann einen Zeitplan angeben, um regelmäßig nach Upload-Ereignissen zu sehen.

Ein Trigger übergibt auch alle Eingaben und anderen erforderlichen Daten an Ihren Workflow, wo spätere Aktionen auf diese Daten im gesamten Workflow verweisen und diese verwenden können. Wenn Sie beispielsweise den Office 365 Outlook-Trigger mit dem Namen Wenn eine neue E-Mail eintrifft verwenden möchten, um einen Workflow zu starten, wenn Sie eine neue E-Mail erhalten. Sie können diesen Trigger so konfigurieren, dass der Inhalt jeder neuen E-Mail übergeben wird, z. B. Absender, Betreffzeile, Text, Anlagen und so weiter. Der Workflow kann diese Informationen dann mithilfe anderer Aktionen verarbeiten.

Aktionen

Eine Aktion ist ein Vorgang, der dem Trigger folgt und eine Art von Aufgabe in Ihrem Workflow ausführt. Sie können mehrere Aktionen in Ihrem Workflow verwenden. Beispielsweise können Sie den Workflow mit einem SQL-Trigger starten, der neue Kundendaten in einer SQL-Datenbank erkennt. Nach dem Trigger kann der Workflow eine SQL-Aktion beinhalten, die die Kundendaten abruft. Nach der SQL-Aktion kann Ihr Workflow eine andere Aktion beinhalten, die die Daten verarbeitet.

Konnektorkategorien

In Azure Logic Apps sind die meisten Trigger und Aktionen entweder in einer integrierten Version oder einer verwalteten Connector-Version verfügbar. In beiden Versionen sind einige Trigger und Aktionen verfügbar. Die verfügbaren Versionen hängen davon ab, ob Sie eine verbrauchsbasierte Logik-App erstellen, die in einer mehrinstanzenfähigen Azure Logic Apps-Instanz ausgeführt wird, oder eine Standard-Logik-App, die in einer Azure Logic Apps-Instanz mit einem einzelnen Mandanten ausgeführt wird.

  • Integrierte Connectors werden nativ in der Azure Logic Apps-Runtime ausgeführt.

  • Verwaltete Konnektoren werden von Microsoft bereitgestellt, gehostet und verwaltet. Diese Konnektoren bieten Trigger und Aktionen für Cloud-Dienste, lokale Systeme oder beides.

    Bei einer Logik-App vom Typ Standard werden alle verwalteten Connectors als Azure-Connectors organisiert. Bei einer Logik-App vom Typ Verbrauch werden verwaltete Connectors dagegen basierend auf der Preisstufe unter Standard oder Enterprise organisiert.

Weitere Informationen zu Logik-App-Typen finden Sie unter Unterschiede zwischen Ressourcentyp und Hostumgebung.

Verbindungskonfiguration

Bei verbrauchsbasierten Logik-Apps benötigen Sie bestimmte Berechtigungen, bevor Sie Logik-Apps und deren Verbindungen erstellen oder verwalten können. Weitere Informationen zu diesen Berechtigungen finden Sie unter Sichere Vorgänge – Schützen des Zugriffs und der Daten in Azure Logic Apps.

Bevor Sie die Trigger oder Aktionen eines verwalteten Connectors in Ihrem Workflow verwenden können, müssen Sie bei vielen Connectors zunächst eine Verbindung mit dem Zieldienst oder -system herstellen. Zum Erstellen einer Verbindung im Logik-App-Workflow-Designer müssen Sie Ihre Identität mit Kontoanmeldeinformationen und manchmal auch mit 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 Anzeigen dieser Verbindungsressourcendefinitionen die folgenden Schritte aus, je nachdem, ob Sie über eine verbrauchsbasierte oder eine Standard-Logik-App verfügen:

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 Azure Active Directory Open Authentication (Azure AD OAuth) verwenden, wie z. B. Office 365, Salesforce und GitHub, erfordern eine Anmeldung, aber Azure Logic Apps speichert nur Zugriffs- und Aktualisierungs-Tokens als Geheimnisse, keine Anmeldedaten.

Hergestellte Verbindungen können solange auf den Zieldienst oder das Zielsystem zugreifen, wie der Dienst oder das System dies zulässt. Bei Diensten, die Azure AD-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.

Tipp

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 Sichern von Logic Apps und Verbindungen finden Sie unter Sicherer Zugriff und Daten 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. Falls für Ihren Workflow auch verwaltete Connectors (z. B. Office 365 Outlook-Connector oder SQL-Connector) oder benutzerdefinierte Connectors verwendet werden, muss in der Firewall in der Azure-Region Ihrer Logik-App zusätzlich der Zugriff für alle ausgehenden IP-Adressen der verwalteten Connectors zulässig sein. Weitere Informationen finden Sie unter Firewall-Konfiguration.

Wiederholungsverhalten

Wiederkehrende integrierte Trigger, z. B. der Wiederholungstrigger, werden nativ in der Azure Logic Apps-Runtime ausgeführt und unterscheiden sich von wiederkehrenden verbindungsbasierten Triggern, z. B. dem Office 365 Outlook-Connectortrigger, bei dem Sie zuerst eine Verbindung erstellen müssen.

Für beide Triggerarten gilt: Wenn eine Serie kein bestimmtes Startdatum und keine Startuhrzeit angibt, wird die erste Wiederholung trotz der Serieneinrichtung Ihres Triggers sofort ausgeführt, wenn Sie die Logik-App speichern oder bereitstellen. Um dieses Verhalten zu vermeiden, geben Sie ein Startdatum und eine Startuhrzeit für die Ausführung der ersten Wiederholung an.

Einige verwaltete Connectors verfügen sowohl über wiederholungsbasierte als auch auf Webhooks basierende Trigger. Wenn Sie einen wiederholungsbasierten Trigger verwenden, sollten Sie die Übersicht über das Wiederholungsverhalten lesen.

Integrierte Trigger für Wiederholungen

Integrierte Trigger für Wiederholungen folgen dem von Ihnen festgelegten Zeitplan, einschließlich der von Ihnen angegebenen Zeitzone. Wenn eine Serie jedoch keine weiteren erweiterten Zeitplanungsoptionen angibt, wie z. B. spezifische Uhrzeiten zum Ausführen zukünftiger Wiederholungen, basieren diese Wiederholungen auf der letzten Triggerausführung. Hieraus ergibt sich, dass die Startzeiten für diese Wiederholungen sich aufgrund von Faktoren wie Wartezeiten während Speicheraufrufen verschieben können.

Weitere Informationen finden Sie in der folgenden Dokumentation:

Wiederholung für verbindungsbasierte Trigger

Bei sich wiederholenden verbindungsbasierten Triggern wie Office 365 Outlook ist der Zeitplan nicht der einzige Treiber, der die Ausführung steuert. Die Zeitzone bestimmt nur die anfängliche Startzeit. Nachfolgende Ausführungen richten sich nach dem Wiederholungszeitplan, der letzten Triggerausführung und anderen Faktoren, die zu einer Verschiebung der Ausführungszeiten oder zu unerwartetem Verhalten führen können. Beispiele:

  • Der Trigger greift auf einen Server mit weiteren Daten zu, für die der Trigger sofort einen Abruf startet.
  • Alle Fehler oder Wiederholungsversuche des Triggers.
  • Wartezeit bei Speicheraufrufen.
  • Nichteinhaltung des angegebenen Zeitplans zu Beginn und Ende der Sommerzeit.
  • Andere Faktoren, die sich auf den Zeitpunkt der nächsten Ausführung auswirken können.

Weitere Informationen finden Sie in der folgenden Dokumentation:

Problembehandlung bei Wiederholungsproblemen

Um sicherzustellen, dass Ihr Workflow zur angegebenen Startzeit ausgeführt wird und keine Wiederholung verpasst – insbesondere wenn die Häufigkeit im Bereich von Tagen oder länger liegt – versuchen Sie die folgenden Lösungen:

  • Wenn die Sommerzeit beginnt, passen Sie die Wiederholung manuell an, damit Ihr Workflow weiterhin zur erwarteten Zeit läuft. Andernfalls verschiebt sich die Startzeit um eine Stunde nach vorn, wenn die Sommerzeit beginnt, und eine Stunde nach hinten, wenn die Sommerzeit endet. Weitere Informationen und Beispiele finden Sie unter Wiederholung für Sommerzeit und Normalzeit.

  • Wenn Sie einen Wiederholungstrigger verwenden, geben Sie eine Zeitzone, ein Startdatum und eine Startzeit an. Konfigurieren Sie die spezifischen Zeiten, um nachfolgende Wiederholungen auszuführen, indem Sie dazu die Eigenschaften namens Zu diesen Stunden und Zu diesen Minuten, die nur für die Häufigkeiten Tag und Woche verfügbar sind. Einige Zeitfenster können bei einer Zeitverschiebung dennoch weiterhin Probleme verursachen.

  • Erwägen Sie die Verwendung eines gleitendes Fenster-Triggers anstelle eines Wiederholungstriggers, um verpasste Wiederholungen zu vermeiden.

Benutzerdefinierte Connectors und APIs

Bei verbrauchsbasierten Logik-Apps, die in einer mehrinstanzenfähigen Azure Logic Apps-Instanz ausgeführt werden, können Sie Swagger- oder SOAP-basierte APIs aufrufen, die nicht als vorkonfigurierte 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:

Bei Standard-Logik-Apps, die in einer Azure Logic Apps-Instanz mit einem einzigen Mandanten ausgeführt werden, können Sie benutzerdefinierte integrierte Connectors auf Dienstanbieterbasis erstellen, die nativ ausgeführt werden und für jede Standard-Logik-App verfügbar sind. Weitere Informationen finden Sie in der folgenden Dokumentation:

ISE und Konnektoren

Für Workflows, die Direktzugriff auf Ressourcen in einem virtuellen Azure-Netzwerk benötigen, können Sie eine dedizierte Integrationsdienstumgebung (ISE) erstellen, in der Sie Ihren Workflow auf dedizierten Ressourcen erstellen, bereitstellen und ausführen können. Weitere Informationen zum Erstellen von ISEs finden Sie unter Verbinden mit Azure Virtual Networks über Azure Logic Apps.

Benutzerdefinierte Connectors, die in einer ISE erstellt wurden, funktionieren nicht mit dem lokalen Datengateway. Diese Connectors können jedoch direkt auf lokale Datenquellen zugreifen, die mit dem virtuellen Azure-Netzwerk verbunden sind, das die ISE hostet. Deshalb benötigen Logik-Apps in einer ISE sehr wahrscheinlich das Datengateway nicht, wenn sie mit diesen Ressourcen kommunizieren. Wenn Sie benutzerdefinierte Konnektoren haben, die Sie außerhalb einer ISE erstellt haben und die das lokale Datengateway benötigen, können Logikanwendungen in einer ISE diese Konnektoren verwenden.

Wenn Sie im Workflow-Designer die integrierten oder verwalteten Connectors durchsuchen, die Sie für Logik-Apps in einer ISE verwenden möchten, sehen Sie für integrierte Connectors die Bezeichnung CORE, während für verwaltete Connectors, die speziell für die Verwendung mit einer ISE konzipiert sind, die Bezeichnung ISE angezeigt wird.

CORE-Beispielconnector

CORE

Integrierte Connectors mit dieser Bezeichnung werden in derselben ISE wie Ihre Logik-Apps ausgeführt.

Beispiel für einen ISE-Connector

ISE

Verwaltete Connectors mit dieser Bezeichnung werden in derselben ISE wie Ihre Logik-Apps ausgeführt.

Wenn Sie ein lokales System haben, das mit einem virtuellen Azure-Netzwerk verbunden ist, ermöglicht eine ISE Ihren Workflows den Direktzugriff auf dieses System ohne das lokale Datengateway. Stattdessen können Sie entweder, falls verfügbar, den ISE-Connector dieses Systems verwenden, eine HTTP-Aktion oder einen benutzerdefinierten Connector.

Für lokale Systeme, die keine ISE-Connectors aufweisen, verwenden Sie das lokale Datengateway. Informationen zu verfügbaren ISE-Connectors finden Sie unter ISE-Connectors.

Beispiel für einen Nicht-ISE-Connector

Keine Bezeichnung

Alle anderen Connectors ohne Bezeichnung, die Sie weiterhin verwenden können, werden im globalen, mehrinstanzenfähigen Logic Apps-Dienst ausgeführt.

Bekannte Probleme

Im Folgenden werden bekannte Probleme bei Logic Apps Connectors behandelt.

Fehlermeldung BESCHREIBUNG Lösung
Error: BadGateway. Client request id: '{GUID}' Dieser Fehler tritt beim Aktualisieren der Tags in einer Logik-App auf, bei der mindestens eine Verbindung die OAuth-Authentifizierung mit Azure Active Directory (Azure AD) nicht unterstützt (z. B. SFTP und SQL), sodass diese Verbindungen unterbrochen werden. Um dieses Verhalten zu vermeiden, sollten Sie diese Tags nicht aktualisieren.

Nächste Schritte