Creare un flusso di lavoro di app per la logica standard in App per la logica di Azure a tenant singolo usando Visual Studio Code

Articolo
09/27/2024

Si applica: App per la logica di Azure (Standard)

Questa guida pratica illustra come creare un flusso di lavoro di integrazione di esempio eseguito in App per la logica di Azure a tenant singolo usando Visual Studio Code con l'estensione App per la logica di Azure (Standard). Prima di creare questo flusso di lavoro, si creerà una risorsa dell'app per la logica standard, che offre le funzionalità seguenti:

L'app per la logica può includere più flussi di lavoro con stato e senza stato.
I flussi di lavoro nella stessa app per la logica e nello stesso tenant vengono eseguiti nello stesso processo del runtime di App per la logica di Azure, in modo da condividere le stesse risorse e offrire prestazioni migliori.
È possibile creare, eseguire e testare flussi di lavoro in locale usando l'ambiente di sviluppo di Visual Studio Code.

Quando si è pronti, è possibile distribuire l'app per la logica in Azure in cui il flusso di lavoro può essere eseguito nell'ambiente app per la logica di Azure a tenant singolo o in un 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, tra cui Azure, servizio Azure Kubernetes, locale o anche altri provider di servizi cloud, a causa del runtime in contenitori di App per la logica di Azure.

Nota

La distribuzione dell'app per la logica in un cluster Kubernetes è attualmente in anteprima pubblica.

Per maggiori informazioni su App per la logica di Azure a tenant singolo, consultare Tenant singolo e multi tenant a confronto nelle app per la logica di Azure.

Anche se il flusso di lavoro di esempio è basato sul cloud e include solo due passaggi, è possibile creare flussi di lavoro da centinaia di operazioni che possono connettere un'ampia gamma di app, dati, servizi e sistemi nel cloud, in locale e in ambienti ibridi. Il flusso di lavoro di esempio inizia con il trigger di Richiesta predefinito e segue con un'azione di Office 365 Outlook. Il trigger 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 attivato, l'azione successiva viene eseguita inviando un messaggio di posta elettronica all'indirizzo di posta elettronica specificato insieme agli output selezionati dal trigger.

Suggerimento

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.

Per creare questo flusso di lavoro di esempio usando il portale di Azure, seguire invece i passaggi descritti in Creare flussi di lavoro di integrazione usando App per la logica di Azure a tenant singolo e il portale di Azure. Entrambe le opzioni offrono la possibilità di sviluppare, eseguire e distribuire flussi di lavoro delle app per la logica negli stessi tipi di ambienti. Tuttavia, con Visual Studio Code, è possibile sviluppare, testare ed eseguire localmente flussi di lavoro nell'ambiente di sviluppo.

Screenshot che mostra Visual Studio Code, il progetto dell'app per la logica e il flusso di lavoro.

A mano a mano che si procede, verranno completate queste attività generali:

Creare un progetto per l'app per la logica e un flusso di lavoro con stato vuoto.
Aggiungere un trigger e un'azione.
Eseguire, testare, eseguire il debug ed esaminare la cronologia di esecuzione in locale.
Trovare i dettagli del nome di dominio per l'accesso al firewall.
Eseguire la distribuzione in Azure, che include facoltativamente l'abilitazione di Application Insights.
Gestire l'app per la logica distribuita in Visual Studio Code e nel portale di Azure.
Abilitare la cronologia di esecuzione per i flussi di lavoro senza stato.
Abilitare o aprire Application Insights dopo la distribuzione.

Prerequisiti

Accesso e connettività

Se si prevede di compilare in locale progetti di app per la logica standard ed eseguire flussi di lavoro usando solo i connettori predefiniti eseguiti in modo nativo nel runtime di App per la logica di Azure, non sono necessari i requisiti seguenti. Tuttavia, assicurarsi di avere le seguenti credenziali di connettività e account Azure per pubblicare o distribuire il progetto da Visual Studio Code in Azure, usare i connettori gestiti eseguiti in Azure globale oppure accedere alle risorse e ai flussi di lavoro dell'app per la logica standard già distribuiti in Azure:
- Accesso a Internet in modo da poter scaricare i requisiti, connettersi da Visual Studio Code all'account Azure e pubblicare da Visual Studio Code in Azure.
- Account e sottoscrizione di Azure. Se non si ha una sottoscrizione, è possibile iscriversi per creare un account Azure gratuito.
Per creare lo stesso flusso di lavoro di esempio in questo articolo, è necessario un account di posta elettronica di Office 365 Outlook che usa un account Microsoft aziendale o dell'istituto di istruzione per accedere.

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, le opzioni potrebbero differire in alcuni modi. Ad esempio, se si usa il connettore Outlook.com, usare l'account Microsoft personale per accedere.

Strumenti

Scaricare e installare Visual Studio Code, gratuito.
Scaricare e installare l'estensione dell’Account di Azure per Visual Studio Code in modo da avere un'unica esperienza comune per l'accesso e il filtro delle sottoscrizioni di Azure in tutte le estensioni di Azure in Visual Studio Code. Questa guida pratica include i passaggi che usano questa esperienza.

Scaricare e installare le dipendenze di Visual Studio Code seguenti per il sistema operativo specifico usando uno dei metodi seguenti:

Installare automaticamente tutte le dipendenze.
Scaricare e installare ogni dipendenza separatamente.

Installare automaticamente tutte le dipendenze

A partire dalla versione 2.81.5, l'estensione App per la logica di Azure (Standard) per Visual Studio Code include un programma di installazione delle dipendenze che installa automaticamente tutte le dipendenze necessarie in una nuova cartella binaria e lascia invariate le dipendenze esistenti. Per altre informazioni, vedere Inizia più facilmente più facilmente con l'estensione App per la logica di Azure (Standard) per Visual Studio Code.

Questa estensione include le dipendenze seguenti:

Dipendenza	Descrizione
C# per Visual Studio Code	Abilita la funzionalità F5 per eseguire il flusso di lavoro.
Azurite per Visual Studio Code	Fornisce un archivio dati locale e un emulatore da usare con Visual Studio Code in modo che sia possibile lavorare sul progetto di app per la logica ed eseguire i flussi di lavoro nell'ambiente di sviluppo locale. Se non si vuole avviare automaticamente Azurite, è possibile disabilitare questa opzione: 1. Nel menu file selezionare Preferenze>Impostazioni. 2. Nella scheda Utente selezionare estensioni>App per la logica di Azure (standard). 3. Trovare l'impostazione denominata App per la logica di Azure Standard: Avvio automatico di Azuritee deselezionare la casella di controllo selezionata.
.NET SDK 6.x.x	Include .NET Runtime 6.x.x, un prerequisito per il runtime di App per la logica di Azure (Standard).
Strumenti di base di Funzioni di Azure - Versione 4.x	Installare la versione basata sul sistema operativo (Windows, macOSo Linux). Questi strumenti includono una versione dello stesso runtime che supporta il runtime di Funzioni di Azure, che l'estensione App per la logica di Azure (Standard) usa in Visual Studio Code.
Node.js versione 16.x.x, a meno che non sia già installata una versione più recente	Obbligatorio per abilitare l'azione Operazioni codice inline che esegue JavaScript.

Il programma di installazione non esegue le attività seguenti:

Controllare se le dipendenze necessarie esistono già.
Installare solo le dipendenze mancanti.
Aggiornare le versioni precedenti delle dipendenze esistenti.

Scaricare e installare l'estensione App per la logica di Azure (Standard) per Visual Studio Code, a partire dalla versione 2.81.5).
Nella barra attività in Visual Studio Code selezionare Estensioni. (Tastiera: premere CTRL+MAIUSC+X)
Nel riquadro Estensioni aprire i puntini di sospensione (...) e selezionare Installa da VSIX.
Trovare e selezionare il file VSIX scaricato.

Al termine dell'installazione, l'estensione viene attivata automaticamente ed esegue il comando Convalidare e installare i file binari di dipendenza. Per visualizzare i log del processo, aprire la finestra Output.
Quando viene visualizzata la richiesta seguente, selezionare Sì (scelta consigliata) per confermare che si desidera installare automaticamente le dipendenze necessarie:
Ricaricare Visual Studio Code, se necessario.
Verificare che le dipendenze siano visualizzate correttamente nella cartella seguente:

C:\Users\<your-user-name>\.azurelogicapps\dependencies\<dependency-name>

Verificare le impostazioni di estensione seguenti in Visual Studio Code:

Nel menu file selezionare Preferenze>Impostazioni.
Nella scheda Utente selezionare estensioni>App per la logica di Azure (standard).

Esaminare le impostazioni seguenti:

Impostazione estensione	Valore
Percorso dipendenze	C:\Users\<your-user-name>\.azurelogicapps\dependencies
Timeout delle dipendenze	60 secondi
Percorso binario Dotnet	C:\Users\<your-user-name>\.azurelogicapps\dependencies\DotNetSDK\dotnet.exe
Percorso binario Func Core Tools	C:\Users\<your-user-name>\.azurelogicapps\dependencies\FuncCoreTools\func
Percorso binario JS del nodo	C:\Users\<your-user-name>\.azurelogicapps\dependencies\NodeJs\node
Avvio automatico di Azurite	Attivata
Fase di progettazione dell'avvio automatico	Attivata

Se si dispone di un progetto di app per la logica esistente con attività definite personalizzate archiviate nel file vscode/tasks.json, assicurarsi di salvare il file tasks.json altrove prima di aprire il progetto.

Quando si apre il progetto, viene richiesto di aggiornare il file tasks.json per usare le dipendenze necessarie. Se si sceglie di continuare, l'estensione sovrascrive il file tasks.json.

Quando si apre il progetto dell'app per la logica, vengono visualizzate le notifiche seguenti:

Notifica	Azione
Avviare sempre il processo in background in fase di progettazione all'avvio?	Per aprire più rapidamente la finestra di progettazione del flusso di lavoro, selezionare Sì (scelta consigliata).
Configurare Azurite per l'avvio automatico al lancio del progetto?	Per avviare automaticamente l'archiviazione di Azurite all'apertura del progetto, selezionare Abilita Avvio automatico. Nella parte superiore di Visual Studio Code, nella finestra di comando visualizzata, premere INVIO per accettare il percorso predefinito: C\Users\<your-user-name>\.azurelogicapps\.azurite

Problemi noti relativi all'anteprima

Se si è scelto di installare automaticamente tutte le dipendenze in un computer che non dispone di alcuna versione di .NET Core SDK, viene visualizzato il messaggio seguente:

"Impossibile trovare .NET Core SDK: Errore durante l'esecuzione di dotnet -- info: Errore: Comando non riuscito: dotnet --info 'dotnet non riconosciuto come comando interno o esterno, programma eseguibile o file batch. "dotnet" non riconosciuto come comando interno o esterno, programma eseguibile o file batch. . Il debug di .NET Core non verrà abilitato. Assicurarsi che .NET Core SDK sia installato e che sia nel percorso."

Questo messaggio viene visualizzato perché .NET Core Framework è ancora in fase di installazione quando l'estensione viene attivata. È possibile scegliere di disabilitare questo messaggio in modo sicuro.

Se si verificano problemi con l'apertura di un progetto di app per la logica esistente o l'avvio dell'attività di debug (tasks.json) per avvio dell'host funce viene visualizzato questo messaggio, seguire questa procedura per risolvere il problema:
1. Aggiungere il percorso binario dotnet alla variabile PATH di ambiente.
  1. Nella casella di ricerca della barra delle applicazioni di Windows immettere variabili di ambiente e selezionare Modifica le variabili di ambiente di sistema.
  2. Nella casella Proprietà di sistema, nella scheda Avanzate, selezionare Variabili di ambiente.
  3. Nella casella Variabili di ambiente, dall’elenco Variabili utente per <nome utente>, selezionare PERCORSO e quindi Modifica.
  4. Se nell'elenco non viene visualizzato il valore seguente, selezionare Nuovo per aggiungere il valore seguente:
    
    C:\Users\<your-user-name>\.azurelogicapps\dependencies\DotNetSDK
  5. Al termine, seleziona OK.
2. Chiudere tutte le finestre di Visual Studio Code e riaprire il progetto.
Se si verificano problemi durante l'installazione e la convalida delle dipendenze binarie, ad esempio:
- Problemi relativi alle autorizzazioni di Linux
- Viene visualizzato l'errore seguente: il<> file o il percorso non esiste
- La convalida viene bloccata in <nome di dipendenza>.
Seguire questa procedura per eseguire di nuovo il comando convalidare e installare dipendenze binarie:
1. Dal menu Visualizza, selezionare Riquadro comandi.
2. Quando viene visualizzata la finestra di comando, immettere ed eseguire il comando Convalidare e installare dipendenze binarie.
Se non è installato .NET Core 7 o versione successiva e si apre un'area di lavoro di App per la logica di Azure che contiene un progetto di Funzioni di Azure, viene visualizzato il messaggio seguente:

Si sono verificati problemi durante il caricamento del progetto [function-name].csproj. Per informazioni dettagliate, vedere il log.

Questo componente mancante non influisce sul progetto funzioni di Azure, quindi è possibile ignorare questo messaggio in modo sicuro.

Installare ogni dipendenza separatamente.

Dipendenza	Descrizione
.NET SDK 6.x.x	Include .NET Runtime 6.x.x, un prerequisito per il runtime di App per la logica di Azure (Standard).
Strumenti di base di Funzioni di Azure - Versione 4.x	- Windows: usare la versione di Microsoft Installer (MSI), che è `func-cli-X.X.XXXX-x*.msi`. - macOS - Linux Questi strumenti includono una versione dello stesso runtime che supporta il runtime di Funzioni di Azure, che l'estensione App per la logica di Azure (Standard) usa in Visual Studio Code. Se si dispone di un'installazione precedente a queste versioni, disinstallare prima tale versione o assicurarsi che la variabile di ambiente PATH punti alla versione scaricata e installata.
Node.js versione 16.x.x, a meno che non sia già installata una versione più recente	Obbligatorio per abilitare l'azione Operazioni codice inline che esegue JavaScript. Nota: per Windows scaricare la versione MSI. Se invece si usa la versione ZIP, è necessario rendere disponibile manualmente Node.js usando una variabile di ambiente PATH per il sistema operativo.

Se è già stata installata la versione dell'estensione App per la logica di Azure (Standard) che installa automaticamente tutte le dipendenze (anteprima), ignorare questo passaggio. In caso contrario, scaricare e installare l'estensione App per la logica di Azure (Standard) per Visual Studio Code.
1. Nella barra degli strumenti sinistra in Visual Studio Code selezionare Estensioni.
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.
  
  Al termine dell'installazione, l'estensione viene visualizzata nell'elenco Estensioni: Installate.
  
  Suggerimento
  
  Se l'estensione non viene visualizzata nell'elenco installato, provare a riavviare Visual Studio Code.
Attualmente, è possibile avere entrambe le estensioni a consumo (multi-tenant) e standard (a tenant singolo) installate contemporaneamente. Le esperienze di sviluppo si differenziano tra loro in alcuni modi, ma la sottoscrizione di Azure può includere sia i tipi di app per la logica standard sia a consumo. In Visual Studio Code la finestra di Azure mostra tutte le app per la logica distribuite e ospitate in Azure nella sottoscrizione di Azure, ma organizza le app nei modi seguenti:
- Sezione App per la logica (consumo): tutte le app per la logica a consumo nella sottoscrizione.
- Sezione Risorse : tutte le app per la logica standard nella sottoscrizione. In precedenza, queste app per la logica venivano visualizzate nella sezioneApp per la logica (standard), ora spostata nella sezione Risorse.
Per eseguire in locale trigger e azioni basati su webhook, ad esempio il trigger webhook HTTP predefinito, in Visual Studio Code, è necessario configurare l'inoltro per l'URL di callback.
Se si creano risorse dell'app per la logica con impostazioni che supportano l'uso di Application Insights, è possibile abilitare facoltativamente la registrazione e la traccia diagnostica per la risorsa dell'app per la logica. È possibile farlo quando si crea l'app per la logica o dopo la distribuzione. È necessario avere un'istanza di Application Insights, ma è possibile creare questa risorsa in anticipo, quando si crea l'app per la logica o dopo la distribuzione.
Installare o usare uno strumento che può inviare richieste HTTP per testare la soluzione, ad esempio:
Attenzione

Per gli 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, funziona offline o in locale, non sincronizza i dati nel cloud e non richiede l'accesso a un account online. In questo modo si riduce il rischio di esporre i dati sensibili al pubblico.

Configurare Visual Studio Code

Per assicurarsi che tutte le estensioni 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 Aggiornamenti controllo automatico sia selezionato e che Aggiornamento automatico sia impostato su Tutte le estensioni.
Verificare che l'impostazione App per la logica di Azure Standard: runtime progetto per l'estensione App per la logica di Azure (Standard) sia sulla versione ~4:

Nota

Questa versione è necessaria per usare le azioni operazioni codice inline.
1. Nel menu File, passare a Preferenze > Impostazioni.
2. Nella scheda Utente selezionare > estensioni > App per la logica di Azure (standard).
  
  Ad esempio, è possibile trovare l'impostazione App per la logica di Azure: runtime progetto qui o usare la casella di ricerca per trovare altre impostazioni:

Connettersi all'account di Azure

Selezionare l'icona Azure nella barra attività di Visual Studio Code.
Nella finestra di 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,nella finestra 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 un altro elenco di sottoscrizioni, selezionare le sottoscrizioni desiderate e quindi assicurarsi di selezionare OK.

Creare un progetto locale

Prima di poter creare l'app per la logica, creare un progetto locale in modo da poter gestire, eseguire e distribuire l'app per la logica da Visual Studio Code. Il progetto sottostante è simile a un progetto di Funzioni di Azure, noto anche come progetto di app per le funzioni. Tuttavia, questi tipi di progetto sono separati l'uno dall'altro, quindi le app per la logica e le app per le funzioni non possono esistere nello stesso progetto.

Nel computer creare una cartella locale vuota da usare per il progetto che verrà creato in seguito in Visual Studio Code.
In Visual Studio Code chiudere tutte le cartelle aperte.
Nella finestra di Azure, sulla barra degli strumenti della sezione Area di lavoro, dal menu App per la logica di Azure, selezionare Crea nuovo progetto.
Se Windows Defender Firewall richiede di concedere l'accesso alla rete per Code.exe, ovvero Visual Studio Code e per func.exe, che è Azure Functions Core Tools, selezionare Reti private, ad esempio la rete domestica o aziendale > Consenti l'accesso.
Passare al percorso in cui è stata creata la cartella del progetto, selezionare la cartella e continuare.
Nell'elenco dei modelli visualizzato selezionare Flusso di lavoro con stato o Flusso di lavoro senza stato. In questo esempio viene selezionato Flusso di lavoro con stato.
Assegnare un nome al flusso di lavoro e quindi premere INVIO. Questo esempio usa Flusso di lavoro con stato come nome.

Nota

È possibile che venga visualizzato un errore denominato azureLogicAppsStandard.createNewProject con il messaggio di errore Impossibile scrivere nelle impostazioni dell'area di lavoro perché azureFunctions.suppressProject non è una configurazione registrata. In questo caso, provare a installare l'estensione Funzioni di Azure per Visual Studio Code, direttamente da Visual Studio Marketplace o dall'interno di Visual Studio Code.
Se Visual Studio Code richiede di aprire il progetto nella finestra corrente di Visual Studio Code o in una nuova finestra di Visual Studio Code, selezionare Apri nella finestra corrente. In caso contrario, selezionare Apri nella nuova finestra.

Visual Studio Code completa la creazione del progetto.

Dalla barra delle attività di Visual Studio aprire il riquadro Esplora risorse, se non è già aperto.

Il riquadro Esplora risorse mostra il progetto, che include ora i file di progetto generati automaticamente. Ad esempio, il progetto ha una cartella che mostra il nome del flusso di lavoro. All'interno di questa cartella, il file workflow.json contiene la definizione JSON sottostante del flusso di lavoro.

Screenshot che mostra il riquadro Esplora risorse con la cartella del progetto, la cartella del flusso di lavoro e il file workflow.json.

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 include cartelle e file leggermente diversi. Un progetto basato su NuGet include una cartella .bin che contiene pacchetti e altri file di libreria. Un progetto basato su bundle non include la cartella .bin e altri file. Alcuni scenari richiedono l'esecuzione di un progetto basato su NuGet per l'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.

Per il progetto predefinito basato su bundle, il progetto ha una cartella e una struttura di file simile all'esempio seguente:

MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
  || Maps 
     ||| MapName1
     ||| ...
  || Schemas
     ||| SchemaName1
     ||| ...
| WorkflowName1
  || workflow.json
  || ...
| WorkflowName2
  || workflow.json
  || ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json

A livello radice del progetto, è possibile trovare i file e le cartelle seguenti con 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.
Elementi	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 mappe e schemi per le operazioni di trasformazione e convalida XML.
*<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	file	Contiene informazioni correlate all' Azure Functions Core Tools.
connections.json	file	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	file	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. 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	file	Contiene impostazioni dell'app, stringhe di connessione e altre impostazioni usate dai flussi di lavoro durante l'esecuzione in locale. In altre parole, 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 usati dagli strumenti di sviluppo locali come valori di `appSettings`. È 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.

Nota

L'impostazione dell'app FUNCTIONS_WORKER_RUNTIME è necessaria per l'app per la logica Standard e il valore è stato impostato in precedenza su node. Tuttavia, il valore richiesto è ora dotnet per tutte le app per la logica Standard nuove ed esistenti distribuite. Questa modifica del valore non deve influire sul runtime del flusso di lavoro, quindi tutto dovrebbe funzionare allo stesso modo di prima. Per altre informazioni, vedere l'impostazione dell'app FUNCTIONS_WORKER_RUNTIME.

L'impostazione dell'app APP_KIND è necessaria per l'app per la logica Standard e il valore deve essere workflowApp. In alcuni scenari, tuttavia, questa impostazione dell'app potrebbe non essere presente, ad esempio a causa dell'automazione che usa modelli di Azure Resource Manager o altri scenari in cui l'impostazione non è inclusa. Se alcune azioni non funzionano, ad esempio l'azione Esegui codice JavaScript o se il flusso di lavoro smette di funzionare, verificare che l'impostazione dell'app APP_KIND esista e sia impostata su workflowApp. Per maggiori informazioni, vedere l'impostazione dell'app APP_KIND.

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

Per impostazione predefinita, Visual Studio Code crea un progetto di app per la logica basato su bundle di estensioni (Node.js), non basato su pacchetti NuGet (.NET). Se è necessario un progetto di app per la logica basato su pacchetti NuGet (.NET), ad esempio per abilitare la creazione del connettore predefinito, è necessario convertire il progetto da basato su bundle di estensioni (Node.js) a basato su pacchetti NuGet (.NET).

Importante

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

Nel riquadro Esplora risorse, nella radice del progetto spostare il puntatore del mouse su qualsiasi area vuota sotto tutti gli altri file e cartelle, aprire il menu di scelta rapida e selezionare Converti in progetto app per la logica basato su NuGet.
Quando viene visualizzata la richiesta, confermare la conversione del progetto.

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 è già stato fatto, convertire il progetto da basato su bundle di estensioni (Node.js) a 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.

Aggiungere elementi personalizzati al progetto

In un flusso di lavoro dell'app per la logica alcuni connettori hanno dipendenze da elementi quali mappe, schemi o assembly. In Visual Studio Code è possibile caricare questi elementi nel progetto dell'app per la logica, in modo analogo a quello usato per caricare questi elementi nel portale di Azure tramite il menu delle risorse dell'app per la logica in Artifacts, ad esempio:

Aggiungere mappe al progetto

Per aggiungere mappe al progetto, nella gerarchia del progetto espandere Artifacts>Mappe, ovvero la cartella in cui è possibile inserire le mappe.

Aggiunta di schemi al progetto

Per aggiungere schemi al progetto, nella gerarchia del progetto espandere Artifacts>Schemi, ovvero la cartella in cui è possibile inserire le mappe.

Aggiungere assembly al progetto

Un'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 specifiche nel progetto. Nella tabella seguente vengono fornite altre informazioni su ogni tipo di assembly e dove inserirli esattamente nel progetto.

Tipo di assembly	Descrizione
Client/SDK Assembly (.NET Framework)	Questo tipo di assembly fornisce archiviazione e distribuzione di client e SDK personalizzati per .NET Framework. Ad esempio, il connettore predefinito SAP usa questi assembly per caricare i file DLL non ridistribuibili SAP NCo. Assicurarsi di aggiungere questi assembly alla cartella seguente: \lib\builtinOperationSdks\net472
Client/SDK Assembly (Java)	Questo tipo di assembly fornisce archiviazione e distribuzione di SDK personalizzati per Java. Ad esempio, il connettore predefinito JDBC usa questi file JAR per trovare i driver JDBC per database relazionali personalizzati (RDB). Assicurarsi di aggiungere questi assembly alla cartella seguente: \lib\builtinOperationSdks\JAR
Assembly personalizzato (.NET Framework)	Questo tipo di assembly fornisce archiviazione e distribuzione di DLL personalizzate. Ad esempio, l'operazione Trasforma XML usa questi assembly per le funzioni di trasformazione personalizzate necessarie durante la trasformazione XML. Assicurarsi di aggiungere questi assembly alla cartella seguente: \lib\custom\net472

L'immagine seguente mostra dove inserire ogni tipo di assembly nel progetto:

Per altre informazioni sul caricamento di assembly nella risorsa dell'app per la logica nel portale di Azure, vedere Aggiungere assembly a cui si fa riferimento.

Eseguire la migrazione di progetti basati su NuGet per usare assembly "lib\*"

Importante

Questa attività è necessaria solo per i progetti di app per la logica basati su NuGet.

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 <nome-progetto>con estensione csproj.

Aprire il file di definizione del flusso di lavoro nella finestra di progettazione

Espandere la cartella del progetto del flusso di lavoro denominata flusso di lavoro con stato in questo esempio e aprire il file workflow.json.
Aprire il menu di scelta rapida del file di workflow.json e selezionare Apri finestra di progettazione.
Dopo aver aperto l'elenco Abilita connettori in Azure, selezionare Usare i connettori da Azure, che si applica a tutti i connettori gestiti o "condivisi", ospitati ed eseguiti in Azure rispetto ai connettori predefiniti, nativi o "in-app", che vengono eseguiti direttamente con il runtime di App per la logica di Azure.

Nota

Attualmente i flussi di lavoro senza stato supportano solo le azioni dai connettori gestiti, non dai 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.
Dopo aver aperto l'elenco Selezionare la sottoscrizione selezionare la sottoscrizione di Azure da usare per il progetto dell'app per la logica.
Dopo aver aperto l'elenco dei gruppi di risorse, selezionare Crea nuovo gruppo di risorse.
Specificare un nome per il gruppo di risorse e premere INVIO. Questo esempio usa Fabrikam-Workflows-RG.
Nell'elenco delle località selezionare l'area di Azure da usare durante la creazione del gruppo di risorse e delle risorse. Questo esempio usa Stati Uniti centro-occidentali.

Dopo aver eseguito questo passaggio, Visual Studio Code apre la finestra di progettazione del flusso di lavoro.

Nota

Quando Visual Studio Code avvia l'API in fase di progettazione del flusso di lavoro, è possibile che venga visualizzato un messaggio che l'avvio potrebbe richiedere alcuni secondi. È possibile ignorare questo messaggio o selezionare OK.

Se la finestra di progettazione non viene aperta, esaminare la sezione risoluzione dei problemi La finestra di progettazione non si apre.

Dopo la visualizzazione della finestra di progettazione, nella finestra di progettazione viene visualizzato il prompt Aggiungi un trigger.
Nella finestra di progettazione selezionare Aggiungi un trigger, che apre il riquadro Aggiungi un trigger e una raccolta che mostra tutti i connettori con trigger da selezionare.
Successivamente, aggiungere un trigger e azioni al flusso di lavoro.

Aggiungere un trigger e azioni

Dopo aver aperto un flusso di lavoro vuoto nella finestra di progettazione, nella finestra di progettazione viene visualizzato il prompt Aggiungi un trigger. È ora possibile iniziare a creare il flusso di lavoro aggiungendo un trigger e azioni.

Importante

Per eseguire localmente un flusso di lavoro che usa un trigger o azioni basate su webhook, ad esempio il trigger o l'azione Webhook HTTP predefiniti, è necessario abilitare questa funzionalità configurando l’inoltro per l'URL di callback del webhook.

Il flusso di lavoro in questo esempio usa il trigger e le azioni seguenti:

Il trigger connettore predefinito della richiesta denominato Quando viene ricevuta una richiesta HTTP, che può ricevere chiamate o richieste in ingresso e crea un endpoint che altri servizi o flussi di lavoro dell'app per la logica possono chiamare.
L’azione connettore gestito di Office 365 Outlook denominata Inviare un messaggio di posta elettronica. Per seguire questa guida pratica, è necessario un account di posta elettronica di Office 365 Outlook. Se si dispone di un account di posta elettronica supportato da un connettore diverso, è possibile usare tale connettore, ma l'esperienza utente di tale connettore sarà diversa dai passaggi descritti in questo esempio.
L'azione del connettore richiesta predefinita denominata Risposta, che viene usata per inviare una risposta e restituire i dati al chiamante.

Aggiungere il trigger Request

Nella finestra di progettazione del flusso di lavoro, nel riquadro Aggiungi un trigger aprire l'elenco Runtime e selezionare In-app in modo da visualizzare solo i trigger predefiniti disponibili.
Trovare il trigger di Richiesta denominato Quando viene ricevuta una richiesta HTTP usando la casella di ricerca e aggiungere tale trigger al flusso di lavoro. Per altre informazioni, vedere Creare un flusso di lavoro con un trigger e azioni.

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

Suggerimento

Se il riquadro informazioni 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.

Se è necessario eliminare un elemento dalla finestra di progettazione, seguire questa procedura per eliminare elementi dalla finestra di progettazione.

Aggiungere l'azione di Office 365 Outlook

Nella finestra di progettazione, sotto il trigger di Richiesta, selezionare il segno più (+)>Aggiungi un'azione.
Nel riquadro Aggiungi un'azione visualizzata, nell'elenco Runtime, selezionare Condiviso in modo da visualizzare solo le azioni del connettore gestito disponibili.
Trovare l'azione del connettore gestito di Office 365 Outlook denominata Inviare un messaggio di posta elettronica (V2) usando la casella di ricerca e aggiungere tale azione al flusso di lavoro. Per altre informazioni, vedere Creare un flusso di lavoro con un trigger e azioni.
Quando si apre il riquadro di autenticazione dell'azione, selezionare Accedi per creare una connessione all'account di posta elettronica.
Seguire le istruzioni successive per selezionare l'account, consentire l'accesso e consentire la restituzione a Visual Studio Code.

Nota

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 visualizzato il prompt di Microsoft, selezionare l'account utente per Office 365 Outlook e quindi 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 Gli strumenti di Microsoft Azure, selezionare Apri.
Suggerimento

Per ignorare tali richieste future, selezionare le opzioni seguenti quando vengono visualizzate le richieste associate:
- Autorizzazione per aprire il collegamento per Visual Studio Code: selezionare Consenti sempre a logic-apis-westcentralus.consent.azure-apim.net di aprire i collegamenti di questo tipo nell'app associata. Questo dominio cambia in base all'area di Azure selezionata per la risorsa dell'app per la logica.
- Autorizzazione per aprire Gli strumenti di Microsoft Azure: selezionare Non chiedere di nuovo questa estensione.
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.
Nella finestra di progettazione, se l'azione Invia un messaggio di posta elettronica non viene visualizzata, selezionare tale azione.

Nel riquadro delle informazioni sull'azione, nella scheda Parametri specificare le informazioni necessarie per l'azione, ad esempio:

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

Proprietà	Richiesto	Valore	Descrizione
Per	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
Testo	Sì	Un saluto dal flusso di lavoro di esempio	Contenuto del corpo del messaggio di posta elettronica

Nota

Se si apportano modifiche nella scheda Test, assicurarsi di selezionare Salva per eseguire il commit di tali modifiche prima di passare alle schede o modificare lo stato attivo nella finestra di progettazione. In caso contrario, Visual Studio Code non manterrà le modifiche.

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

Abilitare webhook in esecuzione in locale

Quando si usa un trigger o un'azione basata su webhook, ad esempio Webhook HTTP, con un flusso di lavoro dell'app per la logica in esecuzione in Azure, il runtime di App per la logica di Azure sottoscrive l'endpoint del servizio generando e registrando un URL di callback con tale endpoint. Il trigger o l'azione attende quindi che l'endpoint del servizio chiami l'URL. Tuttavia, quando si lavora in Visual Studio Code, l'URL di callback generato inizia con http://localhost:7071/.... Questo URL è per il server localhost, che è privato, in modo che l'endpoint del servizio non possa chiamare questo URL.

Per eseguire in locale trigger e azioni basati su webhook in Visual Studio Code, è necessario configurare un URL pubblico che espone il server localhost e inoltra in modo sicuro le chiamate dall'endpoint del servizio all'URL di callback del webhook. È 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 usando ngrok

Passare al sito Web ngrok. Iscriversi per ottenere un nuovo account o accedere al proprio account, se 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. Per altre informazioni, vedere Passaggio 2: connettere l'account.

ngrok authtoken <your_auth_token>
Aprire il tunnel HTTP sulla porta localhost 7071 eseguendo il comando seguente. Per altre informazioni, vedere Passaggio 3: attivarlo.

ngrok http 7071
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

Nella finestra di progettazione di Visual Studio Code aggiungere il trigger o l'azione basata sul webhook da usare.

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.

Nota

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 i trigger o le azioni del webhook successivi 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'Valuesoggetto, la proprietà denominata Workflows.WebhookRedirectHostUri ora viene visualizzata 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",
      <...>
   }
}
```
Nota

In precedenza, il valore predefinito dell'impostazione FUNCTIONS_WORKER_RUNTIME era node. A questo punto, dotnet è il valore predefinito per tutte le app per la logica Standard nuove ed esistenti, anche per le app con un valore diverso. Questa modifica non dovrebbe influire sul runtime del flusso di lavoro e tutto dovrebbe funzionare allo stesso modo di prima. Per altre informazioni, vedere l'impostazione dell'app FUNCTIONS_WORKER_RUNTIME.

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 l'endpoint di servizio e sottoscrive tale endpoint per notificare le operazioni del 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'esecuzione del flusso di lavoro che usa trigger o azioni basati su webhook in locale, le registrazioni di sottoscrizione esistenti non vengono eliminate. Per annullare la registrazione, è necessario rimuovere o eliminare manualmente le registrazioni della sottoscrizione.

Nota

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"

Gestire i 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.

Al momento, i punti di interruzione sono 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.

Nota

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, testare ed eseguire il debug in locale

Per testare il flusso di lavoro dell'app per la logica, seguire questi passaggi per avviare 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.

Per eseguire il debug di un flusso di lavoro senza stato più facilmente, è possibile abilitare la cronologia di esecuzione per tale flusso di lavoro.
Se l'emulatore di Azurite è già in esecuzione, continuare con il passaggio successivo. In caso contrario, assicurarsi di avviare l'emulatore prima di eseguire il flusso di lavoro:
1. In Visual Studio Code, dal menu Visualizza, selezionare Riquadro comandi.
2. Dopo aver visualizzato il riquadro comandi, immettere Azurite: Start.
Per altre informazioni sui comandi di Azurite, vedere la documentazione per l'estensione Azurite in Visual Studio Code.
Nella barra delle attività di Visual Studio Code aprire il menu Esegui e selezionare Avvia debug (F5).

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

Nota

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.
A questo punto, trovare l'URL di callback per l'endpoint nel trigger di Richiesta.
1. Riaprire il riquadro Esplora risorse in modo che sia possibile visualizzare il progetto.
2. Dal menu di scelta rapida del file di workflow.json selezionare Panoramica.
3. Trovare il valore URL di callback, simile a questo URL per il trigger di Richiesta di 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>
4. Copiare e salvare il valore della proprietà URL di callback.
Per testare l'URL di callback e attivare il flusso di lavoro, inviare una richiesta HTTP all'URL, incluso il metodo previsto dal trigger Richiesta, 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.

Se è stato creato un flusso di lavoro con stato, dopo che la richiesta inviata attiva il flusso di lavoro, la pagina di panoramica mostra lo stato e la cronologia di esecuzione del flusso di lavoro.

Suggerimento

Se lo stato dell'esecuzione non viene visualizzato, provare ad aggiornare la pagina di panoramica selezionando Aggiorna. Non viene eseguita alcuna esecuzione per un trigger ignorato a causa di criteri non superati o di nessun dato.

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.
Operazione 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.
Completato	Esecuzione completata. Se un'azione non è riuscita, un'azione successiva nel flusso di lavoro ha gestito tale errore.
Timeout	Timeout dell'esecuzione perché la durata corrente ha superato il limite di durata dell'esecuzione, controllata dall'impostazione Conservazione della 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 delle esecuzioni 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 delle esecuzioni 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 esaminare gli stati per ogni passaggio di un'esecuzione specifica e gli input e gli output del passaggio, selezionare il pulsante dei puntini di sospensione (...) per l'esecuzione e selezionare Mostra esecuzione.

Screenshot che mostra la riga della cronologia di esecuzione del flusso di lavoro con i puntini di sospensione selezionati e Mostra esecuzione.

Visual Studio Code apre la visualizzazione di monitoraggio e mostra lo stato per ogni passaggio dell'esecuzione.

Screenshot che mostra ogni passaggio dell'esecuzione del flusso di lavoro e il relativo stato.

Nota

Se un'esecuzione non è riuscita e un passaggio nella visualizzazione di monitoraggio 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.
Operazione 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.
Completato	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.
Timeout	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 esaminare gli input e gli output per ogni passaggio, selezionare il passaggio da esaminare. Per esaminare ulteriormente gli input non elaborati e gli output per tale passaggio, 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 di Richiesta, è possibile restituire una risposta al chiamante che ha inviato una richiesta al flusso di lavoro usando l'Richiedi azione predefinita denominata Risposta.

Nella finestra di progettazione del flusso di lavoro, nell'azione Invia un messaggio di posta elettronica selezionare il segno più (+) >Aggiungi un'azione.

Viene visualizzato il riquadro Aggiungi un'azione in modo da poter selezionare l'azione successiva.
Nel riquadro Aggiungi un'azione selezionare in-App nell'elenco runtime. Trovare e aggiungere l'azione Risposta.

Dopo che l'azione Risposta è visualizzata nella finestra di progettazione, viene aperto automaticamente il riquadro dei dettagli dell'azione.
Nella scheda Parametri specificare le informazioni necessarie per la funzione che si desidera chiamare.

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 risposta è ora impostata sul valore di uscita Corpo per l’azione Invia un messaggio di posta elettronica.
Nella finestra di progettazione selezionare Salva.

Testare nuovamente l'app per la logica

Dopo aver apportato aggiornamenti all'app per la logica, è possibile eseguire un altro test eseguendo di nuovo il debugger in Visual Studio e inviando un'altra richiesta per attivare l'app per la logica aggiornata, analogamente ai passaggi descritti in Eseguire, testare ed eseguire il debug in locale.

Nella barra delle attività di Visual Studio Code aprire il menu Esegui e selezionare Avvia debug (F5).
In Postman o nello strumento per la creazione e l'invio di richieste inviare un'altra richiesta per attivare il flusso di lavoro.
Se è stato creato un flusso di lavoro con stato, nella pagina di panoramica del flusso di lavoro controllare lo stato dell'esecuzione più recente. Per visualizzare lo stato, gli input e gli output per ogni passaggio dell'esecuzione, selezionare il pulsante dei puntini di sospensione (...) per l'esecuzione e selezionare Mostra esecuzione.

Ad esempio, di seguito è riportato 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).

Trovare i no,i di dominio per l'accesso al firewall

Prima di distribuire ed eseguire il flusso di lavoro dell'app per la logica nel portale di Azure, se l'ambiente ha requisiti di rete o firewall rigorosi che limitano il traffico, è necessario configurare le autorizzazioni per qualsiasi connessione di trigger o azione esistente nel flusso di lavoro.

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

Nel progetto dell'app per la logica aprire il file connections.json che viene creato dopo aver aggiunto il primo trigger o la prima azione basato/a sulla connessione al flusso di lavoro e trovare l'oggetto. managedApiConnections.

Per ogni connessione creata, copiare e salvare il valore della proprietà connectionRuntimeUrl da qualche parte sicura in modo da poter configurare il firewall con queste informazioni.

Questo file di esempio connections.json contiene due connessioni, una connessione AS2 e una connessione a Office 365 con questi valori connectionRuntimeUrl:

AS2: "connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/as2/11d3fec26c87435a80737460c85f42ba
Office 365: "connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/office365/668073340efe481192096ac27e7d467f

{
   "managedApiConnections": {
      "as2": {
         "api": {
            "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{Azure-region}/managedApis/as2"
         },
         "connection": {
            "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group}/providers/Microsoft.Web/connections/{connection-resource-name}"
         },
         "connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/as2/11d3fec26c87435a80737460c85f42ba,
         "authentication": {
            "type":"ManagedServiceIdentity"
         }
      },
      "office365": {
         "api": {
            "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{Azure-region}/managedApis/office365"
         },
         "connection": {
            "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group}/providers/Microsoft.Web/connections/{connection-resource-name}"
         },
         "connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/office365/668073340efe481192096ac27e7d467f,
         "authentication": {
            "type":"ManagedServiceIdentity"
         }
      }
   }
}

Distribuzione in Azure

Da Visual Studio Code è possibile pubblicare direttamente il progetto in Azure per distribuire la risorsa dell'app per la logica Standard. È 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 l'app per la logica in una risorsa dell'app per la logica standard distribuita in precedenza, che sovrascrive l'app per la logica.

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

Nella barra attività di Visual Studio Code selezionare l'icona Azure per aprire la finestra di Azure.
Nella finestra di Azure, sulla barra degli strumenti della sezione Area di lavoro, dal menu App per la logica di Azure, selezionare Distribuisci nell'app per la logica.
Se richiesto, selezionare la sottoscrizione di Azure da usare per la distribuzione dell'app per la logica.
Nell'elenco visualizzato da Visual Studio Code selezionare una delle opzioni seguenti:
- Creare una nuova app per la logica (Standard) in Azure (rapida)
- Creare una nuova app per la logica (Standard) in Azure Advanced
- Una risorsa app per la logica distribuita in precedenza (Standard), se presente
Questo esempio continua con Creare una nuova app per la logica (Standard) in Azure Advanced.

Per creare la nuova risorsa dell'app per la logica Standard, seguire questa procedura:

Specificare un nome univoco globale per la nuova app per la logica, ovvero il nome da usare per la risorsa App per la logica (Standard). Questo esempio usa Fabrikam-Workflows-App.
Selezionare un piano di hosting per la nuova app per la logica. Creare un nome per il piano o selezionare un piano esistente (solo piani di servizio app basati su Windows). In questo esempio viene selezionato Crea nuovo piano di servizio app.
Specificare un nome per il piano di hosting e quindi selezionare un piano tariffario per il piano selezionato.

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

Nota

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 i flussi di lavoro con stato, selezionare Crea nuovo account di archiviazione o un account di archiviazione esistente.

Se le impostazioni di creazione e distribuzione dell'app per la logica supportano l'uso di Application Insights, è possibile abilitare facoltativamente la registrazione e la traccia diagnostica per l'app per la logica. È possibile farlo quando si distribuisce l'app per la logica da Visual Studio Code o dopo la distribuzione. È necessario avere un'istanza di Application Insights, ma è possibile creare questa risorsa in anticipo, quando si distribuisce l'app per la logica o dopo la distribuzione.

Per abilitare la registrazione e la traccia ora, seguire questa procedura:

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>
   }
}
```
Suggerimento

È possibile verificare se i nomi di trigger e azione 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.

Facoltativamente, è possibile modificare il livello di gravità per i dati di traccia raccolti dall'app per la logica e inviati 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. Questa tabella descrive i livelli di gravità e i relativi tipi di traccia:

Livello di gravità	Tipo di traccia
Critico	Log che descrivono un errore irreversibile nell'app per la logica.
Debug	Log che è possibile usare per l'analisi durante lo sviluppo, ad esempio chiamate HTTP in ingresso e in uscita.
Error	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.
Avviso	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"
      }
   }
}

Al termine della procedura di distribuzione, Visual Studio Code inizia a creare e distribuire le risorse necessarie per la pubblicazione dell'app per la logica.

Per esaminare e monitorare il processo di distribuzione, scegliere Output dal menu Visualizza. Nell'elenco della barra degli strumenti della finestra output selezionare App per la logica di Azure.

Al termine della distribuzione dell'app per la logica in Azure, viene visualizzato il messaggio seguente:

L'app per la logica è ora attiva in Azure e abilitata per impostazione predefinita.

Successivamente, è possibile apprendere come eseguire queste attività:

Aggiungere un flusso di lavoro vuoto al progetto.
Gestire le app per la logica distribuite in Visual Studio Code o usando il portale di Azure.
Abilitare la cronologia di esecuzione nei flussi di lavoro senza stato.
Abilitare la visualizzazione di monitoraggio nel portale di Azure per un'app per la logica distribuita.

Aggiungere un flusso di lavoro vuoto al progetto

È possibile avere più flussi di lavoro nel progetto dell'app per la logica. Per aggiungere un flusso di lavoro vuoto al progetto, seguire questa procedura:

Selezionare l'icona Azure nella barra attività di Visual Studio Code.
Nella finestra di Azure, sulla barra degli strumenti della sezione Area di lavoro, dal menu App per la logica di Azure, selezionare Crea flusso di lavoro.
Selezionare il tipo di flusso di lavoro da aggiungere: con stato o senza stato
Specificare un nome per il flusso di lavoro.

Al termine, nel progetto viene visualizzata una nuova cartella del flusso di lavoro insieme a un file workflow.json per la definizione del flusso di lavoro.

Gestire le app per la logica distribuite in Visual Studio Code

In Visual Studio Code è possibile visualizzare tutte le app per la logica distribuite nella sottoscrizione di Azure, indipendentemente dal fatto che si tratti di risorse di app per la logica a consumo o Standard, e selezionare le attività che consentono di gestire tali app per la logica. Tuttavia, per accedere a entrambi i tipi di risorse, sono necessari sia l’estensione App per la logica di Azure (consumo) sia le estensioni di App per la logica di Azure (Standard) per Visual Studio Code.

Selezionare l'icona Azure nella barra attività di Visual Studio Code. Nella Risorse, espandere la sottoscrizione e quindi espandere App per la logica, che mostra tutte le app per la logica distribuite in Azure per tale sottoscrizione.
2. Aprire il progetto da gestire. Dal menu di scelta rapida dell'app per la logica selezionare l'attività da eseguire.

Ad esempio, è possibile selezionare attività come l'arresto, l'avvio, il riavvio o l'eliminazione dell'app per la logica distribuita. È possibile disabilitare o abilitare un flusso di lavoro usando il portale di Azure.

Nota

Le operazioni di arresto e di eliminazione dell'app per la logica influiscono sulle istanze del flusso di lavoro in modi diversi. Per altre informazioni, vedere Considerazioni sull'arresto delle app per la logica e Considerazioni sull'eliminazione di app per la logica.
Per visualizzare tutti i flussi di lavoro nell'app per la logica, espandere l'app per la logica e quindi espandere il nodo Flussi di lavoro.
Per visualizzare un flusso di lavoro specifico, aprire il menu di scelta rapida del flusso di lavoro e selezionare Apri in Finestra di progettazione, che apre il flusso di lavoro in modalità di sola lettura.

Per modificare il flusso di lavoro, sono disponibili queste opzioni:
- In Visual Studio Code aprire il file workflow.json del progetto nella finestra di progettazione del flusso di lavoro, apportare le modifiche e ridistribuire l'app per la logica in Azure.
- Nel portale di Azure aprire l'app per la logica. È quindi possibile aprire, modificare e salvare il flusso di lavoro.
Per aprire l'app per la logica distribuita nel portale di Azure, aprire il menu di scelta rapida dell'app per la logica e selezionare Apri nel portale.

Il portale di Azure si apre nel browser, permette di accedere automaticamente al portale se si è connessi a Visual Studio Code e mostra l'app per la logica.

È anche possibile accedere separatamente al portale di Azure, usare la casella di ricerca del portale per trovare l'app per la logica e quindi selezionare l'app per la logica dall'elenco dei risultati.

Considerazioni sull'arresto delle app per la logica

L'arresto di un'app per la logica influisce sulle istanze del flusso di lavoro nei modi seguenti:

App per la logica di Azure annulla immediatamente tutte le esecuzioni in corso e in sospeso.
App per la logica di Azure non crea o esegue nuove istanze del flusso di lavoro.
I trigger non verranno attivati la volta successiva in cui vengono soddisfatte le condizioni. Tuttavia, gli stati del trigger ricordano i punti in cui l'app per la logica è stata arrestata. Quindi, se si riavvia l'app per la logica, i trigger vengono attivati per tutti gli elementi non elaborati dall'ultima esecuzione.

Per arrestare l'attivazione di un trigger sugli elementi non elaborati dall'ultima esecuzione, cancellare lo stato del trigger prima di riavviare l'app per la logica:
1. Nella barra attività di Visual Studio Code selezionare l'icona Azure per aprire la finestra di Azure.
2. Nella sezione Risorse espandere la sottoscrizione, che mostra tutte le app per la logica distribuite per tale sottoscrizione.
3. Espandere l'app per la logica e quindi espandere il nodo denominato Flussi di lavoro.
4. Aprire un flusso di lavoro e modificare qualsiasi parte del trigger del flusso di lavoro.
5. Salva le modifiche. Questo passaggio reimposta lo stato corrente del trigger.
6. Ripetere per ogni flusso di lavoro.
7. Al termine, riavviare l'app per la logica.

Considerazioni sull'eliminazione di app per la logica

L'eliminazione di un'app per la logica influisce sulle istanze del flusso di lavoro nei modi seguenti:

App per la logica di Azure annulla immediatamente le esecuzioni in corso e in sospeso, ma non esegue attività di pulizia nella risorsa di archiviazione usata dall'app.
App per la logica di Azure non crea o esegue nuove istanze del flusso di lavoro.
Se si elimina un flusso di lavoro e quindi si ricrea lo stesso flusso di lavoro, il flusso di lavoro ricreato non avrà gli stessi metadati del flusso di lavoro eliminato. Per aggiornare i metadati, è necessario salvare di nuovo qualsiasi flusso di lavoro che ha chiamato il flusso di lavoro eliminato. In questo modo, il chiamante ottiene le informazioni corrette per il flusso di lavoro ricreato. In caso contrario, le chiamate al flusso di lavoro ricreato hanno esito negativo con un errore Unauthorized. Questo comportamento si applica anche ai flussi di lavoro che usano artefatti negli account di integrazione e nei flussi di lavoro che chiamano funzioni di Azure.

Gestire le app per la logica distribuite nel portale

Dopo aver distribuito un'app per la logica nel portale di Azure da Visual Studio Code è possibile visualizzare tutte le app per la logica distribuite nella sottoscrizione di Azure, indipendentemente dal fatto che si tratti di risorse di app per la logica a consumo o Standard. Attualmente, ogni tipo di risorsa è organizzato e gestito come categorie separate in Azure. Per trovare le app per la logica Standard, seguire questa procedura:

Nella casella di ricerca del portale di Azure immettere app per la logica. Quando viene visualizzato l'elenco dei risultati, in Serviziselezionare App per la logica.
Nel riquadro App per la logica selezionare l'app per la logica distribuita da Visual Studio Code.

Il portale di Azure apre la pagina delle singole risorse per l'app per la logica selezionata.
Per visualizzare i flussi di lavoro in questa app per la logica, nel menu dell'app per la logica selezionare Flussi di lavoro.

Il riquadro Flussi di lavoro mostra tutti i flussi di lavoro nell'app per la logica corrente. Questo esempio mostra il flusso di lavoro creato in Visual Studio Code.
Per visualizzare un flusso di lavoro, nel riquadro Flussi di lavoro selezionare tale flusso di lavoro.

Viene aperto il riquadro del flusso di lavoro e vengono visualizzate altre informazioni e attività che è possibile eseguire su tale flusso di lavoro.

Ad esempio, per visualizzare i passaggi nel flusso di lavoro, selezionare Finestra di progettazione.

La finestra di progettazione del flusso di lavoro viene aperta e mostra il flusso di lavoro creato in Visual Studio Code. È ora possibile apportare modifiche a questo flusso di lavoro nel portale di Azure.

Aggiungere un altro flusso di lavoro nel portale

Tramite il portale di Azure è possibile aggiungere flussi di lavoro vuoti a una risorsa dell'app per la logica Standard distribuita da Visual Studio Code e compilare tali flussi di lavoro nel portale di Azure.

Nel portale di Azure, selezionare la risorsa dell'app per la logica Standard distribuita.
Nel menu delle risorse dell'app per la logica selezionare Flussi di lavoro. Nel riquadro Flussi di lavoro selezionare Aggiungi.
Nel riquadro Nuovo flusso di lavoro specificare il nome del flusso di lavoro. Selezionare Con stato o Senza stato > Crea.

Dopo che Azure distribuisce il nuovo flusso di lavoro, visualizzato nel riquadro Flussi di lavoro, selezionare il flusso di lavoro in modo che sia possibile gestire ed eseguire altre attività, ad esempio l'apertura della finestra di progettazione o la visualizzazione codice.

Ad esempio, l'apertura della finestra di progettazione per un nuovo flusso di lavoro mostra un'area di disegno vuota. È ora possibile compilare questo flusso di lavoro nel portale di Azure.

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.{yourWorkflowName}.operationOptions e impostare il valore su WithStatelessRunHistory, ad esempio:

Windows

{
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "dotnet",
      "Workflows.{yourWorkflowName}.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.{yourWorkflowName}.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 proprietà Workflows.{yourWorkflowName}.OperationOptionssu Noneoppure eliminare la proprietà e il relativo valore.

Abilitare la visualizzazione di monitoraggio nel portale di Azure

Dopo aver distribuito una risorsa app per la logica (Standard) da Visual Studio Code ad Azure, è possibile esaminare la cronologia di esecuzione e i dettagli disponibili per un flusso di lavoro in tale risorsa usando il portale di Azure e l'esperienza Monitoraggio per tale flusso di lavoro. Tuttavia, è prima necessario abilitare la funzionalità di visualizzazione Monitoraggiosu tale risorsa dell'app per la logica.

Nel portale di Azure, aprire la risorsa dell’app per la logica Standard.
Nel menu delle risorse dell'app per la logica, in APIselezionare 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, l'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 in vari modi. È possibile monitorare il flusso di lavoro usando Application Insights, che fornisce 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 questi dati per diagnosticare i problemi, configurare avvisi e creare grafici.

Per abilitare Application Insights in un'app per la logica distribuita o per esaminare i dati di Application Insights se già abilitati, seguire questa procedura:

Nel portale di Azure trovare l'app per la logica distribuita.
Nel menu dell'app per la logica, in Impostazioni, selezionare Application Insights.
Se Application Insights non è abilitato, nel riquadro Application Insights selezionare Attiva Application Insights. Dopo aver aggiornato il riquadro, nella parte inferiore selezionare Applica.

Se Application Insights è abilitato, nel riquadro Application Insights selezionare Visualizza i dati di Application Insights.

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

Eliminare elementi dalla finestra di progettazione

Per eliminare un elemento nel flusso di lavoro dalla finestra di progettazione, seguire questa procedura:

Selezionare l'elemento, aprire il menu di scelta rapida dell'elemento (MAIUSC+F10) e selezionare Elimina. Per confermare, scegliere OK.
Selezionare l'elemento e premere il tasto di eliminazione. Per confermare, scegliere OK.
Selezionare l'elemento in modo che venga aperto il riquadro dei dettagli per tale elemento. Nell'angolo superiore destro del riquadro aprire i puntini di sospensione (...) e selezionare Elimina. Per confermare, scegliere OK.

Suggerimento

Se il menu con i puntini di sospensione non è visibile, espandere la finestra di Visual Studio Code in modo che nel riquadro dei dettagli siano visualizzati i puntini di sospensione (...) nell'angolo superiore destro.

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 e quindi si è interrotto o si è eliminato il progetto, il bundle di estensione potrebbe non essere scaricato correttamente. Per verificare se questa causa è il problema, 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 '{operationID}'.
System.Private.CoreLib: The file 'C:\Users\{userName}\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{nomeutente}\AppData\Local\Temp\Functions\ExtensionBundlese 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.

Nota

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 alle 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.
Nel computer passare alla cartella seguente, che contiene le cartelle con controllo delle versioni per il bundle esistente:

...\Users\{your-username}\.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\{your-username}\.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 questo problema e modificare per l'URI più lungo, modificare le chiavi del Registro di sistema UrlSegmentMaxCount e UrlSegmentMaxLength nel computer seguendo la procedura seguente. Questi valori predefiniti della chiave sono descritti in questo argomento, 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 denominata vscodee 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
 }

Passaggi successivi

È consigliabile ricevere informazioni sulle esperienze con l'estensione App per la logica di Azure (Standard).

Per i bug o i problemi, creare i problemi in GitHub.
Per domande, richieste, commenti e altri commenti, usare questo modulo di feedback.

Condividi tramite

Creare un flusso di lavoro di app per la logica standard in App per la logica di Azure a tenant singolo usando Visual Studio Code

Prerequisiti

Accesso e connettività

Strumenti

Configurare Visual Studio Code

Connettersi all'account di Azure

Creare un progetto locale

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

Abilitare la creazione di connettori predefiniti

Aggiungere elementi personalizzati al progetto

Aggiungere mappe al progetto

Aggiunta di schemi al progetto

Aggiungere assembly al progetto

Eseguire la migrazione di progetti basati su NuGet per usare assembly "lib\*"

Aprire il file di definizione del flusso di lavoro nella finestra di progettazione

Aggiungere un trigger e azioni

Aggiungere il trigger Request

Aggiungere l'azione di Office 365 Outlook

Abilitare webhook in esecuzione in locale

Configurare l'inoltro delle chiamate usando ngrok

Configurare l'URL di inoltro nelle impostazioni dell'app

Gestire i punti di interruzione per il debug

Eseguire, testare ed eseguire il debug in locale

Restituire una risposta

Testare nuovamente l'app per la logica

Trovare i no,i di dominio per l'accesso al firewall

Distribuzione in Azure

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

Aggiungere un flusso di lavoro vuoto al progetto

Gestire le app per la logica distribuite in Visual Studio Code

Considerazioni sull'arresto delle app per la logica

Considerazioni sull'eliminazione di app per la logica

Gestire le app per la logica distribuite nel portale

Aggiungere un altro flusso di lavoro nel portale

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

Abilitare la visualizzazione di monitoraggio nel portale di Azure

Abilitare o aprire Application Insights dopo la distribuzione

Eliminare elementi dalla finestra di progettazione

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

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive