Методика разработки РИБ в БП 3.0 для передачи только структуры в периферию #790953

Коллеги, был ли у вас опыт создания РИБ для БП 3.0, чтобы в периферию передавалась только структура? И чтобы каждая периферийная база далее работала автономно. Я так понимаю, что это неочевидная задача. В частности из-за того что обновления данных при запуске базы используют условия Главный ли это узел или нет, т.е. базы уже становятся неавтономными. Понимаю, что РИБа здесь как такового нет и можно обойтись без него. Но все таки. Кто делал такую задачу? Какая общая методика по созданию такой РИБ?

Для передачи конфигурации в удаленные инфобазы РИБ не нужен

Передача файла + пакетный режим конфигуратора спасет тебя

Эээ... не совсем полный перечень. Если есть обработки обновления данных в режиме "1С:Предприятие", то потребуется выполнение внешней обработки, которая запустит сеанс, инициализирует выполнение этих обработок и завершит сеанс работы.

+ и всё это желательно проделать во время, когда юзверей нет в базе (намекаю на планировщик заданий)

А если рассмотреть в моей формулировке?

Не получится скорее всего. Если очистить состав плана обмена РИБ, то будет "мигрировать" только изменение конфигурации. Т.е, казалось бы то, что тебе и надо. Но такой номер "проходит" только на платформах до 8.3. Есть одна мелочь в актуальных конфигурация: если в составе плана обмена не будет объектов, то не будут мигрировать те изменения данных, которые в РИБ делаются при обновлении только в центральном узле, а в подчинённые узлы - поступают/мигрируют с обменом. На вскидку, могу предположить возникновение проблем при изменении предопределенных данных (их рассинхронизация).

Да, с предопределенными данными точно возникнут проблемы. В переферийных узлах они не создаются автоматически. Правда, это можно переопределить, и они таки будут создаваться, но это может привести к потенциальной проблеме. А так сделать это не сложно - достаточно переписать правила регистрации так, чтобы ни один объект не регистрировался к обмену.

Да, завязок там немало на главный узел

структура конфигурации это же не только метаданные объектов, модули и формы, обработки или отчеты. Это еще толпа преопределенных значений разного типа. Справочники, План счетов, виды расчетов. Понятно, что соблазн большой, получить базу клон, но очищенный от всякой всячины... Если создавать новую базу из шаблона, например, а затем выгрузить туда справочник со ссылками в реквизитах на предопределенные элементы - в приемнике образуются дубли. Т.е. клонируемую базу надо заготовить либо уничтожением всех неактуальных для клона данных в текущей, либо хранить копию чистой базы от момента начала учета. Второй способ мало эффективен на практике, т.к. базу, в которой ведется учет, регулярно подвергают обновлениям конфигурации, что может привести к появлению новых предопределенных элементов. Таким образом, только копировать чистую, а затем чистить. Но дубли после обновлений конфига и обменов за ними все равно будут появляться. В зависимости от того, как часто добавляют предопределенные в обновляемые конфиги.