Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Ограничение выгрузки элементов справочника в зависимости от узла плана обмена

Ограничение выгрузки элементов справочника в зависимости от узла плана обмена
Я
   Sasha_1CK
 
07.04.19 - 11:15
есть 20 узлов обмена. в каждом из узлов может быть один из двух признаков или оба сразу.

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

Как лучше (или правильнее) это реализовать.
Нужно в правилах обмена это прописать? или модуле плана обмена?
 
 
   Garykom
 
1 - 07.04.19 - 11:34
1. Типовой обмен правишь или свой план обмена с нуля?

2. Вы точно обладаете опытом и получаете заявленную зарплату для подобных вопросов?
   Sasha_1CK
 
2 - 07.04.19 - 11:48
1. Свой план обмена из БСП.

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

З.Ы. Обмены не единственная область программирования за которую платят.
   Garykom
 
3 - 07.04.19 - 11:52
Если на основе БСП то логичнее в правилах, но если в модуле то это будет быстрее работать.
Короче номенклатуры сколько всего будет? Если очень много то только в модуле ибо правилами оно помирать будет.
   Фрэнки
 
4 - 07.04.19 - 11:54
по канонам БСП - это уже разные версии, с несовпадающими подходами :-)

Если не цепляться за каноны, то самое простое - регистрация элемента выполняется в обработчике подписки на событие ПриЗаписи, а в состав объектов плана обмена текущие метаданные должны быть включены без авторегистрации.
   Sasha_1CK
 
5 - 07.04.19 - 11:54
(3) Номенклатуры овер 100000
   Garykom
 
6 - 07.04.19 - 11:56
Когда в свое время писал нетленку то пришлось даже планы обмена не использовать для одного справочника (огромного сотни тысяч, со временем до миллиона элементов) и ваять свою отдельную выгрузку-загрузку на основе DBF файлов и работе с УИД.

Потому что иначе обмен через XML тупо подыхал, когда эти сотни тысяч обновленных записей (пару раз в месяц присылали извне обновления пациентов для льготных рецептов) пытались в XML.
   Garykom
 
7 - 07.04.19 - 11:57
(5) А меняться она как часто будет?
   Sasha_1CK
 
8 - 07.04.19 - 11:58
(4) Ну именно так в БСП и написано.

(7) Ну нет меняться не очень часто - это каталог ЗИП для судов.
   Garykom
 
9 - 07.04.19 - 11:59
(4) 20 узлов и ПриЗаписи начнутся легкие тормоза при проверке признаков
   Garykom
 
10 - 07.04.19 - 12:00
(9)+ А если >100 узлов то проверка надо ли засовывать (регистрировать для него) в каждый конкретный узел и мы приехали.
 
 Рекламное место пустует
   Фрэнки
 
11 - 07.04.19 - 12:06
(8) так если так, как и написано, то в обработчике подписки должно быть подцеплено правило регистрации объекта. Дописываешь в правиле проверку нужных условий и все.

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

з.ы. Можно отключить интерактивную регистрацию принципиально и ставить куда-то отметку, запись в РС на отложенную обработку эпизодическим регламентным заданием или непосредственно перед выгрузкой в обмен.
   Sasha_1CK
 
12 - 07.04.19 - 12:06
(10)  Ну чисто интуитивно я  что то такое и подозревал.

И что тогда?  Лезть в модуль плана обмена и там ставить фильтр уже в "ПриОтправкеДанныхПодчиненному" - правильно?
   Garykom
 
13 - 07.04.19 - 12:07
(11) Последнее зы тоже подумал.

(12) Можно, но как лучше заранее без реальных тестов хз
   Фрэнки
 
14 - 07.04.19 - 12:08
(12) я бы сделал на крайний случай как в 11 в з.ы. написал.

ЗИП для судов - это для комплектации техобслуживания в морском транспорте?
   Garykom
 
15 - 07.04.19 - 12:10
(14) Тут зависит как часто обмен и как часто запись элементов справочника, что лучше.
Если обмен раз в день и время не ограничено на него (по ночам например) в ЦБ, а элементы когда пишут тормоза недопустимы ибо юзеров в ЦБ много.
   Garykom
 
16 - 07.04.19 - 12:18
Фоновым-регламентных кста хорошее решение, но если вумный админ его отрубит или произойдет сбой, то будет весело ))
Короче риск ошибок возрастает и усложнение системы.
   Sasha_1CK
 
17 - 07.04.19 - 12:22
(15)  Да обмен скорее всего редко. несколько раз в день Номенклатура прирастает относительно мало.

(14) ЗИП - это просто наименования ЗИПа в номенклатуре - что бы специалисты с судов могли заказать нужные наименования, нужных артикулов к нужному оборудованию. В обратку с узлов убдет прилетать 1 документ. Номенклатуру в узлах создавать запрещено.
   Garykom
 
18 - 07.04.19 - 12:26
(17) Как насчет вынесения справочника ЗИП наружу и загрузку по необходимости?
Т.е. некий внешний сервис который позволяет поиск и заполнение внутреннего справочника, тогда нет проблем создавать на узлах.

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

Ну и дальше, надо составить для себя схему - вот пометили Элемент на все любые узлы, а он нужен только для одного узла, если проверка настроена непосредственно в модуле плана обмена, то что он в каждой выгрузке будет проверяться?
   Garykom
 
20 - 07.04.19 - 12:28
(19) Угу в каждой, но если не надо то регистрацию убираем при выгрузке.
   Фрэнки
 
21 - 07.04.19 - 12:30
(20) время записи элемента в регистрацию каждого узла обмена намного больше, чем время отработки проверки условия, нужна регистрация по узлу или нет в обработке подписки для события при записи
   Garykom
 
22 - 07.04.19 - 12:32
(21) Неа время записи в регистрацию это функция платформы (очень быстро), а проверка условия зависит от ее сложности и не платформой непосредственно а запрос/код выполняется.
   Фрэнки
 
23 - 07.04.19 - 12:40
(22) ну не знаю.
Я проверял в своих случаях на замерах производительности и видел, что не очень быстро, а сопоставимо по времени с любой записью в базу без только лишних типовых обработчиков событий. Поэтому, после анализа производительности, остановился на варианте с процедурой выборки в список нужных для записи узлов из плана обмена, а затем регистрации только по этому списку.
   Sasha_1CK
 
24 - 07.04.19 - 12:43
(21) При записи или перед записью?
   Garykom
 
25 - 07.04.19 - 12:44
(23) Да думаю для задачи в рамках этой темы такое решение вполне пойдет.
Узлов мало, справочник редко перезаписывают, условие относительно простое поэтому нет смысла сильно оптимизировать.
   Garykom
 
26 - 07.04.19 - 12:45
(25)+ Но вот при начальном заполнении этих 100 тыщ элементов будет прикольно.

Ну и предусмотреть что будет когда новые узлы создаем, как туда нужные зарегаются то.
   Garykom
 
27 - 07.04.19 - 12:48
И самый прикол если поменяли для узла "признаки", надо как то перебрать всю номенклатуру и заново ее переотправить по условию.

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

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


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

(27) Чисто теоретически - это же можно сделать интерактивно?
   Фрэнки
 
29 - 07.04.19 - 12:53
(24) В идеале - после записи
Но на практике - Подписка на событие При записи срабатывает уже в самом конце транзакции, которую устанавливает платформа, т.е. когда практически точно платформа знает, что транзакция успешна
   Garykom
 
30 - 07.04.19 - 12:56
(28) > Без условий -в тестовый узел час почти выгружался. 2 гига ХМЛ весит
Создай 20 узлов с разными признаками и попробуй в пустой справочник загрузить 100 тыщ элементов, когда проверка в ПриЗаписи.

>Чисто теоретически
Можно все что угодно, на практике же могут быть разные интересные моменты
   Sasha_1CK
 
31 - 07.04.19 - 12:58
(30)  обмен по номенклатуре односторонний - по идее в узле получателе - я не буду этого проверять.
   Фрэнки
 
32 - 07.04.19 - 13:02
(31) на стороне получателя вообще должна быть отключена регистрация
   Фрэнки
 
33 - 07.04.19 - 13:04
и нужна еще дополнительная процедура на центральной базе, которая может без перезаписи элементов помечать их на списки узлов обмена
 
 
   Фрэнки
 
34 - 07.04.19 - 13:04
не процедура, а обработка какая-то
   Sasha_1CK
 
35 - 07.04.19 - 13:08
Ладно общую канву я уловил. Спасибо участникам за советы.
   Garykom
 
36 - 07.04.19 - 13:09
Ну лично я не стал бы заморачиваться с этим запутанным условным обменом а сделал полную миграцию.
Но кол-во элементов в справочнике сократил с помощью (18) чтобы там были у всех но только реально требуемые.
   Sasha_1CK
 
37 - 07.04.19 - 13:10
(36) Там задача скорее обратная - что бы на узлах ни в коем случае ничего не создавали.
   Garykom
 
38 - 07.04.19 - 13:12
(37) Так им создавать (точнее переносить готовые из внешнего причем с тем же УИД) можно будет только готовое.
Можно сделать по принципу дисконтного сервера.
В конфе есть отдельный полный справочник которые не ходит по риб, но расшарен через веб-сервисы.
   Garykom
 
39 - 07.04.19 - 13:14
(38)+ Если с инетом плохо то пусть этот редко обновляемый полный в каждом узле или внутри базы, или отдельным файлом, например банальным DBF или еще как.
   Sasha_1CK
 
40 - 07.04.19 - 13:18
(39) ну если обмен будет реально тормозить можно будет поэкспериментировать.

В конец концов - сейчас вообще заказы прилетают в текстовых файликах. А каталог в полуручном режиме 1-2 раза в год обновляется в 7ых базах.
   Garykom
 
41 - 07.04.19 - 13:22
(40) Ну да в (6) я описал как пришлось извращаться в свое время чтобы обмен не тормозил, но при этом можно было оперативно несколько записей обновить если надо.

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


Список тем форума
Рекламное место пустует  Рекламное место пустует
Компьютеры — это как велосипед. Только для нашего сознания. Стив Джобс
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует