Compartilhar via

Sincronização de caixa de correio e EWS no Exchange

  • Artigo

Descubra como funciona a sincronização de caixa de correio quando você usa o EWS para acessar o Exchange.

O EWS no Exchange usa dois tipos de sincronização para recuperar o conteúdo da caixa de correio e as alterações no conteúdo da caixa de correio:

  • Sincronização de pastas
  • Sincronização de itens

Neste artigo, você aprenderá sobre os dois tipos de sincronização, como funciona a sincronização, os padrões de design de sincronização e as práticas recomendadas de sincronização.

Sincronização de pastas e itens

A sincronização de pastas sincroniza uma estrutura de pastas ou uma hierarquia de pastas. A sincronização de itens sincroniza os itens dentro de uma pasta. Ao sincronizar itens, você precisa sincronizar cada pasta na caixa de correio de forma independente. Você pode usar o EWS ou a API Gerenciada do EWS em seu aplicativo para implementar a sincronização de pastas e itens.

Tabela 1. Operações EWS e métodos de API Gerenciada do EWS para sincronizar pastas e itens

Operação do EWS Método da API Gerenciada do EWS
SyncFolderHierarchy Método ExchangeService.SyncFolderHierarchy
SyncFolderItems Método ExchangeService.SyncFolderItems

O escopo da sincronização que ocorre difere dependendo se é uma sincronização inicial ou em andamento, da seguinte forma:

  • Uma sincronização inicial sincroniza todas as pastas ou itens no servidor com o cliente. Após a sincronização inicial, o cliente tem um estado de sincronização que armazena para sincronizações futuras. O estado de sincronização representa todas as alterações no servidor que o servidor comunicou ao cliente.
  • As sincronizações em andamento sincronizam todos os itens ou pastas que foram adicionados, excluídos ou alterados desde a sincronização anterior. O servidor usa o estado da sincronização para calcular as alterações a serem relatadas ao cliente durante cada um dos loops da sincronização em andamento.

Cada método ou operação de sincronização retorna uma lista de alterações, não a pasta ou mensagem que foi alterada. As alterações em itens e pastas são relatadas por meio dos seguintes tipos de alteração:

  • Criar — Indica que um novo item ou pasta deve ser criado no cliente.
  • Atualizar — Indica que um item ou pasta deve ser alterado no cliente.
  • Excluir — Indica que um item ou pasta deve ser excluído no cliente.
  • ReadStateChange para o EWS ou ReadFlagChange para a API Gerenciada do EWS — Indica que o estado de leitura do item foi alterado, de não lido para lido ou de lido para não lido.

No Exchange Online, sendo o Exchange Online como parte do Office 365 e versões do Exchange a partir do Exchange 2010 SP2, os itens e pastas são retornados na ordem do mais novo para o mais antigo. Em versões anteriores do Exchange, os itens e pastas são retornados do mais antigo para o mais recente.

Como funciona a sincronização do EWS?

Resumindo, se você estiver sincronizando uma caixa de correio pela primeira vez, use o processo mostrado na Figura 1. Embora você possa usar outros padrões de design de sincronização, recomendamos essa abordagem para aplicativos escalonáveis.

Figura 1. Padrão de design de sincronização inicial

An illustration that shows the initial synchronization design pattern. The client calls SyncFolderHierarchy and Load or GetItem to get the folders, then calls SyncFolderItems and LoadPropertiesForItems or GetItem to get the items in each folder.

Se você estiver usando um estado de sincronização que já existe no cliente para sincronizar uma caixa de correio, recomendamos implementar o padrão de design mostrado na Figura 2.

Figura 2. Padrão de design de sincronização contínua

An illustration that shows the ongoing synchronization design pattern. A client receives a notification and then calls SyncFolderHierarchy or SyncFolderItems, gets the properties, then updates the client, or simply updates the read flag on the client.

Padrões de design de sincronização

Você pode usar um dos dois padrões de design de sincronização no seu aplicativo para manter suas caixas de correio atualizadas: sincronização baseada em notificação ou a abordagem somente sincronização.

A sincronização baseada em notificação, como ilustrado na Figura 2, depende de notificações que alertam o cliente para fazer uma chamada aos métodos SyncFolderItems ou SyncFolderHierarchy da API Gerenciada do EWS ou para as operações SyncFolderHierarchy ou SyncFolderItems do EWS. Esse tipo de sincronização geralmente é recomendado para aplicativos escalonáveis, mas pode não ser a melhor abordagem para todos. A sincronização baseada em notificação tem a seguinte vantagem:

As notificações são otimizadas para reduzir as chamadas ao banco de dados de back-end do Exchange. As filas de eventos e as assinaturas são gerenciadas pelo servidor de caixas de correio (ou pelo servidor de Acesso para Cliente no Exchange 2010 e no Exchange 2007); no entanto, o gerenciamento de eventos e assinaturas usa menos recursos do que a alternativa, que são as chamadas de sincronização mais frequentes ao banco de dados do Exchange. Além disso, o Exchange tem políticas de limitação específicas para notificações e assinaturas, para proteger o consumo de recursos.

No entanto, também existem algumas desvantagens em usar a sincronização baseada em notificação:

  • As notificações são barulhentas porque a maioria dos cenários envolve várias notificações para uma intenção de usuário. Isso é especialmente verdadeiro para a pasta Calendário. Por exemplo, quando uma única solicitação de reunião é recebida, várias notificações de item e pasta são criadas, incluindo uma notificação para criar o item e outra para modificar o item. Uma maneira de atenuar essa desvantagem é criar um atraso de alguns segundos em sua chamada Load, LoadPropertiesForItems, GetItem ou GetFolder. No caso de uma solicitação de reunião, se você fez chamadas para a operação GetItem imediatamente, poderá ter uma chamada para criar o item e outra para modificar o item. Em vez disso, atrasando a chamada, você pode chamar a operação GetItem uma vez e obter as alterações que abrangem a criação e a modificação do item ao mesmo tempo.
  • As notificações são enfileiradas no servidor de caixas de correio e as assinaturas são salvas no servidor de caixas de correio. Se o servidor de caixas de correio que gerencia a assinatura não estiver disponível, você perderá todas as novas notificações, sua caixa de correio não será sincronizada e terá que assinar novamente as notificações.
  • Você precisará planejar estratégias de mitigação caso as notificações falhem. Dessa forma, a segunda abordagem, o padrão de design somente sincronização, é mais resiliente do que a sincronização baseada em notificação, pois requer apenas que o cliente mantenha o estado de sincronização. Não há problemas de afinidade com o servidor de caixas de correio que gerencia a assinatura.

Se implementado conforme recomendado, o padrão de design de assinatura baseado em notificação depende de:

  • Notificações para determinar quando os dados foram alterados.
  • Os métodos SyncFolderHierarchy ou SyncFolderItems da API Gerenciada do EWS ou as operações EWS SyncFolderHierarchy ou SyncFolderItems para determinar o que mudou, otimizando o número de eventos de sincronização retornados. Um novo item foi criado, atualizado ou excluído? Isso é tudo o que você precisa saber desses métodos, não confie neles para obter a lista de propriedades das alterações. (Não faça uma chamada GetItem ou LoadPropertiesForItems em todos as pastas ou itens retornados).
  • Usando os métodos Load ou LoadPropertiesForItems na API Gerenciada do EWS ou na operação GetItem do EWS para determinar como os dados foram alterados e para recuperar propriedades do servidor conforme necessário, organizando solicitações em lote com base na quantidade de dados que serão retornados. Isso é seguido por uma comparação das propriedades no cliente e aquelas recém-retornadas do servidor e, finalmente, a criação, exclusão ou modificação do item ou pasta no cliente.

A abordagem somente de sincronização depende inteiramente dos métodos SyncFolderItems e SyncFolderHierarchy da API Gerenciada do EWS, ou das operações SyncFolderHierarchy ou SyncFolderItems do EWS, que você pode chamar continuamente ou como um evento com tempo. Também há prós e contras para essa opção. A abordagem somente sincronização é mais resiliente porque o estado de sincronização é armazenado no cliente no nível da caixa de correio e não é necessária uma relação exclusiva entre o estado de sincronização e qualquer servidor de caixa de correio que mantém a assinatura de notificação. A abordagem de sincronização pode sobreviver a um failover de caixa de correio devido à sua independência do servidor de caixas de correio. No entanto, a abordagem de sincronização aumenta a latência para o usuário porque os itens são sincronizados de forma cronometrada ou intermitente, não em tempo real quando os itens chegam. Essa abordagem também é mais dispendiosa, porque você está fazendo chamadas ao banco de dados do Exchange quando é possível que nenhuma alteração tenha ocorrido.

Práticas recomendadas de sincronização

Para aplicativos altamente escalonáveis, recomendamos que você aplique as seguintes práticas recomendadas para sincronizar as caixas de correio em seu aplicativo:

  • Ao chamar o método SyncFolderItems ou SyncFolderHierarchy API Gerenciada do EWS use o valorIdOnly para o parâmetro propertySet, ou ao usar as operaçõesSyncFolderHierarchy ou SyncFolderItems do EWS, use o valor IdOnly para o valor BaseShape para reduzir as chamadas ao banco de dados do Exchange. Quanto mais propriedades você solicitar no conjunto de propriedades da chamada SyncFolderItems ou SyncFolderHierarchy, mais chamadas de back-end serão criadas. Uma nova chamada RPC é feita para cada valor de propriedade solicitado, enquanto apenas uma chamada RPC é feita para recuperar todos os ItemIds de uma solicitação, independentemente do número de resultados a serem relatados. Portanto, uma solicitação IdOnly resulta em uma chamada ao banco de dados, enquanto uma solicitação de recipiente de propriedades para o assunto e o remetente resulta em três chamadas de banco de dados: uma para o Subject, uma para oSender e outra para o ItemId.

  • Não chame os métodosLoad ou LoadPropertiesForItems da API Gerenciada do EWS, ou as operações GetItem ou GetFolder do EWS em cada item de uma resposta de sincronização. Em vez disso, analise os resultados; procure alterações que não exijam que todas as propriedades sejam recuperadas, como as alterações do estado de leitura. Se uma resposta incluir uma alteração do estado de leitura, basta atualizar o sinalizador no cliente e pronto; não é necessário obter todas as propriedades do item. E certifique-se de não duplicar o esforço fazendo alterações originadas do mesmo cliente. Por exemplo, se a resposta de sincronização incluir a exclusão de um item e a exclusão tiver ocorrido no cliente local, você não precisará excluir a mensagem novamente ou obter todas as propriedades desse item.

  • Evite a limitação fazendo o seguinte:

    • Quando você chama o método LoadPropertiesForItems da API Gerenciada do EWS ou a operação GetItem do EWS para obter os itens em um lote, não coloque muitos itens em lote na sua solicitação; caso contrário, você poderá ser limitado. Recomendamos incluir 10 itens por lote.
    • Não faça muitas solicitações em um período muito curto. Isso também causará limitação e aumentará o tempo de resposta, em vez de reduzi-lo.
    • Se você estiver colocando os itens em lotes, agrupe todos os itens com os mesmos valores para os atributos de Id e ChangeKey do elemento FolderId.
    • Se você for limitado, pare de enviar solicitações. O reenvio de solicitações prolongará o esforço de recuperação. Em vez disso, aguarde o tempo de retorno expirar e tente enviar suas solicitações de sincronização novamente.

  • Dependendo do tipo de evento de notificação recebido:

    • Para eventos NewMail ou Modified, chame o métodoSyncFolderItems da API Gerenciada do EWS ou a operação SyncFolderItems do EWS porque as notificações não fornecem um ChangeKey e as notificações não chamam as alterações do estado de leitura.
    • Para eventos Deleted, se a assinatura de notificação estava ativa antes da sincronização anterior, basta excluir o evento localmente. Você não precisa chamar o método SyncFolderItems da API Gerenciada do EWS ou a operação SyncFolderItems do EWS imediatamente após a exclusão.
    • Se um evento Modified foi causado por uma alteração do estado de leitura, não chame o método LoadPropertiesForItems da API Gerenciada do EWS ou a operação GetItem do EWS, apenas altere o sinalizador no item.

  • Ao sincronizar os dados do calendário, proceda da seguinte forma:

    • Use uma abordagem semelhante à sincronização baseada em notificação. Como SyncFolderItem não inclui nenhuma lógica de calendário, use o método FindAppointments da API Gerenciada do EWS ou a operação FindItem do EWS com o elemento CalendarView para exibir compromissos entre duas datas e, em seguida, chame o método LoadPropertiesForItems da API Gerenciada do EWS ou a operação GetItem do EWS para recuperar as propriedades do item para o item de calendário.

    • Não faça sondagens usando o método FindAppointments da API Gerenciada do EWS ou a operação FindItem do EWS com um elemento CalendarView.

  • Ao sincronizar as pastas de pesquisa:

    • Use uma abordagem semelhante à sincronização baseada em notificação.

    • Use as notificações para determinar quando os dados são alterados.

    • Como você não pode usar o SyncFolderItem em uma pasta de pesquisa, use um método FindItems classificado e paginado da API Gerenciada do EWS ou a operação FindItem do EWS com o conjunto de elementos FractionalPageItemView e SortOrder para determinar o que mudou.

    • Use o método LoadPropertiesForItems da API Gerenciada do EWS ou a operação GetItem do EWS para recuperar dados.

Sincronização filtrada

O método SyncFolderItems da API Gerenciada do EWS e a operação SyncFolderItems do EWS permitem ignorar itens específicos, com base em seus ItemIds, definindo o parâmetro ignoreItemIds na API Gerenciada do EWS ou o elemento Ignore no EWS. Isso é ideal quando, por exemplo, as pessoas começam a responder a uma mensagem de e-mail enviada a todos na empresa.

Você pode se perguntar, posso filtrar minhas notificações (e, portanto, apenas acionar a sincronização) se propriedades específicas forem alteradas? Embora isso pareça plausível, porque as assinaturas de notificação se baseiam no tipo de alteração (criar, atualizar, excluir) e não na propriedade que está sendo atualizada, você não pode filtrar as notificações dessa maneira. Em vez disso, você pode fazer o seguinte:

  • Use o padrão de design de assinatura baseado em notificação.
  • Chame os métodos SyncFolderItems e SyncFolderHierarchy da API Gerenciada do EWS repetidamente com o parâmetro propertySet definido como IdOnly para atualizar o seu estado de sincronização. Ou, se estiver usando o EWS, chame as operações SyncFolderHierarchy e SyncFolderItems repetidamente com o valor BaseShape definido como IdOnly.
  • Descarte a resposta (não analise-a ou faça comparações de propriedade).
  • Use o métodoFindItems da API Gerenciada do EWS ou a operação FindItem do EWS para preencher e paginar previamente os itens no escopo filtrado que lhe interessam.
  • Use o estado de sincronização para continuar a chamar o método SyncFolderItems da API Gerenciada do EWS ou a operação SyncFolderItems do EWS, mas monitore apenas as alterações no conjunto de itens filtrados. Se novos itens forem criados, você precisará ver se esses novos itens estão dentro do escopo filtrado.

Nesta seção

Confira também