Всем привет. Планируется использование распределенных ИБ.

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

Вопрос такой: а как быть с запуском обработчиков после обновления конфигурации базы данных и первого входа в пользовательском режиме?

обновление основной конфигурации - обновление конфигурации базы данных - выполнение обработчиков обновления в пользовательском режиме

Например, было пропущено много релизов, необходимо последовательно обновить обновиться на 3 релиза. Проблем с обновлением центральной базы не возникает, а как быть с переферийными? Необходимо тоже выполнять их обновление в 3 этапа (обновить центральную базу первым релизом, обновить РИБ, обновить центральную базу вторым релизом, обновить РИБ и т.д.?)

Всем спасибо за помощь!

для узлов РИБ обновление в пользовательском режиме не нужно, все измененные данные придут из центра в уже готовом виде

(0) В перефирийных базах есть пользователи с полными правами? Пусть они и проводят обновление: после загрузки через обмен изменений конфигурации запускают конфигуратор, нажимают кнопку Ф7, ОК и т.д. Либо удаленно к ним подключаться и все это делать.

Если КонфигурацияИзменена() Тогда
//закрыли 1С
//сделали бекап если нужно
//загрузили обновление
//запустили 1С
//загрузили данные из обмена
КонецЕсли;

Еще рекомендую при обновлении выключать автоматическую синхронизацию. В некоторых местах из-за медленного интернета не успевает приходить увеличенный файл обмена.

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

(5) РИБ - это 100% обмен в разрезе организаций, по этому ничего запускать не нужно

(1) "для узлов РИБ обновление в пользовательском режиме не нужно" - нужно. В РИБ-базах идентичны конфигурации (по определению), но данные информационных баз - могут различаться.

(6) Опять недостоверная информация :(
РИБ - это распределенная база данных, а то про что Вы сказали - это обмен данными (механизм РИБ).

Я сложно сказал, надо ли пояснить примером?

(7) для РИБА не может быть расхождений данных подчинённого и главного узла

(8) Открой состав плана обмена - всё что не включено в состав - может иметь расхождение. Например, как наиболее характерный показатель "расхождения" в данных узлов, - префикс базы.

Стат.отчетность, как правило, не участвует в обмене (не мигрирует). Это имеет смысл, например, когда у организации есть территориально удаленные обособленные подразделения.

Соответственно, если обработка обновления изменяет эти данные - то эта обработка должна быть запущена во всех узлах РИБ.

(9) у РИБ нет состава, там строго 100%


все планы обменов делятся на РИБ и "настраиваемые", ты говоришь про НЕ РИБы

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

прочитав ответы умных людей, так и не увидел однозначного ответа на свой вопрос. Обмен предполагается в одну сторону, т.е. периферийные базы -> Главная база.

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

Правильно?

(10) Вот у меня РИБ. А некоторые РС не ходят между базами. Так что ты не прав

(10) 100% в РИБ - это не про Данные, а про Метаданные. Выбора, какие Метаданные включать/исключать из Обмена нет.

Но Данные - это Состав в свойствах Плана Обмена.

(12)Вот это не стыкуется:
- "Обмен предполагается в одну сторону, т.е. периферийные базы -> Главная база"  
- "3. выполняю обмен с периферийными базами. В результате
   обмена конфигурация периферийных баз тоже обновляется"
т.к. в этом случае обмен будет ГБ -> ПБ

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

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

(8) А как же РИБ с разделением данных(!) по Организации?
В Узлах при таком разделении "лишних" данных быть не должно.

(all) "Односторонний обмен" вовсе не означает отсутствие сообщений обмена от подчинённых узлов в главный узел.

Можно, конечно, как часто рекомендуют, сразу же после передачи данных очищать регистрацию изменений... но в РИБ такой номер не пройдёт - идентичность конфигураций поддерживается на уровне платформы.

хотел уточнить еще такой момент:

а возможно реализовать односторонний обмен "периферийные базы -> ГлавнаяБаза"? Обмен необходим по организациям. Например, учет ведется в 5-ти периферийных базах, данные стекаются в главную базу. Если случайно какие-то полученные данные в главной базе были изменены, эти изменения НЕ должны попасть в периферийную базу

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

(19) про собственно План обмена забыл что-то сказать ?
Название у плана обмена есть?

(20) по организации

написано в (19): "...создаю синхронизацию, с отбором по организации"

(21) ясно. Перечитал текст топика. Раз оно у вас все и так измененное, то какие тут могут быть принципиальные препятствия? Никаких.

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

(22) ткните носом, не могу найти код, который выполняется при регистрации изменений объекта.
Думается, что если использовать метод ПриОтправкеДанных, то в главном узле все равно будут копиться измененные объекты для оправки в подчиненный узел. А это лишние ресурсы компа
Поэтому хочу, чтобы объекты в главном узле не регистрировались для отправки уже сразу в момент их изменения (ПриЗаписи, например). В каком месте, например, типовой Бухгалтерии ред.3 эти объекты регистрируются для оправки?

прошу не пинать, но все же однозначный ответ так и не увидел...

Центральную базу нужно обновлять 3-мя релизами (следовательно, 3 раза будут выполняться обработчики обновления), а именно:
обновлениеОсновнойКонфигурации1 -> ОбновлениеКонфигурацииБД1 -> ВыполнениеОбработчиковОбновления1
обновлениеОсновнойКонфигурации2 -> ОбновлениеКонфигурацииБД2 -> ВыполнениеОбработчиковОбновления2
обновлениеОсновнойКонфигурации3 -> ОбновлениеКонфигурацииБД3 -> ВыполнениеОбработчиковОбновления3

Каким образом при обмене обновлять периферийные базы?
вариант №1:
1. синхронизация с ПБ
2. обновление ЦБ (3этапа)
3. синхронизация с ПБ

вариант №2:
1. синхронизация с ПБ
2. обновление ЦБ (1этап)
3. синхронизация с ПБ
4. обновление ЦБ (2этап)
5. синхронизация с ПБ
6. обновление ЦБ (3этап)
7. синхронизация с ПБ

Если придется использовать вариант №2, то тогда про РИБ придется забыть - работу 5-ти организаций, входящих в холдинг, никто не будет останавливать на сутки...

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

(25) Вы неправы. Без комментариев.

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

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

(26) это при условии, что там на ПБ будут срабатывать все процедуры, заложенные штатно при обновлении моно-базы

(26) +к 27 - я думаю, что ПостПроцедуры для обновления на ПБ лучше отключить

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

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

придется обновлять конфигурацию в ЦБ каждый месяц - и тогда не будет пропущенных релизов и обработчиков обновления. Обмен обязательно делать до обновления? или можно обновлять ЦБ и ПБ с зарегистрированными для изменения объектами?

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

(31) т.е. лучше не начинать обновление базы, если не прокрутил перед ним обычное штатный штатный обмен.

(31) односторонний то решили делать?
Обмен до обновления - представьте что с обменом придет док от позавчера, а вчера новые правила, которые сегодня обработал в цб обработчик обновления

(30) Я наверное не совсем внятно высказал свою мысль. Попрпобую еще раз в стиле Джойса

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

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

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

Да, разумеется, что при сильно перекроенном составе объектов в РИБ, что часть объектов, включенных в конфигурацию и подвергающихся обработке при обновлениях в РИБ не включено - обработки для таких данных там будут нужны. Но я бы считал такое поведение конфигурации в таком плане обмена РИБ источником багов.

(34) как сделать односторонний - не знаю. Решил запретить редактирование документов в ЦБ правами +запретить редактирование справочников в ПБ правами (разрешить только редактировать контрагентов и связанные с ними справочники: подразделения, пункты погрузки-разгрузки и т.д.)

(37) через промежуточную ЦБ мб

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

Открываем в конфигураторе в плане обмена Состав. Там есть авторегистрация данных - ставим везде Запретить. Таким образом ни один справочник, документ, набор записей не попадет в обмен, т.к. он не будет зарегистрирован.

Находим те объекты, которые обязательно должны помечаться на выгрузку в ПБ (периферийной) и там для всех этих объектов создаем подписку на событие, например, на событие ПриЗаписи, затем там в процедуре настраиваем нужна или не нужна регистрация ТекущегоОбъекта в узлы или нет. При этом проверяется условие, что текущий сеанс, в котором происходит обработка подписки происходит в Периферийном узле, а не в Центральной базе.

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

Готовая обработка есть на ИТС. Сию секунду у меня ее под руками нет, но если сами не найдете - пишите - дам позже ссылку.

(39) а есть ли в данном случае смысл в одностороннем обмене?

в ПБ (5баз) будут вести учет - создавать документы
данные из этих 5-ти баз будут стекаться в ЦБ
в ЦБ будут формироваться отчеты для анализа хоз.деятельности

необходимо контролировать учет НСИ. Поэтому редактирование справочников хочу разрешить только в ЦБ.
Можно программно запретить регистрацию изменений справочников в ПБ (чтобы они не отправлялись в ЦБ).
И что получится? Пользователи в ПБ насоздают кучу ненужных элементов справочников, применят их в документах... и получится неразбериха и путаница

Посоветуйте, как лучше сделать? Оставить типовой обмен без дописок? Просто запретить редактирование справочников в ПБ, а в ЦБ запретить редактирование документов?

(40) // И что получится? Пользователи в ПБ насоздают кучу

Само собой разумеется, что при таком обмене (НСИ только в Центре) создавать элементы в ПБ нельзя. Это все строго индивидуально. Что можно сделать в одном справочнике - то нельзя делать в другом.

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

Что тут можно посоветовать? Моей практике у меня было первое приближение и затем я дописывал под конкретные условия работы, бизнес-процессы: здесь - можно, а здесь - нельзя и т.п.

(40) насчет создания "кучи НСИ" - это вовсе отдельная история. Добавление новых элементов НСИ регламентировано бывает самыми разными способами и подходами. Вплоть до работы в отдельной базе НСИ, где по максимуму документов нет, а справочники есть.

еще хотел спросить.

есть 2 варианта регистрации изменений:
1. авторегистрация=разрешить
2. авторегистрация=запретить, а затем в подписке на событие поставить галочку на нужные для регистрации объекты.

Какой использовать предпочтительней? В бух 3 реализовано через 2-ой вариант

(43) если план работает в обе стороны и он максимально полный = разрешена авторегистрация.

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

(43) Если объект всегда, независимо от своего содержимого, должен мигрировать - "авторегистрация = разрешить". Если для регистрации изменений нужен анализ содержимое объекта - "авторегистрация = запретить", а сам анализ содержимого и регистрация - в подписке на событие.

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