Risolvere i problemi e diagnosticare gli errori del flusso di lavoro nelle App per la logica di Azure

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

Il flusso di lavoro dell'app per la logica genera informazioni che consentono di diagnosticare e eseguire il debug dei problemi nell'app. È possibile diagnosticare il flusso di lavoro esaminando gli input, gli output e altre informazioni per ogni passaggio del flusso di lavoro usando la portale di Azure. In alternativa, è possibile aggiungere alcuni passaggi a un flusso di lavoro per il debug di runtime.

Controllare la cronologia dei trigger

Ogni esecuzione del flusso di lavoro inizia con un trigger, che viene generato in una pianificazione o attende una richiesta o un evento in ingresso. La cronologia dei trigger elenca tutti i tentativi di trigger effettuati dal flusso di lavoro e informazioni sugli input e gli output per ogni tentativo di trigger. Se il trigger non viene attivato, provare i passaggi seguenti.

Consumo

1. Per controllare lo stato del trigger nell'app per la logica di consumo, esaminare la cronologia dei trigger. Per visualizzare altre informazioni sul tentativo di trigger, selezionare l'evento trigger, ad esempio:

   

2. Controllare gli input del trigger per verificare che vengano visualizzati come previsto. Nel riquadro Cronologia , in Collegamento Input selezionare il collegamento, che mostra il riquadro Input .

   Gli input dei trigger includono i dati previsti dal trigger e richiedono l'avvio del flusso di lavoro. La verifica di questi input consente di determinare se gli input del trigger sono corretti e se la condizione è stata soddisfatta in modo che il flusso di lavoro possa continuare.

   

3. Controllare gli output dei trigger, se presenti, per verificare che vengano visualizzati come previsto. Nel riquadro Cronologia , nel collegamento Output selezionare il collegamento, che mostra il riquadro Output .

   Gli output dei trigger includono i dati che il trigger passa al passaggio successivo nel flusso di lavoro. La revisione di questi output consente di determinare se i valori corretti o previsti passati al passaggio successivo nel flusso di lavoro.

   Ad esempio, un messaggio di errore indica che il feed RSS non è stato trovato:

   

   Suggerimento

   Se si trovano contenuti non riconosciuti, altre informazioni sui diversi tipi di contenuto in App per la logica di Azure.

Standard

1. Per controllare lo stato del trigger nell'app per la logica Standard, esaminare la cronologia dei trigger. Per visualizzare altre informazioni sul tentativo di trigger, selezionare l'evento trigger, ad esempio:

   

2. Controllare gli input del trigger per verificare che vengano visualizzati come previsto. Nel riquadro Cronologia , in Collegamento Input selezionare il collegamento, che mostra il riquadro Input .

   Gli input dei trigger includono i dati previsti dal trigger e richiedono l'avvio del flusso di lavoro. La verifica di questi input consente di determinare se gli input del trigger sono corretti e se la condizione è stata soddisfatta in modo che il flusso di lavoro possa continuare.

   

3. Controllare gli output dei trigger, se presenti, per verificare che vengano visualizzati come previsto. Nel riquadro Cronologia , nel collegamento Output selezionare il collegamento, che mostra il riquadro Output .

   Gli output dei trigger includono i dati che il trigger passa al passaggio successivo nel flusso di lavoro. La revisione di questi output consente di determinare se i valori corretti o previsti passati al passaggio successivo nel flusso di lavoro.

   Ad esempio, un messaggio di errore indica che il feed RSS non è stato trovato:

   

   Suggerimento

   Se si trovano contenuti non riconosciuti, altre informazioni sui diversi tipi di contenuto in App per la logica di Azure.

Controllare la cronologia delle esecuzioni del flusso di lavoro

Ogni volta che il trigger viene attivato, App per la logica di Azure crea un'istanza del flusso di lavoro ed esegue tale istanza. Se un'esecuzione ha esito negativo, provare i passaggi seguenti in modo da poter esaminare ciò che è successo durante l'esecuzione. È possibile esaminare lo stato, gli input e gli output per ogni passaggio del flusso di lavoro.

Consumo

1. Per controllare lo stato di esecuzione del flusso di lavoro nell'app per la logica consumo, esaminare la cronologia delle esecuzioni. Per visualizzare altre informazioni su un'esecuzione non riuscita, inclusi tutti i passaggi in esecuzione nello stato, selezionare l'esecuzione non riuscita.

   

2. Dopo aver visualizzato tutti i passaggi dell'esecuzione, selezionare ogni passaggio per espandere le forme.

   

3. Esaminare gli input, gli output e tutti i messaggi di errore per il passaggio non riuscito.

   

   Ad esempio, lo screenshot seguente mostra gli output dell'azione RSS non riuscita.

   

Standard

1. Per controllare lo stato di esecuzione del flusso di lavoro nell'app per la logica Standard, esaminare la cronologia delle esecuzioni. Per visualizzare altre informazioni su un'esecuzione non riuscita, inclusi tutti i passaggi in esecuzione nello stato, selezionare l'esecuzione non riuscita.

   

2. Dopo aver visualizzato tutti i passaggi dell'esecuzione, selezionare ogni passaggio per esaminare i dettagli.

   

3. Esaminare gli input, gli output e tutti i messaggi di errore per il passaggio non riuscito.

   

   Ad esempio, lo screenshot seguente mostra gli output dell'azione RSS non riuscita.

   

Eseguire il debug al runtime

Per facilitare il debug, è possibile aggiungere passaggi di diagnostica a un flusso di lavoro dell'app per la logica, oltre a esaminare il trigger e la cronologia delle esecuzioni. Ad esempio, è possibile aggiungere passaggi che usano il servizio Tester Webhook , in modo da poter controllare le richieste HTTP e determinare le dimensioni, la forma e il formato esatto.

1. In un browser passare al sito Webhook Tester e copiare l'URL univoco generato.

2. Nell'app per la logica aggiungere un'azione HTTP POST con qualsiasi contenuto del corpo da verificare, ad esempio un'espressione o l'output di un altro passaggio.

3. Incollare l'URL da Webhook Tester nell'azione HTTP POST.

4. Per esaminare il modo in cui Le app per la logica di Azure generano e formano una richiesta, eseguire il flusso di lavoro dell'app per la logica. Per altre informazioni, è quindi possibile rivedere il sito Webhook Tester.

Prestazioni - Domande frequenti

Perché la durata dell'esecuzione del flusso di lavoro è più lunga della somma di tutte le durate dell'azione del flusso di lavoro?

L'sovraccarico della pianificazione esiste quando si eseguono azioni, mentre il tempo di attesa tra le azioni può verificarsi a causa del carico del sistema back-end. Una durata dell'esecuzione del flusso di lavoro include questi tempi di pianificazione e tempi di attesa insieme alla somma di tutte le durate dell'azione.

In genere, il flusso di lavoro viene completato entro 10 secondi. Ma, a volte, il completamento può richiedere molto più tempo. Come è possibile assicurarsi che il flusso di lavoro venga sempre completato entro 10 secondi?

• Non esiste alcuna garanzia di contratto di servizio sulla latenza.

• I flussi di lavoro a consumo vengono eseguiti in App per la logica di Azure multi-tenant, quindi altri carichi di lavoro dei clienti potrebbero influire negativamente sulle prestazioni del flusso di lavoro.

• Per prestazioni più prevedibili, è possibile considerare la creazione di flussi di lavoro Standard, che vengono eseguiti in App per la logica di Azure a tenant singolo. Sarà necessario avere più controllo per aumentare o ridurre le prestazioni.

L'azione si verifica dopo 2 minuti. Come è possibile aumentare il valore del timeout?

Il valore di timeout dell'azione non può essere modificato ed è fisso a 2 minuti. Se si usa l'azione HTTP e si è proprietari del servizio chiamato dall'azione HTTP, è possibile modificare il servizio per evitare il timeout di 2 minuti usando il modello asincrono. Per altre informazioni, vedere Eseguire attività a esecuzione prolungata con il modello di azione di polling.

Problemi comuni - App per la logica standard

Artefatti inaccessibili nell'account di archiviazione di Azure

Le app per la logica standard archiviano tutti gli artefatti in un account di archiviazione di Azure. È possibile che vengano visualizzati gli errori seguenti se questi artefatti non sono accessibili. Ad esempio, l'account di archiviazione stesso potrebbe non essere accessibile o l'account di archiviazione è dietro un firewall, ma non è configurato alcun endpoint privato per i servizi di archiviazione da usare.

portale di Azure posizione	Errore
Riquadro Panoramica	- System.private.corelib:Access al percorso 'C:\home\site\wwwroot\hostj.son viene negato - Azure.Storage.Blobs: questa richiesta non è autorizzata a eseguire questa operazione
Riquadro Flussi di lavoro	- Impossibile raggiungere il runtime dell'host. Dettagli errore, Codice: 'BadRequest', Messaggio: 'Rilevato un errore (InternalServerError) dal runtime host'. - Impossibile raggiungere il runtime dell'host. Dettagli errore, Codice: 'BadRequest', Messaggio: 'Errore (ServiceUnavailable) dal runtime host'. - Impossibile raggiungere il runtime dell'host. Dettagli errore, Codice: 'BadRequest', Messaggio: 'Errore (BadGateway) dal runtime host'.
Durante la creazione e l'esecuzione del flusso di lavoro	- Impossibile salvare il flusso di lavoro - Errore nella finestra di progettazione: GetCallFailed. Operazioni di recupero non riuscite - Chiamata ajaxExtended non riuscita

Opzioni di risoluzione dei problemi

L'elenco seguente include possibili cause di questi errori e passaggi per la risoluzione dei problemi.

• Per un account di archiviazione pubblico, controllare l'accesso all'account di archiviazione nei modi seguenti:

  • Controllare la connettività dell'account di archiviazione usando Azure Storage Explorer.

  • Nelle impostazioni dell'app per l'app per la logica verificare la stringa di connessione dell'account di archiviazione nelle impostazioni dell'app , AzureWebJobsStorage e WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Per altre informazioni, vedere Impostazioni host e app per le app per la logica in App per la logica di Azure a tenant singolo.

  Se la connettività non riesce, controllare se la chiave di firma di accesso condiviso nella stringa di connessione è la più recente.

• Per un account di archiviazione protetto da un firewall, controllare l'accesso all'account di archiviazione nei modi seguenti:

  • Se le restrizioni del firewall sono abilitate nell'account di archiviazione, controllare se gli endpoint privati sono configurati per i servizi blob, file, tabelle e archiviazione code.

  • Controllare la connettività dell'account di archiviazione usando Azure Storage Explorer.

  Se si verificano problemi di connettività, procedere con la procedura seguente:

  1. Nella stessa rete virtuale integrata con l'app per la logica creare una macchina virtuale di Azure, che è possibile inserire in una subnet diversa.

  2. Da un prompt dei comandi eseguire nslookup per verificare che i servizi di archiviazione BLOB, file, tabelle e code vengano risolti negli indirizzi IP previsti.

     Sintassi: nslookup [StorageaccountHostName] [OptionalDNSServer]

     BLOB: nslookup {StorageaccountName}.blob.core.windows.net

     File: nslookup {StorageaccountName}.file.core.windows.net

     Tavolo: nslookup {StorageaccountName}.table.core.windows.net

     Coda: nslookup {StorageaccountName}.queue.core.windows.net

     • Se il servizio di archiviazione ha un endpoint di servizio, il servizio viene risolto in un indirizzo IP pubblico.

     • Se il servizio di archiviazione ha un endpoint privato, il servizio viene risolto nei rispettivi indirizzi IP privati del controller di interfaccia di rete.If the storage service has a private endpoint, the service resolves to the respective network interface controller (NIC) private addresses.

  3. Se le query DNS (Domain Name Server) precedenti vengono risolte correttamente, eseguire i comandi psping o tcpping per controllare la connettività all'account di archiviazione sulla porta 443:

     Sintassi: psping [StorageaccountHostName] [Port] [OptionalDNSServer]

     BLOB: psping {StorageaccountName}.blob.core.windows.net:443

     File: psping {StorageaccountName}.file.core.windows.net:443

     Tavolo: psping {StorageaccountName}.table.core.windows.net:443

     Coda: psping {StorageaccountName}.queue.core.windows.net:443

  4. Se ogni servizio di archiviazione è risolvibile dalla macchina virtuale di Azure, trovare il DNS usato dalla macchina virtuale per la risoluzione.

     1. Impostare l'impostazione dell'app per la logica WEBSITE_DNS_SERVER sul DNS e verificare che il DNS funzioni correttamente.

     2. Verificare che l'integrazione della rete virtuale sia configurata correttamente con la rete virtuale e la subnet appropriate nell'app per la logica Standard.

  5. Se si usano zone DNS di Azure private per i servizi endpoint privati dell'account di archiviazione, verificare che sia stato creato un collegamento di rete virtuale alla rete virtuale integrata dell'app per la logica.

Per altre informazioni, vedere Distribuire l'app per la logica Standard in un account di archiviazione protetto da un firewall usando endpoint privati o di servizio.

Passaggi successivi

• Monitorare l'app per la logica