Вход | Регистрация
 
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 или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.