• Статья

Обмен данными с мобильными пользователями

Обмен данными с мобильными пользователями является ключевой частью многих приложений. Большинство приложений, поддерживающих мобильных пользователей, относятся к одной из двух больших категорий:

  • Управление взаимоотношениями с клиентами (CRM) и средства автоматизации процесса продаж (SFA)

    Например, менеджер по продажам может использовать приложение SFA для ввода данных заказа при посещении клиента. Эти данные затем передаются обратно на центральный узел, например в центральный офис компании или в центр обработки данных.

  • Автоматизация выездного обслуживания

    Например, работники на выезде — водители, доставляющие продукцию, обслуживающий персонал, инспектора и другие — могут использовать приложение FFA (Field force automation) в карманном компьютере для сбора и передачи данных из удаленных мест. Водитель, доставляющий продукцию, может вводить данные о доставке контейнеров в пункты назначения, и эти данные затем передаются обратно на центральный узел.

Обе категории приложений имеют очень схожие требования к репликации. Основным различием между этими приложениями является необходимость обновления данных одним или несколькими пользователями. Эта проблема описывается в подразделе «Общие требования для данного сценария» этого раздела.

На приводимых ниже схемах показаны два разных подхода к доставке данных мобильным пользователям: в одном применяются переносные компьютеры, а в другом — мобильные устройства (использующие Microsoft SQL Server Compact 3.5 с пакетом обновления 2 (SP2)). Первый подход наиболее часто используется с приложениями SFA и CRM, а второй — с приложениями FFA. Однако любой из этих подходов можно использовать с обеими категориями приложений.

  • На первой схеме показан сценарий, в котором группа пользователей, оснащенная переносными компьютерами, подключается непосредственно к центральному узлу:

    Репликация данных от продавцов в штаб-квартиры

  • На второй схеме показан сценарий, в котором пользователи с мобильными устройствами подключаются к центральному узлу через серверы IIS Microsoft Windows. Серверы IIS необходимы при использовании SQL Server Compact 3.5 с пакетом обновления 2 (SP2).

    Репликация данных для курьеров доставки

Примеры Adventure Works Cycles

Adventure Works Cycles — это вымышленная производственная компания, которая используется для демонстрации концепций баз данных и сценариев работы с ними. Дополнительные сведения см. в разделе Образцы баз данных AdventureWorks2008R2.

Adventure Works Cycles имеет большой штат менеджеров по продажам, которые проводят значительное время на выезде, работая непосредственно с основными клиентами компании, а также с независимыми и франчайзинговыми дилерами велосипедов. Группы продавцов работают с регионами, при этом каждый продавец обычно обслуживает своих собственных клиентов. Тем не менее данные о клиентах могут использоваться совместно продавцами и менеджерами по продажам. Продавцы вводят данные заказов на своих переносных компьютерах и передают эти данные в центральный офис, когда им удобно.

Adventure Works Cycles пользуется услугами экспедиторского агентства первого класса для доставки запчастей и велосипедов в сборе. Все водители экспедиторского агентства первого класса пользуются мобильными устройствами, на которых выполняется SQL Server Compact 3.5 с пакетом обновления 2 (SP2). Водители вводят данные о каждой доставке после ее завершения. Эти данные реплицируются в центральный офис экспедиторского агентства первого класса и удаляются с мобильного устройства. После этого данные становятся доступными для Adventure Works Cycles через клиентскую экстрасеть.

Общие требования для данного сценария

Приложения CRM, SFA и FFA обычно имеют следующие характеристики, выполнение которых должно обеспечиваться соответствующим решением репликации:

  • Синхронизация данных должна быть программируемой, чтобы приложение на переносном компьютере или мобильном устройстве можно было настроить для включения синхронизации, при этом конечному пользователю не надо разбираться в тонкостях репликации.

  • В большинстве мобильных приложений данные могут вводиться и обновляться на центральном веб-узле и на удаленных веб-узлах. В приложениях FFA большинство данных вводятся на удаленных веб-узлах.

  • Удаленные пользователи вводят и обновляют данные, используя переносной компьютер, мобильное устройство или планшетный ПК.

  • Удаленные пользователи должны иметь возможность автономного выполнения обновлений без необходимости подключения к центральному узлу.

  • Так как одни и те же данные могут обновляться несколькими пользователями независимо друг от друга, возможны конфликты данных, которые должны быть разрешены.

  • Некоторые данные должны обновляться только на центральном узле. Например, таблицы цен на продукцию.

  • Пользователям должна быть предоставлена возможность синхронизации данных по запросу, а не только по расписанию.

  • Приложение должно управлять временем, в течение которого удаленный узел может оставаться несинхронизированным.

  • Для некоторых таблиц требуется фильтрация, чтобы разные пользователи получали разные данные из одной или нескольких таблиц. Например, каждый менеджер по продажам получает контактные данные только по своим клиентам.

  • При передаче между узлами некоторые данные должны обрабатываться как отдельный блок. Например, если данные о заказе отсылаются удаленным пользователем на центральный узел, то заголовок заказа должен быть зафиксирован раньше его деталей.

  • При синхронизации данных для выполнения приложения может потребоваться пользовательская бизнес-логика.

  • Приложению может быть необходима синхронизация данных через Интернет, а не через коммутируемое соединение сети VPN или IPSEC.

Основным различием между приложениями CRM, SFA и приложениями FFA в отношении репликации является необходимость обновления данных несколькими пользователями (обновления данных несколькими пользователями могут приводить к конфликтам). Количество данных, обновляемых несколькими пользователями, зависит от экстента фильтрации данных. Например, если фильтрация данных осуществляется таким образом, что все пользователи обновляют только собственные наборы данных, то конфликты между пользователями возникать не будут:

  • В приложениях CRM и SFA данные фильтруются часто, но обновление некоторых данных все же осуществляется в нескольких местах. Некоторые данные обновляются только в центральном офисе, некоторые — одним удаленным пользователем, а некоторые — несколькими удаленными пользователями. На следующей схеме показана фильтрация, характерная для приложений CRM и SFA.

    Фильтрация для приложений автоматизации процесса продаж

  • В приложениях FFA сбор большей части данных обычно осуществляется на выезде, и затем данные передаются в центральный офис без конфликтов, поскольку один удаленный пользователь обновляет фиксированный набор данных. На следующей схеме показана фильтрация, характерная для приложений FFA.

    Фильтрация для приложений автоматизации работы на выезде

Типы репликации, доступные для использования в этом сценарии

SQL Server использует метафору издательского дела для описания компонентов системы репликации. Компоненты включают издатель, подписчики, публикации, статьи и подписки. На первых двух схемах, показанных выше, центральный офис является издателем. Данные центрального узла являются публикацией, причем каждая таблица данных представляет собой статью (статьи могут быть другими объектами базы данных, например хранимыми процедурами). Все переносные компьютеры менеджеров по продажам и мобильные устройства водителей, осуществляющих доставку, являются подписчиками на публикацию, получающими схему и данные в виде подписки. Дополнительные сведения о компонентах системы см. в разделе Обзор модели публикации репликации.

SQL Server предлагает разные виды репликации для разных требований приложений: репликация моментальных снимков, репликация транзакций и репликация слиянием. Этот сценарий лучше всего реализовать с помощью репликации слиянием, которая в достаточной мере отвечает требованиям, указанным в предыдущем разделе. Дополнительные сведения о репликации слиянием см. в разделах Обзор репликации слиянием и Как работает репликация слиянием.

Параметры репликации слиянием, важные для этого сценария

Репликация слиянием предлагает несколько возможностей выполнения требований, описанных ранее в этом разделе. В следующем списке представлены все требования и параметры репликации слиянием, которые обеспечивают их выполнение.

  • Синхронизация данных должна быть программируемой.

    Репликация обеспечивает программирование с помощью хранимых процедур и объектов RMO. RMO обычно используются для мобильных приложений. Дополнительные сведения о программировании репликации см. в разделах Руководство разработчика (репликация) и Sales Orders Sample Scenario.

  • В большинстве мобильных приложений данные могут вводиться и обновляться на центральном веб-узле и на удаленных веб-узлах. В приложениях FFA большинство данных вводятся на удаленных веб-узлах.

    Репликация слиянием предоставляет эту возможность без указания каких-либо отдельных параметров.

  • Удаленные пользователи вводят и обновляют данные, используя переносной компьютер, мобильное устройство или планшетный ПК.

    SQL Server Standard и другие выпуски (включая SQL Server Compact 3.5 с пакетом обновления 2 (SP2)) могут выполняться на переносных компьютерах и планшетных ПК, но для карманных ПК требуется выпуск SQL Server Compact 3.5 с пакетом обновления 2 (SP2). Репликация слиянием позволяет создавать публикации и подписки, которые могут использоваться выпуском SQL Server Compact 3.5 с пакетом обновления 2 (SP2). Дополнительные сведения см. в разделе Репликация данных в выпуске SQL Server Compact.

  • Удаленные пользователи должны иметь возможность автономного выполнения обновлений без необходимости подключения к центральному узлу.

    Репликация слиянием предоставляет эту возможность без указания каких-либо отдельных параметров.

  • Так как одни и те же данные могут обновляться несколькими пользователями независимо друг от друга, возможны конфликты данных, которые должны быть разрешены.

    Репликация слиянием обеспечивает обнаружение и разрешение конфликтов для случаев, в которых возможно возникновение конфликтов данных. Рекомендуется разрабатывать приложения, исключающие появление конфликтов, однако, если это невозможно, можно выбрать стандартный механизм разрешения конфликтов (предпочтение отдается первому) или использовать пользовательский механизм разрешения конфликтов. Дополнительные сведения см. в разделе Обнаружение и разрешение конфликтов репликации слиянием.

  • Некоторые данные должны обновляться только на центральном узле. Например, таблицы цен на продукцию.

    Для таблиц, которые должны обновляться только на издателе, репликация слиянием предоставляет статьи, доступные только для загрузки. Дополнительные сведения см. в разделе Оптимизация производительности репликации слиянием при работе со статьями, доступными только для загрузки.

  • Пользователям должна быть предоставлена возможность синхронизации данных по запросу, а не только по расписанию.

    Репликация предлагает подписки двух типов: принудительные подписки и подписки по запросу. Подписки по запросу лучше подходят для синхронизации по запросу. Дополнительные сведения о типах подписки и синхронизации по расписанию см. в разделах Подписка на публикации и Синхронизация данных.

  • Приложение должно управлять временем, в течение которого удаленный узел может оставаться несинхронизированным.

    Репликация слиянием позволяет задать время действия подписки, чтобы гарантировать, что все подписчики будут синхронизированы в течение определенного интервала времени. Дополнительные сведения см. в разделе Окончание срока действия и отключение подписки.

  • Для некоторых таблиц требуется фильтрация, чтобы разные пользователи получали разные данные из одной или нескольких таблиц. Например, каждый менеджер по продажам может получать контактные данные только по своим клиентам.

    Репликация слиянием позволяет фильтровать столбцы и строки. Фильтры строк могут быть статическими или параметризованными. Статические фильтры применяются только при создании публикации; результат применения представляет собой один набор данных. Параметризованные фильтры применяются при каждой синхронизации подписчика; результатом применения являются разные наборы данных для разных подписчиков. В приложениях CRM и SFA часто используются параметризованные фильтры, но могут использоваться и статические фильтры. Дополнительные сведения см. в разделе Фильтрация опубликованных данных для репликации слиянием.

  • При передаче между узлами некоторые данные должны обрабатываться как отдельный блок. Например, если данные о заказе отсылаются удаленным пользователем на центральный узел, то заголовок заказа должен быть зафиксирован раньше его деталей.

    Репликация слиянием позволяет указывать то, что набор связанных таблиц должен обрабатываться как единый блок. Такой блок называется логической записью. Дополнительные сведения см. в разделе Изменения группирования связанных строк с логическими записями.

  • При синхронизации данных для выполнения приложения может потребоваться пользовательская бизнес-логика.

    Репликация слиянием позволяет указать код, который должен выполняться во время синхронизации. Этот код может реагировать на широкий диапазон событий и иметь доступ к синхронизируемым данным. Дополнительные сведения см. в разделе Выполнение бизнес-логики при синхронизации слиянием.

  • Приложению может требоваться синхронизация данных через Интернет вместо синхронизации через выделенное соединение.

    При использовании выпуска (SQL Server Compact 3.5 с пакетом обновления 2 (SP2)) данные синхронизируются через соединение по протоколам HTTP или HTTPS. Для других выпусков SQL Server можно использовать веб-синхронизацию, для которой требуется HTTPS-соединение. Дополнительные сведения см. в разделе Веб-синхронизация для репликации слиянием.

Шаги по реализации этого сценария

Чтобы реализовать этот сценарий, прежде всего необходимо создать публикацию и подписки, а затем инициализировать каждую подписку. Для перехода к дополнительным сведениям по каждому шагу щелкните ссылки, приводимые ниже:

После того как подписка инициализирована и выполняется обмен данными между издателем и подписчиками, возможно, потребуется ознакомиться с дополнительными сведениями в следующих разделах, в которых рассматриваются общие задачи администрирования и наблюдения: