РИБ и планы обмена (как или какой иной вариант)? #563130

С одной и той же конфигурацией программы планируется осуществлять работу в 3-х уровневой структуре: - "филиал" (у каждого филиала своя база данных, вводится своя учетная инфа в раскиданных территориально филиалах у которых отсутствует постоянный канал связи) - "контроль" Филиалам назначаются кураторы, у каждого куратора своя сводная база по закрепленным за ним филиалами. В основном работа на просмотр, результаты незначительных изменений данных кураторами должены идти в базу конкретного филиала, с которым связано изменение. - "центральный офис" - в базу центрального офиса должна стекаться вся информация из кураторских баз. Какие варианты организации такой структуры могут быть?

гз

гз2

всем пофигу или никто не хочет мозг ломать:) ? Может, кто-чего посоветует по сабжу, все-таки?

ужас, одинесники не пишут...

А в чем проблема. Обмен центр филиал - полный Обмен филиал - куратор по организациям

ну просто типовой обмен по организациям используй, чего ты паришься.

мне просто не понятно следующее: - создам я РИБ (центральный узел - центральный офис) - отпочкую базу куратору - из базы куратора отпочкую базы для подчиненных ему филиалов Правильно?

база не типовая

2 и что?

У нас примерно так все и работает. План обмена с фильтром по организациям написали свой, взяв за основу аналогичный из конфигурации Бухгалтерия 2.0

просто никогда не сталкивался с такими вопросами. "План обмена с фильтром по организациям написали свой" - это значит, что файл выгрузки формируете полностью из языка системы, а не возможностями по умолчанию?

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

и забыл: 3) данные, к которым фильтр применить нельзя, то есть общие данные типа справочника "Банки", и так далее

спасибо

добавил в подчиненном узле в хранилище значения документ ворда, принял пакет в главном узле. Документ ворда перенесся. Неужели 1С полноценно переносит ХранилищеЗначений через планы обмена?

а почему нет? Регламентированные отчеты ведь гоняет.

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

т.е. снять галку в плане обмена "Авторегистрация" и при записи объекта определять по ситуации в какой узел он должен пойти, а в какой нет? И, соответственно, регистрировать либо не регистрировать?

Да, так методически правильнее, но, во-первых, в этом случае база будет чуть-чуть тупить при наступлении события ПередЗаписью объекта, а в указанном выше - сильно тупить при выгрузке в подчиненную базу. Имхо, в сумме так на так получается. Во-вторых, если убрать эти фильтры, то в подчиненный узел могут "уехать" данные другой организации (если какой-нибудь шутник пометит их как зарегистрированные). И потом ищи их там и выгребай :) А в-третьих, если при фильтрации попадаются данные по другой организации, то они не просто фильтруются, а в подчиненный узел команда на удаление этого объекта. Это на случай, если состав организаций узла поменялся и надо перезалить данные в один и вычистить другой.

Да, именно так. При наступлении события ПередЗаписью определяется, для каких узлов регистрируется изменение этого объекта. Список узлов, по-моему, определяется в свойстве "ОбменДанными.Получатели".

2 как и сделано в типовых...

Можно не снимать. Свои плюсы/минусы. Механизм один и тот же - редактирование списка получателей при записи объекта. И в обеих случаях появляется трабла - при создании начального образа в образ зафигачаться все объекты с авторегистрацией без учета подписок. Я оставлял авторегистрацию, а при выгрузке начального образа фильтровал. Без авторегистрации придется регистрировать полностью самому, иначе в образ ничего не попадет. Хотя можно поднять образ, а уже потом отправить туда чего надо. Также без авторегистрации придется где-то хранить список объектов потенциально участвующих в обмене 1) нифига не то на то. При большом количестве узлов и изменений и частых обменах "сильно тупить при выгрузке в подчиненную базу" превращается в лавинообразную нагрузку на сервер. 2) оригинальный аргумент. Точно так же всё уедет если убрать фильтры из ПриОтправкеДанныхПодчиненному :) 3) это доп. костыль, без которого вполне можно обойтись

Спасибо за ответы. Еще вопрос. Есть Куратор1 со своей сводной базой по закрепленным за ним филиалам. Ему грузится Филиал1, Филиал2, Филиал3. Филиал4 находится у Куратор2. Вдруг, Филиал4 решают отдать на Куратор1. Или наоборот, Филиал3 забрали у Куратор1. Какой выход можно придумать в данной ситуации?

1) если долгие обмены, то полностью согласен, надо резать лишний функционал. Только аккуратно. 2) вообще-то я это и написал:) 3) можно обойтись или нельзя - решает заказчик.   самое простое - пересоздать Филиал4 или Филиал3, предварительно заполнив по каким организациям они работают, и не забыв эти же организации заполнить у Кураторов. После этого отправить созданный образ в Филиал4 или 3, вместо старой базы.

Это не должна быть частая ситуация. Малой кровью она не решается. 1) самый простой этап - изменить правила миграции, чтобы изменения по филиалу теперь шли к новому куратору (иерархию узлов я делал в отдельном справочнике, мигрирующем везде). 2) так или иначе нужно засандалить данные филиала к новому куратору 3) так или иначе нужно удалить данные филиала у старого куратора Я проблемы схожие с 2) и 3) решал вручную. 2) - обработками регистрировал изменения для нужных объектов 3) - обработками вычищал ненужные данные (предварительно отключив обменки и вычистив в конце таблицы изменений)

3) В части задач, которые должны быть решены - да. А это не задача. Это костыль конкретной реализации, без которого можно обойтись. Под обойтись я подразумевал не забить на него, а сделать его ненужным.

Да вот не обойтись без него в моих задачах... К примеру, надо перетащить данные по организации из одного узла в другой. У меня также реализован справочник иерархии, доступный во всех узлах. Вносишь в него желаемые изменения, и в самом верхнем узле регистрируешь изменения для всех данных по указанной организации. После этого данные сами расползутся куда надо и сотрутся откуда надо, без геморроя с обработками регистрации в каждом узле. Случается это часто, организаций  - 92.   Я проверил скорость создания начальных образов с этим костылем и без него на нескольких выгрузках одной и той же базы. Средний результат - 3 минуты и 3 минуты соответственно. Что-то подсказывает мне, что это не он сильно грузит сервер:)   Другое дело, когда сокращаешь число узлов-получателей, к примеру, с 30 узлов-розничных магазинов до 1, реализовав твой алгоритм. Тогда число обращений к событию ПриОтправкеДанныхПодчиненному падает в 30 раз и трудно не заметить рост производительности. Конкретно нас спасает то, что узлов-соседей не больше 4 пока в каждом узле. Дальше придется допиливать...

О! Теперь ты озвучил задачу - легкость переброски организаций. Дык аналогичную шнягу несложно организовать и по-другому. Например, при регистрации в верхнем узле изменений всех данных по указанной организации, одновременно генерить регистрацию их удаления для старого узла. Это же разовая операция. Каждый раз проверять "на всякий случай" - впустую расходовать ресурсы.

Да, именно легкость, простота и изящество :) И чтобы даже тупой юзер с админскими правами (бывают, к сожалению, и такие) ничего там случайно не испортил. Старый узел может лежать на 3 уровня ниже верхнего узла и непосредственно для него не получится указать регистрацию удаления. Только для непосредственно подчиненного, а это уже криминал :) ибо тогда сотрутся данные по организации из всех узлов этой ветки иерархии. Согласен, что по своей сути эта проверка "на всякий случай". Но она практически не ест системные ресурсы, так зачем же ее убирать? P.S. Она реализована в типовой Бухгалтерии 2.0, также как и твой алгоритм. Мне кажется эта связка должна работать довольно быстро и практически без потери скорости.

Какая связка? Не будет это в связке работать. Ведь на выгрузку в старый узел данные по новой структуре узлов уже не пойдут, и в ПриВыгрузкеДанныхПодчиненному их уже не поймаешь, чтобы сгенерить удаления... Вариантов решений несколько вижу, но ничего такого же простого, как у тебя, не получается. У тебя же простота как раз тем и обеспечивается, что изначально регистрируется всё.

Связка - регистрация изменений лишь для нужных узлов + фильтр по организациям. То есть именно так, как в типовой, когда ни один из этих пунктов не отключен.  Ну вообще-то при переносе организации в другой узел, в самом верхнем узле я регистрирую изменения не для всех, а лишь для тех, через которые будут сливаться данные в нижестоящие узлы-цели. Мда, тут на словах проще запутать, чем объяснить... Рисовать надо. Короче, все пока работает и не глючит.  Кстати, спасибо за наводку на алгоритмы оптимизации работы выгрузки... Совсем не задумывался о ней, пока на каждый сервак по 4- узлов-соседей :)