Creare flussi di lavoro di app per la logica Standard con Visual Studio Code

2025-06-09

Si applica a: Azure Logic Apps (Standard)

Questa guida illustra come creare in locale un flusso di lavoro di app per la logica Standard di esempio che è possibile eseguire in App per la logica di Azure a tenant singolo quando si usa Visual Studio Code con l'estensione App per la logica di Azure (Standard).

In questa guida si crea un'area di lavoro e un progetto di app per la logica Standard, si compila il flusso di lavoro e si distribuisce il progetto come risorsa dell'app per la logica Standard in Azure in cui il flusso di lavoro può essere eseguito in App per la logica a tenant singolo o nell'ambiente del servizio app v3 (solo piani di servizio app basati su Windows). È anche possibile distribuire ed eseguire il flusso di lavoro ovunque Kubernetes possa essere eseguito, ad esempio in Azure, in Azure Kubernetes Service, in locale o anche presso altri provider di servizi cloud, grazie al runtime containerizzato per App per la logica di Azure (Standard).

Ecco solo alcuni vantaggi offerti dall'app per la logica Standard:

È possibile creare, eseguire il debug, eseguire e testare flussi di lavoro in locale nell'ambiente di sviluppo di Visual Studio Code locale. Sia il portale di Azure che Visual Studio Code offrono la possibilità di compilare, eseguire e distribuire flussi di lavoro e risorse dell'app per la logica Standard. Tuttavia, con Visual Studio Code, è possibile eseguire queste attività in locale.
Il progetto di app per la logica Standard può includere flussi di lavoro con stato e senza stato.
I flussi di lavoro nella stessa risorsa dell'app per la logica Standard e nel tenant vengono eseguiti nello stesso processo del runtime di App per la logica di Azure (Standard), in modo da condividere le stesse risorse e offrire prestazioni migliori.

Il flusso di lavoro di esempio di questa guida inizia inizialmente con un trigger di richiesta seguito da un'azione di Office 365 Outlook . Il trigger Request crea un endpoint chiamabile per il flusso di lavoro e attende una richiesta HTTPS in ingresso da qualsiasi chiamante. Quando il trigger riceve una richiesta e viene attivata, l'azione successiva viene eseguita inviando un messaggio di posta elettronica al destinatario specificato insieme agli output dei trigger selezionati. Successivamente, è possibile aggiungere un'azione Response che restituisce una risposta ed elabora i dati al chiamante.

Screenshot che mostra Visual Studio Code, area di lavoro per le app per la logica, progetto e flusso di lavoro.

Anche se l'esempio di questa guida è basato sul cloud e include solo alcuni passaggi, è possibile creare flussi di lavoro usando operazioni da 1.400 connettori che consentono di integrare una vasta gamma di servizi, sistemi, app e dati in ambienti cloud, locali e ibridi.

Man mano che prosegui con la guida, completi i compiti di alto livello seguenti:

Creare un'area di lavoro dell'app per la logica Standard e un progetto con un flusso di lavoro con stato vuoto.
Aggiungere un trigger e azioni al flusso di lavoro.
Eseguire, effettuare il debug e testare localmente.
Esaminare la cronologia di esecuzione del flusso di lavoro.
Trovare i dettagli del nome di dominio per l'accesso al firewall.
Abilitare la cronologia di esecuzione per i flussi di lavoro senza stato.
Eseguire la distribuzione in Azure, che include facoltativamente l'abilitazione di Application Insights.
Abilitare o aprire Application Insights dopo la distribuzione.
Gestisci la risorsa dell'app logica distribuita in Visual Studio Code e nel portale di Azure.

Prerequisiti

Requisiti di accesso e connettività

Se si prevede di creare ed eseguire flussi di lavoro in locale usando solo operazioni predefinite, che vengono eseguite in modo nativo nel runtime di App per la logica di Azure (Standard), non sono necessari i requisiti di accesso e connettività in questa sezione. Tuttavia, per gli scenari seguenti, è necessario soddisfare questi requisiti:

Distribuire l'app logica in Azure tramite Visual Studio Code.
Creare un flusso di lavoro che usa le operazioni del connettore gestito eseguite in Azure globale.
Accedere alle risorse e ai flussi di lavoro esistenti dell'app per la logica Standard in Azure o ad altre risorse di Azure distribuite.

Questi requisiti includono gli elementi seguenti:

Account e sottoscrizione di Azure. Se non si ha una sottoscrizione, è possibile iscriversi per creare un account Azure gratuito.
Accesso a Internet in modo da poter scaricare l'estensione necessaria, connettersi da Visual Studio Code all'account Azure, testare i flussi di lavoro che includono operazioni del connettore gestito e distribuirlo in Azure da Visual Studio Code.
Per creare lo stesso flusso di lavoro di esempio in questa guida, è necessario un account di posta elettronica di Office 365 Outlook che usa un account microsoft aziendale o dell'istituto di istruzione per accedere.

Se non si ha un account di Office 365, è possibile usare qualsiasi altra azione disponibile in grado di inviare messaggi dall'account di posta elettronica, ad esempio Outlook.com. Se si sceglie un connettore di posta elettronica diverso, ad esempio Outlook.com, è comunque possibile seguire l'esempio e i passaggi generali sono gli stessi. Tuttavia, l'esperienza e le opzioni potrebbero differire in alcuni modi. Ad esempio, con il connettore Outlook.com, usare l'account Microsoft personale per accedere.

Attrezzi

Scaricare e installare Visual Studio Code, gratuito.
Scaricare e installare l'estensione App per la logica di Azure (Standard) per Visual Studio Code seguendo questa procedura:
1. Nella barra attività in Visual Studio Code selezionare Estensioni. (Tastiera: premere CTRL+MAIUSC+X)
2. Nella casella di ricerca delle estensioni immettere app per la logica di Azure standard. Nell'elenco dei risultati selezionare App per la logica di Azure (Standard)>Installa.
  
  L'estensione scarica e installa tutte le dipendenze necessarie e le versioni corrette per i framework seguenti:
  - Strumenti Core di Azure Functions
  - .NET SDK
  - Node.js
  Al termine dell'installazione, l'estensione viene visualizzata nell'elenco Estensioni: Installate.
3. Ricaricare o riavviare Visual Studio Code per assicurarsi che l'estensione e tutte le dipendenze vengano installate correttamente.
4. Per verificare che l'estensione e tutte le dipendenze siano installate correttamente, vedere Controllare l'installazione dell'estensione.
Attualmente, è possibile avere entrambe le estensioni a consumo (multi-tenant) e standard (a tenant singolo) installate contemporaneamente. Le esperienze di sviluppo differiscono l'una dall'altra in alcuni modi, ma l'abbonamento ad Azure può includere sia i tipi di risorse delle app logiche Standard che a consumo. In Visual Studio Code il riquadro di Azure mostra tutte le app per la logica distribuite e ospitate di Azure nella sottoscrizione di Azure, ma organizza le app nei modi seguenti:
- Sezione Risorse : tutte le app per la logica standard nella sottoscrizione.
- Sezione App per la logica (consumo): tutte le app per la logica a consumo nella sottoscrizione.
Per eseguire in locale trigger e azioni basati su webhook, ad esempio il trigger webhook HTTP predefinito, è necessario configurare l'inoltro per l'URL di callback in Visual Studio Code.
Per abilitare la registrazione diagnostica e la traccia con Application Insights per la tua app per la logica Standard, puoi completare questa attività sia durante la distribuzione della tua app per la logica sia successivamente. È necessario avere una risorsa di Application Insights, ma è possibile creare questa risorsa in anticipo, durante la distribuzione o dopo la distribuzione.
Installare o usare uno strumento che può inviare richieste HTTP per testare il flusso di lavoro di esempio, ad esempio:
Attenzione

Per scenari in cui sono presenti dati sensibili, ad esempio credenziali, segreti, token di accesso, chiavi API e altre informazioni simili, assicurarsi di usare uno strumento che protegge i dati con le funzionalità di sicurezza necessarie. Lo strumento deve funzionare offline o in locale e non richiede l'accesso a un account online o sincronizzare i dati nel cloud. Quando si usa uno strumento con queste caratteristiche, si riduce il rischio di esporre i dati sensibili al pubblico.

Controllare l'installazione dell'estensione

Per assicurarsi che l'estensione e tutte le dipendenze siano installate correttamente, ricaricare o riavviare Visual Studio Code.
Verificare che Visual Studio Code trovi e installi automaticamente gli aggiornamenti delle estensioni in modo che tutte le estensioni ottengano gli aggiornamenti più recenti. In caso contrario, è necessario disinstallare manualmente la versione obsoleta e installare la versione più recente.
1. Nel menu File, passare a Preferenze>Impostazioni.
2. Nella scheda Utente, passare a Funzionalità>Estensioni.
3. Verificare che l'opzione Aggiornamenti automatici sia selezionata e che l'opzione Aggiornamento automatico sia impostata su Tutte le estensioni.
Verificare che l'impostazione Azure Logic Apps Standard: Project Runtime sia impostata sulla versione corretta:
1. Nella scheda Utente selezionare >estensioni>App per la logica di Azure (standard).
2. Assicurarsi che Project Runtime sia impostato sulla versione ~4, ad esempio:
  
  Annotazioni
  
  Questa versione è necessaria per usare le azioni operazioni codice inline.

Connettersi all'account di Azure

Se non si è già connessi all'account Azure, seguire questa procedura per connettersi:

Nella barra delle attività di Visual Studio Code selezionare l'icona di Azure per aprire il riquadro di Azure .
Nel riquadro Azure, in Risorse selezionare Accedi ad Azure. Quando viene visualizzata la pagina di autenticazione di Visual Studio Code, accedere con l'account Azure.

Dopo l'accesso, nel riquadro di Azure vengono visualizzate le sottoscrizioni di Azure associate all'account Azure. Se le sottoscrizioni previste non vengono visualizzate o si vuole che il riquadro mostri solo sottoscrizioni specifiche, seguire questa procedura:
1. Nell'elenco delle sottoscrizioni spostare il puntatore accanto alla prima sottoscrizione fino a quando non viene visualizzato il pulsante Seleziona sottoscrizioni (icona filtro). Seleziona l'icona di filtro.
  
  In alternativa, nella barra di stato di Visual Studio Code selezionare l'account Azure.
2. Quando viene visualizzato l'elenco delle sottoscrizioni aggiornate, selezionare le sottoscrizioni desiderate e assicurarsi di selezionare OK.

Creare un'area di lavoro locale

Un progetto di app per la logica richiede sempre un'area di lavoro. Prima di creare l'app per la logica, è quindi necessario creare un'area di lavoro in cui si mantiene il progetto dell'app per la logica. Successivamente si utilizzerà quest'area di lavoro e questo progetto per gestire, eseguire e distribuire la tua app logica da Visual Studio Code al tuo ambiente di distribuzione. Il progetto sottostante è simile a un progetto di Funzioni di Azure, noto anche come progetto di app per le funzioni.

Nel computer creare una cartella locale vuota da usare in un secondo momento per l'area di lavoro e il progetto.

In questo esempio viene creata una cartella denominata fabrikam-workflows.
In Visual Studio Code chiudere tutte le cartelle aperte.
Nella barra degli strumenti della sezione Area di lavoro della finestra di Azure selezionare Crea nuova area di lavoro per le app per la logica dal menu App per la logica di Azure.

Se Windows Defender Firewall richiede di concedere l'accesso alla rete per Code.exe, ovvero Visual Studio Code e per func.exe, che è il Funzioni di Azure Core Tools, selezionare >.
Nella finestra Seleziona cartella, vai al percorso in cui hai creato la tua cartella, seleziona la cartella e scegli Seleziona (non selezionare due volte la cartella).

Sulla barra degli strumenti di Visual Studio Code viene visualizzato un prompt per assegnare un nome all'area di lavoro.
Per Specificare un nome dell'area di lavoro, immettere il nome dell'area di lavoro da usare.

Questo esempio usa Fabrikam-Workflows.

Quindi, crea il tuo progetto di app logica.

Creare il progetto dell'applicazione logica

Dopo aver creato l'area di lavoro necessaria, seguire le istruzioni per creare il progetto.

Per il modello di progetto selezionare App per la logica. Immettere un nome di progetto da usare.

Questo esempio usa Fabrikam-Workflows.
Per il modello di flusso di lavoro, selezionare Flusso di lavoro con stato o Flusso di lavoro senza stato, in base allo scenario in uso. Immettere un nome del flusso di lavoro da usare.

In questo esempio viene selezionato Il flusso di lavoro con stato, che archivia la cronologia del flusso di lavoro, gli input e gli output e usa Stateful-Workflow come nome.

I flussi di lavoro senza stato non archiviano questi dati e attualmente supportano solo le azioni del connettore gestito, non i trigger. Sebbene sia possibile abilitare i connettori in Azure per il flusso di lavoro senza stato, la finestra di progettazione non mostra alcun trigger del connettore gestito da selezionare.

Annotazioni

Se viene visualizzato un errore denominato azureLogicAppsStandard.createNewProject con il messaggio di errore Non è possibile scrivere nelle impostazioni dell'area di lavoro perché azureFunctions.suppressProject non è una configurazione registrata, provare a reinstallare l'estensione Funzioni di Azure per Visual Studio Code, direttamente da Visual Studio Marketplace o dall'interno di Visual Studio Code.
Scegliere ora se aprire il progetto nella finestra corrente di Visual Studio Code o in una nuova finestra. Selezionare Apri nella finestra corrente o Apri nella nuova finestra, in base alle preferenze.

Viene aperto il riquadro Esplora risorse per visualizzare l'area di lavoro, il progetto e il file workflow.json aperto automaticamente. Questo file esiste nella cartella denominata Stateful-Workflow e archivia la definizione JSON sottostante per il flusso di lavoro compilato nella finestra di progettazione. Per informazioni sulla struttura del progetto, vedere Struttura del progetto dell'app per la logica standard.

Viene anche visualizzato un prompt per abilitare i connettori "condivisi" ospitati in Azure multi-tenant, ad esempio:
Per abilitare tutti i connettori "condivisi" gestiti eseguiti in Azure multi-tenant in modo da poter visualizzarli e scegliere di usarli nel flusso di lavoro, selezionare Usa connettori da Azure.

Annotazioni

Se non si seleziona questa opzione e successivamente si tenta di aggiungere un'operazione del connettore gestito quando si compila il flusso di lavoro, non è possibile continuare perché il riquadro informazioni sull'operazione mostra un cerchio rotante che non si arresta.
Per il gruppo di risorse di Azure selezionare Crea nuovo gruppo di risorse. Immettere il nome del gruppo di risorse da usare.

Questo esempio usa Fabrikam-Workflows-RG.
Per la sottoscrizione, selezionate la sottoscrizione di Azure da usare con il vostro progetto di logic app.
Per la località in cui creare il gruppo e le risorse, selezionare l'area di Azure.

Questo esempio usa Stati Uniti centro-occidentali.

Se il progetto richiede un'altra configurazione per lo sviluppo o necessita di elementi di supporto per compilare il flusso di lavoro, vedere gli scenari e le attività correlate seguenti:

Sceneggiatura	Attività
Eseguire localmente trigger o azioni basati su webhook.	Configurare l'inoltro per gli URL di callback del webhook.
Configurare la cronologia dell'esecuzione del flusso di lavoro stateless.	Abilitare la cronologia di esecuzione per i flussi di lavoro senza stato.
Aggiungere elementi e dipendenze, ad esempio mappe, schemi e assemblaggi.	Aggiungere elementi e dipendenze.
Usare un progetto basato su NuGet (.NET)	Convertire un progetto di bundle basato su estensione (Node.js) in un progetto basato su pacchetti NuGet (.NET). Nota: per convertire un progetto basato su bundle di estensione (Node.js) creato prima dell'esistenza del supporto degli assembly, vedere anche Eseguire la migrazione di progetti basati su pacchetti NuGet per usare gli assembly nella cartella lib.
Crea i tuoi connettori integrati.	1. Convertire un progetto basato su bundle di estensione (Node.js) in un progetto basato su pacchetti NuGet (.NET). 2. Abilitare la creazione di connettori predefiniti.

Aprire ora la finestra di progettazione del flusso di lavoro.

Aprire la finestra di progettazione del flusso di lavoro

Quando il progetto si apre nel riquadro Esplora, apri la finestra di progettazione in modo da poter creare il flusso di lavoro.

Dal menu di scelta rapida del file workflow.json, selezionare Apri progettista.

Screenshot che mostra il riquadro di Esplora risorse, il menu di scelta rapida del file workflow.json e l'opzione Apri Progettazione selezionata.

Annotazioni

Dopo aver selezionato questa opzione, è possibile che venga visualizzato il messaggio che l'avvio potrebbe richiedere alcuni secondi a causa dell'avvio dell'API in fase di progettazione del flusso di lavoro. È possibile ignorare questo messaggio o selezionare OK.

Visual Studio Code apre la finestra di progettazione del flusso di lavoro e mostra il prompt Aggiungi un trigger , ad esempio:

Screenshot che mostra il progettista con un flusso di lavoro vuoto.

Annotazioni

Se la finestra di progettazione non viene aperta, vedere la sezione relativa alla risoluzione dei problemi, progettazione non viene aperta.

Aggiungere quindi un trigger e azioni per creare il flusso di lavoro.

Aggiungere un trigger e un'azione

Per creare il flusso di lavoro, avviare il flusso di lavoro con un trigger e quindi aggiungere inizialmente una singola azione. In questo modo, è possibile testare il flusso di lavoro prima di aggiungere l'azione successiva. Il flusso di lavoro di esempio usa i trigger e le azioni seguenti, noti collettivamente come operazioni:

Connettore o gruppo di operazioni	Nome operazione	Tipo di operazione	Descrizione
Richiedi	Quando viene ricevuta una richiesta HTTP	Trigger (predefinito)	Crea un URL di un endpoint nel flusso di lavoro per ricevere chiamate o richieste in ingresso da altri servizi o flussi di lavoro di app logica. Per altre informazioni, vedere Ricevere e rispondere alle chiamate HTTP in ingresso ai flussi di lavoro.
Office 365 Outlook	Invia un messaggio e-mail	Azione (gestita)	Inviare un messaggio di posta elettronica usando un account di Office 365 Outlook. Per seguire la procedura descritta in questa guida, è necessario un account di posta elettronica di Office 365 Outlook. Per ulteriori informazioni, vedere Connettersi a Outlook di Office 365 dalle Azure Logic Apps. Nota: se si dispone di un account di posta elettronica supportato da un connettore diverso, è possibile usare tale connettore, ma l'esperienza utente del connettore è diversa dai passaggi descritti in questo esempio.
Richiedi	risposta	Azione (predefinita)	Inviare una risposta e restituire i dati al chiamante. Per altre informazioni, vedere Aggiungere un'azione Di risposta.

Aggiungere il trigger Request

Nella finestra di progettazione del flusso di lavoro selezionare Aggiungi un trigger, se non è già selezionato.

Viene aperto il riquadro Aggiungi un trigger e viene visualizzata una raccolta in cui è possibile selezionare i connettori e i gruppi di operazioni disponibili, ad esempio:
Nel riquadro Aggiungi un triggerseguire questa procedura generale per aggiungere il trigger di richiesta denominato Quando viene ricevuta una richiesta HTTP.

Nell'esempio seguente viene selezionata l'opzione predefinita in modo che vengano visualizzati solo i trigger predefiniti:

Quando il trigger viene visualizzato nella finestra di progettazione, viene aperto il riquadro informazioni sul trigger e visualizza i parametri, le impostazioni e altre attività correlate del trigger.

Annotazioni

Se il riquadro informazioni sul trigger non viene visualizzato, assicurarsi che il trigger sia selezionato nella finestra di progettazione.
Salvare il flusso di lavoro. Sulla barra degli strumenti della finestra di progettazione seleziona Salva.

Aggiungere l'azione di Office 365 Outlook

Nella finestra di progettazione, sotto il trigger Richiesta, seguire questi passaggi generali per aggiungere l'azione di Office 365 Outlook denominata Invia un messaggio di posta elettronica (V2).

Se l'azione non viene visualizzata nei risultati iniziali, accanto al nome del connettore selezionare Visualizza altro, ad esempio:
Quando viene visualizzato il riquadro di autenticazione dell'azione, selezionare Accedi per creare una connessione all'account di posta elettronica.
Seguire le istruzioni successive per autenticare le credenziali, consentire l'accesso e consentire la restituzione a Visual Studio Code.

Annotazioni

Se è trascorso troppo tempo prima di completare le richieste, il processo di autenticazione raggiunge il timeout e non riesce. In questo caso, tornare alla finestra di progettazione e ripetere l'accesso per creare la connessione.
1. Quando viene visualizzata la richiesta di autenticazione Microsoft, selezionare l'account utente per Office 365 Outlook. Nella pagina richiesta di conferma visualizzata selezionare Consenti l'accesso.
2. Quando App per la logica di Azure richiede di aprire un collegamento a Visual Studio Code, selezionare Apri.
3. Quando Visual Studio Code richiede di aprire l'estensione Strumenti di Microsoft Azure, selezionare Apri.
Dopo che Visual Studio Code ha creato la connessione, alcuni connettori mostrano il messaggio Che la connessione sarà valida solo per <n> giorni. Questo limite di tempo si applica solo alla durata durante la creazione del flusso di lavoro dell'app per la logica in Visual Studio Code. Dopo la distribuzione, questo limite non viene più applicato perché il flusso di lavoro può eseguire l'autenticazione in fase di esecuzione usando l’identità gestita assegnata dal sistema automaticamente. Questa identità gestita è diversa dalle credenziali di autenticazione o dalla stringa di connessione usata quando si crea una connessione. Se si disabilita questa identità gestita assegnata dal sistema, le connessioni non funzioneranno nel runtime.

Nel riquadro Invia informazioni di posta elettronica visualizzato nella scheda Parametri specificare le informazioni necessarie per l'azione.

Annotazioni

Se il riquadro delle informazioni sull'azione non è stato aperto automaticamente, selezionare l'azione Invia un messaggio di posta elettronica nella finestra di progettazione.

Proprietà	Obbligatorio	Valore	Descrizione
a	Sì	< indirizzo-posta-elettronica>	Destinatario del messaggio di posta elettronica, che può essere l'indirizzo di posta elettronica a scopo di test. Questo esempio usa l'indirizzo di posta elettronica fittizio, sophia.owen@fabrikam.com.
Argomento	Sì	Un messaggio di posta elettronica dal flusso di lavoro di esempio	L'oggetto del messaggio di posta elettronica
Corpo	Sì	Un saluto dal flusso di lavoro di esempio	Contenuto del corpo del messaggio di posta elettronica

Per esempio:

Screenshot che mostra informazioni per l'azione di Office 365 Outlook denominata Invia un messaggio di posta elettronica.

Salvare il flusso di lavoro. Nella finestra di progettazione selezionare Salva.

Struttura del progetto dell'app per la logica standard

In Visual Studio Code il progetto di app per la logica ha uno dei tipi seguenti:

Basato su bundle di estensioni (Node.js), ovvero il tipo predefinito
Basato su pacchetti NuGet (.NET), che è possibile convertire dal tipo predefinito

In base a questi tipi, il progetto potrebbe includere cartelle o file leggermente diversi. Ad esempio, un progetto basato su pacchetto NuGet ha una cartella .bin che contiene pacchetti e altri file di libreria. Un progetto basato su bundle di estensioni non include questa cartella .bin .

Alcuni scenari richiedono l'esecuzione di un progetto basato su pacchetti NuGet per l'esecuzione dell'app, ad esempio quando si vogliono sviluppare ed eseguire operazioni predefinite personalizzate. Per altre informazioni sulla conversione del progetto per l'uso di NuGet, vedere Abilitare la creazione di connettori predefiniti.

Il progetto predefinito basato su bundle di estensioni ha una cartella e una struttura di file simile all'esempio seguente:

MyWorkspaceName
| MyBundleBasedLogicAppProjectName
  || .vscode
  || Artifacts
     ||| Maps 
         |||| MapName1
         |||| ...
     ||| Rules
     ||| Schemas
         |||| SchemaName1
         |||| ...
  || lib
     ||| builtinOperationSdks
         |||| JAR
         |||| net472
     ||| custom
  || WorkflowName1
     ||| workflow.json
     ||| ...
  || WorkflowName2
     ||| workflow.json
     ||| ...
  || workflow-designtime
     ||| host.json
     ||| local.settings.json
  || .funcignore
  || connections.json
  || host.json
  || local.settings.json

A livello radice del progetto, è possibile trovare le cartelle e i file seguenti insieme ad altri elementi:

Nome	File o cartella	Descrizione
.vscode	Cartella	Contiene file di impostazioni correlati a Visual Studio Code, ad esempio file extensions.json, launch.json, settings.jsone tasks.json.
Manufatti	Cartella	Contiene elementi dell'account di integrazione definiti e usati nei flussi di lavoro che supportano scenari business-to-business (B2B). Ad esempio, la struttura di esempio include le cartelle seguenti: - Mappe: contiene le mappe da usare per le operazioni di trasformazione XML. - Schemi: contiene schemi da usare per le operazioni di convalida XML. - Regole: artefatti relativi alle regole aziendali nei progetti di motori basati su regole.
movimento di liberazione	Cartella	Contiene assembly supportati che l'app per la logica può usare o fare riferimento. È possibile caricare questi assembly nel progetto in Visual Studio Code, ma è necessario aggiungerli a cartelle specifiche nel progetto. Ad esempio, questa cartella include le cartelle seguenti: - builtinOperationSdks: contiene rispettivamente le cartelle JAR e net472 per gli assembly Java e .NET Framework. - custom: Contiene assembly personalizzati di .NET Framework. Per altre informazioni sui tipi di assembly supportati e sulla posizione in cui inserirli nel progetto, vedere Aggiungere assembly al progetto.
*< WorkflowName>*	Cartella	Per ogni flusso di lavoro, la cartella <WorkflowName> include un file workflow.json che contiene la definizione JSON sottostante del flusso di lavoro.
fase di progettazione del flusso di lavoro	Cartella	Contiene i file di impostazioni correlati all'ambiente di sviluppo.
.funcignore	Documento	Contiene informazioni correlate all' Azure Functions Core Tools.
connections.json	Documento	Contiene i metadati, gli endpoint e le chiavi per tutte le connessioni gestite e le funzioni di Azure usate dai flussi di lavoro. Importante: per usare connessioni e funzioni diverse per ogni ambiente, assicurarsi di parametrizzare questo file connections.json e aggiornare gli endpoint.
host.json	Documento	Contiene impostazioni e valori di configurazione specifici del runtime, ad esempio i limiti predefiniti per la piattaforma app per la logica di Azure a tenant singolo, le app per la logica, i flussi di lavoro, i trigger e le azioni. A livello radice del progetto dell'app per la logica, il file di metadati host.json contiene le impostazioni di configurazione e i valori predefiniti che tutti i flussi di lavoro nella stessa app per la logica usano durante l'esecuzione, sia in locale sia in Azure. Per informazioni di riferimento, vedere Modificare le impostazioni dell'app e le impostazioni host. Nota: quando si crea l'app per la logica, Visual Studio Code crea un file di backup *host.snapshot..json nel contenitore di archiviazione. Se si elimina l'app per la logica, questo file di backup non viene eliminato. Se si crea un'altra app per la logica con lo stesso nome, viene creato un altro file di snapshot. È possibile avere fino a 10 snapshot per la stessa app per la logica. Se si supera questo limite, verrà visualizzato l'errore seguente: `Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))`** Per risolvere questo errore, eliminare i file di snapshot aggiuntivi dal contenitore di archiviazione.
local.settings.json	Documento	Contiene impostazioni dell'app, stringhe di connessione e altre impostazioni usate dai flussi di lavoro durante l'esecuzione in locale. Queste impostazioni e valori si applicano solo quando si eseguono i progetti nell'ambiente di sviluppo locale. Durante la distribuzione in Azure, il file e le impostazioni vengono ignorati e non sono inclusi nella distribuzione. Questo file archivia le impostazioni e i valori come variabili di ambiente locali usate dagli strumenti di sviluppo locali per i `appSettings` valori. È possibile chiamare e fare riferimento a queste variabili di ambiente sia in fase di runtime che in fase di distribuzione usando le impostazioni e i parametri dell’app. Importante: il file local.settings.json può contenere segreti, quindi assicurarsi di escludere anche questo file dal controllo del codice sorgente del progetto. Questo file contiene anche le impostazioni necessarie affinché l'app logica funzioni correttamente. Per informazioni di riferimento, vedere Modificare le impostazioni dell'app e le impostazioni host.

Altre attività di configurazione dello sviluppo

Dopo aver creato il progetto, potrebbero essere presenti altre attività di installazione per supportare scenari di sviluppo locali specifici per la compilazione, l'esecuzione e la distribuzione di app per la logica Standard con Visual Studio Code. Le sezioni seguenti descrivono le attività per questi scenari.

Abilitare webhook in esecuzione in locale

Un'operazione webhook è un trigger o un'azione del flusso di lavoro che attende che si verifichi un evento prima che l'operazione possa essere eseguita. In particolare, l'operazione webhook attende l'arrivo di una richiesta HTTPS da un servizio chiamante o da un flusso di lavoro prima che l'operazione possa continuare. Ad esempio, i webhook includono operazioni come il trigger Request e il trigger HTTP + Webhook .

Nel portale di Azure, il runtime di Azure Logic Apps iscrive automaticamente il webhook al servizio chiamante o al flusso di lavoro. Il runtime registra un URL di richiamo per il webhook con il servizio chiamante o il flusso di lavoro. Il webhook attende quindi che il chiamante invii la richiesta usando l'URL di callback.

In Visual Studio Code, tuttavia, è necessario completare alcune attività di configurazione per il corretto funzionamento delle operazioni webhook. In questo scenario, l'URL di callback usa il server localhost (http://localhost:7071/...), che è privato, quindi il chiamante non può inviare direttamente una richiesta tramite Internet a questo URL.

Per le operazioni webhook nei flussi di lavoro in esecuzione in locale, è necessario configurare un URL pubblico che espone il server localhost e inoltra in modo sicuro le chiamate dal chiamante all'URL di callback. È possibile usare un servizio di inoltro e uno strumento come ngrok, che apre un tunnel HTTP alla porta localhost oppure è possibile usare uno strumento equivalente.

Configurare l'inoltro delle chiamate con ngrok

Passare al sito Web ngrok. Iscriversi per ottenere un nuovo account o accedere al proprio account, se ne ha già uno.
Ottenere il token di autenticazione personale, al quale il client ngrok deve connettersi ed autenticare l'accesso all'account.
1. Per trovare la pagina del token di autenticazione, nel menu del dashboard dell'account espandere Autenticazionee selezionare Authtoken.
2. Dalla casella di Authtoken copiare il token in una posizione sicura.
Dalla pagina di download ngrok o dashboard dell'accountscaricare la versione ngrok desiderata ed estrarre il file ZIP.

Per altre informazioni, vedere Passaggio 1: Decomprimere per installare.
Nel computer aprire lo strumento del prompt dei comandi. Passare al percorso in cui si dispone del file ngrok.exe.
Connettere il client ngrok all'account ngrok eseguendo il comando seguente:

ngrok authtoken <your-authentication-token>

Per altre informazioni, vedere Passaggio 2: connettere l'account.
Aprire il tunnel HTTP sulla porta localhost 7071 eseguendo il comando seguente:

ngrok http 7071

Per altre informazioni, vedere Passaggio 3: attivarlo.
Nell'output trovare la riga seguente:

http://<domain>.ngrok.io -> http://localhost:7071
Copiare e salvare l'URL con questo formato: http://<domain>.ngrok.io

Configurare l'URL di inoltro nelle impostazioni dell'app

Sulla finestra di progettazione di Visual Studio Code, aggiungi l'operazione webhook che vuoi utilizzare nel tuo flusso di lavoro.

Questo esempio continua con il trigger HTTP + Webhook.
Quando viene visualizzata la richiesta per il percorso dell'endpoint host, immettere l'URL di inoltro (reindirizzamento) creato in precedenza.

Annotazioni

Se la richiesta viene ignorata, viene visualizzato un avviso che indica che è necessario specificare l'URL di inoltro, quindi selezionare Configurae immettere l'URL. Al termine di questo passaggio, il prompt non verrà visualizzato per le successive operazioni webhook che è possibile aggiungere.

Per visualizzare la richiesta, a livello radice del progetto aprire il menu di scelta rapida del file local.settings.json e selezionare Configura endpoint di reindirizzamento webhook. Viene ora visualizzato il prompt in modo da poter fornire l'URL di inoltro.

Visual Studio Code aggiunge l'URL di inoltro al file local.settings.json nella cartella radice del progetto. Nell'oggetto Values viene visualizzata la proprietà denominata Workflows.WebhookRedirectHostUri e viene impostata sull'URL di inoltro, ad esempio:
```
{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "dotnet",
      "FUNCTIONS_V2_COMPATIBILITY_MODE": "true",
      <...>
      "Workflows.WebhookRedirectHostUri": "http://xxxXXXXxxxXXX.ngrok.io",
      <...>
   }
}
```
Per altre informazioni su queste impostazioni dell'app, vedere Modificare le impostazioni dell'app e le impostazioni host per le app per la logica Standard.

La prima volta che si avvia una sessione di debug locale o si esegue il flusso di lavoro senza eseguire il debug, il runtime di App per la logica di Azure registra il flusso di lavoro con il chiamante e sottoscrive l'endpoint del chiamante che notifica le operazioni webhook. Alla successiva esecuzione del flusso di lavoro, il runtime non registrerà o riscriverà perché la registrazione della sottoscrizione esiste già nella risorsa di archiviazione locale.

Quando si arresta la sessione di debug per un flusso di lavoro che usa operazioni webhook in locale, le registrazioni di sottoscrizione esistenti non vengono eliminate. Per annullare la registrazione, è necessario rimuovere o eliminare manualmente le registrazioni della sottoscrizione.

Annotazioni

Dopo l'avvio dell'esecuzione del flusso di lavoro, la finestra del terminale potrebbe visualizzare errori come nell'esempio seguente:

message='Http request failed with unhandled exception of type 'InvalidOperationException' and message: 'System.InvalidOperationException: Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.'

In questo caso, aprire il file local.settings.json nella cartella radice del progetto e assicurarsi che la proprietà sia impostata su true:

"FUNCTIONS_V2_COMPATIBILITY_MODE": "true"

Abilitare la cronologia di esecuzione per i flussi di lavoro senza stato

Per eseguire il debug di un flusso di lavoro senza stato più facilmente, è possibile abilitare la cronologia di esecuzione per tale flusso di lavoro e quindi disabilitare la cronologia di esecuzione al termine. Seguire questa procedura per Visual Studio Code o se si lavora nel portale di Azure, vedere Creare flussi di lavoro basati su tenant singolo nel portale di Azure.

Nel progetto di Visual Studio Code, a livello di cartella radice, aprire il file local.settings.json.

Aggiungere la proprietà Workflows.<workflow-name>.operationOptions e impostare il valore su WithStatelessRunHistory, ad esempio:

Finestre

{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "dotnet",
      "Workflows.<workflow-name>.OperationOptions": "WithStatelessRunHistory"
   }
}

macOS o Linux

{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "DefaultEndpointsProtocol=https;AccountName=fabrikamstorageacct; \
          AccountKey=<access-key>;EndpointSuffix=core.windows.net",
      "FUNCTIONS_WORKER_RUNTIME": "dotnet",
      "Workflows.<workflow-name>.OperationOptions": "WithStatelessRunHistory"
   }
}

Nella cartella di progetto denominata workflow-designtime aprire il file local.settings.json e apportare la stessa modifica.
Per disabilitare la cronologia di esecuzione al termine, impostare la Workflows.<workflow-name>.OperationOptions proprietà su Noneo eliminare la proprietà e il relativo valore.

Aggiungere elementi e dipendenze al progetto

In scenari specifici, il flusso di lavoro può includere operazioni che richiedono dipendenze, ad esempio assembly o artefatti, ad esempio mappe, schemi o regole. In Visual Studio Code è possibile aggiungere questi elementi alle cartelle corrispondenti nel progetto, ad esempio:

Elemento	Tipo di file	Descrizione
Mappe	Xslt	Per altre informazioni, vedere Aggiungere mappe per le trasformazioni nei flussi di lavoro.
Schemi	Xsd	Per altre informazioni, vedere Aggiungere schemi per la convalida.
Regole	.xml	Per ulteriori informazioni, vedere Creare un progetto del motore delle regole di Azure Logic Apps.
Assemblaggi	- .dll (.NET Framework o .NET 8) - .jar (Java)	Una risorsa dell'app per la logica Standard può usare o fare riferimento a tipi specifici di assembly, che è possibile caricare nel progetto in Visual Studio Code. Tuttavia, è necessario aggiungerli a cartelle di progetto specifiche. Per altre informazioni, vedere Aggiungere assembly a cui si fa riferimento. Nota: se si dispone di un progetto di app per la logica basata su pacchetti NuGet (.NET) prima che gli assembly siano disponibili, vedere Eseguire la migrazione di progetti basati su pacchetti NuGet per usare gli assembly nella cartella lib.

Convertire il progetto in base al pacchetto NuGet (.NET)

Per impostazione predefinita, Visual Studio Code crea il progetto di app logica come progetto basato su bundle di estensioni (Node.js). Se è necessario un progetto basato su pacchetti NuGet (.NET), ad esempio per creare connettori predefiniti, è necessario convertire il progetto predefinito in un progetto basato su pacchetti NuGet (.NET).

Importante

Questa azione è un'operazione unidirezionale che non è possibile annullare.

Nel riquadro Explorer spostare il puntatore del mouse su qualsiasi area vuota sotto le cartelle e i file del progetto, aprire il menu di scelta rapida e selezionare Converti in progetto di app per la logica basata su NuGet.
Quando viene visualizzata la richiesta, confermare la conversione del progetto.

Eseguire la migrazione di progetti basati su pacchetti NuGet per usare gli assembly nella cartella "lib"

Importante

Questa attività è necessaria solo per i progetti di app per la logica basati su pacchetti NuGet (.NET) creati prima che il supporto degli assembly sia diventato disponibile.

Se è stato creato il progetto di app per la logica quando gli assembly non sono disponibili per i flussi di lavoro dell'app per la logica Standard, è possibile aggiungere le righe seguenti al file<nome progetto>con estensione csproj per lavorare con i progetti che usano assembly:

  <ItemGroup>
    <LibDirectory Include="$(MSBuildProjectDirectory)\lib\**\*"/>
  </ItemGroup>
  <Target Name="CopyDynamicLibraries" AfterTargets="_GenerateFunctionsExtensionsMetadataPostPublish">
    <Copy SourceFiles="@(LibDirectory)" DestinationFiles="@(LibDirectory->'$(MSBuildProjectDirectory)\$(PublishUrl)\lib\%(RecursiveDir)%(Filename)%(Extension)')"/>
  </Target>

Importante

Per un progetto eseguito in Linux o macOS, assicurarsi di aggiornare il separatore di directory. Esaminare ad esempio l'immagine seguente che mostra il codice precedente aggiunto al < file project-name.csproj>:

La schermata mostra gli assembly migrati e il codice aggiunto nel file CSPROJ.

Abilitare la creazione di connettori predefiniti

È possibile creare connettori predefiniti per qualsiasi servizio necessario usando il framework di estendibilità app per la logica di Azure a tenant singolo. Analogamente ai connettori predefiniti, ad esempio il bus di servizio di Azure e SQL Server, questi connettori offrono una velocità effettiva più elevata, una bassa latenza, una connettività locale e un'esecuzione nativa nello stesso processo del runtime di App per la logica di Azure a tenant singolo.

La funzionalità di creazione è attualmente disponibile solo in Visual Studio Code, ma non è abilitata per impostazione predefinita. Per creare questi connettori, effettuare le operazioni seguenti:

Se non l'hai già fatto, converte il tuo progetto basato su bundle di estensioni (Node.js) in un progetto basato su pacchetti NuGet (.NET).
Esaminare e seguire la procedura descritta nell'articolo App per la logica di Azure in esecuzione ovunque - Estendibilità del connettore predefinito.

Esegui, effettua il debug e testa i flussi di lavoro in locale

Le sezioni seguenti illustrano come impostare i punti di interruzione e avviare una sessione di debug per l'esecuzione e il test del flusso di lavoro in locale.

Impostare punti di interruzione per il debug

Prima di eseguire e testare il flusso di lavoro dell'app per la logica avviando una sessione di debug, è possibile impostare punti di interruzione all'interno del file workflow.json per ogni flusso di lavoro. Non sono necessarie altre configurazioni.

I punti di interruzione sono attualmente supportati solo per le azioni, non per i trigger. Ogni definizione di azione ha questi percorsi dei punti di interruzione:

Impostare il punto di interruzione iniziale nella riga che mostra il nome dell'azione. Quando questo punto di interruzione viene raggiunto durante la sessione di debug, è possibile esaminare gli input dell'azione prima che vengano valutati.
Impostare il punto di interruzione finale sulla riga che mostra la parentesi graffa di chiusura dell'azione (}). Quando questo punto di interruzione viene raggiunto durante la sessione di debug, è possibile esaminare i risultati dell'azioneprima che l'azione finisca l'esecuzione.

Per aggiungere un punto di interruzione, seguire questa procedura:

Aprire il file workflow.json per il flusso di lavoro di cui si vuole eseguire il debug.
Nella riga in cui si desidera impostare il punto di interruzione, nella colonna a sinistra selezionare all'interno di tale colonna. Per rimuovere il punto di interruzione, selezionarlo.

Quando si avvia la sessione di debug, la visualizzazione Esegui viene visualizzata sul lato sinistro della finestra del codice, mentre la barra degli strumenti Debug viene visualizzata nella parte superiore.

Annotazioni

Se la visualizzazione Esegui non viene visualizzata automaticamente, premere CTRL+MAIUSC+D.
Per esaminare le informazioni disponibili quando si raggiunge un punto di interruzione, nella visualizzazione Esegui esaminare il riquadro variabili.
Per continuare l'esecuzione del flusso di lavoro, sulla barra degli strumenti Debug selezionare Continua (pulsante Riproduci).

È possibile aggiungere e rimuovere punti di interruzione in qualsiasi momento durante l'esecuzione del flusso di lavoro. Tuttavia, se si aggiorna il file workflow.json dopo l'avvio dell'esecuzione, i punti di interruzione non vengono aggiornati automaticamente. Per aggiornare i punti di interruzione, riavviare l'app per la logica.

Per informazioni generali, vedere Punti di interruzione - Visual Studio Code.

Eseguire il debug e testare il flusso di lavoro

Per testare il flusso di lavoro, seguire questa procedura per eseguire una sessione di debug e trovare l'URL per l'endpoint creato dal trigger di richiesta . Questo URL è necessario per poter inviare successivamente una richiesta a tale endpoint.

Se si dispone di un flusso di lavoro senza stato, abilitare la cronologia di esecuzione per il flusso di lavoro per semplificare il debug.
Dal menu Esegui selezionare Avvia debug (F5).

Viene visualizzata la finestra terminale in modo da poter esaminare la sessione di debug.

Annotazioni

Se viene visualizzato l'errore, "Errore esistente dopo l'esecuzione di preLaunchTask 'generateDebugSymbols'", vedere la sezione relativa alla risoluzione dei problemi, La sessione di debug non si avvia.
Trova ora l'URL di callback per l'endpoint creato dal trigger Request.
1. Riaprire il riquadro Esplora risorse per visualizzare il progetto.
2. Dal menu di scelta rapida del file workflow.json selezionare Panoramica.
3. Copiare e salvare l'URL di callback, simile all'URL seguente per il trigger Quando viene ricevuta una richiesta HTTP in questo esempio:
  
  http://localhost:7071/api/<workflow-name>/triggers/manual/invoke?api-version=2020-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<shared-access-signature>
Per testare l'URL di callback e attivare il flusso di lavoro, inviare una richiesta HTTP all'URL, incluso il metodo previsto dal trigger, usando lo strumento di richiesta HTTP e le relative istruzioni.

Questo esempio usa il metodo GET con l'URL copiato, simile all'esempio seguente:

GET http://localhost:7071/api/Stateful-Workflow/triggers/manual/invoke?api-version=2020-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<shared-access-signature>

Quando il trigger viene attivato, il flusso di lavoro di esempio viene eseguito e invia un messaggio di posta elettronica simile a questo esempio:

In Visual Studio Code tornare alla pagina di panoramica del flusso di lavoro. In Cronologia di esecuzione, controlla lo stato del flusso di lavoro.

Suggerimento

Se lo stato dell'esecuzione non viene visualizzato, provare ad aggiornare la pagina di panoramica selezionando Aggiorna. Un'esecuzione non avviene per un trigger saltato a causa di criteri non soddisfatti o per assenza di dati.

Screenshot che mostra la pagina di panoramica del flusso di lavoro con stato di esecuzione e cronologia.

La tabella seguente illustra i possibili stati finali che ogni esecuzione del flusso di lavoro può avere e visualizzare in Visual Studio Code:

Stato esecuzione	Descrizione
interrotto	L'esecuzione è stata arrestata o non è stata completata a causa di problemi esterni, ad esempio un'interruzione del sistema o una sottoscrizione di Azure scaduta.
annullata	L'esecuzione è stata attivata e avviata ma ha ricevuto una richiesta di annullamento.
Non riuscito	Almeno un'azione nell'esecuzione non è riuscita. Nessuna azione successiva nel flusso di lavoro è stata configurata per gestire l'errore.
In esecuzione	L'esecuzione è stata attivata ed è in corso, ma questo stato può essere visualizzato anche per un'esecuzione limitata a causa di limiti di azione o del piano tariffario corrente. Suggerimento: se si configura la registrazione diagnostica, è possibile ottenere informazioni su tutti gli eventi di limitazione che si verificano.
Riuscito	Esecuzione completata. Se un'azione non è riuscita, un'azione successiva nel flusso di lavoro ha gestito tale errore.
Tempo scaduto	Timeout dell'esecuzione perché la durata corrente ha superato il limite di durata dell'esecuzione, controllato dall'impostazione denominata Conservazione cronologia di esecuzione in giorni. La durata di un'esecuzione viene calcolata usando l'ora di inizio dell'esecuzione e il limite di durata dell'esecuzione all'ora di inizio. Nota: se la durata dell'esecuzione supera anche il limite di conservazione della cronologia di esecuzione corrente, controllato anche dall'impostazione della conservazione della cronologia di esecuzione in giorni, l'esecuzione viene cancellata dalla cronologia di esecuzione da un processo di pulizia giornaliera. Indipendentemente dal timeout o dal completamento dell'esecuzione, il periodo di conservazione viene sempre calcolato usando l'ora di inizio dell'esecuzione e limite di conservazione corrente. Quindi, se si riduce il limite di durata per un'esecuzione in anteprima, si verifica il timeout. Tuttavia, l'esecuzione rimane o viene cancellata dalla cronologia di esecuzione in base al superamento del limite di conservazione della durata dell'esecuzione.
In attesa	L'esecuzione non è stata avviata o sospesa, ad esempio a causa di un'istanza del flusso di lavoro precedente ancora in esecuzione.

Per visualizzare lo stato, gli input e gli output di ogni passaggio per un'esecuzione del flusso di lavoro specifica, scegliere uno dei passaggi seguenti:

Nella colonna Identificatore selezionare l'ID di esecuzione del flusso di lavoro.
Accanto alla colonna Durata si apre il menu con i puntini di sospensione (...) per un'esecuzione del flusso di lavoro e si seleziona Mostra esecuzione, ad esempio:

Visual Studio Code apre la visualizzazione dei dettagli di esecuzione e mostra lo stato per ogni passaggio nel flusso di lavoro.

La screenshot mostra ogni fase dell'esecuzione del flusso di lavoro e il loro stato.

Annotazioni

Se un'esecuzione non è riuscita e un passaggio nella visualizzazione dettagli esecuzione mostra l'errore 400 Richiesta non valida, questo problema potrebbe derivare da un nome di trigger o un nome di azione più lungo che causa il superamento del limite di caratteri predefinito dell'URI (Uniform Resource Identifier) sottostante. Per altre informazioni, vedere "Richiesta non valida 400".

La tabella seguente illustra i possibili stati che ogni azione del flusso di lavoro può avere e visualizzare in Visual Studio Code:

Stato azione	Descrizione
interrotto	L'azione è stata arrestata o non è stata completata a causa di problemi esterni, ad esempio un'interruzione del sistema o una sottoscrizione di Azure scaduta.
annullata	L'azione è stata eseguita ma ha ricevuto una richiesta di annullamento.
Non riuscito	L'azione non è riuscita.
In esecuzione	L'azione è attualmente in esecuzione.
Ignorato	L'azione è stata ignorata perché l'azione immediatamente precedente non è riuscita. Un'azione ha una condizione `runAfter` che richiede che l'azione precedente venga completata correttamente prima che l'azione corrente possa essere eseguita.
Riuscito	L'azione è riuscita.
Operazione riuscita in più tentativi	L'azione ha avuto esito positivo ma solo dopo uno o più tentativi. Per esaminare la cronologia dei tentativi, nella visualizzazione dettagli cronologia di esecuzione selezionare l'azione in modo che sia possibile visualizzare gli input e gli output.
Tempo scaduto	L'azione è stata arrestata a causa del limite di timeout specificato dalle impostazioni dell'azione.
In attesa	Si applica a un'azione webhook in attesa di una richiesta in ingresso da un chiamante.

Per visualizzare gli input e gli output per ogni passaggio, selezionare il passaggio desiderato, ad esempio:

Per visualizzare gli input e gli output non elaborati, selezionare Mostra input non elaborati o Mostra output non elaborati.
Per arrestare la sessione di debug, nel menu Esegui selezionare Arresta debug (MAIUSC + F5).

Restituire una risposta

Quando si dispone di un flusso di lavoro che inizia con il trigger Quando viene ricevuta una richiesta HTTP, il flusso di lavoro può restituire una risposta al chiamante che ha inviato la richiesta iniziale usando l'azione Richiesta denominata Risposta.

Nella finestra di progettazione del flusso di lavoro, sotto l'azione Invia un messaggio di posta elettronica , seguire questa procedura generale per aggiungere l'azione Richiesta denominata Risposta.
Nel riquadro Informazioni dell'azione di risposta , nella scheda Parametri , specificare le informazioni necessarie per la risposta al chiamante.

In questo esempio viene restituito il valore del parametro Corpo, ovvero l'output dell'azione Invia un messaggio di posta elettronica.
1. Per il parametro Corpo, selezionare all'interno della casella di modifica e selezionare l'icona a forma di fulmine, che apre l'elenco di contenuto dinamico. Questo elenco mostra i valori di output disponibili del trigger e delle azioni precedenti nel flusso di lavoro.
2. Nell'elenco di contenuto dinamico, in Invia un messaggio di posta elettronicaselezionare Corpo.
  
  Al termine, la proprietà Corpo dell'azione di risposta è ora impostata sul valore di output Corpo dell'azione Invia un messaggio di posta elettronica, ad esempio:
Salvare il flusso di lavoro.

Ripeti il test del tuo flusso di lavoro

Per testare gli aggiornamenti, è possibile rieseguire il debugger e inviare un'altra richiesta che attiva il flusso di lavoro, analogamente ai passaggi descritti in Eseguire, eseguire il debug e testare i flussi di lavoro in locale.

Sulla barra degli strumenti di Visual Studio Code scegliere Avvia debug (F5) dal menu Esegui.
Nello strumento per la creazione e l'invio di richieste inviare un'altra richiesta per attivare il flusso di lavoro.
Nella pagina di panoramica del flusso di lavoro, sotto Cronologia delle esecuzioni, controlla lo stato per l'esecuzione più recente e apri la visualizzazione dei dettagli dell'esecuzione.

Ecco ad esempio lo stato dettagliato di un'esecuzione dopo l'aggiornamento del flusso di lavoro di esempio con l'azione Risposta .
Per arrestare la sessione di debug, nel menu Esegui selezionare Arresta debug (MAIUSC + F5).

Preparare la distribuzione

Prima di distribuire l'app per la logica Standard nel portale di Azure, esaminare questa sezione per eventuali operazioni di preparazione da eseguire.

Configurare l'accesso al firewall

Se l'ambiente ha requisiti di rete o firewall rigorosi che limitano il traffico, è necessario configurare le autorizzazioni per le connessioni create da connettori gestiti, ospitati e condivisi di Azure e usati nel flusso di lavoro.

Per trovare i nomi di dominio completi (FQDN) per queste connessioni, seguire questa procedura:

Nel progetto di logic app, apri il file local.settings.json.

Per ogni connessione creata, trovare la proprietà denominata <connection-name>-ConnectionRuntimeUrl, che usa la sintassi seguente:

"<connection-name>-ConnectionRuntimeUrl": <connection-runtime-URL>

Si supponga, ad esempio, di avere un file di esempiolocal.settings.json che contiene queste connessioni: una connessione a Office 365 e una connessione AS2. Queste connessioni usano i rispettivi valori di esempio seguenti per le <connection-name>-ConnectionRuntimeUrl proprietà:

Office 365: "office365-ConnectionRuntimeUrl": https://A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u.00.common.logic-<Azure-region>.azure-apihub.net/apim/office365/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1"
AS2: "as2-ConnectionRuntimeUrl": https://A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u.00.common.logic-<Azure-region>.azure-apihub.net/apim/as2/b1b1b1b1-cccc-dddd-eeee-f2f2f2f2f2f2

Il file di esempiolocal.settings.json è simile alla versione seguente:

{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "node",
      "APP_KIND": "workflowapp",
      "ProjectDirectoryPath": "c:\\Users\\<local-username>\\Desktop\\Visual Studio Code projects\\Azure Logic Apps\fabrikam-workflows\\Fabrikam-Workflows\\Fabrikam-Workflows",
      "WORKFLOWS_TENANT_ID": "<Microsoft-Entra-tenant-ID>",
      "WORKFLOWS_SUBSCRIPTION_ID": "<Azure-subscription-ID>",
      "WORKFLOWS_RESOURCE_GROUP_NAME": "Fabrikam-Workflows-RG",
      "WORKFLOWS_LOCATION_NAME": "westcentralus",
      "WORKFLOWS_MANAGEMENT_BASE_URI": "https://management.azure.com/",
      "as2-connectionKey": "<connection-key>",
      "as2-ConnectionRuntimeUrl": "https://A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u.00.common.logic-<Azure-region>.azure-apihub.net/apim/as2/b1b1b1b1-cccc-dddd-eeee-f2f2f2f2f2f2",
      "office365-connectionKey": "<connection-key>",
      "office365-ConnectionRuntimeUrl": "https://A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u.00.common.logic-<Azure-region>.azure-apihub.net/apim/office365/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1",
   }
}

Copiare e salvare questi URL del runtime di connessione in un punto sicuro in modo che sia possibile configurare il firewall con queste informazioni.
Quando si è pronti, configurare il firewall usando gli URL salvati. Per altre informazioni, consultare la documentazione seguente:
- Panoramica dei criteri di Gestione firewall di Azure
- Distribuire e configurare Firewall di Azure usando il portale di Azure classico.

Distribuzione su Azure

Per distribuire l'app per la logica Standard da Visual Studio Code, è possibile pubblicare direttamente il progetto in Azure. È possibile pubblicare l'app per la logica come nuova risorsa, che crea automaticamente tutte le risorse necessarie, ad esempio un account di archiviazione di Azure, in modo analogo ai requisiti dell'app per le funzioni. In alternativa, è possibile pubblicare la logic app in una risorsa Standard precedentemente distribuita, sovrascrivendo la versione esistente.

La distribuzione per la risorsa dell'app per la logica Standard richiede un piano di hosting e un piano tariffario selezionato durante la distribuzione. Per altre informazioni, vedere Piani di hosting e piani tariffari.

Pubblicare in una nuova risorsa dell'app per la logica Standard

Nel riquadro di Esplora risorse, sposta il puntatore del mouse su qualsiasi area vuota sotto le cartelle e i file del progetto, apri il menu di scelta rapida e seleziona Distribuisci nell'app logica.

Anche se non è necessario che i file siano aperti per la distribuzione, assicurarsi di salvare tutti gli elementi che si prevede di distribuire.

Ti vengono presentate le seguenti opzioni per la risorsa dell'app di logica Standard di destinazione. È possibile creare una nuova app per la logica Standard o selezionare un'app per la logica Standard distribuita esistente in Azure:
- Creare una nuova app per la logica (Standard) in Azure (rapida)
- Creare una nuova app per la logica (Standard) in Azure Advanced
- Selezionare tra le risorse dell'app per la logica Standard distribuite in precedenza, se presenti.
Per le opzioni di distribuzione, selezionare se creare o usare una risorsa dell'app per la logica di destinazione esistente.

Questo esempio continua con Creare una nuova app per la logica (Standard) in Azure Advanced.

Seguire questa procedura per creare la nuova risorsa dell'app per la logica di destinazione:

Immettere un nome univoco globale per l'app di logica di destinazione.

Questo esempio usa Fabrikam-Workflows-App.
Per la località in cui eseguire la distribuzione, selezionare l'area di Azure.

Questo esempio usa Stati Uniti centro-occidentali.

Per il piano di hosting, scegliere tra le opzioni seguenti:

Piano di hosting	Descrizione
Flusso di lavoro Standard	Distribuire come nuova risorsa Standard Logic App ospitata in Azure Logic Apps a tenant singolo.
Ibrido	Distribuire un'applicazione logica Standard ospitata nella propria infrastruttura. Nota: prima di selezionare questa opzione, assicurarsi di aver configurato l'infrastruttura necessaria. Per altre informazioni, vedere Configurare un'infrastruttura personalizzata per le app per la logica Standard usando la distribuzione ibrida.

Per il piano di servizio app di Windows, scegliere una delle opzioni seguenti:
- Creare un nuovo piano di servizio app
- Selezionare i piani di servizio app esistenti nell'area di Azure selezionata (solo piani basati su Windows), se presenti.
In questo esempio viene selezionato Crea nuovo piano di servizio app.
Per il nuovo piano, specificare un nome univoco globale e selezionare un piano tariffario.

Questo esempio usa Fabrikam-Workflows-App-Service-Plan e seleziona il livello Standard del flusso di lavoro WS1 .

Per altre informazioni, vedere Piani di hosting e piani tariffari.
Per il gruppo di risorse di Azure di destinazione selezionare lo stesso gruppo di risorse del progetto per ottenere prestazioni ottimali.

In questo esempio viene usato lo stesso gruppo creato in precedenza denominato Fabrikam-Workflows-RG.

Annotazioni

Anche se è possibile creare o usare un gruppo di risorse diverso, questa operazione potrebbe influire sulle prestazioni. Se si crea o si sceglie un gruppo di risorse diverso, ma si annulla dopo che viene visualizzata la richiesta di conferma, viene annullata anche la distribuzione.
Per l'account di archiviazione di Azure da usare con i flussi di lavoro che consentono di salvare le informazioni sulla cronologia di esecuzione, scegliere tra le opzioni seguenti:
- Creare un nuovo account di archiviazione
- Selezionare tra gli account di archiviazione di Azure esistenti, se presenti.
In questo esempio viene selezionato Crea nuovo account di archiviazione.
Immettere un nome univoco globale per l'account di archiviazione. È possibile usare solo lettere minuscole e numeri.

In questo esempio viene usato fabrikamstorageaccount< numero>.
Per l'opzione per usare l'archiviazione SQL in questo esempio, selezionare No.

Se è già stato configurato un database SQL da usare per l'archiviazione seguendo l'opzione Configurare l'archiviazione del database SQL per i flussi di lavoro dell'app per la logica Standard, è possibile selezionare Sì.
Per la risorsa di Application Insights, che abilita la registrazione diagnostica e la traccia per l'app per la logica, scegliere tra le opzioni seguenti:
- Creare una nuova risorsa di Application Insights
- Ignorare per il momento. È possibile configurare Application Insights dopo la distribuzione.
- Selezionare una risorsa di Application Insights esistente, se presente.
In questo esempio viene selezionato Ignora per il momento.
Annotazioni
- Se si ha una risorsa di Application Insights che si vuole usare, è possibile selezionare tale risorsa.
- Per creare una nuova risorsa di Application Insights in questo momento, in modo da poter abilitare la registrazione e la traccia di diagnostica, vedere Abilitare Application Insights durante la distribuzione.
Per altre informazioni su Application Insights, vedere la documentazione seguente:
- Panoramica di Application Insights
- Creare e configurare le risorse di Application Insights
Dopo aver selezionato Ignora per ora o una risorsa di Application Insights esistente, Visual Studio Code visualizza un messaggio di conferma per avviare la distribuzione. Il messaggio consiglia anche che, per ottenere le prestazioni ottimali, si dovrebbero inserire le risorse di connessione per le operazioni gestite nello stesso gruppo di risorse della tua app logica e dei relativi flussi di lavoro. In App per la logica di Azure le connessioni alle operazioni gestite esistono come singole risorse di Azure.

Quando si è pronti per la distribuzione, nel messaggio di conferma selezionare Distribuisci.

Visual Studio Code inizia a creare e distribuire le risorse necessarie per pubblicare l'app logica in Azure.
Per visualizzare e monitorare il processo di distribuzione, scegliere Output dal menu Visualizza.
Nella barra degli strumenti della finestra Output, selezionare Azure Logic Apps (Standard) nell'elenco dell'ambito.

Al termine della distribuzione dell'app per la logica in Azure, viene visualizzato un messaggio che indica che la creazione dell'app per la logica è stata completata correttamente, ad esempio:

La risorsa e il flusso di lavoro dell'app per la logica sono ora attivi, abilitati e in esecuzione in Azure.

Abilitare Application Insights durante la distribuzione

Per abilitare la registrazione dei dati diagnostici e il tracciamento con Application Insights durante la distribuzione dell'applicazione logica, seguire i passaggi seguenti:

Selezionare una risorsa di Application Insights esistente o Creare una nuova risorsa di Application Insights.
Nel portale di Azurepassare alla risorsa di Application Insights.
Nel menu della risorsa, selezionare Panoramica. Trovare e copiare il valore Chiave di strumentazione.

In Visual Studio Code, nella cartella radice del progetto, aprire il file local.settings.json.

Nell'Valuesoggetto, aggiungere la proprietà APPINSIGHTS_INSTRUMENTATIONKEY e impostare il valore sulla chiave di strumentazione, ad esempio:

{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "dotnet",
      "APPINSIGHTS_INSTRUMENTATIONKEY": <instrumentation-key>
   }
}

Controllare se i nomi di trigger e azione del flusso di lavoro vengono visualizzati correttamente nell'istanza di Application Insights.
1. Nel portale di Azure, passare alla risorsa di Application Insights.
2. Nel menu delle risorse, in Analizzareselezionare Mappa delle applicazioni.
3. Esaminare i nomi delle operazioni visualizzati nella mappa.
  
  Alcune richieste in ingresso da trigger predefiniti potrebbero apparire come duplicati nella mappa delle applicazioni. Anziché usare il formato WorkflowName.ActionName, questi duplicati usano il nome del flusso di lavoro come nome dell'operazione e hanno origine dall'host di Funzioni di Azure.

È possibile modificare facoltativamente il livello di gravità per i dati di traccia raccolti e inviati dall'app logica all'istanza di Application Insights.

Ogni volta che si verifica un evento correlato al flusso di lavoro, ad esempio quando viene attivato un flusso di lavoro o quando viene eseguita un'azione, il runtime genera varie tracce. Queste tracce coprono la durata del flusso di lavoro e includono, ma non sono limitati ai tipi di evento seguenti:

Attività del servizio, ad esempio avvio, arresto ed errori.
Processi e attività dispatcher.
Attività del flusso di lavoro, ad esempio trigger, azione ed esecuzione.
Attività della richiesta di archiviazione, ad esempio esito positivo o negativo.
Attività della richiesta HTTP, ad esempio in ingresso, in uscita, riuscita ed errore.
Eventuali tracce di sviluppo, ad esempio messaggi di debug.

Ogni tipo di evento viene assegnato a un livello di gravità. Ad esempio, il livello Trace acquisisce i messaggi più dettagliati, mentre il livello Information acquisisce attività generali nel flusso di lavoro, ad esempio quando l'app per la logica, il flusso di lavoro, il trigger e le azioni vengono avviati e interrotti.

La tabella seguente descrive i livelli di gravità e i relativi tipi di traccia:

Livello di gravità	Tipo di traccia
Critico	Log che descrivono un errore irreversibile nel flusso di lavoro dell'app per la logica.
Debug	Log che è possibile usare per l'analisi durante lo sviluppo, ad esempio chiamate HTTP in ingresso e in uscita.
Errore	Log che indicano un errore nell'esecuzione del flusso di lavoro, ma non un errore generale nell'app per la logica.
Informazioni	Log che tengono traccia dell'attività generale nell'app per la logica o nel flusso di lavoro, ad esempio: - Quando un trigger, un'azione o un'esecuzione inizia e termina. - All'avvio o alla fine dell'app per la logica.
Traccia	Log che contengono i messaggi più dettagliati, ad esempio richieste di archiviazione o attività dispatcher, oltre a tutti i messaggi correlati all'attività di esecuzione del flusso di lavoro.
Avvertenza	Log che evidenziano uno stato anomalo nell'app per la logica, ma non ne impediscono l'esecuzione.

Per impostare il livello di gravità, a livello radice del progetto aprire il file host.json e trovare l'oggetto logging. Questo oggetto controlla il filtro dei log per tutti i flussi di lavoro nell'app per la logica e segue il layout ASP.NET Core per il filtro dei tipi di log.

{
   "version": "2.0",
   "logging": {
      "applicationInsights": {
         "samplingExcludedTypes": "Request",
         "samplingSettings": {
            "isEnabled": true
         }
      }
   }
}

Se l'oggetto logging non contiene un oggetto logLevel che include la proprietà Host.Triggers.Workflow, aggiungere tali elementi. Impostare la proprietà sul livello di gravità per il tipo di traccia desiderato, ad esempio:

{
   "version": "2.0",
   "logging": {
      "applicationInsights": {
         "samplingExcludedTypes": "Request",
         "samplingSettings": {
            "isEnabled": true
         }
      },
      "logLevel": {
         "Host.Triggers.Workflow": "Information"
      }
   }
}

Attività successive alla distribuzione

Le sezioni seguenti descrivono le attività da eseguire al termine della distribuzione dell'app per la logica.

Confermare la distribuzione nel portale di Azure

Dopo aver distribuito l'app per la logica da Visual Studio Code al portale di Azure, verificare che l'app per la logica venga visualizzata nel portale. Le risorse di Azure sono organizzate e raggruppate nel portale in base al tipo di risorsa. Per trovare le app per la logica Standard, seguire questa procedura:

Accedere al portale di Azure con il proprio account Azure.
Nella barra del titolo di Azure, inserisci il nome della tua app logica, che apparirà come risultato nella sezione Risorse. Seleziona la tua app logica per aprire la risorsa.
Nel menu dell'App per la logica, all'interno di Flussi di lavoroselezionare Flussi di lavoro.
Nella pagina Flussi di lavoro selezionare il flusso di lavoro.
Nel menu del flusso di lavoro, in Strumenti, selezionare Progettazione. Verificare che il flusso di lavoro venga visualizzato come previsto.

È ora possibile apportare modifiche a questo flusso di lavoro nel portale di Azure.
Assicurarsi di abilitare l'esperienza di monitoraggio per l'app per la logica distribuita in modo da poter visualizzare la cronologia di esecuzione del flusso di lavoro, gli input, gli output e altre informazioni correlate.

Abilitare l'esperienza di monitoraggio per l'app per la logica distribuita

Prima di esaminare la cronologia di esecuzione del flusso di lavoro, gli input, gli output e le informazioni correlate per una risorsa dell'app per la logica Standard distribuita con l'esperienza di monitoraggio nel portale di Azure, è prima necessario abilitare tale esperienza nella risorsa dell'app per la logica.

Nel portale di Azure aprire la risorsa dell'app per la logica Standard distribuita.
Nel menu delle risorse, in API selezionare CORS.
Nel riquadro CORS, in Origini consentite aggiungere il carattere jolly (*).
Al termine, sulla barra degli strumenti CORS selezionare Salva.

Abilitare o aprire Application Insights dopo la distribuzione

Durante l'esecuzione del flusso di lavoro, il flusso di lavoro dell'app per la logica genera dati di telemetria insieme ad altri eventi. È possibile usare questi dati di telemetria per ottenere una migliore visibilità sull'esecuzione del flusso di lavoro e sul funzionamento del runtime di App per la logica di Azure. Application Insights offre la possibilità di abilitare la registrazione, la traccia e il monitoraggio della diagnostica per l'app per la logica usando dati di telemetria quasi in tempo reale (metriche in tempo reale). Questa funzionalità consente di analizzare più facilmente gli errori e i problemi di prestazioni quando si usano i dati di telemetria per diagnosticare i problemi, configurare avvisi e creare grafici.

Se Application Insights non è stato configurato in precedenza, è possibile abilitare questa funzionalità nel portale di Azure dopo la distribuzione di app per la logica da Visual Studio Code. È necessario avere una risorsa di Application Insights in Azure, ma è possibile creare questa risorsa separatamente in anticipo o quando si abilita questa funzionalità dopo la distribuzione.
Se Application Insights è stato configurato in precedenza durante la distribuzione da Visual Studio Code, è sufficiente aprire la risorsa di Application Insights dall'app per la logica nel portale di Azure.

Abilitare Application Insights per una Logic App distribuita

Nel portale di Azure trovare e aprire l'app per la logica distribuita.
Nel menu dell'app per la logica, in Monitoraggio selezionare Application Insights.
Nella pagina Application Insights selezionare Attiva Application Insights.

Dopo l'aggiornamento della pagina Application Insights , nella sezione Modificare la risorsa selezionare tra le opzioni seguenti:

Creare una nuova risorsa

Azure crea risorse per Application Insights e un'area di lavoro Log Analytics usando la sottoscrizione e il gruppo di risorse correnti. Per usare una sottoscrizione e un gruppo di risorse diversi, vedere Creare una nuova risorsa di Application Insights e tornare a questa pagina.

Proprietà	Descrizione
Nuovo nome risorsa	Accettare il nome generato o specificare un altro nome.
Ubicazione	Selezionare un'area di Azure.
Area di lavoro Log Analytics	Selezionare un'area di lavoro esistente, se disponibile. In caso contrario, viene creata automaticamente un'area di lavoro predefinita. Per altre informazioni, vedere Panoramica dell'area di lavoro Log Analytics.

Selezionare la risorsa esistente:
1. Selezionare la sottoscrizione di Azure per la risorsa di Application Insights.
2. Selezionare la risorsa Application Insights.

Al termine, nella parte inferiore della pagina selezionare Applica.

Aprire Application Insights dall'app per la logica

Nel portale di Azure trovare e aprire l'app per la logica distribuita.
Nel menu dell'app per la logica, in Monitoraggio selezionare Application Insights.
Nella pagina Application Insights selezionare il collegamento per la risorsa di Application Insights.

Dopo l'apertura di Application Insights, è possibile esaminare varie metriche per l'app per la logica. Per altre informazioni, vedere questi articoli:

Risolvere gli errori e i problemi

Non è possibile aprire la finestra di progettazione

Quando si tenta di aprire la finestra di progettazione, viene visualizzato questo errore "Impossibile avviare la fase di progettazione del flusso di lavoro". Se in precedenza si è tentato di aprire la finestra di progettazione, ma il progetto è stato interrotto o eliminato, il bundle di estensione potrebbe non essere scaricato correttamente. Per verificare se questo motivo è la causa, seguire questa procedura:

In Visual Studio Code aprire la finestra di output. Dal menu Visualizza selezionare Output.
Nell'elenco nella barra del titolo della finestra di output selezionare App per la logica di Azure (Standard) in modo da poter esaminare l'output dall'estensione, ad esempio:

Esaminare l'output e verificare se viene visualizzato questo messaggio di errore:

A host error has occurred during startup operation '<operation-ID>'.
System.Private.CoreLib: The file 'C:\Users\<user-name>\AppData\Local\Temp\Functions\
ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows\1.1.7\bin\
DurableTask.AzureStorage.dll' already exists.
Value cannot be null. (Parameter 'provider')
Application is shutting down...
Initialization cancellation requested by runtime.
Stopping host...
Host shutdown completed.

Per risolvere questo errore, eliminare la cartella ExtensionBundles in questo percorso ...\Users\<user-name>\AppData\Local\Temp\Functions\ExtensionBundles e riprovare ad aprire il file workflow.json nella finestra di progettazione.

Nuovi trigger e azioni non sono disponibili nella selezione della finestra di progettazione per i flussi di lavoro creati in precedenza

App per la logica di Azure a tenant singolo supporta azioni predefinite per operazioni di funzioni di Azure, operazioni liquide e operazioni XML, ad esempio Convalida XML e Trasformazione XML. Tuttavia, per le app per la logica create in precedenza, queste azioni potrebbero non essere visualizzate nella selezione della finestra di progettazione per selezionare se Visual Studio Code usa una versione obsoleta del bundle di estensione, Microsoft.Azure.Functions.ExtensionBundle.Workflows.

Inoltre, le azioni e il connettore Operazioni di Funzioni di Azure non vengono visualizzate nella selezione della finestra di progettazione, a meno che non sia stato abilitato o selezionato Usare connettori da Azure quando è stata creata l'app per la logica. Se non sono stati abilitati i connettori distribuiti da Azure in fase di creazione dell'app, è possibile abilitarli dal progetto in Visual Studio Code. Aprire il menu di scelta rapida workflow.json e selezionare Usa connettori da Azure.

Per correggere il bundle obsoleto, seguire questa procedura per eliminare il bundle obsoleto, che fa sì che Visual Studio Code aggiorni automaticamente il bundle di estensione alla versione più recente.

Annotazioni

Questa soluzione si applica solo alle app per la logica create e distribuite usando Visual Studio Code con l'estensione App per la logica di Azure (Standard), non le app per la logica create tramite il portale di Azure. Vedere Trigger e azioni supportati non sono presenti nella finestra di progettazione nel portale di Azure.

Salvare qualsiasi lavoro che non si vuole perdere e chiudere Visual Studio Code.
Nel computer passare alla cartella seguente, che contiene le cartelle con controllo delle versioni per il bundle esistente:

...\Users\<user-name>\.azure-functions-core-tools\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows
Eliminare la cartella della versione per il bundle precedente, ad esempio se si dispone di una cartella per la versione 1.1.3, eliminare tale cartella.
Passare ora alla cartella seguente, che contiene le cartelle con controllo delle versioni per il pacchetto NuGet richiesto:

...\Users\<user-name>\.nuget\packages\microsoft.azure.workflows.webjobs.extension
Eliminare la cartella della versione per il pacchetto precedente.
Riaprire Visual Studio Code, il progetto e il file workflow.json nella finestra di progettazione.

I trigger e le azioni mancanti vengono ora visualizzati nella finestra di progettazione.

"400 Richiesta non valida" viene visualizzato su un trigger o un'azione

Quando un'esecuzione ha esito negativo e si esamina l'esecuzione nella visualizzazione di monitoraggio, questo errore potrebbe essere visualizzato in un trigger o in un'azione con un nome più lungo, che causa il superamento del limite di caratteri predefinito da parte dell'URI (Uniform Resource Identifier) sottostante.

Per risolvere il problema e regolare l'URI più lungo, modificare le chiavi del Registro di sistema UrlSegmentMaxCount e UrlSegmentMaxLength sul computer seguendo questa procedura. Questi valori predefiniti della chiave sono descritti in questo articolo ,Http.sys impostazioni del Registro di sistema per Windows.

Importante

Prima di iniziare, assicurarsi di salvare il lavoro. Questa soluzione richiede di riavviare il computer al termine in modo che le modifiche possano essere applicate.

Nel computer aprire la finestra Esegui ed eseguire il comando regedit, che apre l'editor del Registro di sistema.
Nella casella Controllo account utente selezionare Sì per consentire le modifiche apportate al computer.
Nel riquadro sinistro, in Computerespandere i nodi lungo il percorso, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameterse quindi selezionare Parametri.
Nel riquadro destro trovare le chiavi del Registro di sistema UrlSegmentMaxCount e UrlSegmentMaxLength.
Aumentare questi valori di chiave in modo che gli URI possano contenere i nomi da usare. Se queste chiavi non esistono, aggiungerle alla cartella Parametri seguendo questa procedura:
1. Nel menu di scelta rapida Parametri selezionare Nuovo >valore DWORD (32 bit).
2. Nella casella di modifica visualizzata immettere UrlSegmentMaxCount come nuovo nome della chiave.
3. Aprire il menu di scelta rapida del nuovo tasto e selezionare Modifica.
4. Nella casella Modifica stringa visualizzata immettere il valore chiaveDati valore desiderato in formato esadecimale o decimale. Ad esempio, 400 in esadecimale equivale a 1024 in decimale.
5. Per aggiungere il valore della chiave UrlSegmentMaxLength, ripetere questi passaggi.
Dopo aver aumentato o aggiunto questi valori chiave, l'editor del Registro di sistema è simile all'esempio seguente:
Quando si è pronti, riavviare il computer in modo che le modifiche possano avere effetto.

L'avvio della sessione di debug non riesce

Quando si tenta di avviare una sessione di debug, viene visualizzato l'errore, "Errore esistente dopo l'esecuzione di preLaunchTask 'generateDebugSymbols'". Per risolvere questo problema, modificare il file tasks.json nel progetto in modo che ignori la generazione dei simboli.

Nel progetto espandere la cartella .vscode** e aprire il file tasks.json .

Nell'attività seguente eliminare la riga, "dependsOn: "generateDebugSymbols", insieme alla virgola al termine della riga precedente, ad esempio:

Prima:

 {
   "type": "func",
   "command": "host start",
   "problemMatcher": "$func-watch",
   "isBackground": true,
   "dependsOn": "generateDebugSymbols"
 }

Dopo:

 {
   "type": "func",
   "command": "host start",
   "problemMatcher": "$func-watch",
   "isBackground": true
 }

Condividi tramite

Creare flussi di lavoro di app per la logica Standard con Visual Studio Code

Prerequisiti

Requisiti di accesso e connettività

Attrezzi

Controllare l'installazione dell'estensione

Connettersi all'account di Azure

Creare un'area di lavoro locale

Creare il progetto dell'applicazione logica

Aprire la finestra di progettazione del flusso di lavoro

Aggiungere un trigger e un'azione

Aggiungere il trigger Request

Aggiungere l'azione di Office 365 Outlook

Struttura del progetto dell'app per la logica standard

Altre attività di configurazione dello sviluppo

Abilitare webhook in esecuzione in locale

Configurare l'inoltro delle chiamate con ngrok

Configurare l'URL di inoltro nelle impostazioni dell'app

Abilitare la cronologia di esecuzione per i flussi di lavoro senza stato

Aggiungere elementi e dipendenze al progetto

Convertire il progetto in base al pacchetto NuGet (.NET)

Eseguire la migrazione di progetti basati su pacchetti NuGet per usare gli assembly nella cartella "lib"

Abilitare la creazione di connettori predefiniti

Esegui, effettua il debug e testa i flussi di lavoro in locale

Impostare punti di interruzione per il debug

Eseguire il debug e testare il flusso di lavoro

Restituire una risposta

Ripeti il test del tuo flusso di lavoro

Preparare la distribuzione

Configurare l'accesso al firewall

Distribuzione su Azure

Pubblicare in una nuova risorsa dell'app per la logica Standard

Abilitare Application Insights durante la distribuzione

Attività successive alla distribuzione

Confermare la distribuzione nel portale di Azure

Abilitare l'esperienza di monitoraggio per l'app per la logica distribuita

Abilitare o aprire Application Insights dopo la distribuzione

Abilitare Application Insights per una Logic App distribuita

Aprire Application Insights dall'app per la logica

Risolvere gli errori e i problemi

Non è possibile aprire la finestra di progettazione

Nuovi trigger e azioni non sono disponibili nella selezione della finestra di progettazione per i flussi di lavoro creati in precedenza

"400 Richiesta non valida" viene visualizzato su un trigger o un'azione

L'avvio della sessione di debug non riesce

Contenuti correlati

Commenti e suggerimenti

Risorse aggiuntive