1s 8 coaste și obiecte adăugate. Baza de informatii distribuite. Instrucțiuni pas cu pas și capcane. Setări de schimb de informații distribuite
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 se numesc noduri distribuite baza de informatii(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 nivel de metadate de configurare, ci și la nivel elemente individuale, pe care 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 cutare sau cutare plan să fie folosit în aceasta structura ierarhica, trebuie să aibă proprietatea „Bază de informații distribuită” 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 din mecanism schimb universal cu unele trăsături distinctive care sunt prezente doar în structura RIB.
Sarcină: este necesară configurarea bazei de informații astfel încât trei utilizatori care nu se află în aceeași bază de date de lucru să poată lucra într-o bază de date de lucru. retea locala, dar conectat la Internet.
Să îndeplinim această sarcină prin crearea unei baze de informații distribuite. Configurarea bazei de informații – „Enterprise Accounting 2.0”.
Configurarea unei resurse FTP.
Să setăm FTP folosind HCube ca exemplu: Accesați site-ul web hcube.ru. Fila Gazduire, Gazduire FTP (http://www.hcube.ru/hosting/ftp/). Alegeți minimul plan tarifar FTP -10, acest lucru va fi suficient pentru schimbul între nodurile unei baze de informații distribuite. Puteți comanda o perioadă de probă de 15 zile, faceți clic pe „Încercați”. În continuare trebuie să ne înregistrăm:
Specificați numele de utilizator și parola pentru a vă accesa contul personal. După ce cererea a fost acceptată, așteptăm o scrisoare către e-mailul specificat cu detalii de acces FTP. Informații despre configurația serviciului dvs. de găzduire: ***************************************** ********* ********************
Autentificare gazduire: user725
Parola de gazduire: ffUXP3CDU
Adresă IP de găzduire: 85.10.207.234
****************************************************************
Panou de control pentru găzduire FTP https://cp.hcube.ru/manager/ispmgr 
Așteptăm ca statul să devină „Activ”.
Stabilirea unui plan de schimb.
Este necesar să se determine nodul central al bazei de date. Să alegem ca nod central la locul de muncă situat în birou. Celelalte două vor comunica cu nodul central. Să instalăm nodul central. Pentru a face acest lucru, trebuie să vă conectați la sistemul de securitate a informațiilor ca utilizator cu drepturi depline. În meniul principal al programului, selectați elementul „Planuri de operațiuni/schimb...”. În planurile de schimb ale configurației standard „Contabilitatea întreprinderii 8”, au fost deja create 7 planuri de schimb standard: 
Deschiderea planului "Deplin". Conține o intrare goală predefinită. Această intrare descrie nodul curent. Predeterminat, adică O intrare adăugată la nivel de configurare nu poate fi ștearsă, dar poate fi corectată. Faceți clic pe editați: câmp "Nume" poate fi arbitrar, de exemplu "Nodul central". "Cod" poate fi, de asemenea, arbitrar, de exemplu "01", faceți clic "BINE". Nodul curent a fost descris, acum este necesar să descriem nodurile slave. Adăugați elemente noi cu numele „Nodul 1”și cod "02"Și „Nodul 2” cu cod "03". Obținem trei noduri: 
Pot exista multe noduri slave în RIB și schimbul va fi efectuat între un nod central și fiecare dintre nodurile slave. Acum să creăm fizic un nod slave (o nouă bază de date). Pentru a face acest lucru, trebuie să stați pe linia nodului „Nodul 1”și faceți clic pe pictogramă „Creează imaginea inițială...” sau selectați această acțiune din meniu: 
Sistemul vă va solicita să selectați tipul de bază de informații (IS). Trebuie selectat "Pe acest calculator…»
. Apoi specificați directorul în care va fi creată noua securitate a informațiilor. După aceasta, o nouă bază de date va fi creată în directorul specificat și toate datele din baza de date principală vor fi transferate în această bază de date. Merită remarcat imediat că noua securitate a informațiilor nu este o copie exacta original. Are propriile setări (propria listă de utilizatori etc.), sunt transferate doar datele și planurile de schimb modificate, adică. în noua securitate a informaţiei vor fi doar două noduri "Nodul central"Și „Nodul 1”. Dacă baza de date sursă este mare și există utilizatori care lucrează în ea, pot exista coliziuni la crearea imaginii inițiale, de aceea se recomandă ca operațiunea de creare a unei noi imagini să fie efectuată în modul monopol. Dacă în nodul central au fost descrise mai multe noduri slave, operația de creare a unei imagini inițiale de securitate a informațiilor trebuie efectuată pentru fiecare nod, adică. vor fi create tot atâtea sisteme noi de securitate a informațiilor cât numărul de noduri descris în baza de date inițială. Vom face la fel pt „Nodul 2”. În momentul creării imaginii inițiale, în baza de date principală va fi creat un tabel pentru sincronizarea obiectelor bazei de date principale cu acest nod. În general, astfel de tabele sunt create în funcție de numărul de noduri slave. Atunci când se creează imaginea inițială a unui nod, este setat indicatorul de sincronizare cu nodul. Acum, bazele de date ale nodurilor slave trebuie copiate pe stațiile de lucru „Nodul 1”Și „Nodul 2”. După aceasta, cele trei calculatoare vor avea baze de informații identice (din punct de vedere al datelor).
Setări de schimb de informații distribuite.
În această problemă avem un caz general când toate cele trei baze de date funcționează, adică. documentele sunt introduse și modificate în trei baze de date. Să mergem la meniu „Serviciul / Baza de informații distribuite (RIB) / Configurați nodurile RIB”. Să stabilim un schimb între Hub centralȘi Nodul 1. Pe fila „Baze de informații distribuite” adăugăm element nou, să-i spunem „Birou – Nodul 1”(unde „Office” este centrul nostru central). Selectați din recuzită "Nod" – „Nodul 1”. În câmp „Tipul de schimb” alege „Schimb prin resursă FTP". Completem detaliile care ne-au fost trimise prin e-mail: "Abordare", "Utilizator", "Parola". Filele „Schimb interactiv”Și „Schimb automat” Nu îl completăm încă, o vom face după setările de bază ale schimbului în toate nodurile. 
În continuare, prin analogie, vom crea un nou element pentru stabilirea schimbului dintre Nodul Central și Nodul 2. 
Să trecem la imaginea inițială creată anterior (baza de informații) Nodul 1și creați setări „Nodul 1 – Birou”.
Să facem același lucru în Nodul 2. 
Pe fila „Schimb interactiv” putem stabili dacă trebuie să încărcăm și să descărcam date sau doar un singur lucru. 
Pe fila „Schimb automat” puteți adăuga un nou element pentru a configura schimbul automat. Aici putem stabili un program pentru un anumit schimb, de exemplu pentru „Birou – Nodul 1”, și/sau schimb bazat pe evenimente. 
Când selectați un utilizator în setările de partajare a evenimentelor, trebuie să specificați și utilizator dat V „Setări program” pe filă "Schimb de date".
Schimbul din exemplul nostru va fi efectuat numai dacă baza de date este conectată așa cum este specificat în setări „Schimb după eveniment” utilizator. De asemenea, trebuie să indicați „Prefixul nodului pentru baza de informații distribuită” pentru numerotarea corectă a documentelor. Folosind prefixul, putem vedea care nod a creat documentul și, de asemenea, evităm duplicarea numerelor documentului. Pentru lucru confortabilîntr-o bază de informații distribuite, este necesar să se ia în considerare cu atenție ciclul de schimb de noduri între ele, programul de schimb și/sau schimbul de evenimente pentru o anumită sarcină.
Creare și configurare bază distribuită datele (RIB) din 1C 8.3 Contabilitatea (și alte configurații) sunt necesare î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ă creație copie 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:
Următorii pași cu setarea sincronizării FTP și e-mail sărim. 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 „Nume complet”. baza de date de fișiere„Indicați fișierul 1Cv8.1CD în directorul pe care l-ați 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:
25 octombrie 2016
Nu există o mare diferență între configurarea și sprijinirea 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 o procedură pentru curățarea 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 acestea client slab iar sarcina asupra lor va fi minimă.
.
setări de bază
De pe vremea lui UT 10.3, când 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 la înregistrarea acestuia.
1) Este necesar să se împartă în scenarii de sincronizare separate pentru încărcare și descărcare
Ideea este că descărcarea durează mult ș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 în alte magazine, atunci desigur că ar fi mai corect să prezentați acest lucru sub forma unui director cu parte tabulară, care în cazuri extreme, când sunt scrise, pot forma șiruri din același registru. Oricum, .
Un alt detaliu important - Pentru ce? Există deja aproape 3 milioane de carduri de reducere, pentru a lucra cu un sistem extern online. 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 apărea 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 „vedei”, înainte
Folosit în magazinele de vânzare cu amănuntul opțiunea client-server lucrați 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, asta î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 unitate 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ă în 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 un sistem extern online. Dacă continuați să transferați carduri de reducere în toate magazinele, acest lucru va crește semnificativ schimburile și, î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 standard 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ă funcționeze, 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?
Actualizări și pentru noi pentru o lungă perioadă de timp au fost o dilema:
1) Actualizați manual din magazine (nu foarte corect, este posibil să nu fie primite modificări, vor apărea apeluri și probleme)
2) Actualizare cu forțe suport tehnic(nu 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, sarcinile au mers cu mult dincolo de lista de rezolvabile 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.
Acesta este, de exemplu, cum arată 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 sunt gata pentru replicare ulterioară. Planificarea corectă a sprijinului suplimentar este unul dintre factorii cheie pentru succesul în continuare a unor astfel de proiecte.