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 dell'app per la logica genera informazioni che consentono di diagnosticare ed 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 il 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 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 portale di Azure con 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 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.

    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 esaminare 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, 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.

    Screenshot che mostra 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 output dei passaggi non riusciti.

Eseguire il debug al runtime

Per semplificare il debug, è possibile aggiungere passaggi di diagnostica a un flusso di lavoro dell'app per la logica, oltre a esaminare la cronologia dei trigger e delle esecuzioni. Ad esempio, è possibile aggiungere passaggi che usano il servizio Tester webhook, in modo da poter esaminare le richieste HTTP e determinare le dimensioni esatte, la forma e il 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 esaminare come 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 tester webhook.

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 si verifica 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 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 i carichi di lavoro di altri clienti potrebbero influire negativamente sulle prestazioni del flusso di lavoro.

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

La mia azione scade dopo 2 minuti. Come è possibile aumentare il valore di timeout?

Il valore di timeout dell'azione non può essere modificato e viene risolto 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. 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 l'account di archiviazione si trova 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\hostj.son 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: 'Rilevato un errore (ServiceUnavailable) dal runtime host'.

- Impossibile raggiungere il runtime dell'host. Dettagli errore, Codice: 'BadRequest', Messaggio: 'Rilevato un 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:

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

    Importante

    Quando si dispone di informazioni riservate, ad esempio stringa 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 privilegi minimi necessari.

    Se questa funzionalità non è disponibile, assicurarsi di proteggere i stringa 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 stringa di connessione e chiavi. Analogamente ai modelli arm, in cui è possibile definire le variabili di ambiente in fase di distribuzione, è possibile definire 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 altro ancora. 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 nei modi seguenti:

    Se si riscontrano 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 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

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

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

Passaggi successivi