Вход | Регистрация


1С:Предприятие ::

Метки: 

РИБ и обновления

Я
   altaykniga
 
13.02.18 - 17:09
Всем привет. Планируется использование распределенных ИБ.

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

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

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

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

Всем спасибо за помощь!
 
 
   vde69
 
1 - 13.02.18 - 17:20
для узлов РИБ обновление в пользовательском режиме не нужно, все измененные данные придут из центра в уже готовом виде
   SeriyP
 
2 - 13.02.18 - 17:44
(0) В перефирийных базах есть пользователи с полными правами? Пусть они и проводят обновление: после загрузки через обмен изменений конфигурации запускают конфигуратор, нажимают кнопку Ф7, ОК и т.д. Либо удаленно к ним подключаться и все это делать.
   Tatitutu
 
3 - 13.02.18 - 18:33
Если КонфигурацияИзменена() Тогда
//закрыли 1С

//сделали бекап если нужно
//загрузили обновление

//запустили 1С
//загрузили данные из обмена

КонецЕсли;
   МимохожийОднако
 
4 - 13.02.18 - 20:06
Еще рекомендую при обновлении выключать автоматическую синхронизацию. В некоторых местах из-за медленного интернета не успевает приходить увеличенный файл обмена.
   Лефмихалыч
 
5 - 13.02.18 - 22:12
(0) если данные, которые надо обновлять, присутствуют только в ПБ и их нет в ЦБ, то надо запускать эти обработки и в ПБ тоже. В противном случае - достаточно один раз запустить в центре, а в периферийных правильные данные придут из центра и заменят собой неправильные.
   vde69
 
6 - 13.02.18 - 22:51
(5) РИБ - это 100% обмен в разрезе организаций, по этому ничего запускать не нужно
   Serg_1960
 
7 - 13.02.18 - 23:09
(1) "для узлов РИБ обновление в пользовательском режиме не нужно" - нужно. В РИБ-базах идентичны конфигурации (по определению), но данные информационных баз - могут различаться.

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

Я сложно сказал, надо ли пояснить примером?
   vde69
 
8 - 13.02.18 - 23:14
(7) для РИБА не может быть расхождений данных подчинённого и главного узла
   Serg_1960
 
9 - 13.02.18 - 23:20
(8) Открой состав плана обмена - всё что не включено в состав - может иметь расхождение. Например, как наиболее характерный показатель "расхождения" в данных узлов, - префикс базы.

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

Соответственно, если обработка обновления изменяет эти данные - то эта обработка должна быть запущена во всех узлах РИБ.
   vde69
 
10 - 13.02.18 - 23:33
(9) у РИБ нет состава, там строго 100%


все планы обменов делятся на РИБ и "настраиваемые", ты говоришь про НЕ РИБы
 
 Рекламное место пустует
   Serg_1960
 
11 - 13.02.18 - 23:45
РИБ - это всего лишь галочка в свойствах плана обмена и ничего более. Всё остальное, присущее лишь только им - всё это реализуется механизмами платформы и в программной поддержке конфигурацией.
   altaykniga
 
12 - 14.02.18 - 09:26
прочитав ответы умных людей, так и не увидел однозначного ответа на свой вопрос. Обмен предполагается в одну сторону, т.е. периферийные базы -> Главная база.

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

Правильно?
   Cool_Profi
 
13 - 14.02.18 - 09:28
(10) Вот у меня РИБ. А некоторые РС не ходят между базами. Так что ты не прав
   Фрэнки
 
14 - 14.02.18 - 09:34
(10) 100% в РИБ - это не про Данные, а про Метаданные. Выбора, какие Метаданные включать/исключать из Обмена нет.

Но Данные - это Состав в свойствах Плана Обмена.
   SeriyP
 
15 - 14.02.18 - 09:35
(12)Вот это не стыкуется:
- "Обмен предполагается в одну сторону, т.е. периферийные базы -> Главная база"  
- "3. выполняю обмен с периферийными базами. В результате 
   обмена конфигурация периферийных баз тоже обновляется"
т.к. в этом случае обмен будет ГБ -> ПБ
   Serg_1960
 
16 - 14.02.18 - 09:37
(12) В принципе правильно. Я бы рекомендовал делать взаимный обмен перед изменением конфигурации  для синхронизации данных в базах узлов. И только потом - изменение конфигурации в корневом(центральном) узле. А далее, как обычно, - вход в режим "1С:Предприятие" для выполнения обработчиков обновления. И только после этого - обмен со всеми узлами.

В типовых конфигурациях, относительно недавно, обработчики обновления стали учитывать работу в распределенных информационных базах - до разработчиков конфигураций наконец-то дошло что не все обработчики надо запускать во всех узлах.
   Фрэнки
 
17 - 14.02.18 - 09:38
(8) А как же РИБ с разделением данных(!) по Организации?
В Узлах при таком разделении "лишних" данных быть не должно.
   Serg_1960
 
18 - 14.02.18 - 09:44
(all) "Односторонний обмен" вовсе не означает отсутствие сообщений обмена от подчинённых узлов в главный узел.

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

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

Думаю сделать так:
сейчас есть рабочая база, в ней одна организация. Эта база будет главной.
1. Создаю в этой базе еще несколько организаций
2. Для всех организаций (включая и эту организацию, учет по которой в базе уже ведется) создаю синхронизацию, с отбором по организации. Вопрос: А где настроить направление обмена? (вопрос в начале сообщения)
3. Создаю периферийные базы путем выгрузки базы-образа из главной базы
   Фрэнки
 
20 - 14.02.18 - 11:03
(19) про собственно План обмена забыл что-то сказать ?
Название у плана обмена есть?
   altaykniga
 
21 - 14.02.18 - 11:19
(20) по организации
 написано в (19): "...создаю синхронизацию, с отбором по организации"
   Фрэнки
 
22 - 14.02.18 - 11:32
(21) ясно. Перечитал текст топика. Раз оно у вас все и так измененное, то какие тут могут быть принципиальные препятствия? Никаких.

Самое примитивное - это же в РИБ - В модуле объекта ПланОбмена есть процедуры, в которой отработают ПриОтправке данных. Надо в них различать Главный и Подчиненный.
При выборке измененных объектов в Главном узле смотреть на его тип и ставить Игнорировать. Вот как тут - это только копипаста из копипасты Serg_1960 пост 19
где посмотреть в типовых обмен с досылкой непринятых пакетов?
   altaykniga
 
23 - 26.02.18 - 14:34
(22) ткните носом, не могу найти код, который выполняется при регистрации изменений объекта.
Думается, что если использовать метод ПриОтправкеДанных, то в главном узле все равно будут копиться измененные объекты для оправки в подчиненный узел. А это лишние ресурсы компа
Поэтому хочу, чтобы объекты в главном узле не регистрировались для отправки уже сразу в момент их изменения (ПриЗаписи, например). В каком месте, например, типовой Бухгалтерии ред.3 эти объекты регистрируются для оправки?
   altaykniga
 
24 - 06.03.18 - 16:54
прошу не пинать, но все же однозначный ответ так и не увидел...

Центральную базу нужно обновлять 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 - 06.03.18 - 17:34
приоритет в данных где стоит? в головной?
Значит можно полностью без обменов довести головную до финального релиза, а затем выполнить обмены. И ни в коем случае не очищать регистрацию узлов. Хотя и так понятно, что регистрацией по узлам никто заморачиваться не станет.
   Serg_1960
 
26 - 06.03.18 - 17:39
(25) Вы неправы. Без комментариев.

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

А в принципе, из опыта, нужно добиваться установки так называемого "технологического окна"- кратковременный перерыв в эксплуатации для проведения профилактических работ и прочая.
   Фрэнки
 
27 - 06.03.18 - 17:40
(26) это при условии, что там на ПБ будут срабатывать все процедуры, заложенные штатно при обновлении моно-базы
   Фрэнки
 
28 - 06.03.18 - 17:41
(26) +к 27 - я думаю, что ПостПроцедуры для обновления на ПБ лучше отключить
   Serg_1960
 
29 - 06.03.18 - 17:45
(27) Например, для Бухгалтерии такой совет может быть и приемлем - там запускается последовательно вся цепочка пропущенных обязательных обработок. А, например, в старых УПП или ЗУП - там не всегда предыдущие обработки пропущенных обновлений запускаются в последующих обновлениях. В УПП, например, они могут просто банально физически отсутствовать в более свежей версии конфигурации.
   Serg_1960
 
30 - 06.03.18 - 17:48
И тогда мы может получить ситуацию, когда в ЦУ запускались последовательно все обязательные обработки, а в ПУ - только те, которые присутствуют в последней версии. А это, в свою очередь, может привести к рассогласованию и рассинхронизации данных по узлам.
   altaykniga
 
31 - 06.03.18 - 20:20
придется обновлять конфигурацию в ЦБ каждый месяц - и тогда не будет пропущенных релизов и обработчиков обновления. Обмен обязательно делать до обновления? или можно обновлять ЦБ и ПБ с зарегистрированными для изменения объектами?
   Фрэнки
 
32 - 06.03.18 - 20:28
(31) на практике подтверждено, что гораздо удобней перед обновлением, в любом случае оно стартует в ручном режиме, лучше все данные обновить, что пакет был только с теми данными, которые критичны для обновления, а не всякая всячина, которую затем приходится искать по всей базе, если что-то пошло не так, как ожидалось.
   Фрэнки
 
33 - 06.03.18 - 20:29
(31) т.е. лучше не начинать обновление базы, если не прокрутил перед ним обычное штатный штатный обмен.
 
 
   Йохохо
 
34 - 06.03.18 - 20:31
(31) односторонний то решили делать?
Обмен до обновления - представьте что с обменом придет док от позавчера, а вчера новые правила, которые сегодня обработал в цб обработчик обновления
   Фрэнки
 
35 - 06.03.18 - 20:36
(30) Я наверное не совсем внятно высказал свою мысль. Попрпобую еще раз в стиле Джойса

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

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

з.ы. Конечно все это мое имхо, которое может не совпадает с тем, как выглядит обновление данных в РИБ в типовых конфигах - специально я этого сейчас не тестил. Не удивлюсь, если эта логика им не соответствуют.
   Фрэнки
 
36 - 06.03.18 - 20:39
Да, разумеется, что при сильно перекроенном составе объектов в РИБ, что часть объектов, включенных в конфигурацию и подвергающихся обработке при обновлениях в РИБ не включено - обработки для таких данных там будут нужны. Но я бы считал такое поведение конфигурации в таком плане обмена РИБ источником багов.
   altaykniga
 
37 - 06.03.18 - 20:44
(34) как сделать односторонний - не знаю. Решил запретить редактирование документов в ЦБ правами +запретить редактирование справочников в ПБ правами (разрешить только редактировать контрагентов и связанные с ними справочники: подразделения, пункты погрузки-разгрузки и т.д.)
   Йохохо
 
38 - 06.03.18 - 20:51
(37) через промежуточную ЦБ мб
   Фрэнки
 
39 - 06.03.18 - 21:04
(37) у вас же много изменений в конфигурациях? Поэтому можно дописать так, чтоб был односторонний обмен.

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

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

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

Готовая обработка есть на ИТС. Сию секунду у меня ее под руками нет, но если сами не найдете - пишите - дам позже ссылку.
   altaykniga
 
40 - 07.03.18 - 09:21
(39) а есть ли в данном случае смысл в одностороннем обмене?

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

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

Посоветуйте, как лучше сделать? Оставить типовой обмен без дописок? Просто запретить редактирование справочников в ПБ, а в ЦБ запретить редактирование документов?
   Фрэнки
 
41 - 07.03.18 - 09:29
(40)// И что получится? Пользователи в ПБ насоздают кучу


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

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

Что тут можно посоветовать? Моей практике у меня было первое приближение и затем я дописывал под конкретные условия работы, бизнес-процессы: здесь - можно, а здесь - нельзя и т.п.
   Фрэнки
 
42 - 07.03.18 - 09:31
(40) насчет создания "кучи НСИ" - это вовсе отдельная история. Добавление новых элементов НСИ регламентировано бывает самыми разными способами и подходами. Вплоть до работы в отдельной базе НСИ, где по максимуму документов нет, а справочники есть.
   altaykniga
 
43 - 07.03.18 - 09:40
еще хотел спросить.

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

Какой использовать предпочтительней? В бух 3 реализовано через 2-ой вариант
   Фрэнки
 
44 - 07.03.18 - 17:06
(43) если план работает в обе стороны и он максимально полный = разрешена авторегистрация.

Когда встревают в дополнительные условия, модификацию правил, ограничения по видам объектов и т.п. - запрещают все и подписками рулят :) Не так все и сложно. Но возни гораздо больше.
   Serg_1960
 
45 - 07.03.18 - 20:57
(43) Если объект всегда, независимо от своего содержимого, должен мигрировать - "авторегистрация = разрешить". Если для регистрации изменений нужен анализ содержимое объекта - "авторегистрация = запретить", а сам анализ содержимого и регистрация - в подписке на событие.

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



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