Tehnologii de birou Lotus Notes  Ce este Notes Ce este NotesCe este Notes  Lotus Notes ca o combinație de opt tehnologii cheie Lotus Notes. Notificare de sosire a noilor e-mailuri

În mod implicit, Domino replică toate bazele de date care au același ID de replica. Pentru a replica numai anumite baze de date, editați câmpul Fișier/Directoare de replicat din documentul de conexiune. În acest câmp, introduceți numele bazelor de date sau ale directorului pe care doriți să le replicați. Separați-le unul de celălalt cu punct și virgulă.

Pentru a identifica baza de date selectată pentru replicare, introduceți numele fișierului acesteia, inclusiv extensia .NSF. Dacă baza de date se află într-un subdirector, includeți calea relativă la directorul de date Notes - de exemplu, EAST\SALES.NSF.

Pentru a identifica toate fișierele aflate într-un director, introduceți EAST\. Nu puteți utiliza asterisc (*) în acest scop.

Replicați bazele de date în funcție de prioritățile lor.

Managerii bazelor de date atribuie prioritate de replicare bazelor de date, astfel încât administratorii Domino să poată programa replicări pentru baze de date pe baza priorității. De exemplu, puteți prioritiza bazele de date care sunt critice pentru afaceri - de exemplu, Directorul Domino este replicat frecvent. De asemenea, puteți viza baze de date cu prioritate scăzută.

Setările de replicare folosind prioritate sunt editate în câmpul Replica bazele de date din documentul de conexiune. Setarea implicită este Prioritate scăzută, medie și mare.

Dacă două replici au priorități diferite, Domino utilizează prioritatea atribuită replicilor de pe serverul care inițiază replicarea.

Limită de timp de replicare.

Limitarea timpului de replicare previne sesiunile extinse de replicare și vă permite să gestionați costul replicărilor în zonele îndepărtate ale sistemului dumneavoastră. De exemplu, dacă replicările depind de o conexiune telefonică la distanță și baza de date necesită timp pentru a se replica, puteți limita durata replicilor.

Pentru a limita timpul de replici, introduceți o valoare în câmpul Replication Time Limit din documentul de conectare.

Avertizare Notă: Dacă specificați un timp foarte mic, bazele de date nu se vor putea replica complet. Fișierul LOG.NSF face o intrare care indică faptul că a avut loc o întrerupere a comunicării, dar replicarea nu a avut succes. Istoricul replicărilor nu este actualizat.

Pentru a limita în timp replicările pentru întregul server, editați fișierul NOTES.INI pentru a include variabila ReplicationTimeLimit.

Folosind mai multe replicatoare simultan

Dacă creați documente de conexiune care utilizează mai multe replicări de server simultan sau se suprapun replicări cu servere de destinație diferite, rulați mai multe replicatoare pentru a gestiona fiecare sesiune. Lansările multiple ale replicatorului utilizează eficient resursele serverului, reduc ciclurile de replicare, în special pe serverele Hub și economisesc timpul de replicare.

Când utilizați mai multe replicări, fiecare replicator gestionează o singură sesiune de replicare. De exemplu, dacă Hub-E/East/Acme este programat să se reproducă atât la HR-E/East/Acme, cât și la Hub-W/West/Acme în același timp, un replicator se ocupă de replicarea Hub-E/East/Acme și HR-E/Est/Acme, un alt replicator se ocupă de replica între Hub-E/East/Acme și Hub-W/West/Acme.

Replicatoarele multiple gestionează mai multe replici între un server sursă și mai multe servere destinație simultan.

Exemplu. Dacă Baza de date 1 și Baza de date 2 de pe Hub-E/East/Acme trebuie să se repete de la Hub-W/West/Acme, atunci doar un replicator vorbește cu fiecare sesiune de replicare, pe rând.

Examinați documentele de conexiune care prezintă replicările dvs. pe fiecare server. Prin ajustarea programelor de replicare și lansarea mai multor replicatoare, puteți reduce timpul unui ciclu complet de replicare. Cu această reducere a ciclurilor, puteți programa unul sau mai multe cicluri suplimentare pe zi, ceea ce înseamnă intervale de timp mai scurte pentru actualizarea datelor bazei de date, un ciclu de replicare mai rapid. După ce porniți mai multe replicatoare, puteți utiliza comanda -Tell pentru a opri toate replicatoarele; cu toate acestea, nu puteți utiliza comanda -Tell pentru a opri un anumit replicator.

Dacă nu utilizați mai multe replicatoare, nu programați replici de pe server folosind porturi diferite în același timp.

Exemplu. Dacă utilizați un replicator, nu programați o replică de la Hub-E/East/Acme la Hr-E/East/Acme pe COM1 în același timp cu de la Hub-E/East/Acme la Hub-W/west / Acme prin COM2 simultan.

Permiterea mai multor replicatoare.

Respingerea cererilor de replicare de la server.

Pentru a împiedica serverul să accepte cereri de replicare, editați fișierul NOTES.INI pentru a include variabila ServerNoReplRequests. Dacă această setare este setată la 1, serverul refuză toate cererile de replicare.

Puteți utiliza această caracteristică pentru a reduce volumul de lucru de replicare pe un server selectat.

Interzicerea replicărilor.

Pentru a dezactiva replicările - de exemplu, când testați replicările pe mai multe servere sau nu doriți ca unele baze de date să fie replicate - puteți dezactiva replicările.

Pentru a dezactiva replicarea, editați documentul de conexiune în Directorul Domino. În secțiunea Replicare, dezactivați utilizarea replicării, setați valoarea câmpului Replicare la Tasks – Disabled.

Forțarea replicărilor planificate.

Puteți replica modificările la bazele de date critice, cum ar fi Domino Directory, fără a aștepta replicarea programată. După ce creați documente de conexiune, puteți utiliza comanda consolei server pentru a forța replicarea imediată.

Există multe situații în care sunt necesare replicări forțate. De exemplu, este posibil să doriți să actualizați imediat baza de date, fără a aștepta replicarea programată, sau puteți replica date de la diferite servere, deoarece aceste servere sunt de obicei indisponibile.

Când forțați replicarea imediată de la server la server, puteți replica într-una sau ambele direcții.

Comenzi pentru replicator:

Replica- Modificările în bazele de date sunt replicate în ambele direcții. Domino introduce mai întâi modificările, apoi scoate documentele modificate.

Trage- Modificările în bazele de date sunt replicate într-o direcție, unde serverul preia doar modificările de la alt server

Apăsaţi- Modificările în bazele de date sunt replicate într-o singură direcție, unde serverul împinge doar modificările bazei de date către un alt server.

Joseph Anderson și Pete Burkhardt
Publicat 25.04.2007

Flexibilitatea și libertatea pe care le oferă replicarea reprezintă un beneficiu de neegalat al IBM Lotus Notes. Multe organizații au ales să profite din plin de această funcție puternică și să pună utilizatorii lor să execute replici locale ale bazelor lor de date Notes, inclusiv bazele lor de e-mail. Avantajele și dezavantajele utilizării bazelor de date locale de corespondență sunt discutate în detaliu în articolul developerWorks Lotus, „.”

Pe lângă punctele discutate în acest articol, Lotus Notes/Domino a adăugat caracteristici care pot face implementarea replicilor de corespondență locale și mai tentantă. Acest articol discută aceste îmbunătățiri suplimentare și oferă recomandări pentru configurarea replicilor de corespondență locale. Înainte de a explica modelul replica local și detaliile tehnice de organizare a mediului în cadrul infrastructurii dvs., să privim un exemplu de aplicabilitate a acestui model.

Exemplu de implementare a replicilor de corespondență locale

Fiecare mediu are cerințe unice și, prin urmare, este dificil să schițați un set de recomandări standard care se aplică tuturor organizațiilor. Următorul exemplu este destinat să vă ajute să stabiliți un plan de succes pentru implementarea replicilor de corespondență locale.

Compania XYZ a implementat în cele din urmă servere de e-mail Lotus Domino în fiecare locație nouă, deoarece aceasta era configurația implicită și pentru că majoritatea site-urilor cu mai puțin de 25 de utilizatori aveau comunicații cu lățime de bandă redusă. Majoritatea comunicării prin e-mail în cadrul unei companii au loc între aceste noduri și cerințele pentru utilizatori E-mail situate în același birou sunt minime. De-a lungul timpului, numărul de servere de e-mail Lotus Domino din afara site-ului central a crescut la 37, deservind aproximativ 1.400 de utilizatori, în timp ce biroul principal avea două servere de e-mail Lotus Domino grupate cu 2.900 de utilizatori. Departamentul financiar al companiei a ridicat și a luat în considerare problema numărului de servere și licențe necesare pentru funcționarea mediului de schimb. prin e-mail. Pentru a reduce numărul de servere și licențe necesare, menținând în același timp nivel inalt toleranță la erori și echilibrare a încărcăturii, departamentul de tehnologie informațională a decis să mute unii utilizatori la biroul central și să implementeze replici locale de e-mail.

Grupul IT a evaluat modelele actuale de utilizare a unor astfel de echipamente în companie, determinând amplasarea serverelor, numărul de utilizatori și numărul disponibil. debitului. Tabelul 1 definește următoarele categorii.

Tabelul 1. Evaluarea tiparelor curente de utilizare
Numărul de noduri din mediunumăr de utilizatoriLățimea de bandă disponibilăActivitati recomandate
11 Mai puțin de 25Transfer la biroul central
1 25 – 50 de utilizatoriMai puțin de 256 KBTransfer la biroul central (track)
7 25 – 50 de utilizatoriMai mult de 256 KBTransfer la biroul central
2 50 – 150 de utilizatoriMai puțin de 1 MBImplementați un cluster de servere
13 50 – 150 de utilizatoriMai mult de 1 MBTransfer la biroul central
3 Peste 150 de utilizatoriImplementați un cluster de servere

Pe baza rezultatelor evaluării, departamentul a decis să transfere 32 de noduri din biroul central pe două servere dintr-un cluster și să implementeze cinci servere suplimentare pe noduri care continuă să utilizeze servere în mediul lor. În același timp, numărul total de servere a fost redus de la 39 la 14, oferind un mediu extrem de fiabil, echilibrat de încărcare pentru toți utilizatorii.

Managementul superior IT a solicitat ca toți utilizatorii din mediu să folosească aceeași metodă de acces. Pentru a îndeplini această sarcină, echipa IT a dezvoltat și configurat politici de configurare și desktop pentru a automatiza procesul de implementare. Înainte de a fi luată decizia de a trece la replicile de e-mail locale, existau o politică pentru desktop și o politică de configurare în mediu. Pentru a se asigura că mediul nu a fost copleșit de cererile de replicare a datelor către utilizatorii finali, echipa IT a creat politici de configurare și desktop pentru fiecare locație, astfel încât echipele să poată controla procesul de replicare. După migrarea la replici de e-mail la nivel local, echipa IT a revenit la mai puține politici de configurare și desktop, implementând un set de politici pe server.

Odată ce mediul a fost migrat către replici locale de e-mail, echipa IT a redus numărul de servere. Reducerea numărului de servere și introducerea clusterelor au făcut posibilă menținerea serverelor fără timp de nefuncționare pentru utilizatori. În general, utilizatorii sunt mult mai mulțumiți de mediul de lucru.

Explicarea mecanismului local de replicare a bazei de date de corespondență

Destul de des auzim oameni care vorbesc despre corespondența locală, comparând-o cu e-mailul de pe server. Ce înseamnă asta cu adevărat? Replicarea bazei de date de corespondență locală presupune că o copie sau o copie a fișierului de e-mail al utilizatorului se află pe acesta stație de lucru, care permite utilizatorului să lucreze cu e-mail fără a se conecta la server. E-mailurile trimise sunt trimise periodic și fișierul de e-mail este replicat cu o versiune a acestuia pe server, schimbând modificări între cele două baze de date. O imagine a configurației mediului este prezentată în Figura 1.

Figura 1. Configurarea mediului local de replică de e-mail

Pentru a crea un astfel de mediu, trebuie să faceți unele setări în clientul Lotus Notes al utilizatorului.

Trebuie să creați o replică a bazei de date de e-mail a utilizatorului pe stația de lucru a utilizatorului. Este recomandat să folosiți un director de director pentru a permite utilizatorilor să caute nume atunci când adresează mesaje de e-mail în timpul munca locala. Atât dumneavoastră, cât și administratorul, și utilizatorul puteți crea replici locale manual de la stația de lucru a utilizatorului sau folosind politici Lotus Notes/Domino. După crearea replicii locale și a directorului de director, acestea trebuie configurate pentru a se sincroniza cu replicile bazei de date server. Vă recomandăm replicarea bazei de date la fiecare 30 de minute. Setând replicarea la 30 de minute, vă asigurați că clientul nu reduce performanța serverului sau a acesteia prin replicarea prea frecventă.

Lotus Notes de pe stația de lucru trebuie configurat astfel încât verificarea să aibă loc e-mail nou pe server. Setarea de verificare a e-mailurilor noi ar trebui să fie setată la fiecare cinci minute, permițând utilizatorului să primească e-mailuri la intervale mult mai scurte decât intervalul de replicare de 30 de minute. Acest lucru asigură că clientul menține o sesiune deschisă cu serverul Domino și este notificat în mod regulat când este primit un nou mesaj.

Clientul Lotus Notes al stației de lucru a utilizatorului trebuie, de asemenea, să trimită către replica locală a utilizatorului a fișierului e-mail al utilizatorului ca locație pentru e-mail. În plus, trebuie să faceți unele modificări în configurația clientului pentru a determina dacă directorul de director local este utilizat la adresarea mesajelor de e-mail. După ce a făcut aceste modificări, poate lucra cu replica sa locală, iar senzațiile vor fi aproape aceleași ca atunci când lucrează cu serverul.

Poate părea că dvs. sau utilizatorul va trebui să efectuați o cantitate destul de semnificativă de modificări de la stația de lucru a utilizatorului. Deși este posibilă configurarea manuală, puteți crea și politici în mediul dumneavoastră Lotus Notes/Domino care fac aceste modificări fără a fi nevoie să vizitați o stație de lucru separată. Deoarece politicile vă permit să reconfigurați un număr mare de stații de lucru în același timp, trebuie să vă asigurați că aceste modificări sunt implementate într-o manieră granulară, pentru a nu inunda rețeaua cu solicitări simultane de a crea replici sau fișiere și directoare de e-mail.

Îmbunătățiri în lucrul cu replicile de corespondență locale

Multe organizații preferă ca utilizatorii lor să lucreze cu replici de e-mail locale din mai multe motive. Cu toate acestea, există în mod tradițional câteva dezavantaje ale acestei configurații din perspectivă administrativă. Aceste deficiențe se referă la configurarea stației de lucru, instruirea utilizatorilor și furnizarea de servicii de director pentru utilizatori. Cu îmbunătățiri ale replicării, politicilor și directoarelor de directoare în ultimele versiuni Lotus Notes (V6.0 și versiuni ulterioare), replicile de corespondență locale au devenit chiar mai ușor de gestionat.

Comprimarea rețelei

Începând cu Lotus Notes 6.x, s-au făcut multe modificări la replicare care au crescut semnificativ eficiența atât în ​​ceea ce privește performanța, cât și utilizarea rețelei. Introducerea compresiei în timpul replicării reduce cantitatea de date transferată între client și server cu până la 30-40%, dacă traficul de rețea nu mai este comprimat de routere sau software VPN. Puteți citi mai multe despre compresia rețelei în articolul developerWorks Lotus, „.”

Replicare în flux

În plus, Lotus Notes V6.0 a introdus replicarea în flux. Această caracteristică îmbunătățește experiența utilizatorului atunci când lucrează cu o replică locală de e-mail. În timpul replicării, documentele noi sunt replicate în replica locală de e-mail, în ordinea dimensiunii de la cea mai mică la cea mai mare. Acest lucru elimină întârzierile care apar atunci când un mesaj cu un atașament mare se reproduce primul și blochează multe altele. În plus, replicarea în flux permite utilizatorilor să vizualizeze și să lucreze cu documente în timp ce acestea sunt replicate în baza de date locală de e-mail, astfel încât nu mai trebuie să aștepte ca toate modificările să fie replicate înainte de a putea începe să lucreze la mesaje noi.

Notificare asincronă

Începând cu Lotus Notes V6.5.x, a fost introdusă notificarea asincronă. Dacă clientul Notes rulează o replică locală de e-mail și are o conexiune deschisă la serverul Domino, acesta din urmă trimite clientului notificarea de mesaje noi. Această notificare trimisă de serverul Domino declanșează replicarea fișierelor de e-mail pe clientul Notes, livrând noul mesaj către replica locală de e-mail. Această replicare are loc fără intervenția utilizatorului și este independentă de programul de replicare stabilit în clientul Lotus Notes. Această funcție Permite utilizatorilor să primească imediat e-mailurile primite atunci când lucrează cu replici locale.

Politicienii

Au fost introduse politici pentru a ajuta la configurarea și gestionarea setărilor pe stația de lucru a unui utilizator. Această caracteristică puternică vă oferă o flexibilitate semnificativă atunci când configurați stațiile de lucru ale utilizatorului. Folosind politici, puteți face toate setările necesare pentru a vă asigura că un utilizator poate lucra cu o replică locală de e-mail fără a vizita stația de lucru a utilizatorului. Mai jos vă vom arăta cum să configurați politicile pentru a gestiona acest scenariu. Pentru informații mai detaliate și generale despre politici, consultați următoarele articole developerWorks Lotus, " " și " ."

directoare directoare

În timp ce replicarea și îmbunătățirile politicii sunt caracteristici foarte puternice, cheia implementării cu succes a replicilor de corespondență locale pentru utilizatori constă în crearea unui director de director. Puteți crea două tipuri de directoare de directoare.

  • Director comprimat sau mobil director
    Directorul directorului mobil conține intrări de utilizator și grup din directorul dvs. Domino și din alte directoare pe care le puteți selecta. Mobile Directory Catalog comprimă intrările din directoarele pe care le selectați într-o bază de date de catalog de directoare. Proporția implicită utilizată pentru comprimarea înregistrărilor este de aproximativ 255 de înregistrări (o înregistrare este egală cu o înregistrare de utilizator sau de grup) în Directorul Domino sunt comprimate într-o singură intrare în directorul directorului mobil. Ca urmare, dimensiunea catalogului de directoare este foarte mică, dar sortarea se poate face numai după nume sau prenume, care trebuie specificat la crearea catalogului de directoare.
  • Directorul de director extins
    Directorul de director extins se bazează pe intrările de utilizator, grup și server din Directorul Domino și alte directoare alese de dvs. Directorul Director Avansat nu oferă comprimare a intrărilor, rezultând că Directorul Director Avansat este mult mai mare ca dimensiune decât Directorul Directorului mobil. Cu toate acestea, directorul de director extins este mai mic decât Directorul Domino, deoarece nu conține documente de conexiune, documente de program etc. Este, de asemenea, foarte flexibil în ceea ce privește ușurința de utilizare a căutărilor, deoarece funcționează exact la fel ca atunci când se efectuează o căutare în directorul Domino obișnuit (adică, căutați după nume, prenume, porecla etc.)

Un factor cheie în satisfacția utilizatorilor atunci când lucrează cu replici de e-mail locale este asigurarea faptului că utilizatorii pot căuta nume într-un director atunci când lucrează offline. Atât listele de directoare mobile, cât și cele avansate au avantajele și dezavantajele lor. Deși directorul de director mobil este mai mic ca dimensiune, directorul de director extins oferă capabilități de căutare mai flexibile. Regula generală pentru alegerea directorului de director adecvat pentru mediul dumneavoastră ar trebui să se bazeze pe dimensiunea directorului de director. Dacă dimensiunea catalogului de directoare extins generat este mai mare de 50 MB, utilizați în schimb catalogul de directoare mobile. Când folosiți dimensiunea ca bază pentru alegerea între două tipuri de directoare de directoare, acesta ia în considerare timpul pe care utilizatorul îl va petrece replicând directorul director și ia în considerare creșterea viitoare a directorului.

Acum că am discutat despre elementele cheie ale unui mediu local de replica de e-mail, să vedem cum este creat și configurat unul.

Configurarea mediului

Este necesar să se efectueze multe setări și configurații pe stația de lucru a utilizatorului, astfel încât utilizatorii să poată lucra cu succes și confortabil cu replicile de e-mail locale atunci când folosesc e-mailul. Aceste setări se găsesc în documentul Preferințe utilizator și locație de pe stația de lucru a utilizatorului și sunt prezentate în Tabelul 2.

Tabelul 2. Prezentare generală a câmpurilor personalizate
Instalarea pe o stație de lucruSens
Crearea de replici localeFișier mail, director director
Setari personalizate
Director secvenţial (fila Mail\General)Numele bazei de date director director
Verificarea e-mailurilor noi la fiecare (fila Mail\General)5 minute
Actualizare automată a căsuței primite (fila Mail\General)Inclus
Crearea unui index full-text pentru căutare (fila Replicare)Inclus
Ar trebui Notes să cripteze noi replici? (fila Replicare)Criptare locală cu nivel mediu
Document de locație (fila E-mail)
Postarea unui fișier de e-mailLa nivel local
Introduceți înainte numele destinataruluiNumai local
Adresarea corespondențeiLocal și pe server
Transferul corespondenței trimise dacă1
Document de locație (fila Replicare)
Permite replicareaInclus
Crearea de noi repliciImediat
Replicare când pornește NotesActivat, solicitare de pre-replicare
ProgramaInclus
Replicare zilnică între7:00 AM – 7:00 PM
Repetați fiecare30 minute
Zilele săptămâniiLuni, Marți, Miercuri, Joi, Vineri
Replicări când Notele se terminăSugestie de replicare la închiderea Notes dacă ceva așteaptă să fie trimis.

Există două moduri de a efectua aceste setări pe stația de lucru a utilizatorului: manual sau folosind politici. Această secțiune a articolului discută procesul de configurare manuală a clientului. Următoarea secțiune discută despre configurarea acestor setări folosind politici Lotus Domino.

Crearea de replici locale

În mod implicit, la configurarea unui mediu Lotus Notes, nu este creată o replică locală a bazei de date de e-mail sau a directorului director, ceea ce este necesar pentru cea mai bună utilizare modele de replicare locală. Următoarele sarcini sunt specifice bazei de date de e-mail, dar este important să efectuați aceiași pași pentru directorul director.

NOTĂ:Înainte de a crea o replică locală a directorului director, creați mai întâi directorul director pe serverul Domino. Pentru mai multe informații despre crearea unui director de director, consultați .

Creați o nouă replică a bazei de date de e-mail selectând baza de date de e-mail de pe stația dvs. de lucru și selectând Fișier – Replicare – Replică nouă. Acceptați toate valorile implicite pentru noua replică și faceți clic pe OK pentru a confirma crearea noii replici pe stația de lucru locală (vezi Figura 2).

Figura 2. Caseta de dialog Creare replica

Configurarea criptării pentru o replică locală de e-mail

Pentru a asigura securitatea datelor, asigurați-vă că baza de date de e-mail este criptată local. Deschideți fereastra Proprietăți baze de date și faceți clic pe butonul Setări de criptare. În caseta de dialog Criptare, selectați opțiunea „Criptați local această bază de date folosind” și apoi selectați nivelul de criptare corespunzător din lista derulantă. Valoarea implicită este Criptare medie.

NOTĂ:În funcție de cerințele de securitate ale mediului, pot fi necesare diferite niveluri de criptare. Mediul Domino oferă trei diferite niveluri criptare. Mai mult informatii detaliate pentru nivelurile de criptare, consultați Lotus Domino Administrator Help.

Setari personalizate

Caseta de dialog Preferințe utilizator conține opțiuni de configurare a clientului. Pentru a deschide caseta de dialog, selectați Fișier – Preferințe – Preferințe utilizator. Pentru a vă asigura că e-mailurile noi apar la timp în replica locală a fișierului de e-mail, selectați fila Mail - General și efectuați următoarele setări (vezi Figura 3):

  • În secțiunea Configurare, introduceți sau navigați la numele fișierului directorului local în câmpul Agende locale.
  • În secțiunea Primire, selectați opțiunea „Verificați e-mailuri noi la fiecare” și apoi setați intervalul la cinci minute.
  • În secțiunea „Când sosește un mesaj nou”, selectați opțiunea Actualizare automată a căsuței primite.
Figura 3. Setări de e-mail în caseta de dialog Preferințe utilizator

Selectați fila Replicare și configurați setările implicite care se aplică atunci când creați replici noi (vezi Figura 4).

  • Selectați opțiunea „Creați index text complet pentru căutare” pentru a vă asigura că toate replicile noi sunt gata pentru căutare.
  • Selectați opțiunea Criptare locală folosind și apoi specificați nivelul de criptare adecvat. Acest lucru asigură că toate bazele de date replicate local sunt criptate în mod implicit, asigurând protecția datelor.
Figura 4. Setări de replicare din caseta de dialog Preferințe utilizator

Configurarea documentului de locație

În timpul procesului normal de instalare a clientului, clientul Notes este configurat să utilizeze baza de date de e-mail și informațiile despre director de pe server. Pentru a permite utilizatorului să lucreze cu o replică locală de e-mail, modificați documentul Locație din Agenda personală pentru a utiliza resursele stației de lucru locale, mai degrabă decât resursele serverului.

Deschideți documentul Locație, selectați fila Mail și setați următoarele valori (vezi Figura 5):

  • Locația fișierului de e-mail: local
  • Transferați mesajele e-mail trimise dacă: 1 (mesaje în așteptare) (mesaj în așteptare)
Figura 5. Configurarea opțiunilor de e-mail în documentul Locație

Următorul pas este să activați replicarea bazei de date de pe server. În fila Replicare a documentului Locație, setați următoarele valori:

Figura 6. Configurarea opțiunilor de replicare în documentul Locație

Configurarea politicilor serverului

În secțiunea anterioară a articolului, ați analizat cum să configurați manual replicile de corespondență locale pentru utilizatorii din mediul dumneavoastră. Aceste acțiuni pot fi automatizate prin implementarea politicilor Lotus Notes/Domino. Următoarele secțiuni oferă o privire de ansamblu asupra implementării politicilor necesare pentru a pregăti mediul pentru replicile de corespondență locale. Pentru o prezentare mai detaliată a politicilor Lotus Domino, consultați Ajutorul pentru administratorul Lotus Domino.

Există două tipuri de politici utilizate pentru a inițializa și a menține setările asociate cu replicile de e-mail locale. Politicile de configurare sunt aplicate clienților noi pe măsură ce sunt configurați și introduși în mediu. Este important să rețineți că politicile de configurare sunt aplicate numai atunci când clientul Notes este configurat pentru prima dată. Politicile desktop sunt aplicate clientului Notes de fiecare dată când clientul pornește și deschide o sesiune cu serverul Lotus Domino. Politica Desktop este foarte utilă pentru activarea setărilor de configurare pentru utilizatorii care au deja un client.

Crearea unei politici de configurare

Următorii pași vă vor ghida prin crearea unei politici de configurare, concentrându-vă pe elementele specifice replicilor de corespondență locale. Dacă aveți deja o politică de configurare configurată, o puteți modifica pentru a face modificările enumerate aici pentru a activa replicile de e-mail locale. După cum sa menționat mai devreme, politica de configurare se aplică numai noilor configurații. Trebuie să faceți aceste setări în politica Desktop pentru a vă asigura că sunt aplicate în mod continuu.

Deschideți Domino Directory și accesați vizualizarea Policies\Settings. Faceți clic pe butonul Adăugare setări și selectați Configurare pentru a crea o politică de configurare. În fila Noțiuni de bază a documentului Setări de configurare, selectați opțiunea „Creare local file file replica” (vezi Figura 7).

Figura 7. Configurarea opțiunilor de bază în politica Setup Settings

În fila Baze de date a documentului, adăugați un link către baza de date pentru catalogul de directoare în câmpul Mobile Directory Catalog. Apoi selectați fila Preferințe, iar în subfilele Mail și Știri, setați intervalul de verificare a noilor e-mailuri la cinci minute și selectați opțiunea Actualizare automată a căsuței de intrare.

În subfila Preferințe - Replicare, activați „Creați replici gata pentru căutare”, setați câmpul Criptare replici la Criptare locală și setați câmpul Criptare la nivelul de criptare dorit (Ridicat, Mediu, Scăzut). Vezi Figura 8.

Figura 8. Configurarea opțiunilor de replicare în politica de configurare

Creați și extindeți o politică pentru desktop

Cu doar funcționalitatea de bază furnizată cu politicile de configurare și desktop, nu puteți efectua personalizare completă Locația documentului. Modificarea setărilor tipului de e-mail, activarea replicării și gestionarea programului de replicare nu fac parte din opțiunile implicite din documentul de politică Desktop. Cu toate acestea, puteți configura un document de politică Desktop în Domino Directory pentru a obține controlul asupra tuturor setărilor din documentul Locație al unui utilizator. Această secțiune oferă informații despre configurarea unui document de politică pentru desktop și despre configurarea și gestionarea acestor setări.

Capacitatea de a configura formulare de politică pentru desktop pentru a controla setările Notes.ini și setările documentului Locație este descrisă în nota tehnică Lotus Support, "." Vă recomandăm să reduceți impactul configurării directorului prin crearea unui subformular separat pe care îl puteți introduce în formularul de politică pentru desktop.

Mai întâi de toate, deschideți Directorul Domino în IBM Lotus Domino Designer. Accesați secțiunea Cod partajat\Subforms a bazei de date și creați un nou subformular numit $ClientLocationDoc.

În acest subformular, creați un tabel cu două file: Mail și Replication. În fila Mail, recreați configurația filei Document prin poștă Locația în agenda personală. Cu toate acestea, asigurați-vă că adăugați LocAll la începutul numelui din fiecare câmp, așa cum se arată în Figura 9.


NOTĂ: Dacă copiați un tabel dintr-un document de locație într-o agendă personală de adrese, asigurați-vă că modificați numele câmpurilor în toate formulele de ascundere-când și de câmp (traducere implicită de intrare, validare de intrare etc.) pentru a accepta LocAll atașat la numele câmpurilor. De asemenea, asigurați-vă că eliminați câmpurile MailFile și MailFormat din tabelul copiat. Aceste câmpuri fie există deja undeva în documentul de politică, fie sunt specifice utilizatorului și nu ar trebui gestionate de politici.

După ce ați completat fila Mail a subformularului, mergeți la fila Replicare pentru a recrea configurația filei Replicare a documentului Locație din Agenda personală. Din nou, asigurați-vă că adăugați LocAll la începutul fiecărui nume de câmp, așa cum se arată în Figura 10.

Figura 10. Crearea unui nou subformular Replicare în Directorul Domino

NOTĂ: Recreați tabelul din documentul Locație din Agenda personală, dar nu copiați și lipiți tabelul deoarece majoritatea câmpurilor din documentul Locație sunt câmpuri publice. Prin crearea acestor câmpuri în subformular ca câmpuri individuale, puteți menține independența subformularului în viitor și puteți accepta modificările la toate formulele de ascundere când și câmpuri (traducere implicită de intrare, validare de intrare etc.), precum și adăugarea LocAll la toate nume de câmpuri fără a afecta alte câmpuri comune din Directorul Domino.

După completarea subformularului $ClientLocationDoc, salvați-l și închideți-l. Apoi deschideți formularul „Setări politici\Setări desktop”. În acest formular, introduceți o altă filă în tabelul principal între filele Baze de date și Conexiuni dial-up. Denumiți această filă nouă Locație Document și introduceți noul subformular în această filă (vezi Figura 11).

Figura 11. Adăugarea de noi subformulare la formularul Politică de setări desktop

NOTĂ: Faceți o copie a formularului „Setări politici\Setări desktop” înainte de a-l edita. În plus, dezactivați opțiunea de actualizare din șablonul de design Domino Directory, astfel încât modificările dvs. să nu fie suprascrise atunci când șablonul este înlocuit sau actualizat în timpul întreținerii obișnuite a directorului.

După inserarea noului subformular în noua filă, salvați și închideți formularul „Setări politici\Setări desktop”. Verificați formularul pentru a vă asigura că modificările dvs. sunt reflectate în director și că pot fi personalizate folosind valori.

Odată finalizată configurarea, deschideți Domino Directory utilizând clientul Lotus Notes și navigați la vizualizarea Policies\Settings. Faceți clic pe butonul Adăugare setări și selectați Desktop pentru a crea o politică pentru desktop.

În fila Noțiuni de bază a documentului, în secțiunea Opțiuni server, selectați opțiunea „Creați replica locală a fișierului de e-mail”. În fila Baze de date a documentului, adăugați un link către baza de date pentru catalogul de directoare în câmpul Catalog de directoare mobile.

În noua filă Document de locație pe care ați adăugat-o, selectați fila Mail (vezi Figura 12). Setați următoarele opțiuni:

  • Locația fișierului de e-mail: local
  • Domeniu de e-mail Domino: numele dvs domeniul de mail Domino
  • Numele destinatarului înainte de tip: Numai local
  • Adresa de e-mail: Local apoi Server
  • Transferați e-mailurile trimise dacă: 1 mesaje în așteptare
Figura 12. Setarea documentului de locație – ​​Setări de e-mail în documentul Setări desktop

În noua filă Document de locație, selectați fila Replicare (vezi Figura 13). Setați următoarele opțiuni:

  • Activați replicarea: „Replicarea este activată pentru această locație”
  • Creați replici noi: Imediat
  • Replicați când pornește Notes: „Replicați când pornește Notes” și Solicitați înainte de replicare
  • Program: Interval de replicare
  • Replicați zilnic între: 7:00 AM – 7:00 PM
  • Repetați la fiecare: 30 de minute
  • Zilele săptămânii: Luni, Marți, Miercuri, Joi, Vineri
  • Replicați când Notes se termină: „Solicitați replicarea când Notes se închide” și „Dacă căsuța de trimitere nu este goală”
Figura 13. Documentul de setare a locației – ​​Replicare în documentul Politica de setări desktop

În subfila Preferințe - E-mail și știri a documentului Politică, setați noul interval de verificare a e-mailului la cinci minute și activați opțiunea Actualizare automată a căsuței de intrare. În subfila Preferințe - Replicare, activați „Creați replici gata pentru căutare”, setați câmpul Criptare replici la Criptare locală și câmpul Criptare folosind la nivelul de criptare dorit (Ridicat, Mediu, Scăzut). Salvați și închideți documentul Politica desktop.

Probleme legate de formarea utilizatorilor finali și a personalului de asistență tehnică

Modelul de replicare locală nu necesită instruire specială a utilizatorului atunci când este configurat corect. Scopul implementării este de a automatiza întregul proces pe cât posibil folosind politici. Cu toate acestea, există câteva lucruri care pot necesita o anumită pregătire pentru a se asigura că utilizatorii înțeleg problemele care pot apărea.

Notificare de sosire a noilor e-mailuri

Clientul Lotus Notes verifică în mod regulat dacă există e-mailuri noi pe serverul Domino. Dacă există mesaje noi pe server care nu au fost încă replicate către client, utilizatorul este notificat că a sosit e-mailul nou, dar nu poate găsi noul e-mail în folderul Inbox local. Întârzierea livrării mesajului depinde de dimensiunea mesajului de e-mail și de încărcarea serverului. Când un utilizator folosește copia de server a bazei de date de e-mail, un mesaj apare în Inbox înainte de a fi notificat.

Întârziere în trimiterea mesajelor către server înainte de oprire

Dacă un mesaj este trimis înainte ca clientul Notes să fie închis, este posibil să nu fie suficient timp pentru ca mesajul să fie trimis la server. Configurația este setată să trimită mesaje imediat, dar în funcție de dimensiunea mesajului sau de tipul de conexiune la server, mesajul poate fi în curs de trimitere. Veți vedea următorul mesaj (vezi Figura 14) dacă mesajul nu a fost trimis complet.

Figura 14: Avertizare că există un mesaj de ieșire care așteaptă să fie trimis înainte de a închide clientul

Replicare numai prin e-mail pentru a reduce încărcarea serverului

Una dintre problemele cu utilizatorii care folosesc replici locale de e-mail este că au tendința de a replica toate bazele de date din fila Replicare în loc să utilizeze opțiunea „Replicare numai e-mail”. În fila Replicare, faceți clic pe butonul Începe acum și selectați una dintre următoarele:

  • Începe acum. Pornește replicarea tuturor bazelor de date din fila Replicare.
  • Începeți e-mail numai acum. Pornește replicarea bazei de date de e-mail.
  • Porniți acum baze de date cu prioritate ridicată. Pornește replicarea tuturor bazelor de date marcate ca prioritate ridicată.

Bifați caseta de selectare Notificare din stânga bazei de date de e-mail din fila Replicare. Activează/dezactivează replicarea bazei de date; Utilizatorii pot dezactiva această opțiune. Politicile nu forțează activarea acestei opțiuni. Prin urmare, dacă utilizatorul dezactivează replicarea fișierelor de e-mail, aceasta nu va avea loc până când utilizatorul verifică din nou baza de date.

Opțiuni de configurare a filei Replicare

Puteți modifica fila Replicare pentru a se potrivi nevoilor utilizatorilor dvs. Mai jos este un set de instrucțiuni pentru a ghida utilizatorii prin opțiunile de configurare a filei Replicare.

Utilizatorii pot face clic pe săgeata în jos de pe butonul Replicare (vezi Figura 15). Acestea pot modifica dimensiunile pictogramelor, pot schimba modul de afișare a filei, pot afișa toate bazele de date sau numai pe cele marcate pentru replicare sau pot crea foldere pentru a organiza bazele de date.

Figura 15. Modificarea aspectului și funcționalității filei Replicare

Concluzie

Acest articol oferă o explorare detaliată a modelului de replica locală a corespondenței, concentrându-se pe pașii necesari pentru implementarea completă a mediului, atât manual, cât și automat. Dacă un model local de replică de e-mail pare cel mai potrivit pentru mediul dvs., acest lucru va ajuta la minimizarea bătăilor, efortului și administrarii implementării acestuia.

Sistem de management al documentelor Lotus Notes

Caracteristică

LotusNotes este un sistem de arhitectură client-server orientat către o bază de date de format propriu, dezvoltat de corporația LotusDevelopment, care este în prezent dezvoltat și vândut de IBM. Sistemul rulează pe diferite platforme ale familiilor Windows și UNIX.

Scop

LotusNotes a fost conceput inițial pentru a funcționa pe rețele locale, dar acum poate funcționa pe rețele globale, de exemplu, pe Internet.

Componentele principale:

  • Middleware.

Scurtă descriere a funcționării

Fiecare client sau server poate avea mai multe baze de date locale. Fiecare bază de date este o colecție de note. Clientul este o combinație între un subsistem de lansare și module de vizualizare comparabile ca funcționalitate cu browserele Web. Spre deosebire de browsere, acestea oferă capacitatea nu numai de a citi, ci și de a edita informații.

Funcția principală a serverului Lotus (LotusDomino) este de a gestiona o colecție de baze de date și de a oferi acces la acestea clienților și altor servere.

Replicare

Replicarea se bazează pe documente de conexiune - note speciale conținute în directorul Domino și care descriu ora, metoda (schema de replicare - vezi Tabelul 5) și obiectul replicării.

Tabelul 4

Tipuri de ID-uri de note

Identificator

vizibilitate

Descriere

ID universal (UNID)

Global

Identificator unic global atribuit fiecărei note

ID-ul inițiatorului (OID)

Global

ID notă, inclusiv informații despre istoric

ID-ul bazei de date

În cadrul serverului

Marca temporală pentru crearea unei baze de date sau restaurarea unei baze de date după o defecțiune a serverului

Notă ID

În cadrul bazei de date

Notă ID-ul în funcție de instanța DB

Replica ID

Global

Marca temporală utilizată pentru a identifica copii ale aceleiași baze de date

Operațiuni de modificare:

    modificarea documentului;

    adăugarea unui document;

    ștergerea unui document.

Documentul modificat trebuie distribuit tuturor replicilor. Modificările aduse unei note au ca rezultat o modificare a OID-ului acesteia, a cărei valoare anterioară este copiată în istoricul documentului. Când adăugați un document, un nou UNID și OID sunt create pentru acesta. Când un document este șters, un stub de ștergere este plasat în locul său în baza de date. Stub-ul de ștergere nu este distrus până când toate copiile documentului șters nu sunt distruse.

Tabelul 5

Scheme de replicare

Descriere

Extracție-promovare

Jobul de replicare citește modificările de pe serverul țintă și trimite propriile modificări către acesta

extracţie

Jobul de replicare citește modificările de pe serverul țintă și își transferă propriile modificări pe baza solicitărilor sale

Promovare

Jobul de replicare transmite propriile modificări către serverul țintă fără a reacționa în vreun fel la modificările existente pe acesta

Extracţie

Jobul de replicare citește modificările de pe serverul țintă fără a încerca să-și introducă propriile modificări la acesta

Rezolvarea conflictelor de replicare

În timpul replicării pull-forward, este creată o listă de OID-uri pentru fiecare replică. Apoi se compară listele de pe cele două servere. Notele cu UNID care nu sunt prezente pe celălalt server (adică, adăugate) trebuie să fie transferate la acesta.

Pentru notele care au același UNID, dar OID diferit în listele de servere A și B, următoarele acțiuni. Lucrarea de replicare analizează istoricul ambelor note. Dacă una dintre povești face parte din cealaltă, atunci nu există conflict: nota mai nouă o înlocuiește pe cea mai veche. Dacă modificările se referă la diferite elemente ale notei, atunci nu există nici modificări conflictuale: cele mai recente elemente sunt transferate în nota îmbinată. În toate celelalte cazuri, conflictul este de nerezolvat. În acest caz, Notes alege unul dintre documente drept câștigător. Aceasta devine copia cu numărul de serie mai mare în OID sau (în cazul numerelor de serie egale) cu un marcaj de timp mai mare.

Replicare într-un cluster

Într-un cluster, în loc să se programeze în mod explicit replicarea folosind documente glue, modificările sunt pur și simplu propagate imediat la toate replicile din cluster.

În acest scop, fiecare server menține o coadă de evenimente de replicare în care sunt înregistrate modificările locale. O dată la fiecare secundă, un job special de replicare scanează coada pentru modificări care ar trebui propagate către alte servere din cluster, le promovează și elimină evenimentele din coadă.

4. Lotus Domino și Notes ca o combinație de opt tehnologii cheie

Ce sunt „sistemele de colaborare integrate” în general și care este esența Domino și Notes, în special din punct de vedere tehnologic? Raportul IDC menționat mai devreme conține rezultate interesante dintr-un sondaj al utilizatorilor europeni ai sistemelor de colaborare și colaborare. Pe baza rezultatelor acestui sondaj, V în ordinea descrescătoare a intensității utilizării următoarele tehnologii, care constituie esența „software-ului de colaborare”:

  • E-mail.
  • Mijloace de diseminare și schimb de informații.
  • Managementul documentelor.
  • Abilitatea de a rula aplicații specializate.
  • Instrumente de management al cunoștințelor corporative.
  • Managementul fluxului de lucru.
  • Instrumente pentru susținerea aplicațiilor de tip discuție.
  • Redirecționarea instantanee a mesajelor (chat).
  • Conferințe în timp real.

Lotus Domino și Notes, prin ele însele și în combinație cu alte produse din familia Domino, includ toate tehnologiile enumerate mai sus. Și totuși, dacă vorbim despre tehnologii cheie care sunt importante din punctul de vedere al înțelegerii arhitecturii produsului și a posibilităților de aplicare a acestuia, putem evidenția următoarele:

  • Baza de date orientată pe documente.
  • Instrumente de dezvoltare a aplicațiilor.
  • Sistem de e-mail.
  • Sistem de replicare a documentelor, informațiilor și aplicațiilor.
  • Mijloace de protecție a informațiilor și control al accesului.
  • Facilităţi programare si programare.
  • Tehnologii web și tehnologii Internet/Intranet.
  • Instrumente de integrare cu baze de date relaționale, sisteme de planificare a resurselor întreprinderii (ERP) și sisteme tranzacționale.

Multe dintre aceste tehnologii, luate individual, erau destul de bine cunoscute înainte de apariția Notes. Dar, unite împreună într-un singur sistem, au dat o calitate complet nouă, ceea ce ne permite să spunem: în prezent nu există pe piață un analog cu acest produs software.

Înainte de a ne uita pe scurt la fiecare dintre aceste opt tehnologii, facem următoarea notă. Pe parcursul acestui articol, menționăm în principal două produse software: Lotus Domino și Lotus Notes. Acest lucru se datorează faptului că Domino/Notes este o tehnologie client-server, în care Lotus Domino acționează ca server, iar Lotus Notes acționează ca client. Cu toate acestea, trebuie remarcat imediat că serverul Domino este unic, adică este, de asemenea, un server Web și un server de e-mail care acceptă standardele Internet, astfel încât browserele Web și alte servere de e-mail pot fi folosite ca parte client pentru lucrul cu Domino. aplicatii si e-mail.clienti de internet. Datorită sprijinului standardele industriei, cum ar fi ODMA, ActiveX, OLE și o serie de altele, pentru a accesa și salva date pe serverul Domino cu diferite grade de completitudine, suite de birou populare, telefoane mobile, asistenți digitali personali, cum ar fi PalmPilot, pagere și etc.

4.1. Baza de date Domino/Notes orientată pe documente

Inima lui Domino și Notes este un depozit de obiecte cunoscut sub numele de NSF (Fișier de stocare Note), unde sunt stocate datele.

Bazele de date Domino și Notes sunt diferite de SGBD-urile relaționale cu care mulți sunt obișnuiți să lucreze. În SGBD-urile relaționale, datele sunt descrise folosind tabele care definesc strict formatul datelor.

Baza unității de stocare a informațiilor în baza de date Date Lotus Domino/Notele sunt separate document. Structura unui document Note este determinată de formă, conținând un set de câmpuri de diferite tipuri. De exemplu, un document legat de serviciul pentru clienți poate conține o dată, numele unui client, un număr de identificare a clientului, numele unui operator, un câmp de text pentru a descrie cererea clientului și un câmp de stare a cererii. Notes folosește vizualizări indexate pentru a afișa liste de documente, navigatoare și indexuri full-text pentru a căuta documente și agenți pentru a automatiza anumite procese din baza de date.

O bază de date relațională este de obicei structurată rigid și fiecare înregistrare din tabel are același set de câmpuri, al căror spațiu este definit și alocat în prealabil. Oamenii 90% din timp se ocupă de documente, care sunt obiecte slab structurate, iar Notes a fost conceput inițial pentru a lucra cu astfel de informații. Aceasta a predeterminat structura bazei de date Notes. Un document individual nu are neapărat aceleași câmpuri ca și alte documente; Câmpului i se alocă atâta memorie cât este necesar pentru a stoca date specifice; câmpurile pot fi adăugate la documente în mod dinamic, pe măsură ce apare nevoia lor sau pe măsură ce opiniile dezvoltatorilor și utilizatorilor se schimbă.

O bază de date Notes poate stoca orice tip de date - de la text simplu, numere, ore și date la text formatat, grafică, sunet, video și date arbitrare care pot fi stocate ca obiecte atașate în format nativ. De exemplu, acesta ar putea fi un fișier MS Word sau Lotus 1-2-3 atașat.

Un document poate fi într-un format structurat sau nestructurat, astfel încât Notes poate stoca și procesa cantități mari de date care sunt dificil de procesat de sistemele de baze de date relaționale și de altă natură. În plus, prin utilizarea unui model de procesare a documentelor, Notes oferă utilizatorilor o serie de caracteristici utile.

  • Stocarea text îmbogățit, obiecte atașate și încorporate. Stocarea obiectelor Notes este ideală pentru gestionarea și distribuirea eficientă a informațiilor de afaceri. Aceste informații constau în mod obișnuit din diferite tipuri de date, cum ar fi tabele (poate derivate dintr-o bază de date relațională sau dintr-o foaie de calcul), text formatat, pagini web, grafice, obiecte atașate sau încorporate, obiecte media, cum ar fi imagini și faxuri scanate, clipuri audio și videoclipuri. În acest fel, Notes poate acționa ca un magazin de obiecte universal și un punct central de acces la orice informație corporativă.
  • Documentele se pot referi unul la altul ca documente „părinte” și „copil”. De exemplu, dacă ați creat o aplicație pentru urmărirea contactelor externe, atunci documentul „părinte” ar putea fi o descriere a organizației, „copii” la primul nivel - carduri de angajați, iar la următorul - rapoarte despre întâlnirile cu angajații sau scrisorile , etc.
  • Căutare text integral. Lotus Notes acceptă căutarea full-text, care permite utilizatorilor să indexeze și să caute documente Notes folosind interogări. Notes afișează documentele care corespund criteriilor dvs. de căutare, fie în ordinea în care se potrivesc cu criteriile, fie într-o ordine specificată de utilizator.
  • Gestionarea versiunilor. Lotus Notes include o caracteristică de versiune a documentelor care urmărește mai multe modificări aduse unui document de către diferiți utilizatori. Versiunile automate sunt implementate în așa fel încât fiecare sesiune de editare marchează documentul fie ca principal, fie ca derivat al originalului. Cu toate acestea, modificările aduse unui document Notes de către un utilizator nu sunt șterse atunci când alt utilizator salvează modificările în document. Versiunea Notes este flexibilă și poate fi modificată pentru a se potrivi nevoilor oricărui grup de lucru. În plus, utilizatorii au posibilitatea de a adăuga comentarii suplimentare la documentul original, lucrând cu acesta ca derivat, adică fără a salva din nou originalul.
  • Legături către documente. Notes are suport pentru hipertext, ceea ce înseamnă că fiecare document poate conține „legături” către alte documente din orice bază de date Notes sau către documente Web. Utilizatorii au capacitatea de a crea cu ușurință link-uri de la o pagină la alta cu un singur clic.

Pentru a asigura o scalabilitate adecvată pentru orice scop, dimensiunea stocării obiectelor Domino este limitată doar de resursele fizice disponibile. Această stocare se poate extinde dincolo de limitele sistemelor fizice de stocare. Formatul extrem de optimizat minimizează utilizarea I/O, ceea ce reduce accesul la disc și le face mai eficiente.

Pentru a asigura cea mai mare fiabilitate și protecție împotriva pierderii de date, stocarea obiectelor Domino utilizează cei mai buni algoritmi de jurnalizare sau de înregistrare a tranzacțiilor. Operațiunile cu baze de date sunt scrise secvenţial, reducând activitatea I/O în timp ce optimizează integritatea datelor și accelerează repornirea serverului.

Bazele de date Domino/Notes sunt acceptate de o serie de Servicii, care preiau executia cantitate mare operațiuni nivel inferior. De exemplu, un serviciu separat este responsabil pentru crearea și actualizarea indici, serviciu replicare este responsabil pentru menținerea copiilor de baze de date pe diferite servere și mașinile clientîntr-o stare sincronă unul față de celălalt, serviciu rutare este responsabil pentru livrarea mesajelor poștale etc. Aceste servicii rulează pe serverul Domino, unele dintre ele și pe clientul Notes. Dezvoltatorii de aplicații Domino nu trebuie să-și facă griji cu privire la aceste sarcini de nivel scăzut și se pot baza pe serviciile Domino pentru a gestiona munca grea, care necesită timp și detalii.

Bazele de date Notes sunt de obicei situate pe serverele Domino, dar pot fi localizate și pe mașinile client Notes, ceea ce este foarte important în ceea ce privește sprijinirea utilizatorilor offline și mobili. Utilizatorii accesează datele de pe server printr-o rețea, fie printr-un modem, fie lucrând cu datele local folosind un client Notes. Cu toate acestea, după cum s-a menționat deja, browserele web, clienții de poștă Internet etc. pot fi utilizați ca client pentru lucrul cu date și aplicații pe serverul Domino.

Utilizatorii pot vizualiza liste de documente stocate într-o bază de date Domino/Notes, numite și vederi, vizualizări sau vizualizări. Când un utilizator Notes deschide o vizualizare, numele câmpurilor apar ca titluri de coloană de date. Dacă, de exemplu, utilizatorul dorește să vizualizeze documentele după dată, atunci Notes, sortându-le după valorile din acest câmp, deschide o vizualizare în care coloana din stânga conține data și alte informații din câmpuri (numărul clientului, numele politicii etc.) este afișat în coloanele din dreapta celei principale. Vizualizările din Note sunt flexibile și folosesc o metaforă schematică bazată pe „dezvăluire și ascunde”. De exemplu, dacă un document principal are multe documente secundare, atunci utilizatorul poate alege să vizualizeze fie documentul principal, documentul principal și toate documentele la nivelul următor, fie toate nivelurile de documente legate de primul document principal.

Diferite vizualizări pot efectua selecții diferite de documente, precum și sortarea și/sau clasificarea (gruparea) a acestora în funcție de anumite criterii. Continuând cu exemplul unei baze de date externe de urmărire a contactelor, un mod de vizualizare ar putea fi vizualizarea tuturor documentelor, clasificate după numele organizației, o altă vizualizare ar putea fi doar o listă de profiluri de angajați, sortate după nume etc.

Astfel, pentru a crea o bază de date funcțională în Domino/Notes, trebuie doar să urmați acești pași:

  • Decideți ce tipuri de documente vor fi stocate în el și creați un set adecvat de formulare.
  • Decideți ce moduri de vizualizare a documentelor vor fi convenabile pentru utilizatorul acestei baze de date și creați un set adecvat de moduri de vizualizare (vizualizări).

Pentru a rezolva aceste probleme, există instrumente adecvate de dezvoltare grafică, care vor fi discutate mai jos. După ce ați creat aceste elemente, puteți începe să introduceți documente și să lucrați cu baza de date. Trebuie remarcat faptul că în Notes conceptele de „bază de date” și „aplicație” sunt, de fapt, sinonime. Deși în cazuri mai complexe, o aplicație Domino poate consta din mai multe baze de date interconectate sau poate integra date din alte surse, cum ar fi SGBD-urile relaționale. Desigur, crearea de aplicații mai complexe va necesita și alte instrumente de dezvoltare care vin cu Domino și Notes, pe care le vom trata în continuare.

În plus, Notes vine cu vizualizatoare de fișiere pentru cele mai populare aplicații desktop, oferind utilizatorilor posibilitatea de a citi și imprima date fără a avea aplicația pe computer.

4.2. Replicare

Mulți clienți care folosesc în mod activ Domino și Notes de mult timp, când au fost întrebați care dintre toate tehnologiile acestor produse le place cel mai mult, replica nume. În esență, sistemul de replicare rezolvă două probleme principale:

  • Suport pentru munca distribuită geografic (sincronizarea datelor și aplicațiilor).
  • Suport pentru utilizatorii de telefonie mobilă.

Domino și Notes permit partajarea informațiilor în orice moment și indiferent de locația utilizatorului. Utilizatorii bazelor de date și aplicațiilor Notes pot proveni din diferite părți ale unei organizații, la nivel regional, național sau global. Fiecare dintre aceste departamente poate avea propriul server, la care personalul se poate conecta destul de simplu și fără costuri mari. Ca rezultat, utilizatorul va avea acces la date și aplicații de pe serverul local, în loc să fie nevoit să lucreze cu un server la distanță pe canale de comunicare lente.

Utilizatorii din diferite birouri vor lucra cu propria „copie” a bazei de date situată pe un server local, iar replicarea asigură că grupurile de lucru situate în diferite locații geografice lucrează cu versiuni actualizate ale acelorași documente și schimbă informații. Serverele Domino vor face schimb de date între ele în conformitate cu programul specificat, folosind canalele care le sunt disponibile.

Trebuie remarcat faptul că Domino și Notes sunt omnivore în ceea ce privește utilizarea canalelor de comunicare: acestea pot fi rețele TCP/IP, X.25, ISDN, canale telefonice dial-up etc. Una dintre cele mai subtile și mai bine dezvoltate tehnologii de către dezvoltatorii Lotus este utilizarea eficientă a canalelor de comunicare arbitrare.

Domino vă permite, de asemenea, să creați o arhitectură centralizată dacă comunicațiile disponibile unei anumite organizații permit acest lucru.

Replicarea Notes este de neegalat în funcționalitatea și granularitatea sa: rulează la nivelul domeniilor individuale si perfect personalizabil. Replicarea este caracterizată de următoarele proprietăți:

  • Bidirecționalitate. Utilizatorii din toate părțile organizației care au o copie replicată a bazei de date pot adăuga, modifica și șterge documente. Replicarea bidirecțională în Notes sincronizează toate modificările efectuate în toate locațiile, mai degrabă decât doar propagarea modificărilor făcute într-o locație centrală către serverele de la distanță.
  • Eficienţă. La sincronizarea bazelor de date, replicarea este necesară numai pentru câmpurile de document noi sau pentru câmpurile de document care au fost modificate în oricare dintre instanțele bazei de date care participă la procesul de replicare. Această replicare la nivel de câmp asigură utilizarea optimă a resurselor și cei mai scurti timpi de ciclu de sincronizare.
  • Replicare pentru clientul Notes. Utilizatorii care se conectează ocazional la server (de exemplu, utilizatorii de telefonie mobilă care lucrează la o locație la distanță, în călătorii de afaceri sau acasă) au nevoie de același nivel de acces la informații ca și utilizatorii conectați. Notes nu se limitează la comunicarea de la server la server, ci acceptă și replicarea client-server. Acest lucru oferă suport operațional excelent. utilizatorii de telefonie mobilă lucrul off-line cu datele și aplicațiile Notes în același mod ca și cum ar fi la birou și conectate la server. Utilizatorul poate lua cu ușurință cele mai recente copii ale bazelor de date Notes, poate lucra cu ele local și apoi le poate sincroniza cât mai curând posibil.
  • Replicare selectivă. Cu doar câteva clicuri, un utilizator Notes poate copia doar un anumit subset de informații din baza de date Notes către el însuși. Notes permite utilizatorilor să definească tipul de documente cu care doresc să lucreze pe stațiile de lucru client. Cu replicarea selectivă, utilizatorii pot copia doar documentele care s-au modificat, cum ar fi în ultimele 30 de zile sau au fost scrise doar de un anumit membru al echipei.
  • Replicare de fundal. Rularea procesului de replicare pentru un utilizator mobil nu ar trebui să provoace oprirea tuturor celorlalte lucrări de pe laptop sau computerul de acasă. Replicarea în Notes poate avea loc în fundal, permițând utilizatorului să continue să lucreze la alte sarcini.
  • Sincronizarea designului și logicii aplicației. Acest aspect trece adesea neobservat la prima vedere, deși această tehnologie facilitează distribuirea aplicațiilor în întreaga organizație și dincolo de acestea și efectuarea modificărilor acestora după cum este necesar. În timpul comunicațiilor dintre serverele Domino, nu sunt trimise doar datele în sine, ci și toate modificările în designul și logica aplicației. Domino stochează datele și designul unei aplicații individuale într-un singur fișier NSF. Imaginați-vă, de exemplu, o aplicație Notes pentru colectarea rapoartelor din regiuni. Dacă, de exemplu, dezvoltatorii din Moscova fac modificări în formularul de raportare zilnică, atunci în timpul următoarei sesiuni de replicare toate aceste modificări vor fi transferate către departamentele de la distanță. În dimineața următoare, utilizatorul din Vladivostok va vedea că designul aplicației s-a schimbat și va începe să lucreze cu, de fapt, o nouă versiune a aplicației.

4.3. Sistem de e-mail și mesagerie

De fapt, dacă din cele opt tehnologii cheie enumerate mai sus, doar una ar fi permisă să fie utilizată - cea mai importantă, eficientă, fiabilă etc., atunci, după toate probabilitățile, mulți utilizatori ar opta pentru sistemul de e-mail Domino/Notes . Implementarea produsului este deja justificată doar atunci când este utilizat ca sistem de e-mail corporativ.

Acest sistem poate fi caracterizat prin cuvintele: de încredere, scalabil, sigurȘi controlat. Există organizații în lume în care peste 100 și chiar 200 de mii de angajați sunt uniți prin sistemul de mesagerie Domino și Notes. Aceasta înseamnă că, alegând această tehnologie, nu veți întâlni limitări tehnologice în care totul funcționează bine cu zeci sau câteva sute de utilizatori, dar încep să apară probleme de netrecut pe măsură ce infrastructura continuă să se extindă. Când vine vorba de securitate, Domino oferă cea mai puternică securitate de e-mail pe Internet disponibilă pentru mesajele semnate și criptate prin integrarea perfectă a Infrastructurii cu chei publice (PKI) și a certificatelor X.509 V3.

Foarte important, Lotus Development este singurul furnizor care oferă o platformă de comunicații completă și integrată pentru organizațiile care doresc să treacă de la e-mail de bază la capabilități avansate de mesagerie și aplicații de colaborare bazate pe web. Serverul Domino oferă suport încorporat pentru orice client de mesagerie pe care îl poate folosi clientul: browsere web, Microsoft Outlook, Eudora și altele clienti de mail POP3 și IMAP4. Domino este, de asemenea, o completare excelentă pentru cel mai bun client de colaborare și e-mail din lume, Lotus Notes.

Sistemul de mesagerie Notes este utilizat în scopul său principal - să comunicatiiîntre oameni și ca o componentă importantă a aplicațiilor de automatizare a fluxului de lucru, precum și o platformă pentru calendarul și planificarea grupului.

Notes Messaging vă oferă un cont de e-mail ușor de utilizat. Utilizatorii mai experimentați pot folosi instrumente de gestionare a mesajelor pentru a procesa și organiza volume mari de e-mail. Interfața de utilizator Notes se bazează pe interfața premiată Lotus cc:Mail, care a devenit în esență interfața de e-mail standard pentru toți furnizorii. Notele includ editor puternic pentru a formata textul mesajului de e-mail. Este posibil să folosiți agenți pentru a efectua diverse sarcini, cum ar fi vizualizarea fișierelor atașate la mesajele primite pentru cuvinte cheie și salvarea acestora în folderul corespunzător. Agenții pot automatiza sarcinile efectuate pe server, oferind site-ului dvs. Web posibilitatea de a genera automat mesaje de e-mail cu conținut specific atunci când apar anumite condiții și evenimente.

Trebuie remarcat în special că e-mailul este o parte integrantă, fundamentală a sistemelor de automatizare a fluxului de lucru. Bazele de date integrate de mesagerie și documente ale Domino/Notes combină atât metodele push, cât și cele pull pentru partajarea informațiilor și oferă utilizatorilor un mijloc intuitiv și eficient de colaborare. De exemplu, la creare versiunea originala document pe care mai mulți angajați trebuie să-l examineze, utilizatorul le poate trimite un e-mail care include doar un link către document. Fiecare persoană care primește un mesaj poate deschide documentul cu un singur clic, asigurându-se că toți angajații lucrează la aceeași versiune, cea mai recentă a documentului. Mesajele de e-mail pot conține legături către orice document din baza de date Notes, inclusiv discuții, profiluri de clienți și documentație (cum ar fi politici și proceduri, ghiduri de depanare etc.), pagini web și servicii de știri.

Majoritatea aplicațiilor de afaceri și de flux de lucru vă solicită să notificați o anumită persoană sau să actualizați un document pe baza valorii unui anumit câmp sau a unei stări de proces. Luați în considerare o aplicație de serviciu pentru clienți. Solicitarea clientului vine sub forma unui formular completat de acesta pe o pagina Web. Solicitarea este introdusă în baza de date a serviciului pentru clienți Domino. După ce este salvat, serverul Domino trimite automat un e-mail reprezentantului de service corespunzător. Reprezentantul deschide mesajul și făcând clic pe linkul pe care îl conține, deschide o solicitare dintr-o bază de date partajată în care își pot salva comentariile. În plus, aplicația Domino monitorizează acest proces, astfel încât, dacă se oprește dintr-un motiv oarecare (de exemplu, dacă reprezentantul nu ia măsuri asupra acestei solicitări în termen de 12 ore), atunci Domino trimite e-mailuri suplimentare, de data aceasta nu doar serviciului reprezentantului, dar și managerului său și șefului serviciului pentru clienți, alertându-i asupra unei potențiale probleme înainte ca aceasta să devină efectiv o problemă.

Din cauza caracteristicilor menționate mai sus, a funcționalității implicite de e-mail și a faptului că Domino este livrat cu șabloane de baze de date, cum ar fi Biblioteca de documente, Baza de date de discuții, Reconcilierea documentelor și multe altele, Domino și Note sunt de fapt, soluție gata făcutăîn domeniul colaborării oameni pe care îi puteți folosi imediat. Punerea la dispoziție a acestor funcții pentru utilizatorii de Internet (care nu au un client Notes) este pur și simplu o chestiune de a alege un șablon activat pentru Web.

Desigur, funcționarea unui sistem de e-mail este imposibilă fără o serie de servicii pe care se bazează mediul de mesagerie și care suportă serverul Domino:

  • Fiabil, flexibil și scalabil Magazin de mesaje Domino, bazat pe tehnologia bazei de date discutată mai sus.
  • Serviciu de director la scară de întreprindere (Director Domino). Domino Directory este o componentă arhitecturală scalabilă și sigură, cu suport deplin pentru protocolul de serviciu de directoare LDAP V3, care poate gestiona cu ușurință cerințele de servicii de director chiar și ale întreprinderilor foarte mari, oferind suport garantat pentru milioane de înregistrări. Modificările aduse unei instanțe a acestui director pot fi propagate în întreaga organizație folosind un serviciu eficient și sigur replicări Domino, cu garanția că toate copiile directorului Domino sunt sincronizate. Spre deosebire de unii dintre concurenții săi, Domino nu solicită personalului administrativ să actualizeze în mod constant toate copiile directorului pentru a se adapta la modificări. Capacitatea Domino și Notes de a replica doar porțiunile modificate ale intrărilor de director (până la nivelul câmpului) reduce și mai mult timpul de replicare și trafic de rețea, asociat cu sincronizarea directoarelor prin rețea. Directorul Domino este piatra de temelie a modelului de securitate Domino și Notes. Conține certificatele folosite pentru autentificarea tuturor utilizatorilor atunci când se conectează, certificatele conțin la rândul lor cheile publice folosite pentru semnare și criptare. Acest director acționează și ca un centru central de management și configurare pentru rețea. Menține utilizatorii, grupurile de utilizatori, înregistrările conexiunilor, rolurile și alte informații de control al accesului, permițând gestionarea centralizată (chiar și off-line) a întregii infrastructuri de rețea.
  • Serviciu de rutare a mesajelor. Routerul Domino oferă mesagerie de înaltă performanță, de înaltă fidelitate, atât pentru e-mail, cât și pentru aplicații, pe o gamă largă de protocoale. De exemplu, utilizatorii Domino pot lucra cu mai multe protocoale, folosind atât SMTP, cât și protocolul nativ Notes, Notes Remote Procedure Calls (NRPC-uri). Pentru a fi compatibile cu sistemele existente, NRPC-urile sunt capabile să ruleze o gamă largă de protocoale de rețea. În plus, routerul Domino oferă administratorilor noi modalități de a reduce costurile și de a îmbunătăți eficiența rețelei cu rutare multi-mode, capabilități extinse de suprimare a spam-ului, suport pentru sistemul de adrese Internet, suport complet pentru specificația E/SMTP extinsă, codificare nativă MIME a datelor și fișiere obiecte fără transformări suplimentare.
  • Serviciu de securitate(va fi discutat mai detaliat mai târziu).

Serverul Domino acceptă și modul de stocare „o copie a unui obiect”, care vă permite să economisiți spațiu pe disc și să reduceți traficul atunci când trimiteți aceleași mesaje unui număr mare de utilizatori.

Astfel, mesageria în Domino este mesagerie în conformitate cu standardele Internet, pentru care Domino oferă suport complet.


Algoritm de replicare
Să aruncăm o privire pas cu pas la ceea ce se întâmplă într-o sesiune de replicare
    Pasul 1. Stabilirea unei conexiuni la server. Serverul (stația) care inițiază replicarea se conectează la serverul apelat. Are loc procedura de autentificare și posibilitatea de a accesa acest server(despre mecanismul de autentificare și controlul accesului la server >>>)
    Pentru a stabili un program de replicare, serverul folosește documentul de conectare al Agendei de adrese, clientul Notes folosește documentul de locație.
    Pasul 2. Construirea unei liste de baze de date replicate. Fiecare server păstrează în memoria sa virtuală un tabel cu toate bazele de date și șabloane disponibile pe el, ordonate după identificatorul de replica - așa-numitul memoria cache a ID-ului replica. Replicatorul își compară memoria cache și cache-ul serverului apelat și, ținând cont de prioritățile de replicare și de bazele de date specificate pentru replicare (în documentul Connection sau în parametrii comenzii consolei), construiește o listă de baze de date care urmează să fie replicate în această sesiune
    Pasul 3. În continuare, pentru fiecare bază din listă
      • Stabilește dacă replicarea bazei de date este interzisă. Dacă una dintre replici este configurată cu o opțiune care interzice replicarea ( Dezactivați temporar replicarea pentru această replicăîn setările de replicare), replicarea bazei de date nu are loc, așa cum este indicat de linia de pe consola serverului. Replicarea este dezactivată pentru<сервер> <база>
      • Fiecare dintre servere poate deschide o replică pe alt server. Dacă unul dintre servere nu are acces (nivel fără acces) la una dintre replici sau nu are acces la directorul conectat (legat) în care se află replica, replicarea bazei de date se încheie cu un mesaj Controlul accesului este activat<сервер> <база>pentru a nu permite replicarea din<сервер> <база> . Dacă ambele servere au acces la ambele replici, replicatorul deschide o replică pe serverul apelat.
      • Replicarea ACL. Pentru replicarea ACL, este necesar ca serverul apelat să aibă acces Manager la ACL-ul serverului apelant și opțiunea să fie selectată în setările de replicare de pe serverul apelant Primiți aceste elemente de la alte replici: Lista de control acces. Replicatorul compară datele modificării ACL în ambele replici. Dacă ACL-ul replicii „străine” s-a schimbat mai târziu decât ACL-ul „propriu”, replicatorul primește ACL de la serverul apelat și își înlocuiește propriul ACL cu acesta, după care verifică din nou dacă fiecare dintre servere se poate deschide replica celuilalt. Cu schema Trage împinge acțiunile de tip oglindă sunt efectuate de replicator în raport cu ACL-ul de pe serverul apelat. Cu o schemă de replicare Trage-Trage actualizarea (dacă este necesar) va fi efectuată de replicatorul serverului apelat după ce controlul este transferat acestuia în a doua fază a sesiunii de replicare
      • Replicarea elementelor de proiectare. Pentru ca această parte a replicării bazei de date să aibă succes, este necesar ca nivelul de acces al serverului apelat în ACL-ul replicii bazei de date de pe serverul de inițiere să nu fie mai mic decât nivelul Designer. Serverul caută și acceptă elemente de design care au fost modificate pe serverul apelat mai târziu decât aceste elemente s-au schimbat pe partea sa, înlocuindu-le pe acestea din urmă. Dar numai dacă acest lucru este permis de opțiunile specificate în parametrii de replicare a bazei de date din câmpuri Primiți aceste elemente de la alte replici: Elemente de design, Agenți, Formule de replicare. Ștergerea elementelor de design este similară cu ștergerea documentelor prin transmiterea informațiilor de ștergere ( cioturi). După ce acceptă modificările, serverul elimină modificările care au avut loc pe partea sa (diagrama Trage împinge) după verificări ca oglindă, sau trece la următoarea etapă de recepție, lăsând transferul modificărilor până la a doua fază a sesiunii (schemă Trage-Trage)
      • Replicarea documentelor. Recepția modificărilor documentelor la serverul inițiator are loc dacă serverul apelat are acces la baza de date (ACL) și documente (câmpuri de acces la documente de tip Cititori și Autori), permițându-vă să creați, să modificați sau să ștergeți documente. Printre documentele serverului apelat se construiește o vedere specială care conține documente conform formulei de replicare. Replicatorul creează apoi o listă de ID-uri de document care s-au modificat de la ultima replicare. Dacă opțiunea Primire documente de la server - Cel mai mic primul este activată în setările de replicare, lista rezultată este sortată după dimensiunea documentului, în caz contrar - după data modificării. În continuare, pentru fiecare document, omologul său din replica sa este căutat după identificator. Dacă acest lucru eșuează, document nou adăugat la replică. Dacă documentul nu este nou, orele sunt comparate ultima modificareși numerele succesive ale acestor documente. Dacă documentul a fost modificat de la ultima replicare pe ambele servere, apare un conflict de replicare (acest caz este discutat mai jos). În caz contrar, modificările sunt transmise serverului care inițiază replicarea, modificând documentul pe partea sa. Mai mult decât atât, începând cu versiunea 4.x, toate câmpurile nu sunt copiate complet; sunt copiate doar câmpurile care au steaguri Seq Num diferite. Acest lucru reduce semnificativ cantitatea de informații transmise. Aceasta este ceea ce se numește replicare la nivel de câmp (articole). În plus, în funcție de schema de replicare, fie replicatorul de server repetă acțiunile descrise în acest paragraf în direcția oglindă, împingând documente noi și modificate (schema Trage împinge), sau trece imediat la următorul punct, lăsând această lucrare pentru replicatorul altcuiva ( Trage-Trage)
      • Actualizarea unei intrări în istoricul replicărilor. După finalizarea cu succes a etapelor anterioare de replicare, replicatorul face o intrare în istoricul replicării replicii sale. Dacă replicarea are loc conform schemei Trage împinge, apoi replicatorul face o intrare similară în istoricul de replicare a replicii altcuiva
    Pasul 4. Sfârșitul sesiunii de replicare. Când lista bazelor de date replicate este epuizată, replicatorul fie întrerupe conexiunea (schema Trage împinge), sau trimite o solicitare de activare a replicatorului către partea din spateși transferul modificărilor înapoi.
Rezolvarea conflictelor de replicare
Când replicatorul detectează că, de când ultimele versiuni de replicare ale documentului din ambele replici de baze de date s-au schimbat, este forțat să gestioneze situația unui conflict de replicare. Versiunea documentului care are o oră de modificare ulterioară este selectată și utilizată ca document principal. A doua versiune a documentului este salvată ca document de răspuns la documentul principal (prezența unui câmp $Ref cu un link către documentul principal). În plus, la documentul de răspuns este adăugat un câmp numit $Conflict cu o valoare goală. În vizualizările care sprijină organizarea ierarhică a documentelor, astfel de documente sunt afișate ca document de răspuns, marcate cu un romb în coloana de selecție a documentului și o linie .
De fapt, rezolvarea conflictelor, începând cu cea de-a cincea versiune a Notes, este afectată de valoarea câmpului $ConflictAction, a cărui valoare în interfața client Domino Designer poate fi setată prin proprietatea Conflict Handling a formularului pe care sunt create documentele.
  • Valoarea acestei proprietăți Create Conflicts (absența câmpului $ConflictAction sau a valorii câmpului setată la „1” în document) specifică rezolvarea situației de conflict descrisă mai sus - crearea unui conflict de replicare
  • Valoarea proprietății Merge Conflicts (valoarea câmpului $ConflictAction egală cu „2”) - îmbinarea conflictelor care au apărut la editarea diferitelor câmpuri în replici diferite de baze de date
Din punct de vedere organizațional, pentru a rezolva conflictele apărute, este necesar să se adune autorii modificărilor „la o masă rotundă” pentru a înțelege modificările efectuateși dezvoltarea unei opțiuni convenite.
Din punct de vedere tehnic, această problemă este rezolvată astfel. Dacă se decide să lase versiunea documentului acceptată ca principală, documentul aflat în conflict este pur și simplu șters. Dacă trebuie să păstrați versiunea documentului aflat în conflict, deschideți-o în modul de editare, salvați-o (câmpurile $Conflict și $Ref dispar, iar documentul devine cel principal), apoi ștergeți cealaltă versiune a documentului. [Dar în acest caz, dacă apare un conflict cu documentul de răspuns, împreună cu câmpul $Ref, legarea acestuia la documentul principal se pierde. Este necesar să restabiliți conexiunea pierdută]. În cele din urmă, dacă ambele versiuni trebuie să rămână, este suficient să resaveți documentul aflat în conflict.
Dacă în timpul funcționării bazei există o tendință crescută de a crea conflicte, cel mai probabil este necesar să se schimbe fie designul bazei, fie tehnologia de lucru cu aceasta. Una dintre cele mai eficiente tehnici de modificare a designului este împărțirea unui document mare în mai multe documente mici, în care modificările nu se fac la un singur document, ci se bazează pe crearea de documente noi, mai mici. În plus, fereastra de proprietăți a formularului oferă opțiuni Versiune- gestionarea versiunilor documentelor și Gestionarea conflictelor- cu optiunea de fuzionare automata (Merge conflicts) a documentelor aflate in conflict, daca utilizatori diferiți a schimbat diferite domenii în ele.
Problemele organizatorice includ, în primul rând, limitarea tehnologică a posibilității de a edita un document de către cât mai puțini utilizatori (ideal, autorul documentului plus, pentru asigurări, managerul bazei de date). Alți utilizatori fac modificări documentului creând documente de răspuns la acesta sub formă de comentarii.