Це моя перша в житті стаття, конструктивна критика вітається.
Цільова аудиторія - ті, хто перший раз стикається з РБД.
завдання РБД
Перше з чого необхідно почати - це відповісти на питання «Навіщо нам потрібна РБД?». Варіантів відповідей багато, зокрема:
- У нас є філії, що працюють в незв'язаних БД. Тепер ми хочемо, щоб інформація між ними синхронізувалася;
- У нас є філії, однак навантаження на базу занадто велика (маються на увазі блокіровкітранзакцій, не обсяг БД) і онлайн актуальність (не плутати з актуальністю в кілька хвилин, онлайн - це коли після виконання кожної транзакції дані передаються в другій вузол) даних для філій не потрібно;
- У нас є філії, в яких відбувається тільки введення даних (наприклад, роздрібні магазини), тому можна істотно знизити навантаження на центральну БД;
- З міркувань безпеки ми хочемо, щоб в філіях навіть теоретично (з адмін. Паролем) не було доступу до важливих даних, наприклад балансу підприємства.
В одному випадку для мене були актуальні питання 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.х
Існують два підходи для реалізації:
- Механізм «Плани обміну»;
- Власна реалізація реєстрації об'єктів.
Розглянемо обидва варіанти.
Механізм планів обміну дозволяє, без будь-якої настройки, за кілька хвилин, створити РБД з повним обміном даними. Якщо встановити прапор «Розподілена інформаційна база», то при створенні пакета оновлення будуть вивантажені і оновлення конфігурації. Всього за кілька хвилин можна налаштувати і правила дозволу / заборони обміну різними типами даних, відкривши склад плану обміну. Якщо встановити прапор «Автореєстрація» в положення «Заборонити», то даний тип об'єкта, без додаткових зусиль, ніколи обмінюватися не буде.
Навіщо входити в систему, чому не вивантажувати все і відразу? У будь-якому випадку файл, який містить лише зміни стану БД, буде менше повного знімка самої БД. Тому варіант повного вивантаження розглядатися не буде.
Як налаштувати фільтрацію даних за належністю до підрозділу? Тут вже доведеться програмувати. У моїй реалізації на запис будь-якого об'єкта була встановлена \u200b\u200bпідписка на подію «При записи», де, за допомогою властивості «ОбменДаннимі.Получателі», можна встановити список одержувачів даного об'єкта. Тобто при вивантаженні стандартними засобами для вузла, якого немає в списку, об'єкт вивантажено не буде. Є й інше рішення - вибирати вивантажувати чи об'єкт можна безпосередньо під час вивантаження об'єкта, в процедурах «ПріОтправкеДаннихПодчіненному» і «ПріОтправкеДаннихГлавному» модуля плану обміну.
Обидва варіанти мають право на існування. Однак в якості кращого варіанта вибрав перший, тому що обчислення ознаки вигружаемості відбувається відразу ж під час запису об'єкта, що збільшує тривалість запису об'єкта на 3-5% (можна оптимізувати, в деяких випадках можна досвесті до 0.01%) тобто в середньому 0.1-0.3 секунди, а в разі розрахунку вигружаемості об'єкта безпосередньо при відправленні даних, яка і так створює суттєве навантаження на БД, цей час буде складати до декількох хвилин.
Для повного розуміння роботи механізму «Плани обміну» рекомендую прочитати главу 15 книги «Професійна розробка в система 1С: Підприємство 8», Габец А.П., Гончаров Д.І.
Будь-яка власна реалізація, на мій погляд, або повторить механізм «Плани обміну», або буде вивантажувати об'єкт відразу при зміні, або буде вивантажувати більше, ніж механізм «Плани обміну» (наприклад, вивантажити всі зміни за сьогоднішній день). Дане питання не розглядаю через брак досвіду реалізації.
транспорт
Завдання транспортування файлів від головного до підлеглого вузла зводитися до максимальної відмовостійкості. Не рідко файли шифруються або передаються по захищеному каналу. Для передачі файлів бажано використовувати кілька різних служб, або підготувати кілька різних варіантів підключення. Наприклад, основний спосіб передачі - це використовуючи FTP-сервер, підключений через VPN -туннель; резервний - це e -mail сервер з TLS -Підключення. Навіщо потрібен резервний канал з іншою службою? Як показує практика, використовувати 2 різних FTP сервера менш надійно, ніж FTP сервер і E -Mail.
Рекомендую службу створення пакета поновлення відокремлювати від служби транспорту, це підвищить відмовостійкість всього комплексу обміну даними. У разі, якщо служба, що займається транспортом файлів, які не відпрацює, то служба створення пакетів оновлень продовжить нормально працювати і при деяких умовах буде перезапускати службу транспорту і навпаки.
Моя реалізація РБД
Реалізація повністю автономна, тому як подзадача виступала максимальна відмовостійкість. Звідси вийшло 2 служби - служба транспорту оновлень і служба імпорту / експорту даних. Обидві служби працюють незалежно один від одного.
Після кожного успішного циклу імпорту-експорту даних зберігалося час останнього обміну з цим вузлом. Якщо обміну не відбувалося дуже довго, то транспортна служба починала вивантажувати файли в усі, доступні їй, канали зв'язку з розрахунку на те, що другий вузол все-таки отримає оновлення і вивантажить свої файли. У разі виняткових ситуацій система сама відправляє повідомлення адміністратору з докладним опис помилки.
Для скорочення обсягу трафіку xml-файли пакували в zip -архіви. Система підтримує два види транспорту - FTP та E -mail.
Як налаштувань для фільтра даних існують дві таблиці. В одній (таблична частина планів обміну) зберігаються умови за загальними реквізитами (для кожного об'єкта система намагається знайти цей реквізит), в інший настройки під конкретний об'єкт метаданих. При записи будь-якого об'єкта спочатку відбувається пошук умов за загальними реквізитами (наприклад, Підрозділ), після чого система намагається визначити, чи є персональне правило на цей тип об'єкту за всіма його реквізитами. Не рекомендую фільтрувати списки - велика можливість помилитися, наприклад, з табличній частині видаткової накладної зникнуть кілька рядків, а залишки при цьому будуть рухатися все і навпаки.
Важливо розуміти, під яким системним користувачем працюватимуть служби, тому що може не вистачити прав на створення файлів навіть в тимчасовій папці 1С. Для налагодження вкрай рекомендую писати кожну, успішно виконану, операцію в журнал реєстрацій, або в txt-файл. В 1С 8.1 виконання серверного коду налагодити не можна.
Для зручності налагодження та налаштування своєї реалізації прикладаю обробку "Реєстрація змін", опис якої знаходиться в самій обробці.
Загальна схема роботи комплексу обміну даними вказана на рис 3.
Фільтрація даних відбувається в підписці на подію «ПередЗапісью» кожного об'єкта. Не варто забувати, що при створенні початкового образу вузла дані теж необхідно відфільтрувати. Процедура створення початкового образу досить тривала, тому рекомендую оптимізувати по максимуму її код (наприклад, кешувати налаштування фільтрації).
Післямова
Головне завдання - це відповісти на список питань:
- Навіщо нам потрібна РБД?
- Чим не влаштовує робота через RDP- клієнт?
- Де і чому ми хочемо встановити вузли РБД?
- Як буде відбуватися транспорт оновлень?
- Який рівень відмовостійкості буде реалізований?
Обробка "РегістраціяІзмененій"
Обробка дозволяє примусово реєструвати зміни в об'єктах. Є кілька варіантів реєстрації змін:
- Якщо встановлена \u200b\u200bгалочка на будь-якому метаданих і НЕ обраний жоден об'єкт і НЕ встановлений прапор "Вивантажувати за всіма значеннями", то РЕЄСТРУЄТЬСЯ тільки вибрати ТАБЛИЦЯ;
- Якщо встановлений прапор "Вивантажувати за всіма значеннями", то вибрані метадані будуть вивантажено по всіх об'єктах в циклі;
- Якщо перемикач встановлений в режим "Вивантажувати тільки вибрані об'єкти", то буду вивантажені виключно вибрані об'єкти (наприклад: установка прапора на метаданих без вибору об'єктів рівносильна включеному прапору "Вивантажувати за всіма значеннями" і перемикача в позиції "Вивантажувати тільки вибрані об'єкти";
- Якщо перемикач встановлений в режим "Вивантажувати вибрані і безпосередньо пов'язані об'єкти" то буду вивантажені вибрані об'єкти і ті об'єкти, існування яких залежить від існування обраного об'єкта (наприклад: у довідників - підлеглі довідники);
- Якщо перемикач встановлений в режим "Вивантажувати по всіх посиланнях", то буду вивантажені ВСЕ об'єкти в яких є посилання на обраний об'єкт.
З додаткового функціоналу є:
- Перереєстрація зареєстрованих об'єктів, часто потрібно для налагодження;
- Видалення зареєстрованих, часто потрібно для налагодження;
- Друк змін - друк повного переліку об'єктів, які позначені як змінені;
- Друк дерева конфігурації - тільки для зручності перегляду всієї конфігурації.
Часто виникає ситуація, коли організація має кілька філій або торгових точок, територіально віддалених один від одного. Проте залишається необхідність вести єдиний облік по всій організації. Одним з варіантів вирішення цього завдання є створення єдиної мережі, в яку будуть включені автоматизовані робочі місця всіх філій, і розміщення інформаційної бази 1С на загальнодоступному сервері. Цей спосіб може бути технічно складний і витратний. Крім того, виникає ряд питань, пов'язаних з інформаційною безпекою.
Другий варіант - створення розподіленої інформаційної бази (РИБ). Розподілена інформаційна база являє собою ієрархічну структуру, що складаються з окремих інформаційних баз на платформі 1С: Підприємство, між якими організований обмін даними з метою синхронізації конфігурації і даних. Ці окремі інформаційні бази називаються вузлами РИБ.
Розподілена інформаційна база може бути створена на основі різних конфігурацій системи 1С: Підприємство. Розглянемо її створення на прикладі 1С: Управління торгівлею 10.3.
Припустимо, в організації торгівлі відкривається додаткова торгова точка, в якій необхідно мати доступ до загальної торговельній системі організації. Для створення РИБ необхідно виконати наступні кроки:
На цьому створення розподіленої інформаційної бази завершено. Для обміну інформацією необхідно запустити обмін даних в Центральній базі (вивантажити зміни, які відбулися в ній), потім - в магазині (завантажаться зміни з центральної бази і вивантажити зміни, що відбулися в магазині), і знову - в центральній базі (в неї буде завантажено зміни , що відбулися в магазині).
Розподілені інформаційні бази мають свій механізм вирішення колізій. Так, якщо при проведенні обміну з'ясовується, що який-небудь об'єкт (документ, довідник і т.д.) був змінений і в головній, і в підпорядкованій базі, то пріоритет матиме зміна, зроблене в головній базі.
При необхідності змінити конфігурацію розподіленої інформаційної бази, це потрібно робити в кореневому вузлі (див. Перший малюнок статті), зміни інших вузлів заблоковані. Після проведення необхідних змін, їх можна передати в підлеглі вузли за допомогою стандартної процедури обміну даними між вузлами РИБ. Після проведення обміну в конфігураторі підлеглого вузла необхідно виконати оновлення конфігурації інформаційної бази.
Якщо у вас виникли проблеми з налаштуванням розподіленої інформаційної бази, наші фахівці допоможуть вам налаштувати обмін даними і докладно пояснять, як його використовувати.
Інструкція по створенню та налагодженню розподілених баз за допомогою компоненти УРБД (УРІБ)
Компонента УРБД (Управління розподіленими базами даних) застосовується для обміну інформацією між двома ідентичними базами 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: \\ base2 \\ PC \\ 021.zip
7. Копіюємо файл D: \\ base2 \\ PC \\ 021.zip в папку D: \\ base1 \\ PC
8. Повторюємо пункт 2. У результаті в центральній базі з'являться зміни, які надійшли з периферійної бази.
Отже, загальний принцип обміну: почергове виконання автообміну з одночасним переміщенням файлів (пакетів обміну) з папки PC однієї бази в папку PC іншої бази і з папки CP однієї бази в папку CP іншої бази.
Зміна конфігурації проводиться тільки в центральній базі. При зміні конфігурації необхідно проведення обміну в периферійних базах в монопольному режимі. Для успішної обробки пакетів з периферійних баз в центральній базі конфігурація повинна бути завантажена в периферійні бази. Якщо ви заплуталися - нічого страшного, відкинутий центральною базою пакет вивантажиться повторно.
У цьому матеріалі докладна інструкція по налаштуванню обміну РИБ для 1С: Підприємство 8 і проблеми, з якими зіткнувся автор.
1. Створення вузлів
Створюємо нові вузли (головний і підлеглий): в призначеному для користувача режимі "Операції / Плани обміну / Повний"
Виберемо план обміну "Повний"
Створюємо два записи:
- перший запис назвемо "ЦБ" (головний вузол), код вкажемо "ЦБ",
- другий запис назвемо "Підлеглий вузол", код вкажемо "ПУ".
Значок з зеленим кружком - "ЦБ" (головний вузол)
Для підлеглого вузла натискаємо на іконку "Створити початковий образ". (Буде потрібно монопольний доступ)
Створити початковий образ
Далі у вікні заповнюємо параметри нової бази. Після закінчення натискаємо кнопку "Готово"
Створення початкового образу ІБ
Розпочнеться створення початкового образу підлеглого вузла розподіленої інформаційної бази, після закінчення з'явиться повідомлення "Створення початкового образу успішно завершено". Тиснемо кнопку "ОК".
Додаємо базу підлеглого вузла в список баз, запускаємо її.
У цій підпорядкованої базі відкриваємо повний план обміну - значок "ЦБ червоний, це означає, що цей вузол є головним для інформаційно бази, в якій ми знаходимося.
2. Налаштування префіксів
Для кожної бази, в настройках параметрів обліку (в УПП "Сервіс / Параметри обліку") на закладці "Обмін даними", встановлюємо префікси. Це робиться для того щоб не виникало конфліктів в номерах і кодах документів і довідників, створених в двох базах.
Для автообміну, встановлюємо галочку "Використовувати механізм автоматичного обміну ..."
Закладка "Обмін даними"
3. Додаємо настройку обміну даними між вузлами
Відкриваємо: "Сервіс \\ Розподілена інформаційна база (РИБ) \\ Налаштувати вузли РИБ"
Натискаємо "Додати", відкриється вікно "Налаштування обміну даними"
Налаштування обміну даними
Натискаємо на значок "Виконати обмін по установленою"
Виконати обмін по установленою
Тепер про "підводні камені"
1. Обмін даними може виконуватися в автоматичному режимі і може бути инициализирован в наступних випадках:
* При запуску програми. Обмін буде виконуватися під час запуску програми,
* При завершенні роботи з програмою. Обмін буде виконуватися перед завершенням користувачем роботи з програмою,
* При появі каталогу. Обмін буде виконано тільки в тому випадку, якщо каталог вказаний користувачем був не видко, а зараз стало видно. Налаштування може бути використана для виконання автоматичного обміну при підключенні до локальної мережі або flash карти. Програма періодично перевірятиме видимість зазначеного в налаштуваннях каталогу і відзначати його поточний стан,
* При появі файлу. Рекомендується використовувати дані режим, коли потрібно виконати обмін, якщо з'являється входить файл обміну даними. В цьому випадку, досить вказати повний шлях до вхідного файлу обміну даними. Програма періодично аналізує наявність файлу, і як тільки він з'явиться, буде виконаний обмін, а після обміну цей файл буде примусово УДАЛЕН (це робиться для того, що б процедура обміну не виконувалася постійно),
* Періодичний обмін даними. Обмін буде виконуватися згідно налаштувань періодичного обміну даними. Якщо інформаційна база працює в файл-серверному режимі, то періодичний обмін виконується тільки у користувача, який вказаний в параметрах облікової політики як "Користувач для регламентних завдань у файловому режимі". В Клієнт-серверному варіанті обмін виконується на сервері 1C: Підприємства.
У мене Клієнт-серверний варіант - для роботи регламентного автообміну довелося перевантажувати сервер
2. Кодування Windows.
Обмін переривався помилкою - так як не відбувається стиснення файлу. Це через помилку кирилиці в командному рядку при стисненні.
Лікується виправленням кодувань в реєстрі.
Наприклад, для Windows Server 2008 -
код
REGEDIT4
"1250" \u003d "c_1251.nls"
"1251" \u003d "c_1251.nls"
"1252" \u003d "c_1251.nls"
"1253" \u003d "c_1251.nls"
"1 254" \u003d "c_1251.nls"
"1 255" \u003d "c_1251.nls"
3. Створюючи копію бази (наприклад, для доопрацювання) в клієнт-серверному варіанті, НЕОБХІДНО, щоб регламентний ЗАВДАННЯ КОПІЇ бази були вимкнені. Блокування регламентних завдань для копії ВКЛ
Якщо їх не заблокувати, то копія буде робити обміни з такого самого розкладом, що і основна база. Значить, частина повідомлень в віддалені вузли буде формуватися з робочої бази, а частина з копії, що призведе рассинхронизации конфігурацій.
Технологія розподілених інформаційних баз (РИБ) дозволяє створити територіально розподілену систему на базі конфігурацій 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) і параметри підключення до сервера.
Закладка автоматичний обмін дозволяє налаштувати розклад обмінів, обмін щодо подій (початок і завершення роботи і т.п.), дані настройки проводяться для користувача від чийого імені буде виконуватися обмін, тому переконайтеся в наявності у нього прав для обміну даними.
Не забудьте вказати префікс вузла для нумерації документів (інакше ви отримаєте різні документи з однаковими номерами) в Сервіс - Налаштування програми, тут же можна налаштувати і деякі інші параметри обміну. На цій же закладці слід вибрати користувача для виконання завдань обміну, якщо ви цього не зробите розклад працювати не буде. Пам'ятайте, що обмін буде здійснюватися тільки в тому випадку, якщо даний користувач виконав вхід в програму.
На цьому настройка центрального вузла закінчена, тепер потрібно провести аналогічні налаштування для периферійного вузла, підключивши початковий образ як існуючу ІБ. Після чого можна приступати до обміну даними. Для контролю слід скористатися Монітором обміну даними, Він дозволяє не тільки контролювати успішність проходження вивантаження / завантаження, але і показує виникли колізії або відкладені руху (якщо користувачеві який виготовляв обмін не вистачає прав для здійснення будь-яких дій в базі). Наявність даного інструменту дозволяє швидко і ефективно вирішувати різного роду проблеми, що виникають при автообмене.
На цьому настройку обміну можна вважати закінченою і приступати до роботи в розподіленому режимі. Окремо варто зупинитися на оновленні або внесення змін в конфігурацію. Ці дії доступні тільки на центральному вузлі, всі внесені зміни будуть автоматично поширені на периферійні вузли при наступному обміні. Для автоматичного внесення змін потрібно щоб периферійна база знаходилася в монопольному режимі, в іншому випадку потрібно буде запустити Конфігуратор і виконати Оновлення конфігурації бази даних вручну.