Cum să creați utilizatori pe nodul nervului. Baza de informații distribuite: Noțiuni de bază. Principiile de bază de funcționare ale RIB
Adesea, în practică, există situații în care diferite divizii sau ramuri sunt localizate geografic în locuri diferite. În același timp, datele introduse în program în departamentele aflate la distanță trebuie să ajungă cumva la sediul central, astfel încât evidențele generale să fie păstrate.
În prezent, această problemă este adesea rezolvată oferind angajaților la distanță geografică acces de la distanță la o bază de date comună. Se poate realiza prin publicarea bazei de date pe un server web, printr-un desktop la distanță etc.
Cu toate acestea, situațiile nu sunt neobișnuite când pur și simplu nu există Internet într-un birou îndepărtat din punct de vedere geografic sau nu este suficient de stabil pentru a funcționa într-o bază de date comună de informații. În acest scop, 1C are un mecanism pentru configurarea unei baze de date distribuite.
Mai simplu spus, sediul central este locul în care se află baza principală. Departamentul de la distanță folosește un subordonat. Pot exista mai multe astfel de baze de sclavi. Ca rezultat, o astfel de bază de date distribuită este unită într-una singură prin sincronizare. Se poate face fie automat conform unui program, fie manual.
În acest articol ne vom uita la configurarea unei baze de date distribuite pentru 1C: Contabilitate 3.0. În ciuda acestui fapt, instrucțiunile sunt potrivite pentru majoritatea celorlalte configurații 1C 8.3.
Notă că toate modificările necesare de configurare ar trebui făcute numai în baza de date RIB principală. În timpul sincronizării, aceste modificări vor fi transmise tuturor bazelor de date slave și vor intra în vigoare.
Baza principală de informații
Când utilizați o bază de date distribuită, setările principale cad în baza de date principală. Acestea trebuie făcute în secțiunea „Administrare”, așa cum se arată în imaginea de mai jos.
În fereastra care se deschide, bifați imediat caseta de selectare „Sincronizare datelor”. În partea de jos, specificați prefixul bazei de date principale (actuală). Poate consta din cel mult două caractere. În cazul nostru, prefixul va fi „BG”, deoarece ne referim la acest RIB 1C este „Contabilitatea principală”.
Acum puteți începe configurarea sincronizării în sine, și anume, specificând cu ce bază de date (sau baze de date) vor fi schimbate datele. Pentru a face acest lucru, urmați hyperlinkul „Setări de sincronizare a datelor”. Va fi disponibil pentru navigare numai dacă caseta de selectare din stânga este bifată.
În fereastra care se deschide, selectați „Complet...” din meniu. Ne va permite să specificăm orice bază de informații 1C pentru sincronizare.
În prima fereastră pentru conectarea unei baze de date subordonate, care se află într-un birou îndepărtat geografic, bifați caseta că conexiunea se va face printr-un director local sau de rețea. În cazul nostru este „D:\DB\InfoBase”. De asemenea, vom verifica în prealabil dacă îi puteți scrie.
Asigurați-vă că specificați prefixe diferite pentru diferite baze de date. Faptul este că la sincronizarea datelor, datelor supraîncărcate din fiecare bază de date li se atribuie propriul prefix. Dacă sunt duplicate, munca va fi incorectă, așa că programul nu vă va oferi această oportunitate.
Când programul vă solicită să creați o imagine de pornire, selectați această opțiune. Această procedură va dura ceva timp, după care salvați-o pe computer cu numele „1Cv8.1CD”.
Sincronizarea în sine se poate face fie automat conform unui program pe care îl puteți configura singur, fie manual. În cel de-al doilea caz, faceți clic pe butonul „Sincronizare” la un moment convenabil pentru dvs.
Nod slave RIB
Numărul de setări efectuate în baza de date slave este semnificativ mai mic. În aceeași secțiune, setați indicatorul „Sincronizare date” și făcând clic pe linkul corespunzător, butonul „Sincronizare” va fi disponibil.
În exemplul nostru, două articole de articole au fost adăugate în baza de date principală: „Grânză” și „Placă”. După sincronizare, au ajuns în baza de date slave. După cum puteți vedea în imaginea de mai jos, li s-a dat prefixul „BG”. Celelalte două poziții („strung” și „palet”) li se atribuie prefixul „BP”, deoarece au fost create direct în baza de date subordonată.
Notă că numerotarea elementelor în cazul nostru este continuă, dar numai în cadrul aceluiași prefix.
Tehnologia bazelor de informații distribuite (RIB) vă permite să creați un sistem distribuit geografic bazat pe configurații 1C Enterprise. Acest lucru vă permite să aveți un spațiu de informare comun chiar și cu acele departamente care nu au un canal de comunicare fiabil, combinând autonomia ridicată a nodurilor cu capacitatea de a schimba rapid informații. În articolele noastre ne vom uita la caracteristicile și implementarea practică a acestui mecanism pe platforma 8.2
În primul rând, să ne întrebăm: de ce schimbul automat? Tehnologiile moderne, combinate cu internetul ieftin și rapid, fac posibilă organizarea lucrului de la distanță fără dificultăți. Alegerea metodelor este la fel de largă ca întotdeauna: RDP, clienți subțiri și web, conectarea rețelelor folosind VPN - sunt multe de gândit. Cu toate acestea, toate aceste metode au un dezavantaj semnificativ - o dependență puternică de calitatea canalului de comunicare.
Chiar și cu funcționarea ideală a furnizorului local, este imposibil să se garanteze disponibilitatea 100% a canalului de comunicare. Problemele cu furnizorul de backbone, lipsa sursei de alimentare, deteriorarea fizică a liniei de comunicație și mulți alți factori fac această sarcină de netrecut. În același timp, inaccesibilitatea bazei de informații la un depozit la distanță sau un magazin de vânzare cu amănuntul duce la pierderi destul de semnificative. Și, în sfârșit, să nu uităm că există locuri (de exemplu, zone industriale de la periferia orașelor) în care furnizarea unui canal de comunicare de înaltă calitate este costisitoare și/sau problematică.
Mecanismul RIB vă permite să scăpați de aceste neajunsuri fiecare departament are propria sa copie a bazei de informații cu care puteți lucra autonom chiar și în absența completă a comunicării cu lumea exterioară. Iar cantitatea mică de informații transmise vă permite să utilizați orice canal de comunicare pentru schimb, inclusiv internetul mobil.
RIB pe platforma 8.2 nu este ceva fundamental nou, reprezentând o dezvoltare ulterioară a platformei RIB 7.7, doar că acum această tehnologie a devenit mai accesibilă și mai simplă. Spre deosebire de componenta RIB, care trebuia achiziționată separat, RIB este parte integrantă a multor configurații standard și funcționează în întregime în modul utilizator, permițându-vă să faceți fără Configurator chiar și în etapa de configurare.
În acest moment ar fi timpul să trecem la partea practică, dar va trebui să mai facem o digresiune. Cert este că trecerea la platforma 8.2, care pare să se fi produs deja, a dus, de fapt, la apariția a două tipuri de configurații: bazate pe o aplicație gestionată, „native” pentru platforma 8.2, și adaptată de la 8.1, continuând să utilizeze tehnologii și mecanisme învechite. Deoarece o parte semnificativă a configurațiilor (Contabilitatea întreprinderii, Salarizarea și Managementul resurselor umane) sunt adaptate sau tranzitorii, acestea nu pot fi reduse, astfel încât prima parte a articolului nostru va fi dedicată acestor configurații (în esență platforma 8.1), în timp ce în a doua. vom examina configurarea schimbului automat pentru configurații bazate pe o aplicație gestionată (platforma 8.2).
Să luăm în considerare o sarcină practică: configurarea schimbului automat prin FTP pentru configurația Enterprise Accounting 2.0. În ciuda faptului că RIB vă permite să faceți schimb prin e-mail sau partajări de fișiere, vă recomandăm să utilizați FTP ca cea mai simplă și mai fiabilă metodă de comunicare. Puteți citi cum să vă configurați propriul server FTP sau puteți utiliza serviciul FTP al oricărui furnizor de găzduire.
În primul rând, trebuie să configuram nodurile de schimb. Pentru a face acest lucru, lansați configurația cu drepturi de administrator și selectați Tranzacții - Planuri de schimb.
În lista care apare, selectați Deplin plan sau După organizare, dacă înregistrările sunt păstrate pentru mai multe companii într-o bază de date și schimbul trebuie făcut doar pentru una dintre ele. În fereastra care se deschide, există deja un nod - cel central, trebuie să îl edităm indicând codul și numele.
Apoi vom crea un alt nod pentru ramură, umplându-l în același mod (pentru a adăuga, faceți clic pe cercul verde cu un plus). Următorul pas este crearea unei imagini inițiale pentru acest nod, care este o bază de informații gata făcută în modul fișier. Pentru a face acest lucru, faceți clic dreapta pe nodul dorit și selectați din lista derulantă Creați o imagine de pornire.
Acum să trecem mai departe Serviciu - Baza de informații distribuite (DIB) - Configurați nodurile RIB.
În fereastra care se deschide, faceți clic pe butonul Adăugași configurați un nou schimb specificând gazda la distanță, tipul schimbului (prin FTP) și parametrii de conectare la server.
Marcaj Schimb automat vă permite să stabiliți un program de schimb, schimb pe evenimente (început și sfârșit de lucru etc.), aceste setări sunt făcute pentru utilizatorul în numele căruia se va efectua schimbul, deci asigurați-vă că are drepturi de schimb de date.
Nu uitați să specificați prefixul nodului pentru numerotarea documentelor (în caz contrar veți primi documente diferite cu aceleași numere) în Instrumente - Setări program aici puteți configura și alți parametri de schimb; În aceeași filă, ar trebui să selectați un utilizator pentru a efectua sarcini de schimb, dacă nu faceți acest lucru, programul nu va funcționa. Rețineți că schimbul se va face numai dacă utilizatorul este autentificat în program.
Aceasta completează configurarea nodului central acum trebuie să faceți setări similare pentru nodul periferic, conectând imaginea inițială ca un sistem de securitate a informațiilor existent. După care puteți începe să faceți schimb de date. Pentru a controla ar trebui să utilizați Monitor de comunicare, vă permite nu numai să monitorizați succesul încărcării/descărcării, ci arată și eventualele coliziuni apărute sau mișcările întârziate (dacă utilizatorul care a efectuat schimbul nu are suficiente drepturi pentru a efectua orice acțiuni în baza de date). Prezența acestui instrument vă permite să rezolvați rapid și eficient diferite tipuri de probleme care apar în timpul schimbului automat.
În acest moment, configurarea schimbului poate fi considerată completă și puteți începe să lucrați în modul distribuit. Merită să ne oprim separat la actualizarea sau efectuarea de modificări ale configurației. Aceste acțiuni sunt disponibile numai pe nodul central, toate modificările efectuate vor fi propagate automat către nodurile periferice în timpul următorului schimb. Pentru a face modificări automat, baza de date periferică trebuie să fie în modul exclusiv, altfel va trebui să rulați Configurator si executa Actualizarea configurației bazei de date manual.
25 octombrie 2016
Nu există o mare diferență între configurarea și suportul RIB pentru 2 noduri și pentru 10, dar atunci când numărul de puncte la distanță depășește o sută, trebuie rezolvate probleme complet diferite.
Date inițiale:
Configurație: Retail 2.2
Platforma 1C: 8.3.7.1970
Durata proiectului: un an.
Arhitectură:
În primul rând, ne-am hotărât asupra schemei RIB. S-a decis să se concentreze pe schema „stea” cât mai mult timp posibil; când se atinge limitările tehnologice – un fulg de zăpadă.
Limitări:
- 2 GB RAM
- 1 procesor fizic
Dintre toate cele de mai sus, principalul lucru enervant este limitarea dimensiunii maxime a bazei de date.
Dar asta înseamnă doar că trebuie să organizați cu atenție procedura de curățare a acesteia de datele învechite de pe site.
Un server fizic separat este alocat pentru serverul 1C și MS SQL. Acesta va suporta sarcina principală a schimburilor și operațiunilor pe termen lung.
Calculatoarele clientului final nu sunt înlocuite, deoarece vor funcționa cu clientul subțire și sarcina pe acestea va fi minimă.
.
setări de bază
De pe vremea UT 10.3, timp în care am avut primul meu proiect de implementare a RIB pentru 60 de noduri, desigur, „a trecut multă apă pe sub pod”.
1C nu a stat pe loc. Retail 2.2 ia acum în considerare necesitatea încărcării selective a datelor.
Doar informațiile care sunt relevante pentru aceasta vor fi încărcate în baza de date a magazinului:
- Toate cărțile de referință (cu excepția celor de specialitate)
- Documente pentru acest magazin
O altă întrebare este că într-un fel sau altul, adăugarea unui nod la baza de date înseamnă adăugarea unei alte intrări la tabelul de înregistrare pentru fiecare element comun atunci când este scris.
1) Este necesar să se împartă în scenarii de sincronizare separate pentru încărcare și descărcare
Ideea este că descărcarea durează mult timp și implică blocare, în timp ce încărcarea este destul de simplă. În același timp, se întâmplă adesea să avem nevoie să primim rapid date de la punctele de vânzare cu amănuntul, în timp ce le oferim doar de câteva ori pe zi.
2) Identificați depozitele de probleme și eliminați-le din scenariul general de sincronizare. Pot exista descărcări mari asupra lor - acest lucru va încetini întregul schimb, inclusiv alte noduri. Odată ce problemele sunt rezolvate, acestea sunt adăugate înapoi.
3) Creați mai multe scripturi pentru trimiterea și primirea datelor. Dar principalul lucru aici este să prindeți echilibrul corect al cantității lor.
(din versiunea 8.1).
În consecință, paralelismul în descărcarea RIB este limitat. În practică, se dovedește că rulează 2-3 scripturi în paralel.
Ce trebuia îmbunătățit
Cea mai importantă problemă din logica standard a 1C RIB sunt actualizările
O altă problemă a schimbului sunt registrele de informații. Încărcarea fiecărei înregistrări a registrului de informații în XML creează un nod XML separat cu elemente de serviciu etc. În plus, funcția „SelectChanges()” pentru un registru de informații în care există 100 de înregistrări va primi un tabel rezultat de 100 de rânduri, la în același timp, dacă acest director A cu 100 de rânduri va avea doar o singură intrare selectată în secțiunea sa tabelară. Și acesta este momentul blocării exclusive. Deci, dacă există o mulțime de înregistrări în computer care sunt înregistrate în mod regulat pentru a fi schimbate cu alte magazine, atunci este, desigur, mai corect să prezentați acest lucru sub forma unui director cu o parte tabelară, care, în cazuri extreme, atunci când înregistrați , pot forma rânduri din același registru. Oricum, .
Un alt detaliu important - Pentru ce? Există deja aproape 3 milioane de carduri de reducere pentru a lucra cu ele. Dacă continuați să transferați carduri de reducere în toate magazinele, acest lucru va crește semnificativ schimburile și, de asemenea, poate duce la depășirea volumului de bază de 10 GB.
Unele dintre mecanisme sunt implementate online prin contactarea bazei de date centrală: solduri în alte magazine, returnarea unei chitanțe din alt magazin, verificarea valabilității unui certificat cadou.
Replicare
Crearea unui nod RIB inițial într-o manieră regulată ar face replicarea imposibilă, în principiu.
Prin urmare, un nou nod este creat după cum urmează:
2) Această bază de date face schimb de toate datele generale din RIB, dar nu primește (documente) de specialitate
5) Baza pentru magazin este gata.
Un pachet software gata făcut este implementat pe server, deci nu durează mult timp. Apoi baza de date nou creată este încărcată pe server și este gata să fie trimisă în magazin.
Beneficiile unui client subțire
Două avantaje semnificative ale Retail 2.2 (Thin Client) care „încălzeau sufletul”:
Suport și actualizări
1) Actualizați manual din magazine (nu foarte corect, este posibil să nu fie primite modificări, vor fi apeluri și probleme) - așa era și înainte
3) Scrieți un script *.cmd sau 1C pentru actualizare sau luați unul gata făcut. După cum arată practica, o astfel de soluție este întotdeauna nesigură (instabilă) și va fi posibil să se introducă puține funcționalități în ea.
Care au fost sarcinile noastre:
2) La actualizare este posibilă interacțiunea interactivă cu utilizatorul (mesaje, confirmare, bară de progres).
Functii principale:
4) Verificarea statutului agenților
5) Actualizează rapoarte
6) backup
De exemplu, așa arată mesajul de eroare după o actualizare:
Astfel, proiectul a avut șanse mari să fie finalizat cu succes. Cel puțin la jumătatea zborului zborul este normal.
Dacă ajungem la alte soluții care pot părea interesante, voi scrie separat
P.S. și cel mai important: planificarea corectă a sprijinului suplimentar este unul dintre factorii cheie pentru succesul în continuare a unor astfel de proiecte. :)
25 octombrie 2016
Nu există o mare diferență între configurarea și suportul RIB pentru 2 noduri și pentru 10, dar atunci când numărul de puncte la distanță depășește o sută, trebuie rezolvate probleme complet diferite.
Deci, datele inițiale:
Configurație: Retail 2.2
Platforma 1C: 8.3.7.1970
Numărul estimat de noduri la sfârșitul proiectului: 200
Resurse de echipamente în centru: fără restricții semnificative
Echipamentul la punct: o problemă discutată.
Durata proiectului: un an.
Arhitectură:
În primul rând, ne-am hotărât asupra schemei RIB. S-a decis să se concentreze pe schema „stea”, înainte
La punctele de vânzare cu amănuntul, este utilizată o versiune client-server de lucru, cu un server dedicat care rulează sistemul de operare Windows.
Serverul 1C va fi folosit în versiunea „Server 1C MINI” https://1c.ru/news/info.jsp?id=17577
Server DBMS - MS SQL Express 2008 R2.
SQL Express 2008 R2 este cea mai recentă versiune actuală a acestei linii SQL Server.
Limitări:
2 GB RAM
- 1 procesor fizic
- Dimensiunea maximă a bazei de date de 10 GB
Dintre toate cele de mai sus, cel mai enervant lucru, desigur, este limitarea dimensiunii maxime a bazei de date. Dar, de fapt, acest lucru înseamnă doar că va fi necesar să se organizeze cu atenție procedura de curățare a acesteia de datele învechite de pe site.
Un server separat este alocat pentru serverul 1C și MS SQL. Acesta va suporta sarcina principală a schimburilor și tranzacțiilor.
Calculatoarele clientului final nu sunt înlocuite, deoarece vor funcționa cu un client subțire și sarcina de pe partea de jos va fi minimă.
Serverul din magazin este pur și simplu un computer puternic. Dar o condiție prealabilă este prezența unui disc SSD - pe care se află bazele de date MS SQL.
Serverul va oferi, de asemenea, posibilitatea de a efectua operațiuni de rutină pe timp de noapte și acces la baza de date a magazinului fără întreruperi de la lucru.
setări de bază
De pe vremea lui UT 10.3, timp în care am avut primul meu proiect de implementare a RIB pentru 60 de noduri, desigur, „a zburat multă apă pe sub pod”. 1C nu a stat pe loc. Retail 2.2 ia acum în considerare necesitatea încărcării selective a datelor.
Doar informațiile care sunt relevante pentru magazin vor fi încărcate în baza de date a magazinului:
- Toate directoarele (cu excepția unora)
- Documente pentru acest magazin
Înregistrarea datelor are loc conform regulilor de înregistrare, tot ceea ce poate fi stocat în cache. Nu există încetiniri semnificative în timpul înregistrării.
O altă întrebare este că într-un fel sau altul, adăugarea unui nod la baza de date înseamnă adăugarea unei alte înregistrări pentru fiecare element comun pentru toate bazele de date.
Nu există nimic specific în configurarea încărcării în sine. Există câteva nuanțe la configurarea scenariilor de sincronizare:
1) Este necesar să se separe încărcarea și încărcarea în scenarii de sincronizare separate
Ideea este că descărcarea durează mult și implică blocare, în timp ce încărcarea este destul de fără probleme. În același timp, se întâmplă adesea să avem nevoie să primim rapid date de la punctele de vânzare cu amănuntul, în timp ce le oferim doar de câteva ori pe zi.
2) Identificați depozitele de probleme și eliminați-le din scenariul general de sincronizare. Pot exista descărcări mari asupra lor - acest lucru va încetini întregul schimb, inclusiv alte noduri
3) Creați niște scripturi de trimitere și primire pentru a trimite și primi date. Dar principalul lucru aici este echilibrul.
Unele lucruri din 1C nu se schimbă. Aceeași metodă „SelectChanges” poate fi executată numai secvenţial(din versiunea 8.1).
În consecință, paralelismul în descărcarea RIB este limitat. În practică, ajungi să încarci 2-3 scripturi o dată.
În ceea ce privește scenariul de recepție, aici este posibil un paralelism mult mai mare, dacă este necesar, desigur.
Ce trebuia îmbunătățit
Desigur, este trist și trist, dar a trebuit să interferez complet cu BSP. Cea mai importantă problemă din logica standard 1C sunt actualizările. După actualizare, apare o fereastră similară cu aceasta:
Toate acestea se întâmplă în modul monopol. Printre altele, sistemul va încerca în continuare să facă un schimb după actualizarea în modul exclusiv. Nu este greu de ghicit unde duc toate acestea.
În toată această perioadă de timp, magazinul nu poate funcționa, sunt clienți la casă, iar compania pierde bani.
O altă problemă a schimbului sunt registrele de informații. Încărcarea fiecărei intrări din registrul de informații în XML creează un nod XML separat cu elemente de serviciu și tot ce urmează. În plus, funcția „selectează modificări” pentru un registru de informații în care există 100 de înregistrări, tabelul rezultat va conține 100 de rânduri, în același timp, dacă acesta este un director cu 100 de rânduri, va fi selectată o singură înregistrare în secțiunea de masă. Deci, dacă există o mulțime de înregistrări în computer care sunt înregistrate în mod regulat pentru a fi schimbate cu alte magazine, atunci este, desigur, mai corect să prezentați acest lucru sub forma unui director cu o parte tabelară, care, în cazuri extreme, atunci când înregistrați , poate genera înregistrări ale aceluiași registru. Oricum, registrele de informații în schimburi sunt rele.
Un alt detaliu important - Cardurile de reducere sunt complet excluse de la schimb, iar doar angajații unui anumit magazin sunt excluși de la schimb. Pentru ce? Există deja aproape 3 milioane de carduri de reducere pentru a lucra cu ele. Dacă continuați să transferați carduri de reducere în toate magazinele, acest lucru va crește schimburile de mai multe ori, în plus, poate duce la depășirea volumului de bază de 3GB.
Unele dintre mecanisme sunt implementate online prin contactarea bazei de date centrală: solduri în alte magazine, returnarea unei chitanțe din alt magazin, verificarea valabilității unui certificat cadou.
Replicare
Desigur, replicarea se realizează într-un ritm accelerat.
Crearea nodului RIB inițial într-un mod regulat ar face, desigur, imposibilă replicarea.
Prin urmare, un nou nod este creat după cum urmează:
1) Există o bază de date separată cu un magazin fals
2) Această bază de date schimbă toate datele generale din RIB, dar nu primește de specialitate
3) Când vrem să creăm o nouă bază de date, pur și simplu o copiem pe aceasta
4) Apoi setăm setările - magazin, prefix etc.
5) Baza pentru magazin este gata.
Un pachet software gata făcut este implementat pe server, deci nu durează mult timp. Apoi baza de date nou creată de magazine este încărcată pe server și este gata să fie trimisă la magazin.
Beneficiile unui client subțire
două avantaje semnificative care „încălzeau sufletul”.
1) Nu este nevoie să schimbați întregul parc de calculatoare la punctele de vânzare cu amănuntul. 90% din operațiuni sunt efectuate pe server, iar serverul este adus acolo cu un „calculator relativ puternic”
2) Echipamentul are capacitatea de a refuza să lucreze, acest lucru se întâmplă adesea cu echipamentele nou instalate sau deja uzate.
În acest caz, acțiunile sunt acum extrem de simple - magazinul trece la lucrul în baza de date centrală.
Acest proces nu durează mai mult de 5-10 minute, astfel încât tranzacționarea nu este întreruptă chiar dacă există probleme semnificative cu echipamentul.
Suport și actualizări
În cele din urmă am ajuns la punctul cel mai interesant - cum să menținem și să actualizăm toate acestea?
Pentru noi, actualizările sunt, de asemenea, o dilemă de mult timp:
1) Actualizați manual din magazine (nu foarte corect, este posibil să nu fie primite modificări, vor apărea apeluri și probleme)
2) Actualizați folosind suport tehnic (nu există atât de multe resurse)
3) Scrieți *.cmd pentru actualizare sau luați unul gata făcut. După cum arată practica, o astfel de soluție este întotdeauna nesigură (instabilă) și există puține funcționalități în ea.
Care au fost sarcinile noastre:
1) Actualizarea trebuie să aibă loc în mai multe moduri și să fie gestionată centralizat
2) La actualizare, interacțiunea interactivă cu utilizatorul este posibilă.
3) Trebuie primite rapoarte privind starea actualizării și erorile
4) Trebuie să existe o copie de rezervă
5) Sistemul de actualizare ar trebui să se poată actualiza fără probleme.
6) Sistemul ar trebui să fie extensibil fără probleme.
Desigur, problemele au depășit cu mult lista celor rezolvabile prin metode simple. Pentru că nu ne putem lipsi de automatizare cu atât de multe puncte finale și nu am găsit nimic mai mult sau mai puțin gata făcut cu funcționalitate similară
A trebuit să încep să dezvolt software, care în cele din urmă a căpătat numele MU (MagicUpdater).
Functii principale:
1) Actualizare dinamică a bazei de date (comandă sau programată)
2) Actualizare statică a bazei de date (comandă sau programată)
3) agenți automati pe computerele finale atunci când sunt modificați
4) Verificarea statutului agenților
5) Actualizează rapoarte
6) backup
7) Acțiuni administrative cu server 1C și MS SQL
8) Închiderea tuturor aplicațiilor client 1C de pe computerele din rețea
9) Actualizare statică cu acceptare la casă principală
10) Afișarea descrierilor modificărilor după actualizare
11) Stabilirea ordinii acțiunilor
12) Efectuați toate aceste acțiuni într-un program
Scheme aproximative de interacțiune:
Unde MU Agent este un serviciu care este instalat și configurat în magazin. De fapt, ea primește o comandă de la centru pentru a îndeplini anumite sarcini.
MU Server - Serverul care primește toate cererile către sistem.
Monitorul MU - ceea ce văd angajații de asistență tehnică obișnuită - este folosit pentru a vizualiza jurnalele și a seta sarcini pentru actualizare sau altele.
A iesit destul de bine, dupa parerea mea. Acum actualizările au loc aproape automat.
Așa arată, de exemplu, mesajul de eroare după actualizare, totul rămâne în centru, în așteptare.
Și așa trimitem comenzi către computerele client
Aplicațiile cu siguranță nu sunt 1C, dar cu un set destul de decent de capabilități de interfață. De exemplu, așa arată selecția după dată:
Acum suntem pregătiți pentru replicare ulterioară. Planificarea corectă a sprijinului suplimentar este unul dintre factorii cheie pentru succesul în continuare a unor astfel de proiecte.
Instrucțiuni pentru crearea și configurarea bazelor de date distribuite folosind componenta URDB (URIB).
Componenta URDB (Distributed Database Management) este utilizată pentru a face schimb de informații între două baze de date 1C identice. Dacă configurațiile sunt diferite, atunci îl puteți folosi și, acesta este scris în altul. Pentru ca componenta să funcționeze, trebuie să aveți fișierul DistrDB.dll în folderul BIN al programului 1C: Enterprise.
Să ne uităm la pașii pentru a crea baze de date distribuite. De exemplu, avem o bază de lucru în directorul D:\base1. Este necesar să îl facă central și să creeze o bază periferică.
1. Creați un director D:\base2 pentru baza de date periferică.
2. În directoarele D:\base1 și D:\base2, creați folderele CP și PC (utilizați litere latine).
3. Lansați configuratorul central de baze de date (D:\base1) și selectați Meniu - Administrare - Securitate informații distribuite - Management.
4. Faceți clic pe butonul „Central Information Security”, în fereastra care apare, introduceți codul și numele bazei de date. Este mai bine să folosiți cifre sau litere latine pentru cod. Introduceți, de exemplu, 001 și „Bază centrală”, confirmați apăsând butonul „OK”.
5. Faceți clic pe butonul „Securitate nouă a informațiilor periferice” pentru a crea o bază de date periferice. Introducem parametrii pentru acesta: 002 și „Bază periferică 1”.
6. Folosiți cursorul pentru a selecta baza „Bază periferică 1” și apăsați butonul „Configurare”. schimb auto”. În setări, schimbați modul manual în automat. Fii atent, asta este important.
7. Folosind cursorul, selectați baza de date „Bază periferică 1” și apăsați butonul „Încărcare date”, apoi butonul „OK”. Ca urmare a încărcării, va apărea fișierul D:\base1\CP\020.zip.
8. Lansați 1C în modul configurator, adăugați o nouă bază de date „Peripheral database 1” în fereastra de lansare 1C, specificați directorul creat anterior D:\base2 pentru aceasta.
9. Selectați Meniu - Administrare - Securitate informații distribuite - Management. La întrebarea adresată „Baza de informații nu a fost găsită. Doriți să încărcați date?" Faceți clic pe butonul „Da” și specificați numele fișierului „D:\base1\CP\020.zip”, faceți clic pe butonul „OK”. După ce descărcarea este completă, procesul de creare a unei baze de date periferice poate fi considerat finalizat.
În și, de asemenea, metodele de creare a unei baze de date periferice prin restaurarea unei copii a bazei de date centrale dintr-o copie de rezervă sau atașarea fișierelor unei copii a bazei de date centrale pentru format SQL și executarea scriptului sunt date. Acest lucru va fi util pentru volume mari de date, atunci când încărcările și descărcările durează ore întregi sau sunt complet nerealiste.
Instrucțiuni pentru schimbul între bazele de date distribuite folosind componenta URDB (URIB).
Să luăm în considerare un exemplu simplificat, vom efectua schimbul manual lansând configuratorul. Puteți utiliza modul batch al configuratorului, puteți utiliza e-mail, ftp și copierea automată a fișierelor pentru a livra pachete de schimb.
Pentru a efectua schimbul, trebuie să selectați Meniu - Administrare - Securitate informații distribuite - Schimb automat. Dacă schimbul este automat (a se vedea punctul 6 din instrucțiunile anterioare), atunci totul va funcționa.
1. Deci, schimbăm sau creăm niște obiecte care migrează în baza de date periferică. Regulile de migrare a obiectelor sunt setate în fila „Migrare” din proprietățile obiectului (vezi arborele de obiecte din configurator).
2. Lansați configuratorul central de baze de date, selectați Meniu - Administrare - Securitate informații distribuite - Schimb automat, faceți clic pe butonul „Run”.
3. Mutați fișierul rezultat D:\base1\CP\020.zip în folderul D:\base2\CP\
4. Schimbăm unele obiecte din baza de date periferică. De preferat nu cele care au fost modificate înainte în baza de date centrală, pentru că baza de date centrală are prioritate pentru modificările obiectelor în timpul schimbului.
5. Lansați configuratorul bazei de date periferice, selectați Meniu - Administrare - Securitate informații distribuite - Schimb automat, faceți clic pe butonul „Run”.
6. Ca rezultat al schimbului automat, ar trebui să avem modificări care vin din baza de date centrală. Ar trebui să avem și un fișier de transferat în baza de date centrală D:\base2\PC\021.zip
7. Copiați fișierul D:\base2\PC\021.zip în folderul D:\base1\PC
8. Repetați punctul 2. Ca urmare, modificările primite din baza de date periferică vor apărea în baza de date centrală.
Deci, principiul general al schimbului: execuția alternativă a schimbului automat cu deplasarea simultană a fișierelor (pachete de schimb) din folderul PC al unei baze de date în folderul PC al altei baze de date și din folderul CP al unei baze de date în folderul CP al altă bază de date.
Modificările de configurare se fac numai în baza de date centrală. La schimbarea configurației, este necesar să se efectueze schimbul în baze de date periferice în modul exclusiv. Pentru a procesa cu succes pachetele din bazele de date periferice în baza de date centrală, configurația trebuie să fie încărcată în bazele de date periferice. Dacă sunteți confuz, este în regulă, pachetul respins de baza de date centrală va fi descărcat din nou.
RIB este o bază de informații distribuite, care este o structură arborescentă, ale cărei ramuri sunt baze de date individuale 1C Enterprise implementate. Aceste baze de date sunt numite noduri de bază de informații distribuite (denumite în continuare pur și simplu noduri). Între aceste noduri se formează un schimb de informații pentru a sincroniza toate nodurile (configurații și baze de date).
Mecanismul principal este un mecanism de schimb cu unele capacități distinctive și universale. Principala diferență este că mecanismul de schimb RIB este mai specializat și mai îngust, în timp ce schimburile universale oferă utilizatorului o gamă mai largă de oportunități.
Principiile de bază de funcționare ale RIB
Este posibilă modificarea structurii de configurare numai în nodul rădăcină principal al bazei de informații distribuite. Aceste modificări sunt apoi propagate ierarhic la nodurile subordonate. Astfel, aceasta oferă un spațiu de structură de configurare unic în toate nodurile RIB.
Datele pot fi modificate în oricare dintre noduri, care la rândul său este distribuit tuturor celorlalte noduri. Mai mult, aceste date nu trebuie neapărat transferate altor participanți la sistem și este posibil ca identitatea lor completă să nu fie păstrată. Dezvoltatorul poate personaliza compoziția datelor care participă la schimbul cu alți participanți RIB, după cum dorește. Mai mult, setările pot fi făcute nu numai la nivelul metadatelor de configurare, ci și la nivelul elementelor individuale, asupra cărora pot fi aplicate selecții speciale.
După cum sa menționat mai sus, mecanismul RIB se realizează prin utilizarea planurilor de schimb. dar pentru ca un anumit plan să poată fi utilizat în această structură ierarhică, proprietatea sa „Bază de informații distribuită” trebuie să fie activată.
Toate datele sunt transmise către RIB prin mesaje. Conținutul acestor mesaje este clar reglementat și nu poate fi arbitrar, ca în mecanismul de schimb universal. Datele sunt plasate într-un mesaj utilizând principiul serializării XML. Pe lângă aceste modificări de date, mesajul conține și informații despre modificările de configurare, precum și o anumită cantitate de informații despre servicii. Modificările sunt înregistrate și plasate în mesajul de schimb complet automat. Nici utilizatorul, nici dezvoltatorul nu pot influența acest lucru.
Recepția și generarea mesajelor de schimb în RIB sunt setate cu o singură comandă
Schimb de planuri. WriteChanges(WriteMessages, 0)
Conținutul este citit folosind comanda
Concluzie
Putem spune cu siguranță că mecanismul RIB constă în principal dintr-un mecanism de schimb universal cu unele caracteristici distinctive care sunt prezente numai în structura RIB.