Udostępnij za pośrednictwem

Łą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, 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, takiego jak usługa Office 365 lub Salesforce, która pomaga w rozmowie podstawowej usługi z usługą Azure Logic Apps. Łączniki zarządzane 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 utworzone 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żesz wywołać interfejsy 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 standardowych przepływów pracy aplikacji logiki. Każdy typ aplikacji logiki jest obsługiwany przez inne środowisko uruchomieniowe usługi Azure Logic Apps, odpowiednio hostowane w wielodostępnej platformie Azure 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 na temat tworzenia łączników niestandardowych dla aplikacji logiki Zużycie, w tym kompletnych samouczków podstawowych i zaawansowanych. 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 usługi 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.

Gdy oficjalnie wydano usługę Azure Logic Apps z jedną dzierżawą, nowe wbudowane łączniki obejmowały usługę Azure Blob Storage, usługę Azure Event Hubs, usługę Azure Service Bus i program 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 usługi 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 usługi Azure Functions.

  • Jest implementowany bezpośrednio jako zadanie w środowisku uruchomieniowym usługi Azure Logic Apps, takim jak harmonogram, 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 usługi 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 pakietów, rejestrowania i instalowania własnych wbudowanych łączników jako rozszerzeń usługi 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ą uwidacznianie wyzwalacza lub akcji usługi Azure Functions 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 usłudze Azure Functions:

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

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

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 dla 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 usłudze Azure Functions, metoda GetBindingConnectionInformation() jest używana przez środowisko uruchomieniowe w usłudze Azure Logic Apps w celu dostarczenia wymaganych informacji o parametrach połączenia do powiązania wyzwalacza usługi Azure Functions.

    • Jeśli łącznik zawiera akcje, metoda InvokeOperation() jest używana przez środowisko uruchomieniowe do wywoływania 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 funkcje wyzwalacza obsługują dodawanie lub uwidacznianie wyzwalacza lub akcji usługi Azure Functions jako wyzwalacza dostawcy usług w niestandardowym wbudowanym łączniku. Aby użyć typu wyzwalacza opartego na usłudze Azure Functions i tego samego powiązania usługi 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 usługi Azure Functions.

  • Metoda GetFunctionTriggerType() jest wymagana do zwrócenia ciągu, który jest taki sam jak parametr typu w powiązaniu wyzwalacza usługi 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ć w łączniku. Aby zapoznać się z kompletnym przykładem, zapoznaj się z artykułem Przykładowe CosmosDbServiceOperationProvider.cs i Tworzenie niestandardowych wbudowanych łączników dla aplikacji logiki w warstwie Standardowa w usłudze Azure Logic Apps z jedną dzierżawą.

Ważne

Jeśli masz poufne informacje, takie jak parametry połączenia zawierające nazwy użytkowników i hasła, upewnij się, że jest dostępny najbezpieczniejszy przepływ uwierzytelniania. Na przykład firma Microsoft zaleca uwierzytelnienie dostępu do zasobów platformy Azure przy użyciu tożsamości zarządzanej, gdy jest dostępna pomoc techniczna, i przypisanie roli, która ma najmniej wymagane uprawnienia.

Jeśli ta funkcja jest niedostępna, upewnij się, że zabezpieczasz parametry połączenia za pomocą innych miar, takich jak usługa Azure Key Vault, której można używać z ustawieniami aplikacji. Następnie można bezpośrednio odwoływać się do bezpiecznych ciągów, takich jak parametry połączenia i klucze. Podobnie jak w przypadku szablonów usługi ARM, gdzie można zdefiniować zmienne środowiskowe w czasie wdrażania, można zdefiniować ustawienia aplikacji w definicji przepływu pracy aplikacji logiki. Następnie można przechwytywać dynamicznie generowane wartości infrastruktury, takie jak punkty końcowe połączenia, parametry magazynu i inne. Aby uzyskać więcej informacji, zobacz Typy aplikacji dla Platforma tożsamości Microsoft.

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, zapoznaj się z przykładowym 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, zapoznaj się z przykładowym CosmosDbServiceOperationProvider.cs.

GetBindingConnectionInformation()

Jeśli chcesz użyć typu wyzwalacza opartego na usłudze Azure Functions, ta metoda udostępnia wymagane informacje o parametrach połączenia do powiązania wyzwalacza usługi 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, zapoznaj się z przykładowym 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, zapoznaj się z przykładowym CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerType()

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

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

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

Aby uzyskać więcej informacji, zapoznaj się z przykładowym 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: