Инструкция по настройке Распределенной информационной базы (РИБ) через FTP ресурс. Распределенная информационная база
October 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 записей получит результирующую таблицу в 100 строк, в то же время, есдли это справочник у которого 100 строк в табличной части выберется только одна запись. А это время монопольной блокировки. Так что если в РС много записей, которые регулярно регистрируются к обмену в другие магазины то это конечно правильне представить в виде справочника с табличной частью, который в крайнем случае при записи может формировать строки этого же регистра. В любом случае, .
Ещё одна важная деталь - Зачем? Дисконтных карт скопилось уже близко к 3 млн. Для работы с ними используется внешняя online система. Если продолжать передавать дисконтные карты на все магазины - это в разы увеличит обмены, кроме того может привести к превышению базой объёма в 10 ГБ.
Часть механизмов реализована online обращением в центральную базу: остатки в других магазинах, возврат по чеку из другого магазина, проверка валидности подарочного сертификата.
Тиражирование
Создание начального узла РИБ штатным образом сделало бы невозможным тиражирование в принципе.
Поэтому новый узел создаётся следующим образом
:
2) Эта база обменивается в РИБ всеми общими данными но не получает специализированных (документов)
5) База для магазина готова.
На сервер разворачивается уже готовый пакет ПО, поэтому много врмени это не занимает. Потом на сервер заливается вновь созданная база и он готов для отправки в магазин.
Преимущества тонкого клиента
Два существенных преимущества Розницы 2.2 (Тонкого клиента) которые "согрели душу":
Поддержка и обновления
1) Обновлять руками магазинов (не очень правильно, могут не получить изменения, будут звонки и проблемы) -так было ранее
3) Написать *.cmd или 1С скрипт для обновления или взять готовый. Как показывает практика такое решение всегда половинчатое (нестабильное), а функциональности в нём получится заложить немного.
Какие у нас были задачи:
2) При обновлении возможно интерактивное взаимодействие с пользователем (сообщения, подтверждение, прогресс бар).
Основные функции:
4) Проверка состояния агентов
5) Отчеты об обновлениях
6) резервное копирование
Вот так, к примеру, выглядит сообщение об ошибке после обновления:
Таким образом у проекта появились неплохие шансы быть завершенным успешно. По крайней мере на середине пути "полёт нормальный".
Если придём ещё к каким-либо решениям которые могут показаться интересными напишу отдельно
P.S. и самое главное: Правльное планирование дальнейшей поддержки - один из ключевых факторов дальнейшего успеха подобных проектов. :)
October 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С-ные, но с достаточно приличным набором интерфейсных возможностей. Вот так, к примеру, выглядит отбор по дате:
Теперь к дальнейшему тиражированию готовы. Правльное планирование дальнейшей поддержки - один из ключевых факторов дальнейшего успеха подобных проектов.
Зачастую на практике встречаются такие ситуации, когда различные подразделения или филиалы территориально располагаются в разных местах. При этом данные, заносимые в программу в удаленных подразделениях должны как-то попадать в головной офис, чтобы велся общий учет.
В настоящее время данная проблема зачастую решается предоставлением территориально удаленным сотрудникам удаленный доступ к общей базе. Он может быть осуществлен посредством публикации базы на веб-сервере, через удаленный рабочий стол и проч.
Однако, не редки и такие ситуации, когда в территориально удаленном офисе попросту нет интернета, либо он не достаточно стабилен для работы в общей информационной базе. Для этого в 1С существует механизм настройки распределенной базы.
Проще говоря, в головном офисе располагается главная база. В удаленном подразделении используется подчиненная. Таких подчиненных баз может быть и несколько. В результате такая распределенная база объединяется в одну посредством синхронизации. Ее можно производить как в автоматическом режиме по расписанию, так и вручную.
В данной статье мы рассмотрим настройку распределенной базы данных для 1С:Бухгалтерия 3.0. Несмотря на это, инструкция подойдет и для большинства других конфигураций 1С 8.3.
Обратите внимание , что все необходимые доработки конфигурации должны производиться только в главной базе РИБ. При синхронизации эти изменения передадутся во все подчиненные базы и вступят в силу.
Главная информационная база
При использовании распределенной базы данных основные настройки приходятся на главную базу. Производить их нужно в разделе «Администрирование», как показано на изображении ниже.
В открывшемся окне сразу же установите галку «Синхронизация данных». В нижней части укажите префикс главной (текущей базы). Он может состоять не более чем из двух символов. В нашем случае префиксом будет «БГ», так как мы подразумеваем, что эта РИБ 1С «Бухгалтерия главная».
Теперь можно приступить к настройке самой синхронизации, а именно к указанию того, с какой базой (или базами) будет производиться обмен данными. Для этого перейдите по гиперссылке «Настройки синхронизации данных». Она будет доступна для перехода только при установленной галке слева.
В открывшемся окне из меню выберем пункт «Полный…». Он позволит нам указать любую информационную базу 1С для произведения синхронизации.
В первом окне подключения подчиненной базы, которая расположена в территориально удаленном офисе, отметим флагом, что подключение будет производиться через локальный или сетевой каталог. В нашем случае это «D:\DB\InfoBase». Так же заранее проверим возможность записи в него.
Обязательно указывайте разные префиксы для разных баз. Дело в том, что при синхронизации данных для данных, перегруженных из каждой базы, устанавливается свой префикс. При их дублировании работа будет некорректной, поэтому программа не даст вам такой возможности.
Когда программа предложит вам создать начальный образ, выберите эту опцию. Данная процедура займет некоторое время, после чего сохраните его на компьютер с именем «1Cv8.1CD».
Сама синхронизация может производиться как автоматически по расписанию, которое вы можете настроить самостоятельно, так и вручную. Во втором случае достаточно нажать на кнопку «Синхронизировать» в удобное для вас время.
Подчиненный узел РИБ
Количество производимых настроек в подчиненной базы значительно меньше. В том же разделе установите флаг «Синхронизация данных» и перейдя по соответствующей ссылке будет доступна кнопка «Синхронизировать».
В рамках нашего примера в главную базу были добавлены две номенклатурные позиции: «Брус» и «Доска». После синхронизации они попали в подчиненную базу. Как вы можете увидеть на рисунке ниже, им присвоился префикс «БГ». Остальным двум позициям («Токарный станок» и «Поддон») присвоен префикс «БП», так как они были заведены непосредственно в подчиненной базе.
Обратите внимание , что нумерация элементов в нашем случае сквозная, но только в пределах одного и того же префикса.
Для создания распределенной информационной базы необходимо зайти программу в режиме "1С: Предприятие". Для создания узлов распределенной базы в меню выбираем: Операции - Планы обмена. Откроется окно «Выбор объекта: План обмена».
1. Рассмотрим вариант с планом обмена «Полный».
Обмен будет, осуществляться по всем организациям, находящимся в распределенной информационной базе.
Выберем план обмена «Полный». Откроется окно «План обмена полный».
Заполняем две записи:
Первую запись назовем «Главный узел», код укажем «ГУ»,
Вторую запись назовем «Подчиненный узел», код укажем «ПУ».
Как видим из рисунка, у первой записи значок изображен с зеленным кружком, это значок «Главного узла».
Для создания копии информационной базы «Главного узла», кликаем на «Подчиненный узел» и нажимаем на значок «Создать начальный образ». Это будет информационная база «Подчиненного узла».
Откроется окно «Создание начального образа ИБ», выбираем «На данном компьютере или на компьютере в локальной сети», нажимаем «Далее».
В поле «Каталог информационной базы» выбираем местоположение, куда будет установлена копия «Главного узла», нажимаем «Готово».
После создания информационной базы «Подчиненного узла» появится сообщение:
Нажимаем «Ок».
Добавляем информационную базу «Подчиненного узла» в "1С: Предприятие". Заходим в подчиненную базу в режиме "1С: Предприятие". Откроем: Операции - Планы обмена. Откроется окно «Выбор объекта: План обмена». Выберем план обмена «Полный». Откроется окно «План обмена полный». Видим что значок «Главного узла» оранжевый, это значит, что этот узел является главным для той информационной базы, в которой мы находимся.
Следующие настройки делаем и в Главном и в Подчиненном узле:
1.
Добавляем префикс для распределенной информационной базы.
Это делается для того чтобы не возникало конфликтов в номерах и кодах документов и справочников, созданных в двух базах, поэтому в каждой базе указываем префикс, который будет добавляться в номера документов и коды справочников. Открываем: Сервис - Настройка программы - закладка «Обмен данными». В поле «Префикс узла для распределенной информационной базы:» в подчиненной базе вводим «ПУ», в главной базе вводим «ГУ».
2.
Добавляем настройку обмена данными между узлами:
Открываем: Сервис - Распределенная информационная база (РИБ) - Настроить узлы РИБ. Откроется окно «Настройки обменов данными».
Нажимаем «Добавить», откроется окно «Настройка обмена данными». Вводим «Наименование» вашей настройки.
В поле «Узел» автоматически появится узел, для «Главного узла» будет «Подчиненный узел», для «Подчиненного узла» будет «Главный узел».
В поле «Каталог» выберете папку, в которую будут поступать данные обмена, для главной и подчиненной базы лучше всего указывать один каталог.
В поле «Тип обмена» настраиваем передачу данных между базами: через файловый или фтп-ресурс. Выбирем например «обмен через файловый ресурс».
В остальных полях ничего не меняем.
Нажимаем «Ок». Видим, что появилась настройка.
3.
Для обмена данными делаем следующее:
Сначала в базе, в которой были сделаны изменения, нажимаем на значок «Выполнить обмен по текущей настройке», как показано на рисунке.
После выгрузки появится окно результата выгрузки.
Потом в базе, в которую необходимо передать изменения, нажимаем на значок «Выполнить обмен по текущей настройке» и данные попадут в ту базу, в которую вы хотите.
2. Рассмотрим вариант с планом обмена «По организации».
Обмен будет, осуществляется по выбранным организациям, находящимся в распределенной информационной базе.
Для создание узлов распределенной базы в меню выбираем: Операции - Планы обмена. Откроется окно «Выбор объекта: План обмена».
Выберем план обмена «По организации». Откроется окно «План обмена По организации».
Заполняем две записи:
Первую запись назовем «Главный узел», код укажем «ГУ», видим отличие от «Плана обмена: Полный», появилась таблица, в которой указываем Организации по которым будет происходить обмен.
Вторую запись назовем «Подчиненный узел», код укажем «ПУ», указываем организации.
Во всем остальном настройка идет абсолютно аналогично с «Планом обмена: Полный».
Часто возникает ситуация, когда организация имеет несколько филиалов или торговых точек, территориально удаленных друг от друга. Тем не менее остается необходимость вести единый учет по всей организации. Одним из вариантов решения этой задачи является создание единой сети, в которую будут включены автоматизированные рабочие места всех филиалов, и размещение информационной базы 1С на общедоступном сервере. Этот способ может быть технически сложен и затратен. Кроме того, возникает ряд вопросов, связанных с информационной безопасностью.
Второй вариант — создание распределенной информационной базы (РИБ). Распределенная информационная база представляет собой иерархическую структуру, состоящих из отдельных информационных баз на платформе 1С:Предприятие, между которыми организован обмен данными с целью синхронизации конфигурации и данных. Эти отдельные информационные базы называются узлами РИБ.
Распределенная информационная база может быть создана на основе различных конфигураций системы 1С:Предприятие. Рассмотрим ее создание на примере 1С:Управление торговлей 10.3.
Допустим, в торговой организации открывается дополнительная торговая точка, в которой необходимо иметь доступ к общей торговой системе организации. Для создания РИБ необходимо выполнить следующие шаги:
На этом создание распределенной информационной базы завершено. Для обмена информацией необходимо запустить обмен данных в Центральной базе (выгрузятся изменения, которые произошли в ней), затем — в магазине (загрузятся изменения из центральной базы и выгрузятся изменения, произошедшие в магазине), и снова — в центральной базе (в нее загрузятся изменения, произошедшие в магазине).
Распределенные информационные базы имеют свой механизм разрешения коллизий. Так, если при проведении обмена выясняется, что какой-либо объект (документ, справочник и т.д.) был изменен и в главной, и в подчиненной базе, то приоритет будет иметь изменение, сделанное в главной базе.
При необходимости изменить конфигурацию распределенной информационной базы, это нужно делать в корневом узле (см. первый рисунок статьи), конфигурации остальных узлов заблокированы. После проведения необходимых изменений, их можно передать в подчиненные узлы с помощью стандартной процедуры обмена данными между узлами РИБ. После проведения обмена в конфигураторе подчиненного узла необходимо выполнить обновление конфигурации информационной базы.
Если у вас возникли проблемы с настройкой распределенной информационной базы, наши специалисты помогут вам настроить обмен данными и подробно объяснят, как его использовать.
В 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
Создание распределенной информационной базы и настройка
