Доброго времени суток.
Остро встал вопрос обменов между различными базами. И в следствии этого решено было проникнуться в обмены, а именно РИБы и Конвертация данных.
Но как оказалось, не так то просто найти полноценную литературу. Или же я плохо искал, если что ткните носом. А вопросы следующего плана:
1) Можно ли совмещать РИБ и планы обмена, а именно. Если 2 базы, одна "дочерний узел", т.е. конфигурации у нас всегда идентичные. Можно ли с помощью правил обмена, реализовать обмен между ними, что бы в одну сторону ехал "набор данных 1" а в другую "набор данных 2", но что бы, при изменении структуры данных(изменение кофигурации) не пришлось переписывать планы обмена.
2) Куда грузить правила регистрации объектов в УПП?
3) И вообще как люди делают обмены между сотней узлов?
4) Если правила обмена не помогают в первом вопросе, то как правильнее организовать с помощью узлов и кода разностный обмен в обе стороны?
Есть ещё куча мелких других вопросов, которые возникают при работе с обменами, а ответов комплексных найти не могу( Направьте на путь истинный пожалуйста.
Остро встал вопрос обменов между различными базами. И в следствии этого решено было проникнуться в обмены, а именно РИБы и Конвертация данных.
Но как оказалось, не так то просто найти полноценную литературу. Или же я плохо искал, если что ткните носом. А вопросы следующего плана:
1) Можно ли совмещать РИБ и планы обмена, а именно. Если 2 базы, одна "дочерний узел", т.е. конфигурации у нас всегда идентичные. Можно ли с помощью правил обмена, реализовать обмен между ними, что бы в одну сторону ехал "набор данных 1" а в другую "набор данных 2", но что бы, при изменении структуры данных(изменение кофигурации) не пришлось переписывать планы обмена.
2) Куда грузить правила регистрации объектов в УПП?
3) И вообще как люди делают обмены между сотней узлов?
4) Если правила обмена не помогают в первом вопросе, то как правильнее организовать с помощью узлов и кода разностный обмен в обе стороны?
Есть ещё куча мелких других вопросов, которые возникают при работе с обменами, а ответов комплексных найти не могу( Направьте на путь истинный пожалуйста.
По теме из базы знаний
- Актуализация правил обмена в КД 2.1
- Правила обмена Штрих-М: Кассир miniPOS => Штрих-М: Торговое предприятие 5
- Планы обмена 1С
- Обсудим планы обмена. Способы регистрации объектов к обмену
- Эффективное управление фоновыми заданиями и коммуникация сеансов сервера с Фоном с помощью Структуры обмена (ноу-хау) + Бонус: Альтернативный вариант через Хранилище настроек
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) KiLLius, КД вообще иснтурмент своеобразный... как и все в 1С. Ближе к "сырой концепт".
Учитесь делать лучше свои обмены через COM или DBF - это еще не раз вас выручит.
А КД - так, баловство для разового переноса между близко к идентичным базами.
Учитесь делать лучше свои обмены через COM или DBF - это еще не раз вас выручит.
А КД - так, баловство для разового переноса между близко к идентичным базами.
у гилева есть курс по конвертации данных. сам не видел, но судя по другим тематикам, после этого курса вы будете ГУРУ.
А вот как тогда реализовать следующий момент:
есть 4 базы.
ЗУП_1, ЗУП_2, УПП_1 и УПП_2
Из ЗУП_1 Приезжают в УПП_1 СотруднииОрганизаций, далее они автоматически регистрируются в Узле, который увозит их в УПП_2
Необходимо так же организовать обмен из ЗУП_2 В УПП_1, но что бы они не узжали в УПП_2.
Вообще не понимаю как такое сделать...
есть 4 базы.
ЗУП_1, ЗУП_2, УПП_1 и УПП_2
Из ЗУП_1 Приезжают в УПП_1 СотруднииОрганизаций, далее они автоматически регистрируются в Узле, который увозит их в УПП_2
Необходимо так же организовать обмен из ЗУП_2 В УПП_1, но что бы они не узжали в УПП_2.
Вообще не понимаю как такое сделать...
(5) KiLLius, Легко.
Вариант решения: делается в УПП два плана обмена - один между ЗУП и УПП (не РИБ), второй между УПП и УПП. (может быть РИБ)
В плане обмена ЗУП-УПП - добавить реквизит "транслировать в копию" типа булево.
В УПП_1 будет 2 обмена для ЗУП:
между ЗУП_1 и УПП_1 (для этого обмена реквизит "транслировать в копию" - установлен)
между ЗУП_2 и УПП_1
и один обмен между УПП_1 и УПП_2
В плане обмена УПП-УПП - снимается флаг авторегистрации для справочника "Сотрудники".
И пишется обработка регистрации, которая регистрирует изменения для обмена УПП-УПП в тот момент когда элемент справочника "сотрудник" записывается при получении из обмена ЗУП - УПП у которого установлен реквизит "транслировать в копию" . Если сотрудник "приходит" из ЗУП_2, то он не регистрируется для изменения в обмене УПП-УПП. Ну и отдельно учесть правила регистрации, если сотрудник добавляется/редактируется в УПП_1
Вариант решения: делается в УПП два плана обмена - один между ЗУП и УПП (не РИБ), второй между УПП и УПП. (может быть РИБ)
В плане обмена ЗУП-УПП - добавить реквизит "транслировать в копию" типа булево.
В УПП_1 будет 2 обмена для ЗУП:
между ЗУП_1 и УПП_1 (для этого обмена реквизит "транслировать в копию" - установлен)
между ЗУП_2 и УПП_1
и один обмен между УПП_1 и УПП_2
В плане обмена УПП-УПП - снимается флаг авторегистрации для справочника "Сотрудники".
И пишется обработка регистрации, которая регистрирует изменения для обмена УПП-УПП в тот момент когда элемент справочника "сотрудник" записывается при получении из обмена ЗУП - УПП у которого установлен реквизит "транслировать в копию" . Если сотрудник "приходит" из ЗУП_2, то он не регистрируется для изменения в обмене УПП-УПП. Ну и отдельно учесть правила регистрации, если сотрудник добавляется/редактируется в УПП_1
(7) KiLLius, По моему опыту - разработка самих правил обмена занимает 70-90% времени от всей работы по автоматизации обмена. Если вы четко представляете что именно, откуда и куда у вас должно попадать, то проблем с самим программированием нет.
Но сделать так чтобы "новый" объект в конфигурации тоже участвовал в обмена - легким движением руки не получится - если у вас все везде мигрирует, тогда проблем нет. Но если у вас какие-то нюансы,в зависимости от которых экземпляр объекта должен пройти по тому или иному маршруту, то тут придется доделывать обмен для новых объектов конфигурации. Хотя, если ТЗ сделано очень грамотно, и у разработчика прямые руки, то можно элемент "доделывания обмена" свести только к указанию включать или нет новый объект в тот или иной план обмена.
Но сделать так чтобы "новый" объект в конфигурации тоже участвовал в обмена - легким движением руки не получится - если у вас все везде мигрирует, тогда проблем нет. Но если у вас какие-то нюансы,в зависимости от которых экземпляр объекта должен пройти по тому или иному маршруту, то тут придется доделывать обмен для новых объектов конфигурации. Хотя, если ТЗ сделано очень грамотно, и у разработчика прямые руки, то можно элемент "доделывания обмена" свести только к указанию включать или нет новый объект в тот или иной план обмена.
(7) KiLLius, А так вообще-то правила регистрации пишутся в подписке на событие "при записи" нужных объектов. Можно сказать, что каждое правило миграции - это отдельная подписка на события. Включая в эти события нужные объекты вы реализуете тот или иной способ миграции для них. (ну и естественно, что объекты у которых есть подписки на события в которых регистрируются изменения для планов обмена, должны быть прямо или косвенно быть привязаны к планам обмена)
(10) KiLLius,
Без правил - нет обменов.
А вообще, видимо, для вас "курсы" наподобие "втащи себя куда-нибудь...", в том числе и "в обмены" ))
резюмируя всё выше сказанное я так понимаю использовать КД не имеет смысла?
КД - для написания правил обмена, и только для этого.
Без правил - нет обменов.
А вообще, видимо, для вас "курсы" наподобие "втащи себя куда-нибудь...", в том числе и "в обмены" ))
(10) KiLLius,
Можно.
КД - нужна и очень спасает, когда надо обмениваться между нетиповыми конфигурациями, либо производить выгрузку в не 1С базы, когда есть допиленная типовая конфигурация, когда надо разово перегрузить данные из одной конфы в другую и т.п. в этом случае меняют/разрабатывают правила конвертации и используют их либо с существующими планами обменами в конфигурации либо в универсальной обработке обмена (т.е. правила используют при выгрузке/ данных)
А так, реально с извращенными схемами наподобии описанной вами можно обойтись и без КД. (хотя для обмена между разными конфами то лучше все-таки с ним)
резюмируя всё выше сказанное я так понимаю использовать КД не имеет смысла? Всё можно рулить в конфигураторе?
Можно.
КД - нужна и очень спасает, когда надо обмениваться между нетиповыми конфигурациями, либо производить выгрузку в не 1С базы, когда есть допиленная типовая конфигурация, когда надо разово перегрузить данные из одной конфы в другую и т.п. в этом случае меняют/разрабатывают правила конвертации и используют их либо с существующими планами обменами в конфигурации либо в универсальной обработке обмена (т.е. правила используют при выгрузке/ данных)
А так, реально с извращенными схемами наподобии описанной вами можно обойтись и без КД. (хотя для обмена между разными конфами то лучше все-таки с ним)
(10) KiLLius,
В макет плана обмена под названием "ПравилаРегистрации", только план обмена и сама конфигурация должна быть основана на БСП. В УПП далеко не все есть из БСП, и не во всех планах обмена это можно использовать.
И всё таки куда грузить ПРО в упп?
В макет плана обмена под названием "ПравилаРегистрации", только план обмена и сама конфигурация должна быть основана на БСП. В УПП далеко не все есть из БСП, и не во всех планах обмена это можно использовать.
Спасибо ребята! Вроде немного прояснили ситуацию.
И всё таки ещё раз для уточнения, КД позволяет создать правила выгрузки загрузки, причём, используя их к полному плану обмена, можно малыми усилиями настроить лютые обмены. НО если произойдёт добавление реквизита в объект обмена, или ещё хужее, целой табличной части, то придётся перезагружать конфу в КД и следовательно изменять правила выгрузки. Вот реально ли всего этого избежать и использовать КД?
И всё таки ещё раз для уточнения, КД позволяет создать правила выгрузки загрузки, причём, используя их к полному плану обмена, можно малыми усилиями настроить лютые обмены. НО если произойдёт добавление реквизита в объект обмена, или ещё хужее, целой табличной части, то придётся перезагружать конфу в КД и следовательно изменять правила выгрузки. Вот реально ли всего этого избежать и использовать КД?
(15) KiLLius,
Если так боитесь КД (которую 1С позиционирует "ну там ваще все просто!") - давно бы уже написали свой обмен на любом из трех (четырех) оставшихся вариантов обмена.
то придётся перезагружать конфу в КД и следовательно изменять правила выгрузки.
да
Вот реально ли всего этого избежать и использовать КД?
Да.
Если так боитесь КД (которую 1С позиционирует "ну там ваще все просто!") - давно бы уже написали свой обмен на любом из трех (четырех) оставшихся вариантов обмена.
(17) AlexO, ну на самом деле я не боюсь, а хочу решить задачу выбрав наиболее оптимальный способ. И так как опыта в реализации жуткоизвращённых обменов не имею, вот и решил посоветоваться. А так то да, в КД всё просто, но к сожалению не получиться "сделать и забыть"(
(18) KiLLius,
Но нет, максимум, что из себя выдавила 1С - это "текстовое" КД.
Про изменение конфигурации и говорить нечего.
И так как опыта в реализации жуткоизвращённых обменов не имею
Любой обмен в 1С - это тонны кода, и пшик на выходе: сама платформа могла бы автоматически определять, сопоставлять по типу данных поля, и выполнять обмены. В конце концов, все типовые пишет сама 1С, и давно бы могла поля унифицировать или присвоить уникальный код, который можно использовать для автоматического сопоставления и обмена между типовыми (да и при желании нетиповыми - тоже).
Но нет, максимум, что из себя выдавила 1С - это "текстовое" КД.
А так то да, в КД всё просто, но к сожалению не получиться "сделать и забыть"(
Забудьте, платформа неспособна самостоятельно отслеживать изменения и вносить коррективы, поэтому даже занесение "не тех данных" - может привести к краху всего обмена.
Про изменение конфигурации и говорить нечего.
Не слушайте "умников", которых слишком много в этой ветке.
Все Ваши задачи легко решаются через КД (уточню: "легко" - это для меня).
Но сначала мне пришлось как следует выучить КД. Это было сложно и долго (учил по различным курсам и методичкам, коих в инете много, в том числе и бесплатных).
Так что советую потратить время на обучение и только потом браться за поставленную задачу.
Все Ваши задачи легко решаются через КД (уточню: "легко" - это для меня).
Но сначала мне пришлось как следует выучить КД. Это было сложно и долго (учил по различным курсам и методичкам, коих в инете много, в том числе и бесплатных).
Так что советую потратить время на обучение и только потом браться за поставленную задачу.
(28) KiLLius,
КД же строго регламентирует правила обмена, которые, к тому же, надо актуализировать. А у себя - можешь писать обработку всевозможных ошибо, как хочешь. КД же - загоняет в рамки событий "До записи", "После записи", вводит дополнительные не особо непрозрачные сущности "ПКС", "ПКО" и т.д.
Поэтому применение КД - там, где "все типовое", не меняется, нет ошибок, и вообще - все здорово ))
Я понял что нельзя сделать или тем, или тем сложные вещи.
"Своим" обменом можно сделать любые "вещи" - настроить и обмениваться так, как хочешь/позволяет фантазия.
КД же строго регламентирует правила обмена, которые, к тому же, надо актуализировать. А у себя - можешь писать обработку всевозможных ошибо, как хочешь. КД же - загоняет в рамки событий "До записи", "После записи", вводит дополнительные не особо непрозрачные сущности "ПКС", "ПКО" и т.д.
Поэтому применение КД - там, где "все типовое", не меняется, нет ошибок, и вообще - все здорово ))
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот