Ошибки и состояния, возвращаемых веб-службой Office 365 Reporting

  • Статья

Помимо стандартных кодов ответов HTTP, Веб-служба отчетов Office 365 возвращает ошибки в случае возникновения проблем при обработке запроса. В этом разделе описываются эти ошибки, рекомендации для предотвращения их, где это возможно и помогает разработчикам устранять свои приложения Веб-служба отчетов .

Дата последнего изменения: 17 сентября 2015 г.

Область применения: Office 365

Где указаны ошибки

Существует четыре основных мест, где вы получите ошибки:

Коды ответов HTTP

Как и любая служба HTTP веб- Веб-служба отчетов может возвращать коды ответов HTTP. Стандартное местоположение для их определения является http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html. В частности следить за эти ошибки:

  • HTTP 400 Ошибочный запрос: это возвращается, если запрос содержит вопросы синтаксиса или предоставили конфликтующие сведения о запросе. Вы также получите полезные данные об ошибке в ответе Atom или JSON с более подробными сведениями.

  • HTTP 403: Запрещено: вы получите это при передаче учетные данные, или ошибочный или учетная запись имеет недостаточные права администратора или запрашивается отчет, что нет прав для доступа к.

  • HTTP 404: Не найдено: очень часто во время разработки, если неправильное имя отчета.

< ServiceFault > XML-документа и объект JSON Error

Большинство ошибок, которые можно будет увидеть во время разработки, берутся из неправильных запросов, неверный столбец имен и т. д. При их получении их внимательно прочитайте, как они часто сообщают точно где именно. Ниже приведен пример возвращено сообщение об ошибке в формате JSON. Это первый из них является результатом неправильного ввода имени столбца.

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

Эта ошибка была возвращена в формате Atom, когда синтаксис параметр $filter был неправильно, в данном случае является строка даты и времени в неверном формате.

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

Приложение также следует иметь в виду он может получать ошибки отчетом и обрабатывать их соответствующим образом. К счастью после отладки логики создания URI, эти ошибки будут редко.

Пустой отчет о результатах

В некоторых случаях результаты отчета, которые становятся пустыми полностью верны. В других случаях мелких ошибок, такие как неправильное написание имени пользователя, получение неправильный регистр на правила транспорта, и другие незначительные проблемы будет казаться, что хорошо работают, но не результаты. Одна ошибка раздражает подобные пытается вызвать отчет MailDetail: он всегда возвращает данные, поэтому не трудитесь попытки.

Возникающие в коде исключения

Определенно всегда перехватывать исключения в коде. Однако часто эти ошибки являются обычные ответы на обычные ошибки в протоколе HTTP обработки и не всегда относятся к Веб-служба отчетов.

Предотвращение проблем

В следующем списке описаны рекомендации, которые помогут избежать трудной задачи по устранению неполадок во время разработки и использования:

  • Не кэширует сервисного документа или MailFilterList приводит к слишком долго. Не требуется получать их каждые десять минут, но в больших организациях с нескольких или многих администраторов, происходят изменения в имена политик и правил и должен корректно обрабатывать эти редкие изменения системы.

  • Убедитесь, что служба доступна , перед выполнением запроса отчета. Не думайте, что служба работает. Проверьте периодически запрашивает документ службы и убедитесь, что отчет, который требуется вызвать. Необходимо сделать это каждого запроса, но определенно когда приложение запускается.

  • Всегда использовать выходные данные MailFilterList имен. Имена таких операций, как Предотвращение утечки данных политики и правила имен часто вводятся в форму человека администратором и ошибок правописания. Полагаться на результаты MailFilterList, позволяет гарантировать правильность имен, которые передаются в Веб-служба отчетов .

  • Использования и проверки $metadata. Документ $metadata включает все имена полей для каждого отчета. Рассмотрите возможность извлечения, проверки и использовать эти имена из запуска приложения. Кроме того вы должны внимательно проверьте имена столбцов, которые использует приложение такие же, как в документе $metadata.

  • Включить версию службы в запросеи проверьте, что ответ имеет тот же. Будьте внимательны, однако только выбранная версия этой службы один раз. Приложения можно указать в HTTP-заголовок, или в качестве параметра в ОСТАЛЬНОЙ URI. Если указать оба Веб-служба отчетов возвращает сообщение об ошибке, даже если указать одну и ту же версию служб в обоих местах.

  • Не разрешать перенаправление в HttpWebRequest. AllowAutoRedirect значение false.

  • Убедитесь, что HTTP Content-Length заголовок ответа соответствует длине буфера ответов перед их передачей для синтаксического анализа XML и перед обработкой данных JSON в браузер. Если передать частичный ответ в любом может привести к проблемам, основной и слабая.

  • Явно задать Accept-Language Заголовка HTTP-запроса. В настоящее время нет ничего не локализовано, получаемую с Веб-служба отчетов, однако, можно изменить и если вашим клиентам с разных языковых и региональных параметров, приложение может отображать сведения неправильно.

  • Вернуть все файлы cookie, сервер отправлено приложению следующего запроса.

  • Ссылки "Изменить" Пропустить некоторые отчеты возврата <link rel="edit" title="" ... /> записи в формате Atom результатов. Данные отчета всегда доступен только для чтения, и приложение не следует пытаться использовать ссылки для изменения данных.

  • Не сохранять имена пользователей и пароли как текстовых констант в приложении и если их необходимо запросить от пользователя, их безопасное хранение в .NET FrameworkSecureString.

  • Укажите средство ведения журнала. Когда приложение обнаруживает ошибки веб-службы, сети и среды выполнения, он должен иметь возможность регистрироваться все о запросе и ответе. Это поможет устранить неполадки и может потребоваться, если служба поддержки пользователей Майкрософт для устранения неполадок в Office 365.

  • Не вызывать MailDetails отчет, как он всегда возвращает пустой отчет.

Простых ошибок

Ниже перечислены некоторые проблемы, наблюдалось при создании и разработке образца приложения. Они были все распространенные процессы, пока мы здесь работаем, знакомы с обращения в отчет:

  • Тщательно проверьте имена столбцов документации.

  • Тщательно проверить Именование отчета. HTTP 404 ошибки возвращаются при неверное имя отчета. Во избежание этого рекомендуется использовать только имена отчетов, находящиеся в документе описания службы Reporting.svc .

  • При сопоставлении элементов, которые она охватывает только имена из отчета MailFilterList . Обработки событий, политики и имена правил сообщения следует получить из данного документа для обеспечения правильной орфографии и действительно существует значение.

  • При использовании StartDateнеобходимо включить EndDate. Они помечаются как необязательные, но если включить один должен быть другой.

  • При использовании StartDate и EndDate даты, используйте правильный синтаксис Заметно более строгим, чем другие стандарты ODATA синтаксис при указании значений даты и времени. Примитивные типы данных ODATA спецификации сведения.

  • Запомнить datetime и guid приведения типов в параметрах $filter. При приведении значения datetime и guid строки, выполняется фильтрация с не вы получите ошибок несовместимости типов данных.

  • Не все отчеты используют StartDate и EndDate. Дополнительные сведения содержатся в разделе Как: укажите отчетов диапазонов времени.

  • Не запрашивать обновления дважды.

  • ODATA позволяет только одному из каждого параметра запроса. Не включать два варианта $filter , например.

Нормальные условия, которые выглядят, как проблемы

Следующие условия Иногда кажется, что возникли неполадки, разработчикам и пользователям, но может быть нормально для Веб-служба отчетов:

  • Сразу же данные недоступны. Большинство типов сведения о обработки почты, сообщения трассировки и т. д. доступны отчеты в течение нескольких часов. Однако ни один из данных будет отображаться «быстро». Очень часто Создание учетных записей пользователей и почтовых ящиков изменения не будут доступны до следующего дня календаря, таким образом, может означать, что задержка в 48 часов. Приложения должны учитывать и соответствующим образом ожиданий пользователей.

  • Пустой отчет, результаты иногда обычныйили возникают из-за ограничения времени диапазонов или строгое условие соответствия. Если это нормально для приложения, следует предоставить пользователю знать, что отчет запрос выполнен успешно, но данные не были каким-то образом.

  • В зависимости от объема подробных данных отчетов может занять больше, чем пару секунд . Приложение должно времени, сколько времени отчеты для получения и предоставления состояния ожиданий пользователей соответствующим образом. Может также появиться ошибки таймаута витрине данных могли повторить.

  • Максимальное число строк равно 2000 , может возвращать любой отчет.

  • Все отчеты не поддерживаются параметры $orderby и $top; Проверьте в справочной документации по отчет, который вы используете, чтобы узнать, поддерживает ли эти параметры запроса. Некоторые отчеты эти параметры игнорируются и не указывают на ошибки.

  • Данные отчета со временем удаляется. Большинство данных сохраняется в течение одного года, а данные сообщения трассировки хранятся только в течение 40 дней. Подробные сообщения трассировки данных доступен только для 48 часов из метода обработки окончательного сообщения. Имейте это в виду, как набор отчетов диапазоны времени и попробуйте проблем с доставкой сообщений трассировки.

  • Lync пользователи должны войти в свою учетную запись организации. Пользователи организации могут присутствовать конференциях Lync как «Гость» или войти в свою учетную запись пользователя. Ресурсы конференций, перечисленные в отчетах нарастающим итогом только минут для участников, которые посещение войти в свою учетную запись организации. Кроме того не минут собираются для участников конференции на мобильном устройстве. Да, читать эти права: если они конференции через мобильный, они не попадали (пока).

  • Участие Lync через мобильные устройства не включаются. Ни один из отчетов Lync включают сеансы и время используется участниками для мобильных устройств.

  • Lync отчеты включают только самостоятельно организованных конференций Отчеты Lync возвращают количество времени и сеансов только конференций, которые были организованы по организации пользователя. Поскольку разные планы Lync Online могут не включать возможность организовывать конференции, но по-прежнему могут иметь возможность участвовать в них, число конференций, организованных в рамках этого клиента может никем всегда возвращать нуль.

  • MxRecordReport, OutboundConnectorReport и ServiceDeliveryReport отчет только текущие условия Эти три отчета возвращают сведения о текущей конфигурации и состояния системы Office 365. Они не возвращают исторические или сводные данные.

Неконтролируемых событий

Веб-служба отчетов Office 365 — это встроенная служба, получение данных из разнообразных источников и центрами обработки данных. Ниже перечислены некоторые вещи, приложения могут возникнуть у мало или совсем нет управления через:

  • Веб-служба отчетов зависит от Exchange Online инфраструктура. По этой причине если служба Exchange Online недоступна из-за запланированных и незапланированных простоев, Веб-служба отчетов могут также быть недоступны.

  • Exchange Server политики регулирования может повлиять на время отклика. Если приложение создает большое количество запросов или веб-сайта мониторинга используется учетная запись службы единого для сбора всех данных отчетности, могут возникнуть регулирование запросов. В Office 365Администраторы организации не контролирует параметры полосы пропускания, и не могут их даже читать, текущие параметры. Будьте внимательны, о том, насколько Office 365 ресурсы, которые вы принимаете на себя.

  • Отложенный или потеряно соединение в витрину данных. Иногда при баз данных отчетов, в условиях интенсивной нагрузки или обновляются с большим количеством новой информации, Веб-служба отчетов может стать временно недоступен, или время ожидания. Появляется сообщение об ошибке ConnectionFailedException будет "Failed to connect to the datamart." или аналогичный. Это не проблема с приложением, но следует повторить запрос и в конечном итоге Сообщите пользователям, что данные или службы могут быть недоступны.