Здравствуйте. Появилась задача, реализовать обмен несколькими справочниками между ERP(источник) и УПП(приемник). Не могу определиться с оптимальнийшей технологией для этого (Com, Web-сервисы, Http- сервисы). Стандартный обмен с правилами обмена отпадает. Буду благодарен за совет.

(28) Ща почитаю. Спасибо.

(29)+ Вот еще хорошо описано http://catalog.mista.ru/public/792952/

(30) судя по обилию функциональных требований нет здесь ни какого реального времени, поэтому нужен перечень НСИ к обмену

(32) для крошечной MDM без квитирования =)

(34) Ну если есть четко выделенная главная база то на http делать вполне разумно и дешево.
Если же баз >3 и запутанный обмен то кролик. А если еще и денег много то да MDM.

И упаси делать в 2020 году обмен на COM/OLE.

(0) веб-сервисы. Простое, быстрое и лёгкое.

я бы сделал так:

написал бы правила обмена и в ту и другую сторону например КД2.1 (можно КД3)
написал бы http сервис по загрузке (в источнике и в приемнике), естественно развернул бы эти сервисы

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

===========================================================================
в итоге получишь транспорт между базами, который пуляет пакеты туда/обратно
если пакеты довольно маленькие, например только один элемент справочника, то практически в реальном времени обмен можно сделать !
работает такой обмен и на винде и на никсах
и отлаживать обмен довольно просто

===========================================================================

я такой обмен делал на КД2 для УТ11 и 1С Казначейство, и в одну и другую сторону

===========================================================================

ну это я делал такой выбор,
тебе решать что ты выберешь !!!

(0) XML. Быстро и дёшево.

Писать свою обработку. В качестве транспорта использовать XML
На практике все схемы обмена сложные. Например в УПП отгрузка без права перехода собственности, в ЕРП перемещение между складами. В УПП две накладных, в ЕРП одна, и так далее
КД3 в данном случае слишком не гибкий, КД2 можно использовать но все равно гибкости недостаточно, плюс по времени столько же займет сколько и написание своей обработки

на самом деле,если хочется красиво,то отдельный web-сервер,к которому подключаются все,кто хочет что-то кому-то передать,а уже внутрр этого сервера писать сценарии.
всякие кролики и прочий сброд-это только точка-точка,если много точек,то очень часто можно нарваться на волны сообщений.
Com,при расположении баз на одном сервере,илеальное решение,если нкжно online,то есть из одной базв что-то править в другой.
web или http сервисы требуют публикации базы на web-сервере,а это тоже нужно настраивать-да оно проще,чем понять,почему не взлетел Com,но иногда с первого раза не получается.

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

(36) то,что ты не любишь Com,еще не значит,что им не нужно пользоваться.
если две базы на одном Windows сервере и других агентов с другой версией никто не ставил,то Com готов к работе из коробки.

(42) Я люблю и использую COM/OLE когда оно лучше подходят или иначе ну никак.
Но выбирать заведомо херовый вариант когда есть лучшие альтернативы?

Апач ставится и база на нем публикуется за меньше 5 минут.
И все из коробки OData. Не нравится одата - ну так http сервис с одной стороны и http клиент через http-соединение с другой пишутся за полчаса.
Через json любые объекты 1С банально, с одной стороны даже ничего писать не надо (сериализация встроена) с другой чуть кода если метаданные отличаются.

COM/OLE обмен работал без проблем многие годы пока все базы были на одной платформе Обмен Альфа-Авто с КА2 (ERP): что лучше использовать WEB или HTTP сервис вместо COM?.

Веб-/хттп-сервис, а уж как сериализовать и десериализовать - дело вкуса (КД2, КД3, самописное)

А можно ли открыть объект одной 1С-базы из другой кроме OLE механизма?

(0) Если ты не понял, тебе тут телепаты отвечали :)
То что ты написал, это транспортный уровень. Можно написать код так, что одно на другое будет меняться за полдня. Об обмене думай, а не о том com/web/http... ftp/файлы/флешки/перофокарты... девочка оператор.
КД2/JSON/XDTO по любому из трех работает. Так же как и через "ftp/файлы/флешки/перофокарты".

(46) через Ole,ты открываешь предприятие и можешь им управлять,другой способ управления-это сценарии AutoIt,все остальное управлять не позволяет.
По Com можно просто получить объект и вызвать его экпортные функции,это же можно написать через http-сервис и обертку,при вызове метода,например,ВыполнитьМетод - имя метода и параметры отправляются в другую базу,там выполняется вызов метода,а обратно возвращается результат,ну и,если кто-то очень сильно хочет,можно сделать свой ComConnector,который к реальной базе будет обращаться через http-сервис.

есть еще более прикольная штука:
в базе зарускается регламентное задание,оно лезет на сторонний http-сервер за запросом,что делать,там запрос ждет,пока будет готово задание,ну в общем,стандартный LongPulling.
другая база идет на тот же сервер передавать задание.
текущая БСП позволяет запускать регламентное задание из сохраненной в справочник внешней обработки.
так что альтернатива Com есть и без публикации и внесения изменений в базу.

что еще хочу добавить:
если в задании есть создание объекта,то он создантся и пишется в таблицу,а обратно передается его идентификатор,то есть то,что называется moniker в случае Com,за вызовом методов мы пойдем в базу,а параметры можно устанавливать локально.

(42) завязывание на com означает геморрой если придется переезжать на линукс в дальнейшем

(50) Даже разносим базы 1С на разные сервера и начинается геморрой с com.
Разные версии платформы 1С - упс. И еще куча проблем.

(50) @если придется переезжать на линукс в дальнейшем@

А зачем нужен _этот_ геморрой?

(52) сейчас не нужен, а через год вдруг станет нужен?

В ERP есть EnterpriseData (КД3) через web сервисы. https://its.1c.ru/db/metod8dev#content:5852:hdoc
В УПП есть штатный КД3, который нужно допиливать, например взять готовое отсюда "Обмен УПП - ED"  http://catalog.mista.ru/public/444523/product/465895/
В данном варианте нужно пилить только УПП, ERP можно попытаться оставить типовой, правда и для неё есть доработанные правила для КД3.
При обновлении конфигурации ERP дорабатывать обмен КД3 в УПП не потребуется в отличие от любого другого обмена.

(0) Если это всего лишь несколько справочников, то можно не заморачиваться и сделать свой ламповый http-сервис, без трогания БСП, реализовать можно с любой стороны, как удобнее. Пример, если нужно: https://xn----1-bedvffifm4g.xn--p1ai/articles/2017-09-07-exchange-with-internet-services/

(48) > другой способ управления-это сценарии AutoIt
Поподробней бы... возможен ли он, если базы работают на разных версиях (в т.ч. по разрядности) платформы 8.3?

(56) auto-it это язык описания нажатий клавиш,ему на версию 1с наплевать,он любому приложению может передать последовательность нажатий клавиш с гарантией получения(ожиидает готовности приложения)
но,все равно,очерь много нюансов.

(57) У нас COM/OLE механизм появился давно, до моего прихода в компанию, между Альфа-Авто и УПП/КА. Между ними в основном файловый обмен, но он не чаще раза в неделю. Альфа-Авто - торговая база, все там работают, а УПП/КА лишь в основном для отчетности, ну и з/п считают. В Альфа-Авто при создании контрагента есть кнопочка "Найти в УПП/КА", ее всегда нажимают при создании нового контрагента, вдруг он есть в УПП/КА не как покупатель, например, как поставщик общих услуг. Тогда после того как он откроется, ему добавят нужный договор в УПП/КА, а GUID-ы передадутся в Альфа-Авто. Когда деньги придут от контрагента (выписки из банка принимаются в УПП/КА), они упадут на нужный договор. Это лишь мое предположение для чего был внедрен COM/OLE механизм.
Позже у нас появилась фирма, которая не работает в Альфа-Авто, только в своей УПП/КА. А еще позже не свои организации (близкие партнеры), но в пределах локальной сети. Например, нашим нужны детали, которых нет, но есть у партнера. Нужно быстро оформить передаточные документы: у партнера реализацию, в Альфа-Авто ответное поступление. Сейчас они делаются в Альфа-Авто, и тут же COM/OLE механизмом передаются в УПП/КА партнера (или нашей фирмы). Причем в конфигурации УПП/КА партнера ни каких изменений не вносилось.
Существуют и другие примеры использования COM/OLE механизма, например, сверка документов: если обнаружено несоответствие документов, то документ УПП/КА можно открыть прямо из отчета Альфа-Авто.
Еще пример заполнения банковских выписок в Альфа-Авто, тоже используется COM/OLE механизм.
Версию платформы Альфа-Авто вроде повышают, но только 32-х разрядную!?
Пока только свою КА переводим на КА2, но в будущем и партнеры перейдут на ERP/КА2, а COM/OLE механизм для разных версий платформ не работает...
Сейчас задача из Альфа-Авто запустить КА2, и открыть в ней нужный объект (пока по ссылке). Возможно при минимальном изменении КА2?

(58) "задача из Альфа-Авто запустить КА2, и открыть в ней нужный объект"

Скажу честно - идея очень и очень плохая. По кому открывать формы в других приложениях - это была самая большая ошибка МС в своё время...

(59) А иначе придется открывать КА2, искать в ней нужный объект...

(0) HTTP-сервис или Web-сервис в качестве транспорта. Кидаться сообщениями в формате КД.

(11) Чтобы потом не переделывать все заново - лучше сделать так, чтобы работало когда одна база в Москве, а вторая - в Бобруйске.

(61) Принципиальное отличия HTTP-сервиса от Web-сервиса?

(63) Если коротко - в случае http-сервиса параметры и вызываемая функция передаются в адресной строке (можно даже в браузере проверить). С web-сервисом так не получится.

(64) Ну а что проще в реализации?

(65) Да примерно одинаково, если понимать как оно работает. Кому как удобнее - тот то и выбирает.

(66) В моем случае в УПП/КА нужны изменения конфигурации, только в Альфа-Авто?

(65) ИМХО, с http работать проще. И он легче, если предполагается довольно большое количество обращений.
(67) Насколько я понял, тебе нужно получить объект из Альфа-Авто. Тогда да, только в Альфа-Авто делаешь http-сервис, публикуешь его и получаешь через него данные.
Писать там вообще немного.

(68) Уточню сейчас при COM: (58) Например, нашим нужны детали, которых нет, но есть у партнера. Нужно быстро оформить передаточные документы: у партнера реализацию, в Альфа-Авто ответное поступление. Сейчас они делаются в Альфа-Авто, и тут же COM/OLE механизмом передаются в УПП/КА партнера (или нашей фирмы). Причем в конфигурации УПП/КА партнера ни каких изменений не вносилось.

rest full (oData)

(67) Изменения в конфигурацию обязательны на стороне программы-сервера (т.е. к которой будут обращаться). На стороне клиента код может располагаться и в внешней обработке. Хотя если нужна интеграция, придется в обоих конфигурациях менять.

(69) Т.е. фактически партнер дает вам неконтролируемый доступ к своей базе.

(69) Тогда и там и там будет по http-сервису.

(72) Или Web-сервису там и там?

(73) Тяжеловат он, ИМХО.
Но можно и его.

(74) Не желательно чужую конфигурацию менять. О версии платформы еще можно договориться.

(75) Ну можешь через oData тогда попробовать. Но поаккуратней с ним.)

(76) oData требует изменение чужой конфигурации? Как относится к версии платформы?

(73)
Первое что нужно, это разделить в голове транспортный уровень и сами данные. Web и Http умеют просто передавать данные, они не умеют выгружать и загружать их. К ним в паре будешь или КД2 или какие нибудь обработки использовать.
В com не разбираюсь, видел его только в виде транспортного уровня в паре с КД2. Как я понимаю (возможно неправильно), com умеет и передавать данные и загружать/выгружать их.

По разнице между Web и http. Для web можно использовать xdto. И если тебе xdto не надо, используй http.
В паре с http мне json понравился. Запросом получаю данные, преобразую в json, отправляю по http. На другой стороне из json в нормальные 1С данные и программным кодом раскидываю по базе.
При использовании Web + xdto, по сути тоже самое. xdto вместо json. Но для xdto нужно структуру данных создавать. Что хорошо для порядка и плохо из за лишней возни.

(64)"Если коротко - в случае http-сервиса параметры и вызываемая функция передаются в адресной строке (можно даже в браузере проверить)."
Это утверждение правильно только для get запроса. Если я правило понял, get запрос ограничен по длине, поэтому я post использую.

http не безопасный, поэтому лучше https. Настраивается на веб сервере, плюс в коде прописывается. По внешке гонять по впн каналам.

По oData мало что знаю, но когда смотрел на него для своего последнего проекта, побоялся, что он недостаточно гибок. Но возможно я ошибаюсь.
КД2 требует знаний КД2 :) Если таких спецов нет и нет желания учить, то или web или http.

(8) скоро 1С свою интеграционную шину представят )

(0) Если справочники не сильно большие (по сопоставлению и переносу количества реквизитов), то моё мнение, http + json идеальный вариант. Только предусмотреть гарантированность доставки.

к (78) "КД2 требует знаний КД2 :) Если таких спецов нет и нет желания учить, то или web или http."
Это я сильно неправильно написал. web и http не являются заменой КД2. Правильнее в контексте того сообщения надо было написать или json или xdto вместо КД2. Разумеется можно много чего еще. Например свой собственный формат вместо xdto или json. Совсем простые данные в виде обычной строки с разделителями передавал. Но это черевато. Моя строка из трех параметров, дико разрослась в длину став не читаемой.

(79) А можно подробности узнать? Ссылку на партнерский форум, например.
Ну или отменят КД2 и КД3? (т.т.т.)

(78) > Первое что нужно, это разделить в голове транспортный уровень и сами данные.
Данные формируются в базе источника (Альфа-Авто), и передаются в базу приемника (УПП/КА) файловым обменом (Универсальный обмен данными в формате XML) или COM-обменом. Там они записываются, например, создается документ. Конфигурация базы приемника не меняется. А как с Web или http-сервисом?

шина предприятия-этотмехантзм передачи ДАННЫХ.
КД2 и КД3 это механизм преобразования данных для передачи,если вы привыкли напрямую обращаться к документам другой базы,то КД для вас не очень-то и нужно,вы итак знаете,что данные в базах различаются.
не забываем еще,что для http-сервиса или oData базу нужно опубликовать на Web-сервере,если у вас несколько баз,то опубликовать нужно все.

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

и,кстати,у microsoft была еще одна идея передачи данных,которая называлась DDE,но ее действительно похоронили,в отличие от Com,после того,как в Com появились подписки на события.

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

А бывает(будет) тонкий клиент 1С на нескольких базах? Например, несколько вкладок в программе открыты и они из разных баз.

(84) > для http-сервиса или oData базу нужно опубликовать на Web-сервере
Какую базу: источника или приемника, или обе? Публикация базы вроде не меняет конфигурацию?

(87) публикация не меняет,но в ней должны быть написаны web-сервис или http-сервис.
в стандартных конфигурациях oData и web-сеовис для плана обмена есть,а вот все остальное нужно будет написать.
публмкуется,обычно,та база,из которой мы забираем данные,чтобы публиковать другую базу,нужно читать,что такое long pulling.

(86) это называется web-клиент,все базы во вкладках браузера.

(77): oData не требует изменений ни в одной конфигурации (кроме случаев, когда нужно хранить данные о выполненных действиях - да и то  без этого в задаче обсуждаемого класса вполне можно обойтись) - весь функционал можно реализовать в рамках одной обработки, разработанной для запуска на любой стороне (плюс - опционально - файлы настроек если надо).

(88) С браузером понятно. Имеется ввиду прозрачность для пользователя. Не входить в 10 баз, а, например, если полные права, то у такого пользователя при открытии контрагента в БП открывается не типовая карточка контрагента, а расширенная из CRM. Из которой он может запускать разные отчеты как из БП, так и из CRM, ERP. Открыл в БП номенклатуру, полез далее и добрался до её производства, до задания станку с ЧПУ. В конце рабочего дня уже забыл зачем в БП зашел.

(88) > в ней должны быть написаны web-сервис или http-сервис.
в стандартных конфигурациях oData и web-сеовис для плана обмена есть,а вот все остальное нужно будет написать.
По базе источника нет вопросов - это моя база. А вот по базам приемника есть - это чужие базы. В УПП по Web-сервису ничего нет (и не надо - Com все делает), но если партнеры перейдут на ERP или КА2, там по Web-сервису что-то есть. Что-то еще придется писать?

(78) COM позволяет выполнять произвольный код в чужой базе. Это, фактически, аналог открытия неизвестных обработок. Я бы такое не давал по возможности.

(1) COM однозначно. Желательно с передачей текстовых файлов, сконвертированных в JPG и обратной деконвертацией. Ведь поддерживать это чудо будут не просто динозавры, а BDSM динозавры.

(0) про COM не слушай, тебя троллят.

(92) Да, партнеры для COM предоставили доступ к своим базам неохотно, а тут еще в конфигурации что-то писать...

(94) Знаешь способ, что COM/OLE работает, если базы на разных версиях платформы 8.3?

(95) В конфигурации они код видят и понимают, что он может, а что нет. В отличие от COM, где можно произвольный код выполнить.

(96) Делал так, работало у клиента. Забыл как делал. Нужно где-то базу личных знаний завести, а то голова не резиновая.

(98) Я тоже делал с административными правами, но обычному пользователю их не дашь...

(100)

(91) Кароч. Если принципиально не хочется менять базу партнера, то открывай у нее oData и не парь мозги. Будешь через него работать.

(82) зазеркалье почитайте.

(101) Где почитать про обмены oData?

(102) Спасибо, нашел.
Хотел сам сделать такое решение для клиента - связать производственное оборудование с их софтом через промежуточную БП с БСП, которая в свою очередь обменивается с любой 1С по ED. Не сошлись в цене, как потом выяснилось я продешевил раз в 10, но даже это было дорого клиенту.
Первая версия связи была УПП - напрямую со сторонним софтом, обмен в формате ED. Другие пожелали то же самое, но для КА 2. Не срослось.

(104) * промежуточная БД с БСП и подсистемой обмена в EnterpriseData.

(103) В интернете)

(106) Это понятно, конкретную ссылку про oData?

(107)+ Вроде что-то нашел, но не понял, для Com-соединения указываешь сервер (порт, если надо), имя базы, логин, пароль. А тут как? Допустим создал документ в другой базе (приемнике). А открыть его, чтобы посмотреть, подредактировать смогу через oData?

(108) Сможешь.

(109) Как? (не нашел примера)

(110): например http://catalog.mista.ru/public/802385/

(111)+: http://catalog.mista.ru/public/719982/

ну и http://catalog.mista.ru/public/565435/

(111) Пытался разобраться по этой ссылке (по остальным вроде одна вода), вроде из базы-источника на Web-сервер посылаются параметры: ПараметрыHTTP = Новый Структура("ИнтерактивныйРежим,Соединение,АдресРесурса,ТекстЗапроса,ЗаголовокHTTP,КодСостояния,Ответ,ТекущийОбъект,КритическаяОшибка,Метод",
        ИнтерактивныйРежим, Соединение, "", "", ЗаголовокHTTP, 0, "", Неопределено, Ложь, Неопределено); (в Соединение Новый Структура("Сервер,БазаДанных,Пользователь,Пароль")) эти параметры передаются в базу-приемник, там создается объект (если нужно), формируется какой-то Ответ, который тоже добавляется в ПараметрыHTTP, все возвращается в базу-источника, там анализируются: удачно все прошло или нет.
Но как открыть объект (его форму, как при Com/OLE) другой базы, чтобы его посмотреть, так и не понял. Возможно ли такое с помощью oData? Или это уже решать нужно другими средствами?

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

COM must die. HTTP-сервисы must have

(21) сериализация-десериализация. Вариантов масса

Если структура справочников одинакова, то всё совсем просто. Если различается, то лучше всего использовать КД. А коль КД отпадает, можно, например, преобразовать объект в JSON

(115) Только Com/OLE может, никакой другой механизм (в т.ч. oData) этого не может?

(114) Ты можешь сделать форму у себя и заполнить ее параметрами, полученными из другой базы.

(120) В Альфа-Авто некоторых документов вообще нет, которые есть в УПП/ERP/КА2, например, банковские. Вместо них одна Выписка. Сейчас можно из Альфа-Авто с помощью Com/OLE открыть документы УПП/КА1, но не очень надо...

(121) А что смотрят в этих документах? Сделай форму в виде справки именно по тем данным, которые смотрят.

(122) Тоже самое спрашиваю у пользователей - молчат... вроде как-то иногда надо.

(119) через Application можно управлять 1с как это,обычно,делается с Excel.
то есть открывать формы,вводить данные и т.п.

через Com уже форму не открыть,так как клиентской части в соединении нет,но можно получать практически все обьекты 1с,которые есть на сервере и вызывать их стандартные и экспортные методы,в том числе запррсы и скд.

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

(123) Ну вот как скажут, что надо - значит действительно надо. А пока - просто любопытство.

(123) Отключи. Сразу узнаешь.

(124) Ради ликбеза: аппликатион (с) - это тоже ком.
Используй правильные термины...

(125) Например, в Альфа-Авто скрутили отчет по сверке документов, нашли один отличающийся документ в УПП. Этот документ изначально был сформирован в Альфа-Авто, передам в УПП. Сейчас в УПП его можно открыть из Альфа-Авто. Посмотреть: кто его менял, по какой причине - может сходу найдутся ответы... А при переходе на ERP/КА2 такой возможности не будет. Но эта задача не обмена. Наверное есть методы, имея ссылку на документ из Альфа-Авто, открыть его в ERP/КА2? (при работающем Com/OLE он не нужен)

А публикация Web-сервис базы-приемника в любом случае нужна? (кроме Com/OLE)

(125) Еще вопрос не теме: по найденной ссылке можно сразу открыть объект в базе-приемнике типовыми средствами, или нужно писать обработку?