Meilleures pratiques lors de la création d’un ticket de support

Les informations spécifiques dont Microsoft a besoin pour résoudre votre incident dépendent du problème que vous rencontrez. Cet article fournit des conseils et des meilleures pratiques pour la collecte des informations nécessaires pour les demandes de support. Notez que ces éléments ne s’appliquent pas tous à chaque cas.

Informations à fournir à Microsoft

En fonction de votre problème spécifique, vous pouvez être invité à fournir les informations suivantes.

1. L’URL de la page de navigateur dans laquelle vous rencontrez le problème. L’URL fournit des informations sur l’emplacement (espace de travail) où vous rencontrez le problème, ainsi que le type et l’ID de l’élément ou de la fonctionnalité.

2. L’emplacement du problème (Power BI Desktop/service Power BI/les deux). Cette information est toujours pertinente pour une demande de service. Si un processus échoue sur le service Power BI, mais réussit sur Desktop, ou inversement, cela fournit des informations utiles à Microsoft sur la cause possible du problème. Un autre exemple serait le cas où le même code M fonctionne dans un jeu de données, mais échoue dans un flux de données. Outre ces deux exemples, il existe de nombreux scénarios dans lesquels il est possible de résoudre le problème en identifiant exactement où il se produit et où il ne se produit pas.

3. Codes d’erreur

   Si un code d’erreur est généré en cas de problème, effectuez une copie de ce code d’erreur. Microsoft enregistre des informations détaillées sur tous les codes d’erreur et utilise ces informations afin de diagnostiquer votre problème. Il est peu probable que le code d’erreur seul permette de résoudre le problème, mais il accélère considérablement le processus de résolution.

   Conseil

   Utilisez le bouton Copier pour récupérer le code. N’envoyez pas de capture d’écran. Les codes d’erreur sont longs (généralement 30 caractères), et la transcription manuelle à partir d’une capture d’écran augmente le risque de se tromper.

4. Les sources de données et le mode de stockage utilisés. Les informations sur la source de données sont toujours pertinentes pour une demande de service. Chaque source de données présente certains problèmes qui lui sont propres. Lorsque plusieurs sources sont utilisées, utilisez le principe d’essai/erreur pour identifier la ou les sources qui contribuent au problème.

   Power BI se comporte également différemment quand différents modes de stockage sont utilisés. Les trois options de mode de stockage principales sont les suivantes :

   • Importer

   • Requête directe

   • Connexion active

   Il existe également deux cas particuliers :

   • Stockage en mode mixte (modèles composites)
   • Requête directe pour les jeux de données PBI et Analysis Services

   Pour identifier les sources de données utilisées dans Power BI Desktop, sélectionnez Paramètres de la source de données>Sources de données dans le fichier actuel. Dans le service Power BI, accédez à la page des paramètres sous Informations d’identification de la source de données ou via la vue de traçabilité. Pour y accéder, sélectionnez « Afficher la traçabilité » ou remplacez la vue de liste de l’espace de travail par la vue de traçabilité.

   Conseil

   Pour comprendre le mode de stockage utilisé, contactez le développeur de rapports ou examinez le fichier PBIX.

5. ID de capacité

   L’ID de capacité permet à Microsoft de connaître le type de capacité utilisée (par exemple, Premium). Seul l’administrateur de capacité peut rechercher l’ID de capacité. Si vous êtes l’administrateur de capacité, ouvrez le portail d’administration, sélectionnez Paramètres de capacité>Power BI Premium, puis sélectionnez le nom de la capacité. L’ID de capacité est la dernière partie de l’URL.

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

   L’administrateur de capacité peut également utiliser cette API REST pour récupérer l’ID de capacité.

6. ID du jeu de données

   Si votre problème affecte un jeu de données, l’ID permet à Microsoft d’identifier le jeu de données correct, puis d’examiner les processus en cours d’exécution sur ce jeu de données. Pour rechercher l’ID du jeu de données, accédez à l’espace de travail qui contient le jeu de données, puis ouvrez les paramètres du jeu de données. L’ID du jeu de données est la dernière partie de l’URL (datasets/dataset-id).

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

7. Une copie du fichier PBIX (requêtes d’importation uniquement)

   En cas de problème avec un modèle d’importation, le fichier PBIX permet à l’ingénieur du support de reproduire le problème et d’accélérer le processus de résolution. Si le fichier PBIX contient des informations confidentielles, veillez à partager une version anonyme.

   Important

   Veillez à vérifier auprès des parties concernées au sein de votre organisation si vous pouvez partager des informations potentiellement confidentielles.

8. Journaux d’activité de la passerelle

   Les journaux de passerelle sont requis lors de la résolution d’un problème de passerelle ou de réseau. Pour analyser vous-même les performances de la passerelle, utilisez le modèle de monitoring des performances de la passerelle. Pour plus d’informations, consultez la section Exporter les journaux pour un ticket de support.

9. Informations de diagnostic

   Suivez les étapes décrites dans l’article Collection de diagnostics Power BI Desktop pour afficher et collecter des informations de diagnostic.

10. JSON de flux de données

    Cet élément peut être utile quand un flux de données est en cours d’utilisation. Pour exporter le JSON et le transmettre à votre ingénieur du support, accédez à l’espace de travail, sélectionnez l’élément de flux de données, puis choisissez Export.json.

    

Considérations supplémentaires

Outre les informations standard décrites ci-dessus, les informations suivantes, le cas échéant, permettent à l’ingénieur du support de résoudre votre problème.

Le problème se produit-il uniquement dans une certaine capacité ?

Le basculement vers une autre capacité ou une capacité partagée résout-il le problème ? Parfois, les problèmes sont propres à certains environnements.

Le problème concerne-t-il tous les utilisateurs ?

Le problème touche-t-il l’ensemble de l’entreprise, un nombre donné de personnes ou une seule personne ?

S’agit-il d’un nouveau problème pour quelque chose qui fonctionnait auparavant ?

L’erreur a-t-elle commencé sans qu’aucune modification n’ait été apportée côté utilisateur ou a-t-elle été déclenchée à la suite d’une modification ou d’une nouvelle implémentation ? L’identification du point d’arrêt permet de limiter la cause racine potentielle.

La portée du problème est-elle plus ou moins importante que celle initialement rencontrée ?

Le problème a-t-il un impact sur l’ensemble ou une partie des éléments, ou sur un seul élément ? Par instance, si le problème concerne des API, les autres API fonctionnent-elles ? S’il s’agit d’un problème d’exportation, tous les rapports sont-ils affectés ? S’il s’agit d’un problème de capacité, toutes les capacités se comportent-elles de la même façon ? Si un rapport n’est pas actualisé et qu’il contient plusieurs sources de données, chaque source a-t-elle été testée séparément ?

Une procédure de dépannage a-t-elle déjà été réalisée ?

Cela accélère la résolution de votre problème en évitant les répétitions. Toutefois, dans certaines circonstances, votre ingénieur du support peut vouloir répéter les étapes que vous avez effectuées.

Le problème peut-il être répliqué sous une forme plus simple ?

Parfois, les informations confidentielles ne peuvent pas être transmises à Microsoft. Essayez de répliquer le problème à l’aide d’une version simplifiée du problème et fournissez des étapes de reproduction fiables à votre ingénieur du support.