Łączniki niestandardowe w usłudze Azure Logic Apps

  • Artykuł

Dotyczy: Azure Logic Apps (Zużycie + Standardowa)

Bez pisania kodu możesz szybko tworzyć zautomatyzowane przepływy pracy integracji podczas korzystania ze wstępnie utworzonych operacji łącznika w usłudze Azure Logic Apps. Łącznik ułatwia przepływom pracy łączenie i uzyskiwanie dostępu do danych, zdarzeń i akcji w innych aplikacjach, usługach, systemach, protokołach i platformach. Każdy łącznik oferuje operacje jako wyzwalacze, akcje lub oba te elementy, które można dodać do przepływów pracy. Korzystając z tych operacji, rozszerzasz możliwości aplikacji w chmurze i aplikacji lokalnych, aby pracować z nowymi i istniejącymi danymi.

Łączniki w usłudze Azure Logic Apps są wbudowane lub zarządzane. Wbudowany łącznik działa natywnie w środowisku uruchomieniowym usługi Azure Logic Apps, co oznacza, że są one hostowane w tym samym procesie co środowisko uruchomieniowe i zapewniają większą przepływność, małe opóźnienia i łączność lokalną. Łącznik zarządzany to serwer proxy lub otoka interfejsu API, taka jak Office 365 lub Salesforce, która pomaga w komunikacji podstawowej usługi z usługą Azure Logic Apps. Zarządzane łączniki są obsługiwane przez infrastrukturę łączników na platformie Azure i są wdrażane, hostowane, uruchamiane i zarządzane przez firmę Microsoft. Możesz wybrać spośród setek zarządzanych łączników do użycia z przepływami pracy w usłudze Azure Logic Apps.

Jeśli używasz operacji łącznika po raz pierwszy w przepływie pracy, niektóre łączniki nie wymagają najpierw utworzenia połączenia, ale wiele innych łączników wymaga tego kroku. Każde tworzone połączenie jest w rzeczywistości oddzielnym zasobem platformy Azure, który zapewnia dostęp do docelowej aplikacji, usługi, systemu, protokołu lub platformy.

Czasami jednak może być konieczne wywołanie interfejsów API REST, które nie są dostępne jako wstępnie utworzone łączniki. Aby obsługiwać bardziej dostosowane scenariusze, możesz utworzyć własne łączniki niestandardowe , aby oferować wyzwalacze i akcje, które nie są dostępne jako wstępnie utworzone operacje.

Ten artykuł zawiera omówienie łączników niestandardowych dla przepływów pracy aplikacji logiki zużycie i przepływów pracy standardowej aplikacji logiki. Każdy typ aplikacji logiki jest obsługiwany przez inne środowisko uruchomieniowe usługi Azure Logic Apps, odpowiednio hostowane na platformie Azure z wieloma dzierżawami i na platformie Azure z jedną dzierżawą. Aby uzyskać więcej informacji na temat łączników w usłudze Azure Logic Apps, zapoznaj się z następującą dokumentacją:

Użycie aplikacji logiki

W wielodostępnej usłudze Azure Logic Apps można tworzyć łączniki niestandardowe na podstawie interfejsów API opartych na strukturze Swagger lub SOAP do określonych limitów do użycia w przepływach pracy aplikacji logiki Zużycie. Dokumentacja łączników zawiera więcej informacji o sposobie tworzenia łączników niestandardowych dla aplikacji logiki Zużycie, w tym kompletnych podstawowych i zaawansowanych samouczków. Poniższa lista zawiera również bezpośrednie linki do informacji o łącznikach niestandardowych dla aplikacji logiki Zużycie:

Standardowe aplikacje logiki

W usłudze Azure Logic Apps z jedną dzierżawą przeprojektowane środowisko uruchomieniowe usługi Azure Logic Apps obsługuje standardowe przepływy pracy aplikacji logiki. To środowisko uruchomieniowe różni się od wielodostępnego środowiska uruchomieniowego usługi Azure Logic Apps, które obsługuje przepływy pracy aplikacji logiki Zużycie. Środowisko uruchomieniowe z jedną dzierżawą korzysta z modelu rozszerzalności Azure Functions, który zapewnia kluczową możliwość tworzenia własnych wbudowanych łączników dla każdego, kto ma być używany w przepływach pracy w warstwie Standardowa. W większości przypadków wbudowana wersja zapewnia lepszą wydajność, możliwości, ceny itd.

W przypadku oficjalnego wydania usługi Azure Logic Apps z jedną dzierżawą nowe wbudowane łączniki obejmują Azure Blob Storage, Azure Event Hubs, Azure Service Bus i SQL Server. Wraz z upływem czasu ta lista wbudowanych łączników nadal rośnie. Jeśli jednak potrzebujesz łączników, które nie są dostępne w standardowych przepływach pracy aplikacji logiki, możesz utworzyć własne wbudowane łączniki przy użyciu tego samego modelu rozszerzalności, który jest używany przez wbudowane łączniki dostawcy usług w standardowych przepływach pracy.

Wbudowane łączniki oparte na dostawcy usług

W usłudze Azure Logic Apps z jedną dzierżawą wbudowany łącznik z określonymi atrybutami jest nieformalnie znany jako dostawca usług. Na przykład te łączniki są oparte na modelu rozszerzalności Azure Functions, który zapewnia możliwość tworzenia własnych niestandardowych wbudowanych łączników do użycia w przepływach pracy aplikacji logiki w warstwie Standardowa.

Z kolei wbudowane łączniki dostawcy usług mają następujące atrybuty:

  • Nie jest oparta na modelu rozszerzalności Azure Functions.

  • Jest implementowany bezpośrednio jako zadanie w środowisku uruchomieniowym usługi Azure Logic Apps, takim jak planowanie, http, żądanie i operacje XML.

Obecnie nie można utworzyć wbudowanego łącznika dostawcy usług lub nowego typu zadania uruchamianego bezpośrednio w środowisku uruchomieniowym usługi Azure Logic Apps. Można jednak utworzyć własne wbudowane łączniki przy użyciu infrastruktury dostawcy usług.

Poniższa sekcja zawiera więcej informacji na temat sposobu działania modelu rozszerzalności dla niestandardowych wbudowanych łączników.

Wbudowany model rozszerzalności łącznika

Na podstawie modelu rozszerzalności Azure Functions wbudowany model rozszerzalności łącznika w usłudze Azure Logic Apps z jedną dzierżawą ma infrastrukturę dostawcy usług, której można użyć do tworzenia, tworzenia, tworzenia, rejestrowania i instalowania własnych wbudowanych łączników jako rozszerzeń Azure Functions, których każdy może używać w swoich standardowych przepływach pracy. Ten model obejmuje niestandardowe wbudowane funkcje wyzwalacza, które obsługują udostępnianie wyzwalacza Azure Functions lub akcji jako wyzwalacza dostawcy usług w niestandardowym wbudowanym łączniku.

Na poniższym diagramie przedstawiono implementacje metod oczekiwane przez projektanta i środowisko uruchomieniowe usługi Azure Logic Apps dla niestandardowego wbudowanego łącznika z wyzwalaczem opartym na Azure Functions:

Diagram koncepcyjny przedstawiający infrastrukturę dostawcy usług opartą na Azure Functions.

Poniższe sekcje zawierają więcej informacji na temat interfejsów, które należy zaimplementować przez łącznik.

IServiceOperationsProvider

Ten interfejs zawiera metody, które zapewniają manifest operacji dla niestandardowego wbudowanego łącznika.

  • Manifest operacji

    Manifest operacji zawiera metadane dotyczące wdrożonych operacji w niestandardowym wbudowanym łączniku. Projektant usługi Azure Logic Apps używa głównie tych metadanych do obsługi środowisk tworzenia i monitorowania operacji łącznika. Na przykład projektant używa metadanych operacji do zrozumienia parametrów wejściowych wymaganych przez określoną operację i ułatwienia generowania tokenów właściwości danych wyjściowych na podstawie schematu dla danych wyjściowych operacji.

    Projektant wymaga metod GetService() i GetOperations() oraz używa ich do wykonywania zapytań dotyczących operacji zapewnianych przez łącznik i wyświetlanych na powierzchni projektanta. Metoda GetService() określa również parametry wejściowe połączenia, które są wymagane przez projektanta.

    Aby uzyskać więcej informacji na temat tych metod i ich implementacji, zapoznaj się z sekcją Metody implementacji w dalszej części tego artykułu.

  • Wywołania operacji

    Wywołania operacji to implementacje metod używane podczas wykonywania przepływu pracy przez środowisko uruchomieniowe usługi Azure Logic Apps w celu wywołania określonych operacji w definicji przepływu pracy.

    • Jeśli wyzwalacz jest typem wyzwalacza opartego na Azure Functions, metoda GetBindingConnectionInformation() jest używana przez środowisko uruchomieniowe w usłudze Azure Logic Apps w celu udostępnienia wymaganych informacji o parametrach połączenia do powiązania wyzwalacza Azure Functions.

    • Jeśli łącznik zawiera akcje, metoda InvokeOperation() jest używana przez środowisko uruchomieniowe do wywołania każdej akcji w łączniku, która jest uruchamiana podczas wykonywania przepływu pracy. W przeciwnym razie nie trzeba implementować tej metody.

Aby uzyskać więcej informacji na temat tych metod i ich implementacji, zapoznaj się z sekcją Metody implementacji w dalszej części tego artykułu.

IServiceOperationsTriggerProvider

Niestandardowe wbudowane możliwości wyzwalacza obsługują dodawanie lub uwidacznianie wyzwalacza lub akcji Azure Functions jako wyzwalacza dostawcy usług w niestandardowym wbudowanym łączniku. Aby użyć typu wyzwalacza opartego na Azure Functions i tego samego powiązania Azure Functions co wyzwalacz łącznika zarządzanego platformy Azure, zaimplementuj następujące metody, aby zapewnić informacje o połączeniu i powiązania wyzwalacza zgodnie z wymaganiami Azure Functions.

  • Metoda GetFunctionTriggerType() jest wymagana do zwrócenia ciągu, który jest taki sam jak parametr typu w powiązaniu wyzwalacza Azure Functions.

  • GetFunctionTriggerDefinition() ma domyślną implementację, więc nie trzeba jawnie implementować tej metody. Jeśli jednak chcesz zaktualizować domyślne zachowanie wyzwalacza, takie jak podanie dodatkowych parametrów, których projektant nie uwidacznia, możesz zaimplementować tę metodę i zastąpić domyślne zachowanie.

Metody implementowania

Poniższe sekcje zawierają więcej informacji na temat metod, które należy zaimplementować przez łącznik. Aby uzyskać kompletny przykład, zapoznaj się z przykładami CosmosDbServiceOperationProvider.cs i Tworzenie niestandardowych wbudowanych łączników dla standardowych aplikacji logiki w usłudze Azure Logic Apps z jedną dzierżawą.

GetService()

Projektant wymaga, aby ta metoda pobierała metadane wysokiego poziomu dla usługi, w tym opis usługi, parametry wejściowe połączenia, możliwości, kolor marki, adres URL ikony itd.

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

Aby uzyskać więcej informacji, zobacz Sample CosmosDbServiceOperationProvider.cs.

GetOperations()

Projektant wymaga tej metody, aby uzyskać operacje zaimplementowane przez usługę. Lista operacji jest oparta na schemacie struktury Swagger. Projektant używa również metadanych operacji do zrozumienia parametrów wejściowych dla określonych operacji i wygenerowania danych wyjściowych jako tokenów właściwości na podstawie schematu danych wyjściowych dla operacji.

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

Aby uzyskać więcej informacji, zobacz Sample CosmosDbServiceOperationProvider.cs.

GetBindingConnectionInformation()

Jeśli chcesz użyć typu wyzwalacza opartego na Azure Functions, ta metoda udostępnia wymagane informacje o parametrach połączenia do powiązania wyzwalacza Azure Functions.

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

Aby uzyskać więcej informacji, zobacz Sample CosmosDbServiceOperationProvider.cs.

InvokeOperation()

Jeśli niestandardowy wbudowany łącznik ma tylko wyzwalacz, nie musisz implementować tej metody. Jeśli jednak łącznik ma akcje do zaimplementowania, musisz zaimplementować metodę InvokeOperation(), która jest wywoływana dla każdej akcji w łączniku, która jest uruchamiana podczas wykonywania przepływu pracy. Możesz użyć dowolnego klienta, takiego jak FTPClient, HTTPClient itd., zgodnie z wymaganiami akcji łącznika. W tym przykładzie użyto obiektu HTTPClient.

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);
}

Aby uzyskać więcej informacji, zobacz Sample CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerType()

Aby użyć wyzwalacza opartego na Azure Functions jako wyzwalacza w łączniku, należy zwrócić ciąg, który jest taki sam jak parametr typu w powiązaniu wyzwalacza Azure Functions.

Poniższy przykład zwraca ciąg wbudowanego wyzwalacza "type": "cosmosDBTrigger"usługi Azure Cosmos DB:

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

Aby uzyskać więcej informacji, zobacz Sample CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerDefinition()

Ta metoda ma domyślną implementację, więc nie trzeba jawnie implementować tej metody. Jeśli jednak chcesz zaktualizować domyślne zachowanie wyzwalacza, takie jak podanie dodatkowych parametrów, których projektant nie uwidacznia, możesz zaimplementować tę metodę i zastąpić domyślne zachowanie.

Następne kroki

Gdy wszystko będzie gotowe do rozpoczęcia kroków implementacji, przejdź do następującego artykułu: