Preporučljivo je poduzeti ove korake kada u bazi podataka nema aktivnih korisnika. Ako to nije moguće, onda ćete morati sami "završiti" metodu, pa morate prvo razumjeti njenu logiku
Za 1C 8.x platforme, kada se pojavi greška "Konfiguracija distribuiranog informacijskog sigurnosnog čvora ne odgovara očekivanom"
Metodologija rješavanja problema
Spisak skraćenica koje koristim:
RIB - distribuirana informaciona baza
CB - centralna baza, korijenski čvor RIB-a
UB - udaljena baza, baza podataka udaljenog čvora RIB-a
Iz vlastitog iskustva mogu reći da sam naišao na dva razloga za grešku:
Tokom prijema datoteke poruke, baza podataka je “pala” u sistemu upravljanja, pa je, po svemu sudeći, došlo do desinhronizacije između konf. Centralna banka i UB;
pod MSSQL, klijent je preuzeo kopiju radne baze podataka i nije isključio reg. zadaci automatske razmjene, kao rezultat toga, neke poruke udaljenim čvorovima generirane su iz radne baze podataka, a neke iz kopije, što je dovelo do desinhronizacije konfiguracija
Postoji i mišljenje da je ova greška uzrokovana upotrebom mehanizma dinamičkog ažuriranja baze podataka. Ovdje postoje sumnje, jer s jedne strane, dinamičko ažuriranje nikada ne utiče na strukturu baze podataka, a RIB mehanizmi i dalje rade sa strukturom baze podataka, a ne sa njenim primijenjenim dijelom, RIB koristi mehanizam za generiranje digitalnog potpisa; verziju konfiguracije (ubuduće ću je skraćeno zvati hash), a kada se promijeni dio aplikacije, heš se naravno mora ponovo izračunati. Neću to ni demantovati ni tvrditi, jer... Ako sam se susreo sa ovom situacijom, nisam našao nijedan jasan dokaz za to.
Da to ispravim, koristim 2 metode, ovisno o situaciji.
PRVA TEHNIKA
Prvi (najčešći) se više puta spominje i na partnerskoj konferenciji i na drugim internetskim resursima koji se odnose na 1C. Koristi se u većini slučajeva kada, uprkos poruci o odstupanjima u konfiguracijama, ručno poređenje pokaže da su one identične.
Slijed:
1. skinuti cf fajl iz centralne banke;
2. odvojiti UB od RIB-a (metoda Set MainNode, gotova obrada se može naći u dodatku ili u drugim publikacijama);
3. zamijenite konf. UB u cf fajl koji je učitan u prvom koraku, za ovo koristimo meni „Učitaj konfiguraciju iz datoteke“ (a ne poređenje-spajanje!!!);
4. vratite RIB atribut za UX.
U većini slučajeva, ove radnje su više nego dovoljne za obnavljanje razmjene, ali ne uvijek...
DRUGA METODA
Koristi se ako prva metoda nije uspjela i nije moguće ponovno istovariti čvor.
Dakle, redoslijed radnji:
1. izvršiti korake 1 - 4 prve metode;
2. učitati datoteku za razmjenu sa UB, ali je ne učitavati u Centralnu banku;
3. učitati datoteku za razmjenu iz Centralne banke, ali je ne učitavati u MB;
4. u datoteci za razmjenu iz Centralne banke zamjenjujemo blok koji sadrži informacije o promjenama konfiguracije i hashovima (Digest1 i Digest2) blokom hashova iz UB fajla (vidi primjer ispod)
5. Učitavamo fajl sa 4. tačke na UB;
Obavezno prebrišite datoteku za razmjenu sa UB (2. tačka)! ovaj fajl ne treba preuzimati prilikom razmjene sa Centralnom bankom!
Da bismo provjerili, vršimo nekoliko uzastopnih razmjena.
Ako se tokom razmjene koristi kompresija podataka, tada ili deaktiviramo kompresiju, ili prvo raspakujemo datoteku, promijenimo je, zatim je pakujemo nazad i šaljemo.
Blok datoteka za razmjenu od Centralne banke
treba zamijeniti blokom datoteke za razmjenu iz UB-a (imajte na umu da je Digest1 za datoteku iz UB uvijek jednak “000000000000000000000000000000000”!!!)
Navedene radnje moraju se izvoditi s krajnjim oprezom; nepravilan redoslijed može rezultirati potpunom nefunkcionalnošću RIB-a. Stoga, prije ovih radnji, pravljenje rezervnih kopija je OBAVEZNO!
Ova greška je tipična za . Greška „Konfiguracija distribuiranog informacijskog sigurnosnog čvora ne odgovara očekivanoj“ je sistemska. Uglavnom se javlja zbog nenormalnog isključivanja tokom razmjene podataka putem URIB-a.
Ovo se može riješiti na prilično jednostavan način. Hajde da to razmotrimo.
Instrukcije
1. Napravite kopije baza podataka na kojima će se raditi (u konfiguratoru “Administracija - Upload infobaze”).
2. Pokrenite konfigurator glavne baze podataka RIB čvora.
3. Sačuvajte konfiguraciju centralnog čvora u datoteku baze podataka (“Konfiguracija - Sačuvaj konfiguraciju u datoteku...”)
4. Otvorite konfigurator baze podataka podređenog čvora.
Nabavite 267 video lekcija na 1C besplatno:
5. Uklonite konfiguraciju slave čvora iz podrške (Konfiguracija - Podrška - Postavke podrške - Ukloni iz podrške):
6. Učitajte konfiguraciju baze podataka (“Konfiguracija – Učitaj konfiguraciju iz datoteke...”).
8. Nakon restrukturiranja, potrebno je ući u poslovni mod i instalirati glavni konfiguracijski čvor. To se može učiniti pomoću posebne obrade - . Obrada radi i u režimu upravljane aplikacije i u redovnom režimu aplikacije.
9. U obradi morate odabrati glavni čvor i kliknuti na “Run”:
10. Gotovo! Pokušajte da pokrenete razmenu, sistem bi trebalo da završi razmenu ispravno.
Prvo, lista korištenih skraćenica:
- RIB - distribuirana informaciona baza
- CB - centralna baza, korijenski čvor RIB-a
- UB - udaljena baza, baza podataka udaljenog RIB čvora
Iz vlastitog iskustva mogu reći da sam naišao na dva razloga za grešku:
- Prilikom prijema datoteke sa porukom, baza podataka je “pala” u sistemu upravljanja, pa je, po svemu sudeći, došlo do desinhronizacije između konf. Centralna banka i UB;
- pod MSSQL, klijent je preuzeo kopiju radne baze podataka i nije isključio reg. zadaci automatske razmjene, kao rezultat toga, neke poruke udaljenim čvorovima generirane su iz radne baze podataka, a neke iz kopije, što je dovelo do desinhronizacije konfiguracija
Postoji i mišljenje da je ova greška uzrokovana upotrebom mehanizma dinamičkog ažuriranja baze podataka. Ovdje postoje sumnje, jer s jedne strane, dinamičko ažuriranje nikada ne utiče na strukturu baze podataka, a RIB mehanizmi i dalje rade sa strukturom baze podataka, a ne sa njenim primijenjenim dijelom, RIB koristi mehanizam za generiranje digitalnog potpisa; verziju konfiguracije (u budućnosti ću je skraćeno zvati hash), a kada se promijeni dio aplikacije, heš se naravno mora ponovo izračunati. Neću to ni demantovati ni tvrditi, jer... Ako sam se susreo sa ovom situacijom, nisam našao nijedan jasan dokaz za to.
Da to ispravim, koristim 2 metode, ovisno o situaciji.
PRVA TEHNIKA
Prvi (najčešći) se više puta spominje i na partnerskoj konferenciji i na drugim internetskim resursima koji se odnose na 1C. Koristi se u većini slučajeva kada, uprkos poruci o odstupanjima u konfiguracijama, ručno poređenje pokaže da su one identične.
Slijed:
- učitajte cf fajl iz centralne banke;
- odvajamo UB od RIB-a (metoda Set MainNode, gotova obrada se može naći u aplikaciji ili u drugim publikacijama);
- zamjena konf. UB u cf fajl koji je učitan u prvom koraku, za ovo koristimo meni „Učitaj konfiguraciju iz datoteke“ (a ne poređenje-spajanje!!!);
- Vratimo RIB znak za UX.
U većini slučajeva, ove radnje su više nego dovoljne za obnavljanje razmjene, ali ne uvijek...
DRUGA METODA
Koristi se ako prva metoda nije uspjela i nije moguće ponovno istovariti čvor.
Pozadina: klijent je postavljao kaskadni RIB i došlo je do greške na prvom nivou kaskade (drugi nivo je radio besprekorno sve ovo vreme). Konfiguracija je razvijena u saradnji sa IT servisom klijenta, a od kada je došlo do greške, konfiguracija centralne banke se više puta mijenjala. Opcija vraćanja izmjena nije razmatrana čak ni u principu, jer gubitak nekih podataka i gašenje nekoliko odjela bilo je potpuno neprihvatljivo. Prva opcija za ispravljanje greške nije dala nikakve opipljive rezultate. Stoga smo morali tražiti druga rješenja.
Došla je ideja da se pokuša zamijeniti heš konfiguracijskih datoteka direktno u XML datotekama za razmjenu. Opis strukture datoteke za razmjenu iz knjige "Profesionalni razvoj u sistemu 1C:Enterprise 8" dao je slabu ideju o formiranju digitalnih potpisa konfiguracija i promjenama u njima, ali je odredio smjer kretanja. traži: vrijednosti Digest1 i Digest2. Sve ostalo sam shvatio čisto empirijski (odnosno, pokušajem i greškom), ali je bilo moguće uspostaviti obrazac.
Probni eksperimenti su bili uspješni. I na radnim bazama je sve dobro prošlo.
Dakle, redoslijed radnji:
- izvršiti korake 1 - 4 prve metode;
- Učitavamo fajl za razmjenu iz UB-a, ali ga ne učitavamo u Centralnu banku;
- Učitavamo datoteku za razmjenu iz Centralne banke, ali je ne učitavamo u UB;
- u datoteci za razmjenu iz Centralne banke, blok koji sadrži informacije o promjenama konfiguracije i hashovima (Digest1 i Digest2) zamjenjujemo blokom hashova iz UB datoteke (vidi primjer ispod)
- Učitavamo fajl od 4. tačke u UB;
- Obavezno prebrišite datoteku za razmjenu sa UB (2. tačka)! ovaj fajl ne treba preuzimati prilikom razmjene sa Centralnom bankom!
- Da bismo provjerili, vršimo nekoliko uzastopnih razmjena.
Ako se tokom razmjene koristi kompresija podataka, tada ili deaktiviramo kompresiju, ili prvo raspakujemo datoteku, promijenimo je, zatim je pakujemo nazad i šaljemo.
Blok datoteka za razmjenu od Centralne banke
...ovdje su blokovi koji opisuju promjene konfiguracije...
treba zamijeniti blokom datoteke za razmjenu iz UB (imajte na umu da je Digest1 za datoteku iz UB uvijek jednak "00000000000000000000000000000000"!!!)
Navedene radnje moraju se izvoditi s krajnjim oprezom; nepravilan redoslijed može rezultirati potpunom nefunkcionalnošću RIB-a. Stoga, prije ovih radnji, pravljenje rezervnih kopija je OBAVEZNO!
Distribuirana informaciona baza (DIB) se često koristi za organizaciju rada filijala i odjeljenja, omogućavajući brzu razmjenu informacija uz održavanje potrebnog stepena autonomije. Unatoč činjenici da je ova tehnologija prilično pouzdana, s vremena na vrijeme se pokvari. Danas ćemo pogledati jednu od prilično čestih grešaka: Reći ćemo vam o razlozima za njenu pojavu i načinima rješavanja.
Počnimo, kao i uvijek, od početka. Nakon što ste kreirali RIB, sve promjene u konfiguraciji baze podataka mogu se izvršiti samo u glavnom čvoru. Nakon toga, tokom sljedeće razmjene, sve promjene će se prenijeti na slave čvorove i tamo automatski primijeniti. Ali na papiru je bilo glatko...
U praksi se ponekad dešava da između sesija razmene, posebno ako je kanal na periferiji loš, konfiguracija glavnog čvora uspe da se promeni dva puta. Na primjer, izvršili su promjene, prenijeli ih, periferna baza podataka je primila promjene, ali ih još nije primijenila, što može potrajati, a još nije poslala potvrdu. Ako ponovo unesete promjene tokom ovog perioda i ponovo učitate razmjenu, ispada da centar očekuje da vidi konfiguraciju br. 1 u perifernom čvoru i da će pokušati da je ažurira na konfiguraciju br. 3, ali će u stvari naići na konfiguraciju br. 2 tamo. Ponekad se slična situacija dešava tokom dinamičkog ažuriranja centralne baze podataka. Kao rezultat toga, razmjena će postati nemoguća i dobićete poruku u kojoj se to navodi Konfiguracija distribuiranog informacijskog sigurnosnog čvora ne odgovara očekivanoj!
Općenito, moral ove priče je jednostavan - nemojte aktivno pročišćavati radnu bazu podataka, a ako to učinite, završite sve sesije razmjene prije nego što napravite sljedeće izmjene. Ali šta ako se takva smetnja ipak dogodi?
Jednostavno rješenje je kreiranje nove slike slave čvora, ali u praksi to obično nije primjenjivo. Po pravilu se pojava ozbiljne greške u toku razmene ne detektuje odmah, već neko vreme nakon što prestanu da pristižu operativni podaci iz perifernih baza podataka. Ovisno o rasporedu komunikacije, može proći cijeli radni dan ili više od trenutka kada se problem pojavi do njegovog otkrivanja.
Ovdje vrijedi baciti kamen na programere, koji to prijavljuju kao grešku i ističu situaciju crvenom bojom na isti način Broj poruke je manji ili jednak broju prethodno primljene poruke, što je generalno sasvim normalno. Kao rezultat toga, percepcija grešaka kod korisnika je otupljena, te jednostavno prestaju čitati prikazane poruke, vjerujući da je sve u redu i da druga strana još nije izvršila razmjenu.
No, vratimo se na našu grešku. Rješenje je prilično jednostavno i leži na površini: dovedite konfiguraciju periferne baze na očekivanu, tj. uskladiti ga sa konfiguracijom centralnog čvora. Ali u praksi to nije tako lako. Ako otvorimo perifernu bazu podataka u konfiguratoru, vidjet ćemo da su promjene blokirane od strane alata za upravljanje RIB-om.
Da biste promijenili konfiguraciju slave čvora, morat ćete ga privremeno isključiti iz centralne baze. U ove svrhe možete koristiti jednu od opcija obrade, koje su u izobilju dostupne na mreži, ili isključiti informacijsku sigurnost sa centralnog čvora koristeći parametar za pokretanje konfiguratora/ResetMasterNode.
Otvorite komandnu liniju i unesite (uzimajući u obzir verziju platforme i stvarnu putanju instalacije):
"C:\Program Files (x86)\1cv8\8.3.6.2100\bin\1cv8.exe" konfiguracija /ResetMasterNodeNakon izvršenja ove naredbe, pojavit će se uobičajeni početni prozor, tamo odaberite željenu bazu i kliknite gumb Conifgurator.
Istovremeno pokretanje informacione sigurnosti neće se desiti, tj. može se činiti da se ništa nije dogodilo, ali ponovnim otvaranjem baze podataka u konfiguratoru možete se uvjeriti da je isključena s glavnog čvora i da je dostupna za izmjene.
Pažnja! Na platformama 8.3.7 - 8.3.9, izvršavanje ove komande dovodi do pada. Greška je ispravljena u platformi 8.3.10.
Ako se ne želite petljati s komandnom linijom, možete koristiti jedan od donjih tretmana koji je pronađen na internetu, a mi smo napravili samo kozmetičke izmjene; Imajte na umu da je obrada prikladna samo za običnu aplikaciju za konfiguracije na upravljanoj aplikaciji, koristite ključ za pokretanje konfiguratora.
Rad s njim je izuzetno jednostavan, pokrećemo ga u 1C:Enterprise modu, preko Fajl - Otvori, zatim jednostavno pritisnite željeno dugme, u našem slučaju Onemogući glavni čvor.
Sada nam je potrebna najnovija konfiguracija iz centralnog čvora. Za ovo ćemo otvoriti centralna informaciona bezbednost u konfiguratoru i izvršite Konfiguracija - Sačuvajte konfiguraciju u datoteku. Rezultirajuća datoteka s ekstenzijom cf morat će se prenijeti na periferni čvor.
Zatim, u perifernom čvoru, pokrećemo informacijsku sigurnost (prethodno je isključili iz glavnog čvora) u konfiguratoru i uklanjamo je iz podrške. Da biste to učinili, odaberite: Konfiguracija - Podrška - Podešavanje podrške.
U prozoru koji se otvori prvo omogućite opcije uređivanja.
Zatim uklanjamo konfiguraciju iz podrške.
Sada možete učitati konfiguraciju iz datoteke, da biste to učinili, odaberite Konfiguracija - Učitajte konfiguraciju iz datoteke i ukazuju da se ne prenosi iz centralnog čvora cf-file. Nakon toga ćete dobiti upozorenje da trenutna konfiguracija nije prazna. Imajte na umu da su manipulacije koje izvodimo potencijalno opasne i mogu dovesti do nepovratne štete po sigurnost informacija, pa prije nego što nastavite, provjerite imate li ažurnu rezervnu kopiju.
Prvo, evo liste skraćenica koje koristim:
- RIB - distribuirana informaciona baza
- CB - centralna baza, korijenski čvor RIB-a
- UB - udaljena baza, baza podataka udaljenog RIB čvora
Iz vlastitog iskustva mogu reći da sam naišao na dva razloga za grešku:
- Prilikom prijema datoteke sa porukom, baza podataka je “pala” u sistemu upravljanja, pa je, po svemu sudeći, došlo do desinhronizacije između konf. Centralna banka i UB;
- pod MSSQL, klijent je preuzeo kopiju radne baze podataka i nije isključio reg. zadaci automatske razmjene, kao rezultat toga, neke poruke udaljenim čvorovima generirane su iz radne baze podataka, a neke iz kopije, što je dovelo do desinhronizacije konfiguracija
Postoji i mišljenje da je ova greška uzrokovana upotrebom mehanizma dinamičkog ažuriranja baze podataka. Ovdje postoje sumnje, jer s jedne strane, dinamičko ažuriranje nikada ne utiče na strukturu baze podataka, a RIB mehanizmi i dalje rade sa strukturom baze podataka, a ne sa njenim primijenjenim dijelom, RIB koristi mehanizam za generiranje digitalnog potpisa; verziju konfiguracije (u budućnosti ću je skraćeno zvati hash), a kada se promijeni dio aplikacije, heš se naravno mora ponovo izračunati. Neću to ni demantovati ni tvrditi, jer... Ako sam se susreo sa ovom situacijom, nisam našao nijedan jasan dokaz za to.
Da to ispravim, koristim 2 metode, ovisno o situaciji.
PRVA TEHNIKA
Prvi (najčešći) se više puta spominje i na partnerskoj konferenciji i na drugim internetskim resursima koji se odnose na 1C. Koristi se u većini slučajeva kada, uprkos poruci o odstupanjima u konfiguracijama, ručno poređenje pokaže da su one identične.
Slijed:
- učitajte cf fajl iz centralne banke;
- odvajamo UB od RIB-a (metoda Set MainNode, gotova obrada se može naći u aplikaciji ili u drugim publikacijama);
- zamjena konf. UB u cf fajl koji je učitan u prvom koraku, za ovo koristimo meni „Učitaj konfiguraciju iz datoteke“ (a ne poređenje-spajanje!!!);
- Vratimo RIB znak za UX.
U većini slučajeva, ove radnje su više nego dovoljne za obnavljanje razmjene, ali ne uvijek...
DRUGA METODA
Koristi se ako prva metoda nije uspjela i nije moguće ponovno istovariti čvor.
Pozadina: klijent je postavljao kaskadni RIB i došlo je do greške na prvom nivou kaskade (drugi nivo je radio besprekorno sve ovo vreme). Konfiguracija je razvijena u saradnji sa IT servisom klijenta, a od kada je došlo do greške, konfiguracija centralne banke se više puta mijenjala. Opcija vraćanja izmjena nije razmatrana čak ni u principu, jer gubitak nekih podataka i gašenje nekoliko odjela bilo je potpuno neprihvatljivo. Prva opcija za ispravljanje greške nije dala nikakve opipljive rezultate. Stoga smo morali tražiti druga rješenja.
Došla je ideja da se pokuša zamijeniti heš konfiguracijskih datoteka direktno u XML datotekama za razmjenu. Opis strukture datoteke za razmjenu iz knjige "Profesionalni razvoj u sistemu 1C:Enterprise 8" dao je slabu ideju o formiranju digitalnih potpisa konfiguracija i promjenama u njima, ali je odredio smjer kretanja. traži: vrijednosti Digest1 i Digest2. Sve ostalo sam shvatio čisto empirijski (odnosno, pokušajem i greškom), ali je bilo moguće uspostaviti obrazac.
Probni eksperimenti su bili uspješni. I na radnim bazama je sve dobro prošlo.
Dakle, redoslijed radnji:
- izvršiti korake 1 - 4 prve metode;
- Učitavamo fajl za razmjenu iz UB-a, ali ga ne učitavamo u Centralnu banku;
- Učitavamo datoteku za razmjenu iz Centralne banke, ali je ne učitavamo u UB;
- u datoteci za razmjenu iz Centralne banke, blok koji sadrži informacije o promjenama konfiguracije i hashovima (Digest1 i Digest2) zamjenjujemo blokom hashova iz UB datoteke (vidi primjer ispod)
- Učitavamo fajl od 4. tačke u UB;
- Obavezno prebrišite datoteku za razmjenu sa UB (2. tačka)! ovaj fajl ne treba preuzimati prilikom razmjene sa Centralnom bankom!
- Da bismo provjerili, vršimo nekoliko uzastopnih razmjena.
Ako se tokom razmjene koristi kompresija podataka, tada ili deaktiviramo kompresiju, ili prvo raspakujemo datoteku, promijenimo je, zatim je pakujemo nazad i šaljemo.
Blok datoteka za razmjenu od Centralne banke
treba zamijeniti blokom datoteke za razmjenu sa UB (imajte na umu da je Digest1 za datoteku iz UB uvijek jednak "000000000000000000000000000000000"!!!)
Navedene radnje moraju se izvoditi s krajnjim oprezom; nepravilan redoslijed može rezultirati potpunom nefunkcionalnošću RIB-a. Stoga, prije ovih radnji, pravljenje rezervnih kopija je OBAVEZNO!
Za ostalo mogu samo da vam poželim sreću!
