Доброго дня!
Возможно ли организовать передачу изменений конфигурации с обычным обменом, как этой сделано в РИБ?

Есть существующие базы с идентичными конфигурациями с данными, которые надо объединить в общую схему работы.

Что вообще правильнее - слить все данные в 1 большую базу и сделать РИБ как по мануалу или есть возможность сделать нормально РИБ на уже существующей связке баз?

Если ВСЕ UID-ы всех элементов одинаковые (включая перечисления и т.д.) то можно и слить и настроить распределенку.

На практике (если не используется РИБ) это редкость...

(0) Правильнее слить в одну общую базу с синхронизацией НСИ
А уже затем настраивать РИБ

(2) А если взять обычный план обмена с правилами КД - можно заставить этот механизм отдавать/применять изменения конфигурации как в механизме РИБ?

(1) В-целом нужен обмен по правилам и синхронизацию изменений конфигураций (изначально конфы одинаковые) уже работающих баз. Копаю в сторону РИБ, но чем дальше тем больше вопросов :)

(3) если "изначально конфы одинаковые"

есть база 1 и 2

выгрузить cf и сравнить если одникавые



создать префиксы справочников и документов для каждой из баз
сделать перенумерацию

выбрать самую жирную и сделать из нее Центральную базу
с кодом 00001
добавить еще одну базу 00002
(снять всю регистрацию)

выбрать другую базу сделать
тоже самое
поменять местами узлы из ЦБ сделать ПБ

сделать пробный обмен.

....продолжение следует

(3) можешь их подключить к одному хранилищу и регламентом накатывать конфу...

но это чревато проблемами

(5) хранилище невариант к сожалению
(4) это будет "легкая" жопа, + нет необходимости чтобы данные в полном объеме ходили между базами. Т.е. нужны правила регистрации и обмена...

"Возможно ли организовать..."(0) - возможно. Можно программно в обмен данными добавлять любую информацию. Конфигурацию, выгруженную в файл CF, например, можно добавлять по аналогии с предопределенными данными, как это уже реализовано в РИБ (внутриплатформенный механизм РИБ это автоматически не делает).

"нет необходимости, чтобы данные..."(6) - попробуйте удалить из состава плана обмена РИБ все данные - тогда, имхо, будет мигрировать только конфигурация.

Но прежде чем что-либо делать, нужно через сравнение/объединение убедиться, что конфигурации у Вас реально идентичные.

(6) а, только сейчас понял
тебе нужно , чтобы только изменения конфы мигрировали

проще простого

в правилах обмена дописать при выгрузке удалять всю регистрацию узла

и объединить все в РИБ - "гулять будут" только изменения структуры конфигурации

(8) Дада
Особенно будет весело на предопределенных

(9) Там ничего интересного, достаточно всего лишь внести точечное изменение в алгоритм:

Процедура ЗаписатьПриоритетныеИзмененияВСообщениеОбмена(Знач ЗаписьСообщения)
    
    // Записываем элемент <Parameters>
    ЗаписьСообщения.ЗаписьXML.ЗаписатьНачалоЭлемента("Parameters");
    
    Если ЗаписьСообщения.Получатель <> ПланыОбмена.ГлавныйУзел() Тогда
        
        // Выгружаем приоритетные данные обмена (предопределенные элементы).
        ПриоритетныеДанныеОбмена = ОбменДаннымиСлужебный.ПриоритетныеДанныеОбмена();
        
        Если ПриоритетныеДанныеОбмена.Количество() > 0 Тогда
...

(7) т.е. в-целом можно заставить програмно с планом обмена в сообщении из главной базы передавать изменения конфигурации (ну кроме самих данных), а в базе приемнике их накатывать "как накатывается в РИБ"?

Конфы в обеих базах накатываются одним CF-ником

(8) 1. нужны изменения конфы из главной базы
    2. нужны данные согласно правилам

(10) Ты вероятно не понял, я про дублирование

(12) А мне кажется, что я всё правильно понял. Сам по себе платформенный механизм РИБ не синхронизирует и не контролирует предопределенные данные, а дубли, теоретически, могут возникнуть только в режиме загрузки данных (ОбменДанными.Загрузка = Истина) - если нет обмена данными, то и предопределенные данные не будут циркулировать в обмене данными. Поэтому, имхо, достаточно "заблокировать" принудительную программную синхронизацию предопределенных данных алгоритмом типовой конфигурации из (10).

(13) Дубли когда два (и более) элемента имеют одно ИмяПредопределенныхДанных это ладно
Сами имена предопределенных в конфигураторе после слива двух конф запросто задублятся
И с прочим могут быть проблемы

Имхо сливать конфу и принудительно засовывать две разные базы в РИБ - совершенно не по феншую
Правильно создать пустую чистую базу той же конфы, настроить ее как надо со всеми почищенными НСИ из двух баз
И выгрузить в нее данные (из имеющихся баз) с подменой ссылок НСИ на почищенные
Обратить внимание на РС, чтобы там дублей не было после слива

На скрине пример кривого РИБа, когда "платформенный механизм РИБ не синхронизирует и не контролирует предопределенные данные"

(14)+ Конечно всегда есть вариант ХХП
Когда сливаем как нибудь
А потом начинаем чистить дубли, с пометкой на удаление и заменой ссылок
Что в случае нескольких РИБ баз нехилый такой трындец
Когда ты заменяешь-удаляешь - а они снова по РИБ лезут ))

Коллеги, обе базы хоть и имеют одинаковую конфигурацию, однако работают уже некоторое время и наполняются данными.

Просто изначально не заложили архитектуру их связности, а теперь пришло время этим заниматься.

(14) Ещё раз попробую достучаться до Вас. Обратите внимание на строку " Если ЗаписьСообщения.Получатель <> ПланыОбмена.ГлавныйУзел()(10) и "а дубли, теоретически, могут возникнуть только в режиме загрузки данных"(13). То, что Вы указали на скрине - это печальный итог работы типового алгоритма.

"Сами имена предопределенных в конфигураторе после слива двух конф запросто задублятся" - нет.
"На скрине пример кривого РИБа" - нет.

Дублирование предопределенных не имеет никакого отношения непосредственно к работе механизма обмена данными. Данный механизм всего лишь выявляет и обостряет уже ранее возникшую проблему. РИБ - это не первопричина проблемы, а следствие. В качестве подтверждения могу сказать, что за более чем двадцать лет работы с базами РИБ, с дублированием предопределённых я встречался всего лишь несколько раз, достаточно пальцев одной руки.

Впрочем, вышесказанное Вы и сами подтверждаете, когда говорите "Когда ты заменяешь-удаляешь - а они снова по РИБ лезут" - РИБ косвенно виновато лишь в том, что "распространяет" возникшую проблему по узлам.

Имхо, мы отвлеклись, как мне кажется, от темы.

Задублирование предопределенных свойственно не только лишь для РИБ - достаточно, например, ознакомиться с информацией по ссылкам https://its.1c.ru/db/metod8dev#content:5367:hdoc и  https://infostart.ru/1c/articles/295750/ чтобы понять, что эта проблема выходит за рамки РИБ.