Имя: Пароль:
1C
 
ПланОбмена - 1 база-2 узла
,
0 lartibetra
 
12.01.19
20:55
Здравствуйте,
Кто подскажет, можно ли с одной базой обмениваться по нескольким узлам?
Например по одному узлу выгружать справочники, а по второму выгружать доументы?
1 Cyberhawk
 
12.01.19
21:06
Конечно можно
2 lartibetra
 
12.01.19
21:13
(1) А примеры когда так делают есть?
Например в типовых так делают?
3 MaxS
 
12.01.19
21:17
Нельзя. Префиксы узлов пересекаются, новую настройку создать не получается в типовых.
4 lartibetra
 
12.01.19
21:18
Так можно или нельзя?)
5 Cyberhawk
 
12.01.19
21:22
(2) Когда у разных данных разный приоритет обмена
6 MaxS
 
12.01.19
21:24
Если очень хочется, то можно, но придётся доработать запрет типового механизма и в базе приемнике аналогично создать 2 узла и как-то разрулить имена файлов для обмена. И не регистрировать одно и то же в этих узлах.
7 lartibetra
 
12.01.19
21:27
(6) Имена файлов создаются по префиксу, а префиксы разные будут изза кода узла.
Создать столько же узлов в приемнике это понятно.
И то что обеспечить, чтобы регистрировалось НЕ одинаковая инфа тоже ясно.

Ну значит можно..
8 Serg_1960
 
13.01.19
00:55
(3) Можно. "Пересечение" узлов ни на что не влияет, кроме как на автонумерацию, и легко устраняется их изменением.
(6) Sorry, Вы не в теме.

(7) "Пациент скорее жив, чем мертв"(с) - Скорее можно создать, чем нельзя - Вы у не уточнили главное - РИБ или не РИБ.

(2) "Например в типовых так делают?" - нет.
Там планы обмена "по организациям", "по магазинам", по подразделениям/складам и т.д. И несмотря на различие, у них у всех общая "специфика" - единая НСИ. В этом сакральный смысл Распределенных Информационных Баз.

Если Вы собираетесь делать на РИБ, то можно выкрутиться без изменений конфигурации - за счет написания "своих" правил регистрации.
9 Serg_1960
 
13.01.19
00:57
"на РИБ" --> "не РИБ"
10 MaxS
 
13.01.19
08:43
(8) При создании новой настройки обмена необходимо ввести префикс базы получателя. База получатель одна и та же. Как создать 2-ю настройку типовым способом?
11 lartibetra
 
13.01.19
09:48
(8) У меня НЕ РИБ.
Значит буду пробовать.
12 Мимохожий Однако
 
13.01.19
10:32
Прикольно. Почему возникла такая задача. Каждый узел, это отдельная база.
13 lartibetra
 
13.01.19
10:40
(12) Например разные данные нужно грузить с разной периодичностью.
14 Мимохожий Однако
 
13.01.19
10:43
Можно в одной загрузке грузить данные в зависимости от расписания
15 lartibetra
 
13.01.19
11:22
(14) Допустим идет выгрузку по правилам, тогда прям в правила вшить код по проверки времени.. помоему не очень красиво.
16 Фрэнки
 
13.01.19
11:38
(15) Тут надо тогда спускать уровень рассуждений на саму технологию использования объекта метаданных ПланОбмена.

Что такое Объект ПланОбмена, что такое менеджер, откуда берутся и куда тулятся ссылки на объекты "узел ПланОбмена" и т.д.

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

ну есть у тебя база центрального офиса и еще две базы для двух подчиненных Структур (не важно, что это может быть: филиал, магазин, склад, цех, карьер, другая какая-то организация). И несколько разных наборов правил, связанных с несколькими разными ПланОбмена, допустим три разных: План обмена конфигурацией, план обмена справочниками НСИ, план обмена документами и оперативными справочниками.
Какой будет общий состав узлов? В идеале = в каждом плане будет 1+2 и таких планов 3 == 9 узлов. А баз сколько физически? Всего три базы
17 Фрэнки
 
13.01.19
11:45
продолжу (16)

А если не хочется вводить в Центральную базу "лишние" планы обмена, то как выкрутиться? А как пишет выше в (8)

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

Только при этом не нужно забывать, что свои другие правила надо будет применять в какое-то свое время к каждому своему объекту данных.
Условно непрерывный обмен - синхронный.
Условно дискретный обмен - асинхронный.
Сколько времени должен занимать анализ данных источника, чтоб асинхронно применять к этим данным свои уникальные правила обмена? Это может быть критичной для пользователя длительной процедурой, а еще, в особо тяжелых случаях, и с требованием монопольного режима.
18 lartibetra
 
13.01.19
11:46
(16) Так а вывод какой?
Вот конкретный пример - есть ЦентрБаза и ПодчиненнаяБаза.
Нужно в течении дня выгружать только справочники, а ночью все документы изменившиеся документы.
Вот здесь мне и нужны 2 узла на одну физическую базу
19 Cyberhawk
 
13.01.19
11:57
(18) Какие проблемы с двумя наборами ПВД в правилах конвертации?
20 Фрэнки
 
13.01.19
11:58
(18) Вывод у 1С программистов простой : два плана - с двумя разными правилами обмена

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

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

Если же "один раз настроил и забыл" хоть на какое-то время - тогда нужно свои планы обмена накрутить, один или несколько, но расковырять их досконально, как на уровне регистрации изменений, так и на уровне выгрузки в файлы обмена, например.
21 lartibetra
 
13.01.19
12:03
(20) Я чтото сильно запутался.
Правила понятно что будут разными в рамках узлов, зачем в итоге 2 плана обмена делать?
Это было моим изначальным вопросом, я хочу выкрутиться одним планом и несколькими узлами.
22 MaxS
 
13.01.19
12:21
Прежде чем начинать программировать, напишите в блокноте префиксы узлов всех баз (три префикса - эта база и два узла) и имена файлов сообщений для каждой пары настроек обмена. Всего 6 префиксов и 4 имени файла.
Если получится, то это и будет ответом на вопрос темы топика. пмсм.
23 lartibetra
 
13.01.19
13:15
(22)
ЦБ - Префикс центрального узла
Б1 - Префикс узла 1 подчиненной базы (справочники)
Б2 - Префикс узла 1 подчиненной базы (документы)

ЦБ - Б1; Б1 - ЦБ
ЦБ - Б2; Б2 - ЦБ

Вот такой обмен.
24 MaxS
 
13.01.19
13:25
(23) А у второй базы какие префиксы?
25 Фрэнки
 
13.01.19
13:57
(24) у него в _одном_ плане, для _одной_ подчиненной базы в голове сложилось в _два_ узла с разными префиксами.

Не _правила_ разные, а _узлы_ разные.
26 MaxS
 
13.01.19
14:27
(25) Мне понятно что хочет автор.
Непонятно понимает ли кто-то как на практике это реализовать? После вопроса (22) все советы закончились.

Предположим, что у подчинённой базы такие префиксы узлов:
Б1 - префикс узла самой базы. (ЭтаБаза)
ЦБ - узел для обмена с центральной базой (справочники)
?? - узел для обмена с центральной базой (документы) - если найдётся решение что сделать с этим узлом, будет ответ на вопрос топика.

Файлы ЦБ - Б1; Б1 - ЦБ ходят туда обратно исправно.
При поступлении файла "ЦБ - Б2" подчиненная база ответит, что нет такого узла.
27 Cyberhawk
 
13.01.19
14:38
По разным каталогам обмена разнести обмен не предлагать?
28 lartibetra
 
13.01.19
15:21
(26) Блин, действительно ты прав. Чтото я затупил, 1 узел должен быть равен одной базе.
Не знаю что я даже такую тему поднял, буду делать два разных плана обмена.
29 MaxS
 
13.01.19
15:27
(28) Возвращаемся на исходные позиции? Теоретически можно обойтись одним планом обмена, но сколько это потребует доработок пока не ясно.
Нужно подождать комментария от (8) по теме )
30 lartibetra
 
13.01.19
15:32
(29) Можно на одном узле купить все изменения, но по условию (например по времени) выгружать те или иные данные, это логика будет записана в правилах обмена.
Например, весь день выгружаются только справочники, а в 3 ночи летят и документы.
Но мне так не нравится, сделаю 2 разных плана обмена.
31 MaxS
 
13.01.19
15:36
(30) При поступлении подтверждения о доставке справочников регистрация всех документов сбросится.
Можно конечно завести 2-й узел как тут и обсуждалось и ночью при обмене узлом Б1 (справочники) смотреть на регистрацию узла Б2 (документы). С нумерацией можно запутаться - нужно понять при получении ответа и перед сбросом регистрации что было получено - справочники или документы.
32 lartibetra
 
13.01.19
15:40
(31) Значит и здесь я был неправ..
Хорошо, тогда в вашем варианте может ночью со служебного узла перекидывать регистрацию документов на основной узел. Такое может сработать?
33 MaxS
 
13.01.19
15:43
(32) А, да, можно ночью в основной узел добавлять зарегистрированные документы из служебного узла и тут же снимать с регистрации всё на служебном узле.
34 Cyberhawk
 
13.01.19
15:50
(33) А когда приемник не сможет принять пакет с ночными документами, неоткуда будет взять кандидатов для повторной передачи )
35 Serg_1960
 
13.01.19
15:50
(29) А в (8) ничего такого сакрального не сказано, можно не ждать очередных откровений :))
ТС уже подсказали и он уже сделал правильные выводы - два плана обмена. Это позволит легко настроить различный состав, различные правила и различное расписание. Ничего сложного и всё в пределах, не противоречащих типовым конфигурациям. И главное: без всяких танцев с бубнами.
36 lartibetra
 
13.01.19
15:52
(34) Если не сможет принять, то документы же останутся на основном узле.
37 Cyberhawk
 
13.01.19
15:54
(36) На основном узле документы останутся до первого подтверждения приема по справочникам, а потом тю-тю )
38 lartibetra
 
13.01.19
15:56
(37) Смотри, документ ночью окажутся на основном узле и будут пытаться выгрузить в общей массе и по общим правилам. Если не смогут, то также будут сидеть на узле и ждать успешной выгрузки. Где здесь тютю?
39 Cyberhawk
 
13.01.19
15:58
(38) "Если не смогут" // Не смогут что?
40 Serg_1960
 
13.01.19
15:58
Вариант с двумя узлами к одной базе тоже имеет право жизнь. Я просто напомню: различные узлы в одном плане обмена автономны и независимы друг от друга. У них у каждого своя автономная регистрация, нумерация сообщений и т.д. Надо только в самом начале (при регистрации изменений по узлам) не тормозить и всё будет окей :)
41 MaxS
 
13.01.19
15:59
(34) Почему не сможет принять? На приемнике не будет ограничений в видах объектов. Будут отправлять пока не примет.
(36) На основной узле днем не регистрируются документы и всё. Если ночные документы не отправились, отправляем до посинения. Либо по утрам перекидываем регистрацию документов обратно на служебный узел.

(35) Вы же в последней строчке написали что можно обойтись без изменения конфигурации. Ладно, проехали )
42 lartibetra
 
13.01.19
16:01
(39) - в (41) вот все правильно расписано. Ночью перекинулись на узел и до посинения пытаются выгрузиться. Тут уже никаких ограничений нет.
43 Cyberhawk
 
13.01.19
16:02
Хз о чем ты.
44 lartibetra
 
13.01.19
16:04
(43) Ну и ладно. Я все равно через 2 плана обмена считаю правильно делать, чтобы не запутывать логику.
45 Serg_1960
 
13.01.19
16:08
(41) Погуглите "регистрация изменений для обмена" или нечто подобное для правил регистрации (не конвертации!). Современные платформы и конфигурации позволяют сделать нужное без изменения конфигурации... хотя как по мне - так проще изменить типовую :)
46 Serg_1960
 
13.01.19
16:12
(44) Правильным будет ни в коем случае не регистрировать изменение одного и того же объекта дважды в двух узлах или в двух планах (которые к одной и той же базе). Остальное на Ваше усмотрение.
47 MaxS
 
13.01.19
16:24
(45) Да я как-то сам пишу инструкции пользователям по этому поводу как в современных типовых менять правила регистрации. )
Если база типовая и нуждается в периодическом обновлении, то новый план обмена затронет множество типовых модулей, либо нужно его внедрить нетиповым способом - вся логика в своих общих модулях.
По мне, так заморочек намного больше, чем написать правила регистрации, которые понимают для какого узла запущены (они вероятно одни на план обмена, а не на узел). И добавить внешнюю обработку с регламентным заданием, которая перекидывает регистрацию документов. Такое решение можно легко тиражировать. )
48 Фрэнки
 
13.01.19
17:37
(47) не согласен, что свой самописный план, со своими самописными подписками на регистрацию изменений чего-то глобально затронет, поменяет, что его чрезмерно трудно внедрить и т.д.
49 lartibetra
 
13.01.19
18:27
(48) В 47 наверное имеется ввиду не клепать свой план обмена в рамках БСП подсистемы, так как в типовых добавление своего плана по умолчанию подразумевавется что идет в рамках БСП,