1с 8 риб та додані об'єкти. Олексій Олексєєв ласкаво просимо в мою затишненьку блузку

Це моя перша у житті стаття, конструктивна критика вітається.

Цільова аудиторія - ті, хто вперше стикається з РБД.

Завдання РБД

Перше з чого необхідно почати – це відповісти на запитання: «Навіщо нам потрібна РБД?». Варіантів відповідей багато, зокрема:

У нас є філії, які працюють у нескладних БД. Тепер ми хочемо, щоб інформація між ними синхронізувалась;
У нас є філії, проте навантаження на базу занадто велика (маються на увазі блокування транзакцій, не обсяг БД) та онлайн актуальність (не плутати з актуальністю в кілька хвилин, онлайн - це коли після виконання кожної транзакції дані передаються в другий вузол) даних для філій не потрібно;
У нас є філії, в яких відбувається лише введення даних (наприклад, роздрібні магазини), тому можна суттєво знизити навантаження на центральну БД;
З міркувань безпеки ми хочемо, щоб у філіях навіть теоретично (з адмін. паролем) не було доступу до важливих даних, наприклад, балансу підприємства.

В одному випадку для мене були актуальні питання 2 і 4, в іншому 2 і 3. Перший пункт занадто великий і в рамках тематики цієї статті не розглядатиметься.

Також краще відразу розглянути проблематику транспортування файлів обміну, тому що в деяких випадках вона може накласти суттєві обмеження на реалізацію обміну даних. Спочатку необхідно визначити, у яких філіях точно з'являться вузли РБД (зазвичай це регіональні філії). Далі розглядаємо, де ще хочемо встановити вузли РБД, і чи потрібна в них онлайн актуальність. Наприклад, для роздрібних магазинів далеко не завжди є можливість встановлення навіть модему, а встановлення бездротового зв'язку буде надто дорогим. Тут необхідно ухвалити рішення - можливо, цей магазин може працювати в офлайні і періодично обмінюватися з центром (раз на день/раз на тиждень) за допомогою фізичного носія, наприклад флешки.

У деяких випадках обмін засобами фізичного носія неможливий, наприклад, це дуже віддалена філія, де є суттєві проблеми з налагодженням високошвидкісного зв'язку. Тут варто приблизно підрахувати обсяг інформації під час обміну. Нерідко при актуальності щогодини або кілька разів на добу досить 32к модему. Однак варто пам'ятати, що разом з оновленнями даних доведеться іноді надсилати оновлення самої конфігурації або зовнішніх файлів (друковані форми, фотографії товарів), тому періодично виникатиме ситуація, коли файл обміну суттєво збільшиться через такі оновлення.

Топологія

Отже, ми отримали такі питання, на які необхідно відповісти:

У яких підрозділах ми гарантовано встановлюватимемо вузли РБД і чи є можливість встановити високошвидкісний канал;
У яких підрозділах установка вузла РБД непотрібен;
Які підрозділи можуть працювати з актуальністю кілька годин;
Які підрозділи можуть працювати в офлайн режимі (обмін даними менше 3-4 разів на день).

Відповівши ці запитання, ми отримуємо приблизну схему нашої РБД. Для великих компаній зазвичай виходить щось таке:

Рис 1. Типова схема РБД великої компанії

Якщо з вузлами "Філія" все відносно ясно - це великі центри, що вимагають автоматизації, то під вузлами "Магазин" мається на увазі вузол з серйозним навантаженням на БД при введенні даних, який для зниження навантаження слід відокремити. Наприклад, магазин із 50-ма касами та щоденним товарообігом більше 10000 одиниць.

Магазини - введення даних про власний товарообіг та рух грошових коштів. Аналітика поверхова, тільки за своїм магазином.
Філії - введення даних неавтоматизованих точок, бухгалтерія, зарплата та кадри, виробництво тощо. Аналітика у межах власної філії.
Центр – введення даних неавтоматизованих філій. Аналітика підприємства загалом.

Важливо розуміти, з якою метою буде використовуватися БД у кожному вузлі. Від цілей вибудовуються завдання, необхідні для реалізації, наприклад:

Філії бачать історію взаєморозрахунків із контрагентами один одного;
Магазини бачать залишки товарів у всьому (чи частини) підприємства;
Аналітика доходів/витрат, виконання бюджету тощо видно тільки в рамках ієрархії власного підрозділу;
Бухгалтерія, зарплата та кадри видно лише в рамках ієрархії власного підрозділу;
Номенклатура, всі її властивості та характеристики видно у всіх вузлах РБД;
Щодо ієрархії підрозділів всі дані потрапляють нагору, але фільтруються вниз;
До центру потрапляє абсолютно вся інформація про компанію.

Ставлячи перед собою подібні питання, можна відповісти на найскладніше питання - яка інформація, де і як повинна курсувати між вузлами РБД? Чому найскладніший? Знаючи, які набори даних курсують між вузлами, можна однозначно зрозуміти, як нарізати поточну БД, щоб дані залишалися логічно цілісними. Наприклад, не можна дані про залишки товарів відривати від даних про поточні резерви.

Тепер, залежно від потоків інформації, перемалюємо схему РБД:

Що бачимо малюнку 2? Відповідно до ієрархії підрозділів компанії вишикувалася топологія потоку інформації між вузлами БД. Також додався вузол "Центр 2", чому? При реалізації топології «Зірка» навантаження на центр завжди вище, ніж навантаження на периферійні вузли, при цьому часто навантаження, яке генерується самим вузлом, і таке високе. Приклади використання вузлів «Центр 1» та «Центр 2»:

«Центр 1» служить лише консолідації даних інших вузлів РБД. Доступ до нього має лише адміністратор. "Центр 2" служить для роботи головного офісу;
Центр 1 служить для роботи головного офісу. Проте важкі аналітичні, тестові, створюють величезне навантаження БД, операції виконуються у вузлі «Центр 2»; наприклад відновлення послідовності, переведення закритих періодів, формування зведених звітів по всьому підприємству за тривалий проміжок часу, формування аналітики, що призводить до зміни даних;
Центр 1 служить для роботи головного офісу. «Центр 2» є резервним, у разі непередбачених ситуацій для швидкого відновлення всієї РБД.

Реалізація обміну

Існують 2 варіанти роботи РБД:

Автоматичний – відбувається без участі користувача. Контроль за позаштатними ситуаціями, покладено або на адміністратора БД, або на просунутого користувача;
Ручний - обмін відбувається лише за бажанням користувача.

За своїм досвідом приводив усі реалізації завжди до автоматичного варіанту. Якщо були проблеми з транспортом файлів обміну (наявність мережі у вузлі який завжди), максимум, що дозволяв користувачеві - це натиснути кнопку «Зробити обмін зараз». Ситуації, коли крім оновлення даних йде оновлення конфігурації, бажано приводити теж до повністю автоматичних (наприклад, використовуючи стороннє ПЗ).

Формування пакетів оновлень

Так як є однозначне рішення про те, на які вузли РБД покладені якісь функції, то можна сформувати тільки той пакет даних, який потрібен цьому вузлу. З одного боку, необхідно вказати, які типи об'єктів будуть синхронізуватися між вузлами. Наприклад, регістри бухгалтерії для вузла «Магазин 1» нічого не винні взагалі синхронізуватися, т.к. дані вводяться лише на рівні вузла філії. З іншого боку, ті типи даних, які підлягають обміну, необхідно фільтрувати з прив'язкою до підрозділу. Наприклад, дані про надходження грошей вузла «Магазин 1 філії 2» можуть бути лише у вузлах «Філія 2», «Центр 1» і «Центр 2».

Однак є і обернена проблема, якщо занадто сильно фільтрувати дані обміну, пакет даних втратить логічну цілісність. Наприклад, залишки товарів враховуються в розрізі складів, а резерви враховуються в розрізі фірми в цілому, тоді якщо фільтрувати залишки товарів за складами та не фільтрувати резерви, то дані будуть некоректними.

Також слід вирішити, якому етапі свого життя об'єкт підлягає обміну. Наприклад, обміну підлягають лише проведені видаткові накладні, але не просто збережені. Або Витратні накладні магазинів ніколи не вивантажуються з вузла «Центр», навіть після їх коригування, проте потрібно враховувати зворотний ефект – дані можуть бути розсинхронізовані, або якісь зміни можуть бути затерті.

Важливо розуміти – під час обміну між вузлами, якийсь із них є пріоритетним. Розглянемо ситуацію:

У вузлі "Магазин 1" створили документ;
Під час обміну він потрапив у вузол «Філія 1»;
Документ коригується одночасно в обох вузлах.

Який із документів вважатиметься істинним? У 1С 8.х під час використання механізму «Плани обміну» за умовчанням пріоритетним є головний вузол, тобто. у цьому випадку зміни, зроблені у вузлі «Магазин 1», будуть втрачені та замінені на дані з вузла «Філія 1».

Є інша, складніша ситуація, коли коригують одночасно два зв'язкові об'єкти. Наприклад, видаткова накладна та ПКО по ній коригуються в різних вузлах, тут існує ймовірність втрати цілісності, якщо змінять ціни, суму оплати, контрагентів тощо.

Також важливо контролювати видалення об'єктів, інакше це може призвести до того, що, наприклад, видаткової накладної вже існувати не буде, а рухи з бухгалтерського обліку залишаться.

Механізми обміну в 1С 8.х

Існують два підходи для реалізації:

Механізм "Плани обміну";
Власна реалізація реєстрації об'єктів.

Розглянемо обидва варіанти.

Механізм планів обміну дозволяє, без будь-якої настройки, за кілька хвилин створити РБД з повним обміном даними. Якщо встановити прапорець «Розподілена інформаційна база», під час створення пакета оновлень буде вивантажено й оновлення конфігурації. За кілька хвилин можна налаштувати правила дозволу/заборони обміну різними типами даних, відкривши склад плану обміну. Якщо встановити прапорець «Автореєстрація» у положення «Заборонити», то цей тип об'єкта, без додаткових зусиль, ніколи не обмінюватися.

Навіщо потрібна реєстрація, чому не вивантажувати все й одразу? У будь-якому випадку файл, що містить тільки зміни стану БД, буде меншим за повний знімок самої БД. Тому варіант повного розвантаження не розглядатиметься.

Як настроїти фільтрацію даних щодо приналежності до підрозділу? Тут уже доведеться програмувати. У моїй реалізації на запис будь-якого об'єкта була встановлена підписка на подію «Під час запису», де, за допомогою властивості «ОбмінДаними.Одержувачі», можна встановити список одержувачів даного об'єкта. Тобто. при вивантаженні стандартними засобами для вузла, якого немає у списку, об'єкт не буде вивантажений. Є й інше рішення - вибирати чи вивантажувати об'єкт можна безпосередньо при вивантаженні об'єкта, в процедурах «ПідсиланняДанихПідпорядкованому» і «ПріНадсиланняДанихГоловному» модуля плану обміну.

Обидва варіанти мають право на існування. Однак як кращий варіант вибрав перший, тому що обчислення ознаки вивантаження відбувається відразу ж при записі об'єкта, що збільшує тривалість запису об'єкта на 3-5% (можна оптимізувати, в деяких випадках можна довести до 0.01%) тобто. в середньому 0.1-0.3 секунди, а у разі розрахунку вивантажуваності об'єкта безпосередньо при відправленні даних, що і так створює суттєве навантаження на БД, цей час становитиме до декількох хвилин.

Для повного розуміння роботи механізму "Плани обміну" рекомендую прочитати розділ 15 книги "Професійна розробка в система 1С:Підприємство 8", Габець О.П., Гончаров Д.І.

Будь-яка власна реалізація, на мій погляд, або повторить механізм «Плани обміну», або вивантажуватиме об'єкт відразу при зміні, або вивантажуватиме більше, ніж механізм «Плани обміну» (наприклад, вивантажити всі зміни за сьогоднішній день). Це питання не розглядаю через брак досвіду реалізації.

Транспорт

Завдання транспортування файлів від головного до підпорядкованого вузла зводиться до максимальної стійкості до відмови. Нерідко файли шифруються або передаються захищеним каналом. Для передачі файлів бажано використовувати кілька різних служб або підготувати кілька різних варіантів підключення. Наприклад, основний спосіб передачі – це використовуючи FTP-сервер, підключений через VPN-тунель; резервний - це e-mail сервер із TLS-підключенням. Навіщо потрібний резервний канал з іншою службою? Як показує практика, використовувати два різних FTP сервери менш надійно, ніж FTP сервер і E-Mail .

Рекомендую службу створення пакета оновлення відокремлювати від служби транспорту, це підвищить стійкість до відмови всього комплексу обміну даними. Якщо служба, яка займається транспортом файлів, не відпрацює, то служба створення пакетів оновлень продовжить нормально працювати і за деяких умов перезапускатиме службу транспорту і навпаки.

Моя реалізація РБД

Реалізація повністю автономна, тому як підзавдання виступала максимальна стійкість до відмови. Звідси вийшло 2 служби – служба транспорту оновлень та служба імпорту/експорту даних. Обидві служби працюють незалежно одна від одної.

Після кожного успішного циклу імпорту-експорту даних зберігався час останнього обміну із цим вузлом. Якщо обміну не відбувалося дуже довго, то транспортна служба починала вивантажувати файли у всі доступні їй канали зв'язку з розрахунку на те, що другий вузол таки отримає оновлення і вивантажить свої файли. У разі виняткових ситуацій система сама надсилає повідомлення адміністратору з докладним описом помилки.

Для скорочення обсягу трафіку xml-файли упаковувалися в zip-архіви. Система підтримує два види транспорту - FTP та E-mail.

Як налаштування для фільтра даних існують дві таблиці. В одній (таблична частина планів обміну) зберігаються умови щодо загальних реквізитів (для кожного об'єкта система намагається знайти цей реквізит), в іншій налаштування під конкретний об'єкт метаданих. При записі будь-якого об'єкта спочатку відбувається пошук умов за загальним реквізитами (наприклад, Підрозділ), після чого система намагається визначити, чи є персональне правило цей тип об'єкта за всіма його реквізитами. Не рекомендую фільтрувати списки - велика можливість помилитися, наприклад, з табличної частини витратної накладної зникнуть кілька рядків, а залишки при цьому рухатимуться все і навпаки.

Важливо розуміти, під яким системним користувачем працюватимуть служби, т.к. може вистачити прав створення файлів навіть у тимчасової папці 1С. Для налагодження рекомендую писати кожну, успішно виконану, операцію в журнал реєстрацій, або в txt -файл. У 1С 8.1 виконання серверного коду налагодити не можна.

Для зручності налагодження та налаштування своєї реалізації прикладаю обробку "Реєстрація змін", опис якої знаходиться у самій обробці.

Загальна схема роботи комплексу обміну даними вказано на рис.

Фільтрування даних відбувається у передплаті на подію «ПередЗаписом» кожного об'єкта. Не слід забувати, що при створенні початкового образу вузла дані теж потрібно відфільтрувати. Процедура створення початкового образу досить тривала, тому рекомендую оптимізувати максимум її код (наприклад, кешувати налаштування фільтрації).

Післямова

Головне завдання – це відповісти на список питань:

Для чого нам потрібна РБД?
Чим не влаштовує робота через RDP-клієнт?
Де і чому хочемо встановити вузли РБД?
Як відбуватиметься транспорт оновлень?
Який рівень відмовостійкості буде реалізовано?

Обробка "Реєстрація Змін"

Обробка дає змогу примусово реєструвати зміни в об'єктах. Є кілька варіантів реєстрації змін:

Якщо встановлена галочка на якомусь метаданому і НЕ обраний жодний об'єкт і НЕ встановлено прапор "Вивантажувати за всіма значеннями", то РЕЄСТРУЄТЬСЯ ТІЛЬКИ ВИБРАНА ТАБЛИЦЯ;
Якщо встановлено прапорець "Вивантажувати за всіма значеннями", то вибрані метадані будуть вивантажені по всіх об'єктах у циклі;
Якщо перемикач встановлений у режим "Вивантажувати лише вибрані об'єкти", то будуть вивантажені виключно вибрані об'єкти (наприклад: встановлення прапора на метаданому без вибору об'єктів рівносильне увімкненому прапору "Вивантажувати за всіма значеннями" та перемикачеві в позиції "Вивантажувати тільки вибрані об'єкти";
Якщо перемикач встановлений в режим "Вивантажувати вибрані та безпосередньо пов'язані об'єкти" то вивантажуватимуться вибрані об'єкти і ті об'єкти, існування яких залежить від існування обраного об'єкта (наприклад: у довідників - підпорядковані довідники);
Якщо перемикач встановлений у режим "Вивантажувати за всіма посиланнями", то будуть вивантажені ВСІ об'єкти в яких є посилання на вибраний об'єкт.

З додаткового функціоналу є:

Перереєстрація зареєстрованих об'єктів часто потрібна для налагодження;
Видалення зареєстрованих часто потрібно для налагодження;
Друк змін - друк повного переліку об'єктів, які позначені як змінені;
Друк дерева конфігурації – лише для зручності перегляду всієї конфігурації.

Розподілена Інформаційна База (РІБ) — застосовується коли необхідно мати доступ до розподілених даних кампанії або підприємства з метою використання та обміну інформації, що міститься в них.

Прикладом є конфігурація Управління Торгівлею 11 (11.0.6.9) - платформа 1С 8.2.

Для того щоб створити розподільчу інформаційну базу, Вам необхідно виконати нижченаписані операції.

Перше, що ми робимо, це запускаємо 1С:Підприємство, потім переходимо на вкладку "Адміністрування" і в кінцевому підсумку вибираємо пункт "Налаштування параметрів обліку".
Після цього відкриється вікно і вже в ньому вибираємо пункт Обмін даними. Натискаємо на дозвол використання обміну даними, і після цього натискаємо кнопку "Записати і закрити".
Після того як увімкнемо обміни даними, у лівій частині вікна має з'явитися новий пункт "Обмін даними". Клацаємо по пункту "Обмін даними".
Коли відкриється вікно, натискаємо кнопку "Створити". Вибираємо пункт "Створити обмін у розподіленій інформаційній базі". Після цього відкриється вікно майстра зі створення розподільно-інформаційної бази.
Шукаємо у вікні кнопку "Далі" і натискаємо на неї, після цього переходимо до іншого вікна. У статті, що розглядається, зображено обмін даними через локальний або мережевий каталог.
Знаходимо каталог обміну, ставимо галочку навпроти пункту "Стискати файл вихідного повідомлення". Потім натискаємо на "Далі" і пропускаємо два наступні вікна (робимо це тому, що в цій статті не будемо розглядати обмін через FTP та пошту).
Тиснемо "Далі".
Називаємо, як Вам зручне ім'я для плану обміну даними, я вибрала, наприклад, "Обмін_С_Періферійною_Базою", Ви можете встановити своє ім'я. Потім перевіряємо що "Основний спосіб обміну даними" був "Обмін через локальний або мережевий каталог" і натискаємо "Далі".
Після того як перевіримо вміст поточного вікна та натискаємо "Далі".
У цьому вікні також нічого не змінюємо та натискаємо кнопку "Готово".
Вказуємо шлях до папки для створення розподільно-інформаційної бази. Вказувати потрібно у форматі UNC, наприклад "\rib\1Cv8.1CD". Якщо все правильно, то в зазначеній папці буде створено файл розподіленої бази даних.
Тепер налаштовуємо автообмін та його розклад. Для цього переходимо на вкладку "Адміністрування" та вибираємо пункт "Обмін даними" і робимо подвійний клік за існуючим рядком у списку обмінів даними:
У вікні клацаємо по "Сценарії обмінів даними":
У вікні натискаємо на кнопку "Додати":
У вікні клацаємо по рядку "Кожен день, кожні 900 сек.":
У вікні встановлюємо потрібні параметри:
Встановлюємо такі параметри, щоб обмін виконувався щодня з 00:00:00 до 23:59:59 з перервою в 30 секунд. Це робиться для того, щоб показати, що обмін виконується в відеоролику, ви можете встановити в себе інші значення параметрів. У попередньому вікні натискаємо на кнопку "OK" та "Записати та закрити".
Завершено налаштування обміну даними для центрального вузла, аналогічно виконується налаштування периферійного вузла. Необхідно змінити ярлик запуску 1С, додавши параметр запуску "/CDoScheduledJobs" для того, щоб обмін виконувався в автоматичному режимі.

Налаштування автоматичного обміну на периферійному вузлі нічим не відрізняється від налаштування головного вузла. Якщо налаштовувати сценарій обміну, обмін буде запускатися автоматично при вході користувача з правами адміністратора.

Конфігурація у розподілі оновлюється так: вручну, спочатку зміни робляться в ЦП, потім робимо вивантаження і несемо у периферійку. Автоматом, як правило, не спрацьовує обмін.

Технологія розподілених інформаційних баз (РІБ) дозволяє створити територіально-розподілену систему на базі конфігурацій 1С Підприємство. Це дозволяє мати загальний інформаційний простір навіть із тими підрозділами, які мають надійного каналу зв'язку, поєднуючи високу автономність вузлів з можливістю оперативного обміну інформацією. У наших статтях ми розглянемо особливості та практичну реалізацію цього механізму на платформі 8.2

Насамперед поставимо запитання: чому саме автообмін? Сучасні технології, у поєднанні з недорогим і швидким інтернетом, дозволяють організувати віддалену роботу без будь-яких труднощів. Вибір методів як ніколи широкий: RDP, тонкий і веб-клієнти, об'єднання мереж за допомогою VPN - є над чим задуматися. Однак усі ці способи мають один істотний недолік – сильна залежність від якості каналу зв'язку.

Навіть за ідеальної роботи місцевого провайдера гарантувати 100% доступність каналу зв'язку неможливо. Проблеми у магістрального провайдера, відсутність електропостачання, фізичне пошкодження лінії зв'язку та багато інших факторів роблять це завдання нерозв'язним. У той же час недоступність інформаційної бази на віддаленому складі або роздрібному магазині призводить до відчутних збитків. Ну і нарешті не забуватимемо, що є місця (наприклад промзони на околиці міст) в які підвести якісний канал зв'язку дорого та/або проблематично.

Механізм РІБ дозволяє позбутися зазначених недоліків, кожен підрозділ має власний екземпляр інформаційної бази з якою можна працювати автономно навіть за повної відсутності зв'язку із зовнішнім світом. А невеликий обсяг інформації, що передається, дозволяє використовувати для обміну будь-який канал зв'язку, в тому числі мобільний інтернет.

РИБ на платформі 8.2 не є чимось принципово новим, являючи собою подальший розвиток УРІБ платформи 7.7, тільки тепер ця технологія стала доступнішою та простішою. На відміну від компоненти УРІБ, яку потрібно було придбати окремо, РІБ є невід'ємною частиною багатьох типових конфігурацій і працює повністю в режимі користувача, дозволяючи обійтися без Конфігуратора навіть на етапі налаштування.

На цьому місці час би було перейти до практичної частини, але доведеться зробити ще один відступ. Справа в тому, що перехід на платформу 8.2, який начебто вже відбувся, за фактом призвів до появи двох типів конфігурацій: на основі керованого додатка, "рідні" для платформи 8.2, та адаптовані з 8.1, продовжуючи використовувати застарілі технології та механізми. Так як істотна частина конфігурацій (Бухгалтерія підприємства, Зарплата та управління персоналом) є адаптованими або перехідними, то скидати їх з рахунків не можна, тому перша частина нашої статті буде присвячена цим конфігураціям (по суті платформі 8.1), тоді як у другій ми розберемо налаштування автообміну для конфігурацій на основі керованої програми (платформа 8.2).

Розглянемо практичне завдання: налаштувати автообмін через FTP конфігурації Бухгалтерія підприємства 2.0. Незважаючи на те, що РІБ дозволяє здійснювати обмін з використанням електронної пошти або загальних файлових ресурсів, ми рекомендуємо використовувати саме FTP як найпростіший і найнадійніший спосіб зв'язку. Як налаштувати власний FTP-сервер, ви можете прочитати в , або можна використовувати FTP сервіс будь-якого хостинг провайдера.

Насамперед нам потрібно налаштувати вузли обміну. Для цього запустимо конфігурацію з правами адміністратора та виберемо Операції – Плани обміну.

У списку виберемо Повнийплан або По організації, якщо у основі ведеться облік за кількома фірмам і обмін необхідно проводити лише з однієї з них. У вікні вже існує один вузол - центральний, нам потрібно його відредагувати, вказавши код і назву.

Після цього створимо ще один вузол для філії, заповнивши його аналогічним чином (для додавання натисніть зелений кружок із плюсом). Наступним кроком буде створення початкового образу для даного вузла, який є готовою інформаційною базою у файловому режимі. Для цього клацніть правою кнопкою миші на потрібному вузлі і в списку виберіть Створити початковий образ.

Тепер перейдемо Сервіс - Розподілена інформаційна база (РІБ) - Налаштувати вузли РІБ.

У вікні, натисніть кнопку Додатиі настройте новий обмін, вказавши віддалений вузол, тип обміну (через FTP) та параметри підключення до сервера.

Закладка Автоматичний обміндозволяє налаштувати розклад обмінів, обмін за подіями (початок і завершення роботи тощо), дані налаштування виконуються для користувача від імені якого буде здійснюватися обмін, тому переконайтеся в наявності у нього прав для обміну даними.

Не забудьте вказати префікс вузла для нумерації документів (інакше ви отримаєте різні документи з однаковими номерами) у Сервіс - Налаштування програми, тут можна налаштувати й деякі інші параметри обміну. На цій же закладці слід вибрати користувача для виконання завдань обміну, якщо ви не зробите розклад працювати не буде. Пам'ятайте, що обмін буде здійснюватись лише в тому випадку, якщо цей користувач виконав вхід до програми.

На цьому налаштування центрального вузла закінчено, тепер потрібно зробити аналогічні налаштування для периферійного вузла, підключивши початковий образ як ІБ. Після цього можна приступати до обміну даними. Для контролю слід скористатися Монітором обміну даними, він дозволяє як контролювати успішність проходження вивантаження/завантаження, а й показує виниклі колізії чи відкладені руху (якщо користувачу виробляв обмін не вистачає прав на здійснення будь-яких дій у базі). Наявність даного інструменту дозволяє швидко і ефективно вирішувати різноманітні проблеми, що виникають при автообміні.

На цьому налаштування обміну можна вважати закінченим і розпочинати роботу в розподіленому режимі. Окремо варто зупинитись на оновленні або внесенні змін до конфігурації. Ці дії доступні лише на центральному вузлі, всі внесені зміни будуть автоматично поширені на периферійні вузли під час наступного обміну. Для автоматичного внесення змін потрібно, щоб периферійна база знаходилася в монопольному режимі, інакше потрібно буде запустити Конфігураторта виконати Оновлення конфігурації бази данихвручну.

У 1с 8.3 чи 1С 8.2? Налагодження розподіленої інформаційної бази. Покрокова інструкція.

Розподіл інформаційної бази застосовується за необхідності ведення спільного обліку у базах даних, які можуть, з різних причин, мати фізичного з'єднання. Прикладом може бути ведення обліку в одній фірмі, що має підрозділ у великому місті і маленькому селищі без можливості підключення інтернету. Або в деяких окремих випадках періодичної необхідності одночасної роботи з однією базою даних в офісі та поза офісом, наприклад вдома. У таких і подібних випадках застосування розподіленої інформаційної бази (РІБ) виправдане і необхідне.

У цій статті ми розглянемо організацію розподілу однієї інформаційної БД у конфігурації 1С Бухгалтерія для Росії версії 8.3 через локальний чи мережевий каталог. У версії 8.2 1С ця інструкція також буде корисною, т.к. визначає по суті один процес із суттєво малими відмінностями.

==== Налаштування для головної бази ====

Відкривши 1С 8.3 у режимі «Підприємство» перейдемо до розділу «Адміністрування». У версії 1С 8.2 для початку роботи потрібно перейти в головному меню "Сервіс" - "Розподілена інформаційна база (РІБ)" - "Налаштувати вузли РИБ".

Далі розглядатимемо процес у контексті ІБ версії 8.3. Отже, перейшовши до розділу «Адміністрування», виберемо «Налаштування програми». У налаштуваннях зайдемо до розділу «Синхронізація даних». Тут ставимо галочку «Використовувати синхронізацію даних» та вказуємо префікс бази даних. Вкажемо «ЦБ», що має на увазі центральну базу.

Після цього у правому меню з'являється пункт "Синхронізація даних". Виберемо його. У дочірньому вікні, що відкрилося, натискаємо кнопку «Налаштувати синхронізацію даних». У меню, що випадає, можна вибрати варіанти налаштувань під різні випадки використання синхронізації. Ми обираємо «Розподілена інформаційна база…».

Для загального розвитку знайомимося з вмістом наступного вікна і натискаємо «Далі».

У наступному вікні заповнюємо каталог, через який проходитиме . Вкажемо стиснення даних для скорочення розмірів вивантаження і тут же можна вказувати пароль на архів даних. Важливо його не забути. Підтверджуємо заповнення кнопкою "Далі".

Наступні два вікна призначені для вказівки параметрів для випадків обміну через сервер FTP та через електронну пошту. Як зазначалося раніше, ми розглядаємо спосіб обміну через каталог, тому налаштування для FTP та email пропускаємо.

Наступне вікно призначене для визначення параметрів обміну в частині периферійної бази даних. Вкажемо її назву та префікс. Далі – кнопка «Далі».

Перевіримо сформовані нами параметри обміну та підтвердимо їхню правильність традиційною кнопкою «Далі».

Автоматично буде створено необхідний набір для обміну. Це займе деякий час.

Важливо! Створення початкового образу підлеглого вузла займає значний час. Розмір цієї значущості залежить від ресурсів комп'ютера та обсягів обліку у головній базі даних.

Припустимо, що ми вирішили створити образ. Після натискання на кнопку «Готово» у попередньому вікні, введемо налаштування для створення образу підлеглої ІБ. Ми розглянемо найпростіший випадок для локальних операцій. Для цього вкажемо потрібні реквізити у вікні. Особливо звернемо увагу на параметр "Повне ім'я файлової бази". Його необхідно вказувати у повному форматі UNC, який передбачає формування та локального шляху у «мережевому» форматі. Наприклад - "\\Server1C\Databases\RIB". До зазначеного шляху додамо найменування файлу БД - 1Cv8.1CD.

Після натискання кнопки «Створити початковий образ» стартує процес генерації образу для підлеглої бази.

Після закінчення процесу у вказаному каталозі буде створено файл БД. Цю новостворену базу перед повноцінним використанням потрібно налаштувати.

==== Налаштування для периферійної бази ====

Для цього її потрібно підключити до 1С. Як це зробити ви знайдете в інструкції в нашій статті — Після підключення нову базу потрібно запустити в режимі конфігуратора та створити користувачів. Далі ІБ потрібно запустити як 1С «Підприємство».

Якщо, з якоїсь причини, створення користувачів потрібно перенести на пізніший час, можна після підключення просто запускати базу в режимі 1С «Підприємство». Буде запропоновано створення користувача «Адміністратор», погодьтеся з ним і буде виконано початкове заповнення.

Потім потрібно продовжити налаштування пари з головною базою. Ця настройка подібна до розглянутої вище для головної бази.

Буде створено налаштування для зв'язку з головною базою.

============================================

Отже, тепер у нас створено головну та периферійну бази. Також створено налаштування синхронізації в кожній із цих баз даних. Тепер можна перейти до редагування цих налаштувань та приведення їх у відповідний вигляд. Можна створити правила автоматичного обміну або обмінюватись вручну.

Зробимо це у головній базі даних. Периферійна база налаштовується аналогічно.

Редагування можна застосувати до правил та розкладу синхронізації даних.

За кнопкою «Налаштувати» у розділі «Розклад синхронізації даних», потрібно відредагувати сценарії для автоматичного розпорядку роботи з розвантаження/завантаження даних для вибраної бази. Можна і не редагувати, просто погодившись із запропонованими за умовчанням варіантами.

Для редагування параметрів достатньо натиснути на посилання з даними автоматичного розкладу. І далі редагуємо часові параметри запуску завдань. Переходячи по закладках можна змінювати час, так і дати і дні тижня запуску.

За допомогою кнопки «Виконати завдання» головного вікна сценаріїв можна виконати ручний запуск завдання.

За допомогою кнопки «Налаштувати» розділу «Правила синхронізації даних» можна виконувати операції зі зміни сценаріїв запуску завдань, а також переглядати журнал виконання вивантажень/завантажень. Останнє досить важливе для адміністрування доступів та відстеження регулярності обмінів.

Закінчивши створення та редагування сценаріїв автоматичного запуску обміну розподіленої бази даних, можна перейти до вивантаження та подальшого завантаження даних.

На цьому в основному налаштування розподіленої бази банних для центрального та периферійного вузла закінчено.

Завантажити ілюстровану інструкцію

Розподілена інформаційна база. Покрокова інструкція
Розподілена Інформаційна База (РІБ) 1С:Підприємство
Створення розподіленої інформаційної бази та її налаштування
як налаштувати риб в 1с 8.2
Як налаштувати розподілену інформаційну базу в 1С
Як налаштувати в 1С
Як налаштувати в 1С
Налаштування розподіленої інформаційної бази (РІБ) у 1С
Приклад налаштування РІБ для 1С:Бухгалтерії 8
Створення розподіленої інформаційної бази та налаштування

Інструкція зі створення та налаштування розподілених баз за допомогою компонентів УРБД (УРІБ)

Компонента УРБД (Управління розподіленими базами даних) застосовується обмінюватись інформацією між двома ідентичними базами 1С. Якщо різні конфігурації, то застосовувати її також можна, про це написано в іншій . Для роботи компоненти потрібна наявність файлу DistrDB.dll у папці BIN програми 1С: Підприємство.

Розглянемо дії щодо створення розподілених баз даних. Наприклад, ми маємо робочу базу в каталозі D:\base1. Потрібно зробити її центральною та створити периферійну базу.

1. Створюємо каталог D:\base2 для периферійної бази.

2. У каталогах D:\base1 та D:\base2 створюємо папки CP та PC (використовуємо латинські літери).

3. Запускаємо конфігуратор центральної бази (D: \ base1) і вибираємо Меню - Адміністрація - Розподілена ІБ - Управління.

4. Натискаємо кнопку "Центральна ІБ", у вікні вводимо код і найменування бази. Для коду краще використовувати цифри чи латинські літери. Вводимо, наприклад, 001 та "Центральна база", підтверджуємо натисканням кнопки "ОК".

5. Натискаємо кнопку "Нова периф. ІБ" для створення периферійної бази. Вводимо для неї параметри: 002 та "Периферійна база 1".

6. Курсором виділяємо базу "Периферійна база 1" та натискаємо кнопку «Настр. автообміну». У налаштуваннях змінюємо ручний режим на автоматичний. Будьте уважні, це важливо.

7. Курсором виділяємо базу "Периферійна база 1" та натискаємо кнопку "Вивантажити дані", потім кнопку "ОК". В результаті вивантаження з'явиться файл D:\base1\CP\020.zip.

8. Запускаємо 1С у режимі конфігуратора, додаємо у вікні запуску 1С нову базу "Периферійна база 1", вказуємо для неї раніше створений каталог D:\base2.

9. Вибираємо Меню - Адміністрація - Розподілена ІБ - Управління. На запитання «Інформаційну базу не виявлено. Завантаження даних?» натискаємо кнопку "Так" і вказуємо ім'я файлу "D:\base1\CP\020.zip", натискаємо кнопку "ОК". Після закінчення завантаження процес створення периферійної бази вважатимуться закінченим.

В і ще наведені методи створення периферійної бази шляхом відновлення з бекапу копії центральної бази або приточення файлів копії центральної бази для формату SQL і виконання скрипта. Це буде корисно при великих обсягах даних, коли розвантаження-завантаження розтягуються на годинник або взагалі нереальні.

Інструкція з обміну між розподіленими базами за допомогою компонентів УРБД (УРІБ)

Розглянемо спрощений приклад, виконуватиме обмін вручну, запускаючи конфігуратор. Можна використовувати пакетний режим конфігуратора, для доставки пакетів обміну можна використовувати пошту, FTP, автоматичне копіювання файлів.

Для виконання обміну необхідно вибирати Меню – Адміністрація – Розподілена ІБ – Автообмін. Якщо обмін автоматичний (див. пункт 6 попередньої інструкції), то все в нас вийде.

1. Отже, змінюємо чи створюємо якісь об'єкти, які мігрують у периферійну базу. Правила міграції об'єктів задаються на вкладці "Міграція" у властивостях об'єкта (див. дерево об'єктів у конфігураторі).

2. Запускаємо конфігуратор центральної бази, вибираємо Меню - Адміністрація - Розподілена ІБ - Автообмін, натискаємо кнопку "Виконати".

3. Отриманий файл D:\base1\CP\020.zip переміщуємо до папки D:\base2\CP\

4. Змінюємо якісь об'єкти периферійної бази даних. Бажано не ті, які змінювалися раніше у центральній основі, т.к. центральна база має пріоритет змін об'єктів під час обміну.

5. Запускаємо конфігуратор периферійної бази, вибираємо Меню - Адміністрація - Розподілена ІБ - Автообмін, натискаємо кнопку "Виконати".

6. В результаті автообміну у нас мають з'явитися зміни, що надійшли із центральної бази даних. Також у нас повинен з'явитися файл для передачі в центральну базу D:base2PC021.zip

7. Копіюємо файл D:\base2\PC\021.zip в папку D:\base1\PC

8. Повторюємо пункт 2. В результаті в центральній базі з'являться зміни, що надійшли з периферійної бази.

Отже, загальний принцип обміну: поперемінне виконання автообміну з одночасним переміщенням файлів (пакетів обміну) з папки PC однієї бази до папки PC іншої бази та з папки CP однієї бази до папки CP іншої бази.

Зміна конфігурації провадиться тільки в центральній базі. У разі зміни конфігурації необхідно проведення обміну в периферійних базах у монопольному режимі. Для успішної обробки пакетів із периферійних баз у центральній базі конфігурація має бути завантажена у периферійні бази. Якщо ви заплуталися - нічого страшного, знехтуваний центральною базою пакет вивантажиться повторно.