Имя: Пароль:
1C
 
Разный набор данных для узлов
0 Stim
 
22.10.21
10:40
Коллеги, как бы вы решили такую задачу:

Есть некая база, которая отправляет данные в другие, например, магазины. Состав данных у всех должен быть идентичен. Обмен автоматический, выполняется каждый день.
Важно - это не распределенная база данных! Обмен через регистрацию изменений и правила обмена.

В центральной базе решили добавить, например, новый реквизит в справочник, участвующий в обмене. Этот же реквизит надо добавить и в справочники узлов.
Проблема в том, что магазин1 уже добавил себе этот реквизит, обновил правила и ждет данные. А магазин10 тянет кота за хвост и не обновляет.
И центральная база не может начать заполнение этого реквизита, ведь когда магазин10 не получит все данные. Ведь когда(через неделю) он обновит свой справочник и правила, он потеряет все зарегистрированные для изменения за эту неделю с новым реквизитом.

Как сделать так, чтобы в центральной базе добавить этот реквизит и "хранить" регистрацию изменений этого реквизита до тех пор, пока узел не будет готов их получать?
1 acht
 
22.10.21
10:45
Игнорировать подтверждение обмена конкретно для этого справочника
2 DrShad
 
22.10.21
10:47
все базы подключить к хранилищу
3 Stim
 
22.10.21
10:50
(2) и что это даст?
4 Stim
 
22.10.21
10:52
(1) так разве можно? Узел отправляет ответ "сообщение принял" и цб очищает всю регистрацию для него.
решение, по возможности, нужно такое, чтобы не ломать штатный механизм синхронизации данных
5 DrShad
 
22.10.21
10:54
а еще лучше добавлять реквизиты через механизм доп реквизитов, тогда пофигу кто тупит, а кто нет - все прилетит с обменом
6 Stim
 
22.10.21
10:57
(5) справочник - это для примера. Там может быть и новый справочник и новый РС и все, что угодно
7 Serg_1960
 
22.10.21
11:02
(6) Хмм... ради "накопления" регистрации изменений, в план обмена можно добавить "левый" узел и паралельно регистрировать изменения для магазина и этого узла. Обмен идёт с магазином - регистрация сбрасывается, с "левым" узлом нет обмена - регистрация изменений "накапливается".
8 Serg_1960
 
22.10.21
11:05
Потом, когда "синхронизируются" конфигурации, перерегистрируйте нужные Вам регистрации изменений с узла на нужный Вам магазин.
9 Serg_1960
 
22.10.21
11:08
У Вас же уже не типовые конфигурации? Вариантов - море. Например, через подписку можно "накапливать" регистрацию изменений в регистре сведений, специально созданном для этих целей, со структурой, подобной таблице регистрации изменений.
10 Stim
 
22.10.21
12:17
(8) да. Но как это можно автоматизировать?
Добавили новый справочник и новый реквизит к другому справочнику. И новый РС добавили. Магазин10 справочник добавил, реквизит добавит через 4 дня, а РС добавит хз когда.
Об этом нам сообщили почтовым голубем, а записку унесло ветром. И приходится все держать в голове и для каждого такого магазина изобретать правила переноса регистрации с одного узла на другой.
А если таких магазинов с сотню?
11 Ёпрст
 
22.10.21
12:53
(10) как вы сейчас узнаете в центре, что пб обновила конфу ?
12 Serg_1960
 
22.10.21
13:06
(10) Могу только посочувствовать и пожелать успехов в автоматизации хаоса :( Я с такой ситуацией столкнулся значительно ранее - собственно говоря, меня в своё время пригласили в фирму, чтобы я помог устранить бардак. Я внедрил РИБ.
13 Ёпрст
 
22.10.21
13:09
У нас помесь из риба и обмена по правилам. Все справочники и прочий мусор редактируются в центре и летят по правилам в пб, а доки, наеборот, меняются и создаются в пб и летят рибом в цб.
14 Ёпрст
 
22.10.21
13:10
Часть рс и служебных справочников так и живут и создаются в пб и ниуда не летят.
15 Ёпрст
 
22.10.21
13:11
И да, проще внедрить риб)) хотя бы гарантирует однородность конфы
16 Stim
 
22.10.21
15:52
(11) в чате
17 Ёпрст
 
22.10.21
16:00
(16) а...т.е никакой автоматизации.
Ну хз, прикрутить разве что риб, чтоб конфа у всех соответствовала.
Ну или ипаться со вторым планом обмена, в котором будет узел пб и регистрация, повторяющая все объекты плана обмена для ПБ и дальше как в (7).

Т.е добавить не только узел, и и сам второй план и в нём все узлы.
18 Ёпрст
 
22.10.21
16:02
Как только тебе в чате сообщили, что ПБ обновлена, так все изменения из второго плана для нужного узла переносишь в рабочий план обмена по нужному узлу, меняешь правила и удаляешь регистрацию для узла во втором плане.
19 Ёпрст
 
22.10.21
16:02
Один хрен, это полуручной режим, который всё равно приведёт к бардаку. :)
20 Stim
 
22.10.21
16:21
(17) риб точно не вариант. Базы разные
21 Ёпрст
 
22.10.21
16:38
(20) тогда только еще один план обмена, дублирующий первый и в нём те же узлы...
22 Ёпрст
 
22.10.21
16:39
и потом если есть подтверждение, регим всё из второго плана по узлу в первом плане (основном) и чистим регистрацию во втором.
если сразу измененмя в пб, то просто чистим регистрацию во втором
23 Ёпрст
 
22.10.21
16:41
При желании, можно делать правила регистрации для второго плана, что только конкретные, измененные объекты (для которых реструктуризация была) - то только эти данные накапливать, а не вообще все объекты. Если нет измененых, то и накапливать нечего
24 Stim
 
22.10.21
18:23
(22) все регать точно не надо. там грубо говоря 10тыс записей, из которых 9тыс уже загрузили
25 Ёпрст
 
22.10.21
19:03
(24) праильно, во втором регим только то, что затронуло изменения в cf-нике, грубо храним типы регистрируемых объектов где-то еще.
26 Ёпрст
 
22.10.21
19:03
в рс, каком нить
27 acanta
 
22.10.21
19:18
А разве версии не могут использоваться в качестве такого дополнительного регистратора изменений?
28 mistеr
 
23.10.21
12:01
(0) >он потеряет все зарегистрированные для изменения

С чего бы? Если я ничего не путаю, регистрация изменений хранится для каждого узла отдельно.
Проблемы невозможно решaть нa том же уровне компетентности, нa котором они возникaют. Альберт Эйнштейн