Добрый день
Нужна помощь, чтобы спроектировать обмен между базами. Приведу упрощенный пример. Есть две баз: Источник, Приемник.
В приемнике работает несколько операторов - это разные магазины, работают с базой по удаленке. Каждый оператор инициирует свой обмен.

Вопрос:
Как организовать обмен, чтобы каждый оператор загружал только свои документы?
Если делать по классике, то при организации плана обмена в приемнике будет 2 узла: УзелПриемник(текущая база) и УзелИсточник без разделения по магазинам. Можно, конечно задействовать фильтры и при выборке изменений задавать к.л. образом третий параметр в методе ВыбратьИзменения, но пока четко не понятно как это сделать.

Коллеги, кто решал подобный вопрос? Какие способы задействовали?

это будет несколько планов тогда

сделать несколько баз, по количеству операторов, это логично же.

(2) нужно на существующей инфраструктуре обмен организовать

(3) тебе никто не мешает сделать несколько баз на существующей инфраструктуре. или на жестком диске нет нескольких десятков гигабайт дополнительно?

(4) > тебе никто не мешает
если бы

(5) а что мешает?

(6) несколько баз в одном магазине? а выручку как смотреть по магазину? остатки в кассе?

(7) пожалуйста, не говори за (0).
при учете в одном магазине не вижу необходимости обмена только "своими" документами

тем более в (0):
В приемнике работает несколько операторов - это разные магазины

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

(0) Не раскрыта конфигурация и платформа.

Платформа 8.3.5
Базу действительно разделить не получится - есть устоявшаяся большая система.
Интересно в частности, использовал ли кто успешно фильтрацию в выборке изменений при двустороннем обмене, т.е. с подтверждением доставки.

(12) На платформе 8.2 Общий реквизиты МестоНазначения и МестоСоздания. ДАё Написал РИБ. Столкнулись с пределом на том оборудовании около 1000 документов в час

(13) и фильтрация третьим параметром в методе ВыбратьИзменения?
туда ссылки самих объектов передавали?

хочу уточнить у ТС : вы понимаете, что в терминах и понятиях регистрации изменений в разных данных и по разным планам обменов получается допущение по использованию множества узлов обмена в одной базе, вплоть до того, что в одной и той же базе можно выполнить и отправку и получение пакета от одного к другому источник-приемник?

(15) слишком большое предложение - честно - не понял

(14)Фильтрация На узле РИБ ПриОтправкеПодчиненнному ПриОтправкеГлавному по указанным общим реквизитам.

(16) база отправитель > чем узел отправитель и точно так же приемник больше чем узел приемник. и отправитель и приемник могут сидеть одной и той же базе

(16) (15) Это про особенности платформы 8.3.3 и выше?

(18) и как эта возможность согласуется например с методом ЭтотУзел() ?

(12) это реально извращение. проблемы с подтверждением доставки, с фильтрацией. либо вообще исключить пользователя из обмена и обмениваться всей информацией, либо сделать количество подчиненных баз по количеству пользователей. зачем подпирать костыли другими костылями вместо убирания оных - мне не понятно.

(21) в платформе есть возможность фильтрации выборки изменений
почему использование типовых возможностей - это извращение?

(20) ЭтотУзел применяют в БСП - если хочется, то можно откорректировать, как тебе нужно, по выбранному пользователю, например. ЭтотУзел - это только отправитель

(22) выборка изменений и регистрация изменений делаются не по ЭтотУзел, а в адрес Получателя.

(22) при использовании этой фильтрации есть хорошая возможность выстрелить себе в ногу. Например:
зарегистрирован документ 1 и документ 2 одного вида метаданных.
выгружаем по фильтру документ 1. потом выгружаем по фильтру документ 2, затирая предыдущее сообщение. получаем подтверждение о выгрузке документа 1 и 2 (по номеру сообщений), вуаля, информация о изменениях документ 1 в центр не дошла.

И даже если номер сообщения обнулять, если ранее выгруженный документ не попал в фильтр, то он будет выгружен два раза, что также не очень хорошо, и ведет к повышенной нагрузке на базу.

(17) у меня не риб

(26) если не РИБ, извращайся вообще как хочешь

и несколько "этот узел" не надо

(26) а если не РИБ, так тем более, нет никакого ЭтотУзел()

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

(0) "Возможны ли несколько ЭтихУзлов в плане обмена?" - нет, невозможно. Но, если у Вас несколько различных планов обмена, то в каждом из них есть только один уникальный предопределенный узел, соответствующий этой базе данных. Другими словами, для каждого конкретного плана обмена значение ЭтотУзел() - уникально.

Зачем обмен инициировать?
Запустил по расписанию. Обмен под особым пользователем, по результатам все магазины увидят только свои документы.

Ну или просто пользователю дать запускать только регл. задание по обмену.

(31) по расписанию не получится, там особая схема

(29) вы реализовывали подобное?
вижу, что мханизмы, о которых вы пишите используют функцию ЭтотУзел, как минимум, для формирования имени файла обмена

(33) А религия запрещает изменить строковое значение Отправителя, получаемое из кода Узла из объекта ЭтотУзел?

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

Что нужно в задаче сделать? Есть условное множество Получателей, для которых надо определять, чего им отдавать из Источника. Это делается, да, но уже не автоРегистрацией в составе объектов метаданных из плана обмена, а по Подписке на событие "при записи", например, в которой определяется на какой узел или массив узлов нужно зарегать текущий объект в подписке. Затем, перед отправкой, по расписанию или по пользовательскому желанию, дергается НастройкаОбмена, в которой есть ссылка на узел Получатель. По получателью выбираются данные и в пакет, в отправку.

Если же Вам серьезно нужно принимать в одной и той же базы РАЗНЫЕ по именам входящие пакеты, то и это делается. Еси совсем штатно, то там явно можно указать путь, имя файла для выполнения обмена. Все можно настроить. Там жесткой привязки нет. Даже в РИБ жесткость привязки к базам используется только в одном месте, где подставляется в пакет инфа о конфигурации отправителя из ГлавногоУзла И все.

Кстати, если РИБ не используется, то и ГлавногоУзла (но я точно не помню как оно там именовано) в обмене нет. Там все равно куда отправлять по иерархии вверх или вниз

(34) я написал про этот узел исходя из ваших слов:

"а если не РИБ, так тем более, нет никакого ЭтотУзел()
Если для обмена юзаются типовые механизмы через справочник НастройкиОбмена и НастройкиВыполненияОбмена, то там четко указываются и Отправитель и Получатель"

Но там используется ЭтотУзел, и в настройках не указывается Отправитель

Так вы делали сами подобный обмен?

(35) Подобный, это какой? Где в имени пакета (при установке имени файла) нужно установить нужный суффикс? Делал. И говорю еще раз - не критичен имя или код узла отправителя. Хоть ты его из ЭтотУзел возьмешь, хоть сам припишешь от балды.

(36) обмен, когда в приемнике больше одного узла (этот узел) являются приемниками

(37) сейчас гляну в конфиге, абстрагировано там сделано, или связано с ЭтотУзел. По моему, там в Настройках выбирается сразу конкретный тип: ПланОбмена такой-то, затем Конкретный Узел обмена. И дальше работа с разбором пакетов идет со ссылкой на узел. А данные просто пишутся в базу, без какого-либо различия для какого узла они были получены.

Но это надо глянуть... Когда и если пользоваться типовыми инструментами, то надо глянуть.

В общем решили вопрос, используя несколько узлов в Источнике и только один соответвтующий узел в Приемнике. Но это, конечно не типовой обмен.