Sdílet prostřednictvím

Vlastní konektory v Azure Logic Apps

  • Článek

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 a přistupovat k datům, událostem a akcím v jiných aplikacích, službách, systémech, protokolech a platformách. 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šíříte možnosti cloudových aplikací a místních aplikací pro práci s novými i stávajícími daty.

Konektory v Azure Logic Apps jsou buď integrované , nebo spravované. Integrovaný konektor běží nativně v modulu runtime Azure Logic Apps, což znamená, že se hostuje ve stejném procesu jako modul runtime a poskytuje vyšší propustnost, nízkou latenci a místní připojení. Spravovaný konektor je proxy server nebo obálka kolem rozhraní API, například Office 365 nebo Salesforce, která pomáhá základní službě komunikovat s Azure Logic Apps. Spravované konektory využívají infrastrukturu konektorů v Azure a nasazuje je, hostuje, spouští a spravuje Microsoft. Můžete si vybrat ze stovek spravovaných konektorů, které můžete 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 tento krok vyžaduje mnoho dalších konektorů. 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. Pro podporu více přizpůsobených scénářů můžete vytvořit vlastní konektory , které budou nabízet 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ů aplikací logiky. Každý typ aplikace logiky využívá jiný modul runtime Azure Logic Apps, který je hostovaný v Azure s více tenanty a v Azure s jedním tenantem. Další informace o konektorech v Azure Logic Apps najdete v následující dokumentaci:

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ž po konkrétní omezení pro použití v pracovních postupech aplikací logiky Consumption. Dokumentace ke konektorům poskytuje další přehledné 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:

Standardní aplikace logiky

V Azure Logic Apps s jedním tenantem využívá přepracovaný modul runtime Azure Logic Apps pracovní postupy aplikací logiky Standard. 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 Azure Functions, který poskytuje klíčovou schopnost pro vytváření vlastních integrovaných konektorů pro kohokoli, kdo ho bude používat ve standardních pracovních postupech. Ve většině případů poskytuje integrovaná verze lepší výkon, možnosti, ceny atd.

Při oficiálním vydání Azure Logic Apps pro jednoho tenanta zahrnovaly nové integrované konektory Azure Blob Storage, Azure Event Hubs, Azure Service Bus a SQL Server. V průběhu času se tento seznam předdefinovaný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 standardu.

Integrované konektory založené na poskytovateli služeb

V Azure Logic Apps s jedním tenantem se integrovaný konektor se specifickými atributy označuje neformálně jako poskytovatel služeb. Tyto konektory jsou například založené na modelu rozšiřitelnosti Azure Functions, který poskytuje možnost vytvářet vlastní integrované konektory pro použití v pracovních postupech standardních aplikací logiky.

Naproti tomu integrované konektory, které nejsou poskytovateli služeb, mají následující atributy:

  • Není založená na modelu rozšiřitelnosti Azure Functions.

  • Je přímo implementovaná jako úloha v rámci modulu runtime Azure Logic Apps, jako jsou operace Schedule, HTTP, Request a XML.

V současné době není k dispozici žádná funkce pro vytvoření integrovaného konektoru jiného poskytovatele služeb nebo nového typu úlohy, který běží přímo v modulu runtime Azure Logic Apps. Můžete ale vytvořit vlastní předdefinované konektory pomocí infrastruktury poskytovatele služeb.

Následující část obsahuje další informace o tom, jak model rozšiřitelnosti funguje pro vlastní integrované konektory.

Integrovaný model rozšiřitelnosti 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 předdefinovaných konektorů jako Azure Functions rozšíření, která může kdokoli použít ve svých standardních pracovních postupech. Tento model zahrnuje vlastní integrované funkce triggeru, které podporují zveřejnění triggeru Azure Functions nebo akce jako triggeru poskytovatele služeb ve vašem 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:

Koncepční diagram znázorňující infrastrukturu poskytovatele služeb založenou na Azure Functions

Následující části obsahují další informace o rozhraních, která váš konektor musí implementovat.

IServiceOperationsProvider

Toto rozhraní obsahuje metody, které poskytují manifest operací pro vlastní integrovaný konektor.

  • Manifest operací

    Manifest operací obsahuje metadata o implementovaných operacích ve vašem 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í konektoru. Návrhář například používá metadata operací k pochopení vstupních parametrů vyžadovaných konkrétní operací a k usnadnění generování tokenů vlastností výstupů 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é konektor poskytuje a zobrazuje na ploše návrháře. Metoda GetService() také určuje vstupní parametry připojení, které jsou požadovány návrhářem.

    Další informace o těchto metodách a jejich implementaci najdete v části Metody k implementaci dále v tomto článku.

  • Vyvolání operací

    Vyvolání operací jsou implementace metody používané při provádění pracovního postupu modulem runtime Azure Logic Apps k volání zadaných operací v definici pracovního postupu.

    • Pokud je trigger typu triggeru založeného na Azure Functions, používá modul runtime v Azure Logic Apps metodu GetBindingConnectionInformation() k poskytnutí požadovaných informací o parametrech připojení vazbě triggeru Azure Functions.

    • Pokud váš konektor obsahuje akce, používá modul runtime metodu InvokeOperation() k volání každé akce v konektoru, která se spustí během provádění pracovního postupu. Jinak tuto metodu nemusíte implementovat.

Další informace o těchto metodách a jejich implementaci najdete v části Metody k implementaci dále v tomto článku.

IServiceOperationsTriggerProvider

Vlastní integrované funkce triggeru podporují přidání nebo zveřejnění triggeru nebo akce Azure Functions jako triggeru poskytovatele služeb ve vašem vlastním integrovaném konektoru. Pokud chcete použít typ triggeru založeného na Azure Functions a stejnou Azure Functions vazbu jako trigger spravovaného konektoru Azure, implementujte následující metody, které poskytují informace o připojení a aktivační vazby podle požadavků Azure Functions.

  • Metoda GetFunctionTriggerType() je vyžadována k vrácení řetězce, který je stejný jako parametr typu ve vazbě triggeru Azure Functions.

  • GetFunctionTriggerDefinition() 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 výchozí chování přepsat.

Metody k implementaci

Následující části obsahují další informace o metodách, které váš konektor musí implementovat. Úplnou ukázku najdete v tématu Ukázková služba CosmosDbServiceOperationProvider.cs a Vytvoření vlastních předdefinovaných konektorů pro aplikace logiky Standard v Azure Logic Apps s jedním tenantem.

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 ikon atd.

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

Další informace najdete v ukázce CosmosDbServiceOperationProvider.cs.

GetOperations()

Návrhář vyžaduje tuto metodu k tomu, aby vaše služba implementovala operace. Seznam operací je založený na schématu Swaggeru. Návrhář také používá metadata operace k pochopení vstupních parametrů pro konkrétní operace a generování výstupů jako tokenů vlastností na základě schématu výstupu pro operaci.

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

Další informace najdete v ukázce CosmosDbServiceOperationProvider.cs.

GetBindingConnectionInformation()

Pokud chcete použít typ triggeru založeného na Azure Functions, poskytuje tato metoda informace o požadovaných parametrech připojení 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ázce CosmosDbServiceOperationProvider.cs.

InvokeOperation()

Pokud má váš vlastní integrovaný konektor jenom trigger, nemusíte tuto metodu implementovat. Pokud ale váš konektor obsahuje akce k implementaci, musíte implementovat metodu InvokeOperation(), která se volá pro každou akci v konektoru, která se spustí během provádění pracovního postupu. Můžete použít libovolného klienta, například FTPClient, HTTPClient a tak dále, jak to vyžadují akce vašeho 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ázce CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerType()

Pokud chcete jako trigger v konektoru použít trigger založený na Azure Functions, 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ázce CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerDefinition()

Tato metoda má výchozí implementaci, takže ji nemusíte explicitně implementovat. Pokud ale chcete aktualizovat výchozí chování triggeru, například zadat další parametry, které návrhář nezpřístupňuje, můžete implementovat tuto metodu 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: