Sincronizando unidades de alteração
Uma unidade de alteração representa uma alteração de subitem, como o campo de número de telefone em um item que representa um cartão de contato. Usando unidades de alteração, os provedores podem sincronizar alterações de subitem de maneira mais eficiente. Alguns exemplos de provedores que podem se beneficiar das unidades de alteração são os provedores de PIM (Gerenciador de Informações Pessoais) e provedores que tratam imagens com metadados.
Unidades de alteração
As unidades de alteração permitem que as alterações de subitem compacto sejam representadas e tenham um rastreamento de alterações mais estrito. Isso pode reduzir o número de conflitos gerados quando são feitas alterações no item.
Considere um item que representa um cartão de contato que persiste em um sistema de arquivos. Se a granularidade do rastreamento de alterações estivesse no nível do item (arquivo), qualquer alteração do arquivo seria uma alteração de item e todos os dados no contato teriam que ser transferidos. Usando unidades de alteração, um provedor pode decidir detectar alterações e resolver conflitos de dados no nível da propriedade do contato, como nome, sobrenome e número de telefone. Nesse caso, se duas réplicas alterarem separadamente propriedades diferentes de um contato, por exemplo quando um modifica o endereço de email e outro anexa uma imagem, nenhum conflito será detectado no nível do item e apenas os dados da unidade de alteração devem ser enviados.
O conjunto de unidades de alteração forma um esquema no qual a ordem das unidades de alteração é decidida pelas réplicas que estão sincronizando um esquema específico. Por exemplo, as réplicas podem decidir representar as propriedades do contato da seguinte maneira:
Change Unit[0] = First Name
Change Unit[1] = Last Name
Change Unit[2] = Phone Number
Excluindo unidades de alteração
A duração de uma unidade de alteração está associada à duração do item. Diferentemente dos itens de alteração normais, as unidades de alteração não podem ser excluídas porque as réplicas concordaram que elas são propriedades de um item.
Adicionando unidades de alteração
Os provedores não devem tentar criar espontaneamente unidades de alteração porque isso pode ocasionar efeitos indesejáveis.
As unidades de alteração podem ser adicionadas com base em atualizações de esquema que ocorrem fora da banda com uma sincronização dos dados. Para funcionar, as unidades de alteração adicionadas devem ter um valor null ou um valor padrão usado por todas as réplicas. A versão de atualização das unidades de alteração adicionadas será então a versão de criação do item até que essas unidades sejam modificadas. Tratando adições de unidade de alteração dessa maneira, elas aparecem para os componentes do aplicativo como não sendo diferentes de uma unidade de alteração que existisse desde o início e que nunca foi modificada.
Enumerando alterações de unidade de alteração
Quando o provedor de origem usa unidades de alteração para representar subitens enumerados da réplica de origem, ele envia apenas as unidades de alteração alteradas e não o item inteiro. Observe que quando um item contém unidades de alteração, as informações sobre a versão só são mantidas para cada unidade de alteração e não para o item em si.
Enumerando alterações de unidade de alteração usando código gerenciado
Para determinar quais unidades de alteração devem ser enviadas, o provedor de origem usa o método Contains(ChangeUnitChange) ou Contains(SyncId, SyncId, SyncId, SyncVersion) do objeto SyncKnowledge do provedor de destino. Se uma alteração de unidade de alteração não estiver contida no conhecimento de destino, a alteração deverá ser incluída no lote de alterações enviado pelo provedor de origem.
As alterações de unidade de alteração estão contidas em alterações de item adicionadas ao lote de alterações. O objeto ItemChange pode ser criado para conter as alterações de unidade de alteração usando o construtor ItemChange ou as alterações de unidade de alteração podem ser adicionadas usando AddChangeUnitChange.
Enumerando alterações de unidade de alteração usando código não gerenciado
Para determinar quais unidades de alteração devem ser enviadas, o provedor de origem usa o método ISyncKnowledge::ContainsChangeUnit do objeto ISyncKnowledge do provedor de destino. Se uma alteração de unidade de alteração não estiver contida no conhecimento de destino, ela deverá ser incluída no lote de alterações enviado pelo provedor de origem.
As alterações de unidade de alteração estão contidas em alterações de item adicionadas ao lote de alterações. Para adicionar alterações de unidade de alteração, especifique um valor diferente de NULL para o parâmetro ppChangeBuilder do método ISyncChangeBatchBase::AddItemMetadataToGroup. O objeto ISyncChangeBuilder retornado pode ser usado para adicionar alterações de unidade de alteração à alteração do item associado usando ISyncChangeBuilder::AddChangeUnitMetadata.
Processando alterações de unidade de alteração
Quando o provedor de destino usa um aplicador de alterações para a ajudar processar um lote de alterações no método ProcessChangeBatch (para código gerenciado) ou IKnowledgeSyncProvider::ProcessChangeBatch (para código não gerenciado), o provedor de destino enumera as informações de versão de destino para cada alteração recebida do provedor de origem. Quando uma alteração de origem contém alterações da unidade de alteração, o provedor de destino deve determinar quais versões (se houver) da unidade de alteração devem ser incluídas no lote de versões de destino. Essa decisão depende do tipo de alteração do provedor de origem e do fato de o item estar ou não marcado como excluído na réplica de destino. A tabela a seguir mostra as informações de versão que o provedor de destino deve enviar ao aplicador de alterações.
|
A alteração de origem é uma exclusão |
A alteração de origem é uma atualização |
O item de destino é excluído |
Apenas a versão do item de destino. As exclusões só são permitidas em itens inteiros. Portanto, as informações de versão para uma exclusão são rastreadas para o item. |
Apenas a versão do item de destino. As exclusões só são permitidas em itens inteiros. Portanto, as informações de versão para uma exclusão são rastreadas para o item. |
O item de destino não é excluído |
Todas as versões de unidade de alteração de destino. |
Apenas as versões de unidade de alteração de destino para as unidades de alteração enumeradas da origem. |
Tratando conflitos que contêm unidades de alteração
Quando um aplicativo usa resolução de conflito personalizada para alterações que contêm unidades de alteração, geralmente ele deve definir a ação de resolução de conflito para o conflito de unidade de alteração usando SetResolutionAction(ChangeUnitChange, ConflictResolutionAction) (para código gerenciado) ou IChangeConflict::SetResolveActionForChangeUnit (para código não gerenciado).
Porém, quando o conflito é causado por uma atualização em uma réplica e uma exclusão na outra, o aplicativo deve especificar a ação de resolução de conflito para o conflito de item usando SetResolutionAction(ConflictResolutionAction) (para código gerenciado) ou IChangeConflict::SetResolveActionForChange (para código não gerenciado).
Aplicando alterações de unidade de alteração
Normalmente, quando uma alteração contém unidades de alteração, Sync Framework chama SaveChangeWithChangeUnits (para código gerenciado) ou ISynchronousNotifyingChangeApplierTarget::SaveChangeWithChangeUnits (para código não gerenciado) para aplicar a alteração à réplica de destino. Porém, quando um conflito ocorre e é resolvido com a exclusão do item, Sync Framework chama SaveItemChange (para código gerenciado) ou ISynchronousNotifyingChangeApplierTarget::SaveChange (para código não gerenciado). Isso ocorre porque só é possível excluir itens inteiros e não unidades de alteração individuais.