Enumerando alterações
Quando um provedor de origem responde uma solicitação GetChangeBatch (para código gerenciado) ou IKnowledgeSyncProvider::GetChangeBatch (para código não gerenciado), a tarefa deste é gerar um lote de alterações desconhecidas pela réplica de destino. O provedor de origem determina quais itens na réplica de origem não estão contidos no objeto de conhecimento enviado pelo provedor de destino e retorna um lote desses itens.
Cada lote de alterações é composto pelas seguintes informações:
As IDs e versões globais para os itens alterados.
Marcas de exclusão que a réplica de destino deveria ter conhecimento.
O conhecimento atual. Este é o conhecimento da réplica de origem quando as alterações foram feitas. O Estrutura de sincronização calcula o conhecimento adquirido do destino do conhecimento atual a medida que o provedor de destino aplica as alterações.
O conhecimento pré-requisito. Este é o conhecimento mínimo que uma réplica de destino deve ter para processar este lote de alterações. Se o conhecimento da réplica de destino não contém o conhecimento pré-requisito, este não poderá processar essas alterações.
O conhecimento esquecido da réplica de origem. Isso é usado para detectar uma réplica de destino desatualizada.
Enumeração de alterações entre duas réplicas
Esta seção fornece um cenário que descreve o processo de enumeração de alteração entre duas réplicas usando as interfaces de conhecimento do Estrutura de sincronização.
Dica
Uma réplica é responsável por garantir que alterações feitas localmente são refletidas em seu conhecimento antes de um provedor enumerar alterações. Isso pode ser feito atualizando o conhecimento quando uma alteração local for feita ou efetuando uma passagem de manutenção de metadados antes de enumerar alterações.
Nesse cenário, um provedor de destino solicita alterações do provedor de origem. A ordem da solicitação é a seguinte:
A réplica de destino garante que todas as alterações feitas localmente são refletidas no seu conhecimento para o escopo que será sincronizado com a réplica de origem.
O provedor de destino envia o conhecimento da réplica de destino para o provedor de origem. O provedor de origem recebe o conhecimento através do método GetChangeBatch (para código gerenciado) ou IKnowledgeSyncProvider::GetChangeBatch (para método não gerenciado).
Para criar um lote de alterações o provedor de origem enumera as alterações, exclui na réplica de origem e verifica cada uma com o conhecimento da réplica de destino. Uma alteração só é adicionada ao lote de alterações quando não está contido no conhecimento da réplica de destino. O lote de alterações é representado pelo objeto ChangeBatch (para código gerenciado) ou pela interface ISyncChangeBatch (para código não gerenciado).
O provedor de origem retorna o lote de alterações para o provedor de destino.
Dica
Potencialmente, podem haver muitas alterações em um conjunto de alterações. Para permitir que tenha tempo para processar a lista de alterações de entrada, o provedor de destino pode perguntar se as alterações devem ser enviadas em lotes, retornando um número diferente de zero para o tamanho do lote em seu método GetSyncBatchParameters (para código gerenciado) ou GetSyncBatchParameters (para código não gerenciado).
Quando o provedor de origem usa unidades de alteração para representar subitens enumerados da réplica de origem, este envia somente as unidades de alteração que mudaram em vez do item inteiro. Para obter mais informações, consulte Sincronizando unidades de alteração.
Tratando alterações obsoletas
Quando um lote de alterações é construído, as alterações obsoletas são excluídas automaticamente. Uma alteração obsoleta é uma alteração já contida no conhecimento da réplica de destino e isso não deve ser aplicado à réplica de destino. Quando uma alteração é adicionada a um lote de alterações, o Estrutura de sincronização compara a versão da alteração com o conhecimento da réplica de destino e adiciona a alteração somente se não estiver contida no conhecimento da réplica de destino. Isso produz um lote de alterações mínimo e permite que um provedor implemente um algoritmo mais simples para enumerar alterações, como uma com base na contagem em escala.
Um provedor pode executar a própria verificação de que as alterações adicionadas a um lote de alterações não são obsoletas. Para isso, o provedor determina se a ID global e a versão da alteração estão contidas no conhecimento da réplica de destino. Isso é executado usando o método Contains (para código gerenciado) ou ISyncKnowledge::ContainsChange (para código não gerenciado). Se o conhecimento não contém a alteração, o provedor a adiciona ao lote de alterações. Isso produz um lote de alterações mínimo e é útil para provedores que desejam controle total sobre a construção de lote de alterações.
Consulte também
Referência
Interface ISyncKnowledge
Interface ISyncChangeBatch
IKnowledgeSyncProvider Interface
IKnowledgeSyncProvider::GetChangeBatch
SyncKnowledge
ChangeBatch
KnowledgeSyncProvider
GetChangeBatch
Conceitos
Provedores de sincronização
Tratando conflitos
Noções básicas sobre conhecimento de sincronização