Crearea nervurii în retail 1s 8.3. Instrucțiuni pentru configurarea unei baze de informații distribuite (DIB) prin resursa FTP. Configurarea unei resurse FTP

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 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, inclusiv internetul mobil, pentru schimb.

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 o 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ă, „nativă” pentru platforma 8.2, și adaptată de la 8.1, continuând să utilizeze tehnologii și mecanisme învechite. Întrucât o parte semnificativă a configurațiilor (Contabilitatea întreprinderii, Salarizarea și Managementul resurselor umane) sunt adaptate sau tranzitorii, acestea nu pot fi reduse, așa că 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. Pe 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ă configurația 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 în mod special la actualizarea sau efectuarea de modificări ale configurației. Aceste acțiuni sunt disponibile doar 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.

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:

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 clientul subțire și sarcina pe acestea 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 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 ș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 ale aceluiaș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
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, 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 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ă î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?
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.
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.

Acest material conține instrucțiuni detaliate pentru configurarea schimbului RIB pentru 1C:Enterprise 8 și problemele pe care le-a întâmpinat autorul.

1. Crearea nodurilor
Creăm noi noduri (master și slave): în modul utilizator „Operațiuni/Planuri de schimb/Complet”
Să alegem planul de schimb „Complet”
Creăm două înregistrări:
- să numim prima înregistrare „CB” (nodul principal), să indicăm codul „CB”,
- să numim a doua intrare „Nod subordonat”, indicați codul „PU”.
Pictogramă cu un cerc verde - „CB” (nodul principal)

Pentru nodul slave, faceți clic pe pictograma „Creați imaginea inițială”. (Necesită acces exclusiv)
Creați o imagine de pornire
Apoi, în fereastra care se deschide, completați parametrii noii baze de date. Când ați terminat, faceți clic pe butonul „Terminare”.
Crearea unei imagini inițiale de securitate a informațiilor
Va începe crearea imaginii inițiale a nodului slave al bazei de informații distribuite, iar la finalizare va apărea mesajul „Crearea imaginii inițiale a fost finalizată cu succes”. Faceți clic pe butonul „OK”.
Adăugăm baza nodului slave la lista de baze și o lansăm.
În această bază de date subordonată deschidem planul complet de schimb - pictograma „CB” este roșie, ceea ce înseamnă că acest nod este nodul principal pentru baza de informații în care ne aflăm.

2. Configurarea prefixelor
Pentru fiecare bază de date, în setările parametrilor contabili (în UPP „Service / Accounting Parameters”) din fila „Data Exchange”, setăm prefixe. Acest lucru se face astfel încât să nu existe conflicte în numerele și codurile documentelor și directoarelor create în două baze de date.
Pentru schimbul automat, bifați caseta „Utilizați mecanismul de schimb automat...”
Fila „Schimb de date”

3. Adăugați o setare pentru schimbul de date între noduri
Deschideți: „Service\Distributed Information Base (RIB)\Configurați nodurile RIB”
Faceți clic pe „Adăugați” și se va deschide fereastra „Setări de schimb de date”.
Configurarea schimbului de date

Faceți clic pe pictograma „Schimb conform setărilor curente”.
Executați schimbul conform setării curente

Acum despre capcane
1. Schimbul de date poate fi efectuat automat și poate fi inițiat în următoarele cazuri:
* La pornirea programului. Schimbul va fi efectuat la pornirea programului,
* Când terminați de lucrat cu programul. Schimbul va fi efectuat înainte ca utilizatorul să termine lucrul cu programul,
* Când apare catalogul. Schimbul va fi efectuat numai dacă directorul specificat de utilizator era invizibil, dar acum a devenit vizibil. Setarea poate fi utilizată pentru a efectua schimbul automat atunci când este conectat la o rețea locală sau un card flash. Programul va verifica periodic vizibilitatea directorului specificat în setări și va nota starea sa actuală,
* Când apare fișierul. Este recomandat să utilizați modul de date atunci când trebuie să faceți schimb dacă apare un fișier de schimb de date primit. În acest caz, este suficient să specificați calea completă către fișierul de schimb de date primit. Programul analizează periodic prezența fișierului și, de îndată ce acesta apare, schimbul va fi efectuat, iar după schimb, acest fișier va fi ȘTERS forțat (acest lucru se face astfel încât procedura de schimb să nu se efectueze în mod constant),
* Schimb periodic de date. Schimbul se va efectua conform setărilor pentru schimbul periodic de date. Dacă baza de informații funcționează în modul server de fișiere, atunci schimbul periodic este efectuat numai pentru utilizatorul care este specificat în setările politicii contabile ca „Utilizator pentru sarcini de rutină în modul fișier”. În versiunea Client-server, schimbul se realizează pe serverul 1C:Enterprise.

Am o opțiune Client-Server - pentru ca schimbul automat de rutină să funcționeze, a trebuit să supraîncărcați serverul

2. Codare Windows.
Schimbul a fost întrerupt de o eroare deoarece fișierul nu a fost comprimat. Acest lucru se datorează unei erori chirilice în linia de comandă în timpul compresiei.
Poate fi tratată prin corectarea codificărilor din registru.
De exemplu, pentru Windows Server 2008 -
Cod

REGEDIT4
"1250"="c_1251.nls"
"1251"="c_1251.nls"
"1252"="c_1251.nls"
"1253"="c_1251.nls"
"1254"="c_1251.nls"
"1255"="c_1251.nls"

3. La crearea unei copii a bazei de date (de exemplu, pentru modificare) în versiunea client-server, ESTE NECESAR ca SARCINIILE DE RUTINĂ ALE COPIEI BAZEI DE DATE să fie DEZACTIVATE. Blocarea sarcinilor de rutină pentru copiere ON

Dacă nu sunt blocate, atunci copia va face schimburi în același program ca baza de date principală. Aceasta înseamnă că unele mesaje către nodurile de la distanță vor fi generate din baza de date de lucru, iar altele dintr-o copie, ceea ce va duce la desincronizarea configurațiilor.

OLEG FILIPOV, ANT-Inform, șef adjunct departament dezvoltare, [email protected]

RIB în 1C. Limitele posibilităților

Tehnologia bazelor de informații distribuite (RIB) din platforma 1C:Enterprise provoacă multe controverse. Vom încerca să ne dăm seama când este indicat să îl folosim și când este mai bine să preferăm soluții alternative

Adesea, când citiți forumuri sau articole ale autorilor online despre RIB în 1C, puteți întâlni opinii contradictorii de la „acesta este cel mai bun și singurul lucru care poate fi folosit” la „este iremediabil depășit”. Să încercăm să ne dăm seama cum stau lucrurile cu adevărat.

În numărul din noiembrie 2016, am scris deja despre unele dintre caracteristicile RIB în legătură cu o sarcină practică specifică, așa că doar câteva cuvinte despre elementele de bază și să intrăm puțin mai adânc în detaliile tehnologice.

RIB este o tehnologie de baze de informații distribuite 1C:Enterprise - care nu trebuie confundată cu schimbul universal, cu o tehnologie similară, dar suport fundamental diferit pentru actualizarea centralizată a configurațiilor bazei de informații. Este format din următoarele părți funcționale (care pot fi utilizate și separat):

• Serviciu de înregistrare a modificărilor– când este activat, începe să înregistreze automat modificările aduse obiectelor sau înregistrărilor pentru schimb (sau alte scopuri). În modul RIB este folosit și pentru a înregistra modificările la configurația bazei de informații.
• Serializarea obiectelor/înregistrărilor în XML. Aproape orice obiect 1C:Enterprise este serializat în mod obișnuit în XML.
• Un mecanism pentru menținerea aceleiași configurații a tuturor nodurilor unei baze de informații distribuite.În modul RIB, schimbul de date între diferite noduri este posibil numai dacă acestea au aceeași configurație. Este transferat automat în timpul schimbului. Nodul final trebuie doar să accepte modificările.
• Infrastructura mesajelor schimbate într-un sistem informatic distribuit este garantată de livrare. Modificările înregistrate sunt împachetate în mesaje și trimise la nodul final în loturi. Înregistrările sunt șterse numai după confirmarea livrării pachetului.
• Infrastructură la nivel de aplicație. Desigur, toate cele de mai sus nu vor funcționa fără mecanisme dezvoltate la nivel de soluții de aplicație, dintre care unele sunt deja incluse în BSP. Soluțiile oferă posibilitatea de a încărca date în conformitate cu anumite reguli, de a schimba principiile înregistrării lor și de a determina metoda de livrare a pachetului.

După cum puteți vedea, RIB în 1C poate face destul de multe. În cele mai multe cazuri, această funcționalitate este mai mult decât suficientă. De exemplu, în Fig. Figura 1 prezintă forma nodului de bază de informații din 1C, unde puteți vedea capacitatea de a descărca regulile de înregistrare, de a specifica parametrii de conexiune și de a vizualiza lista de obiecte înregistrate pentru schimb.

Din descrierea de mai sus putem concluziona despre capacitățile RIB 1C ca sistem distribuit:

• Suport pentru o configurație unificată a bazei de informații (semi-automatizată).
• Modificați suportul de urmărire.
• Livrare garantata.
• Posibilitatea circuitului master-master.
• Posibilitatea unui circuit în stea.
• Posibilitatea de filtrare selectivă a modificărilor.

Destul de bine - va satisface complet nevoile unei rețele mici. Dar RIB are anumite limitări, în mare parte legate de caracteristicile arhitecturale ale platformei 1C, care impun anumite restricții privind utilizarea acestei tehnologii:

• Necesitatea de a actualiza manual configurația bazei de informații și de a închide utilizatorii. Oprirea schimburilor până când configurația este actualizată.
• Limita tranzacțională a infrastructurii de mesaje privind regăsirea datelor. La selectarea modificărilor pentru încărcare, tabelul bazei de date este blocat pentru a înregistra noi modificări; cu volume mari de încărcare, acest lucru poate dura mult timp, oprind munca.
• Overhead pentru menținerea unui număr mare de noduri de sincronizare (numărul de înregistrări de serviciu este egal cu numărul de noduri).
• Probleme la încărcarea unor cantități mari de date.

Să încercăm acum să comparăm acest lucru cu un sistem „avansat” care are un mecanism de replicare.