Konfiguracija ne ustreza pričakovanemu 1s 8
Napake pri dinamičnem posodabljanju (ali druge napake platforme) so lahko vzrok za napake izmenjave porazdeljene informacijske baze:
"Podatki so prejeti iz vozlišča, za katerega so bile registrirane spremembe konfiguracije"
"Konfiguracija vozlišča porazdeljene informacijske varnosti ne ustreza pričakovanemu"
Kako obnoviti menjavo?
Toda ne začnimo z obnovo, ampak s priložnostjo za izvedbomenjava "ročno", kar je pomembno čez dan, saj mora, kot vedno, vse delovati "včeraj" :) To je mogoče storiti s pomočjo čudovitih tretmajev, ki se jih nisem spomnilnude, kjer sem ga prenesel (avtorji, odgovorite - pustil bom povezave do vašega vira in po potrebi ga bom izbrisal iz svojega). Obdelava omogoča prenos samo registriranih sprememb podatkov v bazo (v skladu z določenim načrtom izmenjave za določeno vozlišče!) v XML brez prenosa konfiguracijskih sprememb in, če se konfiguracijski objekti niso veliko spremenili, obstaja zelo velika možnost nalaganja teh podatkov. Te lahko prenesete s povezave na koncu članka.
Kar se tiče okrevanja. Obstajajo preprostejše metode, ki ne vključujejo vseh elementov na spodnjem seznamu, vendar ne pomagajo vedno, kot je bilo v enem od mojih primerov. Zato predstavljam metodo, ki mi je pomagala; morebitne težave obide na celovitejši način. Naslednji korak za korakom.
Priporočljivo je, da te korake izvedete, ko v bazi podatkov ni delujočih uporabnikov. Če to ni mogoče, boste morali metodo »dokončati« sami, zato morate najprej razumeti njeno logiko.
1. Povsod naredite varnostne kopije.
2. Za odjemalec-strežnike: onemogočite podatkovne baze prek “administracije strežnika” in jih takoj povežite z blokiranjem načrtovanih opravil (to bo ponastavilo predpomnilnik strežnika). Po tem ne pozabite prenesti registracijskega dnevnika v nov imenik.
3. Na vseh računalnikih, uporabljenih za obnovitev, izbrišite bazo podatkov na seznamu začetnih baz podatkov 1C in ustvarite novo (uporabniški predpomnilnik bo počiščen)
4. V konfiguratorju (v centralni bazi podatkov) dodajte novo konstanto in shranite spremembe conf.
5. Počistite vse izmenjevalne imenike.
6. Izvedite raztovarjanja v vse veje (zaenkrat samo raztovarjanja).
7. Poskusite prenesti (samo prenesti) prejete podatke v vse poslovalnice. Sprejemanje sprememb conf je naravno.
Če je povsod vse v redu, gremo naprej; če je vse slabo, menimo, da bi lahko pomagalo raztovarjanje .cf iz centralne baze podatkov in NALAGANJE v vejo (ne primerjanje-združevanje). V podrejenem vozlišču morate prekiniti povezavo baze podatkov z RIB (pri tem bo pomagala obdelava - prenesite s spodnje povezave). Na infostart.ru je članek o tej temi.
8. Prekličemo registracijo sprememb za podružnice v Centralni banki (navsezadnje smo povsod že prejeli vse spremembe). Na tej stopnji je pomembno, da nabrane spremembe iz različnih vej pridejo v druge veje. (prenesite obdelavo za razvezo-vezavo s spodnje povezave).
9. Naložimo v centralno banko in če je vse v redu, nato večkrat naložimo in razkladamo z vsako vejo, da utrdimo rezultat.
10. To je to.
Omogočite lahko izvajanje rutinskih nalog za baze podatkov odjemalec-strežnik.
Da preprečite težave, ki povzročajo to napako, je priporočljivo, da ne izvajate dinamičnih posodobitev (vsaj večkrat zaporedoma - dokler se spremembe ne naložijo v veje), prav tako je priporočljivo označiti polje "naloži podatke samo ob uspešnem nalaganju" v nastavitvah izmenjave.
Najprej je tukaj seznam okrajšav, ki jih uporabljam:
- RIB - porazdeljena informacijska baza
- CB - centralna baza, korensko vozlišče RIB
- UB - oddaljena baza, baza podatkov oddaljenega RIB vozlišča
Iz lastnih izkušenj lahko povem, da sem naletel na dva razloga za napako:
- Pri prejemu sporočilne datoteke je baza podatkov »padla« v sistem upravljanja in zato je očitno prišlo do desinhronizacije med konf. Centralna banka in UB;
- pod MSSQL je klient prenesel kopijo delujoče baze in ni izklopil reg. opravila samodejne izmenjave, zaradi česar so bila nekatera sporočila oddaljenim vozliščem ustvarjena iz delujoče baze podatkov, nekatera pa iz kopije, kar je povzročilo desinhronizacijo konfiguracij
Obstaja tudi mnenje, da je to napako posledica uporabe mehanizma za dinamično posodabljanje baze podatkov. Tu obstajajo dvomi, ker po eni strani dinamično posodabljanje nikoli ne vpliva na strukturo baze podatkov in mehanizmi RIB še vedno delujejo s strukturo baze podatkov in ne z njenim uporabnim delom; kljub temu pa RIB uporablja mehanizem za generiranje digitalnega podpisa različico konfiguracije (v prihodnje jo bom na kratko imenoval hash), in ko se del aplikacije spremeni, je treba hash seveda znova izračunati. Tega ne bom niti zanikal niti pritrdil, ker... Če sem naletel na to situacijo, nisem našel jasnih dokazov o tem.
Za popravek uporabljam 2 načina, odvisno od situacije.
PRVA TEHNIKA
Prvi (najpogostejši) se večkrat omenja tako na partnerski konferenci kot na drugih internetnih virih, povezanih z 1C. Uporablja se v večini primerov, ko kljub sporočilu o neskladju v konfiguracijah ročna primerjava pokaže, da so enake.
Zaporedje:
- odstranite datoteko cf iz centralne banke;
- prekinemo povezavo UB z RIB (metoda Set MainNode, že pripravljeno obdelavo najdete v aplikaciji ali v drugih publikacijah);
- zamenjava konf. UB v datoteko cf, naloženo v prvem koraku, za to uporabimo meni »Naloži konfiguracijo iz datoteke« (in ne primerjava-spoj!!!);
- Obnovimo znak RIB za UX.
V večini primerov so ta dejanja več kot dovolj za obnovitev izmenjave, vendar ne vedno ...
DRUGA METODA
Uporablja se, če prva metoda ni delovala in vozlišča ni mogoče znova razbremeniti.
Ozadje: naročnik je postavljal kaskadni RIB in je prišlo do napake na prvem nivoju kaskade (drugi nivo je ves ta čas deloval brezhibno). Konfiguracija je bila razvita skupaj z IT službo naročnika, odkar je prišlo do napake, pa se je konfiguracija centralne banke večkrat spremenila. Možnost povrnitve sprememb niti načeloma ni bila upoštevana, saj izguba nekaterih podatkov in zaprtje več oddelkov je bila popolnoma nesprejemljiva. Prva možnost za odpravo napake ni dala oprijemljivih rezultatov. Zato smo morali iskati druge rešitve.
Prišla je ideja, da bi poskusili zamenjati zgoščene vrednosti konfiguracijskih datotek neposredno v datotekah za izmenjavo XML. Opis strukture izmenjevalne datoteke iz knjige "Strokovni razvoj v sistemu 1C:Enterprise 8" je dal šibko predstavo o oblikovanju digitalnih podpisov konfiguracij in sprememb v njih, vendar je določil smer iskanje: vrednosti Digest1 in Digest2. Vse ostalo sem ugotovil čisto empirično (torej s poskusi in napakami), vendar je bilo mogoče ugotoviti vzorec.
Testni poskusi so bili uspešni. Tudi v delovnih bazah je šlo vse dobro.
Torej, zaporedje dejanj:
- izvedite korake 1 - 4 prve metode;
- Izmenjalno datoteko odstranimo iz UB, vendar je ne naložimo v Centralno banko;
- Datoteko za izmenjavo odstranimo iz centralne banke, vendar je ne naložimo v UB;
- v izmenjevalni datoteki centralne banke zamenjamo blok z informacijami o spremembah konfiguracije in zgoščenimi vrednostmi (Digest1 in Digest2) z blokom zgoščenih vrednosti iz datoteke UB (glej primer spodaj)
- Datoteko iz 4. točke naložimo v UB;
- Obvezno prepišite izmenjalno datoteko iz UB (2. točka)! te datoteke ne smete prenesti pri izmenjavi s centralno banko!
- Za preverjanje opravimo več zaporednih menjav.
Če se med izmenjavo uporablja stiskanje podatkov, potem onemogočimo stiskanje ali pa datoteko najprej razpakiramo, spremenimo, nato zapakiramo nazaj in pošljemo.
Blok izmenjave datotek iz centralne banke
je treba nadomestiti z blokom borbene datoteke iz UB (upoštevajte, da je Digest1 za datoteko iz UB vedno enak "00000000000000000000000000000000000" !!!) !!!) !!!) !!!)
Navedena dejanja je treba izvajati zelo previdno, nepravilno zaporedje lahko povzroči popolno nedelovanje RIB. Zato je pred temi dejanji OBVEZNO ustvarjanje varnostnih kopij!
Za ostalo pa ti lahko samo želim veliko sreče!
- Sporočilna datoteka je že naložena v prejemno zbirko podatkov. Ponovno ga morate prenesti iz izvorne baze podatkov.
Napaka "Napaka pri kopiranju datoteke iz vira FTP ... Napaka pri delu z internetom: Časovna omejitev je bila dosežena"
- Zahtevane datoteke ni mogoče kopirati s strani, prek katere poteka izmenjava. To je lahko posledica počasnega interneta ali težav s samim mestom.
- Poskusite ponoviti izmenjavo po 15-30 minutah.
Napaka: Urejanje podatkov za to obdobje je prepovedano. Sprememb ni mogoče zabeležiti ..."
- Preneseni podatki vsebujejo dokumente iz zaprtega obdobja.
- Zamenjavo je potrebno izvesti pod uporabniki, ki imajo v tem obdobju pravico spreminjati dokumente.
Napaka: Izvesti je treba posodobitve konfiguracije baze podatkov. Posodobitev je mogoče izvesti v načinu konfiguratorja"
Razlog: programerji so spremenili konfiguracijo v središču. Rešitev: Posodobite spremenjeno konfiguracijo v periferni bazi podatkov. Za to:- Pojdite na konfigurator.
- Izvedite točko menija “Konfigurator / Posodobi konfiguracijo baze podatkov”.
- Če se prikaže vprašanje z odgovori samo »Ponovi«, »Prekliči«, »Dinamično posodobi«, kliknite gumb »Dinamično posodobi«.
- Če je vprašanje podano samo z odgovoroma »Ponovi« in »Prekliči«.
- vsi uporabniki se odjavijo iz 1C.
- pritisnite gumb "Ponovi".
- Na preostala vprašanja odgovorite pritrdilno: "Da", "Sprejmem", "V redu".
- Zaprite konfigurator.
- Ponovite nalaganje od sredine.
Napaka: »Konfiguracija ni pričakovana«, »Poskus sprejetja sprememb iz neznane konfiguracije«
- Napaka baze podatkov.
- Treba se je obrniti na strokovnjake.
Pozdravljeni, dragi bralci našega bloga! Danes bomo govorili o
odpravljanje dveh napak ki lahko nastanejo med izmenjavo v porazdeljeni informacijski bazi (RIB). Do takšnih napak lahko pride, če ste spremenili konfiguracijo vaše baze podatkov in poskušate te spremembe prenesti iz osrednje baze podatkov v periferno. Na primer na opisani način. Začnimo!
To so sporočila, ki se lahko prikažejo, ko poskušate opraviti zamenjavo z uporabo RIB:
"Podatki so prejeti od vozlišča, za katerega
spremembe konfiguracije so bile zabeležene.
Spremembe je treba prenesti
konfiguracije v vozlišče."
»Konfiguracija vozlišča za varnost porazdeljenih informacij
ne po pričakovanjih!"
Oglejmo si korake, ki bodo pomagali popraviti situacijo. Preden začnemo, ustvarimo našo podatkovno bazo!!!
- Vzamemo konfiguracijsko datoteko s posodobitvijo, odpremo centralno bazo v konfiguratorju in jo naložimo (Konfiguracija-Naloži konfiguracijo iz datoteke ...). Rešimo informacijsko varnost (F7).
- Pojdimo in naložimo v datoteko za periferno bazo podatkov:
- Na seznamu izberite načrt izmenjave, nato z desnim klikom odprite kontekstni meni in izberite »Shrani spremembe ...«.
- Zdaj pa se posvetimo varnosti perifernih informacij. Odprimo ga v ekskluzivnem načinu, da ni uporabnikov, in zapremo tudi konfigurator. Zdaj si morate zapomniti vozlišče, ki je glavno za trenutno bazo podatkov. Odprite Operacije-Menjalni načrti-Izberite svoj menjalni načrt (na primer »Po skladišču«). Na seznamu menjalnih načrtov je glavno vozlišče postavka z rumeno ikono. Ti podatki nam bodo koristili pri sedmi točki. Odprimo obdelavo in kliknite gumb »Prekliči dodelitev glavnega vozlišča«.
- Sedaj pa odprimo periferno informacijsko varnost v konfiguratorju in naložimo isto konfiguracijsko datoteko, ki smo jo v prvem koraku naložili v centralno bazo podatkov (Konfiguracija-Naloži konfiguracijo iz datoteke ...). Rešimo informacijsko varnost (F7).
- Spremenimo nastavitve podpore (Konfiguracija-Podpora-Nastavitve podpore ...). V pogovornem oknu izberite celico v tabeli na presečišču prve vrstice in drugega stolpca. Nato dvokliknite, da odprete pogovorno okno »Nastavitve podpornih pravil«. V njem označite zastavico »Namesti za podrejene objekte« in kliknite gumb »V redu«. Zaprite pogovorno okno z nastavitvami podpore s klikom na gumb »Zapri«. Shrani IB (F7). Zaprimo konfigurator.
- Zdaj znova odprimo varnost perifernih informacij v ekskluzivnem načinu 1C:Enterprise, tako da ni uporabnikov, in zaprite tudi konfigurator. Odpremo namestitev obdelave MainNodeDB.epf in izberemo načrt izmenjave, ki ga želimo namestiti kot glavno vozlišče (v četrtem odstavku smo si zapomnili to vozlišče). Nato kliknite gumb »Namesti glavno vozlišče«. Po tem bo trenutna informacijska varnost spet postala obrobna.
- Sedaj bomo v trenutni informacijski varnosti (periferiji) odprli načrte izmenjav in iz centralne baze prenesli datoteko z izmenjavo, ki smo jo prejeli v tretjem koraku:
- Operacije-Menjalni načrti-Izberite naš menjalni načrt (na primer »Po skladišču«).
- Če je šlo vse v redu, bomo zamenjavo za centralno bazo naložili v trenutno informacijsko varnost (periferno):
- Operacije-Menjalni načrti-Izberite naš menjalni načrt (na primer »Po skladišču«).
- Na seznamu izberite načrt izmenjave, nato z desnim klikom odprite kontekstni meni in izberite »Shrani spremembe ...«.
- V pogovornem oknu navedite pot in ime datoteke za izmenjavo. Kliknite gumb »V redu«.
- Zdaj pa poskusimo naložiti to datoteko v centralno bazo podatkov in jo odpreti v načinu 1C:Enterprise:
- Operacije-Menjalni načrti-Izberite naš menjalni načrt (na primer »Po skladišču«).
- Na seznamu izberite načrt izmenjave - z desnim klikom prikličete kontekstni meni in izberite »Preberi spremembe ...«
- V pogovornem oknu izberite izmenjalno datoteko. Kliknite gumb »V redu«.
Da se izognete težavam z delovnimi kopijami, najprej naredite
Najprej seznam uporabljenih okrajšav:
- RIB - porazdeljena informacijska baza
- CB - centralna baza, korensko vozlišče RIB
- UB - oddaljena baza, baza podatkov oddaljenega RIB vozlišča
Iz lastnih izkušenj lahko povem, da sem naletel na dva razloga za napako:
- Pri prejemu sporočilne datoteke je baza podatkov »padla« v sistem upravljanja in zato je očitno prišlo do desinhronizacije med konf. Centralna banka in UB;
- pod MSSQL je klient prenesel kopijo delujoče baze in ni izklopil reg. opravila samodejne izmenjave, zaradi česar so bila nekatera sporočila oddaljenim vozliščem ustvarjena iz delujoče baze podatkov, nekatera pa iz kopije, kar je povzročilo desinhronizacijo konfiguracij
Obstaja tudi mnenje, da je to napako posledica uporabe mehanizma za dinamično posodabljanje baze podatkov. Tu obstajajo dvomi, ker po eni strani dinamično posodabljanje nikoli ne vpliva na strukturo baze podatkov in mehanizmi RIB še vedno delujejo s strukturo baze podatkov in ne z njenim uporabnim delom; kljub temu pa RIB uporablja mehanizem za generiranje digitalnega podpisa različico konfiguracije (v prihodnje jo bom na kratko imenoval hash), in ko se del aplikacije spremeni, je treba hash seveda znova izračunati. Tega ne bom niti zanikal niti pritrdil, ker... Če sem naletel na to situacijo, nisem našel jasnih dokazov o tem.
Za popravek uporabljam 2 načina, odvisno od situacije.
PRVA TEHNIKA
Prvi (najpogostejši) se večkrat omenja tako na partnerski konferenci kot na drugih internetnih virih, povezanih z 1C. Uporablja se v večini primerov, ko kljub sporočilu o neskladju v konfiguracijah ročna primerjava pokaže, da so enake.
Zaporedje:
- odstranite datoteko cf iz centralne banke;
- prekinemo povezavo UB z RIB (metoda Set MainNode, že pripravljeno obdelavo najdete v aplikaciji ali v drugih publikacijah);
- zamenjava konf. UB v datoteko cf, naloženo v prvem koraku, za to uporabimo meni »Naloži konfiguracijo iz datoteke« (in ne primerjava-spoj!!!);
- Obnovimo znak RIB za UX.
V večini primerov so ta dejanja več kot dovolj za obnovitev izmenjave, vendar ne vedno ...
DRUGA METODA
Uporablja se, če prva metoda ni delovala in vozlišča ni mogoče znova razbremeniti.
Ozadje: naročnik je postavljal kaskadni RIB in je prišlo do napake na prvem nivoju kaskade (drugi nivo je ves ta čas deloval brezhibno). Konfiguracija je bila razvita skupaj z IT službo naročnika, odkar je prišlo do napake, pa se je konfiguracija centralne banke večkrat spremenila. Možnost povrnitve sprememb niti načeloma ni bila upoštevana, saj izguba nekaterih podatkov in zaprtje več oddelkov je bila popolnoma nesprejemljiva. Prva možnost za odpravo napake ni dala oprijemljivih rezultatov. Zato smo morali iskati druge rešitve.
Prišla je ideja, da bi poskusili zamenjati zgoščene vrednosti konfiguracijskih datotek neposredno v datotekah za izmenjavo XML. Opis strukture izmenjevalne datoteke iz knjige "Strokovni razvoj v sistemu 1C:Enterprise 8" je dal šibko predstavo o oblikovanju digitalnih podpisov konfiguracij in sprememb v njih, vendar je določil smer iskanje: vrednosti Digest1 in Digest2. Vse ostalo sem ugotovil čisto empirično (torej s poskusi in napakami), vendar je bilo mogoče ugotoviti vzorec.
Testni poskusi so bili uspešni. Tudi v delovnih bazah je šlo vse dobro.
Torej, zaporedje dejanj:
- izvedite korake 1 - 4 prve metode;
- Izmenjalno datoteko odstranimo iz UB, vendar je ne naložimo v Centralno banko;
- Datoteko za izmenjavo odstranimo iz centralne banke, vendar je ne naložimo v UB;
- v izmenjevalni datoteki centralne banke zamenjamo blok z informacijami o spremembah konfiguracije in zgoščenimi vrednostmi (Digest1 in Digest2) z blokom zgoščenih vrednosti iz datoteke UB (glej primer spodaj)
- Datoteko iz 4. točke naložimo v UB;
- Obvezno prepišite izmenjalno datoteko iz UB (2. točka)! te datoteke ne smete prenesti pri izmenjavi s centralno banko!
- Za preverjanje opravimo več zaporednih menjav.
Če se med izmenjavo uporablja stiskanje podatkov, potem onemogočimo stiskanje ali pa datoteko najprej razpakiramo, spremenimo, nato zapakiramo nazaj in pošljemo.
Blok izmenjave datotek iz centralne banke
... tukaj so bloki, ki opisujejo spremembe konfiguracije ...
je treba zamenjati z blokom izmenjevalne datoteke iz UB (upoštevajte, da je Digest1 za datoteko iz UB vedno enak “000000000000000000000000000000000”!!!)
Navedena dejanja je treba izvajati zelo previdno, nepravilno zaporedje lahko povzroči popolno nedelovanje RIB. Zato je pred temi dejanji OBVEZNO ustvarjanje varnostnih kopij!