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