Integrando dados de diversos sites (cliente)
Muitas empresas têm escritórios ou entidades regionais que coletam e processam dados que devem ser enviados a um local central. Por exemplo:
Os dados de inventário podem ser consolidados de um número de servidores em armazéns locais para um servidor central nos escritórios centrais corporativos.
As informações de divisões empresariais independentes dentro de uma empresa podem ser enviadas para um servidor central.
As informações de processamento de pedidos de locais distribuídos podem ser consolidadas.
Em alguns casos, os dados também são enviados do site central para sites remotos. Normalmente, esses dados destinam-se somente para leitura no site remoto, como uma série de tabelas de inventários de produtos que são atualizadas somente no site central.
O diagrama a seguir ilustra um cenário comum com os dados fluindo em duas direções entre um site central e locais remotos:
.gif "Replicando dados para escritórios regionais")
Neste diagrama, os dados primeiro fluem para um centro antes de serem enviados aos escritórios regionais servidos por esse centro. Também é possível que os dados fluam diretamente entre os escritórios centrais e regionais se a empresa não possuir uma camada intermediária.
Exemplo Adventure Works Cycles
A Adventure Works Cycles é uma empresa de fabricação fictícia utilizada para demonstrar conceitos e cenários de banco de dados. Para obter mais informações, consulte Bancos de dados de exemplo AdventureWorks2008R2.
A Ciclos da Adventure Works tem um número grande de escritórios de vendas ao redor do mundo. Cada escritório de vendas coleta dados da sua equipe de vendas regional. Esses dados são transmitidos para centros regionais e, em seguida, para o site central ao final de cada dia útil. Os dados também são transmitidos do site central pelos centros para cada escritório de vendas, de modo que o escritório de vendas tenha as informações mais recentes sobre preços e promoções.
Requisitos comuns deste cenário
Os aplicativos dos escritórios regionais normalmente têm as características a seguir, que deverão ser encaminhadas por uma solução de replicação apropriada:
Os dados são digitados e atualizados em um site central e em sites remotos.
Os usuários remotos devem poder fazer atualizações de forma independente, sem a necessidade de conexão com o site central.
Como diversos usuários podem atualizar os mesmos dados de forma independente, podem surgir conflitos de dados e devem ser controlados.
Alguns dados devem ser atualizados somente no site central, por exemplo, os dados das tabelas de composição de preços de produtos.
Os usuários devem poder sincronizar os dados sob demanda ou em horas programadas.
O aplicativo deve controlar o tempo durante o qual um site remoto pode permanecer não sincronizado.
Algumas tabelas exigem a filtragem de modo que cada usuário receba dados diferentes para uma ou mais tabelas. Por exemplo, um escritório regional só recebe informações de contato dos clientes na região do escritório.
Alguns dados devem ser tratados como uma unidade quando transferidos entre sites. Por exemplo, se um pedido foi enviado de um usuário remoto para o site central, o cabeçalho do pedido deve estar confirmado antes dos detalhes do pedido.
O aplicativo pode requerer a execução de lógica corporativa personalizada quando os dados forem sincronizados.
O aplicativo pode exigir que os dados sejam sincronizados pela Internet no lugar de uma conexão dedicada.
O negócio pode ser organizado de modo que os dados fluam por uma ou mais camadas entre o site central e sites remotos (como no diagrama anterior neste tópico).
O diagrama a seguir ilustra a filtragem associada com este cenário:
.gif "Filtragem de aplicativos de escritório regional")
O tipo de replicação a ser usado nesse cenário
O Microsoft SQL Server usa uma metáfora da indústria de publicação para descrever os componentes do sistema de replicação. Os componentes abrangem Publicador, Assinantes, publicações e artigos, além de assinaturas. No diagrama acima, o site central é o Publicador. Os dados no site central fazem parte da publicação, com cada tabela de dados sendo um artigo (os artigos também podem ser outros objetos de banco de dados, como os procedimentos armazenados). Cada centro é um Assinante para a publicação, recebendo o esquema e dados como uma assinatura. Então, os centros republicam os dados e os escritórios regionais fazem a assinatura destes dados. Para obter mais informações sobre os componentes do sistema, consulte Visão geral do modelo de publicação de replicação.
O SQL Server oferece diferentes tipos de replicação para diferentes requisitos de aplicativo: replicação de instantâneo, replicação transacional e replicação de mesclagem. O cenário é implementado da melhor forma com a replicação de mesclagem, a qual fica bem ajustada para controlar os requisitos descritos na seção anterior. Para obter mais informações sobre replicação de mesclagem, consulte Visão geral da replicação de mesclagem. e Como a replicação de mesclagem funciona.
.gif "Observação importante") Importante |
|---|
É possível implementar esse cenário de duas maneiras: o escritório central é um Publicador e os escritórios remotos são Assinantes ou o escritório central é um Assinante e os escritórios remotos são Publicadores. A replicação de mesclagem não dá suporte às topologias do Assinante central. Mesmo se todas as alterações estejam ocorrendo em sites remotos, o escritório central deverá ser configurado como Publicador com os sites remotos como Assinantes. Um cenário semelhante pode ser implementado com replicação transacional usando uma topologia de Assinante central. Se o seu aplicativo não exigir a solução de conflitos ou filtros para fornecer um conjunto de dados exclusivos para cada site remoto, considere o uso da replicação transacional. Para obter mais informações, consulte Integrando dados de diversos sites (servidor). |
Opções de replicação de mesclagem pertinentes a este cenário
A replicação de mesclagem oferece várias opções para encaminhar os requisitos descritos anteriormente neste tópico. A lista a seguir apresenta cada requisito e as opções de replicação de mesclagem que encaminham isto.
Os dados são inseridos e atualizados em um site central e em sites remotos.
A replicação de mesclagem fornece essa capacidade sem especificar quaisquer opções separadas.
Os usuários remotos devem poder fazer atualizações de forma independente, sem a necessidade de conexão com o site central.
A replicação de mesclagem fornece essa capacidade sem especificar quaisquer opções separadas.
Como diversos usuários podem atualizar os mesmos dados de forma independente, podem surgir conflitos de dados e devem ser controlados.
A replicação de mesclagem fornece a detecção e solução de conflitos para os casos em que os conflitos de dados são previstos. Em aplicativos de projetos é melhor evitar conflitos, mas quando isto não for possível você poderá selecionar o mecanismo padrão de solução de conflitos (o primeiro a entrar vence) ou usar solução de conflitos personalizada. Para obter mais informações, consulte Detectando e resolvendo conflitos de replicação de mesclagem.
Alguns dados devem ser atualizados somente no site central, por exemplo, os dados das tabelas de composição de preços de produtos.
A replicação de mesclagem fornece artigos de somente download para essas tabelas que devem ser atualizadas somente no Publicador. Para obter mais informações, consulte Otimizando o desempenho de replicação de mesclagem com artigos de somente download.
Os usuários devem poder sincronizar os dados sob demanda, e em horas programadas.
A replicação oferece dois tipos de assinatura: assinaturas push e pull. As assinaturas pull se encaixam melhor em sincronização sob demanda. Para obter mais informações sobre tipos de assinaturas e programação de sincronização, consulte Assinando publicações e Sincronizando dados.
O aplicativo deve controlar o tempo durante o qual um site remoto pode permanecer não sincronizado.
A replicação de mesclagem permite que você configure um período de validade de assinatura para assegurar que todos os Assinantes sincronizaram dentro de uma determinada extensão de tempo. Para obter mais informações, consulte Validade e desativação de assinatura.
Algumas tabelas exigem a filtragem de modo que cada usuário receba dados diferentes para uma ou mais tabelas. Por exemplo, cada funcionário de vendas pode receber informações de contato somente por seus clientes.
A replicação de mesclagem permite a filtragem de colunas e linhas. Filtros de linha podem ser estáticos ou com parâmetros. Um filtro estático é aplicado somente quando uma publicação for criada e resulta em um conjunto de dados. Um filtro com parâmetros é aplicado sempre que um Assinante sincronizar e isso resulta em um conjunto diferente de dados para cada Assinante. Aplicativos de escritório regionais usam com freqüência os filtros com parâmetros, mas também podem usar filtros estáticos. Para obter mais informações, consulte Filtrando dados publicados para replicação de mesclagem.
Alguns dados devem ser tratados como uma unidade quando transferidos entre sites. Por exemplo, se um pedido for enviado de um usuário remoto para o site central, o cabeçalho do pedido deve estar confirmado antes dos detalhes do pedido.
A replicação de mesclagem permite especificar que um conjunto de tabelas relacionadas deve ser processado como uma unidade. Esta unidade é chamada de registro lógico. Para obter mais informações, consulte Agrupando alterações a linhas relacionadas com registros lógicos.
O aplicativo pode requerer a execução de lógica corporativa personalizada quando os dados forem sincronizados.
A replicação de mesclagem permite especificar o código a ser executado durante a sincronização. Este código pode responder a uma ampla variedade de eventos e tem acesso aos dados que estão sendo sincronizados. Para obter mais informações, consulte Executando lógica comercial durante sincronizações de mesclagem.
O aplicativo pode exigir que os dados sejam sincronizados pela Internet no lugar de uma conexão dedicada.
Ao usar o SQL Server Compact 3.5 Service Pack 2(SQL Server Compact 3.5 SP2), os dados são sincronizados em uma conexão HTTP ou HTTPS. Para outras edições do SQL Server, você pode usar a sincronização da Web que requer HTTPS. Para obter mais informações, consulte Sincronização da Web para replicação de mesclagem.
O negócio pode ser organizado de modo que os dados fluam por uma ou mais camadas entre o site central e sites remotos.
A replicação de mesclagem pode acomodar este requisito por meio da republicação, uma abordagem na qual um Publicador central publica os dados para um ou mais Assinantes, os quais por sua vez, publicam os dados para outros Assinantes. Para obter mais informações, consulte Republicando Dados.
Etapas para implementar este cenário
Para implementar este cenário, você deve primeiro criar uma publicação e assinaturas para depois inicializar cada assinatura. Clique nos links abaixo para obter mais informações sobre cada etapa:
Após a inicialização da assinatura, e com os dados fluindo entre o Publicador e os Assinantes, talvez seja necessário consultar os seguintes tópicos para obter informações sobre as tarefas comuns de administração e monitoramento: