Синхронизация данных в системе сервер-клиенты, в которой клиенты не работают в режиме on-line.

Автор: Александр Клочков

1.    Постановка задачи.

Имеется некая система, созданная на базе FileMaker, сделанная для строительной компании. Система рассчитана на пользователей, которые работают исключительно на iPhone-ах. И которые создают некие свои записи различных таблиц в off-line режиме, так как в большинстве случаев они работают в местах, где нет Интернета.

Основные таблицы, имеющиеся в системе:

  1. Адреса (по смыслу это данные компаний).
  2. Персонал – здесь находятся все пользователи системы.
  3. Прайс-лист
  4. Объекты.
  5. Транзакции: приходы и расходы (с фото квитанций).

Система предназначены для учета контроля средств при строительстве объекта.

Все пользователи должны иметь общую картину по всем объектам. То есть они должны нажатием кнопки закачивать всю новую информацию (по всем таблицам), которая была создана на iPhone других пользователей

Среди пользователей (назовем их менеджерами «М») есть директор (Д) компании, который имеет исключительные право добавлять и редактировать данные в первых трёх таблицах. следующее.

М и Д имеют свои индивидуальные файлы системы на своих iPhone. Назовем их (эти файлы) Manager. В моем конкретном случае их пять.

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

1. Адреса
Д — создание новых записей, экспорт на сервер.
М —  только импорт новых (для данного М ) записей с сервера.

2.Персонал
Д — создание новых записей, экспорт на сервер.
М — только импорт новых (для данного М ) записей с сервера.

3.Прайс-лист
Д — создание новых записей, экспорт на сервер.
М — только импорт новых (для данного М ) записей с сервера.

4.Объекты
Д — создание новых записей, экспорт на сервер, импорт новых записей, созданных Менеджерами.
М — создание новых записей, экспорт их на сервер, импорт новых записей, созданных Менеджерами.

5.Транзакции
Д — создание новых записей, экспорт на сервер, импорт новых записей, созданных Менеджерами.
М — создание новых записей, экспорт их на сервер, импорт новых записей, созданных Менеджерами.

2.    Решение задачи.

Синхронизация делается путем обмена данными с аналогичной системой, расположенной на сервере. То есть аналогичный, но с некоторыми своими отличиями, файл запущен под хостингом у некого провайдера. Назовём данный файл Office.

Синхронизация, в том виде, в котором она в настоящий момент сделана организуется следующим способом.

Идея состоит в том, что все записи, которые создаются менеджерами во всех таблицах имеют идентификаторы (текстовое поле) – то есть поля , которые определяют уникальность записи.
Очевидно, что, например , для записей таблицы транзакции,  идентификатор должен содержать в себе информацию о трех составляющих. Объекте, менеджере и счетчика транзакции в файле. Например 1.012.734. где:
1 – ID объекта
012 —  ID пользователя (менеджера или директора)
734 —  значение счетчика записи в таблице транзакций.

Можно применять и другие разделители. Я выбрал точку.

Также каждая запись имеет идентификатор (Назовем его FlagExport), который показывает —  была ли данная запись экспортирована с телефона данного пользователя или пока нет. Значение FlagExport =1 будет означить, что запись еще не экспортирована на сервер,
FlagExport =0 будет означить, что запись уже экспортирована на сервер.

Имея эти два идентификатора, мы четко можем определять с чем ( с какими записями ) работаем.

Работа на стороне пользователя происходит следующим образом.

  1. В файле Manager нажимается кнопка «Синхронизация». Она запускает скрипт (назовем его Синхронизация), выполняющий следующие действия.
    — перебирает все имеющиеся таблицы и в каждой делает выборку тех записей, у которых FlagExport =1.
    — заодно считает, сколько в какой таблице выбрано записей.
    — выдает сообщение для пользователя , что к экспорту подготовлено столько-то таких-то записей.
    — предлагает дать подтверждение – все таки-экспортировать записи. Или отменить экспорт.
    — в случае отмены – просто выходим из скрипта.

2. В случае подтверждения синхронизации сразу меняем флаг FlagExport =1 в каждой выбранной записи каждой таблицы. И запускаем процедуру экспорта. (Для новичков напомню, что в FileMaker нет понятия экспорта из FM файла в другой FM файл. Есть только понятие импорта). Следовательно подготовив на файле Manager нужный набор записей, нужно перейти на файл Server. Но файл Server должен каким-то образом понять – откуда он будет импортировать данные. То есть ему нужно указать путь к тому телефону, у которого он будет брать (импортировать данные). Этот путь вычисляется с самого начала скрипта Синхронизация. Ниже представлен образец данного скрипта.

Переменная $Path запоминает путь, по которому потом, уже в файле Office , будет определяться путь файла, из которого будет производиться импорт. Также в этом скрипте в переменную запоминается ID того пользователя, который сейчас экспортирует данные. Это нужно для идентификации менеджеров , от которых эти данные были импортированы. Соответственно, остальные менеджеры, пока этих данных не имеют. Как организована идентификация менеджеров, которые потом скачали эту запись, будет описано позднее.

Picture1
Рис.1

Таким образом мы экспортировали все записи, которые ранее не были экспортирован на сервер в файл Office. Если говорить строго – импортировали нужные записи из одного из файлов Manager.

Теперь мы подошли к следующему шагу. На этом шаге нужно донести эту информацию о новых появившихся записях остальным пользователям (то есть 1 из пяти внес данные, оставшиеся 4 должны их получить).

Это организовано так.
Периодически (как правило раз в день) все пользователи обновляют свои данные данными с сервера (из файла Office) нажатием кнопки. Скрипт на данной кнопке делает следующее.

Picture2

… здесь я пропустил аналогичные шаги, которые не принципиальны для понимания работы скрипта. Ниже показан конец скрипта.

Picture3
Рис.2

В переменной $Path задается путь файла Office на сервере из которого будет производиться импорт. Выглядит примерно так  fmnet:/dbfms19.pointinspace.com/plsOffice .

В поле (глобальное) PathOffice это значение в моем примере было вставлено ранее при открытии файла Manager. Данное значение является практически неизменяемым. Если только вы не изменили провайдера хостинга.

Также в переменных определяются  ID и имя менеджера (пользователя).

Затем открывается файл Office на сервере и делаем на нем скрипт «500а Подготовка записей», которые еще не были импортированы данным менеджером

Picture4

Рис.3.
Поиск нужных записей происходит по репетиционному полю FlagOfficeManager. Значения этого поля изначально устанавливаются как 1,2.3,4. и 5 в соответствующих репетициях.

Примеры полей для нескольких записей даны ниже.

Picture5

Рис.4

Пусть у нас IDManager =3. Делаем поиск (показан ниже) записей, у которых третье репетиционное поле =3. В приведенном выше примере найдется 2 записи.

Picture6

Затем, после того как записи выделены, заменяем это третье репетиционное поле на значение 0. Операцией Replace (строка 10).

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

Далее все достаточно очевидно. После того, как сделали выборку нужных записей в Office скрипом 500а, возвращаемся в файл Manager в скрипт на рис.2

Последовательно проходим все таблицы и для каждой делаем импорт выбранных записей из такой же таблицы на сервере (в файле Office).

Материал подготовлен Александром Клочковым.
Связаться с автором можно: apklotchkov@yahoo.com

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

− 2 = 2