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



ПланОбмена - 1 база-2 узла

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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