|
Разный набор данных для узлов | ☑ | ||
---|---|---|---|---|
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) >он потеряет все зарегистрированные для изменения
С чего бы? Если я ничего не путаю, регистрация изменений хранится для каждого узла отдельно. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |