Indietro

Prossima

Identificazione e risoluzione dei problemi comuni

Completato

Di seguito sono illustrati due modi comuni per usare Monitoraggio nell'ambito del normale processo di creazione di app:

• Reattivo: l'utente è a conoscenza di un problema e ha bisogno di assistenza per identificarne la causa principale. Ad esempio, se qualcuno che sta usando l'app ha segnalato un errore, è possibile usare Monitoraggio per individuare la causa. In genere si sa dove si è verificato un errore in un'app ed è possibile usare Monitoraggio per osservare gli eventi per un'azione specifica nell'app.

• Proattivo: nell'ambito del normale processo di creazione di app, prima di rilasciare l'app agli utenti, è possibile usare Monitoraggio per identificare eventuali problemi. Durante l'esecuzione di test proattivi molto spesso si esegue l'app mentre Monitoraggio acquisisce gli eventi. Se si esamina il registro eventi, è possibile cercare tempi di risposta lunghi, altre anomalie o errori. I problemi che vengono identificati in modo proattivo nella fase di creazione fanno sì che gli utenti riscontrino un minor numero di difficoltà nella produzione e che l'app sia considerata di qualità superiore.

Il resto di questo modulo esaminerà come identificare e risolvere problemi comuni tramite Monitoraggio.

Indipendentemente dall'approccio usato si consiglia di iniziare l'acquisizione con un registro eventi vuoto. A questo scopo fare clic sul pulsante Cancella dati in Monitoraggio prima di eseguire le azioni nell'app che si sta sottoponendo a test.

Uso di nomi di controllo significativi

I nomi di controllo inclusi negli eventi acquisiti sono correlazioni chiave dell'evento rispetto alla posizione in cui si è verificato nell'app. Se si usano nomi validi per i controlli, è possibile semplificare l'uso dei dati degli eventi. Si consideri il seguente esempio che confronta i nomi generati per impostazione predefinita con quelli consigliati più significativi. Come illustrato, quando vengono usati nomi significativi, sarebbe più facile identificare quale controllo è stato coinvolto nell'attività.

Ricerca di eventi simili

Quando si cerca di identificare l'origine di un problema, un'attività comune che si potrebbe eseguire consiste nell'individuare altre occorrenze correlate. Monitoraggio consente di semplificare la ricerca offrendo due approcci per filtrare i dati degli eventi che sono stati acquisiti. È possibile usare l'opzione di filtro globale per cercare in tutte le colonne di dati del registro eventi. Il filtro globale è disponibile nell'angolo superiore destro di Monitoraggio.

Questo filtro è utile quando non si stanno cercando i dati in un campo specifico. Ad esempio, si desidera cercare ad ampio spettro in tutte le colonne qualcosa che corrisponda a uno schema, come il nome di un controllo o un'azione del connettore.

Ogni colonna consente inoltre di filtrare e fornire più opzioni di filtro specifiche del tipo di dati. Per attivare il filtro delle colonne, selezionare la freccia accanto al nome di ogni colonna e quindi selezionare Filtra per.

È inoltre possibile applicare l'opzione Filtra per a più colonne contemporaneamente per creare criteri che includano più di una colonna con i valori richiesti. Quando si applicano i filtri a più colonne, ogni evento deve essere idoneo affinché vengano visualizzati tutti i filtri delle colonne.

L'uso delle funzionalità di filtro può essere utile se si sono acquisiti numerosi eventi e si desidera isolare problemi specifici.

Identificazione e risoluzione degli errori

In genere gli errori vengono rilevati perché hanno restituito un messaggio di errore all'utente o hanno attivato una logica di gestione degli errori nell'app. In questi casi Monitoraggio è utile perché ha informazioni più dettagliate sull'errore specifico quando questo riguarda un connettore. Man mano che la gestione degli errori dell'app diventa più sofisticata, l'errore può anche essere assorbito dalla logica di gestione degli errori e l'unico modo per visualizzarlo è esaminare i dati acquisiti. Questa situazione è un ottimo esempio di dove il monitoraggio proattivo delle app può rilevare errori che non ci si aspettava o che non si sapeva che si sarebbero verificati.

Il modo più semplice per identificare un errore nel registro dati degli eventi consiste nell'esaminare la colonna del risultato che contiene la parola Errore anziché Operazione riuscita.

Un altro modo per identificare gli errori consiste nell'identificare un indicatore a forma di cerchio rosso posizionato all'inizio delle righe che contengono errori.

Spesso la colonna Stato contiene un codice di stato HTTP dettagliato che indica una categoria di errore più specifica. Di solito le informazioni risultanti contengono un testo di riepilogo del codice di stato. Per ulteriori informazioni sui diversi valori del codice di stato HTTP, vedere Enumerazione HttpStatusCode.

Per lavorare alla risoluzione degli errori, le informazioni migliori provengono dalle schede Formula, Richiesta e Risposta nell'area Dettagli, che viene visualizzata quando si seleziona uno degli errori. La formula è utile per stabilire la correlazione a ciò che ha causato l'errore nell'app, mentre la richiesta e la risposta forniscono i dettagli fondamentali.

La causa più comune degli errori è rappresentata da dati non validi o mancanti quando si usa un connettore. È possibile esaminare la richiesta per determinare che cosa è stato inviato al connettore che ha causato l'errore.

Sebbene i contenuti della richiesta possano variare da un connettore all'altro, i due fattori più comuni da cercare nella richiesta sono l'URL e il corpo.

Nella maggior parte dei casi, per le azioni del connettore che apportano modifiche ai dati, le informazioni più preziose si trovano nel corpo. In genere si cercano dati non validi o mancanti in ciò che ci si aspetta venga inviato al connettore per la richiesta. Anche il confronto del corpo della richiesta con la documentazione dell'API dell'azione del connettore può evidenziare dei problemi.

Per le azioni di tipo query, in genere l'URL contiene altre informazioni utili nella stringa di query.

La scheda Risposta contiene i dati restituiti dal connettore. Sebbene ogni connettore possa avere una struttura di risposta univoca, è possibile rilevare molti errori osservando i suggerimenti della scansione del messaggio di risposta. Nell'esempio seguente, una regola di business ha bloccato la richiesta di creazione di un record di contatto di prova e nella risposta è stato incluso un messaggio di errore.

Sebbene i contenuti della richiesta e della risposta possano sembrare eccessivamente complessi, in caso di una scansione rapida spesso si possono ottenere suggerimenti che contribuiscono a risolvere il problema. Se i suggerimenti non sono utili, è possibile fornire questi dettagli allo sviluppatore del connettore o l'assistenza può aiutare quest'ultimo a capire come si stava usando il connettore.

Identificazione e risoluzione delle azioni lente

Anche se un utente potrebbe confermare che cosa in particolare è lento nell'app, la colonna Durata è un altro indicatore valido. È possibile applicare un filtro alla colonna Durata dopo aver eseguito l'applicazione in modo da concentrarsi solo sulle azioni lente. Il valore della durata viene registrato in millisecondi (ms). Nell'esempio seguente si cercano tutte le voci del registro eventi che hanno richiesto più di un secondo.

Se l'app esegue numerosi processi di caricamento dei dati durante l'avvio, è necessario assicurarsi che Monitoraggio sia in esecuzione e che si sia selezionata la logica Esegui OnStart.

Il modo più comune per risolvere le azioni lente consiste nel ridurre la quantità di lavoro svolto dall'azione o la quantità di dati restituiti dall'azione. Se si analizza la richiesta, potrebbe essere possibile determinare se i criteri sono stati soddisfatti e se si potrebbero fornire più criteri per ridurre il lavoro. Inoltre è possibile esaminare la risposta per stabilire se vengono restituiti più dati del necessario. Alcuni connettori riescono a identificare e restituire automaticamente i dati corretti, mentre altri prevedono che l'utente specifichi le opzioni per la richiesta in modo da restituire solo i dati pertinenti.

Identificazione e risoluzione dei problemi di delega

I problemi di delega si verificano quando si compone una query che contiene criteri che non possono essere risolti completamente e implementati in remoto dal servizio del connettore. In questo caso l'app invia solo una parte dei criteri al connettore per restituire più record del necessario e per post-elaborare i risultati del connettore nell'app. Il numero di record che possono essere ritirati e post-elaborati è limitato da un'impostazione dell'app e ha un valore predefinito pari a 500. Se sono disponibili più record idonei del connettore rispetto al limite specificato, i risultati vengono troncati e nell'app si potrebbero ottenere risultati imprecisi.

In molti casi Verifica app in Power Apps Studio identifica il problema di delega, che è possibile risolvere senza Monitoraggio. Monitoraggio contrassegna anche questi eventi e fornisce ulteriori dettagli. Se non si riesce a identificare il problema con le informazioni fornite da Verifica app, esaminare la richiesta che è stata inviata al connettore. In particolare è necessario esaminare i dati dei criteri di query mancanti, che possono aiutare a capire che cosa non è possibile inviare al connettore come criteri delegabili.

Spesso, per risolvere i problemi di delega, è necessario riscrivere la formula in modo da escludere i calcoli dei dati dinamici nei criteri inviati al connettore. Connettori diversi supportano funzioni diverse per la delega. Ciò che ha funzionato per un connettore potrebbe non funzionare per un altro. È possibile usare Monitoraggio per verificare che la formula restituisca i risultati corretti.

Questa unità ha esaminato alcuni errori comuni che si potrebbe provare a risolvere con Monitoraggio. Monitoraggio deve essere lo strumento di riferimento quando sono necessarie informazioni più dettagliate su ciò che sta accadendo nell'applicazione. Se si esegue Monitoraggio regolarmente, è possibile identificare rapidamente comportamenti anomali e problemi nell'applicazione.

Continua