Benutzerdefinierte Connectors in Azure Logic Apps

  • Artikel

Gilt für: Azure Logic Apps (Verbrauch + Standard)

Durch die Verwendung der vordefinierten Connectorvorgänge in Azure Logic Apps können Sie ohne das Schreiben von Code schnell automatisierte Integrationsworkflows erstellen. Ein Connector bietet Unterstützung für Ihre Workflows beim Verbinden von und Zugreifen auf Daten, Ereignisse und Aktionen in anderen Apps, Diensten, Systemen, Protokollen und auf anderen Plattformen. Jeder Connector bietet Vorgänge als Trigger, Aktionen oder beide Varianten, die Sie Ihren Workflows hinzufügen können. Mithilfe dieser Vorgänge erweitern Sie die Funktionen für Ihre Cloud-Apps und lokalen Apps zum Arbeiten mit neuen und vorhandenen Daten.

Connectors in Azure Logic Apps sind entweder integriert oder verwaltet. Ein integrierter Connector wird nativ über die Azure Logic Apps-Runtime ausgeführt, was bedeutet, dass er im gleichen Prozess wie die Runtime gehostet wird und höheren Durchsatz, niedrige Latenz und lokale Konnektivität bietet. Ein verwalteter Connector ist ein Proxy oder ein Wrapper um eine API (z. B. Office 365 oder Salesforce), der den zugrunde liegenden Dienst bei der Kommunikation mit Azure Logic Apps unterstützt. Verwaltete Connectors werden von der Connectorinfrastruktur in Azure unterstützt und von Microsoft bereitgestellt, gehostet, ausgeführt und verwaltet. Sie können aus Hunderten von verwalteten Connectors auswählen, die Sie mit Ihren Workflows in Azure Logic Apps verwenden können.

Wenn Sie einen Connectorvorgang zum ersten Mal in einem Workflow verwenden, erfordern einige Connectors zunächst keine Verbindung, aber bei vielen anderen Connectors ist dieser Schritt notwendig. Jede von Ihnen erstellte Verbindung ist tatsächlich eine separate Azure-Ressource, die Zugriff auf die Ziel-App, den Dienst, das System, das Protokoll oder die Plattform bietet.

In einigen Fällen müssen Sie jedoch REST-APIs aufrufen, die nicht als vordefinierte Connectors verfügbar sind. Um angepasste Szenarios zu unterstützen, können Sie eigene benutzerdefinierten Connectors erstellen, um Trigger und Aktionen bereitzustellen, die nicht als vordefinierte Vorgänge verfügbar sind.

In diesem Artikel finden Sie eine Übersicht über benutzerdefinierte Connectors für Workflows für verbrauchsbasierte Logik-Apps und Standard-Logik-Apps. Jeder Logik-App-Typ wird von einer anderen Azure Logic Apps-Runtime unterstützt, die jeweils in Azure-Umgebungen mit mehreren oder einem einzelnen Mandanten gehostet wird. Weitere Informationen zu Connectors in Azure Logic Apps finden Sie in der folgenden Dokumentation:

Verbrauchsbasierte Logik-Apps

In Azure Logic Apps-Instanzen mit mehreren Mandanten können Sie benutzerdefinierte Connectors über Swagger- oder SOAP-basierte APIs bis zu bestimmten Grenzwerten für die Verwendung in verbrauchsbasierten Logik-App-Workflows erstellen. Die Dokumentation zu Connectors bietet weitere Informationen zum Erstellen benutzerdefinierter Connectors für verbrauchsbasierte Logik-Apps (einschließlich der vollständigen grundlegenden und erweiterten Tutorials). Die folgende Liste enthält auch direkte Links zu Informationen zu benutzerdefinierten Connectors für verbrauchsbasierte Logik-Apps:

Standard-Logik-Apps

In Azure Logic Apps-Instanzen mit einem einzelnen Mandanten bietet die überarbeitete Azure Logic Apps-Runtime Unterstützung für Standard-Logik-App-Workflows. Diese Runtime unterscheidet sich von der Azure Logic Apps-Runtime für mehrere Mandanten, die die verbrauchsbasierten Logik-App-Workflows unterstützt. Die Runtime für einzelne Mandanten verwendet das Azure Functions-Erweiterbarkeitsmodell, das eine wichtige Funktion zum Erstellen Ihrer eigenen und von allen verwendbaren integrierten Connectors für Standard-Workflows bietet. In den meisten Fällen bietet die integrierte Version eine höhere Leistung, bessere Funktionen, niedrigere Preise usw.

Wenn eine Azure Logic Apps-Instanz mit einem einzelnen Mandanten offiziell veröffentlicht wird, sind neue integrierte Connectors für Azure Blob Storage, Azure Event Hubs, Azure Service Bus und SQL Server enthalten. Im Laufe der Zeit wird diese Liste der integrierten Connectors erweitert. Wenn Sie jedoch Connectors benötigen, die in Standard-Logik-App-Workflows nicht verfügbar sind, können Sie mithilfe des von dienstanbieterbasierten integrierten Connectors in Standard-Workflows verwendeten Erweiterbarkeitsmodells eigene integrierte Connectors erstellen.

Integrierte Connectors auf Dienstanbieterbasis

In Azure Logic Apps-Instanzen mit einem einzelnen Mandanten wird ein integrierter Connector mit bestimmten Attributen informell als Dienstanbieter bezeichnet. Diese Connectors basieren beispielsweise auf dem Azure Functions-Erweiterbarkeitsmodell, das Ihnen die Möglichkeit bietet, eigene benutzerdefinierte, integrierte Connectors für die Verwendung in Logik-App-Standardworkflows zu erstellen.

Im Gegensatz dazu weisen nicht dienstanbieterbasierte, integrierte Connectors die folgenden Attribute auf:

  • Basiert nicht auf dem Azure Functions-Erweiterbarkeitsmodell.

  • Wird direkt als Auftrag innerhalb der Azure Logic Apps-Runtime implementiert (z. B. Zeitplan- und Anforderungsvorgänge sowie HTTP- und XML-Vorgänge).

Derzeit ist keine Funktion verfügbar, um einen integrierten Connector, der kein Dienstanbieter ist, oder einen neuen Auftragstyp zu erstellen, der direkt über die Azure Logic Apps-Runtime ausgeführt wird. Sie können jedoch mithilfe der Dienstanbieterinfrastruktur Ihre eigenen integrierten Connectors erstellen.

Im folgenden Abschnitt finden Sie weitere Informationen dazu, wie das Erweiterbarkeitsmodell für benutzerdefinierte integrierte Connectors funktioniert.

Erweiterbarkeitsmodell für integrierte Connectors

Basierend auf dem Azure Functions-Erweiterbarkeitsmodell bietet das Erweiterbarkeitsmodell für integrierte Connectors in Azure Logic Apps-Instanzen mit einem einzelnen Mandanten eine Dienstanbieterinfrastruktur, die Sie zum Erstellen, Packen, Registrieren und Installieren Ihrer eigenen integrierten Connectors als Azure Functions-Erweiterungen verwenden können, die von allen in Standard-Workflows genutzt werden können. Dieses Modell enthält benutzerdefinierte integrierte Triggerfunktionen, die die Bereitstellung von Azure Functions-Triggern oder -Aktionen als Dienstanbietertrigger in Ihrem benutzerdefinierten integrierten Connector unterstützen.

Das folgende Diagramm veranschaulicht die Methodenimplementierungen, die der Designer und die Runtime von Azure Logic Apps für einen benutzerdefinierten integrierten Connector mit einem Azure Functions-basierten Trigger erwarten:

Konzeptionelles Diagramm: Azure Functions-basierte Dienstanbieterinfrastruktur

In den folgenden Abschnitten finden Sie weitere Informationen zu den Schnittstellen, die Ihr Connector implementieren muss.

IServiceOperationsProvider

Diese Schnittstelle enthält die Methoden, die das Vorgangsmanifest für Ihren benutzerdefinierten integrierten Connector bereitstellen.

  • Vorgangsmanifest

    Das Vorgangsmanifest enthält Metadaten zu den implementierten Vorgängen in Ihrem benutzerdefinierten integrierten Connector. Der Azure Logic Apps-Designer verwendet in erster Linie diese Metadaten, um die Erstellungs- und Überwachungsfunktionen für die Vorgänge Ihres Connector zu steuern. Der Designer verwendet beispielsweise Vorgangsmetadaten, um die von einem bestimmten Vorgang benötigten Eingabeparameter zu verstehen und das Generieren der Eigenschaftstoken der Ausgabe basierend auf dem Schema für die Ausgabe des Vorgangs zu vereinfachen.

    Der Designer erfordert und verwendet die Methoden GetService() und GetOperations() zum Abfragen der Vorgänge, die Ihr Connector bereitstellt und auf der Designer-Oberfläche anzeigt. Die GetService()-Methode gibt auch die vom Designer benötigten Eingabeparameter der Verbindung an.

    Weitere Informationen zu diesen Methoden und deren Implementierung finden Sie weiter unten im Abschnitt Zu implementierende Methoden dieses Artikels.

  • Aufrufe von Vorgängen

    Aufrufe von Vorgängen sind die Methodenimplementierungen, die während der Workflowausführung von der Azure Logic Apps-Runtime verwendet werden, um die angegebenen Vorgänge in der Workflowdefinition aufzurufen.

    • Wenn es sich bei Ihrem Trigger um einen auf Azure Functions basierenden Triggertyp handelt, wird die GetBindingConnectionInformation()-Methode von der Runtime in Azure Logic Apps verwendet, um die erforderlichen Verbindungsparameterinformationen für die Azure Functions-Triggerbindung bereitzustellen.

    • Wenn Ihr Connector Aktionen enthält, wird die InvokeOperation()-Methode von der Runtime verwendet, um jede Aktion in Ihrem Connector aufzurufen, die während der Workflowausführung ausgeführt wird. Andernfalls müssen Sie diese Methode nicht implementieren.

Weitere Informationen zu diesen Methoden und deren Implementierung finden Sie weiter unten im Abschnitt Zu implementierende Methoden dieses Artikels.

IServiceOperationsTriggerProvider

Benutzerdefinierte integrierte Triggerfunktionen unterstützen das Hinzufügen oder Bereitstellen von Azure Functions-Triggern oder -Aktionen als Dienstanbietertrigger in Ihrem benutzerdefinierten integrierten Connector. Implementieren Sie zur Verwendung des auf Azure Functions basierenden Triggertyps und der gleichen Azure Functions-Bindung wie der von Azure verwaltete Connectortrigger die folgenden Methoden, um die Verbindungsinformationen und Triggerbindungen wie von Azure Functions gefordert bereitzustellen.

  • Die GetFunctionTriggerType()-Methode ist erforderlich, um die Zeichenfolge zurückzugeben, die dem Parameter type in der Azure Functions-Triggerbindung entspricht.

  • GetFunctionTriggerDefinition() verfügt über eine Standardimplementierung, sodass Sie diese Methode nicht explizit implementieren müssen. Wenn Sie das Standardverhalten des Triggers jedoch aktualisieren möchten (etwa zusätzliche Parameter bereitstellen, die vom Designer nicht verfügbar gemacht werden), können Sie diese Methode implementieren und das Standardverhalten außer Kraft setzen.

Zu implementierende Methoden

In den folgenden Abschnitten finden Sie weitere Informationen zu den Methoden, die Ihr Connector implementieren muss. Das vollständige Beispiel finden Sie unter Beispiel „CosmosDbServiceOperationProvider.cs“ und Erstellen benutzerdefinierter integrierter Connectors für Standard-Logik-Apps in Azure Logic Apps-Instanzen mit einem einzelnen Mandanten.

GetService()

Der Designer erfordert diese Methode, um die allgemeinen Metadaten auf für Ihren Dienst abzurufen (einschließlich der Dienstbeschreibung, Verbindungseingabeparameter, Funktionen, Markenfarbe, Symbol-URL usw.).

public ServiceOperationApi GetService()
{
   return this.{custom-service-name-apis}.ServiceOperationServiceApi();
}

Weitere Informationen finden Sie unter Beispiel „CosmosDbServiceOperationProvider.cs“.

GetOperations()

Der Designer erfordert diese Methode, um die von Ihrem Dienst implementierten Vorgänge abzurufen. Die Liste der Vorgänge basiert auf dem Swagger-Schema. Der Designer verwendet die Vorgangsmetadaten außerdem, um die Eingabeparameter für bestimmte Vorgänge zu verstehen und die Ausgaben als Eigenschaftstoken basierend auf dem Schema der Ausgabe für einen Vorgang zu generieren.

public IEnumerable<ServiceOperation> GetOperations(bool expandManifest)
{
   return expandManifest ? serviceOperationsList : GetApiOperations();
}

Weitere Informationen finden Sie unter Beispiel „CosmosDbServiceOperationProvider.cs“.

GetBindingConnectionInformation()

Wenn Sie den auf Azure Functions basierenden Triggertyp verwenden möchten, stellt diese Methode die erforderlichen Verbindungsparameterinformationen für die Azure Functions-Triggerbindung bereit.

public string GetBindingConnectionInformation(string operationId, InsensitiveDictionary<JToken> connectionParameters)
{
   return ServiceOperationsProviderUtilities
      .GetRequiredParameterValue(
         serviceId: ServiceId,
         operationId: operationID,
         parameterName: "connectionString",
         parameters: connectionParameters)?
      .ToValue<string>();
}

Weitere Informationen finden Sie unter Beispiel „CosmosDbServiceOperationProvider.cs“.

InvokeOperation()

Wenn der benutzerdefinierte integrierte Connector nur über einen Trigger verfügt, müssen Sie diese Methode nicht implementieren. Wenn es für Ihren Connector jedoch zu implementierende Aktionen gibt, müssen Sie die InvokeOperation()-Methode implementieren, die für jede Aktion in Ihrem Connector aufgerufen wird, die während der Workflowausführung ausgeführt wird. Sie können gemäß den Anforderungen der Aktionen Ihres Connectors einen beliebigen Client verwenden (z. B. FTPClient, HTTPClient usw.). In diesem Beispiel wird HTTPClient verwendet.

public Task<ServiceOperationResponse> InvokeOperation(string operationId, InsensitiveDictionary<JToken> connectionParameters, ServiceOperationRequest serviceOperationRequest)
{
   using (var client = new HttpClient())
   {
      response = client.SendAsync(httpRequestMessage).ConfigureAwait(false).ToJObject();
   }
   return new ServiceOperationResponse(body: response);
}

Weitere Informationen finden Sie unter Beispiel „CosmosDbServiceOperationProvider.cs“.

GetFunctionTriggerType()

Um einen auf Azure Functions basierenden Trigger als Trigger in Ihrem Connector zu verwenden, müssen Sie die Zeichenfolge zurückgeben, die dem Parameter type in der Azure Functions-Triggerbindung entspricht.

Im folgenden Beispiel wird die Zeichenfolge für den vorkonfigurierten integrierten Azure Cosmos DB-Trigger zurückgegeben ("type": "cosmosDBTrigger"):

public string GetFunctionTriggerType()
{
   return "CosmosDBTrigger";
}

Weitere Informationen finden Sie unter Beispiel „CosmosDbServiceOperationProvider.cs“.

GetFunctionTriggerDefinition()

Diese Methode verfügt über eine Standardimplementierung, sodass Sie diese Methode nicht explizit implementieren müssen. Wenn Sie das Standardverhalten des Triggers jedoch aktualisieren möchten (etwa zusätzliche Parameter bereitstellen, die vom Designer nicht verfügbar gemacht werden), können Sie diese Methode implementieren und das Standardverhalten außer Kraft setzen.

Nächste Schritte

Wenn Sie bereit sind, die Implementierungsschritte auszuführen, fahren Sie mit dem folgenden Artikel fort: