Partager via

Les erreurs et l'état retourné par le service web de création de rapports Office 365

  • Article

En plus des codes de réponse HTTP standard, le Service web de création de rapports Office 365 renvoie des erreurs si des problèmes surviennent lors du traitement de la demande. Cette rubrique décrit ces erreurs, propose des suggestions pour les éviter autant que possible et aide les développeurs à résoudre les problèmes de leurs applications Service web de création de rapports .

Dernière modification : jeudi 17 septembre 2015

S’applique à : Office 365

Où les erreurs sont indiquées

Il existe quatre emplacements principaux où vous recevrez des erreurs :

Codes de réponse HTTP

Comme n'importe quel service web basé sur HTTP, le Service web de création de rapports peut retourner des codes de réponse HTTP. L'emplacement de leur définition standard est http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html. En particulier, méfiez-vous de ces erreurs :

  • HTTP 400 incorrecte demande : cette valeur est retournée lorsque la requête a des problèmes de syntaxe, ou vous avez donné des informations sur la demande en conflit. Vous obtiendrez également une charge utile d'erreur dans la réponse Atom ou JSON avec plus de détails.

  • HTTP 403 : Refusé : vous obtenez ceci lorsque les informations d'identification que vous transmettez sont soit incorrect ou que le compte dispose des privilèges d'administration suffisants ou que vous demandez un rapport que vous ne disposez des autorisations d'accès.

  • HTTP 404 : Introuvable : est très courant lors du développement, si vous avez le nom d'état incorrect.

< ServiceFault > XML document et objet Error JSON

Vous le verrez au cours du développement de la plupart des erreurs proviennent de requêtes mal formées, les noms de colonne incorrects et ainsi de suite. Lorsque vous les recevez, lisez-les attentivement, car ils vous indiquent souvent d'exactement où le problème est. Voici un exemple de ce qu'une erreur retournés au format JSON. Ce premier est le résultat de taper un nom de colonne incorrect.

  {
    "error":
      {
        "code":"",
        "message":
          {
            "lang":"en-US",
            "value":"Type 'TenantReporting.MailFilterListReport' does not have a property named 'Organizations'; 
            there is no service action named 'Organizations' that is bindable to the type 
           'TenantReporting.MailFilterListReport'; and there is no type with the name 'Organizations'."
          } 
      }
  }

Cette erreur a été renvoyée au format Atom lorsque la syntaxe d'une option de $filter était erronée, dans ce cas est de la chaîne de date et d'heure dans un format incorrect.

<?xml version="1.0" encoding="utf-8"?>
<m:error xmlns:m="https://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
  <m:code />
  <m:message xml:lang="en-US">Unrecognized 'Edm.DateTime' literal 'datetime'2013010T00:00:00'' in '86'.</m:message>
</m:error>

Votre application doit également être conscient qu'il peut recevoir des erreurs spécifiques à l'état et les gérer de façon appropriée. Heureusement, une fois que la logique de la construction de l'URI de débogage, les erreurs seront rares.

Résultats de l'état vide

Parfois, les résultats du rapport qui sont vides sont entièrement corrects. D'autres fois, petites erreurs comme une coquille dans un nom d'utilisateur lors de l'obtention du cas incorrect sur une règle de Transport, et autres problèmes mineurs semblent fonctionner correctement, mais aucun résultat. Une seule erreur frustrante de cette nature tente d'appeler le rapport MailDetail : elle ne retourne toujours aucuns données, donc ne vous préoccupez pas essayer.

Exceptions levées dans le code

Sans aucun doute toujours intercepter des exceptions dans votre code. Toutefois, ces erreurs sont souvent normales réponses aux erreurs normales dans le protocole HTTP gérant et pas toujours liés à la Service web de création de rapports.

Prévention des problèmes

La liste suivante décrit les meilleures pratiques qui peuvent aider à empêcher les tâches de résolution de problèmes complexes pendant le développement et l'utiliser :

  • Ne mettre en cache du document de service ou la MailFilterList des résultats trop longtemps. Vous n'avez pas besoin de les obtenir toutes les dix minutes, mais dans une grande organisation avec plusieurs ou plusieurs administrateurs, effectuer des modifications dans les règles et les stratégies de noms, et votre système doit gérer ces modifications rares correctement.

  • Assurez-vous que le service est disponible avant d'effectuer la demande de rapport. Ne pensez pas que le service fonctionne. Vérifier en demandant périodiquement le document service et vérifiez que le rapport que vous comptez appeler est présent. Vous n'avez pas besoin de le faire chaque demande, mais sans aucun doute au démarrage de votre application.

  • Toujours utiliser la sortie de MailFilterList pour les noms. Les noms des éléments tels que les noms de règle de stratégie et de prévention des fuites de données sont fréquemment tapés dans un formulaire par un administrateur, et les fautes d'orthographe se produisent. En se basant sur les résultats de la MailFilterList, vous vérifiez que les noms que vous passez à la Service web de création de rapports sont exacts.

  • Utilisation et vérifiez $metadata. Le document $metadata inclut tous les noms de champ pour chaque rapport. Pensez à récupérer, vérifier et utilisez ces noms à partir du démarrage de l'application. Sinon, vous devez vérifier attentivement que votre application utilise les noms de colonne sont les mêmes que ceux du document $metadata.

  • Inclure une version de service dans votre requête, puis vérifiez que la réponse a la même. Veillez, cependant, que vous seulement spécifiez que la version service qu'une seule fois. Votre application peut spécifier soit un en-tête HTTP, ou en tant que paramètre dans l'URI de reste. Si vous fournissez à la fois, le Service web de création de rapports renvoie une erreur, même lorsque vous spécifiez la version du service même aux deux endroits.

  • Ne pas autoriser les redirections dans le HttpWebRequest. AllowAutoRedirect la valeur false.

  • Vérifier que la longueur du contenu HTTP en-tête de réponse correspond à la longueur de la mémoire tampon de réponse avant de transmettre les données à un analyseur XML et avant de traiter les données JSON dans le navigateur. Si vous passez une réponse partielle soit vous peut provoquer des problèmes majeurs et subtiles.

  • Définissez explicitement le Accept-Language En-tête de demande HTTP. Actuellement il est nothing localisé qui est fourni par le biais de la Service web de création de rapports, mais qui peut changer, et si vos clients utilisent un paramètre de culture différent, votre application peut afficher correctement les informations.

  • Retourner tous les cookies de serveur envoyées à votre application dans la demande suivante.

  • Ignorer les liens « Modifier » certains rapports renvoient des entrées de <link rel="edit" title="" ... /> dans les résultats au format Atom. Les données du rapport soient toujours en lecture seule et que votre application ne doit pas tenter de liens permet de modifier les données.

  • Ne stockez pas les noms d'utilisateur et mots de passe en tant que constantes de texte dans votre application et si vous devez les demander par l'utilisateur, les stocker en toute sécurité dans un .NET FrameworkSecureString.

  • Fournit une fonctionnalité de journalisation. Lorsque votre application rencontre des erreurs de service web, de réseau et de runtime, il doit avoir la possibilité de tout consigner à propos de la demande et la réponse. Ceci vous aidera à résoudre les problèmes et peut être nécessaire si le support technique de Microsoft a résoudre le problème dans Office 365.

  • N'appelez pas le rapport de MailDetails, comme toujours, il renvoie un état vide.

Commettre des erreurs simples

Voici quelques problèmes que nous avons rencontré lors de l'écriture et le développement de l'exemple d'application. Il s'agissait de toutes les occurrences communes jusqu'à ce que nous sommes devenus familiers de la création de demandes de rapport :

  • Vérifiez attentivement le nom de la colonne par rapport à la documentation.

  • Vérifiez attentivement le rapport d'affectation de noms. HTTP 404 erreurs sont retournées lorsque le nom du rapport est incorrect. La meilleure façon d'éviter ce problème consiste à utiliser uniquement les noms de rapport fournis dans le document de description du service Reporting.svc .

  • Utiliser uniquement des noms à partir du rapport de MailFilterList mise en correspondance des éléments qu'elle couvre. Traitement des événements, la stratégie et les noms de règle doit être obtenu à partir de ce document afin de garantir la bonne orthographe et que la valeur existe seulement de message.

  • Si vous utilisez StartDate, vous devez inclure EndDate. Elles sont marquées comme facultatifs, mais si vous incluez un vous devez également inclure l'autre.

  • Lorsque vous utilisez la date de début, date de fin ou la Date, utilisez la syntaxe correcte La syntaxe ODATA spécifiant des valeurs de date et d'heure est tout à fait un peu plus restrictive que les autres normes. La spécification de Types de données primitifs ODATA fournit des informations détaillées.

  • Mémoriser casts de type datetime et guid dans les options de $filter. Vous recevrez des erreurs de type de données incompatible si vous n'effectuez un cast les valeurs de chaîne datetime et guid avec que vous filtrez.

  • Pas de tous les rapports utilisent StartDate et EndDate. Pour plus d'informations, consultez Comment : spécifier les rapports intervalles de temps.

  • Ne demandez pas deux fois la version du service.

  • ODATA permet uniquement de chaque option de requête. Ne pas inclure les deux options de $filter , par exemple.

Conditions normales de semblent des problèmes

Les conditions suivantes parfois semblent les développeurs et les utilisateurs à avoir des problèmes, mais peuvent être normales pour le Service web de création de rapports:

  • Données ne seront pas immédiatement disponibles. La plupart des types d'informations sur le traitement du courrier, de suivi des messages, etc. sont disponibles pour les rapports dans quelques heures. Toutefois, aucune des données s'affichent « instantanément ». Création de comptes d'utilisateurs et des modifications de la boîte aux lettres très souvent ne sera pas disponible avant le jour de calendrier suivant, donc cela ne peut signifier délai de 48 heures. Votre application doit qui prennent en considération et définir correctement les attentes des utilisateurs.

  • Rapport vide, les résultats sont parfois normales, ou se produisent en raison des intervalles de temps restrictives ou les critères de filtrage stricts. Si ceci est normal pour votre application, vous devez fournir un moyen pour l'utilisateur de savoir que la demande d'état a réussi, mais aucune donnée.

  • Rapports peuvent prendre plus de quelques secondes en fonction de la quantité de données détaillées. Votre application doit de temps combien de prendre les rapports pour récupérer, fournir l'état et définir des attentes de l'utilisateur en conséquence. Vous pouvez aussi recevoir des erreurs de temporisation mart de données capable de nouvelle tentative.

  • 2000 est le nombre maximal de lignes que n'importe quel rapport peut retourner.

  • Que les options $top et $orderby ne sont pas pris en charge par tous les États; consultez la documentation de référence pour le rapport que vous utilisez pour savoir si elle prend en charge les options de requête. Certains rapports ignorer ces options et n'indiquent pas une erreur.

  • Les données de rapport sont finalement supprimées. La plupart des données sont conservées pendant un an, et les données de suivi des messages sont conservées uniquement pendant quarante jours. Les données de suivi de message détaillé ne sont disponibles que pendant 48 heures à partir de la disposition de message final. Qui Gardez à l'esprit que vous définissez rapports d'intervalles de temps et que vous essayez de problèmes de remise de message de trace.

  • Les utilisateurs de Lync doivent être connectés à son compte entreprise. Utilisateurs de l'entreprise peuvent assister aux conférences Lync comme « Invité » ou connectés à leur compte d'utilisateur. Ressources de conférence répertoriés dans les rapports sont cumulées uniquement minutes pour les participants qui participent connectés à leur compte entreprise. En outre, aucun minutes s'accumulent pour les participants à sur un périphérique mobile. Oui, vous lisez ce droit : si elles vous participiez à via mobile, ils ne s'afficheront (encore).

  • Participation Lync via des périphériques mobiles ne sont pas inclus. Aucune des rapports Lync inclut des sessions ou le temps utilisé par les participants sur les périphériques mobiles.

  • Rapports de Lync incluent uniquement les conférences auto- Les rapports de Lync retournent le nombre de sessions et de temps pour seulement les conférences qui ont été organisés par un utilisateur de l'organisation. Étant donné que les différents plans de Lync Online peut ne pas incluent la possibilité d'organiser des conférences, mais il peut conserver la possibilité d'y participer, nombre de conférences organisées au sein de ce client pourrait retourner facilement toujours zéro.

  • MxRecordReport, OutboundConnectorReport et ServiceDeliveryReport rapport conditions actuelles uniquement Ces trois rapports retournent des informations sur la configuration actuelle et la condition des systèmes Office 365. Elles ne renvoient pas d'informations historiques ou de synthèse.

Événements incontrôlables

Le Service web de création de rapports Office 365 est un service intégré, recevoir des données à partir d'une large gamme de sources et de centres de données. La liste suivante décrit certaines des choses que votre application peut rencontrer qu'il a peu ou pas de contrôle :

  • Le Service web de création de rapports dépend de la Exchange Online infrastructure. Pour cette raison, si le service Exchange Online n'est pas disponible en raison de l'interruption de service planifiée ou non, les Service web de création de rapports peuvent également être inaccessibles.

  • Exchange Server stratégies de limitation peut affecter les temps de réponse. Si votre application effectue de nombreuses requêtes, ou votre site du tableau de bord utilise un compte de service unique pour rassembler toutes les données de rapport, vous pouvez rencontrer la limitation de vos demandes. Dans Office 365, les administrateurs de votre organisation n'ont aucun contrôle sur les paramètres de limitation, ni peuvent elles même lire ce que sont les paramètres en cours. Soyez prudent combien Office 365 ressources que vous supposez sont disponibles.

  • Retard ou perte de la connexion vers le magasin de données. Parfois lorsque les bases de données de création de rapports sont soumis à une charge importante, ou sont mis à jour avec un grand nombre de nouvelles informations, le Service web de création de rapports peut devenir temporairement indisponible, ou délai d'attente. L'erreur ConnectionFailedException s'est "Failed to connect to the datamart." ou similaire. Ce n'est presque jamais un problème avec votre application, mais vous devez relancer la demande et finalement informer vos utilisateurs que les données ou le service ne soit pas disponible.