Share via

Fehler und die Office 365 Reporting-Webdienst zurückgegebene status

  • Artikel

Zusätzlich zu den standard-HTTP-Antwort-Codes gibt die Office 365-Berichterstattungswebdienst Fehler treten Probleme beim Verarbeiten der Anforderung. In diesem Thema beschreibt diese Fehler enthält Vorschläge für sie möglichst zu vermeiden und hilft Entwicklern, ihre Anwendungen Berichterstattungswebdienst zu beheben.

Letzte Änderung: Donnerstag, 17. September 2015

Gilt für: Office 365

Wo Fehler angezeigt werden

Es gibt vier primären Speicherorte, in denen Sie Fehler erhalten:

HTTP-Antwortcodes

Wie alle HTTP-basierten Web Service können die Berichterstattungswebdienst HTTP-Antwortcodes zurück. Der Standardspeicherort für ihre Definition ist http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html. Achten Sie insbesondere auf diesen Fehler:

  • HTTP 400-Bad Request: Dies wird zurückgegeben, wenn die Abfrage Hinweise zur Syntax enthält oder in Konflikt stehenden Informationen zugewiesen haben. Sie erhalten auch eine Fehlernutzlast Reaktion Atom oder JSON mit mehr Details.

  • HTTP 403: Verboten: Dies erhalten Sie, wenn die Anmeldeinformationen, die Sie übergeben entweder falsch oder das Konto keine ausreichenden administrative Berechtigungen hat, oder haben Sie einen Bericht, dass Sie Berechtigungen zum Zugriff auf nicht anfordern.

  • HTTP 404: Nicht gefunden: sehr häufig während der Entwicklung haben Sie den falschen Berichtsnamen.

< ServiceFault > XML-Dokument und JSON-Error-Objekt

Die meisten Fehler sehen Sie während der Entwicklung stammen aus ungültigen Anforderungen, falsche Spaltennamen usw.. Wenn Sie diese erhalten haben, lesen Sie diese sorgfältig, wie sie häufig Ihnen sagen, wo genau das Problem liegt. Der folgende Code ist ein Beispiel der Fehler im JSON-Format zurückgegeben. Diese erste ist das Ergebnis ein Spaltenname falsch eingeben.

  {
    "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'."
          } 
      }
  }

Dieser Fehler wurde im Atom-Format zurückgegeben, wenn die Syntax einer Option $filter falsch war, in diesem Fall die Datum-/ Uhrzeit-Zeichenfolge im falschen Format ist.

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

Ihre Anwendung sollte auch berücksichtigen sie möglicherweise Fehlermeldungen über bestimmte und entsprechend behandelt. Zum Glück haben Sie die URI-Konstruktion Logik gedebuggt wird, werden dieser Fehler selten sein.

Leerer Berichtsergebnisse

In manchen Fällen sind die Ergebnisse, die leer sind vollständig korrekt. In anderen Fällen kleine Fehler wie einen Benutzernamen immer des Falls für eine Transportregel falsch Tippfehler und andere kleinere Probleme werden scheinbar einwandfrei funktionieren, aber keine Ergebnisse. Ein frustrierendes Fehler dieser Art versucht, rufen Sie den Bericht MailDetail: keine Daten, so versuchen die Mühe nicht immer zurückgegeben.

Ausnahmen, die im Code ausgelöst wird.

Auf jeden Fall immer fangen Sie Ausnahmen in Ihrem Code. Oft sind diese Fehler jedoch normal Antworten auf normalen Fehlern im HTTP-Protokoll behandeln und bezieht sich nicht immer auf die Berichterstattungswebdienst.

Verhindern von Problemen

Die folgende Liste beschreibt die empfohlene Vorgehensweisen, die helfen können, zu verhindern, dass schwierige Aufgaben zur Problembehandlung während der Entwicklung und verwenden:

  • Nicht Zwischenspeichern des Servicebelegs angezeigt oder die MailFilterList führt zu lange. Müssen sie alle zehn Minuten erhalten aber in einer großen Organisation mit mehreren oder viele Administratoren, treten die Änderungen in den Namen von Richtlinien und Regeln und das System muss diese selten Änderungen ordnungsgemäß behandelt werden.

  • Stellen Sie sicher, dass der Dienst verfügbar ist , vor der Berichtsanforderung. Nehmen Sie nicht an, dass der Dienst ausgeführt wird. Checken Sie es in regelmäßigen Abständen den Servicebeleg anfordern, und stellen Sie sicher, dass der Bericht, den Sie aufrufen möchten, vorhanden ist. Sie müssen nicht jede Anforderung dazu aber auf jeden Fall beim Starten der Anwendung.

  • Verwenden Sie immer die MailFilterList Ausgabe für Namen. Namen wie z. B. Data Leakage Prevention-Richtlinien und Regeln werden häufig in ein Formular von einem menschlichen Administrator eingegeben und Rechtschreibfehler treten. Von unter Berufung auf die Ergebnisse von MailFilterList, stellen Sie sicher, dass die Namen, die Sie an die Berichterstattungswebdienst übergeben stimmen.

  • Verwenden, und überprüfen Sie $metadata. Das Dokument $metadata enthält die Feldnamen für die einzelnen Berichte. Erwägen Sie, die Anwendung abrufen, überprüfen und die Namen aus den Autostartprogrammen. Alternativ sollten Sie sorgfältig überprüfen, dass die Spaltennamen die Anwendung verwendeten identisch mit denen im Dokument $metadata sind.

  • Service-Version in Ihre Anforderung einschließen, und überprüfen Sie, ob die Antwort hat das gleiche. Vorsicht, jedoch, dass dieser Service-Version nur einmal angeben. Die Anwendung kann es entweder eines HTTP-Headers oder in den REST-URI als Parameter angeben. Wenn Sie beide angeben, die Berichterstattungswebdienst einen Fehler zurückgibt, selbst wenn Sie an beiden Stellen die gleichen Service-Version angeben.

  • In der HttpWebRequestkeine Umleitungen zulassen . AllowAutoRedirect auf False festgelegt.

  • Stellen Sie sicher, dass die HTTP-Content-Length Antwortheader entspricht die Länge des Puffers Antwort vor der Weitergabe an einem XML-Parser und vor der Verarbeitung der JSON-Daten im Browser. Wenn Sie übergeben kann eine partielle Antwort entweder Sie Haupt- und subtile beeinträchtigen.

  • Der Accept-Language explizit festgelegt HTTP-Anfrage-Header. Derzeit gibt es keine lokalisiert, die durch die Berichterstattungswebdienstkommt, aber das ändern können, und wenn Ihre Kunden eine anderen Kultureinstellung verwenden, Ihre Anwendung möglicherweise Anzeigeinformationen falsch.

  • Server-Cookies zurück in die nächste Anforderung für die Anwendung gesendet.

  • Ignorieren "edit" Links geben einige Berichte <link rel="edit" title="" ... /> Einträge im Atom-Format Ergebnisse zurück. Die Berichtsdaten sind immer schreibgeschützt, und die Anwendung sollten nicht versuchen, um die Links zum Ändern von Daten verwenden.

  • Speichern Sie keine Benutzernamen und Kennwörter als Textkonstanten in der Anwendung, und wenn Sie vom Benutzer angefordert werden müssen, speichern sie sicher in einem .NET FrameworkSecureString.

  • Eine Protokollfunktion bereitstellen. Wenn Ihre Anwendung Common Language Runtime, Netzwerk- und Web Service-Fehler auftritt, sollte sie alles über die Anforderung und die Antwort geschrieben haben. Dies hilft Ihnen bei der Problembehandlung, und ist u. u. erforderlich, hat Microsoft-Kundendienst zur Problembehandlung in Office 365.

  • Rufen Sie nicht den MailDetails-Bericht, einen leeren Bericht, wie sie immer zurückgegeben.

Einfache Fehler

Im folgenden werden einige Probleme, die wir beim Schreiben und Entwickeln der Beispielanwendung erfahren. Sie waren alle häufig vorkommen, bis wir vertraut machen Berichtsanforderungen wurde:

  • Überprüfen Sie sorgfältig die Spaltenbenennung der Dokumentation.

  • Überprüfen Sie den Bericht benennen. HTTP 404 Fehler werden zurückgegeben, wenn der Berichtsname falsch ist. Die beste Möglichkeit, dies zu verhindern, dass soll nur die Berichtsnamen verwenden, die durch den Servicebeleg Beschreibung Reporting.svc kommen.

  • Verwenden Sie nur Namen aus dem MailFilterList -Bericht beim Vergleichen von Elementen, die es umfasst. Ereignisse, Richtlinien und Regelnamen die Verarbeitung der Nachricht sollte alle abgerufen aus nur dieses Dokument, damit korrekte Rechtschreibung und, dass der Wert tatsächlich vorhanden ist.

  • Wenn Sie StartDateverwenden, müssen Sie enthalten EndDate. Sie sind sowohl gekennzeichnet als optional, aber wenn Sie Sie müssen auch die andere enthalten.

  • Wenn StartDate oder EndDate, Datum, verwenden die richtige Syntax verwenden Die ODATA-Syntax für das Festlegen von Datum-/ Uhrzeit-Werte ist durchaus etwas stärker eingeschränkt als andere Standards. Der Primitive Datentypen ODATA-Spezifikation ausführliche Informationen.

  • Denken Sie daran, datetime und guid Typumwandlungen in $filter Optionen. Datentypfehler inkompatiblen erhalten, wenn Sie nicht die Werte vom Typ String, Datetime und Guid, denen Sie umwandeln mit Filtern.

  • Nicht alle Berichte StartDate und EndDate verwenden. Weitere Informationen finden Sie unter Vorgehensweise: Angeben der Berichterstellung Zeitspannen.

  • Fordern Sie die Service-Version zweimal.

  • ODATA lässt nur eines einzelnen Abfrage-Optionen. Enthalten Sie zwei $filter -Optionen, z. B. nicht.

Normale Bedingungen, die scheint Probleme

Die folgenden Bedingungen Manchmal scheinen Entwickler und Benutzer Probleme, aber möglicherweise normal, dass der Berichterstattungswebdienst:

  • Daten sind sofort nicht verfügbar. Die meisten Arten von Informationen über e-Mail-Verarbeitung und Verfolgung von Nachrichten usw. stehen die Berichte in ein paar Stunden. Allerdings wird keine Daten "sofort" angezeigt Erstellen von Benutzerkonten und Postfächer Änderungen sehr oft wird nicht verfügbar sein erst am nächsten Kalendertag, damit, das heißt kann bis zu 48 Stunden verzögert. Ihre Anwendung sollte, die berücksichtigen und Benutzererwartungen entsprechend festgelegt.

  • Leerer Bericht, dass Ergebnisse manchmal normal sind, oder aufgrund von eingeschränkten Zeitspannen oder strengen Kriterien erfolgen. Wenn dies für die Anwendung normal ist, sollten Sie eine Möglichkeit für den Benutzer wissen, dass der Berichtsanforderung war erfolgreich, aber es keine Daten wurden bereitstellen.

  • Berichte können mehr als ein paar Sekunden dauern , abhängig von der Menge an Detaildaten. Die Anwendung sollte wie lange dauern die Berichte abrufen, Status anzeigen und die Erwartungen der Benutzer entsprechend Zeit. Möglicherweise erhalten Sie auch wiederholen können Datamart-Timeout-Fehlern.

  • 2000 ist die maximale Anzahl der Zeilen , die jeder Bericht zurückgeben kann.

  • Die Optionen $top und $orderby von allen Berichten nicht unterstützt werden. Überprüfen Sie die Referenzdokumentation für den Bericht, den Sie verwenden, um zu erfahren, ob diese Optionen unterstützt. Einige Berichte ignoriert diese Optionen und geben keine Fehler an.

  • Berichtsdaten werden schließlich gelöscht. Die meisten Daten werden für ein Jahr, und Ablaufverfolgungsdaten Nachricht ist nur 40 Tage lang gespeichert. Detaillierte Meldung Ablaufverfolgungsdaten ist nur für 48 Stunden nach der letzten Nachricht Anordnung zur Verfügung. Beachten Sie, dass Sie Zeitspannen reporting und versuchen, Trace Nachrichtenübermittlung behandeln.

  • Lync-Benutzer müssen ihre Organisation-Konto angemeldet werden. Organisation Benutzer als "Gast" Lync-Konferenzen teilnehmen können oder ihr Konto angemeldet. Konferenzressourcen in den Berichten aufgeführt sammeln nur Minuten für Teilnehmer, die dabei sind, ihre Organisation-Konto angemeldet. Außerdem sammeln keine Minuten für Teilnehmer auf einem mobilen Gerät. Ja, Sie richtig gelesen: Wenn sie über Mobile anwesend sind, sie werden nicht angezeigt (noch).

  • Lync Beteiligung über mobile Geräte sind nicht eingeschlossen. Keiner der Lync-Berichte enthalten Sitzungen oder von Teilnehmern auf mobilen Geräten verwendet wird.

  • Lync-Berichte enthalten nur selbst organisierte Konferenzen Der Lync-Berichte liefern Zeit- und Sitzungen Zählungen für nur Konferenzen, die von einem Benutzer in der Organisation organisiert sind. Da verschiedene Lync Online-Angebote können nicht die Möglichkeit zum Organisieren von enthalten, jedoch möglicherweise immer die Möglichkeit noch, an ihnen teilzunehmen, konnte die Anzahl der innerhalb dieser Mieter organisiert Konferenzen Herausarbeitung immer 0 (null) zurückgegeben.

  • MxRecordReport, OutboundConnectorReport und ServiceDeliveryReport nur aktuelle Bedingungen melden Diese drei Berichte liefern Informationen über die aktuelle Konfiguration und den Zustand der Office 365-Systeme. Sie geben keine historischen oder zusammenfassenden Informationen zurück.

Unkontrollierbare Ereignisse

Der Office 365-Berichterstattungswebdienst ist ein integrierter Dienst, Empfangen von Daten aus einer Vielzahl von Quellen und Rechenzentren. Die folgende Liste beschreibt einige der Dinge, denen Ihre Anwendung auftreten kann, dass sie wenig oder keinen Einfluss hat:

  • Die Berichterstattungswebdienst hängt von der Exchange Online Infrastruktur. Aus diesem Grund ist der Exchange Online -Dienst nicht verfügbar aufgrund einer geplanten oder ungeplanten Ausfällen, die Berichterstattungswebdienst auch möglicherweise nicht verfügbar.

  • Exchange Server Richtlinien Drosselung beeinträchtigen Reaktionszeiten. Wenn die Anwendung viele Anfragen macht oder Ihre Dashboard-Website ein einzelnes Dienstkonto, verwendet um die Berichtsdaten sammeln, können die Drosselung Ihrer Anforderungen auftreten. In Office 365der Organisations-Administratoren haben keine Kontrolle über die Einstellungen der Bandbreiteneinschränkung, noch können sie sogar lesen Was sind die aktuellen Einstellungen. Seien Sie vorsichtig, wie viel Office 365 Ressourcen, die Sie übernehmen verfügbar sind.

  • Verzögerte oder verlorene Verbindung zu den Datamart. In einigen Fällen Wenn die Berichtsdatenbanken stark ausgelastet sind oder mit neuen Informationen aktualisiert werden, die Berichterstattungswebdienst werden vorübergehend nicht verfügbar oder Zeitüberschreitung. Sie erhalten Fehler ConnectionFailedException werden "Failed to connect to the datamart." oder ähnliches. Dies ist fast nie ein Problem mit der Anwendung, aber Sie wiederholen Sie die Anforderung, und informieren Sie Ihre Benutzer schließlich, dass die Daten oder der Dienst möglicherweise nicht verfügbar.