Crearea și configurarea unei baze de date distribuite (RDB) în 1C 8.3 Contabilitate (și alte configurații) este necesară în cazurile în care nu este posibil ca mai mulți utilizatori să lucreze în timp ce se conectează simultan la o bază de date. În zilele noastre, acest lucru este destul de rar, deoarece desktopul standard la distanță funcționează bine și există alte programe care oferă o conexiune la distanță la computerul central unde se află baza de date.

Dar, cu toate acestea, există situații în care pur și simplu nu există Internet. Și datele ar trebui să ajungă în cele din urmă într-o singură bază de informații. Acesta este motivul pentru care se creează o bază de date distribuită.

De obicei, baza principală se numește centrală, iar restul sunt numite periferice. Concluzia este că fie manual, fie automat (în funcție de setări), bazele de date sunt combinate într-una singură. Pentru a vă asigura că numerele de documente nou introduse și codurile de referință nu sunt duplicate, fiecărei baze de date i se atribuie un prefix.

În această instrucțiune, vom folosi un exemplu pentru a crea o bază de date centrală și periferică și a verifica schimbul dintre ele. Acest manual este potrivit atât pentru 1C 8.3 Accounting și 1C Trade Management (UT), cât și pentru alte configurații.

Configurarea bazei de date RIB distribuite principale (centrale).

Să mergem la meniul 1C „Administrare”, apoi faceți clic pe linkul „Setări de sincronizare a datelor”. În fereastra care se deschide, trebuie să bifați caseta de selectare „Sincronizare datelor”. Linkul „Sincronizare datelor” va deveni activ. Chiar aici vom seta un prefix pentru baza de informații principale - de exemplu, „CB”:

Faceți clic pe linkul „Sincronizare datelor” și se va deschide o fereastră cu butonul „Configurați sincronizarea datelor”. Când faceți clic pe acest buton, se va deschide o listă derulantă în care trebuie să selectați modul „Complet”. Dacă sincronizarea este necesară doar pentru o singură organizație, trebuie să selectați „După organizație...”.

În fereastra următoare, programul ne va solicita să facem o copie de rezervă. Recomand cu tărie să faceți acest lucru, deoarece următorii pași de configurare pot fi ireversibili.

După crearea unei copii de rezervă, faceți clic pe butonul „Următorul”. La pasul următor, trebuie să decidem cum va avea loc sincronizarea:

• printr-un director local sau un director din rețeaua locală;
• pe Internet prin FTP.

Pentru simplitate și claritate a exemplului, vom selecta un director local. Am specificat următoarea cale: „D:\1C Baze de date\Synchronization”. Ar fi o idee bună să verificați intrările din acest director; există un buton special pentru aceasta:

Obțineți 267 de lecții video pe 1C gratuit:

Omitem pașii următori cu configurarea sincronizării prin FTP și e-mail. Să ne uităm la setările pentru numele bazelor de date principale și periferice. Aici vom seta prefixul pentru baza de date periferică:

Nu uitați că prefixele pentru fiecare bază de date trebuie să fie unice. În caz contrar, veți primi eroarea „Valoarea prefixului primei baze de informații nu este unică”.

Faceți clic pe „Next”, verificați informațiile introduse și faceți clic din nou pe „Next”, apoi pe „Finish”. În câmpul „Numele complet al bazei de fișiere”, indicați fișierul 1Cv8.1CD din directorul care a fost creat pentru sincronizare. Creăm imaginea inițială a bazei de date distribuite 1C:

După crearea imaginii inițiale a RIB în 1C, puteți seta un program de sincronizare sau puteți sincroniza manual:

După sincronizare, vă puteți conecta la noua bază de date și vă puteți asigura că informațiile din baza de date centrală au fost încărcate acolo:

Doar creați imediat cel puțin un utilizator cu drepturi de administrator în noua bază de date periferică.

Configurarea sincronizării în baza de date periferică

În baza de date periferică 1C, configurarea este mult mai simplă. Doar bifați caseta de selectare „Sincronizare datelor” și urmați linkul cu același nume. Și aproape imediat ne găsim într-o fereastră cu butonul „Sincronizează”. Să încercăm să creăm un articol de testare în baza de date periferică și să-l încărcăm în cea principală folosind RIB:

O situație apare adesea atunci când o organizație are mai multe sucursale sau puncte de vânzare cu amănuntul îndepărtate geografic unele de altele. Cu toate acestea, rămâne nevoia de a menține înregistrări consistente în întreaga organizație. Una dintre opțiunile pentru rezolvarea acestei probleme este crearea unei rețele unificate, care va include stații de lucru automate ale tuturor ramurilor și găzduiește baza de informații 1C pe un server public. Această metodă poate fi complexă și costisitoare din punct de vedere tehnic. În plus, apar o serie de probleme legate de securitatea informațiilor.

A doua opțiune este crearea unei baze de informații distribuite (RIB). O bază de informații distribuite este o structură ierarhică constând din baze de informații separate pe platforma 1C:Enterprise, între care schimbul de date este organizat în scopul sincronizării configurației și datelor. Aceste baze de informații individuale sunt numite noduri RIB.

O bază de informații distribuite poate fi creată pe baza diferitelor configurații ale sistemului 1C:Enterprise. Să luăm în considerare crearea sa folosind exemplul 1C: Managementul comerțului 10.3.

Să presupunem că un punct de vânzare cu amănuntul suplimentar este deschis într-o organizație comercială, unde este necesar să aveți acces la sistemul general de tranzacționare al organizației. Pentru a crea un RIB trebuie să parcurgeți următorii pași:

Aceasta completează crearea unei baze de informații distribuite. Pentru a face schimb de informații, trebuie să începeți schimbul de date în baza de date centrală (modificările care au avut loc în aceasta vor fi descărcate), apoi în magazin (modificările din baza de date centrală vor fi descărcate și modificările care au avut loc în magazin vor fi descărcate ), și din nou în baza de date centrală (modificările vor fi descărcate în ea , au avut loc în magazin).

Bazele de informații distribuite au propriul mecanism de rezoluție a coliziunilor. Deci, dacă în timpul unui schimb se dovedește că orice obiect (document, director etc.) a fost modificat atât în ​​baza de date principală, cât și în cea subordonată, atunci modificarea făcută în baza de date principală va avea prioritate.

Dacă este necesară modificarea configurației unei baze de informații distribuite, aceasta trebuie făcută în nodul rădăcină (vezi prima figură a articolului), configurațiile nodurilor rămase sunt blocate. După efectuarea modificărilor necesare, acestea pot fi transferate către nodurile slave folosind procedura standard pentru schimbul de date între nodurile RIB. După ce schimbul este efectuat în configuratorul nodului slave, este necesară actualizarea configurației bazei de informații.

Dacă aveți probleme la configurarea unei baze de informații distribuite, specialiștii noștri vă vor ajuta să configurați schimbul de date și vă vor explica în detaliu cum să o utilizați.

În acest articol vom vorbi despre configurarea unei baze de date distribuite 1C Enterprise 7.7; configurația Trade Management 9.2 va fi folosită ca exemplu.

Pentru a configura RIB-ul în 1C 7.7, trebuie să mergeți la configurator și să accesați Administration-Distributed IS-Management.

Apoi, trebuie să vă convertiți baza de date în RIB, dacă nu a fost încă convertită în RIB, pentru a face acest lucru trebuie să faceți clic pe butonul „Banca centrală de informații”.

Setați codul și descrierea ca în captura de ecran de mai sus și faceți clic pe „OK”. Ar trebui să apară un avertisment ca în captura de ecran de mai jos, ignorați-l și faceți clic pe „Da”.
După aceasta, baza dvs. va fi gata să creeze noduri periferice.

Faceți clic pe butonul „New Peripheral IB” și setați valorile câmpului ca în următoarea captură de ecran, cu toate acestea, puteți utiliza propriile desemnări.

Faceți clic pe OK și treceți la pasul următor - configurarea schimbului automat.

În acest articol vă voi spune cum să configurați schimbul automat folosind o rețea locală.Dacă aveți nevoie de schimbul automat prin poștă, lăsați solicitarea în comentarii sau contactați-mă și vă voi spune cum să o faceți.

Afișăm totul ca pe slide, puteți avea propriile căi către directoare, casetele de selectare ar trebui să fie ca în captura de ecran de mai sus. Faceți clic pe OK.

Acum încărcăm imaginea inițială a bazei de date periferice pe disc; pentru a face acest lucru, faceți clic pe butonul „Încărcați date”. După descărcarea imaginii inițiale, fereastra de gestionare a RIB va arăta astfel:

Să presupunem că computerul pe care va funcționa nervura noastră este situat nu departe de computerul principal cu o bază centrală și ambele computere sunt conectate la o rețea locală.

Acum trebuie să configuram RIB-ul pe computerul client; pentru a face acest lucru, luați fișierul nostru zip descărcat în pașii anteriori și creați o bază de informații bazată pe acesta. Capturile de ecran de mai jos arată secvența completă de acțiuni.

Faceți clic pe butonul „Adăugați” și indicați un folder gol și faceți clic pe OK.

Selectăm un nou sistem de securitate a informațiilor și trecem la modul configurator.

Creăm o bancă de informații goală într-un folder gol, așa că 1C ne cere să indicăm în ce format va fi baza noastră de date, selectați *.dbf. Faceți clic pe OK.

Acum să încărcăm fișierul zip încărcat în pașii anteriori în baza noastră de date; pentru a face acest lucru, mergeți la administrare - descărcați date.

Specificați calea către fișier și faceți clic pe OK.
Odată ce descărcarea este finalizată, faceți clic pe OK și accesați ib-auto-exchange distribuit de administrare.

La acest pas, este necesar să se țină cont de regula: director de descărcare CB = director de încărcare PB și invers, adică. dacă în baza de date centrală am încărcat în folderul out și am încărcat din folderul in, atunci în baza de date periferică vom încărca din folderul out și vom încărca în folderul in. Faceți clic pe OK și treceți la pasul următor. Efectuam schimburi automate. Pentru a face acest lucru, în baza de date centrală, accesați ib-autoexchange distribuit de administrare.

Faceți clic pe butonul „Run”, apoi faceți același lucru pe baza de clienți. Efectuați operația de schimb automat pe fiecare computer de mai multe ori.

Acum să automatizăm procesul. Pentru a face acest lucru, trebuie să creați 4 fișiere pe fiecare computer. 2 fișiere *.prm și 2 fișiere *.bat pentru fiecare operație de încărcare/descărcare.

Fișierul *.bat ar trebui să conțină următoarea linie:

"<путь к файлу 1cv77.exe>"config/D"<путь к информационной базе>„/N<логин>/P<пароль>/@"<путь к prm-файлу>"

Fișierele mele de încărcare și descărcare arată astfel:

"C:\Program Files\1Cv77\BIN\1cv7s.exe" config /D"C:\base\rib\" /Nadmin /P1 /@"c:\download.prm"

"C:\Program Files\1Cv77\BIN\1cv7s.exe" config /D"C:\base\rib\" /Nadmin /P1 /@"c:\upload.prm"

Tu scrii valorile tale. Acum să ne ocupăm de fișierele prm!

Structura fișierului .prm:

Secțiunea „General” are scopul de a descrie principalii parametri ai modului batch. Parametri posibili:

Ieșire – calea către fișierul jurnal;
- Ieșire – dacă configuratorul trebuie oprit după finalizarea tuturor sarcinilor;
- AutoExchange – dacă ar trebui efectuată autoexchange;
- SaveData – dacă este necesară salvarea bazei de date;
- UnloadData – dacă trebuie efectuată descărcarea;
- CheckAndRepair – dacă baza de date trebuie testată și corectată.

Valorile posibile pentru acești parametri pot fi 1(Y) sau 0(N).

Secțiunea „AutoExchange” este destinată definirii parametrilor de schimb automat. Opțiuni:

SharedMode – indică modul de operare din baza de date. Dacă parametrul nu este specificat, atunci va fi utilizat modul exclusiv;
- ReadFrom - indică din ce baze de date ar trebui primite datele. Identificatorii bazei de date trebuie specificati separati prin virgula. Dacă toate sunt necesare, atunci pune * ;
- WriteTo - indică pentru ce baze de date ar trebui să fie încărcate. Dacă este necesar pentru toată lumea, atunci pune *.

Secțiunea „SaveData” este destinată definirii parametrilor pentru salvarea bazei de date. Parametri posibili:

SaveToFile – indică calea în care se va efectua salvarea;
- FileList – indică lista de fișiere care urmează să fie salvate. Numele fișierelor sunt listate separate prin spații sau virgule;

Secțiunea „UnloadData” – este destinată definirii parametrilor pentru descărcarea datelor. Opțiuni:

UnloadToFile – specifică calea de salvare, inclusiv numele fișierului;
- IncludeUserDef – indică dacă lista de utilizatori ar trebui inclusă în fișierul de transfer;
- Parolă – specifică parola care va fi setată pentru fișierul de transfer.

Secțiunea „CheckAndRepair” este destinată definirii parametrilor de recuperare a bazei de date. Parametri posibili:

Repair – indică dacă este necesară restaurarea bazei de date;
- PhysicalIntegrity – indică dacă este necesară verificarea integrității fizice a tabelelor infobase;
- Reindexare – indică necesitatea reindexării bazei de date;
- LogicalIntegrity – indică dacă este necesar să se verifice integritatea logică a tabelelor;
- RecalcTotals – indică dacă este necesară recalcularea rezultatelor contabilității și contabilității operaționale;
- Pack – indică dacă este necesară eliberarea spațiului ocupat de înregistrările șterse;
- SkipUnresolved – specifică dacă să omiteți legăturile nerezolvate sau dacă le remediați;
- CreateForUnresolved – specifică modul în care sunt rezolvate legăturile nerezolvate. Dacă 1, atunci va fi creat un obiect de tipul corespunzător pentru legătura nerezolvată. Dacă 0, atunci linkul va fi șters.

Pe baza acestui lucru, fișierele mele vor conține următoarele:

pentru a descărca de la banca centrală la periferic:

Ieșire = log.txt
Ieșire = 1

ReadFrom = CB

pentru descărcarea de la Banca Centrală la periferie:

Ieșire = log.txt
Ieșire = 1

WriteTo = CB

pentru a descărca de pe periferic la Banca Centrală:

Ieșire = log.txt
Ieșire = 1

ReadFrom = PB1

pentru descărcarea de la periferie la Banca Centrală:

Ieșire = log.txt
Ieșire = 1

WriteTo = PB1

Acum este suficient să plasați fișierele bat și prm într-un folder și să le rulați unul câte unul pentru a efectua descărcarea și încărcarea.

Dacă aveți întrebări, nu ezitați să comentați!

Acesta este primul meu articol, criticile constructive sunt binevenite.

Publicul țintă este aceia care se confruntă cu RBD pentru prima dată.

Sarcini RDB

Primul lucru cu care trebuie să începeți este să răspundeți la întrebarea „De ce avem nevoie de un RDB?” Există multe răspunsuri posibile, în special:

1. Avem sucursale care rulează în baze de date deconectate. Acum vrem ca informațiile dintre ei să fie sincronizate;
2. Avem filiale, dar încărcarea pe baza de date este prea mare (asta înseamnă blocarea tranzacțiilor, nu volumul bazei de date) și relevanța online (a nu se confunda cu relevanța în câteva minute, online este atunci când după fiecare tranzacție datele sunt transferat la al doilea nod) nu sunt necesare date pentru ramuri;
3. Avem filiale în care are loc doar introducerea datelor (de exemplu, magazine de vânzare cu amănuntul), astfel încât să putem reduce semnificativ încărcarea pe baza de date centrală;
4. Din motive de securitate, dorim ca sucursalele să nu aibă acces, nici măcar teoretic (cu o parolă de administrator), la date importante, cum ar fi bilanţul companiei.

Într-un caz, întrebările 2 și 4 au fost relevante pentru mine, în altul, 2 și 3. Primul punct este prea amplu și nu va fi luat în considerare în sfera acestui articol.

De asemenea, este mai bine să luați în considerare imediat problema transportului fișierelor de schimb, deoarece în unele cazuri poate impune restricții semnificative asupra implementării schimbului de date. În primul rând, trebuie să determinați în ce ramuri vor apărea exact nodurile RDB (de obicei acestea sunt ramuri regionale). Apoi, luăm în considerare unde altundeva vrem să instalăm noduri RDB și dacă au nevoie de relevanță online. De exemplu, pentru magazinele de vânzare cu amănuntul nu este întotdeauna posibil să instalați nici măcar un modem, iar instalarea unei conexiuni wireless va fi prea costisitoare. Aici trebuie să iei o decizie - poate că acest magazin poate funcționa offline și poate schimba periodic cu centrul (o dată pe zi/o dată pe săptămână) folosind un mediu fizic, cum ar fi o unitate flash.

În unele cazuri, schimbul prin medii fizice nu este posibil, de exemplu, aceasta este o ramură foarte îndepărtată, unde există probleme semnificative cu configurarea comunicației de mare viteză. Aici merită să calculați aproximativ cantitatea de informații schimbate. Adesea, dacă este relevant o dată pe oră sau de mai multe ori pe zi, un modem de 32k este suficient. Cu toate acestea, merită să ne amintim că, împreună cu actualizările de date, va trebui uneori să trimiteți actualizări ale configurației în sine sau fișierelor externe (formulare tipărite, fotografii ale mărfurilor), astfel încât din când în când va apărea o situație când fișierul de schimb crește semnificativ datorită la astfel de actualizări.

Topologie

În total, am primit următoarele întrebări la care trebuie să răspundem:

1. În ce departamente avem garanția de a instala noduri RDB și este posibil să instalăm acolo un canal de mare viteză;
2. În ce departamente nu este necesară instalarea unei unități RBD?
3. Ce departamente pot lucra cu relevanță în câteva ore;
4. Ce departamente pot lucra offline (schimbul de date de mai puțin de 3-4 ori pe zi).

După ce am răspuns la aceste întrebări, obținem o diagramă aproximativă a RDB-ului nostru. Pentru companiile mari, de obicei se dovedește ceva de genul:

Fig 1. Diagrama tipică a RDB a unei companii mari

Dacă totul este relativ clar cu nodurile „Branch” - acestea sunt centre mari care necesită automatizare, atunci nodurile „Magazin” înseamnă un nod cu o sarcină serioasă în baza de date la introducerea datelor, care ar trebui să fie separate pentru a reduce sarcina. De exemplu, un magazin cu 50 de case de marcat și o cifră de afaceri zilnică de peste 10.000 de unități.

• Magazine - introduceți date despre propria cifră de afaceri și fluxul de numerar. Analizele sunt superficiale, doar pentru propriul magazin.
• Filiale - introducerea datelor punctelor neautomatizate, contabilitate, salarii și personal, producție etc. Analytics în cadrul propriei filiale.
• Centru - introducerea datelor filialelor neautomatizate. Analiza întreprinderii în ansamblu.

Este important să înțelegeți în ce scopuri va fi utilizată baza de date în fiecare nod. Din obiective se construiesc sarcinile necesare implementării, de exemplu:

• Sucursalele văd istoria decontărilor reciproce cu contrapărțile reciproce;
• Magazinele văd mărfuri rămase în întreaga (sau o parte) întreprindere;
• Analiza veniturilor/cheltuielilor, execuția bugetului etc. sunt vizibile doar în ierarhia propriului departament;
• Contabilitatea, salarizarea si personalul sunt vizibile doar in ierarhia propriului departament;
• Nomenclatura, toate proprietățile și caracteristicile sale sunt vizibile în toate nodurile RDB;
• În ceea ce privește ierarhia departamentală, toate datele curg în sus, dar sunt filtrate în jos;
• Centrul conține absolut toate informațiile despre companie.

Punându-ți astfel de întrebări, poți răspunde la cea mai dificilă întrebare - ce informații, unde și cum ar trebui să circule între nodurile RDB? De ce cel mai dificil? Știind ce seturi de date circulă între noduri, puteți înțelege clar cum să „tăiați” baza de date curentă, astfel încât datele să rămână consistente din punct de vedere logic. De exemplu, datele privind soldurile de mărfuri nu pot fi separate de datele privind rezervele curente.

Acum, în funcție de fluxurile de informații, să redesenăm diagrama RDB:

Ce vedem în figura 2? Conform ierarhiei diviziilor companiei, a fost construită o topologie a fluxului de informații între nodurile bazei de date. A fost adăugat și nodul „Center 2”, de ce? La implementarea topologiei Star, sarcina pe centru este întotdeauna mai mare decât sarcina pe nodurile periferice și adesea sarcina generată de nodul în sine este deja mare. Exemple de utilizare a nodurilor „Center 1” și „Center 2”:

1. „Centrul 1” servește doar la consolidarea datelor de la alte noduri RDB. Doar administratorul are acces la el. „Centrul 2” servește pentru activitatea sediului central;
2. „Centrul 1” servește pentru activitatea sediului central. Cu toate acestea, operațiuni grele de analiză și testare care creează o sarcină uriașă asupra bazei de date sunt efectuate în nodul „Center 2”; de exemplu, restabilirea secvenței, reprogramarea perioadelor închise, generarea de rapoarte rezumative pentru întreaga întreprindere pe o perioadă lungă de timp, generarea de analize care duc la modificări ale datelor;
3. „Centrul 1” servește pentru activitatea sediului central. „Center 2” este un backup în cazul unor situații neprevăzute pentru restaurarea rapidă a întregului RDB.

Implementarea schimbului

Există 2 opțiuni pentru funcționarea RDB:

1. Automat - are loc fără intervenția utilizatorului. Controlul asupra situațiilor de urgență este atribuit fie administratorului bazei de date, fie unui utilizator avansat;
2. Manual - schimbul are loc numai la cererea utilizatorului.

Din experiența mea, am condus întotdeauna toate implementările la versiunea automată. Dacă au existat probleme cu transportul fișierelor de schimb (prezența unei rețele în nod nu este constantă), atunci maximul pe care îl putea face utilizatorul a fost să facă clic pe butonul „Exchange Now”. Situațiile în care, pe lângă actualizarea datelor, există și o actualizare a configurației, este indicat să o faceți și în mod complet automat (de exemplu, folosind software terță parte).

Generarea pachetelor de actualizare

Deoarece există o decizie clară cu privire la nodurile RDB alocate care funcții, este posibil să se genereze numai pachetul de date de care acest nod are nevoie. Pe de o parte, este necesar să se specifice ce tipuri de obiecte vor fi sincronizate între noduri. De exemplu, registrele contabile pentru nodul „Magazin 1” nu ar trebui deloc sincronizate, deoarece Datele sunt introduse numai la nivelul nodului de ramură. Pe de altă parte, acele tipuri de date care fac obiectul schimbului trebuie filtrate cu referire la departament. De exemplu, datele privind primirea de bani de la nodul „Magazin 1 filiala 2” pot fi localizate numai în nodurile „Sucursala 2”, „Centrul 1” și „Centru 2”.

Totuși, există și problema opusă: dacă filtrezi prea mult datele de schimb, pachetul de date își va pierde integritatea logică. De exemplu, soldurile mărfurilor sunt luate în considerare în contextul depozitelor, iar rezervele sunt luate în considerare în contextul companiei în ansamblu, atunci dacă filtrați soldurile mărfurilor pe depozite și nu filtrați rezervele, datele vor fi incorecte.

De asemenea, ar trebui să decideți în ce etapă din viața sa obiectul trebuie schimbat. De exemplu, doar facturile înregistrate pot fi schimbate, dar nu și cele salvate pur și simplu. Fie că facturile din magazin nu se descarcă niciodată din nodul Centru, chiar și după ce sunt ajustate, dar trebuie luat în considerare efectul opus - datele pot fi desincronizate sau unele modificări pot fi suprascrise.

Este important să înțelegeți că atunci când faceți schimburi între noduri, unul dintre ele are prioritate. Luați în considerare situația:

1. Un document a fost creat în nodul „Magazin 1”;
2. În timpul schimbului, a ajuns în nodul „Branch 1”;
3. Documentul este corectat simultan în ambele noduri.

Ce document va fi considerat adevărat? În 1C 8.x, când se utilizează mecanismul „Planuri de schimb”, prioritatea implicită este nodul principal, adică. în acest caz, modificările efectuate în nodul „Magazin 1” vor fi pierdute și înlocuite cu date din nodul „Sucursala 1”.

Există o altă situație, mai complexă, când două obiecte conectate sunt reglate simultan. De exemplu, factura și PQR-ul pentru aceasta sunt ajustate în noduri diferite; există posibilitatea de pierdere a integrității dacă sunt modificate prețurile, sumele de plată, contrapărțile etc.

De asemenea, este important să se controleze ștergerea obiectelor, altfel acest lucru poate duce la faptul că, de exemplu, o factură nu va mai exista, dar mișcările contabile vor rămâne.

Mecanisme de schimb în 1C 8.x

Există două abordări pentru implementare:

1. mecanism „Planuri de schimb”;
2. Implementarea proprie a înregistrării obiectului.

Să luăm în considerare ambele opțiuni.

Mecanismul planurilor de schimb permite, fără nicio configurație, în câteva minute, crearea unei baze de date cu schimb complet de date. Dacă setați indicatorul „Bază de informații distribuită”, atunci când creați un pachet de actualizare, vor fi descărcate și actualizările de configurare. În doar câteva minute, puteți stabili reguli pentru a permite/interzice schimbul de diferite tipuri de date prin deschiderea compoziției planului de schimb. Dacă setați indicatorul „Înregistrare automată” în poziția „Refuz”, atunci acest tip de obiect nu va fi niciodată schimbat fără efort suplimentar.

De ce aveți nevoie de înregistrare, de ce nu încărcați totul deodată? În orice caz, un fișier care conține doar modificări ale stării bazei de date va fi mai mic decât un instantaneu complet al bazei de date în sine. Prin urmare, nu va fi luată în considerare opțiunea de descărcare completă.

Cum se configurează filtrarea datelor în funcție de afilierea departamentului? Aici va trebui deja să programați. În implementarea mea, a fost instalat un abonament la evenimentul „Când scrie” pe înregistrarea oricărui obiect, unde, folosind proprietatea „Schimb de date. Destinatari”, puteți seta lista de destinatari ai acestui obiect. Acestea. Când descărcați folosind mijloace standard pentru un nod care nu este în listă, obiectul nu va fi descărcat. Există o altă soluție - puteți alege dacă să descărcați un obiect direct la descărcarea obiectului, în procedurile „La trimiterea datelor către un subordonat” și „La trimiterea datelor către un maestru” din modulul plan de schimb.

Ambele opțiuni au dreptul de a exista. Totuși, am ales prima variantă ca fiind cea mai bună, deoarece calculul atributului de preîncărcare are loc imediat la scrierea obiectului, ceea ce crește durata înregistrării obiectului cu 3-5% (poate fi optimizat, în unele cazuri poate fi optimizat). să fie redusă la 0,01%), adică în medie 0,1-0,3 secunde, iar în cazul calculării capacității de descărcare a unui obiect direct la trimiterea datelor, ceea ce creează deja o încărcare semnificativă în baza de date, acest timp va fi de până la câteva minute.

Pentru a înțelege pe deplin funcționarea mecanismului „Planuri de schimb”, vă recomand să citiți capitolul 15 al cărții „Dezvoltarea profesională în sistemul 1C:Enterprise 8”, Gabets A.P., Goncharov D.I.

Orice implementare proprie, în opinia mea, fie va repeta mecanismul „Planuri de schimb”, fie va descărca imediat obiectul la schimbare, fie va descărca mai mult decât mecanismul „Planuri de schimb” (de exemplu, descărcați toate modificările pentru astăzi). Nu iau în considerare această problemă din cauza lipsei de experiență în implementare.

Transport

Sarcina de a transporta fișierele de la nodul master la nodul slave este redusă la toleranță maximă la erori. Nu este neobișnuit ca fișierele să fie criptate sau transmise pe un canal securizat. Pentru a transfera fișiere, este recomandabil să utilizați mai multe servicii diferite sau să pregătiți mai multe opțiuni de conectare diferite. De exemplu, metoda principală de transfer este utilizarea unui server FTP conectat printr-un tunel VPN; Cel de rezervă este un server de e-mail cu o conexiune TLS. De ce ai nevoie de un canal de rezervă cu alt serviciu? După cum arată practica, utilizarea a 2 servere FTP diferite este mai puțin fiabilă decât un server FTP și e-mail.

Recomand separarea serviciului de creare a pachetelor de actualizare de serviciul de transport, acest lucru va crește toleranța la erori a întregului complex de schimb de date. Dacă serviciul de transport de fișiere nu funcționează, serviciul de creare a pachetelor de actualizare va continua să funcționeze normal și, în anumite condiții, va reporni serviciul de transport și invers.

Implementarea mea RDB

Implementarea este complet autonomă, astfel încât toleranța maximă la erori a acționat ca o sarcină secundară. Acest lucru a dus la 2 servicii - serviciul de transport de actualizare și serviciul de import/export de date. Ambele servicii funcționează independent unul de celălalt.

După fiecare ciclu de import-export de date cu succes, a fost salvat ora ultimului schimb cu acest nod. Dacă schimbul nu a avut loc o perioadă foarte lungă de timp, atunci serviciul de transport a început să încarce fișiere pe toate canalele de comunicare disponibile, cu așteptarea ca cel de-al doilea nod să primească în continuare actualizări și să-și încarce fișierele. În cazul unor situații excepționale, sistemul însuși trimite administratorului un mesaj cu o descriere detaliată a erorii.

Pentru a reduce volumul de trafic, fișierele xml au fost împachetate în arhive zip. Sistemul acceptă două tipuri de transport - FTP și e-mail.

Există două tabele ca setări pentru filtrul de date. Una (partea tabelară a planurilor de schimb) stochează condiții pentru detalii generale (pentru fiecare obiect sistemul încearcă să găsească acest detaliu), cealaltă conține setări pentru un anumit obiect de metadate. La înregistrarea oricărui obiect, condițiile sunt căutate mai întâi după detalii generale (de exemplu, Divizia), după care sistemul încearcă să determine dacă există o regulă personală pentru acest tip de obiect folosind toate detaliile sale. Nu recomand filtrarea listelor - există o mare posibilitate de a face o greșeală, de exemplu, mai multe rânduri vor dispărea din partea tabelară a facturii, iar soldul rămas se va muta și invers.

Este important să înțelegeți sub ce utilizator de sistem vor rula serviciile, deoarece Este posibil să nu aveți suficiente drepturi pentru a crea fișiere chiar și în folderul temporar 1C. Pentru depanare, vă recomand să scrieți fiecare operațiune finalizată cu succes în jurnalul de înregistrare sau într-un fișier txt. În 1C 8.1, execuția codului serverului nu poate fi depanată.

Pentru comoditatea depanării și configurarea implementării mele, atașez procesarea „Înregistrarea modificărilor”, a cărei descriere se află în procesarea în sine.

Schema generală de funcționare a complexului de schimb de date este prezentată în Fig. 3.

Filtrarea datelor are loc într-un abonament la evenimentul „BeforeRecording” al fiecărui obiect. Nu uitați că atunci când creați imaginea inițială a nodului, datele trebuie și ele filtrate. Procedura de creare a unei imagini inițiale este destul de lungă, așa că recomand optimizarea codului acesteia la maximum (de exemplu, cacherea setărilor de filtrare).

Postfaţă

Sarcina principală este să răspunzi la o listă de întrebări:

1. De ce avem nevoie de RDB?
2. Ce nu-i place să lucrezi printr-un client RDP?
3. Unde și de ce vrem să instalăm noduri RDB?
4. Cum vor fi transportate actualizările?
5. Ce nivel de toleranță la erori va fi implementat?

Procesarea „Înregistrarea modificărilor”

Procesarea vă permite să forțați modificări ale obiectelor să fie înregistrate. Există mai multe opțiuni pentru înregistrarea modificărilor:

1. Dacă vreo metadate este verificată și nu sunt selectate obiecte și NU este setat indicatorul „Încărcare după toate valorile”, atunci NUMAI TABELUL SELECTAT ESTE ÎNREGISTRAT;
2. Dacă este setat indicatorul „Încărcare pentru toate valorile”, atunci metadatele selectate vor fi descărcate pentru toate obiectele din ciclu;
3. Dacă comutatorul este setat la modul „Încărcați numai obiectele selectate”, atunci numai obiectele selectate vor fi descărcate (de exemplu: setarea unui steag pe metadate fără a selecta obiecte este echivalentă cu activarea steagului „Încărcare după toate valorile” și comutatorul în poziția „Descărcați numai obiectele selectate”;
4. Dacă comutatorul este setat pe modul „Descarcă obiectele selectate și direct legate”, atunci obiectele selectate și acele obiecte a căror existență depinde de existența obiectului selectat vor fi descărcate (de exemplu: pentru directoare - directoare subordonate);
5. Dacă comutatorul este setat la modul „Încărcare folosind toate linkurile”, atunci TOATE obiectele care conțin o legătură către obiectul selectat vor fi descărcate.

Funcționalități suplimentare disponibile:

• Reînregistrarea obiectelor înregistrate este adesea necesară pentru depanare;
• Eliminarea celor înregistrate este adesea necesară pentru depanare;
• Imprimare modificări - imprimă o listă completă de obiecte care sunt marcate ca modificate;
• Imprimarea arborelui de configurare este doar pentru comoditatea vizualizării întregii configurații.

Pentru a crea o bază de informații distribuite, trebuie să introduceți programul în modul 1C: Enterprise. Pentru a crea noduri de baze de date distribuite, selectați din meniu: Operațiuni - Planuri de schimb. Se va deschide fereastra „Selectare obiect: Schimb plan”.

1. Luați în considerare opțiunea cu planul de schimb „Complet”.

Schimbul se va desfășura în toate organizațiile situate în baza de informații distribuite.

Să alegem planul de schimb „Complet”. Se va deschide fereastra „Plan de schimb complet”.

Completam doua intrari:

Să numim prima intrare „Nod principal”, să indicăm codul „GU”,

Să numim a doua intrare „Nod subordonat”, indicați codul „PU”.

După cum putem vedea din figură, prima intrare are o pictogramă cu un cerc verde; aceasta este pictograma „Nodul principal”.

Pentru a crea o copie a bazei de informații „Nodul principal”, faceți clic pe „Nodul sclav” și faceți clic pe pictograma „Creați imaginea inițială”. Aceasta va fi baza de informații „Nodul subordonat”.

Se va deschide fereastra „Crearea unei imagini inițiale de securitate a informațiilor”, selectați „Pe acest computer sau pe un computer din rețeaua locală”, faceți clic pe „Următorul”.

În câmpul „Infobase Directory”, selectați locația în care va fi instalată copia „Main Node” și faceți clic pe „Finish”.

După crearea bazei de informații „Nod subordonat”, va apărea următorul mesaj:

Faceți clic pe „Ok”.

Adăugați baza de informații „Subordinate Node” la „1C: Enterprise”. Mergem la baza de date subordonată în modul „1C: Enterprise”. Să deschidem: Operațiuni - Planuri de schimb. Se va deschide fereastra „Selectare obiect: Schimb plan”. Să alegem planul de schimb „Complet”. Se va deschide fereastra „Plan de schimb complet”. Vedem că pictograma „Main Node” este portocalie, ceea ce înseamnă că acest nod este nodul principal pentru baza de informații în care ne aflăm.

Facem următoarele setări atât în ​​nodurile Master, cât și în nodurile Slave:

1. Adăugați un prefix pentru baza de informații distribuită.

Acest lucru se face astfel încât să nu existe conflicte în numerele și codurile documentelor și directoarelor create în două baze de date, astfel încât în ​​fiecare bază de date indicăm un prefix care va fi adăugat numerelor de document și codurilor de director. Deschideți: Instrumente - Setări program - fila „Schimb de date”. În câmpul „Prefix de nod pentru o bază de informații distribuită:”, introduceți „PU” în baza de date subordonată și „GU” în baza de date principală.

2. Adăugați o setare pentru schimbul de date între noduri:

Deschidere: Serviciu - Baza de informații distribuite (DIB) - Configurați nodurile RIB. Se va deschide fereastra „Setări de schimb de date”.

Faceți clic pe „Adăugați” și se va deschide fereastra „Setări de schimb de date”. Introduceți „Numele” setării dvs.

Un nod va apărea automat în câmpul „Nod”, pentru „Nodul principal” va fi un „nod slave”, pentru „nodul sclav” va fi un „nod principal”.

În câmpul „Director”, selectați folderul în care vor fi trimise datele de schimb; cel mai bine este să specificați un director pentru bazele de date principale și slave.

În câmpul „Exchange Type”, configurăm transferul de date între baze de date: printr-un fișier sau o resursă FTP. Să alegem, de exemplu, „partajarea printr-o resursă de fișier”.

Nu modificăm nimic în câmpurile rămase.

Faceți clic pe „Ok”. Vedem că a apărut o setare.

3. Pentru a face schimb de date facem următoarele:

Mai întâi, în baza de date în care au fost efectuate modificările, faceți clic pe pictograma „Schimb în funcție de setarea curentă”, așa cum se arată în figură.

După încărcare, va apărea fereastra cu rezultatul încărcării.

Apoi, în baza de date în care doriți să transferați modificările, faceți clic pe pictograma „Schimb în funcție de setarea curentă” și datele vor merge în baza de date dorită.

2. Luați în considerare opțiunea cu planul de schimb „După organizație”.

Schimbul se va desfășura între organizații selectate situate într-o bază de informații distribuite.

Pentru a crea noduri ale unei baze de date distribuite, selectați din meniu: Operațiuni - Schimb planuri. Se va deschide fereastra „Selectare obiect: Schimb plan”.

Să alegem planul de schimb „După organizație”. Se va deschide fereastra „Plan de schimb după organizație”.

Completam doua intrari:

Să numim prima intrare „Nod principal”, să indicăm codul „GU”, vedem diferența față de „Planul de schimb: Complet”, a apărut un tabel în care indicăm organizațiile pentru care va avea loc schimbul.

Să numim a doua intrare „Nod subordonat”, indicați codul „PU”, indicați organizația.

În toate celelalte privințe, configurația este absolut aceeași ca în cazul „Planului de schimb: complet”.