есть 20 узлов обмена. в каждом из узлов может быть один из двух признаков или оба сразу.

в справочнике(Номенклатура) у группы может быть один из двух признаков или оба сразу. Соответственно если у группы хотя бы один из признаков пересекается с признаком узла - то она должна в него выгрузится.
Элементы выгружаются по признаку первого родителя.

Как лучше (или правильнее) это реализовать.
Нужно в правилах обмена это прописать? или модуле плана обмена?

1. Типовой обмен правишь или свой план обмена с нуля?

2. Вы точно обладаете опытом и получаете заявленную зарплату для подобных вопросов?

1. Свой план обмена из БСП.

2. Вот решил заполнить пробел в знаниях и поковырять КД и ПО - ибо как то все то спроса не было, то времени разбираться. А сейчас попалась задача - решил не изобретать велосипеды - а сделать по канонам.

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

Если на основе БСП то логичнее в правилах, но если в модуле то это будет быстрее работать.
Короче номенклатуры сколько всего будет? Если очень много то только в модуле ибо правилами оно помирать будет.

по канонам БСП - это уже разные версии, с несовпадающими подходами :-)

Если не цепляться за каноны, то самое простое - регистрация элемента выполняется в обработчике подписки на событие ПриЗаписи, а в состав объектов плана обмена текущие метаданные должны быть включены без авторегистрации.

(3) Номенклатуры овер 100000

Когда в свое время писал нетленку то пришлось даже планы обмена не использовать для одного справочника (огромного сотни тысяч, со временем до миллиона элементов) и ваять свою отдельную выгрузку-загрузку на основе DBF файлов и работе с УИД.

Потому что иначе обмен через XML тупо подыхал, когда эти сотни тысяч обновленных записей (пару раз в месяц присылали извне обновления пациентов для льготных рецептов) пытались в XML.

(5) А меняться она как часто будет?

(4) Ну именно так в БСП и написано.

(7) Ну нет меняться не очень часто - это каталог ЗИП для судов.

(4) 20 узлов и ПриЗаписи начнутся легкие тормоза при проверке признаков

(9)+ А если >100 узлов то проверка надо ли засовывать (регистрировать для него) в каждый конкретный узел и мы приехали.

(8) так если так, как и написано, то в обработчике подписки должно быть подцеплено правило регистрации объекта. Дописываешь в правиле проверку нужных условий и все.

(9) отсюда не видно, насколько критично будет поведение, при выборке одного из 20 узлов запросом для проверки правила. И тем более не видно, каким алгоритмом будет выполнятся проверка.

з.ы. Можно отключить интерактивную регистрацию принципиально и ставить куда-то отметку, запись в РС на отложенную обработку эпизодическим регламентным заданием или непосредственно перед выгрузкой в обмен.

(10)  Ну чисто интуитивно я  что то такое и подозревал.

И что тогда?  Лезть в модуль плана обмена и там ставить фильтр уже в "ПриОтправкеДанныхПодчиненному" - правильно?

(11) Последнее зы тоже подумал.

(12) Можно, но как лучше заранее без реальных тестов хз

(12) я бы сделал на крайний случай как в 11 в з.ы. написал.

ЗИП для судов - это для комплектации техобслуживания в морском транспорте?

(14) Тут зависит как часто обмен и как часто запись элементов справочника, что лучше.
Если обмен раз в день и время не ограничено на него (по ночам например) в ЦБ, а элементы когда пишут тормоза недопустимы ибо юзеров в ЦБ много.

Фоновым-регламентных кста хорошее решение, но если вумный админ его отрубит или произойдет сбой, то будет весело ))
Короче риск ошибок возрастает и усложнение системы.

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

(14) ЗИП - это просто наименования ЗИПа в номенклатуре - что бы специалисты с судов могли заказать нужные наименования, нужных артикулов к нужному оборудованию. В обратку с узлов убдет прилетать 1 документ. Номенклатуру в узлах создавать запрещено.

(17) Как насчет вынесения справочника ЗИП наружу и загрузку по необходимости?
Т.е. некий внешний сервис который позволяет поиск и заполнение внутреннего справочника, тогда нет проблем создавать на узлах.

Как в типовых со многим сделано. А в центральном можно и вручную править.

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

Ну и дальше, надо составить для себя схему - вот пометили Элемент на все любые узлы, а он нужен только для одного узла, если проверка настроена непосредственно в модуле плана обмена, то что он в каждой выгрузке будет проверяться?

(19) Угу в каждой, но если не надо то регистрацию убираем при выгрузке.

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

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

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

(21) При записи или перед записью?

(23) Да думаю для задачи в рамках этой темы такое решение вполне пойдет.
Узлов мало, справочник редко перезаписывают, условие относительно простое поэтому нет смысла сильно оптимизировать.

(25)+ Но вот при начальном заполнении этих 100 тыщ элементов будет прикольно.

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

И самый прикол если поменяли для узла "признаки", надо как то перебрать всю номенклатуру и заново ее переотправить по условию.

И это удалять если уже не нужна она на узле по измененным условиям ))

(23) Правильно ли я понимаю.
В подписке запросом выбрать список узлов удовлетворящих условию и зарегистрировать в них.
ПланыОбмена.ЗарегистрироватьИзменения(СписокУзлов, Источник.Ссылка);

Стандартную процедурру  ОбменДаннымиСобытия.МеханизмРегистрацииОбъектовПередЗаписью - отменить.


(26) Без условий -в тестовый узел час почти выгружался. 2 гига ХМЛ весит

(27) Чисто теоретически - это же можно сделать интерактивно?

(24) В идеале - после записи
Но на практике - Подписка на событие При записи срабатывает уже в самом конце транзакции, которую устанавливает платформа, т.е. когда практически точно платформа знает, что транзакция успешна

(28) > Без условий -в тестовый узел час почти выгружался. 2 гига ХМЛ весит
Создай 20 узлов с разными признаками и попробуй в пустой справочник загрузить 100 тыщ элементов, когда проверка в ПриЗаписи.

>Чисто теоретически
Можно все что угодно, на практике же могут быть разные интересные моменты

(30)  обмен по номенклатуре односторонний - по идее в узле получателе - я не буду этого проверять.

(31) на стороне получателя вообще должна быть отключена регистрация

и нужна еще дополнительная процедура на центральной базе, которая может без перезаписи элементов помечать их на списки узлов обмена

не процедура, а обработка какая-то

Ладно общую канву я уловил. Спасибо участникам за советы.

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

(36) Там задача скорее обратная - что бы на узлах ни в коем случае ничего не создавали.

(37) Так им создавать (точнее переносить готовые из внешнего причем с тем же УИД) можно будет только готовое.
Можно сделать по принципу дисконтного сервера.
В конфе есть отдельный полный справочник которые не ходит по риб, но расшарен через веб-сервисы.

(38)+ Если с инетом плохо то пусть этот редко обновляемый полный в каждом узле или внутри базы, или отдельным файлом, например банальным DBF или еще как.

(39) ну если обмен будет реально тормозить можно будет поэкспериментировать.

В конец концов - сейчас вообще заказы прилетают в текстовых файликах. А каталог в полуручном режиме 1-2 раза в год обновляется в 7ых базах.

(40) Ну да в (6) я описал как пришлось извращаться в свое время чтобы обмен не тормозил, но при этом можно было оперативно несколько записей обновить если надо.

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