Vytváření vlastních rozhraní API, která můžete volat z Azure Logic AppsCreate custom APIs you can call from Azure Logic Apps

I když Azure Logic Apps nabízí stovky konektorů , které můžete použít v pracovních postupech aplikace logiky, možná budete chtít volat rozhraní API, systémy a služby, které nejsou k dispozici jako konektory.Although Azure Logic Apps offers hundreds of connectors that you can use in logic app workflows, you might want to call APIs, systems, and services that aren't available as connectors. Můžete vytvořit vlastní rozhraní API, která zajišťují akce a triggery, které se mají použít ve službě Logic Apps.You can create your own APIs that provide actions and triggers to use in logic apps. Tady jsou další důvody, proč byste mohli chtít vytvořit vlastní rozhraní API, které můžete volat z pracovních postupů aplikací logiky:Here are other reasons why you might want to create your own APIs that you can call from logic app workflows:

  • Rozšíříte své stávající pracovní postupy integrace systému a integrace dat.Extend your current system integration and data integration workflows.
  • Zákazníci můžou pomocí vaší služby spravovat profesionální nebo osobní úkoly.Help customers use your service to manage professional or personal tasks.
  • Rozšiřte dostupnost, zjistitelnost a použití pro vaši službu.Expand the reach, discoverability, and use for your service.

V podstatě jsou konektory webová rozhraní API, která používají REST pro připojitelná rozhraní, formát metadat Swagger pro dokumentaci a formát JSON jako formát výměny dat.Basically, connectors are web APIs that use REST for pluggable interfaces, Swagger metadata format for documentation, and JSON as their data exchange format. Vzhledem k tomu, že konektory jsou rozhraní REST API, která komunikují prostřednictvím koncových bodů HTTP, můžete pro vytváření konektorů použít libovolný jazyk, jako je .NET, Java, Python nebo Node.js.Because connectors are REST APIs that communicate through HTTP endpoints, you can use any language, like .NET, Java, Python, or Node.js, for building connectors. Můžete také hostovat rozhraní API na Azure App Service, jako je nabídka typu platforma jako služba (PaaS), která poskytuje jeden z nejlepších, nejjednodušších a nejškálovatelných způsobů pro hostování rozhraní API.You can also host your APIs on Azure App Service, a platform-as-a-service (PaaS) offering that provides one of the best, easiest, and most scalable ways for API hosting.

Aby mohla vlastní rozhraní API spolupracovat s Logic Apps, může vaše rozhraní API poskytovat Akce , které provádějí konkrétní úkoly v pracovních postupech aplikace logiky.For custom APIs to work with logic apps, your API can provide actions that perform specific tasks in logic app workflows. Vaše rozhraní API může fungovat taky jako Trigger , který spouští pracovní postup aplikace logiky, když nová data nebo událost splňují zadanou podmínku.Your API can also act as a trigger that starts a logic app workflow when new data or an event meets a specified condition. Toto téma popisuje běžné vzory, které můžete provést při vytváření akcí a triggerů v rozhraní API na základě chování, které má vaše rozhraní API poskytovat.This topic describes common patterns that you can follow for building actions and triggers in your API, based on the behavior that you want your API to provide.

Své rozhraní API můžete hostovat na Azure App Service, jako je nabídka typu platforma jako služba (PaaS), která poskytuje vysoce škálovatelné a jednoduché hostování rozhraní API.You can host your APIs on Azure App Service, a platform-as-a-service (PaaS) offering that provides highly scalable, easy API hosting.

Tip

I když můžete nasadit rozhraní API jako webové aplikace, zvažte nasazení rozhraní API jako aplikací API, které vám umožní usnadnit práci při sestavování, hostování a využívání rozhraní API v cloudu i místně.Although you can deploy your APIs as web apps, consider deploying your APIs as API apps, which can make your job easier when you build, host, and consume APIs in the cloud and on premises. Nemusíte měnit žádný kód v rozhraních API – stačí kód nasadit do aplikace API.You don't have to change any code in your APIs -- just deploy your code to an API app. Přečtěte si například, jak vytvářet aplikace API vytvořené pomocí těchto jazyků:For example, learn how to build API apps created with these languages:

Ukázky pro aplikace API vytvořené pro Logic Apps najdete v úložišti Azure Logic Apps GitHubu.For API App samples built for logic apps, visit the Azure Logic Apps GitHub repository.

Jak se vlastní rozhraní API liší od vlastních konektorů?How do custom APIs differ from custom connectors?

Vlastní rozhraní API a vlastní konektory jsou webová rozhraní API, která používají REST pro připojitelná rozhraní, formát metadat Swagger pro dokumentaci a formát JSON jako formát výměny dat.Custom APIs and custom connectors are web APIs that use REST for pluggable interfaces, Swagger metadata format for documentation, and JSON as their data exchange format. A vzhledem k tomu, že tato rozhraní API a konektory jsou rozhraní REST API, která komunikují prostřednictvím koncových bodů HTTP, můžete pro vytváření vlastních rozhraní API a konektorů použít libovolný jazyk, třeba .NET, Java, Python nebo Node.js.And because these APIs and connectors are REST APIs that communicate through HTTP endpoints, you can use any language, like .NET, Java, Python, or Node.js, for building custom APIs and connectors.

Vlastní rozhraní API umožňují volat rozhraní API, která nejsou konektory, a poskytnout koncové body, které můžete volat pomocí protokolu HTTP + Swagger, Azure API Management nebo App Services.Custom APIs let you call APIs that aren't connectors, and provide endpoints that you can call with HTTP + Swagger, Azure API Management, or App Services. Vlastní konektory fungují jako vlastní rozhraní API, ale mají také tyto atributy:Custom connectors work like custom APIs but also have these attributes:

  • Registrováno jako Logic Apps prostředků konektoru v Azure.Registered as Logic Apps Connector resources in Azure.
  • Zobrazuje se ikonami vedle konektorů spravovaných Microsoftem v Návrháři Logic Apps.Appear with icons alongside Microsoft-managed connectors in the Logic Apps Designer.
  • K dispozici pouze pro autory konektorů a uživatele aplikace logiky, kteří mají stejné Azure Active Directory tenanta a předplatné Azure v oblasti, kde jsou nasazené Logic Apps.Available only to the connectors' authors and logic app users who have the same Azure Active Directory tenant and Azure subscription in the region where the logic apps are deployed.

Můžete také jmenovat zaregistrované konektory pro certifikaci Microsoftu.You can also nominate registered connectors for Microsoft certification. Tento proces ověří, že registrované konektory splňují kritéria pro veřejné použití a zpřístupňuje tyto konektory uživatelům v Power automatu a Microsoft Power Apps.This process verifies that registered connectors meet the criteria for public use and makes those connectors available for users in Power Automate and Microsoft Power Apps.

Další informace o vlastních konektorech najdete v tématu.For more information about custom connectors, see

Užitečné nástrojeHelpful tools

Vlastní rozhraní API funguje nejlépe s Logic Apps, když rozhraní API má také dokument Swagger , který popisuje operace a parametry rozhraní API.A custom API works best with logic apps when the API also has a Swagger document that describes the API's operations and parameters. Mnoho knihoven, jako je swashbuckle, může automaticky vygenerovat soubor Swagger.Many libraries, like Swashbuckle, can automatically generate the Swagger file for you. Chcete-li přidat poznámku do souboru Swagger pro zobrazované názvy, typy vlastností a tak dále, můžete použít také TRex , aby soubor Swagger dobře fungoval s Logic Apps.To annotate the Swagger file for display names, property types, and so on, you can also use TRex so that your Swagger file works well with logic apps.

Vzorce akcíAction patterns

Aby Logic Apps prováděly úlohy, měla by vaše vlastní rozhraní API poskytovat Akce.For logic apps to perform tasks, your custom API should provide actions. Každá operace v rozhraní API se mapuje na akci.Each operation in your API maps to an action. Základní akce je kontroler, který přijímá požadavky HTTP a vrací odpovědi HTTP.A basic action is a controller that accepts HTTP requests and returns HTTP responses. Například aplikace logiky pošle požadavek HTTP do vaší webové aplikace nebo aplikace API.So for example, a logic app sends an HTTP request to your web app or API app. Vaše aplikace pak vrátí odpověď HTTP spolu s obsahem, který může aplikace logiky zpracovat.Your app then returns an HTTP response, along with content that the logic app can process.

U standardní akce můžete napsat metodu žádosti HTTP do rozhraní API a popsat tuto metodu v souboru Swagger.For a standard action, you can write an HTTP request method in your API and describe that method in a Swagger file. Své rozhraní API pak můžete volat přímo pomocí akce http nebo akce http + Swagger .You can then call your API directly with an HTTP action or an HTTP + Swagger action. Ve výchozím nastavení musí být odpovědi vráceny v rámci časovéholimitu požadavku.By default, responses must be returned within the request timeout limit.

Standardní vzorec akce

Aby aplikace logiky čekala na dokončení probíhajících úloh, vaše rozhraní API může postupovat podle vzorce asynchronního cyklického dotazování nebo pomocí asynchronního vzoru Webhooku popsaného v tomto tématu.To make a logic app wait while your API finishes longer-running tasks, your API can follow the asynchronous polling pattern or the asynchronous webhook pattern described in this topic. V případě analogového způsobu, který vám pomůže vizualizovat Tato vzorová chování, Představte si proces pro objednávání vlastního dortíku z pekařství.For an analogy that helps you visualize these patterns' different behaviors, imagine the process for ordering a custom cake from a bakery. Vzor cyklického dotazování zrcadlí chování, kdy zavoláte do pekařství každých 20 minut, a zkontrolujete, jestli je dortík připravený.The polling pattern mirrors the behavior where you call the bakery every 20 minutes to check whether the cake is ready. Vzorek Webhooku zrcadlí chování, ve kterém se vám bude připojovat k telefonnímu číslu, aby se mohli zavolat na to, kdy je dortík připravený.The webhook pattern mirrors the behavior where the bakery asks you for your phone number so they can call you when the cake is ready.

Ukázky najdete v Logic Apps úložišti GitHubu.For samples, visit the Logic Apps GitHub repository. Přečtěte si taky další informace o měření využití pro akce.Also, learn more about usage metering for actions.

Provádění dlouhotrvajících úloh pomocí vzoru akce cyklického dotazováníPerform long-running tasks with the polling action pattern

Chcete-li, aby vaše rozhraní API provádělo úlohy, které by mohly běžet déle než časový limit žádosti, můžete použít model asynchronního cyklického dotazování.To have your API perform tasks that could run longer than the request timeout limit, you can use the asynchronous polling pattern. Tento model rozhraní API funguje v samostatném vlákně, ale zachová aktivní připojení k modulu Logic Apps.This pattern has your API do work in a separate thread, but keep an active connection to the Logic Apps engine. Díky tomuto postupu aplikace logiky nevypršel časový limit nebo v dalším kroku pracovního postupu pokračovala, než vaše rozhraní API dokončí práci.That way, the logic app does not time out or continue with the next step in the workflow before your API finishes working.

Tady je obecný vzor:Here's the general pattern:

  1. Ujistěte se, že stroj ví, že vaše rozhraní API přijalo požadavek a začal pracovat.Make sure that the engine knows that your API accepted the request and started working.
  2. Když modul provede další požadavky na stav úlohy, poznáte modul, když vaše rozhraní API dokončí úlohu.When the engine makes subsequent requests for job status, let the engine know when your API finishes the task.
  3. Vrátí relevantní data modulu, aby mohl pracovní postup aplikace logiky pokračovat.Return relevant data to the engine so that the logic app workflow can continue.

Teď použijte předchozí pekařskou analogii na vzor cyklického dotazování a Představte si, že voláte a objednat si vlastní dortík za doručení.Now apply the previous bakery analogy to the polling pattern, and imagine that you call a bakery and order a custom cake for delivery. Proces pro zajištění, že dortík přetrvá čas, nechcete čekat na telefon, zatímco pekařace působí na dort.The process for making the cake takes time, and you don't want to wait on the phone while the bakery works on the cake. Baker potvrdí vaši objednávku a zavolá se každé 20 minut na stav dortíku.The bakery confirms your order and has you call every 20 minutes for the cake's status. Po 20 minutách budete volat pekařství, ale dáme vám vědět, že se váš dort nedokončil a že byste měli zavolat za další 20 minut.After 20 minutes pass, you call the bakery, but they tell you that your cake isn't done and that you should call in another 20 minutes. Tento proces back-and se pokračuje, dokud nebudete volat, a přípravné informace o tom, že vaše objednávka je připravená a dává vám svůj dortík.This back-and-forth process continues until you call, and the bakery tells you that your order is ready and delivers your cake.

Pojďme tedy tento vzor cyklického dotazování namapovat zpátky.So let's map this polling pattern back. Pekař představuje vaše vlastní rozhraní API, zatímco vy, což je zákazník, představuje Logic Apps Engine.The bakery represents your custom API, while you, the cake customer, represent the Logic Apps engine. Když stroj zavolá vaše rozhraní API s požadavkem, rozhraní API potvrdí požadavek a odpoví na časový interval, kdy může modul kontrolovat stav úlohy.When the engine calls your API with a request, your API confirms the request and responds with the time interval when the engine can check job status. Modul pokračuje v kontrole stavu úlohy, dokud vaše rozhraní API neodpoví na to, že se úloha dokončila, a vrátí data do vaší aplikace logiky, které pak pokračuje v pracovním postupu.The engine continues checking job status until your API responds that the job is done and returns data to your logic app, which then continues workflow.

Vzor akce cyklického dotazování

Tady jsou konkrétní kroky, které má vaše rozhraní API sledovat, a to popsaných v perspektivě rozhraní API:Here are the specific steps for your API to follow, described from the API's perspective:

  1. Když rozhraní API vrátí požadavek HTTP na spuštění práce, okamžitě vrátí 202 ACCEPTED odpověď HTTP s location hlavičkou popsanou níže v tomto kroku.When your API gets an HTTP request to start work, immediately return an HTTP 202 ACCEPTED response with the location header described later in this step. Tato odpověď umožňuje, aby modul Logic Apps ví, že vaše rozhraní API získalo požadavek, přijalo datovou část požadavku (vstup dat) a právě zpracovává.This response lets the Logic Apps engine know that your API got the request, accepted the request payload (data input), and is now processing.

    202 ACCEPTEDOdpověď by měla obsahovat tyto hlavičky:The 202 ACCEPTED response should include these headers:

    • Požadováno: location záhlaví, které určuje absolutní cestu k adrese URL, kde Logic Apps modul může kontrolovat stav úlohy rozhraní API.Required: A location header that specifies the absolute path to a URL where the Logic Apps engine can check your API's job status

    • Volitelné: retry-after Hlavička, která určuje počet sekund, po které má modul čekat před kontrolou location adresy URL pro stav úlohy.Optional: A retry-after header that specifies the number of seconds that the engine should wait before checking the location URL for job status.

      Ve výchozím nastavení modul kontroluje každých 20 sekund.By default, the engine checks every 20 seconds. Pokud chcete zadat jiný interval, zahrňte retry-after hlavičku a počet sekund do dalšího cyklického dotazování.To specify a different interval, include the retry-after header and the number of seconds until the next poll.

  2. Po uplynutí zadaného času se modul Logic Apps dotazuje na location adresu URL, aby zkontroloval stav úlohy.After the specified time passes, the Logic Apps engine polls the location URL to check job status. Vaše rozhraní API by mělo provádět tyto kontroly a vracet tyto odpovědi:Your API should perform these checks and return these responses:

    • Pokud se úloha dokončí, vraťte odpověď HTTP 200 OK spolu s datovou částí Response (vstup pro další krok).If the job is done, return an HTTP 200 OK response, along with the response payload (input for the next step).

    • Pokud se úloha stále zpracovává, vraťte jinou odpověď HTTP 202 ACCEPTED , ale se stejnými hlavičkami jako původní odpověď.If the job is still processing, return another HTTP 202 ACCEPTED response, but with the same headers as the original response.

Když je tento model rozhraní API, nemusíte dělat nic v definici pracovního postupu aplikace logiky, aby bylo možné pokračovat v kontrole stavu úlohy.When your API follows this pattern, you don't have to do anything in the logic app workflow definition to continue checking job status. Když modul získá 202 ACCEPTED odpověď HTTP a platnou location hlavičku, modul respektuje asynchronní vzor a zkontroluje location hlavičku, dokud rozhraní API nevrátí odpověď, která není 202.When the engine gets an HTTP 202 ACCEPTED response and a valid location header, the engine respects the asynchronous pattern and checks the location header until your API returns a non-202 response.

Tip

Příklad asynchronního vzoru najdete v této ukázce asynchronního řadiče v GitHubu.For an example asynchronous pattern, review this asynchronous controller response sample in GitHub.

Provádění dlouhotrvajících úloh pomocí vzoru akce WebhookuPerform long-running tasks with the webhook action pattern

Alternativně můžete použít vzor Webhooku pro dlouhotrvající úlohy a asynchronní zpracování.As an alternative, you can use the webhook pattern for long-running tasks and asynchronous processing. V tomto modelu se aplikace logiky pozastavuje a před pokračováním pracovního postupu čeká na zpětné volání z rozhraní API, aby se dokončilo zpracování.This pattern has the logic app pause and wait for a "callback" from your API to finish processing before continuing workflow. Toto zpětné volání je příspěvek HTTP, který pošle zprávu na adresu URL, když dojde k události.This callback is an HTTP POST that sends a message to a URL when an event happens.

Teď použijte předchozí pekařii na vzor Webhooku a Představte si, že jste volali pekařství a obvedli vlastní dortíky na doručení.Now apply the previous bakery analogy to the webhook pattern, and imagine that you call a bakery and order a custom cake for delivery. Proces pro zajištění, že dortík přetrvá čas, nechcete čekat na telefon, zatímco pekařace působí na dort.The process for making the cake takes time, and you don't want to wait on the phone while the bakery works on the cake. Baker potvrdí vaši objednávku, ale tentokrát jim poskytnete své telefonní číslo, aby vás mohli zavolat, až se dortík dokončí.The bakery confirms your order, but this time, you give them your phone number so they can call you when the cake is done. Tentokrát vám oznamujeme, že je vaše objednávka připravená a že je doručí váš dort.This time, the bakery tells you when your order is ready and delivers your cake.

Když jsme tento vzor Webhooku namapovali zpátky, pracovní postup představuje vaše vlastní rozhraní API, zatímco vy, což je zákazník v dortu, představuje modul Logic Apps.When we map this webhook pattern back, the bakery represents your custom API, while you, the cake customer, represent the Logic Apps engine. Stroj volá vaše rozhraní API s požadavkem a obsahuje adresu URL zpětného volání.The engine calls your API with a request and includes a "callback" URL. Po dokončení úlohy používá vaše rozhraní API adresu URL, která upozorní modul a vrátí data do vaší aplikace logiky, což pak pokračuje v pracovním postupu.When the job is done, your API uses the URL to notify the engine and return data to your logic app, which then continues workflow.

Pro tento model nastavte na řadiči dva koncové body: subscribe a unsubscribeFor this pattern, set up two endpoints on your controller: subscribe and unsubscribe

  • subscribe koncový bod: když provádění dosáhne akce vašeho rozhraní API v pracovním postupu, modul Logic Apps volá subscribe koncový bod.subscribe endpoint: When execution reaches your API's action in the workflow, the Logic Apps engine calls the subscribe endpoint. Tento krok způsobí, že aplikace logiky vytvoří adresu URL zpětného volání, kterou vaše rozhraní API uloží, a po dokončení práce počká na zpětné volání od rozhraní API.This step causes the logic app to create a callback URL that your API stores and then wait for the callback from your API when work is complete. Rozhraní API pak zavolá zpět s HTTP POST na adresu URL a předá do aplikace logiky libovolný vrácený obsah a záhlaví jako vstup.Your API then calls back with an HTTP POST to the URL and passes any returned content and headers as input to the logic app.

  • unsubscribe koncový bod: Pokud je aplikace logiky zrušena, modul Logic Apps volá unsubscribe koncový bod.unsubscribe endpoint: If the logic app run is canceled, the Logic Apps engine calls the unsubscribe endpoint. Vaše rozhraní API pak může zrušit registraci adresy URL zpětného volání a v případě potřeby zastavit všechny procesy.Your API can then unregister the callback URL and stop any processes as necessary.

Vzor akce Webhooku

Návrhář aplikace logiky v současné době nepodporuje zjišťování koncových bodů webhooků prostřednictvím Swagger.Currently, the Logic App Designer doesn't support discovering webhook endpoints through Swagger. Pro tento model tedy musíte přidat akci Webhooku a zadat adresu URL, záhlaví a text pro vaši žádost.So for this pattern, you have to add a Webhook action and specify the URL, headers, and body for your request. Viz také akce a triggery pracovního postupu.See also Workflow actions and triggers. Příklad vzoru Webhooku najdete v tomto příkladu triggeru Webhooku na GitHubu.For an example webhook pattern, review this webhook trigger sample in GitHub.

Tady jsou některé další tipy a poznámky:Here are some other tips and notes:

  • Chcete-li předat adresu URL zpětného volání, můžete v případě @listCallbackUrl() potřeby použít funkci pracovního postupu v libovolném z předchozích polí.To pass in the callback URL, you can use the @listCallbackUrl() workflow function in any of the previous fields as necessary.

  • Pokud vlastníte aplikaci logiky i předplacenou službu, nemusíte volat unsubscribe koncový bod po volání adresy URL zpětného volání.If you own both the logic app and the subscribed service, you don't have to call the unsubscribe endpoint after the callback URL is called. V opačném případě musí modul runtime Logic Apps volat unsubscribe koncový bod k signalizaci, že nejsou očekávána žádná další volání a aby bylo možné vyčistit prostředky na straně serveru.Otherwise, the Logic Apps runtime needs to call the unsubscribe endpoint to signal that no more calls are expected and to allow for resource clean up on the server side.

Vzory triggerůTrigger patterns

Vaše vlastní rozhraní API může fungovat jako Trigger , který spouští aplikaci logiky, když nová data nebo událost splňují zadanou podmínku.Your custom API can act as a trigger that starts a logic app when new data or an event meets a specified condition. Tato aktivační událost může buď pravidelně kontrolovat, nebo čekat a naslouchat pro nová data nebo události na koncovém bodu služby.This trigger can either check regularly, or wait and listen, for new data or events at your service endpoint. Pokud nová data nebo událost splní zadanou podmínku, Trigger se aktivuje a spustí aplikaci logiky, která naslouchá této aktivační události.If new data or an event meets the specified condition, the trigger fires and starts the logic app, which is listening to that trigger. Aby bylo možné spustit Logic Apps tímto způsobem, může vaše rozhraní API sledovat Trigger cyklického dotazování nebo vzor triggeru Webhooku .To start logic apps this way, your API can follow the polling trigger or the webhook trigger pattern. Tyto vzory jsou podobné jejich protějškům při dotazování akcí a akcí Webhooku.These patterns are similar to their counterparts for polling actions and webhook actions. Přečtěte si taky další informace o měření využití pro aktivační události.Also, learn more about usage metering for triggers.

Pravidelné zjišťování nových dat nebo událostí pomocí vzoru triggeru cyklického dotazováníCheck for new data or events regularly with the polling trigger pattern

Aktivační událost cyklického dotazování funguje podobně jako Akce cyklického dotazování dříve popsané v tomto tématu.A polling trigger acts much like the polling action previously described in this topic. Modul Logic Apps pravidelně volá a kontroluje koncový bod triggeru pro nová data nebo události.The Logic Apps engine periodically calls and checks the trigger endpoint for new data or events. Pokud modul najde nová data nebo událost, která splňuje zadanou podmínku, aktivuje se Trigger.If the engine finds new data or an event that meets your specified condition, the trigger fires. Modul potom vytvoří instanci aplikace logiky, která zpracovává data jako vstup.Then, the engine creates a logic app instance that processes the data as input.

Vzor triggeru cyklického dotazování

Poznámka

Každá žádost o cyklické dotazování se počítá jako provedení akce, a to i v případě, že se nevytvoří žádná instance aplikace logiky.Each polling request counts as an action execution, even when no logic app instance is created. Aby se zabránilo tomu, že se stejná data zpracovávají víckrát, měla by aktivační událost vyčistit data, která již byla přečtena a předána do aplikace logiky.To prevent processing the same data multiple times, your trigger should clean up data that was already read and passed to the logic app.

Tady jsou konkrétní kroky pro aktivační událost cyklického dotazování, která je popsaná v perspektivě rozhraní API:Here are specific steps for a polling trigger, described from the API's perspective:

Našla se nová data nebo událost?Found new data or event? Odpověď rozhraní APIAPI response
FoundFound Vrátí stav HTTP 200 OK s datovou částí Response (vstup pro další krok).Return an HTTP 200 OK status with the response payload (input for next step).
Tato odpověď vytvoří instanci aplikace logiky a spustí pracovní postup.This response creates a logic app instance and starts the workflow.
NenalezenoNot found Vrátí stav HTTP 202 ACCEPTED s location hlavičkou a retry-after hlavičkou.Return an HTTP 202 ACCEPTED status with a location header and a retry-after header.
V případě aktivačních událostí location by záhlaví mělo obsahovat také triggerState parametr dotazu, což je obvykle "časové razítko".For triggers, the location header should also contain a triggerState query parameter, which is usually a "timestamp." Rozhraní API může pomocí tohoto identifikátoru sledovat čas poslední aktivace aplikace logiky.Your API can use this identifier to track the last time that the logic app was triggered.

Pokud třeba chcete pravidelně kontrolovat službu pro nové soubory, můžete vytvořit Trigger cyklického dotazování s tímto chováním:For example, to periodically check your service for new files, you might build a polling trigger that has these behaviors:

Obsahuje požadavek triggerState ?Request includes triggerState? Odpověď rozhraní APIAPI response
NeNo Vrátí stav HTTP a 202 ACCEPTED location hlavičku s triggerState nastavenou na aktuální čas a retry-after interval na 15 sekund.Return an HTTP 202 ACCEPTED status plus a location header with triggerState set to the current time and the retry-after interval to 15 seconds.
AnoYes Ověřte službu pro soubory přidané po DateTime pro triggerState .Check your service for files added after the DateTime for triggerState.
Počet nalezených souborůNumber of files found Odpověď rozhraní APIAPI response
Jeden souborSingle file Vraťte stav HTTP 200 OK a datovou část obsahu, aktualizujte triggerState DateTime hodnotu pro vrácený soubor a nastavte retry-after interval na 15 sekund.Return an HTTP 200 OK status and the content payload, update triggerState to the DateTime for the returned file, and set retry-after interval to 15 seconds.
Více souborůMultiple files V jednom okamžiku vraťte soubor a 200 OK stav HTTP, aktualizujte triggerState a nastavte retry-after interval na 0 sekund.Return one file at a time and an HTTP 200 OK status, update triggerState, and set the retry-after interval to 0 seconds.
Pomocí těchto kroků stroj ví, že jsou k dispozici další data a že by měl modul hned požádat o data z adresy URL v location hlavičce.These steps let the engine know that more data is available, and that the engine should immediately request the data from the URL in the location header.
Žádné souboryNo files Vrátí stav HTTP 202 ACCEPTED , neměňte triggerState a nastavte retry-after interval na 15 sekund.Return an HTTP 202 ACCEPTED status, don't change triggerState, and set the retry-after interval to 15 seconds.

Tip

Ukázkový vzor triggeru cyklického dotazování najdete v ukázce tohoto kontroleru triggeru cyklického dotazování v GitHubu.For an example polling trigger pattern, review this poll trigger controller sample in GitHub.

Vyčkejte a poslouchejte nová data nebo události pomocí vzoru triggeru Webhooku.Wait and listen for new data or events with the webhook trigger pattern

Trigger Webhooku je Trigger push , který čeká a naslouchá novým datům nebo událostem na koncovém bodu služby.A webhook trigger is a push trigger that waits and listens for new data or events at your service endpoint. Pokud nová data nebo událost splní zadanou podmínku, Trigger se aktivuje a vytvoří instanci aplikace logiky, která pak data zpracuje jako vstup.If new data or an event meets the specified condition, the trigger fires and creates a logic app instance, which then processes the data as input. Triggery Webhooku fungují podobně jako Akce Webhooku dříve popsané v tomto tématu a jsou nastavené subscribe pomocí unsubscribe koncových bodů a.Webhook triggers act much like the webhook actions previously described in this topic, and are set up with subscribe and unsubscribe endpoints.

  • subscribe koncový bod: když do aplikace logiky přidáte a uložíte Trigger Webhooku, modul Logic Apps volá subscribe koncový bod.subscribe endpoint: When you add and save a webhook trigger in your logic app, the Logic Apps engine calls the subscribe endpoint. Tento krok způsobí, že aplikace logiky vytvoří adresu URL zpětného volání, které vaše rozhraní API ukládá.This step causes the logic app to create a callback URL that your API stores. Pokud jsou k dispozici nová data nebo událost, která splňuje zadanou podmínku, rozhraní API se vrátí pomocí HTTP POST na adresu URL.When there's new data or an event that meets the specified condition, your API calls back with an HTTP POST to the URL. Datová část obsahu a hlavičky přecházejí jako vstup do aplikace logiky.The content payload and headers pass as input to the logic app.

  • unsubscribe koncový bod: Pokud se Trigger Webhooku nebo celá aplikace logiky odstraní, modul Logic Apps volá unsubscribe koncový bod.unsubscribe endpoint: If the webhook trigger or entire logic app is deleted, the Logic Apps engine calls the unsubscribe endpoint. Vaše rozhraní API pak může zrušit registraci adresy URL zpětného volání a v případě potřeby zastavit všechny procesy.Your API can then unregister the callback URL and stop any processes as necessary.

Vzor triggeru Webhooku

Návrhář aplikace logiky v současné době nepodporuje zjišťování koncových bodů webhooků prostřednictvím Swagger.Currently, the Logic App Designer doesn't support discovering webhook endpoints through Swagger. Pro tento model proto musíte přidat Trigger Webhooku a zadat adresu URL, záhlaví a text vaší žádosti.So for this pattern, you have to add a Webhook trigger and specify the URL, headers, and body for your request. Viz také Trigger HTTPWebhook.See also HTTPWebhook trigger. Příklad vzoru Webhooku najdete v ukázce tohoto kontroleru triggeru triggeru Webhooku na GitHubu.For an example webhook pattern, review this webhook trigger controller sample in GitHub.

Tady jsou některé další tipy a poznámky:Here are some other tips and notes:

  • Chcete-li předat adresu URL zpětného volání, můžete v případě @listCallbackUrl() potřeby použít funkci pracovního postupu v libovolném z předchozích polí.To pass in the callback URL, you can use the @listCallbackUrl() workflow function in any of the previous fields as necessary.

  • Aby se zabránilo tomu, že se stejná data zpracovávají víckrát, měla by aktivační událost vyčistit data, která již byla přečtena a předána do aplikace logiky.To prevent processing the same data multiple times, your trigger should clean up data that was already read and passed to the logic app.

  • Pokud vlastníte aplikaci logiky i předplacenou službu, nemusíte volat unsubscribe koncový bod po volání adresy URL zpětného volání.If you own both the logic app and the subscribed service, you don't have to call the unsubscribe endpoint after the callback URL is called. V opačném případě musí modul runtime Logic Apps volat unsubscribe koncový bod k signalizaci, že nejsou očekávána žádná další volání a aby bylo možné vyčistit prostředky na straně serveru.Otherwise, the Logic Apps runtime needs to call the unsubscribe endpoint to signal that no more calls are expected and to allow for resource clean up on the server side.

Vylepšení zabezpečení volání rozhraní API z Logic AppsImprove security for calls to your APIs from logic apps

Po vytvoření vlastních rozhraní API nastavte ověřování pro vaše rozhraní API, abyste je mohli bezpečně volat z Logic Apps.After creating your custom APIs, set up authentication for your APIs so that you can call them securely from logic apps. Naučte se zlepšovat zabezpečení volání vlastních rozhraní API z Logic Apps.Learn how to improve security for calls to custom APIs from logic apps.

Nasazení a volání rozhraní APIDeploy and call your APIs

Po nastavení ověřování nastavte nasazení pro vaše rozhraní API.After you set up authentication, set up deployment for your APIs. Naučte se nasazovat a volat vlastní rozhraní API z Logic Apps.Learn how to deploy and call custom APIs from logic apps.

Publikování vlastních rozhraní API do AzurePublish custom APIs to Azure

Aby vaše vlastní rozhraní API byla dostupná pro ostatní Logic Apps uživatele v Azure, musíte přidat zabezpečení a zaregistrovat je jako konektory aplikace logiky.To make your custom APIs available for other Logic Apps users in Azure, you must add security and register them as Logic App connectors. Další informace najdete v tématu Přehled vlastních konektorů.For more information, see Custom connectors overview.

Pokud chcete, aby vaše vlastní rozhraní API byla dostupná pro všechny uživatele v Logic Apps, automatizaci a aplikacích Microsoft Power, musíte přidat zabezpečení, zaregistrovat vaše rozhraní API jako konektory aplikací logiky a pojmenovat konektory pro program Microsoft Azure Certified.To make your custom APIs available to all users in Logic Apps, Power Automate, and Microsoft Power Apps, you must add security, register your APIs as Logic App connectors, and nominate your connectors for the Microsoft Azure Certified program.

Získání podporyGet support

Další krokyNext steps