Sdílet prostřednictvím


Co jsou konektory v Azure Logic Apps

Když vytváříte pracovní postup pomocí Azure Logic Apps, můžete pomocí konektoru pracovat s daty, událostmi a prostředky v jiných aplikacích, službách, systémech a platformách – bez psaní kódu. Konektor poskytuje jednu nebo více předem připravených operací, které použijete jako kroky v pracovním postupu.

V konektoru je každá operace buď podmínkou triggeru, která spouští pracovní postup, nebo následnou akci, která provádí konkrétní úlohu, spolu s vlastnostmi, které můžete nakonfigurovat. Zatímco mnoho konektorů má triggery i akce, některé konektory nabízejí jenom triggery, zatímco jiné poskytují jenom akce.

V Azure Logic Apps jsou konektory dostupné buď v integrované verzi, spravované verzi, nebo v obou. Mnoho konektorů obvykle vyžaduje, abyste nejprve vytvořili a nakonfigurovali připojení k podkladové službě nebo systému, obvykle tak, abyste mohli ověřit přístup k uživatelskému účtu. Pokud pro službu nebo systém, ke kterému chcete získat přístup, není k dispozici žádný konektor, můžete odeslat požadavek pomocí obecné operace HTTP nebo můžete vytvořit vlastní konektor.

Tento přehled obsahuje základní úvod ke konektorům a jejich obecné fungování. Další informace o konektoru najdete v následující dokumentaci:

Integrované konektory a spravované konektory

V Azure Logic Apps jsou konektory buď integrované , nebo spravované. Některé konektory mají obě verze. Dostupné verze závisí na tom, jestli vytvoříte pracovní postup aplikace logiky Consumption , který běží ve víceklientských aplikacích Azure Logic Apps, nebo na pracovním postupu standardní aplikace logiky, který běží v Azure Logic Apps s jedním tenantem. Další informace o typech prostředků aplikace logiky najdete v tématu Typy prostředků a rozdíly v hostitelském prostředí.

  • Integrované konektory jsou navržené tak, aby běžely přímo a nativně v Azure Logic Apps.

  • Spravované konektory se nasazují, hostují a spravují v Azure microsoftem. Spravované konektory většinou poskytují proxy server nebo obálku kolem rozhraní API, které podkladová služba nebo systém používá ke komunikaci s Azure Logic Apps.

    • V pracovním postupu Consumption se spravované konektory zobrazují v návrháři pod popisky Standard nebo Enterprise na základě jejich cenové úrovně.

    • Ve standardním pracovním postupu se všechny spravované konektory zobrazí v návrháři pod popiskem Azure .

Další informace najdete v následující dokumentaci:

Aktivační události

Aktivační událost určuje podmínku, která se má splnit před spuštěním pracovního postupu, a je vždy prvním krokem v jakémkoli pracovním postupu. Každá aktivační událost se řídí také konkrétním způsobem spuštění, který řídí, jak trigger monitoruje a reaguje na události. Trigger se obvykle řídí vzorem dotazování nebo vzorem nabízení. Někdy jsou k dispozici obě verze triggerů.

  • Triggery dotazování pravidelně kontrolují konkrétní službu nebo systém podle zadaného plánu a kontrolují nová data nebo konkrétní událost. Pokud jsou k dispozici nová data nebo dojde ke konkrétní události, tyto triggery vytvoří a spustí novou instanci pracovního postupu. Tato nová instance pak může použít data, která se předávají jako vstup.

    Poznámka:

    U konektorů spravovaných Microsoftem, hostovaných a spuštěných v Azure se triggery dotazování používají pouze hodnoty Interval a Frekvence k výpočtu dalšího opakování. Nepoužívají pokročilé možnosti plánování, například v těchto hodinách a v těchto dnech. Tyto možnosti fungují jenom s integrovanými triggery dotazování, které se spouští přímo s modulem runtime Azure Logic Apps, jako jsou například opakování, posuvné okno a triggery HTTP .

  • Triggery nabízených oznámení nebo webhooků naslouchají novým datům nebo události, ke které dojde bez dotazování. Pokud jsou k dispozici nová data nebo když dojde k události, tyto triggery vytvoří a spustí novou instanci pracovního postupu. Tato nová instance pak může použít data, která se předávají jako vstup.

Předpokládejme například, že chcete vytvořit pracovní postup, který se spustí při nahrání souboru na server FTP. Jako první krok pracovního postupu můžete přidat trigger FTP s názvem Při přidání nebo úpravě souboru, který se řídí vzorem dotazování. Pak určíte plán, který bude pravidelně kontrolovat události nahrávání.

Když se trigger aktivuje, aktivační událost obvykle předává výstupy událostí pro následné akce, které se mají odkazovat a používat. V příkladu FTP trigger automaticky vypíše informace, jako je název souboru a cesta. Aktivační událost můžete také nastavit tak, aby zahrnovala obsah souboru. Abyste mohli tato data zpracovat, musíte do pracovního postupu přidat akce.

Akce

Akce určuje úkol, který se má provést, a vždy se zobrazí jako následný krok v pracovním postupu. V pracovním postupu můžete použít více akcí. Můžete například spustit pracovní postup pomocí triggeru SQL Serveru, který kontroluje nová zákaznická data v databázi SQL. Po triggeru může mít váš pracovní postup akci SQL Serveru, která získá zákaznická data. Po provedení této akce SQL Serveru může váš pracovní postup použít jinou akci, která zpracovává data, například akci Operace s daty, která vytvoří tabulku CSV.

Oprávnění k připojení

Před vytvořením nebo správou prostředků, pracovních postupů a jejich připojení v pracovním postupu aplikace logiky Consumption potřebujete konkrétní oprávnění. Další informace o těchto oprávněních najdete v tématu Zabezpečené operace – Zabezpečený přístup a data v Azure Logic Apps.

Vytvoření, konfigurace a ověřování připojení

Než budete moct ve svém pracovním postupu použít operace konektoru, mnoho konektorů vyžaduje, abyste nejprve vytvořili připojení k cílové službě nebo systému. Pokud chcete vytvořit připojení z návrháře pracovního postupu, musíte ověřit identitu pomocí přihlašovacích údajů účtu a někdy i dalších informací o připojení.

Například před přístupem k pracovnímu postupu a prací s e-mailovým účtem Office 365 Outlook musíte autorizovat připojení k ho. U některých integrovaných konektorů a spravovaných konektorů můžete pro ověřování nastavit a použít spravovanou identitu, a ne zadat přihlašovací údaje.

I když vytváříte připojení v rámci pracovního postupu, tato připojení jsou ve skutečnosti samostatné prostředky Azure s vlastními definicemi prostředků. Pokud chcete zkontrolovat tyto definice prostředků připojení, postupujte podle těchto kroků podle toho, jestli máte pracovní postup Consumption nebo Standard:

Zabezpečení a šifrování připojení

Podrobnosti konfigurace připojení, jako je adresa serveru, uživatelské jméno a heslo, přihlašovací údaje a tajné kódy, se šifrují a ukládají v zabezpečeném prostředí Azure. Tyto informace můžou používat jenom v prostředcích aplikace logiky a klienti, kteří mají oprávnění k prostředku připojení, který se vynucuje pomocí kontrol přístupu propojených. Připojení, která používají ověřování Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), jako je Office 365, Salesforce a GitHub, vyžadují, abyste se přihlásili, ale Azure Logic Apps ukládá pouze přístup a obnovovací tokeny jako tajné kódy, nikoli přihlašovací údaje.

Zavedená připojení mají přístup k cílové službě nebo systému, pokud tato služba nebo systém umožňuje. Pro služby, které používají připojení OAuth Microsoft Entra ID, jako jsou Office 365 a Dynamics, Azure Logic Apps aktualizuje přístupové tokeny neomezeně dlouho. Ostatní služby můžou mít omezení, jak dlouho může Logic Apps používat token bez aktualizace. Některé akce, jako je změna hesla, zneplatní všechny přístupové tokeny.

Poznámka:

Pokud vám vaše organizace neumožňuje přístup ke konkrétním prostředkům prostřednictvím konektorů v Azure Logic Apps, můžete zablokovat možnost vytvářet taková připojení pomocí Azure Policy.

Další informace o zabezpečení pracovních postupů a připojení aplikací logiky najdete v tématu Zabezpečený přístup a data v Azure Logic Apps.

Přístup k bráně firewall pro připojení

Pokud používáte bránu firewall, která omezuje provoz a pracovní postupy aplikace logiky musí komunikovat přes tuto bránu firewall, musíte nastavit bránu firewall tak, aby umožňovala přístup pro příchozí i odchozí IP adresy používané platformou Azure Logic Apps nebo modulem runtime v oblasti Azure, kde existují pracovní postupy vaší aplikace logiky.

Pokud vaše pracovní postupy používají také spravované konektory, jako je konektor Office 365 Outlook nebo konektor SQL, nebo používají vlastní konektory, musí brána firewall také povolit přístup pro všechny odchozí IP adresy spravovaného konektoru v oblasti Azure vaší aplikace logiky. Další informace najdete v tématu Konfigurace brány firewall.

Vlastní konektory a rozhraní API

V pracovních postupech Consumption pro víceklientské azure Logic Apps můžete volat rozhraní API založená na Swaggeru nebo SOAP, která nejsou k dispozici jako předem připravená konektory. Vlastní kód můžete také spustit vytvořením vlastních aplikací API. Další informace najdete v následující dokumentaci:

V pracovních postupech Standard pro Azure Logic Apps s jedním tenantem můžete vytvořit nativně spuštěné vlastní integrované konektory založené na poskytovateli služeb, které jsou k dispozici pro jakýkoli pracovní postup standardní aplikace logiky. Další informace najdete v následující dokumentaci:

Známé problémy

Následující tabulka obsahuje známé problémy s konektory v Azure Logic Apps:

Chybová zpráva Popis Rozlišení
Error: BadGateway. Client request id: '{GUID}' Výsledkem této chyby je aktualizace značek u prostředku aplikace logiky, kde jedno nebo více připojení nepodporuje ověřování OAuth s Microsoft Entra ID OAuth, jako je například ad SFTP AD SQL, způsobující tato připojení. Chcete-li zabránit tomuto chování, vyhněte se aktualizaci těchto značek.

Další kroky