1s 8 żeber i dodane obiekty. Rozproszona baza informacji: podstawy

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

1. Rozważ opcję z planem wymiany „Pełny”.

Wymiana będzie prowadzona pomiędzy wszystkimi organizacjami znajdującymi się w rozproszonej bazie informacji.

Wybierzmy plan wymiany „Full”. Otworzy się okno „Pełny plan wymiany”.

Wypełniamy dwa wpisy:

Nazwijmy pierwszy wpis „Węzłem głównym”, wskażmy kod „GU”,

Nazwijmy drugi wpis „węzłem podrzędnym”, podaj kod „PU”.

Jak widać na rysunku, pierwszy wpis ma ikonę z zielonym kółkiem; jest to ikona „Węzła Głównego”.

Aby utworzyć kopię bazy informacyjnej „Węzeł główny” należy kliknąć na „Węzeł podrzędny” i kliknąć ikonę „Utwórz obraz początkowy”. Będzie to baza informacyjna „Węzła Podrzędnego”.

Otworzy się okno „Tworzenie wstępnego obrazu bezpieczeństwa informacji”, wybierz „Na tym komputerze lub na komputerze w sieci lokalnej”, kliknij „Dalej”.

W polu „Infobase Directory” wybierz lokalizację, w której zostanie zainstalowana kopia „Main Node” i kliknij „Zakończ”.

Po utworzeniu bazy informacji „Węzeł podrzędny” pojawi się następujący komunikat:

Kliknij OK".

Dodaj bazę informacyjną „Węzeł podrzędny” do „1C: Enterprise”. Przechodzimy do podrzędnej bazy danych w trybie „1C: Enterprise”. Otwórzmy: Operacje - Plany Exchange. Otworzy się okno „Wybierz obiekt: Plan wymiany”. Wybierzmy plan wymiany „Full”. Otworzy się okno „Pełny plan wymiany”. Widzimy, że ikona „Węzeł główny” ma kolor pomarańczowy, co oznacza, że ​​węzeł ten jest głównym węzłem dla bazy informacyjnej, w której się znajdujemy.

W węzłach Master i Slave dokonujemy następujących ustawień:

1. Dodaj prefiks dla rozproszonej bazy danych.

Dzieje się tak, aby nie było konfliktów w numerach i kodach dokumentów i katalogów utworzonych w dwóch bazach, dlatego w każdej bazie wskazujemy przedrostek, który będzie dodawany do numerów dokumentów i kodów katalogowych. Otwórz: Narzędzia – Ustawienia programu – zakładka „Wymiana danych”. W polu „Prefiks węzła dla rozproszonej bazy danych” wpisz „PU” w bazie podrzędnej i „GU” w bazie głównej.

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

Otwarte: Usługa — baza informacji rozproszonych (DIB) — konfiguracja węzłów RIB. Otworzy się okno „Ustawienia wymiany danych”.

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

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

W polu „Katalog” wybierz folder, do którego będą przesyłane dane wymiany, najlepiej określić jeden katalog dla bazy głównej i bazy podrzędnej.

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

W pozostałych polach nic nie zmieniamy.

Kliknij OK". Widzimy, że pojawiło się ustawienie.

3. W celu wymiany danych wykonujemy następujące czynności:

Najpierw w bazie danych, w której dokonano zmian, kliknij ikonę „Wymień 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 ikonę „Wymień zgodnie z aktualnymi ustawieniami”, a dane trafią do wybranej bazy.

2. Rozważ opcję planu wymiany „Przez organizację”.

Wymiana będzie prowadzona pomiędzy wybranymi organizacjami zlokalizowanymi w rozproszonej bazie informacji.

Aby utworzyć węzły rozproszonej bazy danych, wybierz z menu: Operacje - Plany Exchange. Otworzy się okno „Wybierz obiekt: Plan wymiany”.

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

Wypełniamy dwa wpisy:

Nazwijmy pierwszy wpis „Węzłem Głównym”, 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 nastąpi wymiana.

Nazwijmy drugi wpis „węzłem podrzędnym”, wskażmy kod „PU”, wskażmy organizację.

Pod wszystkimi innymi względami konfiguracja jest absolutnie taka sama, jak w przypadku „Planu wymiany: Pełny”.

To mój pierwszy artykuł, konstruktywna krytyka mile widziana.

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

Zadania RDB

Pierwszą rzeczą, od której musisz zacząć, jest odpowiedź na pytanie „Po co nam RDB?” Możliwych odpowiedzi jest wiele, w szczególności:

1. Mamy oddziały działające w odłączonych 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 (oznacza to blokowanie transakcji, a nie wielkość bazy danych) i przydatność online (nie mylić z trafnością za kilka minut, online jest wtedy, gdy po każdej transakcji dane są przeniesiony do drugiego węzła) nie są wymagane dane dla oddziałów;
3. Posiadamy oddziały, w których następuje jedynie wprowadzanie danych (np. sklepy detaliczne), dzięki czemu możemy znacznie zmniejszyć obciążenie centralnej bazy danych;
4. Ze względów bezpieczeństwa chcemy, aby oddziały nie miały dostępu, nawet teoretycznie (za pomocą hasła administratora), do ważnych danych, takich jak bilans firmy.

W jednym przypadku dotyczyły mnie pytania 2 i 4, w innym 2 i 3. Punkt pierwszy jest zbyt obszerny i nie będzie rozpatrywany w ramach tego artykułu.

Lepiej też od razu rozważyć problem 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 jakich dokładnie gałęziach pojawią się węzły RDB (zwykle są to gałęzie regionalne). Następnie zastanawiamy się, gdzie jeszcze chcemy zainstalować węzły RDB i czy potrzebują one znaczenia online. Na przykład w sklepach detalicznych nie zawsze jest możliwe zainstalowanie nawet modemu, a zainstalowanie połączenia bezprzewodowego będzie zbyt kosztowne. Tutaj 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ą nośnika fizycznego, np. pendrive'a.

W niektórych przypadkach wymiana za pośrednictwem nośników fizycznych nie jest możliwa, np. jest to bardzo odległa branża, w której występują znaczne problemy z ustawieniem szybkiej komunikacji. Tutaj warto z grubsza obliczyć ilość wymienianych informacji. Często, jeśli jest to istotne, 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 (drukowane formularze, zdjęcia towaru), dlatego co jakiś czas zaistnieje sytuacja, gdy plik wymiany znacznie się powiększy z powodu do takich aktualizacji.

Topologia

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

1. W jakich działach mamy gwarancję zainstalowania węzłów RDB i czy można tam zainstalować szybki kanał;
2. W jakich działach nie jest wymagana instalacja jednostki RBD?
3. Które działy mogą pracować z znaczeniem za kilka godzin;
4. Które działy mogą pracować offline (wymiana danych rzadziej niż 3-4 razy dziennie).

Po odpowiedzi na te pytania otrzymujemy przybliżony schemat naszego RDB. W przypadku dużych firm zwykle wygląda to mniej więcej tak:

Ryc. 1. Typowy schemat RDB dużej firmy

Jeśli z węzłami „Oddział” wszystko jest w miarę jasne - są to duże ośrodki 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 fiskalnymi i dziennym obrotem przekraczającym 10 000 sztuk.

• Sklepy - wprowadzaj dane o własnych obrotach i przepływach pieniężnych. Analityka jest powierzchowna i dotyczy tylko Twojego własnego 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 wykorzystywana w każdym węźle. Z celów budowane są zadania niezbędne do realizacji, na przykład:

• Oddziały widzą historię wzajemnych rozliczeń ze swoimi kontrahentami;
• Sklepy widzą resztki towaru w całym (lub części) przedsiębiorstwa;
• Analityki przychodów/wydatków, wykonania budżetu itp. widoczne są jedynie w obrębie hierarchii własnego działu;
• Księgowość, płace i kadry widoczne są jedynie w obrębie hierarchii własnego działu;
• Nazewnictwo, wszystkie jego właściwości i cechy są widoczne we wszystkich węzłach RDB;
• W odniesieniu do hierarchii działów wszystkie dane przepływają w górę, ale są filtrowane w dół;
• W centrum znajdują się absolutnie wszystkie informacje o firmie.

Zadając sobie takie pytania, można odpowiedzieć na najtrudniejsze pytanie – jakie informacje, gdzie i w jaki sposób powinny przepływać pomiędzy węzłami RDB? Dlaczego najtrudniejszy? Wiedząc, jakie zbiory danych krążą pomiędzy węzłami, można jasno zrozumieć, jak „wyciąć” bieżącą bazę danych, tak aby dane pozostały logicznie spójne. Na przykład danych o stanach towarowych nie można oddzielić od danych o rezerwach bieżących.

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

Co widzimy na rysunku 2? Zgodnie z hierarchią oddziałów firmy zbudowano 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 środka jest zawsze wyższe 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 pozostałych węzłów RDB. Dostęp do niego ma wyłącznie administrator. „Centrum 2” służy do pracy centrali;
2. „Centrum 1” służy do pracy centrali. Jednak ciężkie operacje analityczne i testowe, które powodują ogromne obciążenie bazy danych, wykonywane są w węźle „Centrum 2”; np. przywrócenie sekwencji, przesunięcie okresów zamkniętych, wygenerowanie raportów zbiorczych dla całego przedsiębiorstwa w długim okresie, wygenerowanie analityki prowadzącej do zmian w danych;
3. „Centrum 1” służy do pracy centrali. „Centrum 2” to zabezpieczenie na wypadek nieprzewidzianych sytuacji umożliwiające szybkie przywrócenie całego RDB.

Realizacja wymiany

Istnieją 2 opcje działania RDB:

1. Automatyczny - następuje bez interwencji użytkownika. Kontrolę nad sytuacjami awaryjnymi przypisuje się administratorowi bazy danych lub użytkownikowi zaawansowanemu;
2. Ręczna – wymiana następuje wyłącznie na prośbę użytkownika.

Z mojego doświadczenia wynika, że ​​zawsze wszystkie wdrożenia prowadziłem do wersji automatycznej. Jeżeli pojawiały się problemy z transportem plików wymiany (obecność sieci w węźle nie jest stała) wówczas użytkownik mógł najwyżej kliknąć przycisk „Wymień teraz”. W sytuacjach, gdy oprócz aktualizacji danych następuje aktualizacja konfiguracji, wskazane jest wykonanie jej także w pełni automatycznie (np. przy użyciu oprogramowania firm trzecich).

Generowanie pakietów aktualizacji

Ponieważ istnieje jednoznaczna decyzja, które węzły RDB mają przypisane funkcje, możliwe jest wygenerowanie tylko takiego pakietu danych, jakiego potrzebuje ten węzeł. Z jednej strony konieczne jest określenie, jakie typy obiektów będą synchronizowane pomiędzy węzłami. Na przykład rejestry księgowe dla węzła „Sklep 1” nie powinny być w ogóle synchronizowane, ponieważ Dane wprowadzane są wyłącznie na poziomie węzła oddziału. Natomiast tego typu dane, które podlegają wymianie, należy filtrować w odniesieniu do działu. Przykładowo dane o przyjęciu pieniędzy z węzła „Sklep 1 oddział 2” mogą znajdować się jedynie w węzłach „Oddział 2”, „Centrum 1” i „Centrum 2”.

Istnieje jednak również odwrotny problem: jeśli zbyt mocno odfiltrujesz wymieniane dane, pakiet danych utraci swoją logiczną integralność. Na przykład, salda towarów są uwzględniane w kontekście magazynów, a rezerwy są uwzględniane w kontekście firmy jako całości, to jeśli salda towarów będą filtrowane według magazynów i nie będą filtrowane rezerwy, dane będą nieprawidłowe.

Należy także zdecydować, na jakim etapie życia przedmiot powinien zostać wymieniony. Na przykład można wymieniać tylko zaksięgowane faktury, ale nie tylko zapisane. Ani faktury Sklepu, ani razu nie są wyładowywane z węzła Centrum, nawet po ich skorygowaniu, należy jednak liczyć się z odwrotnym skutkiem – dane mogą nie być zsynchronizowane, bądź też niektóre zmiany mogą zostać nadpisane.

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

1. W węźle „Sklep 1” został utworzony dokument;
2. Podczas wymiany trafił do węzła „Oddział 1”;
3. Dokument jest korygowany jednocześnie w obu węzłach.

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

Istnieje inna, bardziej złożona sytuacja, gdy dwa połączone obiekty są dopasowywane jednocześnie. Na przykład faktura i PQR dla niej są korygowane w różnych węzłach, istnieje możliwość utraty integralności w przypadku zmiany cen, kwot płatności, kontrahentów itp.

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

Mechanizmy wymiany w 1C 8.x

Istnieją dwa podejścia do wdrożenia:

1. mechanizm „Planów Giełdy”;
2. Własna realizacja rejestracji obiektów.

Rozważmy obie opcje.

Mechanizm planów wymiany pozwala, bez żadnej konfiguracji, w ciągu kilku minut stworzyć bazę danych z pełną wymianą danych. Jeśli ustawisz flagę „Rozproszona baza danych”, to podczas tworzenia pakietu aktualizacji zostaną pobrane również aktualizacje konfiguracji. W ciągu zaledwie kilku minut możesz ustawić reguły zezwalające/zabraniające wymiany różnego rodzaju danych, otwierając skład planu wymiany. Jeśli ustawisz flagę „Autorejestracja” na pozycję „Odmów”, to tego typu obiekt nigdy nie zostanie wymieniony bez dodatkowego wysiłku.

Dlaczego potrzebujesz rejestracji, dlaczego nie przesłać wszystkiego na raz? W każdym przypadku plik zawierający jedynie zmiany stanu bazy danych będzie mniejszy niż pełny obraz samej bazy danych. Dlatego też opcja całkowitego rozładunku nie będzie brana pod uwagę.

Jak skonfigurować filtrowanie danych według przynależności do działu? Tutaj będziesz już musiał programować. W mojej realizacji na nagraniu dowolnego obiektu została zainstalowana subskrypcja zdarzenia „Podczas pisania”, gdzie za pomocą właściwości „Wymiana danych. Odbiorcy” można ustawić listę odbiorców tego obiektu. Te. Podczas rozładunku przy użyciu standardowych środków dla węzła, którego nie ma na liście, obiekt nie zostanie rozładowany. Jest jeszcze jedno rozwiązanie - możesz wybrać, czy chcesz rozładować obiekt bezpośrednio podczas rozładunku obiektu, w procedurach „Przy wysyłaniu danych do podwładnego” i „Przy wysyłaniu danych do mistrza” modułu planu wymiany.

Obie opcje mają prawo istnieć. Wybrałem jednak opcję pierwszą jako najlepszą, ponieważ wyliczenie atrybutu preloadability następuje natychmiast po zapisaniu obiektu, co wydłuża czas zapisu obiektu o 3-5% (można zoptymalizować, w niektórych przypadkach można zostać zmniejszona do 0,01%), tj. średnio 0,1-0,3 sekundy, a w przypadku obliczenia odciążalności obiektu bezpośrednio przy przesył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 przeczytać rozdział 15 książki „Rozwój zawodowy w systemie 1C:Enterprise 8”, Gabets A.P., Goncharov D.I.

Moim zdaniem każda własna implementacja albo powtórzy mechanizm „Planów wymiany”, albo wyładuje obiekt natychmiast po zmianie, albo wyładuje więcej niż mechanizm „Plany wymiany” (na przykład wyładuje wszystkie zmiany na dzisiaj). Nie rozważam tego problemu ze względu na brak doświadczenia wdrożeniowego.

Transport

Zadanie transportu plików z węzła głównego do węzła podrzędnego zostało zredukowane do maksymalnej odporności na uszkodzenia. Nierzadko zdarza się, że pliki są szyfrowane lub przesyłane bezpiecznym kanałem. 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; Zapasowym jest serwer pocztowy z połączeniem TLS. Dlaczego potrzebujesz kanału zapasowego z inną usługą? Jak pokazuje praktyka, używanie 2 różnych serwerów FTP jest mniej niezawodne niż serwera FTP i poczty e-mail.

Zalecam oddzielenie usługi tworzenia pakietu aktualizacji od usługi transportu, zwiększy to odporność na awarie 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 i, pod pewnymi warunkami, ponownie uruchomi usługę transportu i odwrotnie.

Moja implementacja RDB

Implementacja jest całkowicie autonomiczna, więc maksymalna odporność na błędy działała jako podzadanie. W rezultacie powstały 2 usługi – usługa przesyłania aktualizacji i 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żeli wymiana nie odbywała się przez bardzo długi czas, wówczas usługa transportowa zaczynała przesyłać pliki do wszystkich dostępnych jej kanałów komunikacji, oczekując, że drugi węzeł nadal będzie otrzymywał aktualizacje i przesyłał swoje pliki. W wyjątkowych sytuacjach system sam wysyła do administratora wiadomość ze szczegółowym opisem błędu.

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

Istnieją dwie tabele zawierające ustawienia filtra danych. Jedna (część tabelaryczna planów wymiany) przechowuje warunki dotyczące szczegółów ogólnych (dla każdego obiektu system próbuje znaleźć ten szczegół), druga zawiera ustawienia dla konkretnego obiektu metadanych. Rejestrując dowolny obiekt, najpierw wyszukuje się warunki według szczegółów ogólnych (np. Podział), po czym system próbuje ustalić, czy istnieje reguła osobista dla tego typu obiektu, wykorzystując wszystkie jego szczegóły. Nie polecam filtrowania zestawień – istnieje duże ryzyko popełnienia błędu, np. z tabelarycznej części faktury zniknie kilka wierszy, a pozostałe saldo przesunie się i odwrotnie.

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

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

Ogólny schemat działania kompleksu wymiany danych pokazano na rys. 3.

Filtrowanie danych odbywa się w ramach subskrypcji zdarzenia „BeforeRecording” każdego obiektu. Nie zapominaj, że podczas tworzenia początkowego obrazu węzła dane również muszą zostać przefiltrowane. Procedura tworzenia obrazu początkowego jest dość długa, dlatego zalecam maksymalną optymalizację jego kodu (na przykład ustawienia filtrowania buforowania).

Posłowie

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

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

Przetwarzanie „Rejestracji zmian”

Przetwarzanie umożliwia wymuszenie rejestracji zmian w obiektach. Istnieje kilka możliwości rejestrowania zmian:

1. Jeżeli sprawdzono jakiekolwiek metadane, nie wybrano żadnego obiektu i NIE ustawiono flagi „Wczytaj wszystkimi wartościami”, wówczas REJESTROWANA JEST TYLKO WYBRANA TABELA;
2. Jeżeli ustawiona jest flaga „Prześlij wszystkie wartości”, wybrane metadane zostaną wyładowane dla wszystkich obiektów w cyklu;
3. Jeżeli przełącznik ustawiony jest na tryb „Prześlij tylko wybrane obiekty”, to wyładowane zostaną tylko wybrane obiekty (przykładowo: ustawienie flagi na metadanych bez zaznaczania obiektów jest równoznaczne z włączeniem flagi „Prześlij według wszystkich wartości” i ustawieniem przełącznika w pozycji „Rozładuj tylko wybrane obiekty”;
4. Jeżeli przełącznik ustawiony jest na tryb „Wyładuj wybrane i bezpośrednio powiązane obiekty”, wówczas wyładowane zostaną wybrane obiekty oraz te, których istnienie zależy od istnienia wybranego obiektu (przykładowo: dla katalogów - katalogi podrzędne);
5. Jeśli przełącznik jest ustawiony na tryb „Prześlij przy użyciu wszystkich linków”, wówczas WSZYSTKIE obiekty zawierające link do wybranego obiektu zostaną usunięte.

Dostępna dodatkowa funkcjonalność:

• Do debugowania często wymagana jest ponowna rejestracja zarejestrowanych obiektów;
• Do debugowania często wymagane jest usunięcie zarejestrowanych;
• Drukuj zmiany - wydrukuj pełną listę obiektów oznaczonych jako zmienione;
• Wydruk drzewa konfiguracyjnego służy wyłącznie wygodzie przeglądania całej konfiguracji.

Często w praktyce zdarzają się sytuacje, gdy różne oddziały lub oddziały są geograficznie zlokalizowane w różnych miejscach. Jednocześnie dane wprowadzane do programu w odległych działach muszą w jakiś sposób dotrzeć do centrali, aby została zachowana ogólna ewidencja.

Obecnie problem ten często rozwiązuje się poprzez zapewnienie pracownikom oddalonym geograficznie zdalnego dostępu do wspólnej bazy danych. Można tego dokonać poprzez publikację bazy danych na serwerze www, poprzez zdalny pulpit itp.

Jednak nierzadko zdarzają się sytuacje, gdy w odległym geograficznie biurze po prostu nie ma Internetu lub nie jest on na tyle stabilny, aby pracować we wspólnej bazie danych. W tym celu 1C posiada mechanizm konfigurowania rozproszonej bazy danych.

Mówiąc najprościej, siedziba główna to miejsce, w którym znajduje się główna baza. Dział zdalny korzysta z podwładnego. Może istnieć kilka takich baz niewolników. W rezultacie taka rozproszona baza danych zostaje zjednoczona w jedną poprzez synchronizację. Można to zrobić automatycznie, zgodnie z harmonogramem lub ręcznie.

W tym artykule przyjrzymy się konfigurowaniu rozproszonej bazy danych dla 1C: Księgowość 3.0. Mimo to instrukcje są odpowiednie dla większości innych konfiguracji 1C 8.3.

notatkaże wszelkich niezbędnych zmian konfiguracyjnych należy dokonywać wyłącznie w głównej bazie danych RIB. Podczas synchronizacji zmiany te zostaną przesłane do wszystkich baz danych slave i zaczną obowiązywać.

Główna baza informacji

W przypadku korzystania z rozproszonej bazy danych główne ustawienia przypadają na główną bazę danych. Należy to zrobić w sekcji „Administracja”, jak pokazano na obrazku poniżej.

W oknie, które zostanie otwarte, od razu zaznacz pole wyboru „Synchronizacja danych”. Na dole podaj przedrostek głównej (bieżącej bazy danych). Może składać się z nie więcej niż dwóch znaków. W naszym przypadku przedrostkiem będzie „BG”, ponieważ mamy na myśli, że ten RIB 1C to „Główna księgowość”.

Teraz możesz rozpocząć konfigurowanie samej synchronizacji, czyli określić, z jaką bazą danych (lub bazami danych) będą wymieniane dane. W tym celu należy skorzystać z hiperłącza „Ustawienia synchronizacji danych”. Będzie dostępny do nawigacji tylko wtedy, gdy zaznaczone zostanie pole wyboru po lewej stronie.

W oknie, które zostanie otwarte, wybierz z menu opcję „Pełne...”. Pozwoli nam to określić dowolną bazę informacyjną 1C do synchronizacji.

W pierwszym oknie podłączenia podrzędnej bazy danych, która znajduje się w odległym geograficznie biurze, zaznacz opcję, że połączenie będzie realizowane poprzez katalog lokalny lub sieciowy. W naszym przypadku jest to „D:\DB\InfoBase”. Sprawdzimy też wcześniej, czy możesz do niego napisać.

Pamiętaj, aby określić różne przedrostki dla różnych baz danych. Faktem jest, że podczas synchronizacji danych przeciążonym danym z każdej bazy danych przypisywany jest własny prefiks. Jeśli zostaną zdublowane, praca będzie niepoprawna, dlatego program nie da Ci takiej możliwości.

Gdy program poprosi o utworzenie obrazu startowego, wybierz tę opcję. Ta procedura zajmie trochę czasu, po czym zapisz ją na swoim komputerze pod nazwą „1Cv8.1CD”.

Sama synchronizacja może zostać przeprowadzona automatycznie, zgodnie z harmonogramem, który możesz ustawić samodzielnie, lub ręcznie. W drugim przypadku po prostu kliknij przycisk „Synchronizuj” w dogodnym dla Ciebie momencie.

Węzeł podrzędny RIB

Liczba ustawień dokonanych w bazie danych slave jest znacznie mniejsza. W tej samej sekcji ustaw flagę „Synchronizacja danych” i klikając odpowiedni link, dostępny będzie przycisk „Synchronizuj”.

W naszym przykładzie do głównej bazy danych zostały dodane dwa elementy: „Belka” i „Deska”. Po synchronizacji trafiły do ​​bazy danych slave. Jak widać na poniższym obrazku, nadano im przedrostek „BG”. Pozostałe dwie pozycje („Tokarka” i „Paleta”) mają przypisany przedrostek „BP”, ponieważ zostały utworzone bezpośrednio w podrzędnej bazie danych.

notatkaże numeracja elementów w naszym przypadku jest ciągła, ale tylko w obrębie tego samego przedrostka.

RIB to rozproszona baza informacji, która ma strukturę drzewiastą, której gałęziami są indywidualnie wdrożone bazy danych 1C Enterprise. Bazy te nazywane są węzłami rozproszonej bazy informacji (zwanymi dalej po prostu węzłami). Pomiędzy tymi węzłami następuje wymiana informacji w celu synchronizacji wszystkich węzłów (konfiguracje i bazy danych).

Głównym mechanizmem jest mechanizm wymiany o pewnych charakterystycznych i uniwersalnych możliwościach. Główna różnica polega na tym, że mechanizm wymiany RIB jest bardziej wyspecjalizowany i wąski, natomiast giełdy uniwersalne zapewniają użytkownikowi szerszy wachlarz możliwości.

Podstawowe zasady działania RIB

Możliwa jest zmiana struktury konfiguracji tylko w głównym węźle głównym rozproszonej bazy danych. Zmiany te są następnie propagowane hierarchicznie do podrzędnych węzłów. W ten sposób zapewnia to pojedynczą przestrzeń struktury konfiguracyjnej we wszystkich węzłach RIB.

Dane można zmieniać w dowolnym z węzłów, co z kolei jest dystrybuowane do wszystkich pozostałych węzłów. Co więcej, dane te nie muszą być koniecznie przekazywane innym uczestnikom systemu i może nie zostać zachowana ich pełna tożsamość. Deweloper może według potrzeb dostosować skład danych uczestniczących w wymianie z innymi uczestnikami RIB. Co więcej, ustawień można dokonać nie tylko na poziomie metadanych konfiguracji, ale także na poziomie poszczególnych elementów, na których można dokonać specjalnych selekcji.

Jak wspomniano powyżej, mechanizm RIB realizowany jest poprzez wykorzystanie planów wymiany. ale aby konkretny plan mógł być używany w tej hierarchicznej strukturze, jego właściwość „Rozproszona baza danych” musi być aktywowana.

Wszystkie dane są przesyłane do RIB za pośrednictwem komunikatów. Treść tych komunikatów jest jasno uregulowana i nie może być dowolna, jak ma to miejsce w uniwersalnym mechanizmie wymiany. Dane umieszczane są w wiadomości z wykorzystaniem zasady serializacji XML. Oprócz tych zmian danych wiadomość zawiera także informacje o zmianach konfiguracji, a także pewną ilość informacji serwisowych. Zmiany są rejestrowane i umieszczane w wiadomości wymiany całkowicie automatycznie. Ani użytkownik, ani programista nie mają na to wpływu.

Odbiór i generowanie komunikatów wymiany w RIB-ie ustawiane są za pomocą jednego polecenia

Plany wymiany. WriteChanges(WriteMessages, 0)

Treść odczytywana jest za pomocą polecenia

Wniosek

Można śmiało powiedzieć, że mechanizm RIB składa się głównie z uniwersalnego mechanizmu wymiany z pewnymi charakterystycznymi cechami, które występują tylko w strukturze RIB.