Compartilhar via

Erros e status retornado pelo serviço da web de relatório do Office 365

  • Artigo

Além dos códigos de resposta HTTP padrão, o Office 365 Reporting web service retorna erros se ocorrerem problemas ao processar a solicitação. Este tópico descreve esses erros, oferece sugestões para esquivar-se deles sempre que possível e ajuda os desenvolvedores a resolver seus aplicativos Reporting web service .

Última alteração: quinta-feira, 17 de setembro de 2015

Aplica-se a: Office 365

Onde os erros são indicados

Há quatro locais principais onde você receberá erros:

Códigos de resposta HTTP

Como qualquer serviço web baseado em HTTP, o Reporting web service pode retornar códigos de resposta HTTP. O local padrão para sua definição é http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html. Em particular, cuidado com esses erros:

  • HTTP 400-solicitação ruim: isso é retornado quando a consulta tem problemas de sintaxe ou que forneceu informações conflitantes de solicitação. Você também terá uma carga de erro na resposta Atom ou JSON com mais detalhes.

  • HTTP 403: Proibido: você obterá isso quando as credenciais que você passar são o correto ou a conta não tem privilégios administrativos suficientes ou você está solicitando um relatório que você não tem privilégios de acesso.

  • HTTP 404: Não encontrado: é muito comum durante o desenvolvimento, se você tiver o nome de relatório incorreto.

Documento XML < ServiceFault > e objeto JSON Error

A maioria dos erros que você verá durante o desenvolvimento provenientes de solicitações incorretas, nomes de coluna incorretos e assim por diante. Ao recebê-los, lê-las com cuidado, pois eles geralmente dizer exatamente onde está o problema. O seguinte é um exemplo do que um erro retornado no formato JSON. Este primeiro é o resultado de digitar um nome de coluna incorretamente.

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

Esse erro foi retornado no formato Atom quando a sintaxe de uma opção de $filter estava errada, que nesse caso, é a seqüência de caracteres de data e hora no formato errado.

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

O aplicativo também deve estar ciente que pode receber erros específicos de relatório e tratá-los adequadamente. Felizmente, uma vez que a lógica de construção de URI depurada, esses erros serão raros.

Resultados de relatório vazio

Às vezes, os resultados de relatório que estejam vazios são totalmente corretos. Outras vezes, pequenos erros, como digitar incorretamente um nome de usuário obter o caso errado em uma regra de transporte e outros pequenos problemas parecerá funcionar, mas não há resultados. Um erro frustrante dessa natureza está tentando chamar o relatório MailDetail: ela sempre não retorna nenhum dado, portanto, não se preocupe em tentar.

Exceções geradas no código

Definitivamente sempre captura exceções em seu código. No entanto, muitas vezes esses erros são normais respostas a erros normais no protocolo HTTP tratamento e nem sempre relacionado com o Reporting web service.

Evitando problemas

A lista a seguir descreve as práticas recomendadas que podem ajudar a evitar tarefas de solução de problemas difíceis durante o desenvolvimento e usar:

  • Não armazenar em cache o documento de serviço ou a MailFilterList os resultados por muito tempo. Você não precisa colocá-los a cada dez minutos, mas em uma grande organização com vários ou muitos administradores, ocorrem alterações nas regras e políticas de nomes e seu sistema precisa lidar com essas alterações freqüentes normalmente.

  • Certifique-se de que o serviço está disponível antes de fazer a solicitação de relatório. Não presuma que o serviço está funcionando. Verificá-lo periodicamente solicitando o documento de serviço e verificar se o relatório que você pretende chamar está presente. Você não precisa fazer isso em cada solicitação, mas definitivamente quando o aplicativo for iniciado.

  • Sempre usar a saída MailFilterList para nomes. Os nomes de coisas como nomes de diretiva e regra de prevenção de perda de dados com freqüência são digitados em um formulário por um administrador humano e ocorrem erros de ortografia. Baseando-se nos resultados MailFilterList, verifique se os nomes que você passar para o Reporting web service são precisos.

  • Uso e verifique se $metadata. O documento de $metadata inclui todos os nomes de campo para cada relatório. Considere ter o aplicativo recupere, verificar e use esses nomes de inicialização. Como alternativa, você deve verificar cuidadosamente que seu aplicativo usa os nomes das colunas são os mesmos que os do documento $metadata.

  • Incluir uma versão de serviço em sua solicitaçãoe verifique que a resposta tem a mesma. Cuidado, no entanto, se você especificar somente essa versão de serviço uma vez. Seu aplicativo pode especificá-lo em um cabeçalho HTTP ou como um parâmetro no URI restante. Se você fornecer ambos, o Reporting web service retorna um erro, mesmo quando você especificar a mesma versão de serviço em ambos os locais.

  • Não permitir redirecionamentos a HttpWebRequest. Defina AllowAutoRedirect como falso.

  • Verificar se o Content-Length de HTTP cabeçalho de resposta coincide com o tamanho do buffer de resposta antes de passar os dados para um analisador XML e antes de processar os dados JSON no navegador. Se você passar uma resposta parcial em você poderá causar problemas principais e sutis.

  • Definir explicitamente Accept-Language Cabeçalho de solicitação HTTP. Atualmente não há nada localizado que vem através de Reporting web service, mas isso pode mudar e se os clientes estão usando uma configuração de cultura diferente, o aplicativo pode exibir informações incorretamente.

  • Retornar os cookies de servidor enviados para seu aplicativo na próxima solicitação.

  • Links de "Editar" Ignorar alguns relatórios retornam entradas <link rel="edit" title="" ... /> no formato Atom resultados. Os dados do relatório serão sempre somente leitura e seu aplicativo não deve tentar usar os links para modificar os dados.

  • Não armazene nomes de usuário e senhas como constantes de texto em seu aplicativo e se é preciso solicitá-los de seu usuário, armazená-los com segurança em um .NET FrameworkSecureString.

  • Fornecer um recurso de registro. Quando seu aplicativo tiver erros do serviço da web, rede e tempo de execução, ele deve ter a capacidade de registrar tudo sobre a solicitação e resposta. Isso ajudará você a solucionar problemas, podendo ser necessário se tiver de suporte ao cliente da Microsoft solucionar o problema no Office 365.

  • Não chamar o relatório de MailDetails, como ela sempre retorna um relatório vazio.

Erros simples

A seguir estão alguns problemas que enfrentamos ao escrever e desenvolver o aplicativo de exemplo. Eles foram todas as ocorrências comuns até que nos tornamos familiarizados com a criação de solicitações de relatório de:

  • Verificar cuidadosamente o nome da coluna a documentação.

  • Verifique cuidadosamente a nomeação de relatório. HTTP 404 erros são retornados quando o nome do relatório está errado. A melhor maneira de evitar isso é só usar os nomes de relatório são provenientes do documento de descrição de serviço Reporting.svc .

  • Usar somente os nomes do relatório MailFilterList quando correspondentes a itens que ele aborda. Mensagem de processamento de eventos, política e nomes de regra devem ser obtidos com apenas esse documento para garantir a ortografia correta e o valor realmente existe.

  • Se você usar StartDate, você deve incluir EndDate. Eles são ambos marcados como opcionais, mas se você incluir um também deve incluir o outro.

  • Ao usar a data de início, data de término ou data, use a sintaxe correta A sintaxe ODATA para especificar valores de data e hora é um pouco mais restritiva do que outros padrões. A especificação de tipos de dados primitivos ODATA fornece detalhes.

  • Conversões de tipo datetime e guid de lembrar em Opções de $filter. Se você não converter os valores de data e hora e o guid de seqüência com que estiver filtrando, você receberá erros de tipo de dados incompatível.

  • Nem todos os relatórios usam StartDate e EndDate. Para obter mais informações, consulte Como: especificar períodos de tempo de relatórios.

  • Não solicite a versão de serviço duas vezes.

  • ODATA permite que apenas um de cada opção de consulta. Não inclua duas opções de $filter , por exemplo.

Condições normais parecem problemas

As seguintes condições às vezes parecem que os desenvolvedores e usuários problemas, mas podem ser normais para o Reporting web service:

  • Dados não estão disponíveis imediatamente. A maioria dos tipos de informações sobre o processamento de email, rastreamento de mensagem e assim por diante estão disponíveis para os relatórios dentro de algumas horas. No entanto, nenhum dos dados será exibida "instantaneamente". Criar contas de usuário e alterações de caixa de correio com muita freqüência, não estará disponível até o próximo dia do calendário, portanto, isso pode significar atraso até 48 horas. Seu aplicativo deve levar isso em consideração e definir adequadamente as expectativas do usuário.

  • Relatório vazio, os resultados são às vezes normais, ou ocorrer devido a períodos de tempo restritivo ou strict critérios de correspondência. Se isso é normal para o seu aplicativo, você deve fornecer uma maneira para o usuário sabe que a solicitação de relatório foi bem-sucedida, mas não havia nenhum dado.

  • Relatórios podem demorar mais do que alguns segundos , dependendo da quantidade de dados de detalhes. Seu aplicativo deve sempre os relatórios de quanto tempo levam para recuperar, fornecer o status e definir as expectativas do usuário de acordo. Você também poderá receber erros de tempo limite do armazém de dados capaz de tentar novamente.

  • 2000 é o número máximo de linhas que pode retornar qualquer relatório.

  • Que as opções $top e $orderby não são suportadas por todos os relatórios; Consulte a documentação de referência para o relatório que você está usando para saber se ele oferece suporte a essas opções de consulta. Alguns relatórios ignoram essas opções e não indicam erros.

  • Dados de relatório são excluídos eventualmente. A maioria dos dados é mantida por um ano, e os dados de rastreamento de mensagem só são mantidos para 40 dias. Dados de rastreamento de mensagem detalhada estão disponíveis somente para 48 horas de descarte a mensagem final. Leve isso em consideração ao definir períodos de tempo de emissão de relatórios e tentar problemas de entrega de mensagem de rastreamento.

  • Usuários do Lync devem estar conectados a sua conta de empresa. Os usuários da organização podem participar de conferências de Lync como "Convidado" ou conectado a sua conta de usuário. Recursos de conferência listados nos relatórios apenas se acumulam minutos para os participantes que estão participando logados em sua conta de organização. Além disso, não há minutos acumulam para participantes em um dispositivo móvel. Sim, você pode ler esse direito: se eles esteja participando via celular, eles não aparecerão (ainda).

  • Lync participação através de dispositivos móveis não estão incluídos. Nenhum dos relatórios Lync incluem sessões ou tempo usado pelos participantes em dispositivos móveis.

  • Relatórios do Lync apenas incluem conferências organizadas automaticamente Os relatórios do Lync retornam contagens de tempo e sessões para apenas as conferências eram organizadas por um usuário da organização. Como diferentes planos Lync Online não podem incluir a capacidade de organizar conferências, mas ainda podem ter a capacidade de participá-los, o número de conferências organizados dentro desse inquilino pode viabilizar sempre retornará zero.

  • MxRecordReport, OutboundConnectorReport e ServiceDeliveryReport relatam condições somente atuais Esses três relatórios retornam informações sobre a configuração atual e condição dos sistemas Office 365. Não retornam informações históricas ou resumo.

Eventos incontroláveis

O Office 365 Reporting web service é um serviço integrado, receber dados de uma variedade de fontes e data centers. A lista a seguir descreve algumas das coisas que seu aplicativo pode encontrar que ele tem pouco ou nenhum controle sobre:

  • O Reporting web service depende do Exchange Online infra-estrutura. Por esse motivo, se o serviço Exchange Online não está disponível devido ao tempo de inatividade planejado ou não, o Reporting web service pode também estar indisponível.

  • Exchange Server otimização de políticas pode afetar os tempos de resposta. Se seu aplicativo toma uma série de solicitações ou seu site dashboard usa uma conta de serviço único para reunir todos os dados de relatórios, você pode encontrar a otimização de suas solicitações. Em Office 365, administradores da sua organização não tem nenhum controle sobre as configurações de otimização, nem pode até mesmo lerem quais são as configurações atuais. Cuidado quanto os recursos de Office 365 que você assumir estão disponíveis.

  • Atrasada ou conexão perdida com o datamart. Às vezes, quando os bancos de dados de relatórios estão sob carga pesada, ou estão sendo atualizados com muita informação nova, o Reporting web service pode tornar-se indisponível temporariamente, ou o tempo limite. O erro de ConnectionFailedException você receber será "Failed to connect to the datamart." ou algo semelhante. Isso quase nunca é um problema com o seu aplicativo, mas você deve repetir a solicitação e, eventualmente, informar os usuários que os dados ou o serviço pode não estar disponível.