Vlastní konektory v Azure Logic Apps
Platí pro: Azure Logic Apps (Consumption + Standard)
Bez psaní kódu můžete rychle vytvářet pracovní postupy automatizované integrace při použití předem připravených operací konektoru v Azure Logic Apps. Konektor pomáhá vašim pracovním postupům připojovat data, události a akce v jiných aplikacích, službách, systémech, protokolech a platformách a přistupovat k datům, událostem a akcím. Každý konektor nabízí operace jako triggery, akce nebo obojí, které můžete přidat do pracovních postupů. Pomocí těchto operací rozšiřujete možnosti cloudových aplikací a místních aplikací, aby fungovaly s novými a existujícími daty.
Konektory v Azure Logic Apps jsou integrované nebo spravované. Integrovaný konektor běží nativně v modulu runtime Azure Logic Apps, což znamená, že jsou hostované ve stejném procesu jako modul runtime a poskytují vyšší propustnost, nízkou latenci a místní připojení. Spravovaný konektor je proxy server nebo obálka kolem rozhraní API, jako je Office 365 nebo Salesforce, která pomáhá podkladové službě komunikovat s Azure Logic Apps. Spravované konektory využívají infrastrukturu konektorů v Azure a nasazují se, hostují, spouštějí a spravují Microsoft. Můžete si vybrat z více než 1 400 spravovaných konektorů , které se budou používat s pracovními postupy v Azure Logic Apps.
Při prvním použití operace konektoru v pracovním postupu některé konektory nevyžadují, abyste nejprve vytvořili připojení, ale mnoho dalších konektorů vyžaduje tento krok. Každé připojení, které vytvoříte, je ve skutečnosti samostatným prostředkem Azure, který poskytuje přístup k cílové aplikaci, službě, systému, protokolu nebo platformě.
Někdy ale můžete chtít volat rozhraní REST API, která nejsou k dispozici jako předem připravené konektory. Pokud chcete podporovat více přizpůsobené scénáře, můžete vytvořit vlastní konektory, které nabízejí triggery a akce, které nejsou k dispozici jako předem připravené operace.
Tento článek obsahuje přehled vlastních konektorů pro pracovní postupy aplikací logiky Consumption a standardních pracovních postupů aplikace logiky. Každý typ aplikace logiky využívá jiný modul runtime Azure Logic Apps hostovaný ve víceklientských Azure a Azure s jedním tenantem. Další informace o konektorech v Azure Logic Apps najdete v následující dokumentaci:
- Informace o konektorech v Azure Logic Apps
- Integrované konektory v Azure Logic Apps
- Spravované konektory v Azure Logic Apps
- Přehled konektorů
- Jednoklient a víceklient v Azure Logic Apps
Aplikace logiky Consumption
Ve víceklientské službě Azure Logic Apps můžete vytvářet vlastní konektory z rozhraní API založených na Swaggeru nebo SOAP až do konkrétních limitů pro použití v pracovních postupech aplikace logiky Consumption. Dokumentace ke konektorům poskytuje podrobnější informace o vytváření vlastních konektorů pro aplikace logiky Consumption, včetně kompletních základních a pokročilých kurzů. Následující seznam obsahuje také přímé odkazy na informace o vlastních konektorech pro aplikace logiky Consumption:
- Vytvoření konektoru Azure Logic Apps
- Vytvoření vlastního konektoru z definice OpenAPI
- Použití vlastního konektoru z aplikace logiky
- Sdílení vlastního konektoru v rámci organizace
- Odeslání konektoru Microsoftu k certifikaci
- Nejčastější dotazy k vlastnímu konektoru
Standardní aplikace logiky
V Azure Logic Apps s jedním tenantem využívá přepracovaný modul runtime Azure Logic Apps pracovní postupy standardních aplikací logiky. Tento modul runtime se liší od modulu runtime Azure Logic Apps s více tenanty, který využívá pracovní postupy aplikací logiky Consumption. Modul runtime s jedním tenantem používá model rozšiřitelnosti služby Azure Functions, který poskytuje klíčovou funkci pro vytvoření vlastních integrovaných konektorů pro každého, kdo bude používat v pracovních postupech Standard. Ve většině případů integrovaná verze poskytuje lepší výkon, možnosti, ceny atd.
Když služba Azure Logic Apps s jedním tenantem oficiálně vydala, byly součástí nových integrovaných konektorů Azure Blob Storage, Azure Event Hubs, Azure Service Bus a SQL Server. V průběhu času se tento seznam integrovaných konektorů stále rozšiřuje. Pokud ale potřebujete konektory, které nejsou dostupné v pracovních postupech standardní aplikace logiky, můžete vytvořit vlastní integrované konektory pomocí stejného modelu rozšiřitelnosti, který používají integrované konektory založené na poskytovateli služeb v pracovních postupech Standard.
Integrované konektory založené na poskytovateli služeb
V Azure Logic Apps s jedním tenantem se neformálně označuje integrovaný konektor s konkrétními atributy jako poskytovatel služeb. Tyto konektory jsou například založené na modelu rozšiřitelnosti služby Azure Functions, který umožňuje vytvářet vlastní integrované konektory pro použití v pracovních postupech standardní aplikace logiky.
Naproti tomu integrované konektory jiného poskytovatele služeb mají následující atributy:
Není založená na modelu rozšiřitelnosti služby Azure Functions.
Je přímo implementován jako úloha v rámci modulu runtime Azure Logic Apps, jako jsou například operace Schedule, HTTP, Request a XML.
V současné době není k dispozici žádná funkce pro vytvoření integrovaného konektoru poskytovatele služeb nebo nového typu úlohy, který běží přímo v modulu runtime Azure Logic Apps. Pomocí infrastruktury poskytovatele služeb ale můžete vytvořit vlastní integrované konektory.
Následující část obsahuje další informace o tom, jak model rozšiřitelnosti funguje pro vlastní integrované konektory.
Model rozšiřitelnosti integrovaných konektorů
Na základě modelu rozšiřitelnosti azure Functions má integrovaný model rozšiřitelnosti konektorů v Azure Logic Apps s jedním tenantem infrastrukturu poskytovatele služeb, kterou můžete použít k vytváření, balení, registraci a instalaci vlastních integrovaných konektorů jako rozšíření Azure Functions, která můžou všichni používat ve svých standardních pracovních postupech. Tento model zahrnuje vlastní integrované funkce triggeru, které podporují zveřejnění triggeru nebo akce Azure Functions jako trigger poskytovatele služeb ve vlastním integrovaném konektoru.
Následující diagram znázorňuje implementace metod, které návrhář a modul runtime Azure Logic Apps očekávají pro vlastní integrovaný konektor s triggerem založeným na Azure Functions:
V následujících částech najdete další informace o rozhraních, která váš konektor potřebuje implementovat.
IServiceOperationsProvider
Toto rozhraní zahrnuje metody, které poskytují manifest operací pro vlastní integrovaný konektor.
Manifest operací
Manifest operací obsahuje metadata o implementovaných operacích ve vlastním integrovaném konektoru. Návrhář Azure Logic Apps primárně používá tato metadata k řízení prostředí pro vytváření a monitorování operací vašeho konektoru. Návrhář například používá metadata operací k pochopení vstupních parametrů požadovaných konkrétní operací a k usnadnění generování tokenů vlastností výstupu na základě schématu pro výstupy operace.
Návrhář vyžaduje a používá metody GetService() a GetOperations() k dotazování operací, které váš konektor poskytuje a zobrazuje na ploše návrháře. Metoda GetService() také určuje vstupní parametry připojení vyžadované návrhářem.
Další informace o těchto metodách a jejich implementaci najdete v části Metody implementace dále v tomto článku.
Vyvolání operací
Vyvolání operací jsou implementace metody používané během provádění pracovního postupu modulem runtime Azure Logic Apps k volání zadaných operací v definici pracovního postupu.
Pokud je aktivační událost typu založená na Azure Functions, použije modul runtime v Azure Logic Apps metodu GetBindingConnectionInformation() k poskytnutí požadovaných parametrů připojení pro vazbu triggeru Azure Functions.
Pokud má váš konektor akce, metoda InvokeOperation() je používána modulem runtime k volání každé akce v konektoru, která se spouští během provádění pracovního postupu. Jinak nemusíte tuto metodu implementovat.
Další informace o těchto metodách a jejich implementaci najdete v části Metody implementace dále v tomto článku.
IServiceOperationsTriggerProvider
Vlastní integrované funkce triggerů podporují přidání nebo zveřejnění triggeru nebo akce Azure Functions jako triggeru poskytovatele služeb ve vlastním integrovaném konektoru. Pokud chcete použít typ triggeru založeného na Azure Functions a stejnou vazbu Azure Functions jako trigger spravovaného konektoru Azure, implementujte následující metody, které poskytují informace o připojení a vazby triggerů, jak to vyžaduje Služba Azure Functions.
Metoda GetFunctionTriggerType() je nutná k vrácení řetězce, který je stejný jako parametr typu ve vazbě triggeru Azure Functions.
GetFunctionTriggerDefinition () má výchozí implementaci, takže nemusíte explicitně implementovat tuto metodu. Pokud ale chcete aktualizovat výchozí chování triggeru, například poskytnout další parametry, které návrhář nezpřístupňuje, můžete tuto metodu implementovat a přepsat výchozí chování.
Metody implementace
Následující části obsahují další informace o metodách, které váš konektor potřebuje implementovat. Kompletní ukázku najdete v ukázce CosmosDbServiceOperationProvider.cs a vytvoření vlastních integrovaných konektorů pro standardní aplikace logiky v Azure Logic Apps s jedním tenantem.
Důležité
Pokud máte citlivé informace, například připojovací řetězec, které obsahují uživatelská jména a hesla, ujistěte se, že používáte nejbezpečnější dostupný tok ověřování. Microsoft například doporučuje ověřit přístup k prostředkům Azure pomocí spravované identity , pokud je k dispozici podpora, a přiřadit roli s nejnižším požadovaným oprávněním.
Pokud tato funkce není dostupná, nezapomeňte zabezpečit připojovací řetězec prostřednictvím jiných měr, jako je Azure Key Vault, které můžete použít s nastavením aplikace. Pak můžete přímo odkazovat na zabezpečené řetězce, jako jsou připojovací řetězec a klíče. Podobně jako šablony ARM, kde můžete definovat proměnné prostředí v době nasazení, můžete definovat nastavení aplikace v definici pracovního postupu aplikace logiky. Pak můžete zaznamenávat dynamicky generované hodnoty infrastruktury, jako jsou koncové body připojení, řetězce úložiště a další. Další informace najdete v tématu Typy aplikací pro platformu Microsoft Identity Platform.
GetService()
Návrhář vyžaduje, aby tato metoda získala metadata vysoké úrovně pro vaši službu, včetně popisu služby, vstupních parametrů připojení, možností, barvy značky, adresy URL ikony atd.
public ServiceOperationApi GetService()
{
return this.{custom-service-name-apis}.ServiceOperationServiceApi();
}
Další informace najdete v ukázkové CosmosDbServiceOperationProvider.cs.
GetOperations()
Návrhář vyžaduje, aby tato metoda získala operace implementované vaší službou. Seznam operací je založený na schématu Swaggeru. Návrhář používá také metadata operací k pochopení vstupních parametrů pro konkrétní operace a generování výstupů jako tokenů vlastností na základě schématu výstupu operace.
public IEnumerable<ServiceOperation> GetOperations(bool expandManifest)
{
return expandManifest ? serviceOperationsList : GetApiOperations();
}
Další informace najdete v ukázkové CosmosDbServiceOperationProvider.cs.
GetBindingConnectionInformation()
Pokud chcete použít typ triggeru založeného na Azure Functions, tato metoda poskytuje požadované informace o parametrech připojení k vazbě triggeru Azure Functions.
public string GetBindingConnectionInformation(string operationId, InsensitiveDictionary<JToken> connectionParameters)
{
return ServiceOperationsProviderUtilities
.GetRequiredParameterValue(
serviceId: ServiceId,
operationId: operationID,
parameterName: "connectionString",
parameters: connectionParameters)?
.ToValue<string>();
}
Další informace najdete v ukázkové CosmosDbServiceOperationProvider.cs.
InvokeOperation()
Pokud má váš vlastní integrovaný konektor jenom trigger, nemusíte tuto metodu implementovat. Pokud ale má váš konektor akce k implementaci, musíte implementovat metodu InvokeOperation(), která se volá pro každou akci v konektoru, která se spouští během provádění pracovního postupu. Můžete použít libovolného klienta, jako je FTPClient, HTTPClient atd., podle požadavků akcí konektoru. V tomto příkladu se používá 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);
}
Další informace najdete v ukázkové CosmosDbServiceOperationProvider.cs.
GetFunctionTriggerType()
Pokud chcete použít trigger založený na Azure Functions jako trigger ve vašem konektoru, musíte vrátit řetězec, který je stejný jako parametr typu ve vazbě triggeru Azure Functions.
Následující příklad vrátí řetězec pro předdefinovaný trigger Služby Azure Cosmos DB: "type": "cosmosDBTrigger"
public string GetFunctionTriggerType()
{
return "CosmosDBTrigger";
}
Další informace najdete v ukázkové CosmosDbServiceOperationProvider.cs.
GetFunctionTriggerDefinition()
Tato metoda má výchozí implementaci, takže tuto metodu nemusíte explicitně implementovat. Pokud ale chcete aktualizovat výchozí chování triggeru, například poskytnout další parametry, které návrhář nezpřístupňuje, můžete tuto metodu implementovat a přepsat výchozí chování.
Další kroky
Až budete připraveni zahájit kroky implementace, pokračujte následujícím článkem: