1с 8 риб та додані об'єкти. Розподілена інформаційна база. Покрокова інструкція та підводні камені. Налаштування обмінів розподіленої інформаційної бази
РИБ - розподілена інформаційна база, що представляє собою деревоподібну конструкцію, гілками якої є окремі розгорнуті бази 1С Підприємства. Ці бази називають вузлами розподіленої інформаційної бази(Далі просто вузли). Між цими вузлами утворено обмін інформацією для синхронізації всіх вузлів (конфігурацій та баз).
Основним механізмом є механізм обмінів з деякими відмінними та універсальними можливостями. Основною відмінністю можна виділити те, що механізм обміну РІБ є більш спеціалізованим і вузьким, тоді як універсальні обміни дають користувачеві ширше коло можливостей.
Базові засади роботи РИБ
Змінювати структуру зміни можна лише у головному кореневому вузлі розподіленої інформаційної базы. Далі ці зміни ієрархічно поширюються до підлеглих вузлів. Таким чином, це забезпечує єдиний простір структури конфігурації у всіх вузлах РИБ.
Дані ж можуть бути змінені в будь-якому з вузлів, які в свою чергу поширюються на всі інші вузли. Причому ці дані не обов'язково мають бути передані іншим учасникам системи та їхня повна ідентичність може не підтримуватися. Склад даних, що беруть участь в обміні з іншими учасниками РІБ, розробник може налаштувати за власним бажанням. Причому налаштування можуть проводитися не тільки на урочні метаданих конфігурації, але й на рівні окремих елементівна які можна накласти спеціальні відбори.
Як було зазначено вище, механізм РИБ досягається з допомогою використання планів обміну. але щоб той чи інший план міг використовуватись у цій ієрархічній структурі, у нього має бути активована властивість "Розподілена інформаційна база".
Всі дані в РИБ передаються за допомогою повідомлень. Вміст цих повідомлень чітко регламентований і може бути довільним, як і універсальному механізмі обмінів. Дані поміщаються у повідомлення, використовуючи принцип XML серіалізації. Крім цих змін даних, повідомлення також містить інформацію про зміну конфігурації, а також деяку кількість службової інформації. Зміни реєструються від поміщаються у повідомлення обміну повністю автоматично. Ні користувач, ні розробник на це не можуть вплинути.
Прийом та формування повідомлень обміну в РІБ встановлюються однією командою
Плани обміну. ЗаписатиЗміни(Запис Повідомлення, 0 )
Вміст читається за допомогою команди
Висновок
Можна сміливо говорити, що механізм РІБ переважно складається з механізму універсального обмінуз деякими відмінними рисами, які є лише у структурі РИБ.
Завдання: необхідно налаштувати інформаційну базу так, щоб в одній робочій базі могли працювати три користувачі, які не знаходяться в локальної мережі, але підключені до Інтернету.
Здійснимо це завдання через налаштування розподіленої інформаційної бази. Зміна інформаційної бази – “Бухгалтерія підприємства 2.0”.
Налаштування ресурсу FTP.
Налаштуємо FTP на прикладі HCube: Заходимо на веб-сайт hcube.ru. Вкладка Хостинг, FTP Хостинг (http://www.hcube.ru/hosting/ftp/). Вибираємо мінімальний тарифний план FTP -10 цього буде достатньо для обміну між вузлами розподіленої інформаційної бази. Можна замовити пробний період 15 днів, натискаємо "Пробуємо". Далі нам необхідно зареєструватися:
Вказуємо ім'я користувача та пароль для доступу до особистого кабінету. Після того, як заявку прийнято, чекаємо листа на вказану електронну пошту з реквізитами доступу до FTP . Інформація про конфігурацію Вашої послуги хостингу: ************************************************ *********************
Логін хостингу: user725
Пароль хостингу: ffUXP3CDU
IP-адреса хостингу: 85.10.207.234
****************************************************************
Панель керування для ФТП хостингу https://cp.hcube.ru/manager/ispmgr 
Чекаємо, коли стан стане активним.
Налаштування плану обміну.
Потрібно визначити центральний вузол бази даних. Центральним вузлом оберемо робоче місце, що знаходиться в офісі. З центральним вузлом обмінюватимуться два інші. Налаштуємо центральний вузол. Для цього в ІБ необхідно зайти під користувачем із повними правами. В основному меню програми вибрати пункт "Операції / Плани обміну ...". У планах обміну стандартної конфігурації "Бухгалтерія підприємства 8" вже створено 7 стандартних планів обміну: 
Відкриваємо план «Повний». У ньому знаходиться один зумовлений порожній запис. Цей запис визначає поточний вузол. Зумовлену, тобто. доданий на рівні конфігурації запис видалити не можна, але його можна виправити. Натискаємо змінити: поле «Найменування»може бути довільним, наприклад «Центральний вузол». «Код»теж може бути довільним, наприклад "01", тиснемо "ОК". Поточний вузол описаний, тепер потрібно описати підлеглі вузли. Додаємо нові елементи з ім'ям «Вузол 1»та кодом «02»і «Вузол 2»з кодом «03». Отримуємо три вузли: 
У РИБ може бути багато підлеглих вузлів і обмін вироблятиметься між одним центральним вузлом і кожним із підлеглих вузлів. Тепер фізично створимо підлеглий вузол (нову базу даних). Для цього необхідно стати на рядок вузла «Вузол 1»і натиснути на значок "Створити початковий образ ..."або вибрати цю дію з меню: 
Система запропонує вибрати тип інформаційної бази (ІБ). Необхідно вибрати «На даному комп'ютері…»
. Потім вказати каталог, в якому буде створено нову ІБ. Після цього у вказаному каталозі буде створено нову базу і в цю базу буде перенесено всі дані з головної бази. Відразу варто зазначити, що нова ІБ не є точною копієювихідний. У ньому свої налаштування (свій список користувачів і т.д.), переносяться лише дані та модифіковані плани обміну, тобто. у новій ІБ залишаться лише два вузли «Центральний вузол»і «Вузол 1». Якщо вихідна база даних велика і в ній працюють користувачі, при створенні початкового образу можливі колізії, тому операцію створення нового образу рекомендується проводити в монопольний режим.Якщо центральному вузлі було описано кілька підлеглих вузлів, операцію зі створення початкового образу ІБ необхідно провести кожному за вузла, тобто. буде створено стільки нових ІБ, скільки було описано вузлів у вихідній базі. Теж зробимо для «Вузол 2». У момент створення початкового образу, у головній базі буде створено таблицю синхронізації об'єктів головної бази з цим вузлом. У випадку таких таблиць створюється за кількістю підлеглих вузлів. Під час створення початкового образу вузла встановлюється ознака синхронізації з вузлом. Тепер бази даних підлеглих вузлів необхідно скопіювати на робочі місця «Вузол 1»і «Вузол 2». Після цього на трьох комп'ютерах будуть однакові (у сенсі даних) інформаційні бази.
Налаштування обмінів розподіленої інформаційної бази.
У цьому завдання ми загальний випадок, коли три бази даних є робочими, тобто. документи вводяться та змінюються у трьох базах. Перейдемо до меню «Сервіс / Розподілена інформаційна база (РІБ) / Налаштувати вузли РІБ». Налаштуємо обмін між Центральним вузломі Взлом 1. На вкладці «Розподілені інформаційні бази» додаємо новий елемент, назвемо його «Офіс – Вузол 1»(Де «Офіс» це наш Центральний вузол). Вибираємо у реквізиті «Вузол» – «Вузол 1». В полі "Тип обміну"обираємо «Обмін через FTP ресурс». Заповнюємо реквізити, які надішли нам у листі на пошту: «Адреса», «Користувач», «Пароль». Вкладки "Інтерактивний обмін"і "Автоматичний обмін"доки не заповнюємо, зробимо це після основних налаштувань обміну у всіх вузлах. 
Далі за аналогією створимо новий елемент налаштування обміну між Центральним вузлом і Вузлом 2. 
Зайдемо у раніше створений початковий образ (інформаційна база) Вузла 1і створимо налаштування «Вузол 1 – Офіс».
Зробимо також у Вузлі 2. 
На вкладці "Інтерактивний обмін"ми можемо визначити: чи потрібно нам і вивантажувати та завантажувати дані, чи щось одне. 
На вкладці "Автоматичний обмін"можна додати новий елемент для налаштування автоматичного обміну. Тут ми можемо встановити розклад для конкретного обміну, наприклад для «Офіс – Вузол 1», та/або обмін за подіями. 
При виборі користувача в налаштуваннях обміну подіями необхідно також вказати даного користувачав «Налаштування програми»на вкладці "Обмін даними".
Обмін у нашому прикладі буде виконуватися лише в тому випадку, якщо до бази зайшли під вказаним у налаштуваннях «Обмін за подіями»користувачем. Також потрібно вказати "Префікс вузла для розподіленої інформаційної бази"для коректної нумерації документів За допомогою префіксу ми зможемо бачити: яким вузлом створювався документ, а також уникнути дублювання номерів документів. Для зручної роботиу Розподіленій інформаційній базі необхідно ретельно продумати цикл обміну вузлів один з одним, розклад обміну та/або обмін подіями під конкретне завдання.
Створення та налаштування розподіленої базиданих (РІБ) в 1С 8.3 Бухгалтерія (та інших конфігураціях) необхідні у випадках, коли немає можливості працювати кільком користувачам, одночасно підключаючись до однієї бази даних. В даний час це досить рідкісне явище, так як чудово працює стандартний віддалений робочий стіл та є інші програми, які забезпечують віддалене підключення до центрального комп'ютера, де розташована база даних.
Але бувають ситуації, коли просто немає інтернету. А дані мають у результаті опинитися в одній інформаційній базі. І тому створюється розподілена база даних.
Зазвичай головну базу називають центральною, інші — периферійними. Суть у тому, що або в ручному або автоматичному режимі (залежить від налаштування) бази даних об'єднуються в одну. Щоб номери нововведених документів та коди довідників не дублювалися, кожній базі даних призначається префікс.
У цій інструкції ми на прикладі створимо центральну та периферійну бази даних, перевіримо обмін між ними. Цей посібник підійде як для 1С 8.3 Бухгалтерія, так і для 1С Управління торгівлею (УТ) та інших конфігурацій.
Налаштування головної (центральної) розподіленої бази РІБ
Зайдемо в меню 1С "Адміністрація", далі за посиланням "Налаштування синхронізації даних". У вікні потрібно встановити прапорець «Синхронізація даних». Стане активним посилання «Синхронізація даних». Відразу тут же встановимо префікс для головної інформаційної бази – наприклад, ЦБ:
Заходимо на посилання «Синхронізація даних», відкриється вікно з кнопкою «Налаштувати синхронізацію даних». При натисканні на цю кнопку відкриється список, що випадає, де потрібно вибрати режим «Повний». Якщо потрібно синхронізувати лише одну організацію, потрібно вибрати «По організації…».
У наступному вікні програма запропонує зробити резервну копію. Настійно рекомендую це зробити, оскільки наступні кроки настройки можуть бути незворотними.
Після створення резервної копіїнатискаємо кнопку "Далі". На наступному кроці нам слід визначитися, як відбуватиметься синхронізація:
- через локальний каталог чи каталог у локальній мережі;
- по інтернету за допомогою FTP.
Для простоти та наочності прикладу виберемо локальний каталог. Я вказав наступний шлях: «D: Бази 1С Синхронізація». Чи не зайвою буде перевірка запису в даний каталог, для цього є спеціальна кнопка:
Отримайте 267 відеоуроків з 1С безкоштовно:
Наступні кроки з налаштуванням синхронізації по FTP та електронній поштіпропускаємо. Зупиняємось на налаштуваннях назв головної та периферійної баз даних. Тут же поставимо префікс для периферійної бази:
Не забувайте, що префікси кожної бази мають бути унікальними. В іншому випадку Ви отримаєте помилку «Значення префіксу першої інформаційної бази не є унікальним».
Тиснемо "Далі", перевіряємо введену інформацію і знову натискаємо "Далі", потім - "Готово". У полі «Повне ім'я файлової бази» вказуємо файл 1Cv8.1CD у каталозі, який створили для синхронізації. Створюємо початковий образ розподіленої бази 1С:
Після створення початкового образу РИБ в 1С можна встановити розклад синхронізації або синхронізувати вручну:
Після синхронізації можна підключитися до нової бази даних та переконатися, що туди вивантажилася інформація з центральної бази:
Тільки відразу в новій периферійній базі заведіть хоча б одного користувача з правами адміністратора.
Налаштування синхронізації у периферійній базі даних
У периферійній базі 1С налаштування набагато простіше. Достатньо встановити прапорець «Синхронізація даних» та перейти за однойменним посиланням. І ми майже відразу потрапляємо у вікно із кнопкою «Синхронізувати». Спробуємо створити тестову номенклатуру в периферійній базі та вивантажити її в основну за допомогою РИБ:
Жовтень 25th, 2016
Між налаштуванням і підтримкою РІБ на 2 вузли і на 10 великої різниці немає, а коли кількість віддалених точок перевалює за сотню, доводиться вирішувати вже зовсім інші питання
Початкові дані:
Конфігурація: Роздріб 2.2
Платформа 1С: 8.3.7.1970
Термін проекту: рік.
Архітектура:
Спочатку визначилися із схемою РИБ. Було ухвалено рішення орієнтуватися на схему "зірка", поки це буде можливо; при досягненні технологічних обмежень – сніжинка.
Огранічення:
- 2 ГБ ОЗУ
- 1 фізичний процесор
З усього переліченого вище напружує в основному обмеження на максимальний обсяг БД.
Але це всього лише означає, що потрібно організувати процедуру її очищення від застарілих даних на місцях.
Під сервер 1С та MS SQL виділяється окремий фізичний сервер. На нього лягатиме основне навантаження щодо обмінів та проведення тривалих операцій.
Кінцеві клієнтські комп'ютери не замінюються, тому що працюватимуть з тонким клієнтомі навантаження на них буде мінімальним.
.
Основні налаштування
З часів УТ 10.3, на якій у мене відбувся перший проект впровадження РІБ на 60 вузлів, звичайно "вибігло багато води".
1С не стояли дома. Роздріб 2.2 тепер враховує необхідність вибіркового розвантаження даних.
В базу магазину вивантажуватиметься лише та інформація, яка має до нього відношення:
- всі довідники (крім спеціалізованих)
- Документи по даному магазину
Інше питання що так чи інакше додавання вузла в базу означає додавання ще одного запису до таблиці реєстрації на кожен загальний елементпід час його запису.
1) Потрібно розділити на окремі сценарії синхронізації на розвантаження та завантаження
Сенс у тому, що вивантаження відбувається довго і з блокуваннями, а завантаження досить безпроблемно. При цьому часто буває, що дані нам потрібно оперативно отримувати з роздрібних точок, віддаючи при цьому лише кілька разів на день.
2) Виділити проблемні магазини та прибрати їх із загального сценарію синхронізації. На них можуть бути великі вивантаження - при цьому гальмуватися буде весь обмін, включаючи інші вузли. Після вирішення проблем вони додаються назад
3) Створити кілька сценаріїв відправлення та отримання даних. Але тут головне зловити правильний баланс їхньої кількості.
(Ще з версії 8.1).
Отже, паралельність у вивантаженні РИБ обмежена. На практиці виходить запускати паралельно 2-3 сценарії.
Що довелося допрацювати
Найголовніший одвірок у штатній логіці 1С РИБ - це оновлення
Ще однією проблемою обміну стають регістри відомостей. Вивантаження в XML кожного запису регістру відомостей створює окремий вузол XML зі службовими елементами і т.п. довідник у якого 100 рядків у табличній частині вибереться лише один запис. А це час монопольного блокування. Так що якщо в РС багато записів, які регулярно реєструються до обміну в інші магазини, то це звичайно правильне представити у вигляді довідника з табличною частиною, який у крайньому випадку під час запису може формувати рядки цього ж регістру. В будь-якому випадку, .
Ще одна важлива деталь - Навіщо? Дисконтних карток накопичилося вже близько 3 млн. Для роботи з ними використовується зовнішня online система. Якщо продовжувати передавати дисконтні картки на всі магазини - це в рази збільшить обміни, крім того, може призвести до перевищення об'єму в 10 ГБ.
Частину механізмів реалізовано online зверненням до центральної бази: залишки в інших магазинах, повернення за чеком з іншого магазину, перевірка валідності подарункового сертифікату.
Тиражування
Створення початкового вузла РИБ штатним чином унеможливило б тиражування в принципі.
Тому новий вузол створюється так:
2) Ця база обмінюється в РИБ усіма загальними даними але не отримує спеціалізованих (документів)
5) База для магазину готова.
На сервер розгортається вже готовий пакет, тому багато часу це не займає. Потім на сервер заливається новостворена база і готовий для відправки в магазин.
Переваги тонкого клієнта
Дві істотні переваги Роздріб 2.2 (Тонкого клієнта) які "зігріли душу":
Підтримка та оновлення
1) Оновлювати руками магазинів (не дуже правильно, можуть не отримати зміни, будуть дзвінки та проблеми) – так було раніше
3) Написати *.cmd або 1С скрипт для оновлення або взяти готовий. Як показує практика, таке рішення завжди половинчасте (нестабільне), а функціональності в ньому вдасться закласти небагато.
Які ми мали завдання:
2) При оновленні можлива інтерактивна взаємодія з користувачем (повідомлення, підтвердження, прогрес бар).
Основні функції:
4) Перевірка стану агентів
5) Звіти про оновлення
6) резервне копіювання
Ось так, наприклад, виглядає повідомлення про помилку після оновлення:
Таким чином, у проекту з'явилися непогані шанси бути завершеним успішно. Принаймні на середині шляху "політ нормальний".
Якщо прийдемо ще до будь-яких рішень, які можуть здатися цікавими, напишу окремо
P.S. і найголовніше: Правильне планування подальшої підтримки – один із ключових факторів подальшого успіху подібних проектів. :)
Жовтень 25th, 2016
Між налаштуванням і підтримкою РІБ на 2 вузли і на 10 великої різниці немає, а коли кількість віддалених точок перевалює за сотню доводиться вирішувати вже зовсім інші питання.
Отже, вихідні дані:
Конфігурація: Роздріб 2.2
Платформа 1С: 8.3.7.1970
Орієнтовна кількість вузлів наприкінці проекту: 200
Ресурси обладнання у центрі: без суттєвих обмежень
Обладнання на точці: питання, що обговорюється.
Термін проекту: рік.
Архітектура:
Спочатку визначилися із схемою РИБ. Було ухвалено рішення орієнтуватися на схему "зірка", до тієї
У торгових точках використовується клієнт-серверний варіантроботи, з виділеним сервером, під керуванням Windows.
Сервер 1С буде використаний у варіанті "Сервер 1С МІНІ" https://1c.ru/news/info.jsp?id=17577
Сервер СУБД - MS SQL Express 2008 R2.
SQL Express 2008 R2 - остання на даний момент версія цієї лінійки SQL Server.
Огранічення:
2 ГБ ОЗУ
- 1 фізичний процесор
- 10 ГБ максимальний об'єм бази
З усього перерахованого вище напружує звичайно в основному обмеження на максимальний обсяг БД. Але це всього лише означає, що потрібно буде організувати процедуру її очищення від застарілих даних на місцях.
Під сервер 1С та MS SQL виділяється окремий сервер. На нього лягатиме основне навантаження щодо обмінів та проведення операцій.
Кінцеві клієнтські комп'ютери не замінюються, тому що працюватимуть із тонким клієнтом і навантаження на низ буде мінімальним.
Сервер у магазині – просто потужний ПК. Але обов'язковою умовою є наявність диска SSD- на якому розташовані бази MS SQL.
Також сервер забезпечуватиме можливість проведення регламентних операцій у нічний час та доступ до бази магазину без відриву від роботи.
Основні налаштування
З часів УТ 10.3, на якій у мене відбувся перший проект впровадження РІБ на 60 вузлів, звичайно "вибігло багато води". 1С не стояли дома. Роздріб 2.2 тепер враховує необхідність вибіркового розвантаження даних.
В базу магазину буде вивантажуватися тільки та інформація, яка до нього має відношення:
- всі довідники (крім окремих)
- Документи з даного магназину
Реєстрація даних відбувається за правилами реєстрації, все, що можна кешується. Істотних уповільнень саме на реєстрації немає.
Інше питання, що так чи інакше додавання вузла в базу означає додавання ще одного запису на кожний загальний елемент для всіх баз.
У налаштуванні самого вивантаження нічого специфічного немає. Є деякі нюанси при настроюванні сценаріїв синхронізації:
1) Потрібно розділити на окремі сценарії синхронізації вивантаження та завантаження
Сенс у тому, що вивантаження відбувається довго і з блокуваннями, а завантаження досить безпроблемно. При цьому часто буває, що дані нам потрібно оперативно отримувати з роздрібних точок, віддаючи при цьому лише кілька разів на день.
2) Виділити проблемні магазини та прибрати їх із загального сценарію синхронізації. На них можуть бути великі вивантаження - гальмуватися буде весь обмін, включаючи інші вузли
3) Створити кілька сценаріїв відправлення та отримання для відправлення та отримання даних. Але тут головне — баланс.
Деякі речі у 1С не змінюються. Той самий метод "Вибрати Зміни" може виконуватися лише послідовно(Ще з версії 8.1).
Отже, паралельність у вивантаженні РИБ обмежена. На практиці отримується вивантажувати одночасно 2-3 сценарії.
Що стосується сценарів отримання - тут можлива куди більша паралельність, якщо потрібна звичайно.
Що довелося допрацювати
Звичайно сумно і сумно, але довелося ґрунтовно влазити до БСП. Найголовніший одвірок у штатній логіці 1С - це оновлення. Після оновлення з'являється приблизно таке віконце:
Це все відбувається у монопольному режимі. Крім того, система ще намагатиметься зробити обмін після оновлення в монопольному режимі. До чого все це призводить - не важко здогадатися.
Весь цей період магазин не може працювати, на касі стоять покупці, компанія втрачає гроші.
Ще однією проблемою обміну стають регістри відомостей. Вивантаження в XML кожного запису регістру відомостей створює окремий вузол XML зі службовими елементами та всім звідси поточним. Крім того, функція "вибрати зміни" для регістру відомостей у якому 100 записів результуюча таблиця буде містити 100 рядків, в той же час, якщо це довідник у якого 100 рядків у табличній частині вибереться лише один запис. Так що якщо в РС багато записів, які регулярно реєструються до обміну в інші магазини, то це звичайно правильне подати у вигляді довідника з табличною частиною, який у крайньому випадку при записі може формувати записи цього ж регістра. В будь-якому випадку, регістри відомостей в обмінах - це зло.
Ще одна важлива деталь - з обміну повністю виключені дисконтні карти, а фізособи - лише співробітники конкретного магазину.Навіщо? Дисконтних карток накопичилося вже близько 3 млн. Для роботи з ними використовується зовнішня online система. Якщо продовжувати передавати дисконтні картки на всі магазини – це в рази збільшить обміни, крім того, може призвести до перевищення бази об'єму в 3ГБ.
Частину механізмів реалізовано online зверненням до центральної бази: залишки в інших магазинах, повернення за чеком з іншого магазину, перевірка валідності подарункового сертифікату.
Тиражування
Звичайно, тиражування ведеться прискореними темпами.
Створення початкового вузла РИБ штатним чином звичайно унеможливило б тиражування.
Тому новий вузол створюється так:
1) Існує окрема база з фейковим магазином
2) Ця база обмінюється в РИБ всіма загальними даними але не отримує спеціалізованих
3) Коли хочемо створити нову базу – просто копіюємо цю
4) Потім встановлюємо налаштування – магазин, префікс тощо.
5) База для магазину готова.
На сервер розгортається вже готовий пакет, тому багато часу це не займає. Потім на сервер заливається новостворена база магазинів і готовий для відправки в магазин.
Переваги тонкого клієнта
дві істотні переваги які "зігріли душу".
1) Немає необхідності змінювати весь комп'ютерний парк у торгових точках. 90% операцій виконується на сервері, а сервер туди привозиться "щодо потужний комп'ютер"
2) Техніка має властивості відмовлятися працювати, особливо часто це відбувається із знову встановленим або вже зношеним обладнанням.
У цьому випадку дії тепер гранично прості – магазин перемикається на роботу у центральній базі.
Цей процес займає не більше 5-10 хвилин, таким чином торгівля не переривається навіть за суттєвих проблем з обладнанням.
Підтримка та оновлення
Зрештою дійшли до найцікавішого пункту – як же все це підтримувати та оновлювати?
Для нас оновлення також довгий часбули проблемою:
1) Оновлювати руками магазинів (не дуже правильно, можуть не отримати зміни, будуть дзвінки та проблеми)
2) Оновлювати силами технічної підтримки(немає стільки ресурсів)
3) Написати *.cmd для оновлення або взяти готовий. Як показує практика, таке рішення завжди половинчасте (нестабільне), а функціональності в ньому небагато.
Які ми мали завдання:
1) Оновлення повинно відбуватися в кількох режимах і урпавлятися централізовано
2) При оновленні можлива інтерактивна взаємодія з користувачем.
3) Обов'язково повинні надходити звіти про стан та помилки оновлення
4) Повинне бути резервне копіювання
5) Система оновлення повинна вміти без проблем оновлювати саму себе.
6) Система має бути розширюваною без особливих проблем.
Звичайно завдання вийшли далеко за перелік розв'язуваних простими методами. Оскільки без автоматизації з такою кількістю кінцевих точок не обійтися, а нічого більш-менш готового зі схожим функціоналом ми не знайшли
довелося зайнятися розробкою ПЗ, яке згодом набуло назви MU (MagicUpdater).
Основні функції:
1) Динамічне оновлення бази (команда або за розкладом)
2) Статичне оновлення бази (команда або за розкладом)
3) автоматичне агентів на кінцевих комп'ютерах при їх модифікації
4) Перевірка стану агентів
5) Звіти про оновлення
6) резервне копіювання
7) Адміністративні дії з сервером 1C та MS SQL
8) Закриття всіх клієнтських програм 1С на комп'ютерах мережі
9) Статичне оновлення з акцептом на головній касі
10) Відображення опису модифікацій після оновлення
11) Налаштування порядку дій
12) Виконання всіх цих дій за розкладом
Зразкова схема взаємодій:
Де MU Агент - це служба, що встановлюється та налаштовується в магазині. Власне вона з центру отримує команда виконання певних дланных.
MU Сервер – Сервер, який приймає всі запити до системи.
MU монітор - те, що бачать рядові співробітники технічної підтримки - використовується для перегляду логів і постановки завдань на оновлення або інших.
Вийшло дуже непогано, як на мене. Тепер оновлення відбуваються практично в автоматичному режимі.
Ось так, наприклад, виглядає повідомлення про помилку після оновлення залишилися в центрі все чекає.
А ось таким чином ми здійснюємо відправку команд на клієнтські комп'ютери
Програми звичайно не 1С-ні, але з досить пристойним набором інтерфейсних можливостей. Ось так, наприклад, виглядає відбір за датою:
Тепер до подальшого тиражування готові. Правильне планування подальшої підтримки – один із ключових факторів подальшого успіху подібних проектів.