Двусторонний обмен УПП - ERP
1С:ERP Управление предприятием 2
1С:Конвертация данных
1С:Управление производственным предприятием
Платформа 1С v8.3
Имеются две конфигурации: нетиповая УПП и типовая ERP Управление предприятием, между которыми необходимо настроить обмен. Для обмена имеются правила обмена УПП-ERP и ERP-УПП. Теперь нужно реализовать непосредственную процедуру обмена и разрешения коллизий, т.к. обмен двусторонний и начать процедуру обмена может как одна, так и другая конфигурация в любой момент.
В обменах я не специалист, поэтому вижу несколько вариантов решения данной задачи.
Регистрация изменений:
- Планы обмена или регистр, в который записываются измененные объекты;
- Регистр, который содержит в себе дату начала и окончания обменов. Необходимо для исключения коллизий (например, чтобы база 1 не запустила обмен, т.к. база 2 уже его выполняет).
Технология обмена:
- Вызов базы 1С через COM или OLE;
- WEB/HTTP-сервисы;
- регламентное задание и файл с выгрузкой.
Подскажите, пожалуйста, какую лучше технологию использовать? Каким образом лучше разрешать коллизии? Может быть, посоветуете какие-нибудь статьи по обменам.
Буду рад любому конструктивному мнению!
p.s. Всех с Наступающим Новым годом :)
В обменах я не специалист, поэтому вижу несколько вариантов решения данной задачи.
Регистрация изменений:
- Планы обмена или регистр, в который записываются измененные объекты;
- Регистр, который содержит в себе дату начала и окончания обменов. Необходимо для исключения коллизий (например, чтобы база 1 не запустила обмен, т.к. база 2 уже его выполняет).
Технология обмена:
- Вызов базы 1С через COM или OLE;
- WEB/HTTP-сервисы;
- регламентное задание и файл с выгрузкой.
Подскажите, пожалуйста, какую лучше технологию использовать? Каким образом лучше разрешать коллизии? Может быть, посоветуете какие-нибудь статьи по обменам.
Буду рад любому конструктивному мнению!
p.s. Всех с Наступающим Новым годом :)
По теме из базы знаний
Найденные решения
Проще писать через COM.
Универсальнее - через файл/WEB/HTTP
Чтобы не было коллизий, вызывайте обмен с одной стороны. Например, при обмене через WEB последовательно выполняйте шаги в базе 1:
1. Формирование пакета с данными 1->2
2. Вызов функции базы 2 для приема данных. Эта же функция возвращает пакет с данными 2->1.
3. Прием данных 2->1. Очистка регистрации изменений в базе 1.
4. Вызов функции базы 2 "Прием успешен". Очистка регистрации изменений в базе 2.
Универсальнее - через файл/WEB/HTTP
Чтобы не было коллизий, вызывайте обмен с одной стороны. Например, при обмене через WEB последовательно выполняйте шаги в базе 1:
1. Формирование пакета с данными 1->2
2. Вызов функции базы 2 для приема данных. Эта же функция возвращает пакет с данными 2->1.
3. Прием данных 2->1. Очистка регистрации изменений в базе 1.
4. Вызов функции базы 2 "Прием успешен". Очистка регистрации изменений в базе 2.
(10) все правильно понимаете. Обычно данные вводят в центральной базе, далее они мигрируют. Если делать в 2 база ввод. Тогда придется решать не коллизии, а вопросы с дублями. Коллизии будут возникать когда в 2 базах 1 объект отредактировали. Администратор базы или администратор обмена будет такие проблемы разруливать!
Даже если ввод данных будет в 1 базе, то коллизии все равно будут и их администратор должен будет решать. Чтобы их минимизировать нужно административно решить где заполнять данные и все.
Даже если ввод данных будет в 1 базе, то коллизии все равно будут и их администратор должен будет решать. Чтобы их минимизировать нужно административно решить где заполнять данные и все.
Есть готовое решение
"Обмен УПП - ED"
"Правила синхронизации ERP 2 - ED"
УПП может быть нетиповой и любой версии.
ERP аналогично может быть любой версии, с доработками и постоянно обновляться обновлениями от 1С. На обмен не повлияет, работать будет.
Используется план обмена в обеих базах. Обмен через каталог или FTP или почту. Можно запустить по расписанию.
"Обмен УПП - ED"
"Правила синхронизации ERP 2 - ED"
УПП может быть нетиповой и любой версии.
ERP аналогично может быть любой версии, с доработками и постоянно обновляться обновлениями от 1С. На обмен не повлияет, работать будет.
Используется план обмена в обеих базах. Обмен через каталог или FTP или почту. Можно запустить по расписанию.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Проще писать через COM.
Универсальнее - через файл/WEB/HTTP
Чтобы не было коллизий, вызывайте обмен с одной стороны. Например, при обмене через WEB последовательно выполняйте шаги в базе 1:
1. Формирование пакета с данными 1->2
2. Вызов функции базы 2 для приема данных. Эта же функция возвращает пакет с данными 2->1.
3. Прием данных 2->1. Очистка регистрации изменений в базе 1.
4. Вызов функции базы 2 "Прием успешен". Очистка регистрации изменений в базе 2.
Универсальнее - через файл/WEB/HTTP
Чтобы не было коллизий, вызывайте обмен с одной стороны. Например, при обмене через WEB последовательно выполняйте шаги в базе 1:
1. Формирование пакета с данными 1->2
2. Вызов функции базы 2 для приема данных. Эта же функция возвращает пакет с данными 2->1.
3. Прием данных 2->1. Очистка регистрации изменений в базе 1.
4. Вызов функции базы 2 "Прием успешен". Очистка регистрации изменений в базе 2.
(2) какой путь лучше выбрать, регистрировать изменения через планы обмена или через регистр?
Тот путь, который вы описали, он подразумевает, что одна база будет ведущая, другая — ведомая. хотелось бы, чтобы они были равноправными и каждая из них могла начать обмен. Или не стоит заморачиваться?
Тот путь, который вы описали, он подразумевает, что одна база будет ведущая, другая — ведомая. хотелось бы, чтобы они были равноправными и каждая из них могла начать обмен. Или не стоит заморачиваться?
(8) спасибо.
Всё же хотелось ещё уточнить, как разрешать коллизии. Стоит ли делать систему ведущий-ведомый, чтобы только одна база могла начинать обмен, а вторая была подчиненная, или сделать их равноправными? Ведь если они обе начнут одновременно передавать данные, начнутся конфликты. Или я что-то не понимаю?
Всё же хотелось ещё уточнить, как разрешать коллизии. Стоит ли делать систему ведущий-ведомый, чтобы только одна база могла начинать обмен, а вторая была подчиненная, или сделать их равноправными? Ведь если они обе начнут одновременно передавать данные, начнутся конфликты. Или я что-то не понимаю?
(10) все правильно понимаете. Обычно данные вводят в центральной базе, далее они мигрируют. Если делать в 2 база ввод. Тогда придется решать не коллизии, а вопросы с дублями. Коллизии будут возникать когда в 2 базах 1 объект отредактировали. Администратор базы или администратор обмена будет такие проблемы разруливать!
Даже если ввод данных будет в 1 базе, то коллизии все равно будут и их администратор должен будет решать. Чтобы их минимизировать нужно административно решить где заполнять данные и все.
Даже если ввод данных будет в 1 базе, то коллизии все равно будут и их администратор должен будет решать. Чтобы их минимизировать нужно административно решить где заполнять данные и все.
Есть готовое решение
"Обмен УПП - ED"
"Правила синхронизации ERP 2 - ED"
УПП может быть нетиповой и любой версии.
ERP аналогично может быть любой версии, с доработками и постоянно обновляться обновлениями от 1С. На обмен не повлияет, работать будет.
Используется план обмена в обеих базах. Обмен через каталог или FTP или почту. Можно запустить по расписанию.
"Обмен УПП - ED"
"Правила синхронизации ERP 2 - ED"
УПП может быть нетиповой и любой версии.
ERP аналогично может быть любой версии, с доработками и постоянно обновляться обновлениями от 1С. На обмен не повлияет, работать будет.
Используется план обмена в обеих базах. Обмен через каталог или FTP или почту. Можно запустить по расписанию.
(15) Используется типовой план обмена УППУПП. Все механизмы типового обмена задействованы. В нужный момент идёт подмена алгоритма формирования xml файла.
Внешняя обработка, подключенная штатно в режиме предприятия автоматически запускается, готовит xml и оставляет его там, где он должен быть.
Далее типовой транспорт отправляет xml файл по назначению.
Приём файла аналогично - внешняя обработка перехватывает типовой алгоритм, загружает xml, отменяет регистрацию, сообщает о результате.
Внешняя обработка, подключенная штатно в режиме предприятия автоматически запускается, готовит xml и оставляет его там, где он должен быть.
Далее типовой транспорт отправляет xml файл по назначению.
Приём файла аналогично - внешняя обработка перехватывает типовой алгоритм, загружает xml, отменяет регистрацию, сообщает о результате.
(17) в 15-м году проверил идею, заработало, внедрил клиенту в старую УТ 10.3.5. Для обмена с постоянно обновляемой БП 3.0. До сих пор работает. Пару раз требовалось небольшое обновление.
С тех пор для других клиентов доработка функционала и расширение видов конфигураций.
Внедрение максимально простое - несколько строк в одной обработке или модуле.
С тех пор для других клиентов доработка функционала и расширение видов конфигураций.
Внедрение максимально простое - несколько строк в одной обработке или модуле.
(14) прочитал вашу статью про КД 3 (ранее с ней не сталкивался) и почитал про ваши продукты для обмена с использованием ED. Очень интересно, но не совсем понятно, подойдет ли это в моем случае.
Потому что в моем случае УПП очень сильно доработанная, типовой план обмена УПП-УПП не подойдет, его придется дорабатывать + есть уже самостоятельно разработанные правила обмена для нашей УПП - ERP.
Правильно ли я понимаю, основной плюс вашей разработки в том, что не "сломается" обмен после обновления ERP? Т.к. сама структура ED обновляется вместе с конфигурацией ERP. От возникновения конфликтов и коллизий, ваша разработка не будет панацеей.
И ещё вопрос, почему именно файловый обмен а не с помощью других технологий?
Заранее извиняюсь, если я где-то неправильно выразился. С КД3 я ни разу не работал и ещё много чего не знаю.
Потому что в моем случае УПП очень сильно доработанная, типовой план обмена УПП-УПП не подойдет, его придется дорабатывать + есть уже самостоятельно разработанные правила обмена для нашей УПП - ERP.
Правильно ли я понимаю, основной плюс вашей разработки в том, что не "сломается" обмен после обновления ERP? Т.к. сама структура ED обновляется вместе с конфигурацией ERP. От возникновения конфликтов и коллизий, ваша разработка не будет панацеей.
И ещё вопрос, почему именно файловый обмен а не с помощью других технологий?
Заранее извиняюсь, если я где-то неправильно выразился. С КД3 я ни разу не работал и ещё много чего не знаю.
(20) Добрый день!
План обмена УПП-УПП подойдет, т.к. он используется только для регистрации объектов. И состав плана обмена самый полный. Правила обмена УПП не используются и не требуют доработки.
>есть уже самостоятельно разработанные правила обмена для нашей УПП - ERP.
для КД3 они не требуются и не могут быть использованы, разве, что для анализа что куда и как передавать.
Если в ERP обновляется формат ED, это не повлияет на обмен со старой УПП, т.к. будет использован тот формат, который есть в обеих конфигурациях.
В УПП и в ERP этих форматов несколько 1.4, 1.5, 1.6, 1.7.
Если в ERP появится формат 1.8, обмен не поломается, т.к. никуда не денется 1.7. Под ним и будет обмен.
Обмен посредством файлов через папку, FTP или почту, т.к. он присутствует в обеих конфигурациях. Прямой обмен через COM не поддерживается, т.к. потребуется доработка УПП, которая сведёт на нет универсальность и появится зависимость от конфигурации ERP.
План обмена УПП-УПП подойдет, т.к. он используется только для регистрации объектов. И состав плана обмена самый полный. Правила обмена УПП не используются и не требуют доработки.
>есть уже самостоятельно разработанные правила обмена для нашей УПП - ERP.
для КД3 они не требуются и не могут быть использованы, разве, что для анализа что куда и как передавать.
Если в ERP обновляется формат ED, это не повлияет на обмен со старой УПП, т.к. будет использован тот формат, который есть в обеих конфигурациях.
В УПП и в ERP этих форматов несколько 1.4, 1.5, 1.6, 1.7.
Если в ERP появится формат 1.8, обмен не поломается, т.к. никуда не денется 1.7. Под ним и будет обмен.
Обмен посредством файлов через папку, FTP или почту, т.к. он присутствует в обеих конфигурациях. Прямой обмен через COM не поддерживается, т.к. потребуется доработка УПП, которая сведёт на нет универсальность и появится зависимость от конфигурации ERP.
(21) видимо, я не совсем понятно описал ситуацию: есть ли смысл начинать использовать КД3, когда уже созданы правила обмена под КД2? По большому счету, на данный момент осталось только решить вопрос с тем, как автоматизировать процедуру обмена и регистрацию измененных объектов. Сам обмен уже работает с разработанными правилами, если вызывать его вручную.
УПП нетиповая, в ней много создано дополнительных объектов конфигурации. Правила обмена это учитывают (когда, например, два документа в УПП нужно объединить в один в ERP и наоборот).
Понял, спасибо за ответ.
План обмена УПП-УПП подойдет, т.к. он используется только для регистрации объектов.
УПП нетиповая, в ней много создано дополнительных объектов конфигурации. Правила обмена это учитывают (когда, например, два документа в УПП нужно объединить в один в ERP и наоборот).
Обмен посредством файлов через папку, FTP или почту, т.к. он присутствует в обеих конфигурациях.
Понял, спасибо за ответ.
(22) Однажды у меня была подобная задача. Правила вроде почти готовы, а автоматизации никакой. В итоге потом получилось, что затрат на автоматизацию оказалось больше, чем на правила.
Второй раз на те же грабли решил не наступать и попробовал КД3. Получилось тиражировать этот подход. Внедряется один раз и потом не зависит от обновлений второй базы.
В Вашем случае зависит от объёмов доработок. Может получиться, что сейчас доработать имеющиеся правила будет быстрее, а потом придётся обслуживать обмен и поддерживать актуальность после обновлений ERP.
С КД3 внедрить готовое получится сразу и запустить обмен типовыми объектами. Потом потребуется время чтобы разобраться с нетиповыми объектами. Всё зависит от желания разобраться в доработке КД3.
Второй раз на те же грабли решил не наступать и попробовал КД3. Получилось тиражировать этот подход. Внедряется один раз и потом не зависит от обновлений второй базы.
В Вашем случае зависит от объёмов доработок. Может получиться, что сейчас доработать имеющиеся правила будет быстрее, а потом придётся обслуживать обмен и поддерживать актуальность после обновлений ERP.
С КД3 внедрить готовое получится сразу и запустить обмен типовыми объектами. Потом потребуется время чтобы разобраться с нетиповыми объектами. Всё зависит от желания разобраться в доработке КД3.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот