Compartilhar via


Aplicando alterações usando o serviço de aplicação de alterações

O serviço de aplicação de alterações executa as mesmas ações que o componente aplicador de alterações do Sync Framework, porém de modo mais granular. Um provedor de destino que requer mais flexibilidade que a fornecida pelo aplicador de alterações padrão pode usar o serviço de aplicação de alterações para executar apenas o conjunto de ações exigido pelo provedor. Por exemplo, um provedor pode realizar sua própria detecção de conflitos e usar o serviço de aplicação de alterações para calcular o conhecimento atualizado. Ou um provedor de destino pode usar o serviço de aplicação de alterações para aplicar alterações em uma ordem diferente da enviada pelo provedor de origem.

Lembre-se de que o serviço do aplicativo de alteração não pode ser usado por um provedor que relate conflitos de restrição ou use filtros personalizados, ou podem ocorrer resultados inesperados.

Processando alterações

Para processar alterações, o provedor de destino executa as seguintes etapas:

  1. Cria e inicializa o serviço do aplicador de alterações.

  2. Inicia uma sessão de aplicação de alterações.

  3. Usa o serviço de aplicação de alterações para executar a detecção de conflitos e a aplicação de alterações que, de outra forma, não seriam manipuladas pelo provedor.

  4. Relata as alterações cuja aplicação falhou.

  5. Opcionalmente, relata as alterações que foram aplicadas com êxito. Isso é necessário somente quando o provedor recupera o conhecimento de destino atualizado durante a sessão de aplicação de alterações. Caso contrário, é mais eficiente relatar apenas as alterações que falharam e recuperar o conhecimento de destino atualizado uma vez após o encerramento da sessão de aplicação de alterações.

  6. Encerra a sessão de aplicação de alterações. O serviço de aplicação de alterações retorna o conhecimento de destino atualizado para o lote de alterações processado.

Criando o objeto de serviço de aplicação de alterações

O provedor de destino cria e inicializa o objeto ChangeApplicationServices (para código gerenciado) ou o objeto IChangeApplicationServices (para código não gerenciado). Isso é realizado chamando ChangeApplicationServices (para código gerenciado) ou passando IID_IChangeApplicationServices para IProviderSyncServices::CreateChangeApplier e chamando IChangeApplicationServices::Initialize (para código não gerenciado).

Iniciando uma sessão de aplicação de alterações

O provedor de destino inicia uma sessão de aplicação de alterações chamando BeginChangeApplication (para código gerenciado) ou IChangeApplicationServices::BeginChangeApplication (para código não gerenciado). O conhecimento de destino passado para esse método é usado como base para o cálculo do conhecimento de destino atualizado durante e após a aplicação de alterações.

Processando uma alteração

O provedor de destino usa o serviço de aplicação de alterações para processar somente as alterações que, de outra forma, não seriam manipuladas. Por exemplo, um provedor de destino executa sua própria detecção de conflitos e aplica as alterações. Nesse caso, o serviço de aplicação de alterações não é usado para processar as alterações. Ou um provedor de destino aplica as alterações em uma ordem diferente da enviada pelo provedor de origem. Nesse caso, o serviço de aplicação de alterações é usado para processar alterações na ordem especificada pelo provedor de destino.

Para processar uma alteração, o provedor de destino executa as seguintes etapas:

  1. Chama GetChangeApplicationContext (para código gerenciado) ou IChangeApplicationServices::GetChangeApplicationContext (para código não gerenciado) a fim de iniciar o processamento de uma alteração. Esse método retorna um objeto ChangeApplicationContext (para código gerenciado) ou um objeto IChangeApplicationContext (para código não gerenciado).

  2. Obtém a propriedade ChangeApplicationAction (para código gerenciado) ou chama IChangeApplicationContext::GetChangeApplicationAction (para código não gerenciado). Esse método retorna a próxima ação a ser executada como um valor ChangeApplicationAction (para código gerenciado) ou um valor Interface IChangeApplicationContext (para código não gerenciado).

  3. Executa a ação especificada, como salvar a alteração da réplica de destino. Para obter mais informações sobre como manipular as ações possíveis, consulte os tópicos de referência dos componentes do serviço de aplicação de alterações.

  4. Repita essas etapas até que a ação retornada na etapa 1 seja Finished (para código gerenciado) ou CAA_FINISHED (para código não gerenciado).

Relatando alterações bem-sucedidas e com falhas

Se o provedor de destino usar o serviço de aplicação de alterações para calcular o conhecimento atualizado, o provedor deverá relatar todas as alterações cuja aplicação falhou antes do encerramento da sessão de aplicação de alterações. Para relatar uma alteração com falhas, chame ReportRecoverableErrorOnItemChange ou ReportRecoverableErrorOnChangeUnitChange (para código gerenciado) ou IChangeApplicationServices::ReportRecoverableErrorOnItemChange ou IChangeApplicationServices::ReportRecoverableErrorOnChangeUnitChange (para código não gerenciado).

Além disso, se o provedor de destino recuperar o conhecimento de destino atualizado durante a sessão de aplicação de alterações, o provedor deverá relatar as alterações que foram aplicadas com êxito. O conhecimento de destino atualizado é recuperado chamando GetUpdatedDestinationKnowledge (para código gerenciado) ou IChangeApplicationServices::GetUpdatedDestinationKnowledge (para código não gerenciado). Não é necessário relatar as alterações bem-sucedidas quando o provedor recupera o conhecimento atualizado somente após o encerramento da sessão de aplicação de alterações. Para relatar uma alteração aplicada com êxito, chame ReportItemChangeApplied ou ReportChangeUnitChangeApplied (para código gerenciado) ou IChangeApplicationServices::ReportItemChangeApplied ou IChangeApplicationServices::ReportChangeUnitChangeApplied (para código não gerenciado).

Encerrando uma sessão de aplicação de alterações

Quando todas as alterações foram processadas, o provedor de destino encerra a sessão de aplicação de alterações chamando EndChangeApplication (para código gerenciado) ou IChangeApplicationServices::EndChangeApplication (para código não gerenciado). O conhecimento adquirido contido no lote de alterações do provedor de origem é passado para esse método. O serviço de aplicação de alterações calcula o conhecimento de destino atualizado a partir do conhecimento adquirido e das alterações que foram relatadas como tendo falhado. O conhecimento de destino atualizado retornado desse método deve substituir o conhecimento atual da réplica de destino.

Consulte também

Conceitos

Aplicando alterações