1s 8 rebara i dodanih predmeta. Distribuirana baza podataka. Korak po korak upute i zamke. Postavke razmjene distribuirane infobaze
RIB je distribuirana baza podataka, koja je struktura poput stabla, čije su grane pojedinačne raspoređene baze podataka 1C Enterprise. Ove baze se nazivaju distribuirani čvorovi informacijska baza(u daljnjem tekstu samo čvorovi). Između ovih čvorova formira se razmjena informacija kako bi se sinkronizirali svi čvorovi (konfiguracije i baze podataka).
Glavni mehanizam je mehanizam razmjene s nekim posebnim i univerzalnim mogućnostima. Glavna razlika je u tome što je RIB mehanizam razmjene specijaliziraniji i uži, dok univerzalne razmjene korisniku pružaju širi raspon mogućnosti.
Osnovni principi rada RIB-a
Moguće je promijeniti strukturu konfiguracije samo u glavnom korijenskom čvoru distribuirane infobaze. Te se promjene zatim hijerarhijski prenose na podređene čvorove. Dakle, ovo osigurava jedan prostor konfiguracijske strukture u svim RIB čvorovima.
Podaci se mogu mijenjati u bilo kojem od čvorova, koji se zatim distribuiraju na sve ostale čvorove. Štoviše, ti se podaci ne moraju nužno prenijeti drugim sudionicima u sustavu i njihov potpuni identitet možda neće biti sačuvan. Programer može prema želji prilagoditi sastav podataka koji sudjeluju u razmjeni s drugim sudionicima RIB-a. Štoviše, postavke se mogu napraviti ne samo na razini konfiguracijskih metapodataka, već i na razini pojedinačni elementi, na koje se mogu primijeniti posebne selekcije.
Kao što je gore spomenuto, RIB mehanizam se postiže korištenjem planova razmjene. ali da bi se ovaj ili onaj plan upotrijebio u ovome hijerarhijska struktura, mora imati aktivirano svojstvo "Distribuirana infobaza".
Svi podaci se putem poruka prenose u RIB. Sadržaj ovih poruka je jasno reguliran i ne može biti proizvoljan, kao u univerzalnom mehanizmu razmjene. Podaci se stavljaju u poruku korištenjem principa XML serijalizacije. Osim ovih promjena podataka, poruka sadrži i informacije o promjenama konfiguracije, kao i određeni broj servisnih informacija. Promjene se registriraju i stavljaju u poruku razmjene potpuno automatski. Na to ne mogu utjecati ni korisnik ni programer.
Prijem i generiranje razmjenskih poruka u RIB-u postavljaju se jednom naredbom
Planovi razmjene. WriteChanges(WriteMessages, 0)
Sadržaj se čita pomoću naredbe
Zaključak
Sa sigurnošću možemo reći da se RIB mehanizam uglavnom sastoji od mehanizma univerzalna razmjena s nekim razlikovnim značajkama koje su prisutne samo u RIB strukturi.
Zadatak: informacijsku bazu potrebno je konfigurirati tako da tri korisnika koji nisu u istoj radnoj bazi mogu raditi u jednoj radnoj bazi. lokalna mreža, ali spojen na internet.
Ostvarimo ovaj zadatak postavljanjem distribuirane informacijske baze. Konfiguracija informacijske baze – “Enterprise Accounting 2.0”.
Postavljanje FTP resursa.
Postavimo FTP koristeći HCube kao primjer: Idite na web stranicu hcube.ru. Kartica Hosting, FTP Hosting (http://www.hcube.ru/hosting/ftp/). Odaberite minimum tarifni plan FTP -10, to će biti dovoljno za razmjenu između čvorova distribuirane baze podataka. Možete naručiti probno razdoblje od 15 dana, kliknite na “Isprobaj”. Zatim se moramo registrirati:
Navedite korisničko ime i lozinku za pristup vašem osobnom računu. Nakon što je prijava prihvaćena, čekamo pismo na navedenu e-mail adresu s detaljima FTP pristupa. Informacije o konfiguraciji vašeg hosting servisa: ***************************************** ********* *********************
Prijava na hosting: user725
Lozinka za hosting: ffUXP3CDU
IP adresa hostinga: 85.10.207.234
****************************************************************
Upravljačka ploča za FTP hosting https://cp.hcube.ru/manager/ispmgr 
Čekamo da država postane “Aktivna”.
Postavljanje plana razmjene.
Potrebno je odrediti središnji čvor baze podataka. Izaberimo kao središnji čvor radno mjesto koji se nalazi u uredu. Druga dva će komunicirati sa središnjim čvorom. Postavimo središnji čvor. Za to se morate prijaviti u informacijski sigurnosni sustav kao korisnik s punim pravima. U glavnom izborniku programa odaberite stavku "Operacije/Planovi razmjene...". U planovima razmjene standardne konfiguracije “Enterprise Accounting 8” već je kreirano 7 standardnih planova razmjene: 
Otvaranje plana "Pun". Sadrži jedan unaprijed definirani prazan unos. Ovaj unos opisuje trenutni čvor. Predodređeno, tj. Unos dodan na razini konfiguracije ne može se izbrisati, ali se može ispraviti. Pritisnite uredi: polje "Ime" može biti proizvoljan, na primjer "Središnji čvor". "Kodirati" također može biti proizvoljan, na primjer "01", kliknite "U REDU". Trenutni čvor je opisan, sada je potrebno opisati podređene čvorove. Dodajte nove elemente s imenom "Čvor 1" i kod "02" I "Čvor 2" sa šifrom "03". Dobivamo tri čvora: 
U RIB-u može postojati mnogo podređenih čvorova, a razmjena će se vršiti između jednog središnjeg čvora i svakog od podređenih čvorova. Kreirajmo sada fizički podređeni čvor (novu bazu podataka). Da biste to učinili, morate stajati na liniji čvora "Čvor 1" i kliknite na ikonu “Stvori početnu sliku...” ili odaberite ovu akciju iz izbornika: 
Sustav će od vas zatražiti odabir vrste informacijske baze (IS). Obavezno odabrati "Na ovo računalo…»
. Zatim odredite direktorij u kojem će se kreirati nova informacijska sigurnost. Nakon toga će se kreirati nova baza podataka u navedenom direktoriju i svi podaci iz glavne baze podataka će se prenijeti u tu bazu podataka. Vrijedno je odmah napomenuti da nova informacijska sigurnost nije točna kopija izvornik. Ima svoje postavke (svoj popis korisnika i sl.), prenose se samo podaci i modificirani planovi razmjene, tj. u novoj informacijskoj sigurnosti bit će samo dva čvora "Središnji čvor" I "Čvor 1". Ako je izvorna baza podataka velika i u njoj rade korisnici, može doći do kolizija prilikom kreiranja početne slike, pa se preporučuje da se operacija kreiranja nove slike izvrši u monopolski način rada. Ako je nekoliko podređenih čvorova opisano u središnjem čvoru, operacija za stvaranje početne informacijske sigurnosne slike mora se provesti za svaki čvor, tj. stvorit će se onoliko novih sustava informacijske sigurnosti koliko je čvorova opisanih u izvornoj bazi podataka. Učinit ćemo isto za "Čvor 2". U trenutku kreiranja početne slike, u glavnoj bazi podataka će se kreirati tablica za sinkronizaciju objekata glavne baze podataka s ovim čvorom. Općenito, takve se tablice izrađuju prema broju podređenih čvorova. Prilikom kreiranja početne slike čvora postavlja se oznaka sinkronizacije s čvorom. Sada baze podataka podređenih čvorova moraju biti kopirane na radne stanice "Čvor 1" I "Čvor 2". Nakon toga će tri računala imati identične (po podacima) baze podataka.
Postavke razmjene distribuirane infobaze.
U ovom problemu imamo opći slučaj kada sve tri baze podataka rade, tj. dokumenti se unose i mijenjaju u tri baze podataka. Idemo na jelovnik “Usluga / Distribuirana informacijska baza (RIB) / Konfiguracija RIB čvorova”. Uspostavimo razmjenu između Središnje čvorište I Čvor 1. Na kartici "Distribuirane infobaze" dodajemo novi element, nazovimo to "Ured - čvor 1"(gdje je "Office" naše središnje čvorište). Odaberite iz rekvizita "Čvor" – "Čvor 1". U polju "Vrsta razmjene" izabrati "Razmjena putem FTP resurs". Ispunjavamo podatke koji su nam poslani e-poštom: "Adresa", "Korisnik", "Lozinka". Kartice "Interaktivna razmjena" I "Automatska zamjena" Još ga ne ispunjavamo, učinit ćemo to nakon osnovnih postavki razmjene u svim čvorovima. 
Zatim ćemo, analogno tome, kreirati novi element za postavljanje razmjene između središnjeg čvora i čvora 2. 
Idemo na prethodno stvorenu početnu sliku (informacijska baza) Čvor 1 i kreirati postavke "Čvor 1 - Ured".
Učinimo isto u čvoru 2. 
Na kartici "Interaktivna razmjena" možemo odrediti trebamo li i učitati i preuzimati podatke ili samo jednu stvar. 
Na kartici "Automatska zamjena" možete dodati novi element za konfiguraciju automatske razmjene. Ovdje možemo postaviti raspored za određenu razmjenu, na primjer za "Ured - čvor 1" i/ili razmjena temeljena na događajima. 
Prilikom odabira korisnika u postavkama dijeljenja događaja morate također navesti dati korisnik V "Postavke programa" na kartici "Razmjena podataka".
Razmjena u našem primjeru bit će izvršena samo ako je baza podataka prijavljena kako je navedeno u postavkama "Razmjena po događaju" korisnik. Također morate naznačiti "Prefiks čvora za distribuiranu informacijsku bazu" za pravilno numeriranje dokumenata. Pomoću prefiksa možemo vidjeti koji je čvor kreirao dokument, a također možemo izbjeći dupliciranje brojeva dokumenata. Za ugodan rad u Distribuiranoj informacijskoj bazi potrebno je pažljivo razmotriti ciklus međusobne razmjene čvorova, raspored razmjene i/ili razmjenu po događajima za određeni zadatak.
Izrada i konfiguracija distribuirana baza podataka (RIB) u 1C 8.3 Računovodstvo (i druge konfiguracije) su potrebne u slučajevima kada nije moguće raditi nekoliko korisnika dok se istovremeno povezuju s jednom bazom podataka. U današnje vrijeme to je prilično rijetka pojava, budući da standardna udaljena radna površina radi dobro, a postoje i drugi programi koji omogućuju udaljenu vezu sa središnjim računalom na kojem se nalazi baza podataka.
Ali ipak postoje situacije kada jednostavno nema interneta. A podaci bi u konačnici trebali završiti u jednoj informacijskoj bazi. Zbog toga se stvara distribuirana baza podataka.
Obično se glavna baza naziva središnjom, a ostale se nazivaju periferne. Zaključak je da se ručno ili automatski (ovisno o postavkama) baze podataka spajaju u jednu. Kako bi se osiguralo da se brojevi novounesenih dokumenata i referentnih kodova ne dupliciraju, svakoj se bazi podataka dodjeljuje prefiks.
U ovoj uputi ćemo na primjeru izraditi središnju i perifernu bazu podataka te provjeriti razmjenu između njih. Ovaj priručnik je prikladan i za 1C 8.3 Računovodstvo i za 1C Upravljanje trgovinom (UT) i druge konfiguracije.
Postavljanje glavne (centralne) distribuirane RIB baze podataka
Idemo na izbornik 1C "Administracija", a zatim kliknite na vezu "Postavke sinkronizacije podataka". U prozoru koji se otvori morate potvrditi okvir "Sinkronizacija podataka". Veza "Sinkronizacija podataka" postat će aktivna. Ovdje ćemo postaviti prefiks za glavnu informacijsku bazu - na primjer, "CB":
Kliknite poveznicu “Sinkronizacija podataka” i otvorit će se prozor s gumbom “Postavi sinkronizaciju podataka”. Kada kliknete na ovaj gumb, otvorit će se padajući popis na kojem trebate odabrati način rada "Puni". Ako je sinkronizacija potrebna samo za jednu organizaciju, trebate odabrati “Po organizaciji...”.
U sljedećem prozoru program će nas zatražiti da napravimo sigurnosnu kopiju. Toplo preporučujem da to učinite jer bi se sljedeći koraci postavljanja mogli nepovratno učiniti.
Nakon stvaranja sigurnosna kopija kliknite gumb "Dalje". U sljedećem koraku moramo odlučiti kako će se dogoditi sinkronizacija:
- putem lokalnog imenika ili imenika na lokalnoj mreži;
- putem interneta putem FTP-a.
Radi jednostavnosti i jasnoće primjera odabrat ćemo lokalni imenik. Naveo sam sljedeći put: “D:\1C baze podataka\Sinkronizacija”. Bilo bi dobro provjeriti unose u ovom imeniku; za to postoji poseban gumb:
Besplatno nabavite 267 video lekcija o 1C:
Sljedeći koraci s postavljanjem FTP sinkronizacije i e-pošta preskačemo. Pogledajmo postavke za nazive glavne i periferne baze podataka. Ovdje ćemo postaviti prefiks za perifernu bazu podataka:
Ne zaboravite da prefiksi za svaku bazu podataka moraju biti jedinstveni. U suprotnom, dobit ćete pogrešku "Vrijednost prefiksa prve infobaze nije jedinstvena."
Pritisnite “Dalje”, provjerite unesene podatke i ponovno kliknite “Dalje”, zatim “Završi”. U polju "Puno ime". baza podataka datoteka"Naznačite datoteku 1Cv8.1CD u direktoriju koji ste stvorili za sinkronizaciju. Stvaramo početnu sliku distribuirane 1C baze podataka:
Nakon stvaranja početne slike RIB-a u 1C, možete postaviti raspored sinkronizacije ili sinkronizirati ručno:
Nakon sinkronizacije možete se spojiti na novu bazu podataka i provjeriti jesu li podaci iz središnje baze podataka tamo učitani:
Samo odmah stvorite barem jednog korisnika s administratorskim pravima u novoj perifernoj bazi podataka.
Postavljanje sinkronizacije u perifernoj bazi podataka
U perifernoj bazi podataka 1C konfiguracija je mnogo jednostavnija. Samo potvrdite okvir "Sinkronizacija podataka" i slijedite istoimenu vezu. I gotovo odmah se nalazimo u prozoru s gumbom "Sinkroniziraj". Pokušajmo stvoriti testnu stavku u perifernoj bazi podataka i učitati je u glavnu pomoću RIB-a:
25. listopada 2016
Nema velike razlike između postavljanja i podržavanja RIB-a za 2 čvora i za 10, ali kada broj udaljenih točaka premaši stotinu, moraju se riješiti potpuno druga pitanja
Početni podaci:
Konfiguracija: Maloprodaja 2.2
Platforma 1C: 8.3.7.1970
Trajanje projekta: jedna godina.
Arhitektura:
Prvo smo se odlučili za RIB shemu. Odlučeno je usredotočiti se na shemu "zvijezda" što je duže moguće; kada se dostignu tehnološka ograničenja – pahulja.
Ograničenja:
- 2 GB RAM-a
- 1 fizički procesor
Od svega navedenog, glavna stvar koja smeta je ograničenje maksimalne veličine baze podataka.
Ali to samo znači da trebate pažljivo organizirati postupak čišćenja od zastarjelih podataka na licu mjesta.
Za 1C i MS SQL poslužitelj dodijeljen je poseban fizički poslužitelj. Nosit će glavni teret razmjena i dugoročnog poslovanja.
Krajnja klijentska računala se ne mijenjaju, jer će raditi s njima tanak klijent a opterećenje na njima bit će minimalno.
.
osnovne postavke
Od vremena UT 10.3, tijekom kojeg sam imao svoj prvi projekt implementacije RIB-a za 60 čvorova, naravno, "puno je vode prošlo ispod mosta."
1C nije stajao mirno. Retail 2.2 sada uzima u obzir potrebu za selektivnim učitavanjem podataka.
Samo informacije koje su relevantne za njega bit će učitane u bazu podataka trgovine:
- Sve referentne knjige (osim specijaliziranih)
- Dokumenti za ovu trgovinu
Drugo je pitanje da, na ovaj ili onaj način, dodavanje čvora u bazu podataka znači dodavanje još jednog unosa u registracijsku tablicu za svaki zajednički element prilikom snimanja.
1) Potrebno je podijeliti u zasebne scenarije sinkronizacije za upload i download
Poanta je da istovar traje dugo i uključuje blokadu, dok je utovar prilično jednostavan. Pritom se često događa da trebamo brzo dobiti podatke iz prodajnih mjesta, a da ih dajemo samo nekoliko puta dnevno.
2) Identificirajte problematična spremišta i uklonite ih iz općeg scenarija sinkronizacije. Na njima mogu biti velika opterećenja - to će usporiti cijelu razmjenu, uključujući i druge čvorove. Nakon što se problemi riješe, oni se ponovno dodaju.
3) Napravite nekoliko skripti za slanje i primanje podataka. Ali ovdje je glavna stvar uhvatiti pravu ravnotežu njihove količine.
(od verzije 8.1).
Posljedično, paralelizam u istovaru RIB-a je ograničen. U praksi ispada da se paralelno izvode 2-3 skripte.
Što je trebalo poboljšati
Najvažniji problem u standardnoj logici 1C RIB-a su ažuriranja
Drugi problem razmjene su registri informacija. Učitavanje svakog zapisa registra informacija u XML stvara zaseban XML čvor s elementima usluge, itd. Osim toga, funkcija "SelectChanges()" za registar informacija u kojem postoji 100 zapisa primit će rezultirajuću tablicu od 100 redaka, na u isto vrijeme, ako će ovaj direktorij sa 100 redaka imati odabran samo jedan unos u svom tabličnom odjeljku. A ovo je vrijeme isključivog blokiranja. Dakle, ako postoji mnogo zapisa na PC-u koji se redovito registriraju za razmjenu u drugim trgovinama, onda bi naravno bilo ispravnije to predstaviti u obliku imenika s tablični dio, koji u ekstremnim slučajevima, kada je napisan, može tvoriti nizove istog registra. svejedno, .
Još jedan važan detalj - Za što? Kartica s popustom već ima blizu 3 milijuna, a za rad s njima koristi se vanjski online sustav. Ako nastavite prenositi diskontne kartice u sve trgovine, to će značajno povećati razmjene, a također može dovesti do toga da baza premaši volumen od 10 GB.
Neki od mehanizama implementiraju se online kontaktom sa središnjom bazom podataka: stanja u drugim trgovinama, vraćanje računa iz druge trgovine, provjera valjanosti darovnog bona.
Replikacija
Stvaranje inicijalnog RIB čvora na pravilan način učinilo bi replikaciju načelno nemogućom.
Stoga se novi čvor stvara na sljedeći način:
2) Ova baza podataka razmjenjuje sve opće podatke u RIB-u, ali ne prima specijalizirane (dokumente)
5) Baza za trgovinu je spremna.
Gotovi softverski paket postavlja se na poslužitelj, tako da ne oduzima puno vremena. Zatim se novostvorena baza podataka učitava na poslužitelj i spremna je za slanje u trgovinu.
Prednosti tankog klijenta
Dvije značajne prednosti Retail 2.2 (Thin Client) koje su “razgrijale dušu”:
Podrška i ažuriranja
1) Ažurirajte ručno iz trgovina (nije baš točno, promjene se možda neće primiti, bit će poziva i problema) - to je bio slučaj prije
3) Napišite *.cmd ili 1C skriptu za ažuriranje ili uzmite gotovu. Kao što pokazuje praksa, takvo je rješenje uvijek polovično (nestabilno) i bit će moguće ugraditi malo funkcionalnosti u njega.
Koji su bili naši zadaci:
2) Prilikom ažuriranja moguća je interaktivna interakcija s korisnikom (poruke, potvrde, traka napretka).
Glavne funkcije:
4) Provjera statusa agenata
5) Ažuriranje izvješća
6) sigurnosna kopija
Na primjer, ovako izgleda poruka pogreške nakon ažuriranja:
Dakle, projekt je imao dobre šanse da se uspješno završi. Barem na pola puta let je normalan.
Ako dođemo do nekog drugog rješenja koje bi moglo biti zanimljivo, pisat ću zasebno
p.s. i najvažnije: Pravilno planiranje daljnje podrške jedan je od ključnih čimbenika za daljnji uspjeh ovakvih projekata. :)
25. listopada 2016
Nema velike razlike između postavljanja i podržavanja RIB-a za 2 čvora i za 10, ali kada broj udaljenih točaka prijeđe stotinjak, moraju se rješavati sasvim druga pitanja.
Dakle, početni podaci:
Konfiguracija: Maloprodaja 2.2
Platforma 1C: 8.3.7.1970
Procijenjeni broj čvorova na kraju projekta: 200
Resursi opreme u centru: bez značajnih ograničenja
Oprema na punktu: raspravljeno pitanje.
Trajanje projekta: jedna godina.
Arhitektura:
Prvo smo se odlučili za RIB shemu. Prije je odlučeno usredotočiti se na shemu "zvijezda".
Koristi se u maloprodajnim objektima opcija klijent-poslužitelj raditi s namjenskim poslužiteljem koji pokreće Windows OS.
Server 1C će se koristiti u verziji "Server 1C MINI" https://1c.ru/news/info.jsp?id=17577
DBMS poslužitelj - MS SQL Express 2008 R2.
SQL Express 2008 R2 trenutačno je najnovija verzija ove linije SQL Servera.
Ograničenja:
2 GB RAM-a
- 1 fizički procesor
- 10 GB maksimalne veličine baze podataka
Od svega navedenog, najviše smeta, naravno, ograničenje maksimalne veličine baze podataka. Ali zapravo, to samo znači da će biti potrebno pažljivo organizirati postupak čišćenja od zastarjelih podataka na licu mjesta.
Za 1C i MS SQL poslužitelj dodijeljen je poseban poslužitelj. Ona će nositi glavni teret razmjena i transakcija.
Krajnja klijentska računala se ne mijenjaju, jer će raditi s tankim klijentom i opterećenje na dnu će biti minimalno.
Poslužitelj u trgovini jednostavno je moćno računalo. Ali preduvjet je prisutnost SSD pogon- na kojem se nalaze MS SQL baze podataka.
Poslužitelj će također omogućiti obavljanje rutinskih operacija noću i pristup bazi podataka trgovine bez ometanja posla.
osnovne postavke
Od vremena UT 10.3, tijekom kojeg sam imao svoj prvi projekt implementacije RIB-a za 60 čvorova, naravno, "puno je vode proteklo ispod mosta." 1C nije stajao mirno. Retail 2.2 sada uzima u obzir potrebu za selektivnim učitavanjem podataka.
Samo informacije koje su relevantne za trgovinu bit će učitane u bazu podataka trgovine:
- Svi imenici (osim nekih)
- Dokumenti za ovu trgovinu
Registracija podataka odvija se prema pravilima registracije, sve što se može predmemorirati. Nema značajnijih usporavanja tijekom registracije.
Drugo je pitanje da, na ovaj ili onaj način, dodavanje čvora u bazu podataka znači dodavanje još jednog zapisa za svaki zajednički element za sve baze podataka.
Ne postoji ništa posebno u postavljanju samog uploada. Postoje neke nijanse pri postavljanju scenarija sinkronizacije:
1) Potrebno je razdvojiti upload i load u zasebne scenarije sinkronizacije
Radi se o tome da istovar traje dugo i uključuje blokadu, dok je utovar prilično jednostavan. Pritom se često događa da trebamo brzo dobiti podatke iz prodajnih mjesta, a da ih dajemo samo nekoliko puta dnevno.
2) Identificirajte problematična spremišta i uklonite ih iz općeg scenarija sinkronizacije. Na njima mogu biti velika opterećenja - to će usporiti cijelu razmjenu, uključujući druge čvorove
3) Napravite neke skripte za slanje i primanje podataka. Ali glavna stvar ovdje je ravnoteža.
Neke stvari u 1C se ne mijenjaju. Ista metoda "SelectChanges" može se izvršiti samo uzastopno(od verzije 8.1).
Posljedično, paralelizam u istovaru RIB-a je ograničen. U praksi, na kraju učitavate 2-3 skripte odjednom.
Što se tiče prijemnog scenarija, tu je moguć puno veći paralelizam, ako zatreba, naravno.
Što je trebalo poboljšati
Naravno da je tužno i žalosno, ali morao sam se temeljito umiješati u BSP. Najvažniji problem u standardnoj 1C logici su ažuriranja. Nakon ažuriranja pojavljuje se prozor sličan ovome:
Sve se to događa u monopolnom načinu rada. Između ostalog, sustav će i dalje pokušavati izvršiti razmjenu nakon ažuriranja u ekskluzivnom načinu rada. Nije teško pogoditi kamo sve ovo vodi.
Cijelo to vrijeme trgovina ne može raditi, na blagajni ima kupaca, a tvrtka gubi novac.
Drugi problem razmjene su registri informacija. Učitavanje svakog unosa registra informacija u XML stvara zaseban XML čvor s elementima usluge i svime što slijedi. Osim toga, funkcija "odaberi promjene" za informacijski registar u kojem postoji 100 zapisa, rezultirajuća tablica će sadržavati 100 redaka, u isto vrijeme, ako je to imenik sa 100 redaka, samo će jedan zapis biti odabran u odjeljak stola. Dakle, ako u PC-u postoji puno zapisa koji se redovito registriraju za razmjenu u druge trgovine, onda je naravno ispravnije to prikazati u obliku imenika s tabelarnim dijelom, koji u ekstremnim slučajevima prilikom snimanja , može generirati zapise istog registra. svejedno, registri informacija u mjenjačnicama su zlo.
Još jedan važan detalj - Iz razmjene su u potpunosti isključene diskontne kartice, a iz razmjene su isključeni samo djelatnici određene trgovine. Za što? Kartica s popustom već ima blizu 3 milijuna, a za rad s njima koristi se vanjski online sustav. Ako nastavite prenositi diskontne kartice u sve trgovine, to će značajno povećati razmjene, a osim toga, može dovesti do toga da baza premaši volumen od 3 GB.
Neki od mehanizama implementiraju se online kontaktom sa središnjom bazom podataka: stanja u drugim trgovinama, vraćanje računa iz druge trgovine, provjera valjanosti darovnog bona.
Replikacija
Naravno, replikacija se provodi ubrzanim tempom.
Stvaranje početnog RIB čvora na standardni način bi, naravno, onemogućilo replikaciju.
Stoga se novi čvor stvara na sljedeći način:
1) Postoji zasebna baza podataka s lažnom trgovinom
2) Ova baza podataka razmjenjuje sve opće podatke u RIB-u, ali ne prima specijalizirane
3) Kada želimo kreirati novu bazu podataka, jednostavno kopiramo ovu
4) Zatim postavljamo postavke - pohranu, prefiks itd.
5) Baza za trgovinu je spremna.
Gotovi softverski paket postavlja se na poslužitelj, tako da ne oduzima puno vremena. Zatim se novostvorena baza trgovina učitava na poslužitelj i spremna je za slanje u trgovinu.
Prednosti tankog klijenta
dvije značajne prednosti koje su “zagrijale dušu”.
1) Nema potrebe mijenjati cijeli računalni park na prodajnim mjestima. 90% operacija se obavlja na poslužitelju, a poslužitelj se tamo dovodi s “relativno snažnim računalom”
2) Oprema ima sposobnost odbijanja rada, to se posebno često događa s novo instaliranom ili već istrošenom opremom.
U ovom slučaju radnje su sada krajnje jednostavne - trgovina se prebacuje na rad u središnjoj bazi podataka.
Ovaj proces ne traje više od 5-10 minuta, tako da se trgovanje ne prekida čak i ako postoje značajni problemi s opremom.
Podrška i ažuriranja
Konačno smo došli do najzanimljivije točke - kako sve to održavati i ažurirati?
Ažuriranja i za nas dugo vremena bila je dilema:
1) Ažurirajte ručno iz trgovina (nije baš točno, promjene se možda neće primiti, bit će poziva i problema)
2) Ažuriranje sa snagama tehnička podrška(nema toliko resursa)
3) Napišite *.cmd za ažuriranje ili uzmite gotovu. Kao što pokazuje praksa, takvo je rješenje uvijek polovično (nestabilno) i ima malo funkcionalnosti.
Koji su bili naši zadaci:
1) Ažuriranje se mora odvijati u nekoliko načina i njime se upravlja centralno
2) Prilikom ažuriranja moguća je interaktivna interakcija s korisnikom.
3) Moraju se primati izvješća o statusu ažuriranja i pogreškama
4) Mora postojati sigurnosna kopija
5) Sustav ažuriranja trebao bi se moći sam ažurirati bez problema.
6) Sustav bi trebao biti proširiv bez ikakvih problema.
Naravno, zadaci su daleko prevazilazili popis rješivih jednostavne metode. Jer ne možemo bez automatizacije s toliko krajnjih točaka, a nismo pronašli ništa više ili manje spremno sa sličnom funkcionalnošću
Morao sam početi razvijati softver koji je s vremenom dobio naziv MU (MagicUpdater).
Glavne funkcije:
1) Dinamičko ažuriranje baze podataka (naredba ili planirano)
2) Statičko ažuriranje baze podataka (naredba ili planirano)
3) automatski agenti na krajnjim računalima kada su modificirani
4) Provjera statusa agenata
5) Ažuriranje izvješća
6) sigurnosna kopija
7) Administrativne radnje s 1C poslužiteljem i MS SQL
8) Zatvaranje svih 1C klijentskih aplikacija na mrežnim računalima
9) Statičko ažuriranje s prihvaćanjem na glavnoj blagajni
10) Prikaz opisa izmjena nakon ažuriranja
11) Postavljanje redoslijeda radnji
12) Izvršite sve ove radnje prema rasporedu
Približne sheme interakcije:
Gdje je MU Agent usluga koja se instalira i konfigurira u trgovini. Zapravo, ona dobiva zapovijed iz centra da izvrši određene zadatke.
MU poslužitelj - poslužitelj koji prima sve zahtjeve prema sustavu.
MU monitor - ono što obični zaposlenici tehničke podrške vide - koristi se za pregled zapisa i postavljanje zadataka za ažuriranje ili drugih.
Ispalo je dosta dobro, po mom mišljenju. Sada se ažuriranja odvijaju gotovo automatski.
Ovako, na primjer, izgleda poruka o pogrešci nakon ažuriranja; sve ostaje u centru, čeka.
I ovako šaljemo naredbe klijentskim računalima
Aplikacije sigurno nisu 1C, ali s prilično pristojnim skupom mogućnosti sučelja. Na primjer, ovako izgleda odabir prema datumu:
Sada su spremni za daljnju replikaciju. Pravilno planiranje daljnje podrške jedan je od ključnih čimbenika za daljnji uspjeh ovakvih projekata.