Troca de dados com usuários móveis
Fornecer e coletar dados de usuários móveis é parte fundamental de muitos aplicativos. A maioria dos aplicativos que dá suporte aos usuários móveis se classifica em uma de duas categorias abrangentes:
CRM (Gerenciamento de Relacionamento com o Cliente) e SFA (Automação de Força de Vendas)
Por exemplo, um vendedor pode usar um aplicativo SFA para inserir dados de pedidos enquanto visita um cliente. Estes dados são transmitidos em seguida de volta a um local central, como os escritórios centrais da empresa ou um centro de dados.
FFA (Automação de Força em Campo)
Por exemplo, os trabalhadores em campo – motoristas de entrega, funcionários de manutenção, supervisores e outros – podem usar um aplicativo FFA como dispositivo manual para coletar e transmitir dados de locais remotos. Um motorista de entrega pode inserir dados sobre entregas de pacotes nos locais de entrega e esses dados são transmitidos em seguida para um local central.
Ambas as categorias de aplicativos exigem recursos de replicação muito semelhantes. A diferença básica entre os aplicativos é a questão dos dados serem ou não atualizados por mais de um usuário. Esta questão é tratada na seção "Requisitos comuns para este cenário" neste tópico.
O diagrama a seguir ilustra duas abordagens diferentes para distribuir dados para usuários móveis: uma usa laptops e a outra, dispositivos (que executam o Microsoft SQL Server Compact 3.5 SP1). A primeira abordagem, normalmente é mais usada com aplicativos SFA e CRM e a segunda abordagem é mais usada com os aplicativos FFA. No entanto, qualquer abordagem pode ser usada para qualquer categoria de aplicativo.
O primeiro diagrama ilustra um cenário no qual um conjunto de usuários com laptops se conecta diretamente a um site central:
.gif "Replicando dados de vendedores para o escritório central")
O segundo diagrama ilustra um cenário no qual um conjunto de usuários com dispositivos se conecta por meio dos servidores do Windows Internet Information Services (IIS) Microsofta um site central. Os servidores de IIS são requeridos ao usar o SQL Server Compact 3.5 SP1.
.gif "Replicando dados para drivers de entrega")
Exemplos 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 AdventureWorks.
O Adventure Works Cycles tem uma grande força de vendas que gasta uma quantidade considerável de seu tempo em campo trabalhando diretamente com os principais clientes da empresa, revendedores independentes e de franquias de bicicletas. Pessoas da equipe de vendas são designadas para regiões e cada pessoa de vendas controla normalmente seus próprios clientes. No entanto, os dados de clientes podem ser compartilhados pelas pessoas de vendas e gerentes de vendas. O pessoal de vendas insere os dados dos pedidos em seus laptops e transmite estes dados para o escritório central quando for conveniente.
O Adventure Works Cycles usa Remessa A-1 para suas entregas de peças e bicicletas montadas. Todas as unidades de entrega da Remessa A-1 usam dispositivos que executam SQL Server Compact 3.5 SP1. Os motoristas inserem os dados sobre cada entrega após sua conclusão. Estes dados são replicados para o escritório central da Remessa A-1 e excluídos do dispositivo. Em seguida, os dados ficam disponíveis para Adventure Works Cycles por meio de uma extranet de clientes.
Requisitos comuns deste cenário
Os aplicativos de CRM, SFA e FFA normalmente possuem as características a seguir, as quais deverão ser encaminhadas por uma solução de replicação apropriada:
A sincronização de dados deve ser programável, de modo que um aplicativo de um dispositivo ou laptop possa ser personalizado ou incluir a sincronização sem exigir conhecimento de replicação do usuário final.
Na maioria dos aplicativos móveis, os dados podem ser inseridos e atualizados em um site central e em sites remotos. Nos aplicativos FFA, a maioria dos dados é inserida em sites remotos.
Os usuários remotos inserem e atualizam dados usando um laptop, dispositivo ou Tablet PC.
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, e não somente em horas marcadas.
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, cada funcionário de vendas recebe informações de contato somente por seus clientes.
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 de rede discada IPSEC ou VPN.
A diferença básica entre os aplicativos de CRM e SFA e FFA em relação à replicação é se os dados são ou não atualizados por mais de um usuário (atualizações feitas por mais de um usuário podem resultar em conflitos). A quantidade de dados que é atualizada por mais de um usuário depende da extensão em que os dados são filtrados. Por exemplo, se os dados forem filtrados de modo que todos os usuários somente atualizarem seu próprio conjunto de dados, não ocorrerão conflitos entre os usuários:
Nos aplicativos de CRM e SFA, os dados são filtrados com freqüência, mas alguns dados ainda serão atualizados em mais de um lugar. Alguns dados são atualizados somente em escritórios centrais, alguns por um usuário remoto e outros por mais de um usuário remoto. O diagrama a seguir ilustra a filtragem comum em CRM e SFA:
.gif "Filtragem para aplicativos de automação da força de vendas")
Nos aplicativos FFA, é comum os dados serem coletados basicamente em campo e, em seguida, carregados para os escritórios centrais sem conflitos, porque um único usuário remoto está atualizando uma determinada parte dos dados. O diagrama a seguir ilustra a filtragem comum em aplicativos FFA:
.gif "Filtragem para aplicativos de automação da força de campo")
O tipo de replicação a ser usado nesse cenário
O SQL Server usa uma metáfora do setor 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. Nos dois primeiros diagramas 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). O laptop de cada funcionário e o dispositivo do motorista de entrega é um Assinante da publicação, que recebe o esquema e 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 a encaminha.
A sincronização de dados deve ser programável.
A replicação oferece formas de programação por meio de procedimentos armazenados e RMO (Replication Management Objects). O RMO é normalmente usado para aplicativos móveis. Para obter mais informações sobre a programação de replicação, consulte Guia do desenvolvedor (replicação) e Sales Orders Sample Scenario.
Na maioria dos aplicativos móveis, os dados podem ser inseridos e atualizados em um site central e em sites remotos. Nos aplicativos FFA, a maioria dos dados é inserida em sites remotos.
A replicação de mesclagem fornece essa capacidade sem especificar quaisquer opções separadas.
Os usuários remotos inserem e atualizam dados usando usam um laptop, dispositivo ou tablet.
Os laptops e Tablet PCs podem executar oSQL Server Standard e outras edições (incluindo SQL Server Compact 3.5 SP1), mas os dispositivos do Pocket PC exigem o SQL Server Compact 3.5 SP1. A replicação de mesclagem permite criar publicações e assinaturas que podem ser usadas pelo SQL Server Compact 3.5 SP1. Para obter mais informações, consulte Replicando os dados no SQL Server Compact.
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 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.
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 CRM e SFA 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.
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 SP1), 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: