Distribuovaná informační báze: Základy. Distribuovaná informační základna. Pokyny krok za krokem a úskalí 1s 8 nastavení žeber nahoru
Pokyny pro vytváření a konfiguraci distribuovaných databází pomocí komponenty URDB (URIB).
Komponenta URDB (Distributed Database Management) slouží k výměně informací mezi dvěma identickými databázemi 1C. Pokud se konfigurace liší, můžete to také použít, je to napsáno v jiném. Aby komponenta fungovala, musíte mít soubor DistrDB.dll ve složce BIN programu 1C: Enterprise.
Podívejme se na kroky k vytvoření distribuovaných databází. Například máme funkční základ v adresáři D:\base1. Je nutné, aby byl centrální a vytvořil obvodovou základnu.
1. Vytvořte adresář D:\base2 pro databázi periferií.
2. V adresářích D:\base1 a D:\base2 vytvořte složky CP a PC (použijte latinku).
3. Spusťte konfigurátor centrální databáze (D:\base1) a vyberte Nabídka - Administrace - Zabezpečení distribuovaných informací - Správa.
4. Klikněte na tlačítko „Centrální zabezpečení informací“ a v zobrazeném okně zadejte kód a název databáze. Pro kód je lepší používat čísla nebo latinská písmena. Zadejte například 001 a „Central base“, potvrďte stisknutím tlačítka „OK“.
5. Klikněte na tlačítko „Nové zabezpečení periferních informací“ pro vytvoření databáze periferií. Zadáme pro něj parametry: 002 a „Periferní základna 1“.
6. Pomocí kurzoru vyberte základnu „Peripheral Base 1“ a stiskněte tlačítko „Setup“. automatická výměna“. V nastavení měníme manuální režim na automatické. Buďte opatrní, je to důležité.
7. Pomocí kurzoru vyberte databázi „Periferní databáze 1“ a stiskněte tlačítko „Nahrát data“ a poté tlačítko „OK“. V důsledku nahrání se objeví soubor D:\base1\CP\020.zip.
8. Spusťte 1C v režimu konfigurátoru, do spouštěcího okna 1C přidejte novou databázi „Periferní databáze 1“, zadejte pro ni dříve vytvořený adresář D:\base2.
9. Vyberte Nabídka - Správa - Zabezpečení distribuovaných informací - Správa. Na položená otázka„Informační základna nebyla nalezena. Chcete načíst data?" Klikněte na tlačítko "Ano" a zadejte název souboru "D:\base1\CP\020.zip", klikněte na tlačítko "OK". Po dokončení stahování lze proces vytváření periferní databáze považovat za dokončený.
V a také v metodách vytváření periferní databáze obnovením kopie centrální databáze ze zálohy nebo připojením souborů kopie centrální databáze pro formát SQL a spuštěním skriptu. To se bude hodit pro velké objemy dat, kdy nahrávání a stahování trvá hodiny nebo je zcela nereálné.
Pokyny pro výměnu mezi distribuovanými databázemi pomocí komponenty URDB (URIB).
Podívejme se na zjednodušený příklad, výměnu provedeme ručně spuštěním konfigurátoru. Můžete použít dávkový režim konfigurátoru, můžete použít poštu, ftp a automatické kopírování souborů k doručení výměnných balíčků.
Chcete-li provést výměnu, musíte vybrat Nabídka - Správa - Zabezpečení distribuovaných informací - Automatická výměna. Pokud je výměna automatická (viz bod 6 předchozího návodu), tak vše klapne.
1. Změníme nebo vytvoříme některé objekty, které migrují do databáze periferií. Pravidla migrace objektů se nastavují na záložce "Migrace" ve vlastnostech objektu (viz strom objektů v konfigurátoru).
2. Spusťte konfigurátor centrální databáze, vyberte Nabídka - Správa - Zabezpečení distribuovaných informací - Automatická výměna, klikněte na tlačítko "Spustit".
3. Přesuňte výsledný soubor D:\base1\CP\020.zip do složky D:\base2\CP\
4. Změna některých objektů periferní základna data. Nejlépe ne ty, které byly dříve změněny v centrální databázi, protože centrální databáze má prioritu pro změny objektů během výměny.
5. Spusťte konfigurátor periferní databáze, vyberte Nabídka - Správa - Zabezpečení distribuovaných informací - Automatická výměna, klikněte na tlačítko "Spustit".
6. V důsledku automatické výměny bychom měli mít změny pocházející z centrální databáze. Měli bychom mít také soubor pro přenos do centrální databáze D:\base2\PC\021.zip
7. Zkopírujte soubor D:\base2\PC\021.zip do složky D:\base1\PC
8. Opakujte bod 2. V důsledku toho se změny přijaté z periferní databáze objeví v centrální databázi.
Takže obecný princip výměny: střídavé provádění automatické výměny se současným přesunem souborů (výměnných balíčků) ze složky PC jedné databáze do složky PC jiné databáze a ze složky CP jedné databáze do složky CP jinou databázi.
Změny konfigurace se provádějí pouze v centrální databázi. Při změně konfigurace je nutné provést výměnu v periferních databázích ve výhradním režimu. Pro úspěšné zpracování paketů z periferních databází v centrální databázi je nutné načíst konfiguraci do periferních databází. Pokud budete zmateni, nevadí, balíček odmítnutý centrální databází se stáhne znovu.
V 1C 8.3 nebo v 1C 8.2? Nastavení distribuované informační databáze. Návod krok za krokem.
Distribuce informační báze se používá, když je potřeba udržovat společné záznamy v databázích, které z různých důvodů nemohou mít fyzické spojení. Příkladem může být účetnictví v jedné společnosti, která má divizi velkoměsto a malá vesnice bez připojení k internetu. Nebo v některých speciálních případech periodické potřeby současně pracovat s jednou databází v kanceláři i mimo kancelář, například doma. V takových a podobných případech je použití distribuované informační báze (DIB) oprávněné a nezbytné.
V tomto článku se podíváme na organizaci distribuce jedné informační databáze v konfiguraci 1C Accounting for Russia verze 8.3 prostřednictvím místního popř. síťový adresář. Ve verzi 8.2 1C tento pokyn bude také užitečné, protože popisuje v podstatě jeden proces s výrazně malými rozdíly.
==== Nastavení pro hlavní základnu ====
Po otevření 1C 8.3 v režimu „Enterprise“ přejdeme do sekce „Administrace“. Ve verzi 1C 8.2, abyste mohli začít, musíte přejít do hlavní nabídky „Service“ - „Distributed informační základna(RIB)" - "Konfigurovat uzly RIB."
Dále se budeme zabývat procesem v kontextu zabezpečení informací verze 8.3. Přejděte do části „Správa“ a vyberte „Nastavení programu“. V nastavení přejděte do části „Synchronizace dat“. Zde zaškrtneme políčko „Použít synchronizaci dat“ a určíme prefix databáze. Označme „CB“, což znamená centrální základnu.
Poté se v pravém menu objeví položka „Synchronizace dat“. Pojďme si ho vybrat. V podřízeném okně, které se otevře, klikněte na tlačítko „Nastavit synchronizaci dat“. V rozevírací nabídce můžete vybrat nastavení pro různé případy použití synchronizace. Vybereme „Distribuovaná informační základna...“.
Pro obecný vývoj se seznamte s obsahem dalšího okna a klikněte na „Další“.
V dalším okně vyplňte adresář, přes který se . Upřesníme kompresi dat pro zmenšení velikosti uploadu a rovnou můžete zadat heslo pro archiv s daty. Důležité je na něj nezapomenout. Vyplnění potvrďte tlačítkem „Další“.
Další dvě okna jsou určena pro specifikaci parametrů nastavení pro případy výměny přes FTP server a skrz e-mailem. Jak již bylo řečeno, uvažujeme o metodě výměny prostřednictvím adresáře, takže přeskakujeme nastavení pro FTP a e-mail.
Další okno je určeno pro zadání parametrů výměny v periferní databázové části. Uveďme jeho název a předponu. Dále je tlačítko „Další“.
Zkontrolujeme námi vytvořené parametry výměny a potvrdíme jejich správnost tradičním tlačítkem „Další“.
Automaticky se vytvoří potřebná sada nastavení pro výměnu. Chvíli to potrvá.
Důležité! Vytvoření počátečního obrazu pro podřízený uzel zabere značné množství času. Velikost tohoto významu závisí na prostředcích počítače a objemu účetnictví v hlavní databázi.
Předpokládejme, že se rozhodneme vytvořit obrázek. Po kliknutí na tlačítko „Dokončit“ v předchozím okně vstoupíme do nastavení pro vytvoření obrazu informačního zabezpečení slave. Zvážíme nejjednodušší případ pro místní provozy. Chcete-li to provést, v okně, které se otevře, uveďte potřebné podrobnosti. Věnujme zvláštní pozornost parametru „ Celé jméno databáze souborů". Musí být specifikován v plném formátu UNC, což vyžaduje vytvoření místní cesty v „síťovém“ formátu. Například - „\\Server1C\Databases\RIB“. K zadané cestě přidáme název databázového souboru - 1Cv8.1CD.
Po kliknutí na tlačítko „Vytvořit úvodní obrázek“ se spustí proces generování obrázku pro podřízenou databázi.
Po dokončení procesu se v zadaném adresáři vytvoří databázový soubor. Tuto nově vytvořenou databázi je třeba před úplným použitím nakonfigurovat.
==== Nastavení pro periferní základnu ====
Chcete-li to provést, musíte jej připojit k 1C. Jak na to, najdete v návodu v našem článku - Po připojení je potřeba spustit novou databázi v režimu konfigurátoru a vytvořit uživatele. Dále musí být zabezpečení informací spuštěno v režimu 1C „Enterprise“.
Pokud je z nějakého důvodu potřeba vytvoření uživatelů odložit na později, po připojení můžete databázi jednoduše spustit v režimu 1C „Enterprise“. Budete vyzváni k vytvoření uživatele „Administrator“, souhlas s tím a bude provedeno počáteční vyplnění.
Poté je třeba pokračovat v nastavení párování s hlavní základnou. Toto nastavení je podobné jako výše uvedené pro hlavní databázi.
Vytvoří se nastavení pro komunikaci s hlavní základnou.
============================================
Nyní jsme tedy vytvořili hlavní a okrajové základny. V každé z těchto databází byla také vytvořena nastavení synchronizace. Nyní můžete přejít k úpravě těchto nastavení a jejich převedení do vhodné podoby. Můžete vytvořit automatická pravidla výměny nebo provést výměnu ručně.
Udělejme to v hlavní databázi. Periferní základna je konfigurována stejným způsobem.
Úpravy lze aplikovat na pravidla a plány synchronizace dat.
Kliknutím na tlačítko „Konfigurovat“ v části „Plán synchronizace dat“ musíte upravit skripty, aby se automaticky naplánovalo nahrávání/načítání dat pro vybranou databázi. Nemusíte jej upravovat, stačí souhlasit s výchozími možnostmi.
Chcete-li upravit parametry, stačí kliknout na odkaz s údaji automatického rozvrhu. A poté upravíme dočasné parametry pro spouštění úloh. Procházením záložek můžete změnit jak čas, tak data a dny v týdnu spuštění.
Kliknutím na tlačítko „Spustit úlohu“ v hlavním okně skriptu můžete úlohu spustit ručně.
Kliknutím na tlačítko „Konfigurovat“ v části „Pravidla synchronizace dat“ můžete provádět operace pro změnu skriptů spouštění úloh a také prohlížet protokol nahrávání/stahování. Ten je poměrně důležitý pro správu přístupu a sledování pravidelnosti výměn.
Po dokončení vytváření a úprav skriptů automatický start výměnou distribuované databáze, můžete přistoupit k vykládání a následnému načítání dat.
V tomto okamžiku je konfigurace distribuované databáze lázní pro centrální a periferní uzly v podstatě dokončena.
Stáhněte si ilustrovaný návod
Distribuovaná informační základna. Návod krok za krokem
Distribuovaná informační základna (RIB) 1C:Enterprise
Vytvoření distribuované infobáze a její nastavení
jak nastavit žebro za 1s 8.2
Jak nastavit distribuovanou informační základnu v 1C
Jak nastavit v 1C
Jak nastavit v 1C
Nastavení distribuované informační základny (RIB) v 1C
Příklad nastavení RIB pro 1C:Accounting 8
Vytvoření distribuované infobáze a konfigurace
V tomto článku budeme hovořit o nastavení distribuované databáze 1C Enterprise 7.7 jako příklad bude použita konfigurace Trade Management 9.2.
Chcete-li nakonfigurovat RIB v 1C 7.7, musíte přejít do konfigurátoru a přejít do Administration-Distributed IS-Management.
Poté musíte převést vaši databázi na RIB, pokud ještě nebyla převedena na RIB, k tomu musíte kliknout na tlačítko "Centrální informační banka".
Nastavte kód a popis jako na obrázku výše a klikněte na „OK“. Mělo by se objevit varování jako na obrázku níže, ignorujte ho a klikněte na „Ano“. 
Poté bude vaše základna připravena k vytvoření periferních uzlů.
Klikněte na tlačítko „New Peripheral IB“ a nastavte hodnoty polí jako na následujícím snímku obrazovky, můžete však použít vlastní označení.
Klikněte na OK a přejděte k dalšímu kroku – nastavení automatické výměny.
V tomto článku vám řeknu, jak nastavit automatickou výměnu pomocí lokální síť, pokud potřebujete automatickou výměnu poštou, pak zanechte svůj požadavek v komentářích nebo mě kontaktujte na a já vám řeknu, jak na to.
Zobrazujeme vše jako na snímku, můžete mít své vlastní cesty k adresářům, zaškrtávací políčka by měla být jako na obrázku výše. Klepněte na tlačítko OK.
Nyní nahrajeme počáteční obrázek periferní databáze na disk, klikněte na tlačítko „Nahrát data“. Po stažení úvodního obrazu bude okno správy RIB vypadat takto:
Předpokládejme, že počítač, na kterém bude naše žebro pracovat, se nachází nedaleko hlavního počítače s centrální základnou a oba počítače jsou připojeny k lokální síti.
Nyní musíme nakonfigurovat RIB na klientském počítači, abychom to udělali, vzít náš soubor zip stažený v předchozích krocích a vytvořit na něm informační základnu. Níže uvedené snímky obrazovky ukazují kompletní sekvenci akcí.
Klikněte na tlačítko "Přidat", ukažte na prázdnou složku a klikněte na OK. 
Vybereme nový informační bezpečnostní systém a přejdeme do režimu konfigurátoru. 
V prázdné složce vytvoříme prázdnou informační banku, takže nás 1C požádá, abychom uvedli, v jakém formátu bude naše databáze, vyberte *.dbf. Klepněte na tlačítko OK. 
Nyní načteme zip soubor nahraný v předchozích krocích do naší databáze, přejděte do administrace - stahování dat. 
Zadejte cestu k souboru a klepněte na OK. 
Po dokončení stahování klikněte na OK a přejděte na administraci distribuovaný ib-auto-exchange.
Při tomto kroku je nutné vzít v úvahu pravidlo: adresář vykládky CB = adresář načítání PB a naopak, tzn. pokud jsme v centrální databázi nahráli do složky out a načetli ze složky in, tak v periferní databázi načteme ze složky out a nahrajeme do složky in. Klikněte na OK a přejděte k dalšímu kroku. Provádíme automatickou výměnu. Chcete-li to provést, přejděte v centrální databázi na administraci distribuovaný ib-autoexchange.
Klikněte na tlačítko "Spustit" a poté proveďte totéž na klientské základně. Proveďte operaci automatické výměny na každém počítači několikrát.
Nyní zautomatizujme proces. Chcete-li to provést, musíte na každém počítači vytvořit 4 soubory. 2 soubory *.prm a 2 *. bat soubor pro každou operaci nakládání a vykládání.
*.bat soubor by měl obsahovat následující řádek:
"<путь к файлу 1cv77.exe>"config/D"<путь к информационной базе>"/N<логин>/P<пароль>/@"<путь к prm-файлу>"
Moje načítání a vyjímání souborů vypadá takto:
Konfigurace "C:\Program Files\1Cv77\BIN\1cv7s.exe" /D"C:\base\rib\" /Nadmin /P1 /@"c:\download.prm"
Konfigurace "C:\Program Files\1Cv77\BIN\1cv7s.exe" /D"C:\base\rib\" /Nadmin /P1 /@"c:\upload.prm"
Píšete své hodnoty. Nyní se pojďme zabývat soubory prm!
Struktura souboru .prm:
Část „Obecné“ je určena k popisu hlavních parametrů dávkového režimu. Možné parametry:
Výstup – cesta k souboru protokolu;
- Quit – zda je nutné ukončit konfigurátor po dokončení všech úkolů;
- AutoExchange – zda má být provedena automatická výměna;
- SaveData – zda je nutné uložit databázi;
- UnloadData – zda se má provést vyložení;
- CheckAndRepair – zda je potřeba databázi otestovat a opravit.
Možné hodnoty pro tyto parametry mohou být 1(Y) nebo 0(N).
Sekce „AutoExchange“ je určena pro definování parametrů automatické výměny. Možnosti:
SharedMode – označuje režim provozu z databáze. Pokud parametr není zadán, použije se exkluzivní režim;
- ReadFrom - označuje, ze kterých databází mají být přijímána data. Identifikátory databáze musí být uvedeny oddělené čárkami. Pokud jsou všechny potřebné, vložte * ;
- WriteTo - označuje, do kterých databází mají být nahrána data. Pokud je to nutné pro všechny, vložte *.
Sekce „SaveData“ je určena pro definování parametrů pro uložení databáze. Možné parametry:
SaveToFile – označuje cestu, kam bude uložení provedeno;
- FileList – označuje seznam souborů k uložení. Názvy souborů jsou uvedeny oddělené mezerami nebo čárkami;
Sekce „UnloadData“ – je určena pro definování parametrů pro vykládání dat. Možnosti:
UnloadToFile – určuje cestu pro uložení, včetně názvu souboru;
- IncludeUserDef – označuje, zda má být v přenosovém souboru zahrnut seznam uživatelů;
- Heslo – určuje heslo, které bude nastaveno pro přenosový soubor.
Sekce „CheckAndRepair“ je určena pro definování parametrů obnovy databáze. Možné parametry:
Opravit – označuje, zda je nutné obnovit databázi;
- Fyzická integrita – udává, zda je nutné kontrolovat fyzickou integritu tabulek infobázové báze;
- Reindexovat – indikuje nutnost reindexace databáze;
- LogicalIntegrity – označuje, zda je nutné kontrolovat logickou integritu tabulek;
- RecalcTotals – udává, zda je nutné přepočítat výsledky účetního a provozního účetnictví;
- Pack – označuje, zda je nutné uvolnit místo obsazené smazanými záznamy;
- SkipUnresolved – určuje, zda se mají přeskočit nevyřešené odkazy nebo je opravit;
- CreateForUnresolved – určuje, jak jsou vyřešeny nevyřešené odkazy. Pokud je 1, bude pro nevyřešený odkaz vytvořen objekt příslušného typu. Pokud je 0, pak bude odkaz vymazán.
Na základě toho budou moje soubory obsahovat následující:
stáhnout z centrální banky do periferie:
Výstup = log.txt
Výstup = 1
ReadFrom = CB
pro vyložení z centrální banky do periferie:
Výstup = log.txt
Výstup = 1
WriteTo = CB
ke stažení z periferie do centrální banky:
Výstup = log.txt
Výstup = 1
ReadFrom = PB1
pro vyložení z periferie do centrální banky:
Výstup = log.txt
Výstup = 1
WriteTo = PB1
Nyní stačí umístit soubory bat a prm do jedné složky a spustit je jeden po druhém, aby se provedlo stahování a nahrávání.
Pokud máte nějaké dotazy, neváhejte je komentovat!
V praxi často dochází k situacím, kdy jsou různé divize nebo pobočky geograficky umístěny na různých místech. Přitom data zadávaná do programu na vzdálených odděleních se musí nějak dostat do centrály, aby byla vedena obecná evidence.
V současné době tento problémčasto řešeno poskytnutím geograficky vzdálených zaměstnanců vzdálený přístup na společnou základnu. Lze to provést zveřejněním databáze na webovém serveru, přes vzdálenou plochu atd.
Neobvyklé však nejsou situace, kdy v geograficky vzdálené kanceláři prostě není internet nebo není dostatečně stabilní, aby fungovala ve společné informační databázi. Pro tento účel má 1C mechanismus pro nastavení distribuované databáze.
Jednoduše řečeno, centrála je tam, kde se nachází hlavní základna. Vzdálené oddělení využívá podřízeného. Takových otrokářských základen může být několik. Výsledkem je, že taková distribuovaná databáze se synchronizací sjednotí do jedné. Lze jej vyrobit buď v automatický režim plánovaně i ručně.
V tomto článku se podíváme na nastavení distribuované databáze pro 1C: Accounting 3.0. Navzdory tomu pokyny budou fungovat a pro většinu ostatních konfigurací 1C 8.3.
Poznámkaže všechny potřebné úpravy konfigurace by měly být prováděny pouze v hlavní databázi RIB. Během synchronizace se tyto změny přenesou do všech podřízených databází a projeví se.
Hlavní informační základna
Při použití distribuované databáze jsou hlavní nastavení hlavní základna. Je třeba je provést v části „Správa“, jak je znázorněno na obrázku níže.
V okně, které se otevře, okamžitě zaškrtněte políčko „Synchronizace dat“. V dolní části zadejte prefix hlavní (aktuální databáze). Může obsahovat maximálně dva znaky. V našem případě bude předpona „BG“, protože máme na mysli, že tento RIB 1C je „Hlavní účetnictví“.
Nyní můžete začít s nastavováním samotné synchronizace, konkrétně určením, se kterou databází (nebo databázemi) budou data vyměňována. Chcete-li to provést, postupujte podle hypertextového odkazu „Nastavení synchronizace dat“. Bude k dispozici pro navigaci, pouze pokud je zaškrtnuto políčko vlevo.
V okně, které se otevře, vyberte z nabídky „Úplné...“. Umožní nám to specifikovat libovolnou informační základnu 1C pro synchronizaci.
V prvním okně pro připojení podřízené databáze, která se nachází v geograficky vzdálené kanceláři, zaškrtněte políčko, že připojení bude provedeno přes lokální nebo síťový adresář. V našem případě je to „D:\DB\InfoBase“. Předem také ověříme, zda si do něj můžete napsat.
Nezapomeňte zadat různé předpony pro různé databáze. Faktem je, že při synchronizaci dat je datům přetíženým z každé databáze přiřazen vlastní prefix. Pokud jsou duplikovány, práce bude nesprávná, takže program vám tuto příležitost nedá.
Když vás program vyzve k vytvoření úvodní bitové kopie, vyberte tuto možnost. Tento postup bude chvíli trvat, poté jej uložte do počítače pod názvem „1Cv8.1CD“.
Samotnou synchronizaci lze provést buď automaticky podle plánu, který si sami nastavíte, nebo ručně. V druhém případě stačí kliknout na tlačítko „Synchronizovat“ v čase, který vám vyhovuje.
podřízený uzel RIB
Počet nastavení provedených v databázi slave je podstatně menší. Ve stejné sekci nastavte příznak „Synchronizace dat“ a kliknutím na příslušný odkaz se zpřístupní tlačítko „Synchronizovat“.
V našem příkladu byly do hlavní databáze přidány dvě položky položky: „Beam“ a „Board“. Po synchronizaci skončily v databázi otroků. Jak můžete vidět na obrázku níže, dostaly předponu „BG“. Zbývajícím dvěma pozicím („Soustruh“ a „Paleta“) je přiřazena předpona „BP“, protože byly vytvořeny přímo v podřízené databázi.
Poznámkaže číslování prvků je v našem případě souvislé, ale pouze v rámci stejné předpony.
25. října 2016
Není velký rozdíl mezi nastavením a podporou RIB pro 2 uzly a pro 10, ale když počet vzdálených bodů přesáhne stovku, musí se řešit úplně jiné problémy
Počáteční údaje:
Konfigurace: Maloobchod 2.2
Nástupiště 1C: 8.3.7.1970
Doba trvání projektu: jeden rok.
Architektura:
Nejprve jsme se rozhodli pro schéma RIB. Bylo rozhodnuto zaměřit se na „hvězdné“ schéma co nejdéle; při dosažení technologických omezení - sněhová vločka.
Omezení:
- 2 GB RAM
- 1 fyzický procesor
Ze všeho výše uvedeného je hlavní nepříjemná věc omezení maximální velikosti databáze.
Ale to jen znamená, že musíte pečlivě zorganizovat postup pro jeho vyčištění od zastaralých dat na místě.
Pro 1C a MS SQL server je přidělen samostatný fyzický server. Ponese hlavní břemeno burz a dlouhodobých operací.
Finále klientské počítače se nevyměňují, protože budou pracovat s tenkým klientem a zátěž na ně bude minimální.
.
základní nastavení
Od dob UT 10.3, během kterých jsem měl svůj první projekt implementace RIB pro 60 uzlů, samozřejmě „pod mostem uplynulo hodně vody“.
1C nestál na místě. Retail 2.2 nyní zohledňuje potřebu selektivního nahrávání dat.
Do databáze obchodu budou nahrány pouze informace, které jsou pro něj relevantní:
- Všechny referenční knihy (kromě specializovaných)
- Dokumenty pro tento obchod
Další otázkou je, že tak či onak přidání uzlu do databáze znamená přidání další položky do registrační tabulky pro každý společný prvek, když je zapsán.
1) Je nutné rozdělit do samostatných scénářů synchronizace pro nahrávání a stahování
Jde o to, že vykládání trvá dlouho a obnáší blokování, zatímco načítání je celkem bezproblémové. Často se přitom stává, že potřebujeme rychle přijímat data z maloobchodních prodejen a přitom je rozdávat jen párkrát za den.
2) Identifikujte problémová úložiště a odstraňte je z obecného scénáře synchronizace. Může na nich docházet k velkým vykládkám – to zpomalí celou ústřednu včetně dalších uzlů. Jakmile jsou problémy vyřešeny, jsou přidány zpět.
3) Vytvořte několik skriptů pro odesílání a přijímání dat. Zde je ale hlavní chytit správnou rovnováhu jejich množství.
(od verze 8.1).
V důsledku toho je paralelismus při vykládání RIB omezený. V praxi se ukazuje, že paralelně běží 2-3 skripty.
Co bylo třeba zlepšit
Nejdůležitějším problémem standardní logiky 1C RIB jsou aktualizace
Dalším problémem výměny jsou informační registry. Nahráním každého záznamu registru informací do XML se vytvoří samostatný uzel XML s prvky služby atd. Funkce „SelectChanges()“ pro registr informací, ve kterém je 100 záznamů, navíc obdrží výslednou tabulku o 100 řádcích na adrese současně, pokud tento adresář A se 100 řádky bude mít ve své tabulkové části vybranou pouze jednu položku. A to je doba exkluzivního blokování. Pokud je tedy v PC mnoho záznamů, které se pravidelně registrují k výměně do jiných obchodů, pak by samozřejmě bylo správnější toto prezentovat ve formě adresáře s tabulková část, který v extrémních případech může při zápisu tvořit řetězce stejného registru. Tak jako tak, .
Další důležitý detail - Proč? Slevových karet je již téměř 3 miliony. Pro práci s nimi je využíván externí online systém. Pokud budete nadále převádět slevové karty do všech obchodů, výrazně se tím zvýší výměny a může dojít i k tomu, že základ překročí objem 10 GB.
Některé z mechanismů jsou implementovány online přístupem do centrální databáze: zůstatky na jiných prodejnách, vrácení účtenkou z jiné prodejny, kontrola platnosti dárkového certifikátu.
Replikace
Vytvoření počátečního uzlu RIB běžným způsobem by v zásadě znemožnilo replikaci.
Proto se nový uzel vytvoří následovně:
2) Tato databáze vyměňuje všechna obecná data v RIB, ale nepřijímá specializované (dokumenty)
5) Základ pro obchod je připraven.
Již nasazeno na server připravený balíček Software, takže to nezabere moc času. Poté se nově vytvořená databáze nahraje na server a je připravena k odeslání do obchodu.
Výhody tenkého klienta
Dvě významné výhody Retail 2.2 (Thin Client), které „zahřály duši“:
Podpora a aktualizace
1) Aktualizujte ručně z obchodů (nepříliš správná, změny nemusí být přijaty, budou hovory a problémy) - dříve tomu tak bylo
3) Napište *.cmd nebo 1C skript pro aktualizaci nebo si vezměte hotový. Jak ukazuje praxe, takové řešení je vždy polovičaté (nestabilní) a bude možné do něj zabudovat malou funkčnost.
Jaké byly naše úkoly:
2) Při aktualizaci je možná interaktivní interakce s uživatelem (zprávy, potvrzení, ukazatel průběhu).
Hlavní funkce:
4) Kontrola stavu agentů
5) Aktualizujte zprávy
6) záloha
Například takto vypadá chybová zpráva po aktualizaci:
Projekt tak měl velkou šanci na úspěšné dokončení. Minimálně v polovině letu je let normální.
Pokud dojdeme k dalším řešením, která se mohou zdát zajímavá, napíšu samostatně
P.S. a hlavně: Správné plánování další podpory je jedním z klíčových faktorů pro další úspěch takových projektů. :)
25. října 2016
Není velký rozdíl mezi nastavením a podporou RIB pro 2 uzly a pro 10, ale když počet vzdálených bodů přesáhne stovku, je třeba řešit úplně jiné problémy.
Takže prvotní údaje:
Konfigurace: Maloobchod 2.2
Nástupiště 1C: 8.3.7.1970
Odhadovaný počet uzlů na konci projektu: 200
Vybavení v centru: bez výrazných omezení
Vybavení v místě: diskutovaný problém.
Doba trvání projektu: jeden rok.
Architektura:
Nejprve jsme se rozhodli pro schéma RIB. Dříve bylo rozhodnuto zaměřit se na schéma „hvězdy“.
V maloobchodních prodejnách se používá verze klient-server s dedikovaným serverem s operačním systémem Windows.
Server 1C bude použit ve verzi „Server 1C MINI“ https://1c.ru/news/info.jsp?id=17577
DBMS server - MS SQL Express 2008 R2.
SQL Express 2008 R2 je aktuální nejnovější verze této řady SQL Server.
Omezení:
2 GB RAM
- 1 fyzický procesor
- Maximální velikost databáze 10 GB
Ze všeho výše uvedeného je samozřejmě nejnepříjemnější omezení maximální velikosti databáze. Ale ve skutečnosti to znamená, že bude nutné pečlivě zorganizovat postup čištění od zastaralých dat na místě.
Pro 1C a MS SQL server je vyhrazen samostatný server. Ponese hlavní břemeno směn a transakcí.
Koncové klientské počítače se nevyměňují, protože budou pracovat s tenkým klientem a zátěž spodní části bude minimální.
Server v obchodě je prostě výkonný počítač. Předpokladem je ale přítomnost SSD disk- na kterých jsou umístěny databáze MS SQL.
Server také poskytne možnost provádět rutinní operace v noci a přístup k databázi obchodu bez přerušení práce.
základní nastavení
Od dob UT 10.3, během kterých jsem měl svůj první projekt implementace RIB pro 60 uzlů, samozřejmě „pod mostem uplynulo hodně vody“. 1C nestál na místě. Retail 2.2 nyní zohledňuje potřebu selektivního nahrávání dat.
Do databáze obchodu budou nahrány pouze informace, které jsou relevantní pro obchod:
- Všechny adresáře (kromě některých)
- Dokumenty pro tento obchod
Registrace dat probíhá podle registračních pravidel, vše, co lze kešovat. Během registrace nedochází k žádnému výraznému zpomalení.
Další otázkou je, že tak či onak přidání uzlu do databáze znamená přidání dalšího záznamu pro každý společný prvek pro všechny databáze.
V samotném nastavení nahrávání není nic konkrétního. Při nastavování scénářů synchronizace existují určité nuance:
1) Je nutné oddělit nahrávání a načítání do samostatných scénářů synchronizace
Jde o to, že vykládání trvá dlouho a obnáší blokování, zatímco načítání je celkem bezproblémové. Často se přitom stává, že potřebujeme rychle přijímat data z maloobchodních prodejen a přitom je rozdávat jen párkrát za den.
2) Identifikujte problémová úložiště a odstraňte je z obecného scénáře synchronizace. Může na nich docházet k velkým unloadům – to zpomalí celou výměnu včetně dalších uzlů
3) Vytvořte nějaké skripty pro odesílání a přijímání pro odesílání a přijímání dat. Ale hlavní je zde rovnováha.
Některé věci v 1C se nemění. Stejná metoda "SelectChanges" může být provedena pouze postupně(od verze 8.1).
V důsledku toho je paralelismus při vykládání RIB omezený. V praxi to skončí tak, že nahrajete 2-3 skripty najednou.
Co se týče přijímacího scénáře, je zde možná mnohem větší paralelismus, pokud je to nutné, samozřejmě.
Co bylo třeba zlepšit
Samozřejmě je to smutné a smutné, ale musel jsem důkladně zasahovat do BSP. Nejdůležitějším problémem standardní logiky 1C jsou aktualizace. Po aktualizaci se zobrazí okno podobné tomuto:
To vše se děje v monopolním režimu. Mimo jiné se systém po aktualizaci v exkluzivním režimu ještě pokusí o výměnu. Není těžké uhodnout, kam to všechno vede.
Po celou tuto dobu nemůže obchod fungovat, zákazníci jsou u pokladny a firma je ve ztrátě.
Dalším problémem výměny jsou informační registry. Nahráním každého záznamu registru informací do XML se vytvoří samostatný uzel XML s prvky služby a vším, co následuje. Navíc funkce „vybrat změny“ pro informační registr, ve kterém je 100 záznamů, výsledná tabulka bude obsahovat 100 řádků, zároveň, pokud se jedná o adresář se 100 řádky, bude vybrán pouze jeden záznam v tabulka sekce. Pokud je tedy v PC hodně záznamů, které se pravidelně evidují k výměně do jiných obchodů, pak je samozřejmě správnější toto prezentovat ve formě adresáře s tabulkovou částí, která v krajním případě při záznamu , může generovat záznamy stejného registru. Tak jako tak, informační registry ve výměnách jsou zlo.
Další důležitý detail - Z výměny jsou zcela vyloučeny slevové karty a z výměny jsou vyloučeni pouze zaměstnanci konkrétní prodejny. Proč? Slevových karet je již téměř 3 miliony. Pro práci s nimi je využíván externí online systém. Pokud budete nadále převádět slevové karty do všech obchodů, výrazně se tím zvýší výměny a navíc to může vést k tomu, že základ překročí objem 3GB.
Některé z mechanismů jsou implementovány online kontaktováním centrální databáze: zůstatky na jiných prodejnách, vrácení účtenky z jiné prodejny, kontrola platnosti dárkového certifikátu.
Replikace
Replikace samozřejmě probíhá zrychleným tempem.
Vytvoření počátečního uzlu RIB standardním způsobem by samozřejmě znemožnilo replikaci.
Proto se nový uzel vytvoří následovně:
1) Existuje samostatná databáze s falešným obchodem
2) Tato databáze vyměňuje všechna obecná data v RIB, ale nepřijímá specializovaná
3) Když chceme vytvořit novou databázi, jednoduše tuto zkopírujeme
4) Poté nastavíme nastavení - store, prefix atp.
5) Základ pro obchod je připraven.
Na server je nasazen hotový softwarový balíček, takže to nezabere mnoho času. Poté se nově vytvořená databáze prodejen nahraje na server a je připravena k odeslání do obchodu.
Výhody tenkého klienta
dvě významné výhody, které „zahřály na duši“.
1) Není potřeba měnit celý počítačový park u maloobchodních prodejen. 90 % operací se provádí na serveru a server je tam přenesen s „relativně výkonným počítačem“
2) Zařízení má schopnost odmítnout pracovat, což se zvláště často stává u nově nainstalovaného nebo již opotřebovaného zařízení.
V tomto případě jsou nyní akce extrémně jednoduché – obchod se přepne na práci v centrální databázi.
Tento proces netrvá déle než 5-10 minut, takže obchodování není přerušeno, i když se vyskytnou značné problémy se zařízením.
Podpora a aktualizace
Konečně jsme se dostali k nejzajímavějšímu bodu – jak toto vše udržovat a aktualizovat?
Aktualizace i pro nás na dlouhou dobu bylo dilema:
1) Aktualizujte ručně z obchodů (nepříliš správné, změny nemusí být přijaty, dojde k hovorům a problémům)
2) Aktualizace pomocí sil technická podpora(ne tolik zdrojů)
3) Napište *.cmd pro aktualizaci nebo si vezměte hotový. Jak ukazuje praxe, takové řešení je vždy polovičaté (nestabilní) a je v něm málo funkčnosti.
Jaké byly naše úkoly:
1) Aktualizace musí probíhat v několika režimech a musí být spravována centrálně
2) Při aktualizaci je možná interaktivní interakce s uživatelem.
3) Musí být přijímány zprávy o stavu aktualizace a chybách
4) Musí existovat záloha
5) Aktualizační systém by se měl bez problémů sám aktualizovat.
6) Systém by měl být bez problémů rozšiřitelný.
Úkoly samozřejmě dalece přesahovaly výčet řešitelných jednoduché metody. Protože se s tolika koncovými body neobejdeme bez automatizace a nenašli jsme nic víceméně hotového s podobnou funkčností
Musel jsem začít vyvíjet software, který nakonec získal jméno MU (MagicUpdater).
Hlavní funkce:
1) Dynamická aktualizace databáze (příkazová nebo plánovaná)
2) Statická aktualizace databáze (příkazová nebo plánovaná)
3) automatické agenty na koncových počítačích při jejich úpravě
4) Kontrola stavu agentů
5) Aktualizujte zprávy
6) zálohování
7) Administrativní akce se serverem 1C a MS SQL
8) Uzavření všech klientských aplikací 1C na počítačích v síti
9) Statická aktualizace s přijetím na hlavní pokladně
10) Zobrazení popisů úprav po aktualizaci
11) Nastavení pořadí akcí
12) Proveďte všechny tyto akce podle plánu
Přibližná schémata interakce:
Kde MU Agent je služba, která je nainstalována a konfigurována v obchodě. Ve skutečnosti dostává z centra příkaz k provedení určitých úkolů.
Server MU - Server, který přijímá všechny požadavky do systému.
Monitor MU - to, co vidí běžní zaměstnanci technické podpory - slouží k prohlížení logů a nastavení úkolů pro aktualizaci, případně dalších.
Dopadlo to podle mě docela dobře. Aktualizace nyní probíhají téměř automaticky.
Takto vypadá například chybová hláška po aktualizaci vše zůstává v centru a čeká.
A takto posíláme příkazy do klientských počítačů
Aplikace rozhodně nejsou 1C, ale s poměrně slušnou sadou možností rozhraní. Výběr podle data vypadá například takto:
Nyní jsme připraveni na další replikaci. Správné plánování další podpory je jedním z klíčových faktorů pro další úspěch takových projektů.