Вимоги бізнесу щодо забезпечення роботи мобільних користувачів
Впровадження інформаційних систем для автоматизації діяльності бізнесу вимагає від розробників баз даних реалізації все нових можливостей в розроблюваних ними додатках. Створення програмного забезпечення, що дозволяє користувачам працювати лише в межах офісу, на сьогоднішній день стає явно недостатньо. Співробітникам офісу потрібно забезпечити доступ до інформаційних масивів фірми у відрядженні, з дому, з офісу клієнта. При цьому користувачі хочуть не тільки переглядати дані, але і мати можливість вносити в них зміни. Важливою вимогою з боку адміністраторів інформаційних систем є простота установки і настройки клієнтських додатків.
Підводячи підсумок вищесказаного, можна виділити основні вимоги замовників до програмного забезпечення для мобільних клієнтів інформаційної системи:
- Можливість отримання даних, співробітниками поза межами офісу фірми.
- Можливість внесення мобільним клієнтом змін до дані, які потім повинні бути синхронізовані з центральною БД.
- Можливість роботи мобільного клієнта при відсутності постійного каналу зв'язку з офісом.
- Простота установки, настройки і експлуатації створених додатків.
Технічні проблеми та варіанти реалізації
При реалізації вищеописаних вимог замовників виникають наступні технічні проблеми:
- Забезпечення зберігання отриманої користувачем інформації в перервах між сеансами зв'язку з центральним офісом з можливістю продовження роботи мобільного користувача. Іншими словами користувач не повинен помічати відмінностей в роботі додатка в режимах on-line та off-line.
- Синхронізація зроблених дій користувачів в системі з центральною базою. Оскільки час між редагуванням запису мобільним користувачем і внесенням її в центральну базу може становити дні, тижні і навіть місяці застосування звичайного для моделі клієнт-сервер механізму блокувань записів не має сенсу. При цьому кілька мобільних користувачів можуть одночасно редагувати кожен свою копію даних з сервера, тоді при спробі синхронізації даних неминуче виникнення конфліктів змін внесених в одну і ту ж запис різними користувачами. Дані конфлікти - це конфлікти синхронізації. Забезпечення засобів вирішення конфліктів сінхронізаціі- це одне з головних вимог до технічної реалізації такого ПЗ.
Далі ми коротко розглянемо найбільш часто застосовуються варіанти рішення задачі доступу мобільних користувачів до центральної бази даних.
Використання Internet і Web
Web спочатку проектувалася як територіально розподілена мережа, що дозволяє здійснювати доступ до різних інформаційних ресурсів в режимі on-line. Основним недоліком даного підходу є необхідність бути весь час підключеним до мережі. Даний недолік практично не дозволяє застосовувати даний підхід для роботи мобільних користувачів.
Реплікація баз даних
Реплікація - це процес синхронізації даних між декількома серверами БД. При застосуванні даного способу роботи архітектура системи виглядає наступним чином:
Більшість сучасних серверів БД мають вбудовані засоби для підтримки реплікації, що дозволяють обмінюватися даними між декількома серверами. Клієнтську програму при цьому не вимагає особливих модифікацій. Головним недоліком такого методу є необхідність установки і обслуговування сервера БД на машині клієнта.
Модель роботи briefcase
Briefcase модель має на увазі роботу клієнта з базою даних без підтримки постійного з'єднання. Клієнт підключається до БД, завантажує необхідні дані, передає зроблені ним зміни, і тут же відключається. У Delphi дана модель може бути реалізована з використанням можливостей ADO або MIDAS.
При створенні програми, що реалізує модель briefcase можна виділити кілька підзадач:
- Отримання даних з центрального сервера;
- Збереження даних в локальний кеш;
- Завантаження даних з локального кеша;
- Синхронізація даних з центральним сервером і обробка помилок синхронізації.
Для наших прикладів як сервер БД я використовував MS SQL сервер. На ньому була створена база даних ParamsHolder, що містить усього одну таблицю Params з наступними полями:
Каркас головної форми додатка наведено на малюнку. Я не буду детально описувати каркас, при необхідності Ви можете звернутися до прикладеним прикладів.
Відзначимо лише, що компонент підключення до сервера названий ParamConns, а компонент доступу до даних ParamsCS. Зосередимося на реалізації перерахованих вище підзадач створення додатку briefcase. Всі перераховані підзадачі реалізовані за допомогою Action-нов.
Реалізація моделі briefcase засобами ADO
Оскільки компоненти доступу до даних через ADO мають можливість зберігати і завантажувати дані в / з файл, вони придатні для розробки додатків briefcase.
Отримання даних з центрального сервера
Код для реалізації отримання даних з центрального сервера, для подальшого обговорення рядка коду пронумеровані:
Завдання даного коду підключитися до центрального серверу, отримати дані і зберегти їх в локальний кеш для подальшого використання.
Блок try ... finally (рядки 1, 12-15) дозволяє нам незалежно від успішності підключення до сервера відключитися від нього і відобразити користувачеві дані з локального кеша. Код для безпосередньо підключення до сервера і завантаження даних міститься в рядках 2-10. Блок try except забезпечує обробку помилок отримання даних з сервера. При виникненні помилки користувачу відображається повідомлення про неможливість підключення. Код, безпосередньо реалізує отримання даних, це рядки 5-9. У цих рядках ми налаштовуємо компонент класу TADODataset (ParamsCS) на роботу з сервером і відкриваємо. Ви запитаєте: навіщо це робити кожен раз. Робити це потрібно тому, що при відкритті локального кешу (за допомогою методу TADODataset.LoadFromFile) датасета сам перебудовує свої властивості CommandType і CommandText. Метод LoadFromFile викликається всередині акції act_ConnectLocal. Після отримання з сервера ми зберігаємо вибірку в локальний кеш, викликавши відповідний Action (рядок 11).
Збереження даних в локальний кеш
Для забезпечення можливості роботи з даними без постійного підключення до сервера (і постійно завантаженої програми) необхідно зберігати отримані дані і зроблені користувачем зміни. Компоненти ADO (Спадкоємці TCustomADODataset) мають можливість зберігати вибірку даних в файл, використовуючи метод SaveToFile. Метод має два параметри. Перший - ім'я файлу, другий формат збереження даних. Підтримуються два формати збереження даних:
- XML
- ADTG (Advanced Data Tablegram)
За замовчуванням збереження відбувається у форматі ADTG, хоча особисто я віддаю перевагу збереження в форматі XML, так як він більш зручний для сприйняття даних людиною.
ПРИМІТКА
Якщо ім'я файлу має розширення XML, дані зберігаються у форматі XML, ігноруючи другий параметр методу SaveFile.
Код збереження даних в локальний кеш складається з лише виклику методу ParamsCS.SaveFile.
Завантаження даних з локального кеша
Для завантаження даних з файлу спадкоємці TCustomADODataSet мають метод LoadFromFile. Перед завантаженням з файлу властивість Connection у ParamsCS необхідно встановити в nil, так як в ході завантаження здійснюється спроба підключитися до сервера БД. Код представлений нижче:
ПРИМІТКА
Виклик LoadFromFile автоматично змінює тип команди датасета (св-во CommandType) на cmdFile і в властивість CommandText зберігає ім'я файлу, звідки була проведена завантаження.
Синхронізація даних з сервером
Синхронізація включає в себе передачу зроблених користувачем змін та отримання з сервера оновлених (оновлення від всіх користувачів) даних. Отримання даних з сервера ми вже розглянули і тут зупинимося на проблемі передачі змін в центральну базу. Завдання передачі змін може бути розділена на дві непосредсвтенно передачу і обробку помилок синхронізації.
Передача змін здійснюється викликом методу UpdateBatch. Як ми вже говорили, причиною помилок синхронізації є одночасне редагування одного запису декількома користувачами. За замовчуванням запис на сервері відшукується за ключовими полю і полях, в яких користувач зробив зміни. При цьому якщо інший користувач встиг зробити в тих же полях цього запису зміни і внести їх в базу, запис не може бути виявлена. Виникає помилка синхронізації. Алгоритм пошуку записи контролюється властивістю Update Criteria об'єкта ADO RecordSet. Update Criteria може приймати наступні значення:
Пошук по сукупності всіх стовпців. Найбільш «жорсткий» режим.
Пошук тільки по ключових полях. Найбільш «м'який» режим. Конфлікт виникає лише при видаленні запису з бази.
Якщо в таблиці є поле типу TimeStamp для синхронізації буде використано воно
Пошук по сукупності ключових полів і полів, що містять зміни даних
При виявленні помилок синхронізації генерується виняткова ситуація класу EOleError c повідомленням про неможливість зберегти зміни. Обробка помилок синхронізації підтримується в ADO, починаючи з версії 2.7. При цьому алгоритм вирішення конфліктів, наведений в MSDN, наступний:
Властивість Filter об'єкта Recordset ADO встановити рівним adFilterConflictingRecords. При цьому будуть відображені тільки конфліктні запису.
Викликати метод Resync того ж об'єкта з параметром AffectRecords рівним adAffectGroup, параметр ResyncValues рівним adResyncUnderlyingValues. при цьому будуть отримані оновлені дані про стан конфліктних записів з сервера. Актуальні значення полів записів рекордсета зберігаються у властивості UnderlyingValue об'єкта Field, початкові в OriginalValue, а змінені користувачем в Value.
Відобразивши користувачеві набір конфліктних записів і значення їх полів ми даємо йому можливість відредагувати конфліктні запису і усунути конфлікти.
Записати в БД зміни користувача можна викликавши UpdateBatch з параметром adAffectGroup.
Обробку помилок я виніс в окремий модуль ADOReconcileError. У ньому визначено процедуру HandleADOReconcileError, що відповідає за підтримку обробки помилок синхронізації. Сам же код синхронізації виглядає так:
Скасування внесених змін
Ще однією особливістю використання ADO є можливість користувачеві скасування зроблених ним змін. Дана можливість реалізується методом CancelBatch. При виклику c параметром arAll (параметр за замовчуванням) скасовуються всі зроблені зміни. Коли Ви телефонуєте з параметром arCurrent будуть скасовані зміни, внесені до поточного запису датасета.
В наступній частині статті буде розглянута реалізації моделі briefcase за допомогою засобів MIDAS.