Prečo sa chyba vyskytuje?

Pre platformy 1C 8.x, keď sa vyskytne chyba „Konfigurácia distribuovaného informačného bezpečnostného uzla nezodpovedá očakávanej“

Metodika riešenia problému

Zoznam skratiek, ktoré používam:
RIB - distribuovaná informačná základňa
CB - centrálna báza, koreňový uzol RIB
UB - vzdialená základňa, databáza vzdialeného uzla RIB

Z vlastnej skúsenosti môžem povedať, že som narazil na dva dôvody chyby:
Počas príjmu súboru správ „spadla“ databáza v systéme riadenia, a preto zrejme došlo k desynchronizácii medzi konf. centrálna banka a UB;
pod MSSQL si klient stiahol kópiu pracovnej databázy a nevypol reg. úlohy automatickej výmeny, v dôsledku toho boli niektoré správy pre vzdialené uzly generované z pracovnej databázy a niektoré z kópie, čo viedlo k desynchronizácii konfigurácií
Existuje tiež názor, že táto chyba je spôsobená použitím mechanizmu dynamickej aktualizácie databázy. Tu sú pochybnosti, pretože na jednej strane dynamická aktualizácia nikdy neovplyvňuje štruktúru databázy a mechanizmy RIB stále pracujú so štruktúrou databázy, a nie s jej aplikovanou časťou, napriek tomu RIB používa mechanizmus na generovanie digitálneho podpisu verziu konfigurácie (v budúcnosti to budem skrátene nazývať hash) a keď sa zmení aplikačná časť, hash sa musí samozrejme prepočítať. Nebudem to popierať ani tvrdiť, pretože... Ak som sa s touto situáciou stretol, nenašiel som o tom žiadny jasný dôkaz.

Na nápravu používam 2 spôsoby, podľa situácie.

PRVÁ TECHNIKA

Prvý (najbežnejší) sa opakovane spomína na partnerskej konferencii aj na iných internetových zdrojoch súvisiacich s 1C. Používa sa vo väčšine prípadov, keď napriek hláseniu o nezrovnalostiach v konfiguráciách manuálne porovnanie ukáže, že sú totožné.

Sekvenovanie:

1. stiahnuť súbor cf z centrálnej banky;
2. odpojiť UB od RIB (metóda Set MainNode, hotové spracovanie nájdete v prílohe alebo v iných publikáciách);
3. nahradiť konf. UB do súboru cf nahraného v prvom kroku, na tento účel používame ponuku „Načítať konfiguráciu zo súboru“ (a nie porovnanie-zlúčiť!!!);
4. obnovte atribút RIB pre UX.
Vo väčšine prípadov sú tieto akcie viac než dostatočné na obnovenie výmeny, ale nie vždy...

DRUHÝ SPÔSOB

Používa sa, ak prvá metóda nefungovala a uzol nie je možné znova vyložiť.

Takže postupnosť akcií:

1. vykonajte kroky 1 až 4 prvého spôsobu;
2. vyložiť výmenný súbor z UB, ale nenačítať ho do centrálnej banky;
3. vyložiť výmenný súbor z centrálnej banky, ale nenačítať ho do MB;
4. vo výmennom súbore od centrálnej banky nahradíme blok obsahujúci informácie o zmenách konfigurácie a hashoch (Digest1 a Digest2) blokom hashov zo súboru UB (pozri príklad nižšie)
5. Nahráme súbor zo 4. bodu do UB;
Uistite sa, že ste prepísali výmenný súbor z UB (2. bod)! tento súbor by sa nemal sťahovať pri výmene s centrálnou bankou!
Pre kontrolu vykonáme niekoľko po sebe nasledujúcich výmen.

Ak sa pri výmene používa kompresia dát, tak buď kompresiu vypneme, alebo súbor najprv rozbalíme, zmeníme, potom zabalíme a odošleme.
Výmenný blok súboru z centrálnej banky

106.0...tu sú bloky popisujúce zmeny konfigurácie... 1cf680807e97a5dc0d1ed7f901b07392 038211651cf680807e97a5dc0d1ed7f9

je potrebné nahradiť blokom výmenného súboru z UB (všimnite si, že Digest1 pre súbor z UB sa vždy rovná „00000000000000000000000000000000“!!!)

106.0 00000000000000000000000000000000 11651cf680807e97a5dc0d1ed7f901b0

Uvedené činnosti sa musia vykonávať s mimoriadnou opatrnosťou; nesprávna postupnosť môže viesť k úplnej nefunkčnosti RIB. Preto je pred týmito akciami vytváranie záložných kópií POVINNÉ!

Na organizáciu práce pobočiek a divízií sa často používa distribuovaná informačná základňa (DIB), ktorá umožňuje rýchlu výmenu informácií pri zachovaní požadovaného stupňa autonómie. Napriek tomu, že táto technológia je celkom spoľahlivá, z času na čas sa pokazí. Dnes sa pozrieme na jednu z pomerne častých chýb: Povieme vám o dôvodoch jej výskytu a spôsoboch jej riešenia.

Začnime ako vždy od začiatku. Po vytvorení RIB je možné všetky zmeny konfigurácie informačnej databázy vykonať iba v hlavnom uzle. Následne sa pri ďalšej výmene všetky zmeny prenesú do podriadených uzlov a tam sa automaticky aplikujú. Ale na papieri to bolo hladké...

V praxi sa niekedy stáva, že medzi výmennými reláciami, najmä ak je kanál na periférii zlý, sa konfigurácia hlavného uzla stihne zmeniť dvakrát. Napríklad vykonali zmeny, nahrali ich, periférna databáza prijala zmeny, ale ešte ich neaplikovala, čo môže chvíľu trvať, a ešte neposlala potvrdenie. Ak počas tohto obdobia znova vykonáte zmeny a znova nahráte výmenu, ukáže sa, že centrum očakáva, že v periférnom uzle uvidí konfiguráciu č. 1 a pokúsi sa ju aktualizovať na konfiguráciu č. 3, ale v skutočnosti narazí na konfiguráciu č. 2 tam. Niekedy k podobnej situácii dochádza pri dynamickej aktualizácii centrálnej databázy. V dôsledku toho bude výmena nemožná a dostanete správu, v ktorej sa uvádza Konfigurácia distribuovaného informačného bezpečnostného uzla sa nezhoduje s očakávanou!

Vo všeobecnosti je morálka tohto príbehu jednoduchá – nevylepšujte aktívne fungujúcu databázu, a ak áno, dokončite všetky výmenné stretnutia pred vykonaním ďalších zmien. Ale čo ak sa takáto nepríjemnosť predsa len stane?

Priamočiarym riešením je vytvorenie nového obrazu podriadeného uzla, ale v praxi to zvyčajne nie je použiteľné. Výskyt závažnej chyby pri výmene sa spravidla nezistí okamžite, ale až po určitom čase, keď prestanú prichádzať prevádzkové údaje z periférnych databáz. V závislosti od plánu komunikácie môže medzi objavením sa problému a jeho zistením uplynúť celý pracovný deň alebo aj viac.

Tu sa oplatí hodiť kameňom do vývojárov, ktorí to nahlásia ako chybu a rovnakým spôsobom zvýraznia situáciu červenou farbou Číslo správy je menšie alebo rovné číslu predtým prijatej správy, čo je vo všeobecnosti celkom normálne. V dôsledku toho je vnímanie chýb zo strany používateľov otupené a zobrazené správy jednoducho prestanú čítať v domnení, že je všetko v poriadku a že druhá strana ešte neuskutočnila výmenu.

Ale vráťme sa k našej chybe. Riešenie je celkom jednoduché a leží na povrchu: priviesť konfiguráciu obvodovej základne na očakávanú, t.j. uviesť ho do súladu s konfiguráciou centrálneho uzla. Ale v praxi to nie je také jednoduché. Ak v konfigurátore otvoríme databázu periférií, uvidíme, že zmeny sú blokované nástrojmi na správu RIB.

Ak chcete zmeniť konfiguráciu podriadeného uzla, budete ho musieť dočasne odpojiť od centrálnej základne. Na tieto účely môžete využiť niektorú z možností spracovania, ktoré sú na sieti dostupné, alebo odpojiť informačnú bezpečnosť od centrálneho uzla pomocou parametra spustenia konfigurátora/ResetMasterNode.

Otvorte príkazový riadok a zadajte (berúc do úvahy verziu platformy a skutočnú cestu inštalácie):

"C:\Program Files (x86)\1cv8\8.3.6.2100\bin\1cv8.exe" config /ResetMasterNode

Po vykonaní tohto príkazu sa zobrazí obvyklé štartovacie okno, v ktorom vyberte požadovanú základňu a kliknite na tlačidlo Konifgurátor.

Súčasne spustenie informačnej bezpečnosti sa nestane, t.j. môže sa zdať, že sa nič nestalo, ale opätovným otvorením databázy v konfigurátore sa môžete uistiť, že je odpojená od hlavného uzla a je k dispozícii na vykonanie zmien.

Pozor! Na platformách 8.3.7 - 8.3.9 má vykonanie tohto príkazu za následok zlyhanie. Chyba bola opravená na platforme 8.3.10.

Ak sa nechcete motať s príkazovým riadkom, môžete použiť jednu z procedúr; nižšie je tá, ktorú používame; bola nájdená na internete a urobili sme na nej iba kozmetické úpravy. Upozorňujeme, že spracovanie je vhodné len pre bežnú aplikáciu, pre konfigurácie v riadenej aplikácii použite kláves na spustenie konfigurátora.

Práca s ním je mimoriadne jednoduchá, spúšťame ho v režime 1C:Enterprise, cez Súbor - Otvoriť, potom jednoducho stlačte požadované tlačidlo, v našom prípade Zakázať hlavný uzol.

Teraz potrebujeme najnovšiu konfiguráciu z centrálneho uzla. Za týmto účelom otvoríme centrálna informačná bezpečnosť v konfigurátore a spustite Konfigurácia - Uloženie konfigurácie do súboru. Výsledný súbor s príponou porov bude potrebné odoslať do periférneho uzla.

Potom v periférnom uzle spustíme informačnú bezpečnosť (predtým sme ju odpojili od hlavného uzla) v Konfigurátore a odstránime ju z podpory. Ak to chcete urobiť, vyberte: Konfigurácia - Podpora - Nastavenie podpory.

V okne, ktoré sa otvorí, najprv povoľte možnosti úprav.

A potom odstránime konfiguráciu z podpory.

Teraz môžete načítať konfiguráciu zo súboru, ak to chcete urobiť, vyberte Konfigurácia – načítanie konfigurácie zo súboru a indikujú nevysielané z centrálneho uzla porov- súbor. Potom dostanete upozornenie, že aktuálna konfigurácia nie je prázdna. Upozorňujeme, že manipulácie, ktoré vykonávame, sú potenciálne nebezpečné a môžu viesť k nezvratnému poškodeniu informačnej bezpečnosti, preto sa pred pokračovaním uistite, že máte aktuálnu záložnú kópiu.

Najprv uvádzam zoznam skratiek, ktoré používam:

RIB - distribuovaná informačná základňa
CB - centrálna báza, koreňový uzol RIB
UB - vzdialená základňa, databáza vzdialeného uzla RIB

Z vlastnej skúsenosti môžem povedať, že som narazil na dva dôvody chyby:

Pri prijímaní súboru správ databáza „spadla“ do riadiaceho systému, a preto zrejme došlo k desynchronizácii medzi konf. centrálna banka a UB;
pod MSSQL si klient stiahol kópiu pracovnej databázy a nevypol reg. úlohy automatickej výmeny, v dôsledku toho boli niektoré správy pre vzdialené uzly generované z pracovnej databázy a niektoré z kópie, čo viedlo k desynchronizácii konfigurácií

Existuje tiež názor, že táto chyba je spôsobená použitím mechanizmu dynamickej aktualizácie databázy. Tu sú pochybnosti, pretože na jednej strane dynamická aktualizácia nikdy neovplyvňuje štruktúru databázy a mechanizmy RIB stále pracujú so štruktúrou databázy, a nie s jej aplikovanou časťou, napriek tomu RIB používa mechanizmus na generovanie digitálneho podpisu verziu konfigurácie (v budúcnosti to budem skrátene nazývať hash) a keď sa zmení aplikačná časť, hash sa musí samozrejme prepočítať. Nebudem to popierať ani tvrdiť, pretože... Ak som sa s touto situáciou stretol, nenašiel som o tom žiadny jasný dôkaz.

Na nápravu používam 2 spôsoby, podľa situácie.

PRVÁ TECHNIKA

Sekvenovanie:

vyložiť súbor cf z centrálnej banky;
odpojíme UB od RIB (metóda Set MainNode, hotové spracovanie nájdete v aplikácii alebo v iných publikáciách);
nahradenie konf. UB do súboru cf nahraného v prvom kroku, na tento účel používame ponuku „Načítať konfiguráciu zo súboru“ (a nie porovnanie-zlúčiť!!!);
Obnovme znak RIB pre UX.

Vo väčšine prípadov sú tieto akcie viac než dostatočné na obnovenie výmeny, ale nie vždy...

DRUHÝ SPÔSOB

Používa sa, ak prvá metóda nefungovala a uzol nie je možné znova vyložiť.

Pozadie: klient nastavoval kaskádový RIB a v prvej úrovni kaskády sa vyskytla chyba (druhá úroveň fungovala celý čas bezchybne). Konfigurácia bola vyvinutá spoločne s IT službou klienta a od vzniku chyby sa konfigurácia centrálnej banky niekoľkokrát zmenila. S možnosťou vrátenia zmien sa ani v zásade neuvažovalo, pretože strata niektorých údajov a odstávka niekoľkých oddelení bola úplne neprijateľná. Prvá možnosť na opravu chyby nepriniesla žiadne hmatateľné výsledky. Preto sme museli hľadať iné riešenia.

Prišiel nápad pokúsiť sa nahradiť hashe konfiguračných súborov priamo vo výmenných súboroch XML. Opis štruktúry výmenného súboru z knihy „Profesionálny vývoj v systéme 1C:Enterprise 8“ poskytol slabú predstavu o vytváraní digitálnych podpisov konfigurácií a zmien v nich, ale určil smer vyhľadávanie: hodnoty Digest1 a Digest2. Na všetko ostatné som prišiel čisto empiricky (teda pokusom a omylom), ale bolo možné stanoviť vzorec.

Testovacie experimenty boli úspešné. Na pracovných základniach tiež išlo všetko dobre.

Takže postupnosť akcií:

vykonajte kroky 1 až 4 prvého spôsobu;
Uvoľníme výmenný súbor z UB, ale nenačítame ho do centrálnej banky;
Vykladáme výmenný súbor z centrálnej banky, ale nenačítavame ho do UB;
vo výmennom súbore od centrálnej banky nahradíme blok obsahujúci informácie o zmenách konfigurácie a hashoch (Digest1 a Digest2) blokom hashov zo súboru UB (pozri príklad nižšie)
Nahráme súbor zo 4. bodu do UB;
Uistite sa, že ste prepísali výmenný súbor z UB (2. bod)! tento súbor by sa nemal sťahovať pri výmene s centrálnou bankou!
Pre kontrolu vykonáme niekoľko po sebe nasledujúcich výmen.

Ak sa pri výmene používa kompresia dát, tak buď kompresiu vypneme, alebo súbor najprv rozbalíme, zmeníme, potom zabalíme a odošleme.

Výmenný blok súboru z centrálnej banky

106.0
...tu sú bloky popisujúce zmeny konfigurácie...
1cf680807e97a5dc0d1ed7f901b07392
038211651cf680807e97a5dc0d1ed7f9

je potrebné nahradiť blokom výmenného súboru z UB (všimnite si, že Digest1 pre súbor z UB sa vždy rovná "0000000000000000000000000000000"!!!)

106.0
00000000000000000000000000000000
11651cf680807e97a5dc0d1ed7f901b0

Vo zvyšku vám môžem zaželať len veľa šťastia!

Dobrý deň, milí čitatelia nášho blogu! Dnes budeme hovoriť o
oprava dvoch chýb ktoré môžu vzniknúť počas výmeny v distribuovanej informačnej báze (RIB). Takéto chyby sa môžu vyskytnúť, ak ste zmenili konfiguráciu vašej databázy a pokúšate sa preniesť tieto zmeny z centrálnej databázy do periférnej. Napríklad spôsobom, ktorý bol popísaný. Začnime!

Toto sú správy, ktoré sa môžu zobraziť, keď sa pokúsite uskutočniť výmenu pomocou RIB:

„Údaje sa prijímajú z uzla, pre ktorý
zmeny konfigurácie boli zaznamenané.
Zmeny je potrebné preniesť
konfigurácie do uzla."

“Konfigurácia uzla zabezpečenia distribuovaných informácií
nie podľa očakávania!"

Pozrime sa na kroky, ktoré pomôžu situáciu napraviť. Skôr ako začneme, vytvorme si našu informačnú databázu!!!

Vezmeme konfiguračný súbor s aktualizáciou, otvoríme centrálnu databázu v Konfigurátore a načítame ju (Konfigurácia-Načítať konfiguráciu zo súboru...). Uložme informačnú bezpečnosť (F7).
Poďme a nahrajte súbor pre periférnu databázu:
- V zozname vyberte plán výmeny, potom kliknutím pravým tlačidlom myši otvorte kontextové menu a vyberte „Uložiť zmeny...“.
Teraz sa poďme zaoberať bezpečnosťou periférnych informácií. Otvorme ho v exkluzívnom režime, aby neexistovali žiadni používatelia, a tiež zatvorme konfigurátor. Teraz si musíte zapamätať uzol, ktorý je hlavný pre aktuálnu databázu. Otvoriť Operácie – Výmenné plány – Vyberte si plán výmeny (napríklad „Podľa skladu“). V zozname výmenných plánov je hlavným uzlom položka so žltou ikonou. Tieto informácie sa nám budú hodiť v siedmom bode. Otvorme spracovanie a kliknite na tlačidlo „Zrušiť priradenie hlavného uzla“.
Teraz otvorme zabezpečenie periférnych informácií v Konfigurátore a načítajme rovnaký konfiguračný súbor, aký sme načítali v prvom kroku do centrálnej databázy (Konfigurácia-Načítať konfiguráciu zo súboru...). Uložme informačnú bezpečnosť (F7).
Zmeňme nastavenia podpory (Konfigurácia-Podpora-Nastavenia podpory...). V dialógovom okne vyberte bunku v tabuľke na priesečníku prvého riadka a druhého stĺpca. Potom dvojitým kliknutím otvorte dialógové okno „Nastavenia pravidiel podpory“. V ňom začiarknite príznak „Inštalovať pre podriadené objekty“ a kliknite na tlačidlo „OK“. Zatvorte dialógové okno s nastaveniami podpory kliknutím na tlačidlo „Zavrieť“. Uložiť IB (F7). Zatvorme konfigurátor.
Teraz znova otvorme zabezpečenie periférnych informácií v exkluzívnom režime 1C:Enterprise, aby neexistovali žiadni používatelia, a tiež zatvorte konfigurátor. Otvoríme spracovanie Inštalácia MainNodeDB.epf a vyberieme výmenný plán, ktorý chceme nainštalovať ako hlavný uzol (v štvrtom bode sme si tento uzol zapamätali). Potom kliknite na tlačidlo „Inštalovať hlavný uzol“. Potom sa súčasná informačná bezpečnosť opäť stane periférnou.
Teraz v aktuálnom informačnom zabezpečení (periférne) otvoríme plány výmeny a stiahneme súbor s burzou z Centrálnej databázy, ktorú sme dostali v treťom kroku:
- Operácie-Výmenné plány-Vyberte náš plán výmeny (napríklad „Podľa skladu“).
Ak všetko prebehlo dobre, nahráme výmenu do centrálnej databázy v aktuálnom informačnom zabezpečení (periférne):
- Operácie-Výmenné plány-Vyberte náš plán výmeny (napríklad „Podľa skladu“).
- V zozname vyberte plán výmeny, potom kliknutím pravým tlačidlom myši otvorte kontextové menu a vyberte „Uložiť zmeny...“.
- V dialógovom okne uveďte cestu a názov výmenného súboru. Kliknite na tlačidlo „OK“.
Teraz sa pokúsime načítať tento súbor do centrálnej databázy a otvoriť ho v režime 1C: Enterprise:
- Operácie-Výmenné plány-Vyberte náš plán výmeny (napríklad „Podľa skladu“).
- V zozname vyberte plán výmeny - Kliknutím pravým tlačidlom myši vyvolajte kontextové menu a vyberte možnosť „Prečítať zmeny...“
- V dialógovom okne vyberte výmenný súbor. Kliknite na tlačidlo „OK“.

Ak chcete predísť problémom s pracovnými kópiami, urobte to najskôr

Najprv zoznam použitých skratiek:

RIB - distribuovaná informačná základňa
CB - centrálna báza, koreňový uzol RIB
UB - vzdialená základňa, databáza vzdialeného uzla RIB

Z vlastnej skúsenosti môžem povedať, že som narazil na dva dôvody chyby:

Pri prijímaní súboru správ databáza „spadla“ do riadiaceho systému, a preto zrejme došlo k desynchronizácii medzi konf. centrálna banka a UB;
pod MSSQL si klient stiahol kópiu pracovnej databázy a nevypol reg. úlohy automatickej výmeny, v dôsledku toho boli niektoré správy pre vzdialené uzly generované z pracovnej databázy a niektoré z kópie, čo viedlo k desynchronizácii konfigurácií

Na nápravu používam 2 spôsoby, podľa situácie.

PRVÁ TECHNIKA

Sekvenovanie:

vyložiť súbor cf z centrálnej banky;
odpojíme UB od RIB (metóda Set MainNode, hotové spracovanie nájdete v aplikácii alebo v iných publikáciách);
nahradenie konf. UB do súboru cf nahraného v prvom kroku, na tento účel používame ponuku „Načítať konfiguráciu zo súboru“ (a nie porovnanie-zlúčiť!!!);
Obnovme znak RIB pre UX.

Vo väčšine prípadov sú tieto akcie viac než dostatočné na obnovenie výmeny, ale nie vždy...

DRUHÝ SPÔSOB

Používa sa, ak prvá metóda nefungovala a uzol nie je možné znova vyložiť.

Testovacie experimenty boli úspešné. Na pracovných základniach tiež išlo všetko dobre.

Takže postupnosť akcií:

vykonajte kroky 1 až 4 prvého spôsobu;
Uvoľníme výmenný súbor z UB, ale nenačítame ho do centrálnej banky;
Vykladáme výmenný súbor z centrálnej banky, ale nenačítavame ho do UB;
vo výmennom súbore od centrálnej banky nahradíme blok obsahujúci informácie o zmenách konfigurácie a hashoch (Digest1 a Digest2) blokom hashov zo súboru UB (pozri príklad nižšie)
Nahráme súbor zo 4. bodu do UB;
Uistite sa, že ste prepísali výmenný súbor z UB (2. bod)! tento súbor by sa nemal sťahovať pri výmene s centrálnou bankou!
Pre kontrolu vykonáme niekoľko po sebe nasledujúcich výmen.

Ak sa pri výmene používa kompresia dát, tak buď kompresiu vypneme, alebo súbor najprv rozbalíme, zmeníme, potom zabalíme a odošleme.

Výmenný blok súboru z centrálnej banky

106.0
...tu sú bloky popisujúce zmeny konfigurácie...
1cf680807e97a5dc0d1ed7f901b07392
038211651cf680807e97a5dc0d1ed7f9

je potrebné nahradiť blokom výmenného súboru z UB (všimnite si, že Digest1 pre súbor z UB sa vždy rovná "0000000000000000000000000000000"!!!)

106.0
00000000000000000000000000000000
11651cf680807e97a5dc0d1ed7f901b0