1s 8 ребра и добавени обекти. Разпределена информационна база: Основи

За да създадете разпределена информационна база, трябва да влезете в програмата в режим 1C: Enterprise. За да създадете възли на разпределена база данни, изберете от менюто: Операции - Планове за обмен. Ще се отвори прозорецът „Избор на обект: План за обмен“.

1. Обмислете опцията с плана за обмен „Пълен“.

Обменът ще се извършва между всички организации, намиращи се в разпределената информационна база.

Нека изберем плана за обмен „Пълен“. Ще се отвори прозорецът „Пълен план за обмен“.

Попълваме два записа:

Нека наречем първия запис „Главен възел“, посочете кода „GU“,

Нека наречем втория запис „Подчинен възел“, посочете кода „PU“.

Както можем да видим от фигурата, първият запис има икона със зелен кръг; това е иконата „Главен възел“.

За да създадете копие на информационната база „Главен възел“, щракнете върху „Подчинен възел“ и щракнете върху иконата „Създаване на първоначално изображение“. Това ще бъде информационната база „Подчинен възел“.

Ще се отвори прозорецът „Създаване на първоначално изображение за защита на информацията“, изберете „На този компютър или на компютър в локалната мрежа“, щракнете върху „Напред“.

В полето „Директория на информационната база“ изберете мястото, където ще бъде инсталирано копието на „Главния възел“ и щракнете върху „Край“.

След създаването на информационната база „Подчинен възел“ ще се появи следното съобщение:

Кликнете върху „Ok“.

Добавете информационната база „Подчинен възел“ към „1C: Enterprise“. Отиваме в подчинената база данни в режим "1C: Enterprise". Да отворим: Операции - Планове за обмен. Ще се отвори прозорецът „Избор на обект: План за обмен“. Нека изберем плана за обмен „Пълен“. Ще се отвори прозорецът „Пълен план за обмен“. Виждаме, че иконата “Main Node” е оранжева, което означава, че този възел е основният възел за информационната база, в която се намираме.

Правим следните настройки както в главния, така и в подчинения възел:

1. Добавете префикс за разпределената информационна база.

Това се прави, за да няма конфликти в номерата и кодовете на документите и директориите, създадени в две бази данни, така че във всяка база данни посочваме префикс, който ще бъде добавен към номерата на документите и кодовете на директориите. Отворете: Инструменти - Настройки на програмата - раздел "Обмен на данни". В полето „Префикс на възел за разпределена информационна база:“ ​​въведете „PU“ в подчинената база данни и „GU“ в основната база данни.

2. Добавяне на настройка за обмен на данни между възли:

Отворете: Услуга - Разпределена информационна база (DIB) - Конфигуриране на RIB възли. Ще се отвори прозорецът „Настройки за обмен на данни“.

Щракнете върху „Добавяне“ и ще се отвори прозорецът „Настройки за обмен на данни“. Въведете „Име“ на вашата настройка.

Възел автоматично ще се появи в полето „Възел“, за „Главен възел“ ще има „Подчинен възел“, за „Подчинен възел“ ще има „Главен възел“.

В полето „Директория“ изберете папката, в която ще бъдат изпратени данните за обмен, най-добре е да посочите една директория за основната и подчинената база данни.

В полето „Тип обмен“ конфигурираме прехвърлянето на данни между бази данни: чрез файл или FTP ресурс. Нека изберем например „споделяне чрез файлов ресурс“.

Не променяме нищо в останалите полета.

Кликнете върху „Ok“. Виждаме, че се е появила настройка.

3. За обмен на данни правим следното:

Първо, в базата данни, в която са направени промените, щракнете върху иконата „Обмен според текущата настройка“, както е показано на фигурата.

След качването ще се появи прозорецът с резултатите от качването.

След това в базата данни, към която искате да прехвърлите промените, щракнете върху иконата „Обмен според текущата настройка“ и данните ще отидат в базата данни, която желаете.

2. Обмислете опцията с плана за обмен „По организация“.

Обменът ще се извършва между избрани организации, разположени в разпределена информационна база.

За да създадете възли на разпределена база данни, изберете от менюто: Операции - Планове за обмен. Ще се отвори прозорецът „Избор на обект: План за обмен“.

Нека изберем плана за обмен „По организация“. Ще се отвори прозорецът „План за обмен по организация“.

Попълваме два записа:

Нека наречем първия запис „Основен възел“, посочете кода „GU“, виждаме разликата от „План за обмен: пълен“, появи се таблица, в която посочваме Организациите, за които ще се извърши обменът.

Нека наречем втория запис „Подчинен възел“, посочете кода „PU“, посочете организацията.

Във всички останали отношения настройката е абсолютно същата като при „План за обмен: пълен“.

Това е първата ми статия, градивната критика е добре дошла.

Целевата аудитория са тези, които се сблъскват с RBD за първи път.

RDB задачи

Първото нещо, с което трябва да започнете, е да отговорите на въпроса „Защо се нуждаем от RDB?“ Има много възможни отговори, по-специално:

1. Имаме клонове, работещи в несвързани бази данни. Сега искаме информацията между тях да бъде синхронизирана;
2. Имаме клонове, но натоварването на базата данни е твърде високо (това означава блокиране на транзакция, а не обема на базата данни) и онлайн уместност (да не се бърка с уместност за няколко минути, онлайн е, когато след всяка транзакция данните са прехвърлено към втория възел) няма необходими данни за клонове;
3. Имаме клонове, където се извършва само въвеждане на данни (например магазини за търговия на дребно), така че можем значително да намалим натоварването на централната база данни;
4. От съображения за сигурност искаме клоновете да нямат достъп, дори теоретично (с администраторска парола), до важни данни, като например баланса на компанията.

В един случай за мен бяха уместни въпроси 2 и 4, в друг - 2 и 3. Първата точка е твърде обширна и няма да бъде разглеждана в рамките на тази статия.

Също така е по-добре незабавно да разгледате проблема с транспортирането на файлове за обмен, тъй като в някои случаи това може да наложи значителни ограничения върху осъществяването на обмен на данни. Първо, трябва да определите в кои точно клонове ще се появят RDB възлите (обикновено това са регионални клонове). След това обмисляме къде другаде искаме да инсталираме RDB възли и дали имат нужда от онлайн релевантност. Например, за магазините на дребно не винаги е възможно да се инсталира дори модем, а инсталирането на безжична връзка ще бъде твърде скъпо. Тук трябва да вземете решение - може би този магазин може да работи офлайн и периодично да обменя с центъра (веднъж на ден/веднъж седмично), като използва физически носител, като например флашка.

В някои случаи обменът чрез физически носители не е възможен, например това е много отдалечен клон, където има значителни проблеми с настройката на високоскоростна комуникация. Тук си струва грубо да се изчисли количеството обменена информация. Често, ако е подходящо веднъж на час или няколко пъти на ден, е достатъчен 32k модем. Все пак си струва да запомните, че заедно с актуализациите на данните понякога ще трябва да изпращате актуализации на самата конфигурация или външни файлове (отпечатани формуляри, снимки на стоки), така че от време на време ще възникне ситуация, когато файлът за обмен се увеличи значително поради към такива актуализации.

Топология

Общо получихме следните въпроси, на които трябва да се отговори:

1. В кои отдели гарантираме инсталирането на RDB възли и възможно ли е да инсталираме високоскоростен канал там;
2. В кои отдели не се изисква инсталиране на RBD модул?
3. Кои отдели могат да работят по отношение на няколко часа;
4. Кои отдели могат да работят офлайн (обмен на данни по-малко от 3-4 пъти на ден).

След като отговорихме на тези въпроси, получаваме приблизителна диаграма на нашата RDB. За големите компании обикновено се оказва нещо подобно:

Фигура 1. Типична диаграма на RDB на голяма компания

Ако с възлите „Клон“ всичко е сравнително ясно - това са големи центрове, които изискват автоматизация, тогава възлите „Съхранение“ означават възел със сериозно натоварване на базата данни при въвеждане на данни, които трябва да бъдат разделени, за да се намали натоварването. Например магазин с 50 каси и дневен оборот над 10 000 единици.

• Магазини - въведете данни за собствения си оборот и паричен поток. Анализите са повърхностни, само за собствен магазин.
• Клонове - въвеждане на данни на неавтоматизирани точки, счетоводство, заплати и персонал, производство и др. Анализ във вашия собствен клон.
• Център - въвеждане на данни на неавтоматизирани клонове. Анализ на предприятието като цяло.

Важно е да се разбере за какви цели ще се използва базата данни във всеки възел. От целите се изграждат задачите, необходими за изпълнение, например:

• Клоновете виждат историята на взаимните разплащания с контрагентите помежду си;
• Магазините виждат остатъчни стоки в цялото (или част от) предприятието;
• Анализите на приходите/разходите, изпълнението на бюджета и т.н. са видими само в рамките на йерархията на вашия собствен отдел;
• Счетоводството, заплатите и персоналът са видими само в рамките на йерархията на вашия собствен отдел;
• Номенклатурата, всички нейни свойства и характеристики са видими във всички възли на RDB;
• По отношение на йерархията на отделите всички данни се движат нагоре, но се филтрират надолу;
• Центърът съдържа абсолютно цялата информация за компанията.

Задавайки си такива въпроси, можете да отговорите на най-трудния въпрос - каква информация, къде и как трябва да тече между RDB възлите? Защо най-трудното? Знаейки кои набори от данни циркулират между възлите, можете ясно да разберете как да „отрежете“ текущата база данни, така че данните да останат логически последователни. Например данните за балансите на стоки не могат да бъдат отделени от данните за текущите резерви.

Сега, в зависимост от информационните потоци, нека преначертаем RDB диаграмата:

Какво виждаме на фигура 2? В съответствие с йерархията на подразделенията на компанията е изградена топология на информационния поток между възлите на базата данни. Възелът „Център 2“ също е добавен, защо? При внедряването на топологията Star, натоварването на центъра винаги е по-високо от натоварването на периферните възли и често натоварването, генерирано от самия възел, вече е високо. Примери за използване на възлите „Център 1“ и „Център 2“:

1. „Център 1“ служи само за консолидиране на данни от други RDB възли. Само администраторът има достъп до него. „Център 2” служи за работата на централата;
2. „Център 1” служи за работата на централата. Въпреки това, тежки аналитични и тестови операции, които създават огромно натоварване на базата данни, се извършват във възела „Център 2“; например възстановяване на последователността, разсрочване на затворени периоди, генериране на обобщени отчети за цялото предприятие за дълъг период от време, генериране на анализи, които водят до промени в данните;
3. „Център 1” служи за работата на централата. „Център 2” е резервно копие в случай на непредвидени ситуации за бързо възстановяване на цялата RDB.

Осъществяване на обмен

Има 2 опции за работа с RDB:

1. Автоматично - възниква без намеса на потребителя. Контролът върху аварийните ситуации се възлага или на администратора на базата данни, или на напреднал потребител;
2. Ръчно - обменът се извършва само по желание на потребителя.

Според моя опит винаги водех всички внедрявания към автоматичната версия. Ако имаше проблеми с транспортирането на файлове за обмен (наличието на мрежа в възела не е постоянно), тогава максимумът, който потребителят може да направи, е да щракнете върху бутона „Обмен сега“. Ситуации, при които освен актуализирането на данните има и актуализиране на конфигурацията, е препоръчително това да се направи и напълно автоматично (например чрез софтуер на трети страни).

Генериране на пакети за актуализация

Тъй като има недвусмислено решение за това кои RDB възли кои функции са присвоени, е възможно да се генерира само пакетът от данни, от който този възел се нуждае. От една страна е необходимо да се уточни какви типове обекти ще се синхронизират между възлите. Например, счетоводните регистри за възела „Магазин 1” изобщо не трябва да се синхронизират, т.к. Данните се въвеждат само на ниво разклонителен възел. От друга страна, тези видове данни, които подлежат на обмен, трябва да бъдат филтрирани по отношение на отдела. Например данните за получаването на пари от възела „Магазин 1 клон 2“ могат да се намират само в възлите „Клон 2“, „Център 1“ и „Център 2“.

Съществува обаче и обратният проблем: ако филтрирате твърде много данните за обмен, пакетът от данни ще загуби своята логическа цялост. Например балансите на стоките се вземат предвид в контекста на складовете, а резервите се вземат предвид в контекста на компанията като цяло, тогава ако филтрирате балансите на стоките по складове и не филтрирате резервите, данните ще бъдат неверни.

Трябва също така да решите на какъв етап от живота си предметът трябва да бъде заменен. Например могат да се обменят само осчетоводени фактури, но не и само запазени. Или фактурите на магазина никога не се разтоварват от централния възел, дори след като са коригирани, но трябва да се вземе предвид обратният ефект - данните може да не са синхронизирани или някои промени могат да бъдат презаписани.

Важно е да се разбере, че при обмен между възли един от тях има приоритет. Помислете за ситуацията:

1. Във възела „Магазин 1” е създаден документ;
2. По време на обмена той се озова в възела „Клон 1“;
3. Документът се коригира едновременно и в двата възела.

Кой документ ще се счита за верен? В 1C 8.x, когато използвате механизма „Планове за обмен“, приоритетът по подразбиране е главният възел, т.е. в този случай промените, направени в възела „Магазин 1“, ще бъдат загубени и заменени с данни от възела „Клон 1“.

Има и друга, по-сложна ситуация, когато два свързани обекта се настройват едновременно. Например, фактурата и PQR за нея се коригират в различни възли, има възможност за загуба на цялост, ако се променят цени, суми на плащане, контрагенти и др.

Също така е важно да се контролира изтриването на обекти, в противен случай това може да доведе до факта, че например фактура вече няма да съществува, но счетоводните движения ще останат.

Механизми за обмен в 1C 8.x

Има два подхода за изпълнение:

1. Механизъм „Планове за обмен“;
2. Собствено изпълнение на обектна регистрация.

Нека разгледаме и двата варианта.

Механизмът на плановете за обмен позволява, без никаква конфигурация, за няколко минути да се създаде база данни с пълен обмен на данни. Ако зададете флага „Разпределена информационна база“, тогава при създаването на пакет за актуализация ще бъдат изтеглени и актуализации на конфигурацията. Само за няколко минути можете да настроите правила за разрешаване/забрана на обмен на различни видове данни, като отворите състава на плана за обмен. Ако зададете флага „Автоматична регистрация“ на позиция „Отказ“, тогава този тип обект никога няма да бъде обменен без допълнителни усилия.

Защо ви трябва регистрация, защо не качите всичко наведнъж? Във всеки случай файл, съдържащ само промени в състоянието на базата данни, ще бъде по-малък от пълна моментна снимка на самата база данни. Следователно вариантът за пълно разтоварване няма да се разглежда.

Как да настроите филтриране на данни по принадлежност на отдел? Тук вече ще трябва да програмирате. В моята реализация беше инсталиран абонамент за събитието "При писане" на записа на всеки обект, където, използвайки свойството "Обмен на данни. Получатели", можете да зададете списъка с получатели на този обект. Тези. При разтоварване чрез стандартни средства за възел, който не е в списъка, обектът няма да бъде разтоварен. Има и друго решение - можете да изберете дали да разтоварвате обект директно при разтоварване на обекта, в процедурите „При изпращане на данни към подчинен“ и „При изпращане на данни към главен“ на модула за план за обмен.

И двата варианта имат право на съществуване. Въпреки това избрах първата опция като най-добра опция, тъй като изчисляването на атрибута за предварително зареждане се извършва веднага, когато обектът е написан, което увеличава продължителността на записа на обекта с 3-5% (може да се оптимизира, в някои случаи може да се намали до 0,01%), т.е. средно 0,1-0,3 секунди, а в случай на изчисляване на разтоварваемостта на обект директно при изпращане на данни, което вече създава значително натоварване на базата данни, това време ще бъде до няколко минути.

За да разберете напълно работата на механизма „Планове за обмен“, препоръчвам да прочетете глава 15 от книгата „Професионално развитие в системата 1C:Enterprise 8“, Габец А.П., Гончаров Д.И.

Всяко собствено внедряване, по мое мнение, или ще повтори механизма „Планове за обмен“, или ще разтовари обекта веднага при промяна, или ще разтовари повече от механизма „Планове за обмен“ (например ще разтовари всички промени за днес). Не разглеждам този въпрос поради липса на опит в прилагането.

транспорт

Задачата за транспортиране на файлове от главния към подчинения възел е намалена до максимална отказоустойчивост. Не е необичайно файловете да бъдат криптирани или предадени по защитен канал. За прехвърляне на файлове е препоръчително да използвате няколко различни услуги или да подготвите няколко различни опции за свързване. Например, основният метод за прехвърляне е използването на FTP сървър, свързан чрез VPN тунел; Резервният е сървър за електронна поща с TLS връзка. Защо ви е необходим резервен канал с друга услуга? Както показва практиката, използването на 2 различни FTP сървъра е по-малко надеждно от FTP сървър и електронна поща.

Препоръчвам да отделите услугата за създаване на пакет за актуализиране от транспортната услуга, това ще увеличи устойчивостта на грешки на целия комплекс за обмен на данни. Ако услугата за транспортиране на файлове не работи, услугата за създаване на пакети за актуализиране ще продължи да работи нормално и при определени условия ще рестартира услугата за транспортиране и обратно.

Моята реализация на RDB

Внедряването е напълно автономно, така че максималната толерантност към грешки действа като подзадача. Това доведе до 2 услуги - услугата за транспортиране на актуализиране и услугата за импортиране/експортиране на данни. И двете услуги работят независимо една от друга.

След всеки успешен цикъл на импортиране и експортиране на данни времето на последния обмен с този възел се запазва. Ако обменът не се осъществи много дълго време, тогава транспортната услуга започва да качва файлове във всички комуникационни канали, достъпни за нея, с очакването, че вторият възел все още ще получава актуализации и ще качва своите файлове. В случай на извънредни ситуации системата сама изпраща съобщение до администратора с подробно описание на грешката.

За да се намали обемът на трафика, xml файловете бяха пакетирани в zip архиви. Системата поддържа два вида транспорт - FTP и E-mail.

Има две таблици като настройки за филтъра за данни. Единият (табличната част на плановете за обмен) съхранява условия за общи подробности (за всеки обект системата се опитва да намери този детайл), другият съдържа настройки за конкретен обект на метаданни. При записване на който и да е обект условията първо се търсят по общи данни (например Разделяне), след което системата се опитва да определи дали има персонално правило за този тип обект, използвайки всички негови подробности. Не препоръчвам филтриране на списъците - има голяма вероятност да направите грешка, например няколко реда ще изчезнат от табличната част на фактурата, а оставащото салдо ще се премести и обратно.

Важно е да разберете под кой потребител на системата ще работят услугите, тъй като Възможно е да нямате достатъчно права за създаване на файлове дори във временната папка 1C. За отстраняване на грешки силно препоръчвам да записвате всяка успешно завършена операция в регистъра за регистрация или в txt файл. В 1C 8.1 изпълнението на сървърния код не може да бъде отстранено.

За удобство при отстраняване на грешки и настройка на моята реализация, прилагам обработката „Регистриране на промените“, чието описание е в самата обработка.

Общата оперативна схема на комплекса за обмен на данни е показана на фиг. 3.

Филтрирането на данни се извършва в абонамент за събитието „BeforeRecording“ на всеки обект. Не забравяйте, че когато създавате първоначалното изображение на възел, данните също трябва да бъдат филтрирани. Процедурата за създаване на първоначално изображение е доста дълга, така че препоръчвам да оптимизирате неговия код до максимум (например кеширане на настройките за филтриране).

Послеслов

Основната задача е да отговорите на списък от въпроси:

1. Защо се нуждаем от RDB?
2. Какво не харесвате в работата чрез RDP клиент?
3. Къде и защо искаме да инсталираме RDB възли?
4. Как ще се транспортират актуализациите?
5. Какво ниво на отказоустойчивост ще бъде приложено?

Обработка на "Регистрация на промени"

Обработката ви позволява да принудите да регистрирате промени в обекти. Има няколко опции за регистриране на промените:

1. Ако са проверени метаданни и не са избрани обекти и флагът "Зареждане по всички стойности" НЕ е зададен, тогава СЕ РЕГИСТРИРА САМО ИЗБРАНАТА ТАБЛИЦА;
2. Ако флагът "Качване за всички стойности" е зададен, тогава избраните метаданни ще бъдат разтоварени за всички обекти в цикъла;
3. Ако превключвателят е настроен на режим „Качване само на избрани обекти“, тогава само избраните обекти ще бъдат разтоварени (например: задаване на флаг върху метаданни без избиране на обекти е еквивалентно на включване на флага „Качване по всички стойности“ и превключвателя в позиция "Разтоварване само на избрани обекти";
4. Ако превключвателят е настроен на режим "Разтоварване на избрани и пряко свързани обекти", тогава избраните обекти и онези обекти, чието съществуване зависи от съществуването на избрания обект, ще бъдат разтоварени (например: за директории - подчинени директории);
5. Ако превключвателят е настроен на режим „Качване чрез всички връзки“, тогава ВСИЧКИ обекти, които съдържат връзка към избрания обект, ще бъдат разтоварени.

Налична допълнителна функционалност:

• Често се изисква повторно регистриране на регистрирани обекти за отстраняване на грешки;
• Премахването на регистрираните често се изисква за отстраняване на грешки;
• Печат на промените - отпечатване на пълен списък с обекти, които са маркирани като променени;
• Отпечатването на конфигурационното дърво е само за удобство при преглед на цялата конфигурация.

Често на практика има ситуации, когато различни подразделения или клонове са географски разположени на различни места. В същото време данните, въведени в програмата в отдалечени отдели, трябва по някакъв начин да стигнат до централния офис, така че да се поддържат общи записи.

Понастоящем този проблем често се решава чрез предоставяне на географски отдалечени служители с отдалечен достъп до обща база данни. Може да стане чрез публикуване на базата данни на уеб сървър, чрез отдалечен работен плот и др.

Въпреки това не са необичайни ситуации, когато просто няма интернет в географски отдалечен офис или не е достатъчно стабилен, за да работи в обща информационна база. За тази цел 1C има механизъм за създаване на разпределена база данни.

Просто казано, главният офис е мястото, където се намира основната база. Отдалеченият отдел използва подчинен. Може да има няколко такива робски бази. В резултат на това такава разпределена база данни се обединява в една чрез синхронизация. Може да се извърши както автоматично по график, така и ръчно.

В тази статия ще разгледаме създаването на разпределена база данни за 1C: Accounting 3.0. Въпреки това инструкциите са подходящи за повечето други конфигурации на 1C 8.3.

Забележкаче всички необходими модификации на конфигурацията трябва да се правят само в основната база данни на RIB. По време на синхронизирането тези промени ще бъдат предадени на всички подчинени бази данни и ще влязат в сила.

Основна информационна база

Когато използвате разпределена база данни, основните настройки попадат върху основната база данни. Те трябва да бъдат направени в секцията „Администриране“, както е показано на изображението по-долу.

В прозореца, който се отваря, незабавно поставете отметка в квадратчето „Синхронизиране на данни“. В долната част посочете префикса на основната (текущата база данни). Може да се състои от не повече от два знака. В нашия случай префиксът ще бъде „BG“, тъй като имаме предвид, че този RIB 1C е „Основно счетоводство“.

Сега можете да започнете да настройвате самата синхронизация, а именно да посочите с коя база данни (или бази данни) ще се обменят данните. За да направите това, следвайте хипервръзката „Настройки за синхронизиране на данни“. Ще бъде достъпен за навигация само ако е поставена отметка в квадратчето отляво.

В прозореца, който се отваря, изберете „Пълен...“ от менюто. Това ще ни позволи да посочим всяка 1C информационна база за синхронизация.

В първия прозорец за свързване на подчинена база данни, която се намира в географски отдалечен офис, поставете отметка, че връзката ще се осъществява през локална или мрежова директория. В нашия случай това е „D:\DB\InfoBase“. Също така ще проверим предварително дали можете да му пишете.

Не забравяйте да посочите различни префикси за различните бази данни. Факт е, че при синхронизиране на данни, данните, претоварени от всяка база данни, получават собствен префикс. Ако се дублират, работата ще бъде некоректна, така че програмата няма да ви даде тази възможност.

Когато програмата ви подкани да създадете стартово изображение, изберете тази опция. Тази процедура ще отнеме известно време, след което я запазете на вашия компютър с името „1Cv8.1CD“.

Самата синхронизация може да се извърши както автоматично по график, който можете да настроите сами, така и ръчно. Във втория случай просто кликнете върху бутона „Синхронизиране“ в удобно за вас време.

RIB подчинен възел

Броят на настройките, направени в подчинената база данни, е значително по-малък. В същия раздел задайте флага „Синхронизиране на данни“ и като щракнете върху съответната връзка, бутонът „Синхронизиране“ ще бъде достъпен.

В нашия пример два елемента бяха добавени към основната база данни: „Beam“ и „Board“. След синхронизиране те се озоваха в подчинената база данни. Както можете да видите на снимката по-долу, те получиха префикса "BG". Останалите две позиции („Струг“ и „Палет“) са с префикс „BP“, тъй като са създадени директно в подчинената база данни.

Забележкаче номерацията на елементите в нашия случай е непрекъсната, но само в рамките на един и същ префикс.

RIB е разпределена информационна база, която представлява дървовидна структура, чиито клонове са отделни разгърнати бази данни 1C Enterprise. Тези бази данни се наричат ​​възли на разпределена информационна база (наричани по-нататък просто възли). Между тези възли се формира обмен на информация, за да се синхронизират всички възли (конфигурации и бази данни).

Основният механизъм е обменен механизъм с някои отличителни и универсални възможности. Основната разлика е, че механизмът за обмен на RIB е по-специализиран и тесен, докато универсалните обмени предоставят на потребителя по-широк набор от възможности.

Основни принципи на работа на RIB

Възможно е да се промени структурата на конфигурацията само в главния основен възел на разпределената информационна база. След това тези промени се разпространяват йерархично към подчинените възли. По този начин това осигурява единно пространство за конфигурационна структура във всички RIB възли.

Данните могат да се променят във всеки от възлите, които от своя страна се разпространяват към всички останали възли. Освен това не е задължително тези данни да се прехвърлят на други участници в системата и може да не се запази пълната им идентичност. Разработчикът може да персонализира състава на данните, които участват в обмена с други участници в RIB, както желае. Освен това настройките могат да се правят не само на ниво метаданни за конфигурация, но и на ниво отделни елементи, върху които могат да се прилагат специални селекции.

Както бе споменато по-горе, механизмът RIB се постига чрез използването на планове за обмен. но за да може конкретен план да се използва в тази йерархична структура, неговото свойство „Разпределена информационна база“ трябва да бъде активирано.

Всички данни се предават към RIB чрез съобщения. Съдържанието на тези съобщения е ясно регламентирано и не може да бъде произволно, както при универсалния механизъм за обмен. Данните се поставят в съобщение, като се използва принципът на XML сериализация. В допълнение към тези промени в данните, съобщението съдържа и информация за промени в конфигурацията, както и определено количество сервизна информация. Промените се регистрират и поставят в съобщението за обмен напълно автоматично. Нито потребителят, нито разработчикът могат да повлияят на това.

Приемането и генерирането на обменни съобщения в RIB се настройват с една команда

Планове за обмен. WriteChanges(WriteMessages, 0)

Съдържанието се чете с помощта на командата

Заключение

Можем спокойно да кажем, че механизмът RIB се състои главно от универсален механизъм за обмен с някои отличителни характеристики, които присъстват само в структурата на RIB.