Aplicativos de POS (ponto de venda ao consumidor)
Os aplicativos de POS (ponto de venda de consumidor) incluem os aplicativos que os consumidores encontram diretamente ou indiretamente no ponto de venda. Os exemplos incluem os terminais usados por caixas, bancos 24 horas, e em quiosques de lojas. Estes aplicativos coletam dados em sites remotos e os transmitem de volta a um local central, como um escritório central ou centro de dados. Nesses aplicativos é comum os dados serem coletados basicamente no ponto de vendas e em seguida carregados para os escritórios centrais sem conflitos, porque um único usuário remoto (normalmente um cliente ou atendente de vendas) está atualizando uma determinada parte dos dados.
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 de filiais para o escritório central")
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.
Muitas lojas de varejo que vendem produtos Ciclos da Adventure Works usam sistemas POS que recebem e transmitem dados de e para um site central. Normalmente, os dados de estoque dos depósitos e a composição de preços de produtos do tipo somente leitura são enviados para a loja de varejo quando ocorrerem as atualizações nestes dados. As informações de compras do cliente são transmitidas de cada loja de varejo para o site central.
Requisitos comuns deste cenário
Os aplicativos POS normalmente têm as seguintes características, as quais deverão encaminhar uma solução de replicação apropriada:
A maioria dos dados é inserida e atualizada nos sites remotos.
Os usuários remotos devem poder fazer atualizações de forma independente, sem a necessidade de conexão com o site central.
Os dados atualizados em um site remoto não são atualizados em qualquer outro site; por isso, os conflitos normalmente não ocorrem.
Alguns dados só devem ser atualizados no site central; por exemplo, os dados das tabelas de descrição de produtos.
Os usuários sincronizam os dados em horas marcadas (como o final do dia útil).
O aplicativo deve controlar o tempo durante o qual um site remoto pode permanecer não sincronizado.
Algumas tabelas exigem a filtragem de forma que cada loja receba dados diferentes para uma ou mais tabelas. Por exemplo, cada loja recebe informações somente de produtos que estoca.
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 em vez de uma conexão dedicada.
O diagrama a seguir ilustra a filtragem associada a este cenário:
.gif "Filtragem de aplicativos de ponto-de-vendas")
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 terminal de ponto de vendas é um Assinante para a publicação, recebendo o esquema e os dados como uma assinatura. 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, que 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.
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.
A maioria dos dados é inserida e atualiza nos 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.
Os dados atualizados em um site remoto não são atualizados em qualquer outro site; por isso, os conflitos normalmente não ocorrem.
Em aplicativos de POS, conflitos são evitados com freqüência porque um único usuário atualiza uma determinada parte dos dados. Como os dados não se sobrepõem entre os usuários, é possível otimizar o desempenho com a opção de partições não-sobrepostas. Para obter mais informações, consulte a seção "Configurando opções de partição" no tópico Filtro de linha com parâmetros.
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 esperados. 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 não somente em horas marcadas.
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.
A maioria das tabelas exige a filtragem, de modo que cada usuário receba dados diferentes para uma ou mais tabelas.
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 resulta em um conjunto diferente de dados para cada Assinante. Aplicativos de POS usam freqüentemente 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.
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 em vez de em uma conexão dedicada.
Ao usar o 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.
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: