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

Si applica a: 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 App per la logica di Azure.

  Nota

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

  Per altre informazioni sul App per la logica di Azure a tenant singolo, vedere Ambiente del servizio multi-tenant e multi-tenant.

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 attivata, 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 la procedura descritta 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 flussi di lavoro in locale nell'ambiente di sviluppo.

Man 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 il 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

1. Scaricare e installare Visual Studio Code, gratuito.

2. Scaricare e installare l'estensione account 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.

3. 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 eventuali dipendenze esistenti. Per altre informazioni, vedere Introduzione 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: Auto Start Azurite e deselezionare la casella di controllo selezionata.
   .NET SDK 6.x.x.x	Include .NET Runtime 6.x.x, un prerequisito per il runtime di App per la logica di Azure (Standard).
   Funzioni di Azure Core Tools - Versione 4.x	Installa la versione in base al sistema operativo (Windows, macOS o Linux). Questi strumenti includono una versione dello stesso runtime che supporta il runtime 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.

   1. Scaricare e installare l'estensione App per la logica di Azure (Standard) per Visual Studio Code, a partire dalla versione 2.81.5).

   2. Nella barra attività di Visual Studio Code selezionare Estensioni. (Tastiera: premere CTRL+MAIUSC+X)

   3. Nel riquadro Estensioni aprire il menu con i puntini di sospensione (...) e selezionare Installa da VSIX.

   4. 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 .

   5. Quando viene visualizzata la richiesta seguente, selezionare Sì (scelta consigliata) per confermare di voler installare automaticamente le dipendenze necessarie:

      

   6. Ricaricare Visual Studio Code, se necessario.

   7. Verificare che le dipendenze siano visualizzate correttamente nella cartella seguente:

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

   8. Verificare le impostazioni di estensione seguenti in Visual Studio Code:

      1. Scegliere Preferenze> dal menu File Impostazioni.

      2. Nella scheda Utente selezionare Estensioni> App per la logica di Azure (Standard).

      3. Esaminare le impostazioni seguenti:

         Impostazione dell'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 di 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
         Auto Start Azurite	Attivata
         Ora di progettazione dell'avvio automatico	Attivata

   9. Se si dispone di un progetto di app per la logica esistente con attività definite personalizzate archiviate nel file con estensione 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 tasks.json file per usare le dipendenze necessarie. Se si sceglie di continuare, l'estensione sovrascrive il file tasks.json .

   10. 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 la finestra di progettazione del flusso di lavoro più velocemente, selezionare Sì (scelta consigliata).To open the workflow designer faster, select Yes (Recommended).
       Configurare Azurite per l'avvio automatico al lancio del progetto?	Per fare in modo che l'archiviazione di Azurite venga avviata automaticamente 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 viene 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 l'avvio dell'host func e 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 le variabili di ambiente e selezionare Modifica le variabili di ambiente di sistema.

        2. Nella casella Proprietà sistema selezionare Variabili di ambiente nella scheda Avanzate.

        3. Nella casella Variabili di ambiente selezionare PATH dall'elenco Variabili utente per <nome utente> 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: <File o percorso> non esistente
     • La convalida viene bloccata in <base al nome> della dipendenza.

     Seguire questa procedura per eseguire di nuovo il comando Convalidare e installare dipendenze binarie :

     1. Scegliere Riquadro comandi dal menu Visualizza.

     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 App per la logica di Azure che contiene un progetto Funzioni di Azure, viene visualizzato il messaggio seguente:

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

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

   Installare ogni dipendenza separatamente

   Dipendenza	Descrizione
   .NET SDK 6.x.x.x	Include .NET Runtime 6.x.x, un prerequisito per il runtime di App per la logica di Azure (Standard).
   Funzioni di Azure Core Tools - Versione 4.x	- Windows: usare la versione di Microsoft Installer (MSI), ovvero func-cli-X.X.XXXX-x*.msi. - macOS - Linux Questi strumenti includono una versione dello stesso runtime che supporta il runtime 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.

4. 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 di Visual Studio Code selezionare Estensioni.

   2. Nella casella di ricerca delle estensioni immettere azure logic apps 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: Installato .

      

      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 che 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 sezione App per la logica (Standard), che ora è stata spostata nella sezione Risorse .

5. 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.

6. Per testare il flusso di lavoro di esempio in questo articolo, è necessario uno strumento in grado di inviare chiamate all'endpoint creato dal trigger di richiesta. Se non si dispone di uno strumento di questo tipo, è possibile scaricare, installare e usare l'app Postman .

7. Se si creano le risorse dell'app per la logica con impostazioni che supportano l'uso di Application Insights, è possibile abilitare facoltativamente la registrazione diagnostica e la traccia 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.

Configurare Visual Studio Code

1. Per assicurarsi che tutte le estensioni siano installate correttamente, ricaricare o riavviare Visual Studio Code.

2. 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 Estensioni funzionalità>.

   3. Verificare che l'opzione Verifica automatica Aggiornamenti sia selezionata e che l'opzione Aggiornamento automatico sia impostata su Tutte le estensioni.

3. Verificare che l'impostazione App per la logica di Azure Standard: Project Runtime per l'estensione App per la logica di Azure (Standard) sia impostata 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 passare a> Estensioni> App per la logica di Azure (Standard).

      Ad esempio, è possibile trovare l'impostazione App per la logica di Azure Standard: Project Runtime qui o usare la casella di ricerca per trovare altre impostazioni:

      

Connettersi all'account di Azure

1. Nella barra delle attività di Visual Studio Code selezionare l'icona di Azure.

   

2. 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.

1. Nel computer creare una cartella locale vuota da usare per il progetto che verrà creato successivamente in Visual Studio Code.

2. In Visual Studio Code chiudere tutte le cartelle aperte.

3. Nella barra degli strumenti della sezione Area di lavoro della finestra di Azure scegliere Crea nuovo progetto dal menu App per la logica di Azure.

   

4. Se Windows Defender Firewall richiede di concedere l'accesso alla rete per Code.exe, ovvero Visual Studio Code e per func.exe, che è il Funzioni di Azure Core Tools, selezionare Reti private, ad esempio la rete>domestica o aziendale Consenti l'accesso.

5. Passare al percorso in cui è stata creata la cartella del progetto, selezionare la cartella e continuare.

   

6. 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.

   

7. Specificare un nome per il flusso di lavoro e premere INVIO. In questo esempio viene usato Stateful-Workflow come nome.

   

   Nota

   È possibile che venga visualizzato un errore denominato azureLogicAppsStandard.createNewProject con il messaggio di errore Impossibile scrivere nell'area di lavoro Impostazioni 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.

8. 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.

9. 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.

   

   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 di extensions.json, launch.json, settings.json e 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.
   workflow-designtime	Cartella	Contiene i file di impostazioni correlati all'ambiente di sviluppo.
   .funcignore	file	Contiene informazioni correlate all'Funzioni di Azure Core Tools installato.
   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 valori e impostazioni 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 usati da tutti i flussi di lavoro nella stessa app per la logica durante l'esecuzione, sia in locale che in Azure. Nota: quando si crea l'app per la logica, Visual Studio Code crea un file host.snapshot.*.json di backup 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, viene 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, stringa 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 usate dagli strumenti di sviluppo locali come appSettings valori. È possibile chiamare e fare riferimento a queste variabili di ambiente sia in fase di runtime che in fase di distribuzione usando le impostazioni e i parametri dell'app. Importante: il file local.settings.json può contenere segreti, quindi assicurarsi di escludere anche questo file dal controllo del codice sorgente del progetto.

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 bundle basato su estensione (Node.js) a basato su pacchetti NuGet (.NET).

Importante

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

1. 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.

   

2. 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 tenant singolo. Analogamente ai connettori predefiniti, ad esempio bus di servizio di Azure e SQL Server, questi connettori offrono velocità effettiva più elevata, bassa latenza, connettività locale ed esecuzione in modo nativo 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, seguire questa procedura:

1. Se non è già stato fatto, convertire il progetto da bundle basato su estensione (Node.js) a pacchetto Basato su NuGet (.NET).

2. Esaminare e seguire la procedura descritta nell'articolo App per la logica di Azure l'estendibilità del connettore predefinito In esecuzione via Internet.

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 artefatti nel progetto dell'app per la logica, in modo analogo a come caricare questi artefatti nel portale di Azure tramite il menu delle risorse dell'app per la logica in Artefatti, 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.

Aggiungere schemi al progetto

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

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
Assembly client/SDK (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 Transform 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 nella 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 project-name.csproj> per lavorare con i progetti che usano assembly:

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

Importante

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

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

1. Espandere la cartella del progetto del flusso di lavoro, denominata Stateful-Workflow in questo esempio, e aprire il file workflow.json .

2. Aprire il menu di scelta rapida del file workflow.json e selezionare Apri finestra di progettazione.

   

3. Dopo aver aperto l'elenco Abilita connettori in Azure, selezionare Usa 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 dei connettori gestiti, non i trigger. Sebbene sia possibile abilitare i connettori in Azure per il flusso di lavoro senza stato, la finestra di progettazione non mostra alcun trigger del connettore gestito da selezionare.

4. Dopo aver aperto l'elenco Seleziona sottoscrizione , selezionare la sottoscrizione di Azure da usare per il progetto di app per la logica.

   

5. Dopo aver aperto l'elenco dei gruppi di risorse, selezionare Crea nuovo gruppo di risorse.

   

6. Specificare un nome per il gruppo di risorse e premere INVIO. Questo esempio usa Fabrikam-Workflows-RG.

   

7. 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 relativa alla risoluzione dei problemi, progettazione non viene aperta.

   Dopo aver visualizzato la finestra di progettazione, viene visualizzata la finestra di progettazione Aggiungi un trigger .

8. 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.

   

9. Aggiungere quindi 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, viene visualizzata la finestra di progettazione 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:

• Trigger connettore predefinito 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.

• Azione del connettore gestito di Office 365 Outlook denominata Invia 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 predefinito Request denominata Response, che viene usata per inviare una risposta e restituire i dati al chiamante.

Aggiungere il trigger Request

1. 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.

2. 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.

3. 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 Office 365 Outlook

1. Nella finestra di progettazione, sotto il trigger Richiesta, selezionare il segno più (+) >Aggiungi un'azione.

2. Nell'elenco Runtime del riquadro Aggiungi un'azione visualizzata selezionare Condiviso in modo da visualizzare solo le azioni del connettore gestito disponibili.

3. Trovare l'azione connettore gestito di Office 365 Outlook denominata Invia 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.

   

4. Quando si apre il riquadro di autenticazione dell'azione, selezionare Accedi per creare una connessione all'account di posta elettronica.

   

5. 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 visualizzata la richiesta Microsoft, selezionare l'account utente per Office 365 Outlook e quindi selezionare Consenti l'accesso.

   2. Quando App per la logica di Azure chiede 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 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 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 si applica più perché il flusso di lavoro può eseguire l'autenticazione in fase di esecuzione usando l'identità gestita assegnata dal sistema automaticamente abilitata. Questa identità gestita è diversa dalle credenziali di autenticazione o stringa di connessione usate quando si crea una connessione. Se si disabilita questa identità gestita assegnata dal sistema, le connessioni non funzioneranno in fase di esecuzione.

6. Nella finestra di progettazione, se l'azione Invia un messaggio di posta elettronica non viene visualizzata, selezionare tale azione.

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

   

   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. In questo esempio viene usato il messaggio 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ì	Ciao 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 sulla finestra di progettazione. In caso contrario, Visual Studio Code non manterrà le modifiche.

8. 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 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 con ngrok

1. Vai al sito Web di ngrok. Iscriversi per ottenere un nuovo account o accedere al proprio account, se ne ha già uno.

2. Ottenere il token di autenticazione personale, che il client ngrok deve connettere ed autenticare l'accesso all'account.

   1. Per trovare la pagina del token di autenticazione, nel menu del dashboard dell'account espandere Autenticazione e selezionare Authtoken.

   2. Nella casella Authtoken copiare il token in una posizione sicura.

3. Dalla pagina di download di ngrok o dal dashboard dell'account scaricare la versione ngrok desiderata ed estrarre il file .zip. Per altre informazioni, vedere Passaggio 1: Decomprimere l'installazione.

4. Nel computer aprire lo strumento del prompt dei comandi. Passare al percorso in cui si dispone del file ngrok.exe .

5. Connessione il client ngrok all'account ngrok eseguendo il comando seguente. Per altre informazioni, vedere Passaggio 2: Connessione l'account.

   ngrok authtoken <your_auth_token>

6. Aprire il tunnel HTTP sulla porta localhost 7071 eseguendo il comando seguente. Per altre informazioni, vedere Passaggio 3: Attivarlo.

   ngrok http 7071

7. Nell'output trovare la riga seguente:

   http://<domain>.ngrok.io -> http://localhost:7071

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

Configurare l'URL di inoltro nelle impostazioni dell'app

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

   Questo esempio continua con il trigger HTTP + Webhook .

2. Quando viene visualizzata la richiesta per il percorso dell'endpoint host, immettere l'URL di inoltro (reindirizzamento) creato in precedenza.

   Nota

   Ignorando la richiesta viene visualizzato un avviso che indica che è necessario specificare l'URL di inoltro, quindi selezionare Configura e 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 di local.settings.json e selezionare Configura endpoint di reindirizzamento webhook. Viene ora visualizzato il prompt in modo da poter fornire l'URL di inoltro.

   Visual Studio Code aggiunge l'URL di inoltro al file local.settings.json nella cartella radice del progetto. Nell'oggetto Values viene visualizzata la proprietà denominata Workflows.WebhookRedirectHostUri ora e viene impostata sull'URL di inoltro, ad esempio:

   {
      "IsEncrypted": false,
      "Values": {
         "AzureWebJobsStorage": "UseDevelopmentStorage=true",
         "FUNCTIONS_WORKER_RUNTIME": "node",
         "FUNCTIONS_V2_COMPATIBILITY_MODE": "true",
         <...>
         "Workflows.WebhookRedirectHostUri": "http://xxxXXXXxxxXXX.ngrok.io",
         <...>
      }
   }
   

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

Quando si arresta la sessione di debug per un'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 raggiunge 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 raggiunge durante la sessione di debug, è possibile esaminare i risultati dell'azione prima che l'azione finisca l'esecuzione.

Per aggiungere un punto di interruzione, seguire questa procedura:

1. Aprire il file workflow.json per il flusso di lavoro di cui si vuole eseguire il debug.

2. 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, selezionare il punto di interruzione.

   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.

3. Per esaminare le informazioni disponibili quando si raggiunge un punto di interruzione, nella visualizzazione Esegui esaminare il riquadro Variabili .

4. 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 questa procedura 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.

1. Per eseguire il debug di un flusso di lavoro senza stato più facilmente, è possibile abilitare la cronologia di esecuzione per tale flusso di lavoro.

2. 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 scegliere Riquadro comandi dal menu Visualizza.

   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.

3. 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 viene avviata.

4. 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 dell'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>

      

5. Per testare l'URL di callback attivando il flusso di lavoro dell'app per la logica, aprire Postman o lo strumento preferito per la creazione e l'invio di richieste.

   Questo esempio continua usando Postman. Per altre informazioni, vedere Introduzione a Postman.

   1. Sulla barra degli strumenti postman selezionare Nuovo.

      

   2. Nel riquadro Crea nuovo, in Blocchi predefiniti, selezionare Richiesta.

   3. Nella finestra Salva richiesta, in Nome richiesta, specificare un nome per la richiesta, ad esempio, Trigger del flusso di lavoro di test.

   4. In Selezionare una raccolta o una cartella in cui salvare selezionare Crea raccolta.

   5. In Tutte le raccolte specificare un nome per la raccolta da creare per organizzare le richieste, premere INVIO e selezionare Salva in <nome> raccolta. Questo esempio usa le richieste di App per la logica come nome della raccolta.

      In Postman viene aperto il riquadro della richiesta in modo che sia possibile inviare una richiesta all'URL di callback per il trigger di richiesta.

      

   6. Tornare a Visual Studio Code. Nella pagina di panoramica del flusso di lavoro copiare il valore della proprietà URL di callback.

   7. Torna a Postman. Nel riquadro della richiesta, accanto all'elenco dei metodi, che attualmente mostra GET come metodo di richiesta predefinito, incollare l'URL di callback copiato in precedenza nella casella dell'indirizzo e selezionare Invia.

      

      Il flusso di lavoro dell'app per la logica di esempio invia un messaggio di posta elettronica simile a questo esempio:

      

6. 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.

   

   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
   Interrotta	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 dei limiti di azione o del piano tariffario corrente. Suggerimento: se si configura la registrazione diagnostica, è possibile ottenere informazioni sugli 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, controllato dall'impostazione Conservazione cronologia di esecuzione in giorni. La durata di un'esecuzione viene calcolata usando l'ora di inizio dell'esecuzione e il limite di durata dell'esecuzione all'ora di inizio. Nota: se la durata dell'esecuzione supera anche il limite di conservazione della cronologia di esecuzione corrente, controllato anche dall'impostazione Conservazione 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 il 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.

7. Per esaminare gli stati per ogni passaggio di un'esecuzione specifica e gli input e gli output del passaggio, selezionare il pulsante con i puntini di sospensione (...) per l'esecuzione e selezionare Mostra esecuzione.

   

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

   

   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 "400 Richiesta non valida".

   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
   Interrotta	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 runAfter condizione che richiede che l'azione precedente venga completata correttamente prima che l'azione corrente possa essere eseguita.
   Completato	L'azione è riuscita.
   Operazione completata con 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.

8. Per esaminare gli input e gli output per ogni passaggio, selezionare il passaggio da esaminare. Per esaminare ulteriormente gli input e gli output non elaborati per tale passaggio, selezionare Mostra input non elaborati o Mostra output non elaborati.

   

9. 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 Richiesta, è possibile restituire una risposta al chiamante che ha inviato una richiesta al flusso di lavoro usando l'azione predefinita Richiesta denominata Risposta.

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

   Viene visualizzato il riquadro Aggiungi un'azione in modo che sia possibile selezionare l'azione successiva.

2. Nell'elenco Runtime del riquadro Aggiungi un'azione selezionare In-App. Trovare e aggiungere l'azione Risposta .

   Dopo che l'azione Risposta viene visualizzata nella finestra di progettazione, viene aperto automaticamente il riquadro dei dettagli dell'azione.

   

3. Nella scheda Parametri specificare le informazioni necessarie per la funzione che si desidera chiamare.

   In questo esempio viene restituito il valore del parametro Body , 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 elettronica selezionare Corpo.

      

      Al termine, la proprietà Corpo dell'azione di risposta è ora impostata sul valore di output Corpo dell'azione Invia un messaggio di posta elettronica.

      

4. Nella finestra di progettazione selezionare Salva.

Eseguire il retest dell'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.

1. Nella barra delle attività di Visual Studio Code aprire il menu Esegui e selezionare Avvia debug (F5).

2. In Postman o nello strumento per la creazione e l'invio di richieste inviare un'altra richiesta per attivare il flusso di lavoro.

3. 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 con i 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.

   

4. Per arrestare la sessione di debug, nel menu Esegui selezionare Arresta debug (MAIUSC + F5).

Trovare i nomi 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:

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

2. Per ogni connessione creata, copiare e salvare il valore della connectionRuntimeUrl proprietà in un punto sicuro in modo da poter configurare il firewall con queste informazioni.

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

   • 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 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

1. Nella barra delle attività di Visual Studio Code selezionare l'icona di Azure per aprire la finestra di Azure.

2. Nella barra degli strumenti della sezione Area di lavoro della finestra di Azure scegliere Distribuisci nell'app per la logica dal menu App per la logica di Azure.

   

3. Se richiesto, selezionare la sottoscrizione di Azure da usare per la distribuzione dell'app per la logica.

4. 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 (Standard) distribuita in precedenza, se presente

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

   

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

   1. 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.

      

   2. 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.

      

   3. 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.

   4. 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.

   5. Per i flussi di lavoro con stato, selezionare Crea nuovo account di archiviazione o un account di archiviazione esistente.

      

   6. Se le impostazioni di creazione e distribuzione dell'app per la logica supportano l'uso di Application Insights, è possibile abilitare facoltativamente la registrazione diagnostica e la traccia 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:

      1. Selezionare una risorsa di Application Insights esistente o Crea nuova risorsa di Application Insights.

      2. Nella portale di Azure passare alla risorsa di Application Insights.

      3. Nel menu della risorsa selezionare Panoramica. Trovare e copiare il valore della chiave di strumentazione.

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

      5. Nell'oggetto Values aggiungere la APPINSIGHTS_INSTRUMENTATIONKEY proprietà e impostare il valore sulla chiave di strumentazione, ad esempio:

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

         Suggerimento

         È possibile verificare se i nomi di trigger e azione vengono visualizzati correttamente nell'istanza di Application Insights.

         1. Nella portale di Azure passare alla risorsa di Application Insights.

         2. Nel menu delle risorse, in Ricerca, selezionare 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 WorkflowName.ActionName formato, questi duplicati usano il nome del flusso di lavoro come nome dell'operazione e hanno origine dall'host Funzioni di Azure.

      6. 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.
         • Archiviazione'attività della richiesta, ad esempio esito positivo o negativo.
         • Attività della richiesta HTTP, ad esempio in ingresso, in uscita, riuscita e 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 acquisisce i messaggi più dettagliati, mentre il livello acquisisce l'attività generale nel flusso di lavoro, ad esempio quando l'app Information per la logica, il Trace flusso di lavoro, il trigger e le azioni vengono avviate e interrotte. 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 logLevel oggetto che include la Host.Triggers.Workflow proprietà , 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.

6. 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 nella 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:

1. Nella barra delle attività di Visual Studio Code selezionare l'icona di Azure.

2. Nella barra degli strumenti della sezione Area di lavoro della finestra di Azure scegliere Crea flusso di lavoro dal menu App per la logica di Azure.

3. Selezionare il tipo di flusso di lavoro da aggiungere: con stato o senza stato

4. 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 necessarie sia le estensioni App per la logica di Azure (consumo) che le estensioni App per la logica di Azure (Standard) per Visual Studio Code.

1. Nella barra delle attività di Visual Studio Code selezionare l'icona di Azure. In 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 l'app per la logica che si vuole 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 dell'app per la logica e eliminazione influiscono sulle istanze del flusso di lavoro in modi diversi. Per altre informazioni, vedere Considerazioni per arrestare le app per la logica e Considerazioni per l'eliminazione di app per la logica.

   

3. 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 .

4. Per visualizzare un flusso di lavoro specifico, aprire il menu di scelta rapida del flusso di lavoro e selezionare Apri in 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 di workflow.json del progetto nella finestra di progettazione del flusso di lavoro, apportare le modifiche e ridistribuire l'app per la logica in Azure.

   • Nella portale di Azure aprire l'app per la logica. È quindi possibile aprire, modificare e salvare il flusso di lavoro.

5. Per aprire l'app per la logica distribuita nella 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, accede 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 delle attività di Visual Studio Code selezionare l'icona di 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 ricampionare 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 Unauthorized errore. 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 presenti nella sottoscrizione di Azure, indipendentemente dal fatto che si tratti di risorse per l'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:

1. Nella casella di ricerca portale di Azure immettere app per la logica. Quando viene visualizzato l'elenco dei risultati, in Servizi selezionare App per la logica.

   

2. 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.

   

3. Per visualizzare i flussi di lavoro in questa app per la logica, scegliere Flussi di lavoro dal menu dell'app per la logica.

   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.

   

4. Per visualizzare un flusso di lavoro, nel riquadro Flussi di lavoro selezionare il 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 Progettazione.

   

   La finestra di progettazione del flusso di lavoro viene aperta e mostra il flusso di lavoro compilato 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 nella portale di Azure.

1. Nella portale di Azure selezionare la risorsa dell'app per la logica Standard distribuita.

2. Nel menu delle risorse dell'app per la logica selezionare Flussi di lavoro. Nel riquadro Flussi di lavoro selezionare Aggiungi.

   

3. Nel riquadro Nuovo flusso di lavoro specificare il nome del flusso di lavoro. Selezionare Con stato o Crea senza>stato.

   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 nella portale di Azure.

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

2. Aggiungere la Workflows.{yourWorkflowName}.operationOptions proprietà e impostare il valore su WithStatelessRunHistory, ad esempio:

   Windows

   {
      "IsEncrypted": false,
      "Values": {
         "AzureWebJobsStorage": "UseDevelopmentStorage=true",
         "FUNCTIONS_WORKER_RUNTIME": "node",
         "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": "node",
         "Workflows.{yourWorkflowName}.OperationOptions": "WithStatelessRunHistory"
      }
   }
   

3. Nella cartella di progetto denominata workflow-designtime aprire il file local.settings.json e apportare la stessa modifica.

4. Per disabilitare la cronologia di esecuzione al termine, impostare la Workflows.{yourWorkflowName}.OperationOptionsproprietà su Noneo eliminare la proprietà e il relativo valore.

Abilitare la visualizzazione di monitoraggio nella portale di Azure

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

1. Nella portale di Azure aprire la risorsa dell'app per la logica Standard.

2. Nel menu delle risorse dell'app per la logica, in API selezionare CORS.

3. Nel riquadro CORS, in Origini consentite, aggiungere il carattere jolly (*).

4. 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.

Se le impostazioni di creazione e distribuzione dell'app per la logica supportano l'uso di Application Insights, è possibile abilitare facoltativamente la registrazione diagnostica e la traccia 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 Application Insights in un'app per la logica distribuita o per esaminare i dati di Application Insights se già abilitati, seguire questa procedura:

1. Nella portale di Azure trovare l'app per la logica distribuita.

2. Nel menu dell'app per la logica, in Impostazioni selezionare Application Insights.

3. 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 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:

• App per la logica di Azure Esecuzione via Internet - Monitorare con Application Insights - Parte 1
• App per la logica di Azure Esecuzione via Internet - Monitorare con Application Insights - Parte 2

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 il riquadro dei dettagli mostri 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 l'errore "Impossibile avviare l'ora di progettazione del flusso di lavoro". Se in precedenza si tentava di aprire la finestra di progettazione e quindi si interrompeva o si eliminava il progetto, il bundle di estensione potrebbe non essere scaricato correttamente. Per verificare se questa causa è il problema, seguire questa procedura:

1. In Visual Studio Code aprire la finestra Output. Scegliere Output dal menu Visualizza.

2. Nell'elenco nella barra del titolo della finestra Output selezionare App per la logica di Azure (Standard) in modo da poter esaminare l'output dall'estensione, ad esempio:

   

3. 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\ExtensionBundles e riprovare ad aprire il file workflow.json nella finestra di progettazione.

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

L'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, il connettore e le azioni operazioni per le funzioni di Azure non vengono visualizzate nella selezione della finestra di progettazione, a meno che non sia stata abilitata o selezionata l'opzione Usa 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 Connessione ors da Azure.

Per correggere il bundle obsoleto, seguire questa procedura per eliminare il bundle obsoleto, che rende Visual Studio Code aggiornare 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 le app per la logica create usando il portale di Azure. Vedere Trigger e azioni supportati mancanti nella finestra di progettazione nel portale di Azure.

1. Salvare qualsiasi lavoro che non si vuole perdere e chiudere Visual Studio.

2. 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

3. 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.

4. 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

5. Eliminare la cartella della versione per il pacchetto precedente.

6. 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 UrlSegmentMaxCount chiavi del Registro di sistema 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.

1. Nel computer aprire la finestra Esegui ed eseguire il regedit comando , che apre l'editor del Registro di sistema.

2. Nella casella Controllo account utente selezionare Sì per consentire le modifiche apportate al computer.

3. Nel riquadro sinistro, in Computer espandere i nodi lungo il percorso, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters e quindi selezionare Parametri.

4. Nel riquadro destro trovare le UrlSegmentMaxCount chiavi del Registro di sistema e UrlSegmentMaxLength .

5. Aumentare questi valori di chiave in modo che gli URI possano contenere i nomi da usare. Se queste chiavi non esistono, aggiungerle alla cartella Parameters seguendo questa procedura:

   1. Dal 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 della chiave dati Valore desiderato in formato esadecimale o decimale. Ad esempio, 400 in esadecimale equivale a 1024 in decimale.

   5. Per aggiungere il valore della UrlSegmentMaxLength chiave, ripetere questi passaggi.

   Dopo aver aumentato o aggiunto questi valori di chiave, l'editor del Registro di sistema è simile all'esempio seguente:

   

6. 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 per ignorare la generazione dei simboli.

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

2. Nell'attività seguente eliminare la riga , "dependsOn: "generateDebugSymbols"insieme alla virgola che termina la 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

Vorremmo ascoltare le vostre 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.