Condividi tramite

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

  • Articolo

Si applica a: App per la logica di Azure (a consumo e standard)

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

Controllare la cronologia dei trigger

Ogni esecuzione del flusso di lavoro inizia con un trigger, che viene attivato in base a 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 le informazioni sugli input e sugli output per ogni tentativo di trigger. Se il trigger non viene attivato, provare i passaggi seguenti.

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

    Screenshot che mostra il portale di Azure con la cronologia dei trigger del flusso di lavoro dell'app per la logica a consumo.

  2. Controllare gli input del trigger per verificare che vengano visualizzati come previsto. Nel riquadro Cronologia, sotto la voce Collegamento input selezionare il collegamento che mostra il riquadro Inputs.

    Gli input dei trigger includono i dati previsti dal trigger e richiedono l'avvio del flusso di lavoro. La revisione di tali input consente di determinare se gli input del trigger sono corretti e se la condizione è stata soddisfatta, affinché il flusso di lavoro possa continuare.

    Screenshot che mostra gli input del trigger del flusso di lavoro dell'app per la logica a consumo.

  3. Controllare gli output dei trigger, se presenti, per verificare che vengano visualizzati come previsto. Nel riquadro Cronologia, sotto la voce Collegamento output selezionare il collegamento che mostra il riquadro Outputs.

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

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

    Screenshot che mostra gli output dei trigger del flusso di lavoro dell'app per la logica a consumo.

    Suggerimento

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

Controllare la cronologia di esecuzione 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 per rivedere ciò che è successo durante l'esecuzione. È possibile esaminare lo stato, gli input e gli output per ogni passaggio del flusso di lavoro.

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

    Screenshot che mostra il portale di Azure con le esecuzioni del flusso di lavoro dell'app per la logica a consumo e un'esecuzione non riuscita selezionata.

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

    Screenshot che mostra il flusso di lavoro dell'app per la logica a consumo con il passaggio non riuscito selezionato.

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

    Screenshot che mostra il flusso di lavoro dell'app per la logica a consumo con i dettagli dei passaggi non riusciti.

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

    Screenshot che mostra il flusso di lavoro dell'app per la logica a consumo con gli output dei passaggi non riusciti.

Eseguire il debug al runtime

Per faciltiare il debug, è possibile aggiungere passaggi di diagnostica a un flusso di lavoro dell'app per la logica, oltre a rivedere la cronologia dei trigger e delle esecuzioni. È possibile ad esempio aggiungere passaggi che usano il servizio Webhook Tester, in modo da poter controllare le richieste HTTP e determinarne le esatte dimensioni, forma e formato.

  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 rivedere le modalità con cui App per la logica di Azure genera e crea 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 è superiore alla somma di tutte le durate dell'azione del flusso di lavoro?

L'overhead di pianificazione avviene durante l'esecuzione di 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 di attesa, oltre 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 i carichi di lavoro di altri clienti potrebbero influire negativamente sulle prestazioni del flusso di lavoro.

  • Per prestazioni più prevedibili, è consigliabile creare flussi di lavoro Standard, che vengono eseguiti in App per la logica di Azure a tenant singolo. Si disporrà di un maggiore controllo per aumentare o aumentare le prestazioni.

Timeout di un'azione dopo 2 minuti. Come è possibile aumentare il valore di timeout?

Il valore di timeout dell'azione non può essere modificato ed è fissato 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 con l'utilizzo del 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. Se questi artefatti non sono accessibili, è possibile che vengano visualizzati gli errori seguenti. Ad esempio, l'account di archiviazione stesso potrebbe non essere accessibile o trovarsi dietro un firewall, ma non è configurato alcun endpoint privato per l'uso dei servizi di archiviazione.

posizione portale di Azure Error
Riquadro Panoramica - System.private.corelib:Accesso al percorso 'C:\home\site\wwwroot\host.json negato

- Azure.Storage.Blobs: questa richiesta non è autorizzata a eseguire questa operazione
Riquadro Workflows - Impossibile raggiungere il runtime host. Dettagli errore, Codice: 'BadRequest', Messaggio: 'Rilevato un errore (InternalServerError) dal runtime host.'

- Impossibile raggiungere il runtime host. Dettagli errore, Codice: 'BadRequest', Messaggio: 'Rilevato un errore (ServiceUnavailable) dal runtime host'.

- Impossibile raggiungere il runtime host. Dettagli errore, Codice: 'BadRequest', Messaggio: 'Rilevato un errore (BadGateway) dal runtime host'.
Durante la creazione e l'esecuzione del flusso di lavoro - Non è stato possibile salvare il flusso di lavoro

- Errore nel Designer: 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 i passaggi da applicare per la risoluzione dei problemi.

  • Per un account di archiviazione pubblico, controllare l'accesso all'account di archiviazione con le modalità seguenti:

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

    Importante

    Quando si dispone di informazioni sensibili, ad esempio stringhe di connessione che includono nomi utente e password, assicurarsi di usare il flusso di autenticazione più sicuro disponibile. Ad esempio, nei flussi di lavoro dell'app per la logica Standard, i tipi di dati sicuri, ad esempio securestring e secureobject, non sono supportati. Microsoft consiglia di autenticare l'accesso alle risorse di Azure con un'identità gestita, quando possibile, e assegnare un ruolo con i privilegi minimi necessari.

    Se questa funzionalità non è disponibile, assicurarsi di proteggere le stringhe di connessione tramite altre misure, ad esempio

Azure Key Vault, che è possibile usare con le impostazioni dell'app. È quindi possibile fare riferimento direttamente a stringhe sicure, ad esempio stringhe di connessione e chiavi. Analogamente ai modelli ARM, in cui è possibile definire le variabili di ambiente in fase di distribuzione, è possibile indicare le impostazioni dell'app all'interno della definizione del flusso di lavoro dell'app per la logica. È quindi possibile acquisire valori di infrastruttura generati dinamicamente, ad esempio endpoint di connessione, stringhe di archiviazione e altri. Per altre informazioni, vedere Tipi di applicazione per Microsoft Identity Platform.

  • Per un account di archiviazione protetto da un firewall, controllare l'accesso all'account di archiviazione con le modalità seguenti:

    • Se le restrizioni del firewall sono abilitate nell'account di archiviazione, verificare 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 riscontrano problemi di connettività, eseguire la procedura seguente:

    1. Nella stessa rete virtuale integrata nell'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 BLOB, file, tabelle e archiviazione 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

      Tabella: 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 (NIC).

    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

      Tabella: 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. Configurare 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 un'app per la logica Standard in un account di archiviazione dietro un firewall usando endpoint privati o di servizio.

Passaggi successivi