Cerințe de afaceri pentru utilizatorii mobili
Introducerea sistemelor informatice pentru automatizarea afacerii necesită ca dezvoltatorii de baze de date să implementeze noi oportunități în aplicațiile pe care le dezvoltă. Crearea de software care să permită utilizatorilor să lucreze numai în cadrul biroului, până în prezent, este în mod evident insuficientă. Angajații biroului sunt obligați să furnizeze accesul la rețelele de informații ale companiei în cadrul unei călătorii de afaceri, de la domiciliu, la biroul clientului. În acest caz, utilizatorii doresc să vizualizeze nu numai date ci și să le poată modifica. O cerință importantă din partea administratorilor de sisteme informatice este ușurința de instalare și configurare a aplicațiilor client.
Rezumând cele de mai sus, putem identifica principalele cerințe ale clienților pentru software pentru clienții mobili ai sistemului informatic:
- Abilitatea de a obține date de către angajații din afara biroului companiei.
- Posibilitatea ca clientul mobil să efectueze modificări ale datelor, care apoi trebuie sincronizate cu baza de date centrală.
- Posibilitatea unui client mobil în absența unui canal permanent de comunicare cu biroul.
- Instalare, configurare și operare ușoară a aplicațiilor create.
Probleme tehnice și opțiuni de implementare
În implementarea cerințelor descrise mai sus ale clienților apar următoarele probleme tehnice:
- Asigurarea stocării informațiilor primite de utilizator între sesiuni la sediul central cu posibilitatea continuării activității utilizatorului mobil. Cu alte cuvinte, utilizatorul nu trebuie să observe diferențe în funcționarea aplicației în modurile on-line și off-line.
- Sincronizarea modificărilor efectuate de utilizator cu baza de date centrală. Deoarece timpul dintre editarea unei înregistrări de către un utilizator mobil și adăugarea acestuia în baza de date centrală poate fi zile, săptămâni sau chiar luni, aplicarea mecanismului obișnuit de blocare pentru modelul client-server nu are sens. În acest caz, mai mulți utilizatori de dispozitive mobile pot edita simultan fiecare copie a datelor de pe server, iar atunci când încercați să sincronizați datele, este inevitabil un conflict de modificări făcute în aceeași înregistrare de către diferiți utilizatori. Aceste conflicte sunt conflicte de sincronizare. Asigurarea mijloacelor de rezolvare a conflictelor de sincronizare este una dintre principalele cerințe pentru implementarea tehnică a unui astfel de software.
Apoi, analizăm pe scurt soluțiile cele mai frecvent utilizate la problema accesului utilizatorilor de telefonie mobilă la o bază de date centrală.
Utilizarea Internetului și a Web-ului
Webul a fost inițial conceput ca o rețea distribuită teritorial, care permite accesul la diverse resurse de informații în modul on-line. Principalul dezavantaj al acestei abordări este necesitatea conectării continue la rețea. Acest dezavantaj practic nu permite aplicarea acestei abordări pentru activitatea utilizatorilor de telefonie mobilă.
Replicarea bazei de date
Replicarea este procesul de sincronizare a datelor între mai multe servere de baze de date. Când se utilizează această metodă de funcționare, arhitectura sistemului arată astfel:
Majoritatea serverelor de baze de date moderne au instrumente integrate pentru a sprijini replicarea, permițându-vă să faceți schimb de date între mai multe servere. Aplicația client nu necesită modificări speciale. Principalul dezavantaj al acestei metode este nevoia de a instala și de a menține serverul de baze de date pe mașina client.
Modelul lucrării de servieta
Modelul de servietă înseamnă munca unui client cu o bază de date fără suportul unei conexiuni permanente. Clientul se conectează la baza de date, prelucrează datele solicitate, transmite modificările efectuate și apoi se deconectează. În Delphi, acest model poate fi implementat utilizând capabilitățile ADO sau MIDAS.
Când creați o aplicație care implementează modelul de servieta, puteți selecta mai multe sub-sarcini:
- Primirea datelor de la serverul central;
- Salvați datele în memoria cache locală;
- Încărcarea datelor din memoria cache locală;
- Sincronizați datele cu serverul central și gestionați erorile de sincronizare.
Pentru exemplele noastre, ca server de baze de date, am folosit MS SQL Server. A creat baza de date ParamsHolder care conține doar un tabel Params cu următoarele câmpuri:
Schema formei principale a aplicației este prezentată în figură. Nu voi descrie în detaliu cadrul, dacă este necesar, vă puteți referi la exemplele atașate.
Rețineți numai că componenta de conectare la server este denumită ParamConns, iar componenta de acces la date este ParamsCS. Ne vom concentra pe implementarea sub-tastelor de mai sus pentru crearea aplicației pentru servieta. Toate sub-tastele de mai sus sunt implementate folosind Action-new.
Implementarea modelului de servieta cu ADO
Dat fiind că componentele de acces la date prin intermediul ADO au capacitatea de a salva și de a încărca date în / din fișier, ele sunt potrivite pentru dezvoltarea aplicațiilor pentru serviete.
Primirea datelor de la un server central
Codul de implementare a prelucrării de date de la serverul central, pentru discutarea ulterioară a liniei de cod, este numerotat:
Sarcina acestui cod este conectarea la serverul central, obținerea datelor și salvarea acestuia în cache-ul local pentru utilizare ulterioară.
Încercarea ... în cele din urmă blocați (linii 1, 12-15) ne permite să ne deconectăm de la acesta, indiferent de succesul conexiunii la server și să afișăm datele din cache-ul local către utilizator. Codul pentru conectarea directă la server și încărcarea datelor este conținut în liniile 2-10. Încercarea cu excepția blocului asigură gestionarea erorilor de recuperare a datelor de la server. Dacă apare o eroare, utilizatorul primește mesajul că conexiunea nu poate fi efectuată. Codul care implementează în mod direct achiziția de date este linii 5-9. În aceste linii, configurați componenta de clasă TADODataset (ParamsCS) pentru a lucra cu serverul și a o deschide. Voi întrebați: de ce faceți asta de fiecare dată. Trebuie să faceți acest lucru deoarece, atunci când deschideți o memorie cache locală (utilizând metoda TADODataset.LoadFromFile), setul de date își reconstruiește propriile proprietăți CommandType și CommandText. Metoda LoadFromFile este numită în acțiunea act_ConnectLocal. După primirea de la server, salvăm selecția în cache-ul local chemând acțiunea corespunzătoare (linia 11).
Se salvează datele în memoria cache locală
Pentru a asigura capacitatea de a lucra cu date fără o conexiune permanentă la server (și un program încărcat în mod constant), este necesar să salvați datele primite și modificările efectuate de utilizator. Componentele ADO (moștenitorii TCustomADODaset) pot salva selectarea datelor într-un fișier utilizând metoda SaveToFile. Metoda are doi parametri. Primul este numele fișierului, al doilea este formatul pentru salvarea datelor. Se acceptă două formate de stocare a datelor:
- XML
- ADTG (tabel de date avansate)
În mod implicit, salvarea are loc în format ADTG, deși personal prefer să salvez în format XML, deoarece este mai convenabil pentru percepția datelor umane.
NOTĂ
Dacă numele fișierului are o extensie XML, datele sunt salvate în format XML, ignorând al doilea parametru al metodei SaveFile.
Codul pentru salvarea datelor în cache-ul local constă în apelarea numai a metodei ParamsCS.SaveFile.
Încărcarea datelor din memoria cache locală
Pentru a încărca datele din fișier, moștenitorii TCustomADODataSet au metoda LoadFromFile. Înainte de a descărca din fișier, proprietatea Connection a ParamsCS trebuie să fie setată la zero, deoarece în timpul descărcării se face o încercare de conectare la serverul de baze de date. Codul este prezentat mai jos:
NOTĂ
Apelul la LoadFromFile schimbă automat tipul comenzii setului de date (sv-in CommandType) în cmdFile și în proprietatea CommandText salvează numele fișierului din care sa făcut descărcarea.
Sincronizarea datelor cu serverul
Sincronizarea include transmiterea modificărilor efectuate de utilizator și primirea de la server a datelor actualizate (actualizate de toți utilizatorii). Am luat deja în considerare primirea datelor de la server și aici ne vom ocupa de problema transferului de modificări în baza de date centrală. Sarcina transferării modificărilor poate fi împărțită în două erori de sincronizare direct de trimitere și procesare.
Transmiterea modificărilor se face apelând metoda UpdateBatch. Așa cum am spus deja, cauza erorilor de sincronizare este editarea simultană a unei înregistrări de către mai mulți utilizatori. În mod implicit, intrarea serverului este căutată pentru câmpurile și câmpurile cheie în care utilizatorul a efectuat modificările. În acest caz, dacă un alt utilizator a reușit să facă modificări în aceleași câmpuri ale acestei înregistrări și să le facă în baza de date, înregistrarea nu poate fi detectată. Există o eroare de sincronizare. Algoritmul de căutare este controlat de proprietatea Criterii de actualizare a obiectului ADO RecordSet. Criteriile de actualizare pot lua următoarele valori:
Căutați după totalitatea tuturor coloanelor. Modul cel mai "greu".
Căutați numai câmpurile cheie. Modul cel mai "moale". Conflictul apare numai atunci când înregistrarea este ștearsă din baza de date.
Dacă tabelul are un câmp tip TimeStamp pentru sincronizare, acesta va fi utilizat
Căutați un set de câmpuri și câmpuri cheie care conțin modificări de date
Dacă sunt detectate erori de sincronizare, se face o excepție la clasa EOleError cu mesajul că nu este posibilă salvarea modificărilor. Manipularea erorilor de sincronizare este acceptată în ADO, începând cu versiunea 2.7. În acest caz, algoritmul de rezolvare a conflictului dat în MSDN este după cum urmează:
Proprietatea Filtru a obiectului ADO Recordset trebuie setată la adFilterConflictingRecords. Numai intrările în conflict vor fi afișate.
Apelați metoda Resync a aceluiași obiect cu parametrul AffectRecords setat la adAffectGroup, parametrul ResyncValues este adResyncUnderlyingValues. vor fi primite informații actualizate despre starea înregistrărilor conflictuale de la server. Valorile reale ale câmpurilor înregistrărilor înregistrării sunt stocate în proprietatea UnderlyingValue a obiectului Field, inițial în OriginalValue, dar modificate de utilizator în Value.
Prin afișarea către utilizator a unui set de înregistrări conflictuale și a valorilor câmpurilor, îi oferim posibilitatea de a edita înregistrări conflictuale și de a rezolva conflicte.
Puteți scrie modificările utilizatorului în baza de date apelând UpdateBatch cu parametrul adAffectGroup.
Procesarea erorilor pe care le-am făcut într-un modul separat ADOReconcileError. Acesta definește procedura HandleADOReconcileError, care este responsabilă pentru sprijinirea procesării erorilor de sincronizare. Codul de sincronizare în sine arată astfel:
Anulați modificările
O altă caracteristică a utilizării ADO este abilitatea utilizatorului de a anula modificările pe care le-a făcut. Această opțiune este implementată prin metoda CancelBatch. Când apelați c cu parametrul arAll (setarea implicită), toate modificările sunt anulate. Când apelați cu parametrul arCurrent, modificările aduse intrării din setul de date actuale vor fi anulate.
În următoarea parte a articolului, va fi luată în considerare implementarea modelului de servieta cu instrumente MIDAS.