Procedure consigliate per la creazione di un ticket di supporto

La creazione di un ticket di supporto di Power BI o Fabric efficace richiede informazioni specifiche per consentire a Microsoft di risolvere rapidamente il problema. Questo articolo fornisce procedure consigliate e informazioni chiave da includere quando si inviano richieste di supporto, consentendo di ottenere una risoluzione più rapida. Le informazioni specifiche necessarie dipendono dal problema e non tutti i suggerimenti si applicano a ogni caso.

Informazioni da fornire a Microsoft

A seconda del problema specifico, potrebbe essere richiesto di fornire le informazioni seguenti.

1. URL della pagina del browser in cui si verifica il problema. L'URL fornisce informazioni sulla posizione in cui (area di lavoro) si verifica il problema e il tipo di elemento o il tipo di funzionalità e l'ID.

2. Posizione del problema (servizio Power BI Desktop/Power BI/entrambi) Queste informazioni sono sempre rilevanti per una richiesta di servizio. Se un processo ha esito negativo nel servizio Power BI ma ha esito positivo su Desktop o viceversa, queste informazioni forniscono informazioni utili a Microsoft per quanto riguarda la possibile causa del problema. Un altro esempio è il caso in cui lo stesso codice M funziona in un set di dati ma non riesce in un flusso di dati. Oltre a questi due esempi, esistono molti scenari in cui è possibile risolvere il problema identificando esattamente dove si verifica e dove non lo fa.

3. Codici di errore

   Se viene generato un codice di errore quando si verifica un errore, creare una copia del codice di errore. Microsoft salva informazioni dettagliate su tutti i codici di errore e usa queste informazioni per diagnosticare il problema. È improbabile che il codice di errore risolva il problema autonomamente, ma accelera notevolmente il processo di risoluzione dei problemi.

   Suggerimento

   Usare il pulsante Copia per recuperare il codice. Non inviare uno screenshot. I codici di errore sono lunghi (in genere lunghi 30 caratteri) e la trascrizione manuale da uno screenshot aumenta la possibilità di sbagliarsi.

4. Le origini dati e la modalità di archiviazione in uso sono sempre rilevanti per una richiesta di servizio. Ogni origine dati presenta alcuni problemi rilevanti solo per se stesso. Se vengono utilizzate più fonti, usare tentativi ed errori per identificare quali fonti contribuiscono al problema.

   Power BI si comporta anche in modo diverso quando vengono usate diverse modalità di archiviazione. Le tre opzioni principali della modalità di archiviazione sono:

   • Importa
   • Direct Query
   • Connessione dinamica

   Esistono anche due casi speciali:

   • Storage a modalità mista (modelli compositi)
   • Direct Query per set di dati PBI e Analysis Services

   Per identificare le origini dati usate in Power BI Desktop, selezionare Impostazioni origine dati>Origini dati nel file corrente. Nel servizio Power BI, navigare alla pagina delle impostazioni sotto Credenziali origine dati o tramite la visualizzazione della linea. È possibile accedere a queste informazioni selezionando "Visualizza derivazione" o modificando la visualizzazione dell'area di lavoro dall'elenco alla derivazione.

   Suggerimento

   Per comprendere la modalità di archiviazione in uso, contattare lo sviluppatore di report o esaminare il file PBIX.

5. ID capacità

   L'ID capacità consente a Microsoft di conoscere il tipo di capacità in uso( ad esempio Premium). Solo l'amministratore della capacità può consultare l'ID della capacità. Se si è l'amministratore della capacità, aprire il portale di amministrazione e selezionare Impostazioni> capacitàPower BI Premium e selezionare il nome della capacità. L'ID capacità è l'ultima parte dell'URL.

   https://app.powerbi.com/admin-portal/capacities/ XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

   In alternativa, l'amministratore della capacità può usare questa API REST per recuperare l'ID capacità.

6. ID set di dati

   Se il problema influisce su un set di dati, l'ID consente a Microsoft di identificare il set di dati corretto e quindi di analizzare i processi in esecuzione su tale set di dati. Per trovare l'ID del set di dati, passare all'area di lavoro che contiene il set di dati e aprire le impostazioni del set di dati. L'ID del set di dati è l'ultima parte dell'URL (set-di-dati/id-set-di-dati).

   https://app.powerbi.com/groups/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/settings/datasets/ XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

7. Copia del file PBIX (solo query di importazione)

   Quando si verifica un problema con un modello di importazione, la presenza del file PBIX consente al tecnico del supporto di riprodurre il problema e accelerare la risoluzione dei problemi. Se il PBIX contiene informazioni riservate, assicurarsi di condividere una versione anonima.

   Importante

   Assicurarsi di confermare con le parti pertinenti all'interno dell'organizzazione prima di condividere informazioni potenzialmente riservate.

8. Log del gateway

   I log dei gateway sono necessari per la risoluzione di eventuali problemi di gateway o di rete. Per analizzare manualmente le prestazioni del gateway, usare il modello Di monitoraggio delle prestazioni del gateway. Per altre informazioni, vedere esportare i log per un ticket di supporto.

9. Informazioni di diagnostica

   Seguire la procedura descritta nella raccolta di diagnostica di Power BI Desktop per visualizzare e raccogliere informazioni di diagnostica.

10. JSON del flusso di dati

    Questa opzione è utile quando è in uso un flusso di dati. Per esportare il codice JSON e condividerlo con il tecnico del supporto tecnico, passare all'area di lavoro, selezionare l'elemento del flusso di dati e scegliere Export.json.

    

Domande frequenti

Oltre alle informazioni standard descritte in precedenza, le informazioni seguenti consentono al tecnico del supporto di risolvere il problema.

Il problema si verifica solo in un certo contesto?

Il passaggio a un'altra capacità o a una capacità condivisa risolve il problema? A volte i problemi sono specifici di determinati ambienti.

Il problema influisce su tutti gli utenti?

Il problema riguarda l'intera azienda, che influisce solo su un numero di persone o su un solo individuo?

Si tratta di un nuovo problema per qualcosa che funzionava in precedenza?

L'errore ha avuto inizio senza apportare modifiche sul lato utente o è stato attivato da una qualche modifica o da una nuova implementazione? L'identificazione del punto di interruzione consente di limitare la potenziale causa radice.

Il problema è più ristretto o più ampio rispetto all'inizio?

Il problema influisce su tutti, alcuni o solo una "cosa"? Ad esempio, se il problema riguarda le API, funzionano altre API? Se si tratta di un problema di esportazione, tutti i report sono interessati? Se si tratta di un problema di capacità, tutte le capacità si comportano allo stesso modo? Se un report non viene aggiornato e contiene più origini dati, ogni origine è stata testata separatamente?

Si è già provato a eseguire i passaggi per la risoluzione dei problemi?

Queste informazioni accelerano la risoluzione del problema evitando ripetizioni. Tuttavia, in determinate circostanze, il tecnico del supporto potrebbe comunque voler ripetere i passaggi impiegato.

È possibile replicare il problema in un formato più semplice?

In alcuni casi non è possibile condividere informazioni riservate con Microsoft. Provare a replicare il problema usando una versione semplificata del problema e fornire procedure di riproduzione affidabili al tecnico del supporto tecnico.