Creare API personalizzate che è possibile chiamare da flussi di lavoro di app per la logicaCreate custom APIs that you can call from logic app workflows

Sebbene le app per la logica di Azure offrano più di 100 connettori incorporati che è possibile usare nei flussi di lavoro delle app per la logica, si consiglia di chiamare le API, i sistemi e i servizi che non sono disponibili come connettori.Although Azure Logic Apps offers 100+ built-in connectors that you can use in logic app workflows, you might want to call APIs, systems, and services that aren't available as connectors. È possibile creare API personalizzate che specificano le azioni e i trigger da usare in app per la logica.You can create your own APIs that provide actions and triggers to use in logic apps. Di seguito vengono indicati altri motivi per cui è utile creare API personalizzate da chiamare da flussi di lavoro di app per la logica:Here are other reasons why you might want to create your own APIs that you can call from logic app workflows:

  • Estendere gli attuali flussi di lavoro di integrazione del sistema e integrazione dei dati.Extend your current system integration and data integration workflows.
  • Aiutare i clienti a usare il servizio per gestire attività professionali o personali.Help customers use your service to manage professional or personal tasks.
  • Espandere la copertura, l'individuabilità e l'uso del servizio.Expand the reach, discoverability, and use for your service.

In pratica, i connettori sono API Web che usano REST per le interfacce collegabili, il formato dei metadati Swagger per la documentazione e JSON come formato di scambio di dati.Basically, connectors are web APIs that use REST for pluggable interfaces, Swagger metadata format for documentation, and JSON as their data exchange format. Poiché i connettori sono API REST che comunicano attraverso endpoint HTTP, è possibile usare qualsiasi linguaggio, ad esempio .NET, Java o Node.js, per la creazione dei connettori.Because connectors are REST APIs that communicate through HTTP endpoints, you can use any language, like .NET, Java, or Node.js, for building connectors. È anche possibile ospitare le API nel servizio app di Azure, una soluzione PaaS (platform-as-a-service) che offre uno dei modi più efficaci, semplici e scalabili per ospitare le 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.

Per consentire alle API personalizzate di funzionare con le app per la logica, l'API può rendere disponibili azioni che eseguono attività specifiche nei flussi di lavoro delle app per la logica.For custom APIs to work with logic apps, your API can provide actions that perform specific tasks in logic app workflows. L'API può anche agire come un trigger che avvia un flusso di lavoro di app per la logica quando nuovi dati o un evento soddisfano una condizione specificata.Your API can also act as a trigger that starts a logic app workflow when new data or an event meets a specified condition. Questo argomento descrive i modelli comuni che è possibile seguire per la creazione di azioni e trigger nell'API, in base al comportamento previsto per l'API.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.

È possibile ospitare le API in Servizio app di Azure, una soluzione PaaS (Platform-as-a-Service, piattaforma distribuita come servizio) che offre hosting di API semplice e altamente scalabile.You can host your APIs on Azure App Service, a platform-as-a-service (PaaS) offering that provides highly scalable, easy API hosting.

Suggerimento

Benché sia possibile distribuire le API come app Web, è consigliabile distribuirle come app per le API, in modo da semplificare le attività durante la compilazione, l'hosting e l'utilizzo delle API nel cloud e in locale.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. Non è necessario modificare alcun codice nelle API, è sufficiente implementare il codice a un'app per le API.You don't have to change any code in your APIs -- just deploy your code to an API app. Ad esempio, è possibile compilare app per le API create con questi linguaggi:For example, learn how to build API apps created with these languages:

Per gli esempi di app per le API compilate per le app per la logica, visitare il repository GitHub o il blog sulle app per la logica di Azure.For API App samples built for logic apps, visit the Azure Logic Apps GitHub repository or blog.

Differenza tra le API e i connettori personalizzatiHow do custom APIs differ from custom connectors?

Le API personalizzate e i connettori personalizzati sono API Web che usano REST per le interfacce modulari, il formato dei metadati Swagger per la documentazione e JSON come formato di scambio di dati.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. Poiché questi connettori e API sono API REST che comunicano tramite endpoint HTTP, è possibile usare qualsiasi linguaggio, tra cui .NET, Java o Node.js, per la compilazione di API e connettori personalizzati.And because these APIs and connectors are REST APIs that communicate through HTTP endpoints, you can use any language, like .NET, Java, or Node.js, for building custom APIs and connectors.

Le API personalizzate consentono di chiamare API che non sono connettori e forniscono gli endpoint che è possibile chiamare con HTTP + Swagger, Gestione API di Azure o Servizi app.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. I connettori personalizzati funzionano come le API personalizzate, ma hanno anche questi attributi:Custom connectors work like custom APIs but also have these attributes:

  • Sono registrati come risorse connettore di App per la logica in Azure.Registered as Logic Apps Connector resources in Azure.
  • Vengono visualizzati con icone insieme ai connettori gestiti da Microsoft in Progettazione app per la logica.Appear with icons alongside Microsoft-managed connectors in the Logic Apps Designer.
  • Sono disponibili solo per gli autori dei connettori e degli utenti di app per la logica che hanno lo stesso tenant di Azure Active Directory e la stessa sottoscrizione di Azure nell'area in cui vengono distribuite le app per la logica.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.

È anche possibile designare connettori registrati per la certificazione Microsoft.You can also nominate registered connectors for Microsoft certification. Questo processo verifica che i connettori registrati soddisfino i criteri per l'uso pubblico e rende i connettori disponibili per gli utenti in Microsoft Flow e Microsoft PowerApps.This process verifies that registered connectors meet the criteria for public use and makes those connectors available for users in Microsoft Flow and Microsoft PowerApps.

Per altre informazioni sui connettori personalizzati, vedereFor more information about custom connectors, see

Strumenti utiliHelpful tools

Un'API personalizzata funziona meglio con le app per la logica quando l'API include anche un documento Swagger che descrive le operazioni e i parametri dell'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. Molte librerie, ad esempio Swashbuckle, sono in grado di generare automaticamente il file Swagger.Many libraries, like Swashbuckle, can automatically generate the Swagger file for you. Per annotare il file Swagger per i nomi visualizzati, i tipi di proprietà e così via, è anche possibile usare TRex in modo che il file Swagger funzioni bene con le app per la logica.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.

Modelli di azioneAction patterns

Affinché le app per la logica eseguano le attività, l'API personalizzata deve specificare delle azioni.For logic apps to perform tasks, your custom API should provide actions. Ogni operazione dell'API è mappata a un'azione.Each operation in your API maps to an action. Un'azione di base è un controller che accetta le richieste HTTP e restituisce risposte HTTP.A basic action is a controller that accepts HTTP requests and returns HTTP responses. Un'app per la logica, ad esempio, invia una richiesta HTTP all'app Web o all'app per le API.So for example, a logic app sends an HTTP request to your web app or API app. L'app restituisce una risposta HTTP, insieme a contenuto che l'app per la logica è in grado di elaborare.Your app then returns an HTTP response, along with content that the logic app can process.

Per un'azione standard, è possibile scrivere un metodo di richiesta HTTP nell'API e descrivere tale metodo in un file Swagger.For a standard action, you can write an HTTP request method in your API and describe that method in a Swagger file. È quindi possibile chiamare l'API direttamente con un'azione HTTP o un'azione HTTP + Swagger.You can then call your API directly with an HTTP action or an HTTP + Swagger action. Per impostazione predefinita, le risposte devono essere restituite entro il limite di timeout della richiesta.By default, responses must be returned within the request timeout limit.

Modello di azione standard

Per fare in modo che un'app per la logica resti in attesa mentre l'API termina le attività con tempi di esecuzione più lunghi, l'API può seguire il modello di polling asincrono o il modello webhook asincrono descritto in questo argomento.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. Per un'analogia che consente di visualizzare i diversi comportamenti di questi modelli, si immagini la procedura necessaria per ordinare una torta personalizzata a un panificio.For an analogy that helps you visualize these patterns' different behaviors, imagine the process for ordering a custom cake from a bakery. Il modello di polling rispecchia il comportamento in cui si chiama il panificio ogni 20 minuti per verificare se la torta è pronta.The polling pattern mirrors the behavior where you call the bakery every 20 minutes to check whether the cake is ready. Il modello webhook rispecchia il comportamento in cui il panificio chiede al cliente il numero di telefono in modo da poterlo chiamare quando la torta è pronta.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.

Per gli esempi, visitare il repository GitHub per le app per la logica.For samples, visit the Logic Apps GitHub repository. Vedere anche le informazioni sulla misurazione dell'utilizzo per le azioni.Also, learn more about usage metering for actions.

Eseguire attività a esecuzione prolungata con il modello di azione di pollingPerform long-running tasks with the polling action pattern

Per fare in modo che l'API esegua attività che possono avere una durata superiore al limite di timeout della richiesta, è possibile usare il modello di polling asincrono.To have your API perform tasks that could run longer than the request timeout limit, you can use the asynchronous polling pattern. Questo modello consente all'API di funzionare in un thread separato, ma mantiene una connessione attiva al motore App per la logica.This pattern has your API do work in a separate thread, but keep an active connection to the Logic Apps engine. In questo modo, l'app per la logica non raggiunge il timeout né continua con il passaggio successivo del flusso di lavoro prima che termini l'attività dell'API.That way, the logic app does not time out or continue with the next step in the workflow before your API finishes working.

Di seguito è illustrato il modello generale:Here's the general pattern:

  1. Verificare che il motore "sappia" che l'API ha accettato la richiesta e ha iniziato a lavorare.Make sure that the engine knows that your API accepted the request and started working.
  2. Quando il motore effettua le richieste successive dello stato del processo, indicare al motore quando l'API termina l'attività.When the engine makes subsequent requests for job status, let the engine know when your API finishes the task.
  3. Restituire i dati pertinenti al motore in modo che il flusso di lavoro dell'app per la logica possa continuare.Return relevant data to the engine so that the logic app workflow can continue.

Applicare ora la stessa analogia del panificio al modello di polling e immaginare di chiamare un panificio e ordinare una torta personalizzata da consegnare.Now apply the previous bakery analogy to the polling pattern, and imagine that you call a bakery and order a custom cake for delivery. Il processo di preparazione della torta richiede tempo e non si vuole attendere al telefono mentre il panificio è al lavoro sulla torta.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. Il panificio conferma l'ordine e chiede di chiamare ogni 20 minuti per sapere qual è lo stato della torta.The bakery confirms your order and has you call every 20 minutes for the cake's status. Dopo 20 minuti, si chiama il panificio ma dicono che la torta non è pronta e che è necessario chiamare dopo altri 20 minuti.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. Questo andare avanti e indietro continua fino a quando si telefona e il panificio dice che l'ordine è pronto e consegna la torta.This back-and-forth process continues until you call, and the bakery tells you that your order is ready and delivers your cake.

Questo scenario si può mappare al modello di polling.So let's map this polling pattern back. Il panificio rappresenta l'API personalizzata, mentre il cliente che acquista la torta rappresenta il motore App per la logica.The bakery represents your custom API, while you, the cake customer, represent the Logic Apps engine. Quando il motore chiama l'API con una richiesta, l'API conferma la richiesta e risponde con l'intervallo di tempo quando il motore è in grado di controllare lo stato del processo.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. Il motore continua a verificare lo stato del processo finché l'API risponde indicando che il processo è completato e restituisce i dati all'app per la logica, che quindi continua il flusso di lavoro.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.

Modello di azione di polling

Questi sono i passaggi specifici che l'API deve seguire, descritti dalla prospettiva dell'API:Here are the specific steps for your API to follow, described from the API's perspective:

  1. Quando l'API riceve una richiesta HTTP per avviare il lavoro, restituisce immediatamente una risposta HTTP 202 ACCEPTED con l'intestazione location descritta più avanti in questo passaggio.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. Questa risposta consente al motore App per la logica di sapere che l'API ha ricevuto la richiesta, ha accettato il payload della richiesta (input dati) e sta elaborando.This response lets the Logic Apps engine know that your API got the request, accepted the request payload (data input), and is now processing.

    La risposta 202 ACCEPTED deve includere queste intestazioni:The 202 ACCEPTED response should include these headers:

    • Obbligatoria: un'intestazione location che specifica il percorso assoluto a un URL in cui il motore App per la logica può controllare lo stato del processo dell'APIRequired: A location header that specifies the absolute path to a URL where the Logic Apps engine can check your API's job status

    • Facoltativa: un'intestazione retry-after che specifica il numero di secondi che il motore deve attendere prima di controllare l'URL location per lo stato del processo.Optional: A retry-after header that specifies the number of seconds that the engine should wait before checking the location URL for job status.

      Per impostazione predefinita, il motore esegue il controllo ogni 20 secondi.By default, the engine checks every 20 seconds. Per specificare un intervallo diverso, includere l'intestazione retry-after e il numero di secondi fino al polling successivo.To specify a different interval, include the retry-after header and the number of seconds until the next poll.

  2. Trascorso il tempo specificato, il motore App per la logica esegue il polling dell'URL location per controllare lo stato del processo.After the specified time passes, the Logic Apps engine polls the location URL to check job status. L'API deve eseguire questi controlli e restituire queste risposte:Your API should perform these checks and return these responses:

    • Se il processo viene eseguito, restituisce una risposta HTTP 200 OK insieme al payload di risposta (input per il passaggio successivo).If the job is done, return an HTTP 200 OK response, along with the response payload (input for the next step).

    • Se il processo è ancora in fase di elaborazione, restituisce un'altra risposta HTTP 202 ACCEPTED con le stesse intestazioni della risposta originale.If the job is still processing, return another HTTP 202 ACCEPTED response, but with the same headers as the original response.

Quando l'API segue questo modello, non è necessario eseguire alcuna operazione nella definizione del flusso di lavoro dell'app per la logica per continuare la verifica dello stato del processo.When your API follows this pattern, you don't have to do anything in the logic app workflow definition to continue checking job status. Quando il motore riceve una risposta HTTP 202 ACCEPTED e un'intestazione location valida, il motore rispetta il modello asincrono e controlla l'intestazione location fino a quando l'API restituisce una risposta non 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.

Suggerimento

Per un esempio di modello asincrono, esaminare questo esempio di risposta del controller asincrono in GitHub.For an example asynchronous pattern, review this asynchronous controller response sample in GitHub.

Eseguire attività a esecuzione prolungata con il modello di azione webhookPerform long-running tasks with the webhook action pattern

In alternativa, è possibile usare il modello webhook per le attività di lunga durata e l'elaborazione asincrona.As an alternative, you can use the webhook pattern for long-running tasks and asynchronous processing. Questo modello usa la pausa dell'app per la logica e attende un "callback" dall'API per terminare l'elaborazione prima di continuare il flusso di lavoro.This pattern has the logic app pause and wait for a "callback" from your API to finish processing before continuing workflow. Questo callback è un HTTP POST che invia un messaggio a un URL quando si verifica un evento.This callback is an HTTP POST that sends a message to a URL when an event happens.

Applicare ora la stessa analogia del panificio al modello webhook e immaginare di chiamare un panificio e ordinare una torta personalizzata da consegnare.Now apply the previous bakery analogy to the webhook pattern, and imagine that you call a bakery and order a custom cake for delivery. Il processo di preparazione della torta richiede tempo e non si vuole attendere al telefono mentre il panificio è al lavoro sulla torta.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. Il panificio conferma l'ordine, ma questa volta il cliente lascia il proprio numero di telefono in modo che possano chiamarlo quando la torta è pronta.The bakery confirms your order, but this time, you give them your phone number so they can call you when the cake is done. Questa volta il panificio avvisa quando l'ordine è pronto e consegna la torta.This time, the bakery tells you when your order is ready and delivers your cake.

In base all'analogia con il modello webhook, il panificio rappresenta l'API personalizzata, mentre il cliente che acquista la torta rappresenta il motore App per la logica.When we map this webhook pattern back, the bakery represents your custom API, while you, the cake customer, represent the Logic Apps engine. Il motore chiama l'API con una richiesta e include un URL di "callback".The engine calls your API with a request and includes a "callback" URL. Quando il processo viene eseguito, l'API usa l'URL per notificare al motore e restituire i dati all'app per la logica, che quindi continua il flusso di lavoro.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.

Per questo modello, configurare due endpoint sul controller: subscribe e unsubscribeFor this pattern, set up two endpoints on your controller: subscribe and unsubscribe

  • Endpoint subscribe: quando l'esecuzione raggiunge l'azione dell'API nel flusso di lavoro, il motore App per la logica chiama l'endpoint subscribe.subscribe endpoint: When execution reaches your API's action in the workflow, the Logic Apps engine calls the subscribe endpoint. Questo passaggio fa sì che l'app per la logica crei un URL di callback, che viene archiviato dall'API, e quindi attenda il callback dell'API quando il lavoro viene completato.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. L'API quindi richiama con un HTTP POST all'URL e passa eventuali contenuti e intestazioni come input all'app per la logica.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.

  • Endpoint unsubscribe: se l'esecuzione dell'app per la logica è stata annullata, il motore App per la logica chiama l'endpoint unsubscribe.unsubscribe endpoint: If the logic app run is canceled, the Logic Apps engine calls the unsubscribe endpoint. L'API può quindi annullare la registrazione dell'URL di callback e arrestare i processi in base alle esigenze.Your API can then unregister the callback URL and stop any processes as necessary.

Modello di azione webhook

Nota

Attualmente, Progettazione app per la logica non supporta l'individuazione di endpoint webhook con Swagger.Currently, the Logic App Designer doesn't support discovering webhook endpoints through Swagger. Per questo modello è quindi necessario aggiungere un'azione webhook e specificare l'URL, le intestazioni e il corpo per la richiesta.So for this pattern, you have to add a Webhook action and specify the URL, headers, and body for your request. Vedere anche Azioni e trigger del flusso di lavoro.See also Workflow actions and triggers. Per passare l'URL di callback, è possibile usare la funzione di flusso di lavoro @listCallbackUrl() in uno qualsiasi dei campi precedenti in base alle necessità.To pass in the callback URL, you can use the @listCallbackUrl() workflow function in any of the previous fields as necessary.

Suggerimento

Per un esempio di modello webhook, esaminare questo esempio di trigger webhook in GitHub.For an example webhook pattern, review this webhook trigger sample in GitHub.

Modelli di triggerTrigger patterns

L'API personalizzata può anche agire come un trigger che avvia un'app per la logica quando nuovi dati o un evento soddisfano una condizione specificata.Your custom API can act as a trigger that starts a logic app when new data or an event meets a specified condition. Questo trigger può verificare regolarmente, o attendere e restare in ascolto, la presenza di nuovi dati o eventi presso l'endpoint servizio.This trigger can either check regularly, or wait and listen, for new data or events at your service endpoint. Se nuovi dati o eventi soddisfano la condizione specificata, il trigger viene attivato e avvia l'app per la logica, che è in ascolto di quel trigger.If new data or an event meets the specified condition, the trigger fires and starts the logic app, which is listening to that trigger. Per avviare l'app per la logica in questo modo, l'API può seguire il modello di trigger di polling o trigger webhook.To start logic apps this way, your API can follow the polling trigger or the webhook trigger pattern. Questi modelli sono simili alle loro controparti per le azioni di polling e le azioni webhook.These patterns are similar to their counterparts for polling actions and webhook actions. Vedere anche le informazioni sulla misurazione dell'utilizzo per i trigger.Also, learn more about usage metering for triggers.

Verificare la presenza di nuovi dati o eventi regolarmente con il modello di trigger di pollingCheck for new data or events regularly with the polling trigger pattern

Un trigger di polling funziona in modo molto simile all'azione di polling descritta in precedenza in questo argomento.A polling trigger acts much like the polling action previously described in this topic. Il motore App per la logica periodicamente chiama l'endpoint di trigger e verifica la presenza di nuovi dati o eventi.The Logic Apps engine periodically calls and checks the trigger endpoint for new data or events. Se il motore rileva nuovi dati o eventi che soddisfano la condizione specificata, il trigger viene attivato.If the engine finds new data or an event that meets your specified condition, the trigger fires. Quindi, il motore crea un'istanza di app per la logica che elabora i dati come input.Then, the engine creates a logic app instance that processes the data as input.

Modello di trigger di polling

Nota

Ogni richiesta di polling viene considerata un'esecuzione di azione, anche quando non viene creata alcuna istanza di app per la logica.Each polling request counts as an action execution, even when no logic app instance is created. Per evitare che gli stessi dati vengano elaborati più volte, il trigger deve pulire i dati che sono già stati letti e passati all'app per la logica.To prevent processing the same data multiple times, your trigger should clean up data that was already read and passed to the logic app.

Di seguito sono riportati i passaggi specifici per un trigger di polling, descritti dalla prospettiva dell'API:Here are specific steps for a polling trigger, described from the API's perspective:

Sono stati rilevati nuovi dati o eventi?Found new data or event? Risposta dell'APIAPI response
TrovatoFound Restituire uno stato HTTP 200 OK con il payload di risposta (input per il passaggio successivo).Return an HTTP 200 OK status with the response payload (input for next step).
Questa risposta crea un'istanza di app per la logica e avvia il flusso di lavoro.This response creates a logic app instance and starts the workflow.
Non trovatoNot found Restituire uno stato HTTP 202 ACCEPTED con un'intestazione location e un'intestazione retry-after.Return an HTTP 202 ACCEPTED status with a location header and a retry-after header.
Per i trigger, l'intestazione location deve contenere anche un parametro di query triggerState, che in genere è "timestamp".For triggers, the location header should also contain a triggerState query parameter, which is usually a "timestamp." L'API è in grado di usare questo identificatore per verificare quando è stata attivata l'app per la logica per l'ultima volta.Your API can use this identifier to track the last time that the logic app was triggered.

Ad esempio, per verificare periodicamente se nel servizio sono presenti nuovi file, si può creare un trigger di polling con questi comportamenti:For example, to periodically check your service for new files, you might build a polling trigger that has these behaviors:

La richiesta include triggerState?Request includes triggerState? Risposta dell'APIAPI response
NoNo Restituire uno stato HTTP 202 ACCEPTED oltre a un'intestazione location con triggerState impostato sull'ora corrente e l'intervallo retry-after su 15 secondi.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.
Yes Verificare se nel servizio sono presenti file aggiunti dopo DateTime per triggerState.Check your service for files added after the DateTime for triggerState.
Numero di file trovatiNumber of files found Risposta dell'APIAPI response
Singolo fileSingle file Restituire uno stato HTTP 200 OK e il payload del contenuto, aggiornare triggerState a DateTime per il file restituito e impostare l'intervallo retry-after su 15 secondi.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.
File multipliMultiple files Restituire un file alla volta e uno stato HTTP 200 OK, aggiornare triggerState e impostare l'intervallo retry-after su 0 secondi.Return one file at a time and an HTTP 200 OK status, update triggerState, and set the retry-after interval to 0 seconds.
Questi passaggi consentono al motore di sapere che sono disponibili più dati e che il motore deve richiedere immediatamente i dati dall'URL nell'intestazione location.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.
Nessun fileNo files Restituire uno stato HTTP 202 ACCEPTED, non modificare triggerState e impostare l'intervallo retry-after su 15 secondi.Return an HTTP 202 ACCEPTED status, don't change triggerState, and set the retry-after interval to 15 seconds.

Suggerimento

Per un esempio di modello di trigger di polling, vedere questo esempio di controller di trigger di polling in GitHub.For an example polling trigger pattern, review this poll trigger controller sample in GitHub.

Attendere e restare in ascolto di nuovi dati o eventi con il modello di trigger webhookWait and listen for new data or events with the webhook trigger pattern

Un trigger webhook è un trigger di push che attende e resta in ascolto di nuovi dati o eventi in corrispondenza dell'endpoint servizio.A webhook trigger is a push trigger that waits and listens for new data or events at your service endpoint. Se i nuovi dati o un evento soddisfano la condizione specificata, il trigger viene attivato e crea un'istanza di app per la logica, che quindi elabora i dati come input.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. I trigger webhook funzionano in modo molto simile alle azioni webhook descritte in precedenza in questo argomento e sono impostati con gli endpoint subscribe e unsubscribe.Webhook triggers act much like the webhook actions previously described in this topic, and are set up with subscribe and unsubscribe endpoints.

  • Endpoint subscribe: quando si aggiunge e si salva un trigger webhook nell'app per la logica, il motore App per la logica chiama l'endpoint subscribe.subscribe endpoint: When you add and save a webhook trigger in your logic app, the Logic Apps engine calls the subscribe endpoint. Questo passaggio fa sì che l'app per la logica crei un URL di callback che archivia l'API.This step causes the logic app to create a callback URL that your API stores. Quando sono presenti nuovi dati, o un evento, che soddisfano la condizione specificata o nuovi dati, l'API richiama con un HTTP POST all'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. Il payload di contenuto e le intestazioni vengono passati come input all'app per la logica.The content payload and headers pass as input to the logic app.

  • Endpoint unsubscribe: se si elimina il trigger webhook o l'intera app per la logica, il motore App per la logica chiama l'endpoint unsubscribe.unsubscribe endpoint: If the webhook trigger or entire logic app is deleted, the Logic Apps engine calls the unsubscribe endpoint. L'API può quindi annullare la registrazione dell'URL di callback e arrestare i processi in base alle esigenze.Your API can then unregister the callback URL and stop any processes as necessary.

Modello di trigger webhook

Nota

Attualmente, Progettazione app per la logica non supporta l'individuazione di endpoint webhook con Swagger.Currently, the Logic App Designer doesn't support discovering webhook endpoints through Swagger. Per questo modello è quindi necessario aggiungere un trigger webhook e specificare l'URL, le intestazioni e il corpo per la richiesta.So for this pattern, you have to add a Webhook trigger and specify the URL, headers, and body for your request. Vedere anche Trigger HTTPWebhook.See also HTTPWebhook trigger. Per passare l'URL di callback, è possibile usare la funzione di flusso di lavoro @listCallbackUrl() in uno qualsiasi dei campi precedenti in base alle necessità.To pass in the callback URL, you can use the @listCallbackUrl() workflow function in any of the previous fields as necessary.

Per evitare che gli stessi dati vengano elaborati più volte, il trigger deve pulire i dati che sono già stati letti e passati all'app per la logica.To prevent processing the same data multiple times, your trigger should clean up data that was already read and passed to the logic app.

Suggerimento

Per un esempio di modello webhook, esaminare questo esempio di controller di trigger webhook in GitHub.For an example webhook pattern, review this webhook trigger controller sample in GitHub.

Proteggere le chiamate alle API da app per la logicaSecure calls to your APIs from logic apps

Dopo aver creato le API personalizzate, configurare l'autenticazione per le API in modo che possano essere chiamate in modo sicuro da app per la logica.After creating your custom APIs, set up authentication for your APIs so that you can call them securely from logic apps. Vedere Come proteggere le chiamate alle API personalizzate da app per la logica.Learn how to secure calls to custom APIs from logic apps.

Distribuire e chiamare le APIDeploy and call your APIs

Dopo aver configurato l'autenticazione, configurare la distribuzione per le API.After you set up authentication, set up deployment for your APIs. Vedere Come distribuire e chiamare API personalizzate da app per la logica.Learn how to deploy and call custom APIs from logic apps.

Pubblicare API personalizzate in AzurePublish custom APIs to Azure

Per rendere disponibili le API personalizzate per altri utenti di App per la logica in Azure, è necessario incrementare la sicurezza e registrarle come connettori di App per la logica.To make your custom APIs available for other Logic Apps users in Azure, you must add security and register them as Logic App connectors. Per altre informazioni, vedere Panoramica dei connettori personalizzati.For more information, see Custom connectors overview.

Per rendere le API personalizzate disponibili a tutti gli utenti in App per la logica, Microsoft Flow e Microsoft PowerApps, è necessario incrementare la sicurezza, registrare le API come connettori di App per la logica e designare i connettori per il programma Microsoft Azure Certified.To make your custom APIs available to all users in Logic Apps, Microsoft Flow, and Microsoft PowerApps, you must add security, register your APIs as Logic App connectors, and nominate your connectors for the Microsoft Azure Certified program.

SupportoGet support

Passaggi successiviNext steps