Tworzenie i konfigurowanie rozproszonej bazy danych (RIB) w 1C 8.3 Rozliczanie (i inne konfiguracje) jest konieczne w przypadkach, gdy kilku użytkowników nie może pracować podczas jednoczesnego łączenia się z jedną bazą danych. Jest to obecnie dość rzadkie, ponieważ standardowy pulpit zdalny działa dobrze, a istnieją inne programy, które zapewniają zdalne połączenie z komputerem centralnym, na którym znajduje się baza danych.

Niemniej jednak zdarzają się sytuacje, w których po prostu nie ma Internetu. A dane powinny trafić do jednej bazy danych. Do tego służy rozproszona baza danych.

Zwykle główna baza nazywana jest centralną, a reszta peryferyjną. Najważniejsze jest to, że w trybie ręcznym lub automatycznym (w zależności od ustawień) bazy danych są łączone w jedną. Aby numery nowo wprowadzanych dokumentów i kody katalogów nie dublowały się, każdej bazie danych przypisywany jest przedrostek.

W tej instrukcji na przykładzie stworzymy centralną i peryferyjną bazę danych oraz sprawdzimy wymianę między nimi. Ta instrukcja jest odpowiednia zarówno dla 1C 8.3 Księgowość, jak i 1C Trade Management (UT) oraz innych konfiguracji.

Konfiguracja głównej (centralnej) rozproszonej bazy danych RIB

Przejdźmy do menu „Administracja” 1C, a następnie kliknij link „Ustawienia synchronizacji danych”. W oknie, które zostanie otwarte, zaznacz pole „Synchronizuj dane”. Link „Synchronizacja danych” stanie się aktywny. Natychmiast tutaj ustawimy prefiks dla głównej bazy danych - na przykład „CB”:

Przechodzimy przez link „Synchronizacja danych”, otworzy się okno z przyciskiem „Ustaw synchronizację danych”. Po kliknięciu tego przycisku otworzy się lista rozwijana, w której należy wybrać tryb „Pełny”. Jeśli synchronizacja jest wymagana tylko dla jednej organizacji, musisz wybrać „Według organizacji ...”.

W kolejnym oknie program poprosi nas o wykonanie kopii zapasowej. Zdecydowanie polecam to zrobić, ponieważ następujące kroki konfiguracji mogą być nieodwracalne.

Po utworzeniu kopii zapasowej kliknij przycisk „Dalej”. W kolejnym kroku powinniśmy zdecydować, w jaki sposób odbędzie się synchronizacja:

• poprzez katalog lokalny lub katalog w sieci lokalnej;
• przez Internet za pośrednictwem FTP.

Dla uproszczenia i przejrzystości przykładu wybierzemy katalog lokalny. Wskazałem następującą ścieżkę: „D: \ Bazy 1C \ Synchronizacja”. Sprawdzanie wpisu w tym katalogu nie będzie zbyteczne, jest do tego specjalny przycisk:

Zdobądź 267 lekcji wideo 1C za darmo:

Pomijamy kolejne kroki związane z konfiguracją synchronizacji przez FTP i e-mail. Zastanawiamy się nad ustawieniami nazw głównych i peryferyjnych baz danych. Tutaj ustawiamy prefiks dla bazy peryferyjnej:

Nie zapominaj, że prefiksy każdej bazy muszą być unikalne. W przeciwnym razie pojawi się błąd „Wartość prefiksu pierwszej bazy danych nie jest unikalna”.

Kliknij „Dalej”, sprawdź wprowadzone informacje i ponownie kliknij „Dalej”, a następnie - „Zakończ”. W polu „Pełna nazwa bazy plików” podaj plik 1Cv8.1CD w katalogu, który został utworzony do synchronizacji. Tworzymy początkowy obraz rozproszonej bazy 1C:

Po utworzeniu początkowego obrazu RIB w 1C możesz ustawić harmonogram synchronizacji lub zsynchronizować ręcznie:

Po synchronizacji możesz połączyć się z nową bazą danych i upewnić się, że zostały tam przesłane informacje z bazy centralnej:

Po prostu natychmiast utwórz co najmniej jednego użytkownika z uprawnieniami administratora w nowej bazie danych urządzeń peryferyjnych.

Skonfiguruj synchronizację w bazie danych Edge

W bazie peryferyjnej 1C konfiguracja jest znacznie łatwiejsza. Wystarczy zaznaczyć pole „Synchronizacja danych” i kliknąć link o tej samej nazwie. I prawie natychmiast wchodzimy do okna z przyciskiem „Synchronizuj”. Spróbujmy utworzyć element testowy w peryferyjnej bazie danych i przesłać go do głównej za pomocą RIB:

Często dochodzi do sytuacji, gdy organizacja posiada kilka oddziałów lub placówek, które są od siebie oddalone geograficznie. Niemniej jednak istnieje potrzeba prowadzenia jednego rejestru w całej organizacji. Jedną z opcji rozwiązania tego problemu jest utworzenie jednej sieci, która będzie obejmować stacje robocze wszystkich oddziałów, oraz umieszczenie bazy informacyjnej 1C na serwerze publicznym. Ta metoda może być trudna technicznie i kosztowna. Ponadto istnieje szereg zagadnień związanych z bezpieczeństwem informacji.

Drugą opcją jest utworzenie rozproszonej bazy informacji (RIB). Rozproszona baza danych to hierarchiczna struktura składająca się z oddzielnych baz danych na platformie 1C:Enterprise, między którymi zorganizowana jest wymiana danych w celu synchronizacji konfiguracji i danych. Te oddzielne bazy danych nazywane są węzłami RIB.

Rozproszona baza danych może zostać utworzona w oparciu o różne konfiguracje systemu 1C:Enterprise. Rozważ jego stworzenie na przykładzie 1C: Trade Management 10.3.

Załóżmy, że w organizacji handlowej otwierany jest dodatkowy punkt sprzedaży, w którym niezbędny jest dostęp do ogólnego systemu handlowego organizacji. Aby utworzyć RIB, wykonaj następujące kroki:

To kończy tworzenie rozproszonej bazy danych. W celu wymiany informacji należy uruchomić wymianę danych w Bazie Centralnej (zostaną wczytane zmiany, które w niej zaszły), następnie w sklepie (zmiany zostaną pobrane z Centralnej Bazy i wczytane zostaną zmiany, które zaszły w sklepie ), i ponownie w centralnej bazie danych (zostaną do niej pobrane zmiany, które nastąpiły w sklepie).

Rozproszone bazy danych mają własny mechanizm rozstrzygania kolizji. Jeśli więc podczas wymiany okaże się, że jakiś obiekt (dokument, katalog itp.) został zmieniony zarówno w bazie głównej, jak iw bazie podrzędnej, to zmiana dokonana w bazie głównej będzie miała pierwszeństwo.

Jeśli konieczna jest zmiana konfiguracji rozproszonej bazy danych, należy to zrobić w węźle głównym (patrz pierwszy rysunek w artykule), konfiguracje pozostałych węzłów są zablokowane. Po dokonaniu niezbędnych zmian można je przesłać do podrzędnych węzłów przy użyciu standardowej procedury wymiany danych pomiędzy węzłami RIB. Po wykonaniu wymiany w konfiguratorze węzła slave należy zaktualizować konfigurację infobase.

Jeśli masz problem z założeniem rozproszonej bazy danych, nasi specjaliści pomogą Ci skonfigurować wymianę danych i szczegółowo wyjaśnią, jak z niej korzystać.

W tym artykule skupimy się na konfigurowaniu rozproszonej bazy danych 1C Enterprise 7.7, na przykład zostanie użyta konfiguracja Trade Management 9.2.

Aby skonfigurować RIB w 1C 7.7, musisz przejść do konfiguratora i przejść do administracji-rozproszonego zarządzania IS.

Następnie musisz przekonwertować swoją bazę danych na RIB, jeśli nie została jeszcze przekonwertowana na RIB, w tym celu musisz kliknąć przycisk „Central IB”.

Ustaw kod i opis jak na powyższym zrzucie ekranu i kliknij „OK”. Powinno pojawić się ostrzeżenie jak na poniższym zrzucie ekranu, zignoruj ​​je i kliknij „Tak”.
Następnie twoja baza będzie gotowa do tworzenia węzłów peryferyjnych.

Kliknij w przycisk „New Peripheral IB” i ustaw wartości pól jak na poniższym zrzucie ekranu, jednak możesz użyć własnych oznaczeń.

Kliknij OK i przejdź do następnego kroku - konfiguracji automatycznej wymiany.

W tym artykule powiem ci, jak skonfigurować automatyczną wymianę za pomocą sieci lokalnej, jeśli potrzebujesz automatycznej wymiany pocztą, zostaw swoją prośbę w komentarzach lub skontaktuj się ze mną, a powiem ci, jak to zrobić.

Wszystko eksponujemy jak na slajdzie, można mieć własne ścieżki do katalogów, checkboxy powinny być jak na screenie powyżej. Kliknij OK.

Teraz przesyłamy początkowy obraz bazy peryferyjnej na dysk, w tym celu naciskamy przycisk „Rozładuj dane”. Po wyładowaniu obrazu początkowego okno kontrolne RIB będzie wyglądać następująco:

Załóżmy, że komputer, na którym będzie działać nasze żebro, znajduje się niedaleko głównego komputera z centralną bazą i oba komputery są podłączone do sieci lokalnej.

Teraz musisz skonfigurować RIB na komputerze klienckim, w tym celu bierzemy nasz plik zip przesłany w poprzednich krokach i tworzymy na jego podstawie bazę danych. Poniższe zrzuty ekranu pokazują pełną sekwencję działań.

Kliknij przycisk „Dodaj”, wskaż pusty folder i kliknij OK.

Wybierz nowy IB i przejdź do trybu konfiguratora.

W pustym folderze tworzymy pusty IB, więc 1C prosi nas o wskazanie, w jakim formacie będzie nasza baza danych, wybierz *.dbf. Kliknij OK.

Teraz prześlijmy plik zip przesłany w poprzednich krokach do naszej bazy danych, w tym celu przejdziemy do administracji - prześlij dane.

Określ ścieżkę do pliku i kliknij OK.
Po zakończeniu pobierania kliknij OK i przejdź do dystrybuowanego przez administrację ib-auto-exchange.

Na tym etapie należy wziąć pod uwagę regułę: katalogi rozładunkowe papierów wartościowych = katalogi załadunkowe IB i odwrotnie, tj. jeśli w centralnej bazie wgraliśmy do folderu out i pobraliśmy z folderu w, to w peryferyjnej bazie danych wrzucimy z folderu out i wrzucimy do folderu w. Kliknij OK i przejdź do następnego kroku. Dokonujemy automatycznej wymiany. Aby to zrobić, w centralnej bazie danych przejdź do rozproszonego przez administrację ib-auto-exchange.

Kliknij przycisk „Uruchom”, a następnie zrób to samo w bazie klientów. Wykonaj operację automatycznej wymiany po kolei na każdym z komputerów kilka razy.

Teraz zautomatyzujmy ten proces. Aby to zrobić, musisz utworzyć 4 pliki na każdym komputerze. 2 pliki *.prm i 2 pliki *.bat dla każdej operacji wysyłania i pobierania.

Plik *.bat musi zawierać następującą linię:

"<путь к файлу 1cv77.exe>"konfiguracja /D"<путь к информационной базе>"/N<логин>/P<пароль>/@"<путь к prm-файлу>"

Moje przesyłane i pobierane pliki wyglądają tak:

"C:\Program Files\1Cv77\BIN\1cv7s.exe" config /D"C:\base\rib\" /Nadmin /P1 /@"c:\download.prm"

"C:\Program Files\1Cv77\BIN\1cv7s.exe" config /D"C:\base\rib\" /Nadmin /P1 /@"c:\upload.prm"

Zapisujesz swoje wartości. Teraz zajmijmy się plikami prm!

Struktura pliku .prm:

Sekcja „Ogólne” ma na celu opisanie głównych parametrów trybu burst. Możliwe opcje:

Wyjście - ścieżka do pliku dziennika;
- Quit – czy po wykonaniu wszystkich zadań konieczne jest zamknięcie konfiguratora;
- AutoExchange – czy wykonać automatyczną wymianę;
- SaveData – czy zapisać bazę danych;
- UnloadData – czy konieczny jest rozładunek;
- CheckAndRepair - czy konieczne jest wykonanie testów i naprawy bazy danych.

Możliwe wartości dla tych parametrów to 1(Y) lub 0(N).

Sekcja „AutoExchange” służy do definiowania parametrów autoexchange. Opcje:

SharedMode – określa tryb działania z bazy danych. Jeśli parametr nie jest ustawiony, zastosowany zostanie tryb wyłączności;
- ReadFrom - wskazuje z jakich baz danych mają być pobierane dane. Identyfikatory bazy danych muszą być oddzielone przecinkami. Jeśli wszystkie są potrzebne, umieszcza się *;
- WriteTo - wskazuje dla jakich baz dane mają być wyładowane. Jeśli jest to konieczne dla wszystkich, umieść * .

Sekcja „SaveData” służy do definiowania parametrów zapisu bazy danych. Możliwe opcje:

SaveToFile - określa ścieżkę, w której zostanie dokonany zapis;
- FileList – określa listę zapisanych plików. Nazwy plików są oddzielone spacjami lub przecinkami;

Sekcja „UnloadData” służy do definiowania parametrów rozładunku danych. Opcje:

UnloadToFile — określa ścieżkę zapisu wraz z nazwą pliku;
- IncludeUserDef – wskazuje, czy lista użytkowników powinna znaleźć się w pliku transferu;
- Hasło - określa hasło, które zostanie ustawione dla pliku transferu.

Sekcja „CheckAndRepair” służy do definiowania parametrów odzyskiwania bazy danych. Możliwe opcje:

Napraw - wskazuje, czy konieczne jest przywrócenie bazy danych;
- Integralność fizyczna – wskazuje, czy konieczne jest sprawdzenie integralności fizycznej tabel bazy danych;
- Reindex – wskazuje na potrzebę reindeksacji bazy danych;
- LogicalIntegrity – wskazuje, czy konieczne jest sprawdzenie logicznej integralności tabel;
- RecalcTotals - wskazuje, czy konieczne jest ponowne przeliczenie wyników rachunkowości i rachunkowości operacyjnej;
- Pakuj - wskazuje, czy konieczne jest zwolnienie miejsca zajmowanego przez usunięte rekordy;
- SkipUnresolved - określa, czy pominąć nierozwiązane linki, czy je naprawić;
- CreateForUnresolved — określa, w jaki sposób zostaną rozwiązane nierozwiązane łącza. Jeśli 1, wówczas dla nierozwiązanego odniesienia zostanie utworzony obiekt odpowiedniego typu. Jeśli 0, łącze zostanie wyczyszczone.

Na tej podstawie moje pliki będą zawierać:

pobrać z banku centralnego na urządzenie peryferyjne:

Wyjście = log.txt
wyjście = 1

odczyt z = CB

za rozładunek z banku centralnego do peryferyjnego:

Wyjście = log.txt
wyjście = 1

Napisz do = CB

pobrać z urządzenia peryferyjnego do banku centralnego:

Wyjście = log.txt
wyjście = 1

Odczyt z=PB1

do rozładunku z peryferii do banku centralnego:

Wyjście = log.txt
wyjście = 1

Zapisz do=PB1

Teraz wystarczy umieścić pliki bat i prm w jednym folderze i uruchomić je po kolei, aby wykonać pobieranie i wysyłanie.

Jeśli masz jakieś pytania - witaj w komentarzach!

To mój pierwszy post, konstruktywna krytyka mile widziana.

Grupą docelową są osoby, które spotykają się z RDB po raz pierwszy.

zadania BRD

Pierwszą rzeczą, od której należy zacząć, jest odpowiedź na pytanie „Dlaczego potrzebujemy RDB?”. Odpowiedzi jest wiele, w szczególności:

1. Mamy oddziały działające w rozłącznych bazach danych. Teraz chcemy, aby informacje między nimi były zsynchronizowane;
2. Mamy oddziały, ale obciążenie bazy danych jest zbyt duże (czyli blokowanie transakcji, a nie wielkość bazy) i trafność online (nie mylić z trafnością w kilka minut, online jest wtedy, gdy po każdej transakcji dane są przesyłane do drugiego węzła) nie są wymagane dane dla oddziałów;
3. Posiadamy oddziały, w których występuje tylko wprowadzanie danych (np. sklepy detaliczne), dzięki czemu możemy znacznie odciążyć centralną bazę danych;
4. Ze względów bezpieczeństwa chcemy, aby oddziały nawet teoretycznie (z hasłem administratora) nie miały dostępu do ważnych danych, takich jak bilans firmy.

W jednym przypadku pytania 2 i 4 były dla mnie istotne, w drugim 2 i 3. Pierwszy akapit jest zbyt obszerny i nie będzie rozpatrywany w ramach tego artykułu.

Lepiej też od razu rozważyć kwestię transportu plików wymiany, ponieważ w niektórych przypadkach może to nałożyć znaczne ograniczenia na realizację wymiany danych. Najpierw należy określić, w których oddziałach dokładnie pojawią się węzły RDB (zwykle są to oddziały regionalne). Następnie zastanawiamy się, gdzie jeszcze chcemy zainstalować węzły RDB i czy potrzebują one przydatności online. Na przykład w przypadku sklepów detalicznych nie zawsze jest możliwe zainstalowanie nawet modemu, a instalacja połączenia bezprzewodowego będzie zbyt kosztowna. Tu trzeba podjąć decyzję – być może ten sklep może działać offline i okresowo wymieniać się z centrum (raz dziennie/raz w tygodniu) za pomocą fizycznego nośnika, takiego jak pendrive.

W niektórych przypadkach wymiana za pośrednictwem fizycznych nośników nie jest możliwa, na przykład jest to bardzo odległy oddział, w którym występują znaczne problemy z konfiguracją szybkiej komunikacji. Tutaj warto z grubsza obliczyć ilość wymienianych informacji. Często, z trafnością raz na godzinę lub kilka razy dziennie, wystarczy modem 32k. Warto jednak pamiętać, że wraz z aktualizacją danych, czasami trzeba będzie przesłać aktualizacje samej konfiguracji lub plików zewnętrznych (druki formularzy, zdjęcia produktów), więc od czasu do czasu pojawi się sytuacja, kiedy plik wymiany będzie się zwiększał znacznie dzięki takim aktualizacjom.

Topologia

W sumie otrzymaliśmy następujące pytania, na które należy odpowiedzieć:

1. w jakich działach będziemy mieli zagwarantowaną instalację węzłów RDB i czy jest możliwość zainstalowania tam szybkiego kanału;
2. W jakich podrejonach instalacja węzła RDB nie jest wymagana;
3. Które działy mogą skutecznie pracować w ciągu kilku godzin;
4. Które działy mogą pracować offline (wymiana danych mniej niż 3-4 razy dziennie).

Po udzieleniu odpowiedzi na te pytania otrzymujemy przybliżony schemat naszej RDB. W przypadku dużych firm zwykle okazuje się to mniej więcej tak:

Rys. 1. Typowy schemat RDB dla dużej firmy

Jeśli wszystko jest względnie jasne z węzłami „Oddział” - są to duże centra wymagające automatyzacji, to węzły „Sklep” oznaczają węzeł z poważnym obciążeniem bazy danych podczas wprowadzania danych, które należy oddzielić, aby zmniejszyć obciążenie. Na przykład sklep z 50 kasami i dziennym obrotem przekraczającym 10 000 sztuk.

• Sklepy - wprowadzanie danych o własnych obrotach i przepływach pieniężnych. Analityka jest powierzchowna, tylko dla Twojego sklepu.
• Oddziały - wprowadzanie danych punktów niezautomatyzowanych, księgowość, płace i kadry, produkcja itp. Analityka we własnym oddziale.
• Centrum - wprowadzanie danych oddziałów niezautomatyzowanych. Analityka przedsiębiorstwa jako całości.

Ważne jest, aby zrozumieć, do jakich celów baza danych będzie używana w każdym węźle. Z celów budowane są zadania niezbędne do realizacji, na przykład:

• Oddziały widzą historię rozliczeń ze swoimi kontrahentami;
• Sklepy widzą resztki towaru w całości (lub części) przedsiębiorstwa;
• Analityka przychodów/wydatków, wykonania budżetu itp. są widoczne tylko w ramach hierarchii własnego działu;
• Księgowość, kadry i płace widoczne są tylko w hierarchii własnego działu;
• Nomenklatura, wszystkie jej właściwości i cechy są widoczne we wszystkich węzłach RDB;
• W stosunku do hierarchii działów wszystkie dane idą w górę, ale są filtrowane w dół;
• Centrum zawiera absolutnie wszystkie informacje o firmie.

Stawiając przed sobą takie pytania można sobie odpowiedzieć na najtrudniejsze pytanie – jakie informacje, gdzie i jak powinny przebiegać pomiędzy węzłami RDB? Dlaczego najtrudniejszy? Wiedząc, jakie zestawy danych działają między węzłami, możesz jasno zrozumieć, jak „wyciąć” bieżącą bazę danych, aby dane pozostały logicznie spójne. Na przykład danych o bilansie towarowym nie można oddzielić od danych o rezerwach bieżących.

Teraz, w zależności od przepływów informacji, przerysujmy schemat RDB:

Co widzimy na rycinie 2? Zgodnie z hierarchią działów firmy, ułożono topologię przepływu informacji pomiędzy węzłami bazy danych. Dodano także węzeł „Centrum 2”, dlaczego? Przy wdrażaniu topologii gwiazdy obciążenie centrum jest zawsze większe niż obciążenie węzłów peryferyjnych, a często obciążenie generowane przez sam węzeł jest już duże. Przykłady wykorzystania węzłów „Centrum 1” i „Centrum 2”:

1. „Centrum 1” służy jedynie do konsolidacji danych innych węzłów RDB. Dostęp do niego ma tylko administrator. „Centrum 2” służy do pracy centrali;
2. „Centrum 1” służy do pracy centrali. Jednak ciężkie analityczne, testowe, powodujące ogromne obciążenie bazy danych operacje są wykonywane w węźle „Centrum 2”; na przykład ponowne sekwencjonowanie, ponowne księgowanie zamkniętych okresów, generowanie raportów podsumowujących w całym przedsiębiorstwie przez długi okres czasu, generowanie analiz prowadzących do zmian danych;
3. „Centrum 1” służy do pracy centrali. „Centrum 2” stanowi kopię zapasową na wypadek nieprzewidzianych sytuacji do szybkiego przywrócenia całego RDB.

Implementacja wymiany

Istnieją 2 opcje działania RDB:

1. Automatyczny - następuje bez interwencji użytkownika. Kontrola nad sytuacjami awaryjnymi jest przypisana albo do administratora bazy danych, albo do zaawansowanego użytkownika;
2. Ręczny - wymiana następuje tylko na żądanie użytkownika.

Z własnego doświadczenia zawsze prowadziłem wszystkie wdrożenia do wersji automatycznej. Jeśli występowały problemy z transportem plików wymiany (obecność sieci w węźle nie jest stała), to maksimum, na które użytkownik zezwolił, to kliknięcie przycisku „Wymień teraz”. Sytuacje, w których oprócz aktualizacji danych aktualizowana jest konfiguracja, pożądane jest również doprowadzenie do sytuacji w pełni automatycznych (na przykład przy użyciu oprogramowania firm trzecich).

Tworzenie pakietów aktualizacji

Ponieważ istnieje jednoznaczna decyzja, które węzły RDB mają przypisane jakie funkcje, możliwe jest utworzenie tylko takiego pakietu danych, jakiego ten węzeł potrzebuje. Z jednej strony konieczne jest określenie, jakie typy obiektów będą synchronizowane między węzłami. Na przykład rejestry rozliczeniowe dla węzła „Sklep 1” nie powinny być w ogóle synchronizowane, ponieważ dane wprowadzane są tylko na poziomie oddziału. Z drugiej strony te typy danych, które podlegają wymianie, muszą być filtrowane w odniesieniu do działu. Na przykład dane dotyczące odbioru pieniędzy węzła „Sklep 1 oddziału 2” mogą znajdować się tylko w węzłach „Oddział 2”, „Centrum 1” i „Centrum 2”.

Istnieje jednak odwrotny problem, jeśli za bardzo przefiltrujesz wymieniane dane, pakiet danych utraci spójność logiczną. Na przykład stany magazynowe są rozliczane według magazynów, a rezerwy są rozliczane przez firmę jako całość, to jeśli odfiltrujesz stany magazynowe według magazynów i nie odfiltrujesz zapasów, dane będą nieprawidłowe.

Należy również zdecydować, na jakim etapie życia przedmiot podlega wymianie. Przykładowo, wymianie podlegają tylko zaksięgowane faktury, a nie tylko zapisane. Albo Faktury Sklepu nigdy nie są pobierane z węzła Centrum, nawet po ich skorygowaniu, ale trzeba liczyć się z odwrotnym skutkiem – dane mogą nie być zsynchronizowane lub niektóre zmiany mogą zostać nadpisane.

Ważne jest, aby zrozumieć - podczas wymiany między węzłami jeden z nich jest priorytetem. Rozważ sytuację:

1. Utworzono dokument w węźle Store 1;
2. Podczas wymiany dostał się do węzła „Oddział 1”;
3. Dokument jest poprawiany jednocześnie w obu węzłach.

Który z dokumentów zostanie uznany za prawdziwy? W 1C 8.x, przy korzystaniu z mechanizmu „Plany wymiany”, domyślnie główny węzeł ma priorytet, tj. w takim przypadku zmiany dokonane w węźle „Sklep 1” zostaną utracone i zastąpione danymi z węzła „Oddział 1”.

Jest jeszcze inna, bardziej skomplikowana sytuacja, gdy korygowane są jednocześnie dwa połączone ze sobą obiekty. Np. faktura wychodząca i PKO na niej są korygowane w różnych węzłach, istnieje możliwość utraty integralności w przypadku zmiany cen, kwoty płatności, kontrahentów itp.

Ważna jest również kontrola usuwania obiektów, w przeciwnym razie może to doprowadzić do tego, że np. faktura już nie będzie istniała, ale ruchy księgowe pozostaną.

Mechanizmy wymiany w 1C 8.x

Istnieją dwa podejścia do wdrożenia:

1. Mechanizm „Plany wymiany”;
2. Niestandardowa implementacja rejestracji obiektów.

Rozważmy obie opcje.

Mechanizm planów wymiany pozwala, bez jakiejkolwiek konfiguracji, w kilka minut stworzyć RDB z pełną wymianą danych. Jeśli ustawisz flagę „Rozproszona baza danych”, aktualizacje konfiguracji zostaną również pobrane podczas tworzenia pakietu aktualizacji. W zaledwie kilka minut możesz także skonfigurować zasady zezwalania/zabraniania wymiany różnego rodzaju danych otwierając skład planu wymiany. Jeśli ustawisz flagę „Auto-rejestracja” w pozycji „Wyłącz”, to ten typ obiektu, bez dodatkowych wysiłków, nigdy nie zostanie wymieniony.

Dlaczego potrzebna jest rejestracja, dlaczego nie przesłać wszystkiego na raz? W każdym razie plik zawierający tylko zmiany stanu bazy danych będzie mniejszy niż pełna migawka samej bazy danych. W związku z tym opcja pełnego rozładunku nie będzie brana pod uwagę.

Jak skonfigurować filtrowanie danych według przynależności do działu? Tu trzeba programować. W mojej implementacji dla nagrania dowolnego obiektu została ustawiona subskrypcja zdarzenia „On Recording”, gdzie za pomocą właściwości „Wymiana danych.Odbiorcy” można ustawić listę odbiorców tego obiektu. Te. przy rozładowywaniu w sposób standardowy dla węzła, którego nie ma na liście, obiekt nie zostanie rozładowany. Jest jeszcze inne rozwiązanie - czy można wybrać wyładowanie obiektu bezpośrednio przy wyładunku obiektu, w procedurach "Podczas wysyłania danych do Slave" i "Podczas wysyłania danych do Master" modułu planu wymiany.

Obie opcje są prawidłowe. Wybrałem jednak pierwszą opcję jako najlepszą, ponieważ obliczenie cechy nieładowalności następuje natychmiast po zapisaniu obiektu, co zwiększa czas zapisu obiektu o 3-5% (można to zoptymalizować, w niektórych przypadkach można zwiększyć do 0,01%), tj. średnio 0,1-0,3 sekundy, a w przypadku obliczania nieobciążalności obiektu bezpośrednio przy wysyłaniu danych, co już powoduje znaczne obciążenie bazy danych, czas ten wyniesie nawet kilka minut.

Aby w pełni zrozumieć działanie mechanizmu „Plany wymiany”, polecam przeczytanie rozdziału 15 książki „Rozwój zawodowy w systemie 1C: Enterprise 8”, Gabets A.P., Goncharov D.I.

Moim zdaniem każda natywna implementacja albo powtórzy mechanizm planów wymiany, albo zwolni obiekt natychmiast po zmianie, albo zwolni więcej niż mechanizm planów wymiany (na przykład zwolni wszystkie zmiany na dzisiaj). Nie uważam tego problemu za brak doświadczenia wdrożeniowego.

Transport

Zadanie przesyłania plików z węzła nadrzędnego do węzła podrzędnego jest ograniczone do maksymalnej odporności na uszkodzenia. Często zdarza się, że pliki są szyfrowane lub przesyłane przez bezpieczny kanał. Do przesyłania plików wskazane jest skorzystanie z kilku różnych usług lub przygotowanie kilku różnych opcji połączenia. Na przykład główną metodą przesyłania jest użycie serwera FTP połączonego przez tunel VPN; kopią zapasową jest serwer pocztowy z połączeniem TLS. Dlaczego potrzebujesz zapasowego kanału z inną usługą? Jak pokazuje praktyka, korzystanie z 2 różnych serwerów FTP jest mniej niezawodne niż serwer FTP i poczta e-mail.

Polecam oddzielenie usługi tworzenia service packa od usługi transportowej, zwiększy to awaryjność całego kompleksu wymiany danych. Jeśli usługa transportu plików nie działa, usługa tworzenia pakietów aktualizacji będzie nadal działać normalnie iw określonych warunkach ponownie uruchomi usługę transportu i odwrotnie.

Moja implementacja RDB

Implementacja jest całkowicie autonomiczna, więc podzadaniem była maksymalna odporność na awarie. W rezultacie powstały 2 usługi - usługa transportu aktualizacji oraz usługa importu/eksportu danych. Obie usługi działają niezależnie od siebie.

Po każdym udanym cyklu importu-eksportu danych zapisywany był czas ostatniej wymiany z tym węzłem. Jeśli wymiana nie odbywała się przez bardzo długi czas, to usługa transportowa zaczynała przesyłać pliki do wszystkich dostępnych jej kanałów komunikacji, licząc na to, że drugi węzeł nadal będzie otrzymywał aktualizacje i przesyłał swoje pliki. W wyjątkowych sytuacjach system sam wysyła wiadomość do administratora ze szczegółowym opisem błędu.

Aby zmniejszyć ruch, pliki xml zostały spakowane do archiwów zip. System obsługuje dwa rodzaje transportu - FTP i E-mail.

Istnieją dwie tabele jako ustawienia dla filtra danych. Jedna (część tabelaryczna planów wymiany) przechowuje warunki dla atrybutów ogólnych (system stara się znaleźć ten atrybut dla każdego obiektu), druga zawiera ustawienia dla konkretnego obiektu metadanych. Podczas rejestrowania dowolnego obiektu warunki są najpierw wyszukiwane według typowych atrybutów (na przykład Podpodział), po czym system próbuje określić, czy istnieje osobista reguła dla tego typu obiektu dla wszystkich jego atrybutów. Nie polecam filtrowania zestawień - istnieje duża szansa na pomyłkę, np. z części tabelarycznej faktury zniknie kilka wierszy, a reszta przesunie się na całość i odwrotnie.

Ważne jest, aby zrozumieć, w ramach jakiego użytkownika systemu będą działać usługi, ponieważ może nie być wystarczających uprawnień do tworzenia plików nawet w folderze tymczasowym 1C. W przypadku debugowania zdecydowanie zalecam zapisywanie każdej pomyślnie zakończonej operacji w dzienniku lub w pliku txt. W 1C 8.1 nie można debugować wykonania kodu serwera.

Dla wygody debugowania i dostosowywania mojej implementacji załączam przetwarzanie „Rejestracja zmian”, którego opis znajduje się w samym przetwarzaniu.

Ogólny schemat działania kompleksu wymiany danych przedstawiono na rysunku 3.

Filtrowanie danych odbywa się w ramach subskrypcji zdarzenia „BeforeWrite” każdego obiektu. Nie zapominaj, że podczas tworzenia początkowego obrazu węzła dane muszą być również filtrowane. Procedura tworzenia początkowego obrazu jest dość długa, dlatego zalecam maksymalne zoptymalizowanie jego kodu (na przykład buforowanie ustawień filtrowania).

Posłowie

Głównym zadaniem jest udzielenie odpowiedzi na listę pytań:

1. Dlaczego potrzebujemy RDB?
2. Co jest złego w pracy za pośrednictwem klienta RDP?
3. Gdzie i dlaczego chcemy zainstalować węzły RDB?
4. W jaki sposób będą przesyłane aktualizacje?
5. Jaki poziom odporności na awarie zostanie wdrożony?

Obsługa „RegistrationChanges”

Przetwarzanie umożliwia wymuszenie zaewidencjonowania zmian w obiektach. Istnieje kilka opcji rejestrowania zmian:

1. Jeśli pole wyboru jest zaznaczone na jakichkolwiek metadanych i NIE jest wybrany pojedynczy obiekt, a flaga „Wyładuj według wszystkich wartości” NIE jest ustawiona, to ZAREJESTROWANA JEST TYLKO WYBRANA TABELA;
2. Jeżeli ustawiona jest flaga „Wyładuj po wszystkich wartościach”, to wybrane metadane zostaną wyładowane przez wszystkie obiekty w cyklu;
3. Jeżeli przełącznik ustawiony jest w tryb „Wyładuj tylko wybrane obiekty”, to usunięte zostaną tylko wybrane obiekty (przykładowo: ustawienie flagi na metadanych bez zaznaczania obiektów jest równoznaczne z ustawieniem flagi „Wyładuj według wszystkich wartości” i przełączeniem w pozycja „Rozładuj tylko wybrane obiekty”);
4. Jeśli przełącznik jest ustawiony na tryb „Wyładuj wybrane i bezpośrednio powiązane obiekty”, to wybrane obiekty oraz te obiekty, których istnienie zależy od istnienia wybranego obiektu, zostaną usunięte (na przykład: wyszukiwania mają wyszukiwania podrzędne);
5. Jeśli przełącznik ustawiony jest w tryb „Rozładuj przez wszystkie linki”, to WSZYSTKIE obiekty, w których znajduje się link do wybranego obiektu, zostaną usunięte.

Dostępna dodatkowa funkcjonalność:

• Ponowna rejestracja zarejestrowanych obiektów, często wymagana do debugowania;
• Usuwanie zarejestrowanych jest często wymagane do debugowania;
• Drukuj zmiany — wydrukuj pełną listę obiektów, które zostały oznaczone jako zmienione;
• Wydruk drzewa konfiguracji służy jedynie wygodzie przeglądania całej konfiguracji.

Aby utworzyć rozproszoną bazę danych, musisz wejść do programu w trybie „1C: Enterprise”. Aby utworzyć rozproszone węzły bazowe w menu wybierz: Operacje - Plany wymiany. Otworzy się okno „Wybierz obiekt: plan wymiany”.

1. Rozważ opcję z planem wymiany „Full”.

Wymiana zostanie przeprowadzona dla wszystkich organizacji znajdujących się w rozproszonej bazie informacyjnej.

Wybierzmy plan wymiany „Pełny”. Otworzy się okno pełnego planu wymiany.

Wypełnij dwa wpisy:

Nazwijmy pierwszy wpis „Węzeł główny”, podaj kod „GU”,

Nazwijmy drugi rekord „węzłem Slave”, podaj kod „PU”.

Jak widać na rysunku, ikona pierwszego wpisu jest pokazana z zielonym kółkiem, jest to ikona „Głównego węzła”.

Aby utworzyć kopię bazy danych węzła Master, kliknij węzeł Slave i kliknij ikonę Utwórz obraz początkowy. Będzie to baza informacyjna „węzła Slave”.

Otworzy się okno „Utwórz początkowy obraz IS”, wybierz „Na tym komputerze lub na komputerze w sieci lokalnej”, kliknij „Dalej”.

W polu „Katalog Infobase” wybierz lokalizację, w której zostanie zainstalowana kopia „Głównego węzła”, kliknij „Zakończ”.

Po utworzeniu bazy danych „węzła Slave” pojawi się następujący komunikat:

Wciskamy „OK”.

Dodajemy bazę informacji „węzła Slave” do „1C: Enterprise”. Wchodzimy do podrzędnej bazy danych w trybie „1C: Enterprise”. Otwórzmy: Operacje - Plany wymiany. Otworzy się okno „Wybierz obiekt: plan wymiany”. Wybierzmy plan wymiany „Pełny”. Otworzy się okno pełnego planu wymiany. Widzimy, że ikona „Główny węzeł” jest pomarańczowa, co oznacza, że ​​ten węzeł jest głównym dla bazy danych, w której się znajdujemy.

W węźle Master i Slave dokonujemy następujących ustawień:

1. Dodaj przedrostek dla rozproszonej bazy danych.

Odbywa się to tak, aby nie było konfliktów w numerach i kodach dokumentów i kartoteek tworzonych w dwóch bazach danych, dlatego w każdej bazie danych określamy przedrostek, który zostanie dodany do numerów dokumentów i kodów kartoteki. Otwórz: Serwis – Ustawienia programu – zakładka „Wymiana danych”. W polu „Prefiks węzła dla rozproszonej bazy danych:” w podrzędnej bazie danych wpisz „PU”, aw bazie głównej „GU”.

2. Dodaj ustawienie wymiany danych między węzłami:

Otwórz: Usługa — rozproszona baza informacji (RIB) — konfiguruj węzły RIB. Zostanie otwarte okno Ustawienia komunikacji.

Kliknij „Dodaj”, otworzy się okno „Ustawienia wymiany danych”. Wprowadź „Nazwę” swojego ustawienia.

Węzeł pojawi się automatycznie w polu „Węzeł”, dla „węzła nadrzędnego” będzie to „węzeł podrzędny”, dla „węzła podrzędnego” będzie to „węzeł nadrzędny”.

W polu „Katalog” należy wybrać folder, do którego będą odbierane dane z giełdy, najlepiej określić jeden katalog dla bazy głównej i podrzędnej.

W polu „Typ wymiany” konfigurujemy transfer danych pomiędzy bazami danych: poprzez plik lub zasób ftp. Wybierzmy na przykład „wymianę przez zasób plikowy”.

Na pozostałych polach nic nie zmieniamy.

Wciskamy „OK”. Widzimy, że pojawiło się ustawienie.

3. Aby wymienić dane, wykonaj następujące czynności:

Najpierw w bazie danych, w której dokonano zmian, należy kliknąć ikonę „Dokonaj wymiany zgodnie z aktualnymi ustawieniami”, jak pokazano na rysunku.

Po przesłaniu pojawi się okno z wynikami przesyłania.

Następnie w bazie, do której chcesz przenieść zmiany, kliknij w ikonę „Wykonaj wymianę zgodnie z aktualnymi ustawieniami” i dane trafią do wybranej przez Ciebie bazy danych.

2. Rozważ opcję z planem wymiany „Według organizacji”.

Wymiana zostanie przeprowadzona dla wybranych organizacji zlokalizowanych w rozproszonej bazie informacyjnej.

Aby utworzyć rozproszone węzły bazowe w menu wybierz: Operacje - Plany wymiany. Otworzy się okno „Wybierz obiekt: plan wymiany”.

Wybierzmy plan wymiany „Według organizacji”. Otworzy się okno „Plan wymiany według organizacji”.

Wypełnij dwa wpisy:

Nazwijmy pierwszy wpis „Główny węzeł”, wskażmy kod „GU”, widzimy różnicę w stosunku do „Planu wymiany: Pełny”, pojawiła się tabela, w której wskazujemy Organizacje, dla których odbędzie się wymiana.

Nazwijmy drugi wpis „węzłem Slave”, podaj kod „PU”, podaj organizację.

Pod wszystkimi innymi względami ustawienie jest takie samo jak w przypadku „Planu wymiany: pełny”.