Бизнес изисквания за работа на мобилните потребители
за автоматизация на бизнес дейността, Изпълнение на информационните системи изисква база данни на разработчиците прилагане на всички нови функции в приложенията, те се развиват. Създаване на софтуер, който позволява на потребителите да работят само в офиса, не е достатъчно за днес. персонала на Службата е длъжен да предостави достъп до информация колекции на компанията в командировка извън къщата, от офиса на клиента. В този случай, потребителите не просто искат да видите данните, но и да могат да ги променят. Важно изискване от страна на администраторите на информационни системи, е лекотата на инсталиране и конфигуриране на клиентски приложения.
Обобщавайки по-горе, че е възможно да се разпределят на основните изисквания на клиентите за софтуер за мобилен информация за клиентите на системата:
- Възможността за получаване на данни, служители извън офиса на фирмата.
- Възможността за извършване на промени в данните за мобилни клиенти, които след това трябва да бъдат синхронизирани с централната база данни.
- Възможност за работа в отсъствието на клиента постоянна връзка с мобилен офис.
- Лесен за инсталиране, настройка и експлоатация на приложения, създадени.
Технически проблеми и изпълнения
При изпълнението на описаните по-горе изисквания на клиентите повдига следните технически проблеми:
- Съхраняване на информация за потребителя, получена в между комуникационни сесии с централния офис с възможност да се продължи работата на мобилния потребител. С други думи, потребителят не трябва да забележите разликата в заявлението в он-лайн и оф-лайн режим.
- Синхронизация с централните промените в базата данни, направени от потребителя. Тъй като времето между редактирате запис на мобилния потребител и като го превърне в централна база данни може да бъде дни, седмици или дори месеци за използването на конвенционален модел клиент-сървър записва заключващия механизъм няма смисъл. В този случай, някои мобилни потребители могат едновременно да редактирате всеки копие на данните от сървъра, а след това, когато се опитате да синхронизирате данните непременно ще бъде конфликт на промените, направени в същия запис различните потребители. Тези конфликти - конфликти е синхронизация. За да се осигури средство за разрешаване на конфликти sinhronizatsii- е едно от основните изисквания за техническото изпълнение на такъв софтуер.
На следващо място, ние ще прегледаме накратко най-често използваните варианти за разрешаване на проблема с достъпа до мобилните потребители на централна база данни.
Използването на интернет и уеб
Уеб първоначално е бил замислен като географски разпределени мрежа, което позволява достъп до различни информационни ресурси в он-лайн режим. Основният недостатък на този подход е необходимостта винаги да сте свързани към мрежата. Този недостатък е практически не позволява да се прилага този подход за мобилни потребители.
Пресъздаване на бази данни
Репликация - процес на синхронизация на данни между множество сървъри за бази данни. При прилагането на този метод, архитектурата на системата е както следва:
Повечето модерни сървъри на бази данни имат вградена поддръжка за репликация, ви позволява да споделяте данни между няколко сървъра. Клиентът в този случай не се нуждае от специални модификации. Основният недостатък на този метод е необходимостта от изграждането и поддържането на сървъра на базата данни на клиентската машина.
модел на работа куфарче
Куфарче модел включва работата на клиента с базата данни, без подкрепата на постоянна връзка. Клиентът се свързва с базата данни, файлове за изтегляне на необходимите данни, доклади промените, направени в тях, а след това се изключва. В Делфи, моделът може да се осъществява чрез използване на ADO или MIDAS възможности.
При създаване на приложение, което прилага модела куфарче има няколко подзадачи:
- Получаване на данни от централния сървър;
- Съхраняване на данни в локален кеш;
- Зареждане на данни от локалния кеш;
- Синхронизация с централния сървър и грешки обработка времето.
За нашия пример като сървър на база данни, аз използвах MS SQL сървър. Тя ParamsHolder база данни, съдържаща само една маса Params е създаден със следните полета:
Основната форма на рамката на заявлението е показано на фигурата. Няма да описвам подробно рамката, можете да, ако е необходимо, направете справка с приложения пример.
Трябва да отбележим само, че връзката към сървъра компонент име ParamConns и данни ParamsCS достъп на отделните компоненти. Ние се фокусираме върху изпълнението на посоченото по-горе се създаде Подцели куфарче приложения. Всички тези подзадачи, прилагани от действие нов.
Прилагане на модела чрез ADO куфарче
Тъй като компоненти за достъп до данни чрез ADO имат способността да се спаси и натоварване на данни към / от файл, те могат да бъдат използвани за разработване на приложения куфарче.
Получаване на данни от централния сървър
Код за прилагане на придобиване на данни от централен сървър, за по-нататъшно обсъждане на редове код, са преброени:
Целта на този код, за да се свържете с централен сървър, да получава данни и да ги съхранявате в локален кеш за бъдеща употреба.
опитайте блок ... най-накрая (линия 1, 12-15) ни позволява, независимо от успеха на връзката към сървъра е изключен от него и да се покаже потребителски данни от локалния кеш. Код, за да се свържете директно към сървъра и изтегляне на данните, съдържащи се в редове 2-10. Блок опитайте с изключение предвижда обработка на грешки, получаване на данни от сървъра. Когато възникне грешка, потребителят се показва съобщение за невъзможността на връзката. Кодът се изпълнява получаването на данни, тя е 5-9 линии. В тези редове ние се създаде компонент клас TADODataset на (ParamsCS) да работи със сървъра и открито. Може да попитате: защо го правя всеки път. Това трябва да се направи така, че при отваряне на локалния кеш (с помощта на метод TADODataset.LoadFromFile) набор от данни се е преструктуриране на неговите свойства CommandType и CommandText. метод LoadFromFile се нарича в рамките act_ConnectLocal за действие. пазим пробата в локален кеш, което води до съответното действие (линия 11), след като получи от сървъра.
Съхраняване на данни в локален кеш
За да може да се работи с данни, без постоянна връзка със сървъра (и постоянно заредена програмата) е необходимо да се запазят данните и промените на потребителите. ADO компоненти (Наследници TCustomADODataset) имат способността да спаси извадковите данни към файл се използва метод SaveToFile. Методът взима два параметъра. името на файла, втори формат за съхранение на данни - първият. Той поддържа два формата на съхранение на данни:
- XML
- ADTG (Advanced Data Tablegram)
пестене на неизпълнение, ADTG формат, въпреки че лично аз предпочитам да запазите в XML формат, тъй като тя е по-удобен за човек възприятие на данни.
ЗАБЕЛЕЖКА
Ако разширението на файла е XML, данните се съхраняват в XML формат, игнорирайки втори параметър на метода SaveFile.
Код, за да запазите данните в локален кеш се състои от метод на разговор ParamsCS.SaveFile.
Зареждане на данни от локалния кеш
За да изтеглите данните от файла TCustomADODataSet наследници имат метод LoadFromFile. Преди изтегляне на файл от ParamsCS връзка трябва да се настрои до нула, тъй като по време на зареждане е опит да се свърже със сървъра на база данни. Кодът е, както следва:
ЗАБЕЛЕЖКА
Обадете LoadFromFile набор от данни, автоматично се променя вида на команда (в Saint-CommandType) на cmdFile и CommandText имот запазва името на файла, където можете обувка.
Синхронизиране на данни със сървъра
Синхронизация включва предаване и приемане на промени в актуализацията на сървъра (от всички потребители), данните, направени от потребителя. Първи данни от сървъра, вече разгледахме тук ще се фокусира върху промените в проблема с предаване в централната база данни. предаване задача промяна може да бъде разделена на две neposredsvtenno прехвърляне и обработка на грешки синхронизация.
Трансфер направените промени, като се обадите UpdateBatch. Както казахме, причината за грешки синхронизация е едновременно редактиране на записи от няколко потребители. акаунт по подразбиране на сървъра се търси ключ поле и областите, в които потребителят направени промяната. В този случай, ако друг потребител е успял да направи в същите области, които записват промените и да ги включи в базата данни, записът не може да бъде намерен. Има грешка на времето. запис алгоритъм за търсене се контролира от имота Актуализация Критерии възразят АДО Recordset. Актуализация Критерии могат да вземат следните стойности:
Търсене на съвкупността от всички колони. Най- "твърд" режим.
Търсене само по ключови области. Най- "лек" режим. Конфликт възниква само когато изтриване на записи от база данни.
Ако таблицата има поле тип TimeStamp да синхронизирате тя ще бъде използвана
Търсене обобщени ключовите области и полета, съдържащи информация промени
В случай на откриване на грешки синхронизация генерирани изключителна ситуация в EOleError клас съобщение за невъзможността за да запазите промените. Синхронизация обработка на грешки се поддържа в АДО, започвайки с версия 2.7. В този случай, алгоритъмът на разрешаване на конфликти, като се има в MSDN, както следва:
Филтър собственост на обекта Recordset АДО настроен да adFilterConflictingRecords. Това ще покаже само противоречиви записи.
Обадете се на метода Повторно синхронизиране на един и същ обект с adAffectGroup на параметрите равни AffectRecords, настройка ResyncValues равни adResyncUnderlyingValues. Това ще получите данните за обновление за състоянието на записите в конфликт от сървъра. Действителните стойности rekordseta полета рекордни се съхраняват в имота UnderlyingValue възрази поле, като се започне в OriginalValue и променени от потребителя на стойността.
Показани на потребителя набор от противоречиви записи и ценностите на своята област, ние му даваме възможност да редактирате конфликта запис и разрешаване на конфликти.
Напиши за промяна на потребителското база данни, можете да се обадите UpdateBatch с параметър adAffectGroup.
обработка на грешки, аз направих отделна ADOReconcileError модул. Той определя процедура HandleADOReconcileError, е отговорен за поддържане на обработката на грешки синхронизация. кода за синхронизация самата изглежда така:
Отказ на промените
Друга особеност е възможността за използване на АДО потребител, за да отмените промените, направени в тях. Тази функция се изпълнява от CancelBatch. Когато се обадите на параметъра в arAll (настройката по подразбиране), за да отмените всички промени. Когато е извикан с опция arCurrent ще отмените промените, направени в текущия запис на набор от данни.
В следващия раздел ще разгледа изпълнението на модел куфарче с помощта на MIDAS фондове.
Свързани статии