Всем привет!
Есть задача: синхронизация данных 1С и внешней системы (не 1С). Нужен двухсторонний обмен.
Причем 1С должна передавать только изменения данных. Т.е. если 1С передала контрагента, то в следующий раз нужно передать его во внешнюю систему только в том случае, если у контрагента что-то поменялось, какой-то реквизит.
Была мысль сделать план обмена, реализовать нужную регистрацию изменений объектов, анализировать изменения и выгружать их в какой-то файл или напрямую во внешнюю систему (есть описания таблиц SQL внешней системы, т.е. можно напрямую пихать туда данные).
Но все сейчас говорят про веб-сервисы. Мол их очень удобно использовать как раз для задач синхронизации с внешними системами, к тому же это безопасно, потому что нет прямых подключений к внешним базам, и наоборот, в твою базу никто не лазает. В общем это сейчас очень популярно, и главное, как я понял, очень правильно. Хочется попробовать и научиться этому.
Я только начинаю в этом разбираться, но пока не могу понять, реализуема ли моя задача через веб-сервисы в принципе?
Пока всё что я понял - это возможность публикации определенных методов, которые клиент будет вызывать, получая мои данные. Либо наоборот, изменять мои данные.
Но как сделать, чтобы клиент получал только изменения данных? Т.е. тут в любом случае получается связка "План обмена + Web-сервисы"? Без плана обмена не обойтись? Т.е. в методах нужно просто через план обмена получать изменения?
И небольшая путаница с веб-сервисами, ибо в 1С они разделяются на http-сервисы и собственно на веб-сервисы. Первые для меня понятнее, тем более что я как клиент уже использовал их, забирал данные с различных площадок через опубликованные API. Но что лучше в моем случае...
Просьба поделиться соображениями, что в моем случае лучше использовать, в какую сторону мне копать.

План обмена плюс любой транспорт, который тебе больше нравится

Если все в одной сети веб сервисы, как по мне, не нужны.

план обмена + из БСП подсистему истории данных (для регистрации только измененных)

(1) т.е. связка План обмена плюс http-сервисы это норм?
(2) в одной сети, но разработчики внешней базы против прямого подключения. Говорят, что это не правильно, что это прошлый век. Руководство их поддерживает. А я просто плохо знаю эти механизмы веб-сервисов, чтобы дать оценку что лучше. Но если это действительно правильный подход, как везде пишут и говорят, то я тоже за то, чтобы попробовать.
(3) Не совсем понял, план обмена и так содержит регистрацию только измененных, зачем БСП?

(4) да ну?

(0)
ИМХО
Прямое подключение - зло.
- Если изменилась структура таблиц - ошибка.
- Необходимо знать структуру таблиц sql и иметь прямой доступ.
- Если тупит база sql - ожидание, пока протупит.
- Если лежит база sql - ожидание пока отлежится -и у тебя копится очередь.

Http-сервисы - возможно зло.
- Если тупит сервис- ожидание, пока протупит.
- Если лежит сервис- ожидание пока отлежится -и у тебя копится очередь.


Можно выкладывать файликами на обменник ftp(в сетевую папку)
Можно поднять менеджер очередей RabbitMQ - и выкладывать туда сообщения.

(5) Я наверное что-то не понимаю, но делал обмен между двумя 1с-ками. Есть план обмена, в нем нужные объекты метаданных. В коде регистрирую изменения только нужных элементов объектов метаданных. Они автоматически видны в обработке регистрации изменений (как-то так она называется). Т.е. все нужные измененные объекты сами автоматически попадали в регистрацию изменений. Затем правила обмена в КД написаны, по которым идет выгрузка.
Но я не работал с этим вне стандартной обработки обмена, без правил обмена. Т.е. не знаю как самому вытащить зарегистрированные измененные объекты. Но думал что это просто.

(6) "Можно поднять менеджер очередей RabbitMQ - и выкладывать туда сообщения"
А в этом случае реализация на стороне 1С уже будет без всяких веб-сервисов?

(7) таблички Изменения.  . Выбрать …

(3) Реально, зачем подсистему истории данных из БСП ?

при больших объемах изменений - планы обмена зло

(7) что ты имеешь в виду под "изменением"
вот сколько раз пользователь изменил документ нажав на кнопки "Записать" - "Провести" - "Провести и закрыть"?

(10) ну это я загнул - там одна функция нужна - сравнение объекта со ссылкой через сериализацию

(12) 0

(14) вот - и зачем мне обмениваться этим документом?
а бывает надо перепровести ВСЕ документы

(0) Для начала уточни что значит "у контрагента что-то поменялось, какой-то реквизит"?

Его перезаписали в базу или именно поменяли реквизит? А что если поменяли на точно такой же?

+(9) в идеале через файлики. Никто не отвечает .  Файлик есть - загрузил.
Все остальное - деление на зоны ответственности и поддержка доп. функционала
за теже деньги.

(15) Угу и задачка (0) становится очень нетривиальной
Особенно с перепроведением для восстановления последовательности при закрытии месяца

(17) Причем файлики отдельные по измененным объектам а не все в один пихать
Если что много файликов в один слепить не проблема

(19) как они будут создаваться - дело десятое.
Лучше в екселе. Выгрузил - забыл.кто и когда заберет- неважно.

(0) Что бы сделал я:
1. Подписки на события записи, там смотреть ОбменДанными.Загрузка = Истина
Если не служебное то в очередь (РС)
2. Фоновое обслуживает очередь, сериализуя в JSON и отправляя куда то (по http/rest или брокер сообщений или в файлики)

На приеме - вы чего мне выгрузили . Ответ - смотри строку номер 5 файла ексель.

(20) муахаха
это говноподход нубский

(23)+ обмен через эксель это только когда иначе никак

(23) надежен потому как прост . А лом надежен на 99 процентов

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

(4) > т.е. связка План обмена плюс http-сервисы это норм?
Это можно сказать стандарт де-факто для обмена с внешними системами. А внутри json (структуры/массивы на примитивных типах).
Но так как формат обмена будет полностью рукопашный - то чем сложнее структура передаваемых данных, тем геморнее получается. Для простых обменов - вообще минусов нет, одни плюсы.
А web-сервисы - это SOAP. С XDTO внутри - удобно для обмена 1С-1С. Именно потому, что проще со сложными данными.

(27) план обмена есть смысл юзать когда требуется подтверждение доставки и повторная отправка много раз пока не получено подтверждение
если оно нафик не надо и контроль доставки самому сделать то нафик не нужны планы обмена

(27) иногда достаточно лишь плана обмена и пару регламентных заданий, для двухстороннего обмена, без всяких http сервисов)

(28) Даже если не требуется подтверждение доставки - все равно удобно их задействовать. Почему нет? Регистрация измененных так или иначе какая-то нужна, если речь не про распределенные транзакции.
(29) http - это на текущий момент самая удобная "гальваническая развязка" между разными системами, которые потенциально могут менять свое окружение.

(30) + "которые потенциально могут менять свое окружение" -> "окружение которых потенциально может меняться"

(30) да не спорю, прост иногда не нужна такая оперативность доставки данных и достаточен тупо регламент.

1. Для регистрации изменении нужен план обмена.
2. Для транспорта - http-сервис.

(32) Речь не про оперативность. Речь про транспорт между системами. Если системы в одной локалке - тогда есть варианты. А если не в одной? А если завтра они могут разъехаться?

Регламент или событийность какая-то или вообще распределенные транзакции - это отдельный вопрос обмена. Ничего же не мешает по регламенту через http меняться.

(28) У меня сейчас так обмен с мобильным приложением сделан. План обмена регистрирует измененные на мобильном девайсе документы. Выгрузка их идет синхронно - то есть подтверждение успешной загрузки я получаю сразу. И в этот момент просто удаляю запись об изменении. Если будет сбой обмена - значит объект выгрузится при следующей попытке. Удобно, почему нет? Ну, можно тоже самое и на РС сделать. Но какой смысл?

если надо сохранять историю то план обмена не очень удобен
лучше свое на Справочниках/РС

(36) у меня было пару проектов, где достаточно раз в сутки выплюнуть данные на сайт, и каждые 3-5мин спрашивать у сайта, есть ли новые заказы, или нет. В это случае смысл какой то http сервис поднимать, всего 2 рег.задания и привет новый http соединение)

(38) Так у тебя был http-сервис. Просто с другой стороны :)

(37) Для сохранения истории планы обмена вообще не предназначены.

Они придназначены исключительно для регистрации изменений. Что потом делать с этими объектами в РИБ решает система, в не РИБ - разработчик. Можно отправлять получателю, можно удалять, можно еще чего нибудь. В том числе логировать. Но уже не средствами планой обмена.

(39) ну это понятно, я именно про 1совкий думал тут речь в ветке)

(40) я в курсе
но иногда надо сохранять некий срок историю обмена для разборок
и тут удобней использовать нечто свое вместо планов обмена

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

(43) это внешнее хранилище, иногда лучше внутри 1С чтобы ее же средствами сделать поиск по истории

я не против планов обмена!
просто уточняю что они не всегда лучше

(41) Ну, так-то да. Если можно все нормально порешать через http-сервис на той стороне, то конечно это будет намного проще. Плюс свою жопу в инет совать не придется.

Лично я бы опубликовал ODATA и сплавил задачу на разрабов "внешней системы" - типа ипитесь как хотите ))

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

(47) ахах, а в ответ - "у нас лапки". В итоге приходится самому разрабатывать протокол обмена, его странспорт и т.д.

(25) Эксель совсем не прост =) особенно для загрузки - это OLE-с своими приколами,  либо Excellapplication - тяжёлый и как не странно тоже с приколами.
Ещё в экселе сложно с массивами(табличными частями)
Мне JSON нравится.

(40) Именно поэтому не люблю планы обмена =(

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

(50) ну так планом обмена получаешь данные для отправки и суй ты их в json в чем проблема)

(51) История не хранится. Когда поместил в в обмен,  когда отправил. Нужно делать РС - тогда теряется смысл плана обмена.
У меня вообще РС,  Справочник и RAbbit участвуют в обмене, та ещё и логи пишутся в файлы. Зато можно быстро найти момент ошибки в случае проблемы.

(52) можно использовать журнал регистрации, создать отдельную ветку под  это.

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

(52) Ошибки видимо можно быстро. Вопрос как быстро происходит именно регистрация и выборка.

(54) Порядка 20-ти торговых. Порядка 20-ти обменов в день от каждого. Прикинь объемы данных за 2 года работы.

(47) + 100 . И бюджет одноэсника передать тем кто
будет таблички копать.

(55) В РС пишутся объекты быстро и без разбора(ну только минимальный разбор что данный объект нужен обмену). Дальше Рег задание разбирает что оставить к отправке, а что удалить. В момент записи если разбирать, то крайне долго получается.

+ (56) Вообще ИМХО правильно разделять службу регистрации изменений, транспорт и службу логирования.

Я думал про эксель в шутку написали)
Нет, формат конечно типа JSON будет.
Изменения у нас будут очень часто передаваться, много раз в день, много разных объектов. Причем из внешней системы в 1С тоже данные пойдут, но скорее всего в меньшем объеме.
На счет плана обмена правильно подметили. В самом деле, при массовом перепроведении документов как быть? При передаче во внешнюю систему не важны проводки и регистры, важна внутренность самого документа. И если она не меняется, а документ постоянно перепроводят, то план обмена сыграет злую шутку, если не отслеживать самому, изменились ли реквизиты документа. А вот как их отслеживать...
Если использовать подписки на события, то как отследить удаление объектов (физическое). Ну справочники, документы, не удаляем как правило. Но вот регистры сведений допустим, там записи могут удаляться. План обмена может зафиксировать удаление записи регистра.

(47) (57)
Обратное Вебер даёт доступ к MySQL сайта и говорит "Обмен настроен",  а одно эсники уже читаю/пишут и всячески страдают!

(58) Первый же вопрос который возникает при таком подходе - когда система перестанет отмеченный объект передавать в обмен. Когда получит первый получатель (а остальные?) или когда получит последний (и все кто уже получил будут получать его повторно?). Или нужно иметь по одной записи на каждого получателя?

(61) эта эта ситуация проще . Скажут в какие таблички инсертить.Обычный sql.
А вот обратное в 1с через прокладку метаданных …. Внешним долго обьяснять придется

Ещё я пока не понял, если использовать брокер сообщений, типа RabbitMQ , то в этом случае не нужен http-сервис? Он его заменит?

(62) Rabbit менеджер очередей. Он получает успешно и отмечается как отправлено.

(63) Зачем обратно? 1с Так же читает таблицу MySQL "и загружает отмеченные к обмену"

(64) Да. Но и на другой стороне нужно уметь работать с Rabbit ом.

(66) на другой стороне всё умеют, и с раббитом, и с http-сервисами. Вопрос в 1С, как в неё всё это реализовать

(65) тогда да . 1ска инсертит во внешку и селектит из нее .
Файлики не нужны . Сервисы и гирлянды isonoв с xml тоже.

(60) Я как-то делал свой контроль изменений. Брал значения проверяемых реквизитов (проверялись не все, а критичные: контрагент, сумма и т.д.) по ссылке на объект до записи и сравнивал с тем, что указано в текущем объекте. Если не было расхождений - отменял регистрацию.

(68) Не понял. Предлагаешь напрямую во внешнюю SQL писать, и читать из неё? Но мы как раз от этого хотим уйти

вопрос уходить в http-сервисы, или в Раббит, и как это на стороне 1С реализовать (план обмена или что ещё)

(70) А чем текущая реализация не устраивает?

(70) Я так делал раньше - это очень плохо, поверь мне

(71) Еще раз. Планы обмена - суть служба регистрации измененных объектов. "http-сервисы, или в Раббит" или файлы - суть транспорт. И это разные сущности. Нельзя ставить вопрос "или". Вопрос должен стоять "и".

(70) так это работает сейчас ?

(75) это работает сейчас с одной внешней системой. Будет переход на другую внешнюю систему, аналогичную этой, но другую. Эта система будет писаться с нуля, соответственно мы можем всё сделать правильно, уйти от прямых записей в базы. Ну и разработчики этой внешней системы крайне против такого подхода, они и предлагают веб-сервисы и прочее

(76) они сервисы на своей стороне предлагают или ждут сервисов  от 1с ?

(74) я поставил "или" между http-сервисы и Раббит, разве опять что-то не так понял? Т.е. не план обмена или раббит, а план обмена и какой-то транспорт (раббит или http-сервисы,...). Так ведь?

(76) а еще вопрос синхронизации объектов-сущностей встанет

(77) основной обмен из 1С во внешку. Т.е. мы должны опубликовать сервис. Ну и от них тоже будет

(78) если будут входящие в 1С а не только исходящие то план обмена не але

(80) сервис публикуется наоборот, когда надо чтобы внешка постучалась в 1с

(79) это кто такие, объекты-сущности? Справочники? Конечно будет такой обмен, а в чем разница?

(80) т.е внешка ( инициатор) будет опрашивать сервис 1с .

(82) я это и имел ввиду, обмен из 1С во внешку подразумевает, что 1С выкладывает, а внешка стучится и забирает

(84) Да. Но и обратно тоже будет, пока просто непонятно какой объем информации на какой стороне будет вестись.

(78) Ну так - то да.

(81) почему?

(83) это НСИ и документы
Их надо будет как то синхронизировать по неким ID, кодам (уид) или наборам признаков-реквизитов

(89) https://infostart.ru/1c/articles/792952/

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

(89) всё по ГУИД. Сложнее только с регистрами сведений

(80) "Т.е. мы должны опубликовать сервис. Ну и от них тоже будет" А вот это вот плохая идея.
Сервис должен быть один и на одной стороне. А другая сторона будет либо забирать с этого сервиса свои данные или отдавать.

(91) основной учет в 1С

(92) если один вид сущности вводится в разных системах то дубли неизбежны

(93) тут пока не понимаю. Если обмен двухсторонний, то всё-равно должен быть один сервис???

(93) а пойдет это по сценарию …. Сервисов на 1с по причине «там все есть»

(95) это исключено. Источник данных всегда один

(96) достаточно одного сервиса который умеет и туды и сюды
второй лишний

(98) это фантастика и сказки

(96) сервис на стороне 1с удобен например для корзины, к примеру перед оплатой сайт постучался в 1с и убедился что товар есть в наличие и дал оплатить онлайн. А если же речь о получении заказов, то 1ска сама может по крону спрашивать у сайта, а есть ли для меня заказики и загружать если есть. Смысл для этого поднимать сервис со стороны 1с, чтобы сайт пихал заказ сразу как создался, эти 3 мин в большинстве случаев роли не играют.

(101) опять же надо понимать какая нагрузка будет на 1с в этом случае. К примеру тысячи клиентов начнут по 100 раз запрашивать статусы заказов, данные по скидкам/товарам и т.д. и дергать 1ску.

(99) ясно. Просто пока не очень понимаю как реализуется.
(100) нет-нет, это реальность)

(102) у нас не торговля. Синхронизация будет по расписанию. Т.е. неожиданно никто не начнет дергать. Дергать будет внешняя система, по расписанию, определенный набор объектов, каждый раз разный (в течении дня)

(103) в веб сервис ты можешь постучаться с целью выплюнуть данные, или наоборот - запросить. Вот тебе и двухсторонний обмен.

(104) я прост общую логику расписал с примерами, когда сервис удобен со стороны 1с.

(103) У сервиса есть входные параметры (как минимум данные авторизации) и может возвращать какие-то ответы. Все. Этого достаточно.
Например запрос за цены - на входе коды номенклатуры и тип цен, на выходе - табличка цен.
Запрос на создание заказа - на входе код покупателя и табличка заказа. На выходе - табличка резервов. (Ну это так... Пример)

(104) дык опубликуй из 1С http сервис, стандартную ODATA или свое и пусть "Дергать будет внешняя система, по расписанию"

В общем то все уже обозначено. Осталось ТС определиться с тем что он будет пытаться реализовать.
Я - за ПланыОбмена + http сервис на стороне 1С.

https://infostart.ru/1c/articles/899200/

(109) я за планы обмена и http сервис со стороны сайта)

(111) в некоторых случаях напрямую в sql базу 1С

(109) а я за планы обмена + выгрузка во внешний источник

(104) А почему дергать должна внешняя система, если регламент? Дергай из 1С по регламенту - тогда и http-сервис не нужен будет на стороне 1С.

(104) Раз у тебя на той стороне такие умельцы, то пусть все сами и сделают. Скажи им что сумеешь по регламенту дергать ихний rest и засылать им json с примитивными типами. А дальше они сами все разрулят и дадут тебе протокол с форматами. И ты просто будешь через http-соединение работать как им надо.

(115) а те умельцы ждут умельцев на 1с . Кто кого переждет.

А в финале “ а это ваш сервис такой … :)

"трансграничная передача данных"

(0) пусть внешники ваяют на свой стороне все.
Вы дергайте и …. Оперативно тикет во внешний хелп - сервис не доступен просьба разобраться.

(105) "в веб сервис ты можешь постучаться с целью выплюнуть данные, или наоборот - запросить. Вот тебе и двухсторонний обмен."
Т.е. если делаем один http-сервис, допустим на стороне 1С, то это значит, что внешняя система будет запускать методы сервиса для получения данных из 1С. А если нужно наоборот, получить данные из внешней системы в 1С, то опять же внешняя система будет запускать методы сервиса 1С, которые что-то пишут в базу 1С, передавая в эти методы какие-то объемы данных. Так?

(120) к примеру у вас поднят сервис СожриФайл, сайт стукнет гет запросом в 1ску, та возьмет и проверит определенный каталог, если там есть файлы, то сожрет их. Либо поднять POST метод, тогда сайт будет в тушке запроса пихать данные, а 1ска загружать из нее и отвечать, мол спс было вкусно.

(121) на я бы все же эту головную боль переложил на сайт, а 1ска пущай регламенты юзает.

в общем решили, что будет брокер сообщений. Только хотят не RabbitMQ, а Кафку.
Знаю, что крутая штука, но как 1С с ней общается пока не ясно.

Да. Без брокера тут не обойтись. Побольше middleware, нужных и не очень. Нужно же что-то админить.

(123) а много будет систем для обмена? Сколько примерно сообщений в день? А то может получиться, что все эти брокеры будут выглядеть, как С-300 против мухи)

(124) угу и ВК добавить обязательно для работы с брокером

Не, ну если у них kafka уже юзается в качестве эдакой корпоративной шины, тогда может и норм.

Просто обмен через брокера еще и больше ньюансов предполагает.
Вот запулит туда 1С свою чехарду. Считать это сразу успешной доставкой? А потом при выгребании окажется что там фигня какая-то оказалась и данные валидацию не проходят. Что дальше делать?

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

Я к тому, что обмен через брокера сложнее, если все по уму делать.

(128)Если у сообщений нет адресации то нужен ли брокер? Положил в папочку - забрал.

(131) а если 2 системы принимают, то положил в 2 папочки?)

(128) Тогда при обработке данных в шину валится сообщение "перешлите данные пакета Х" или "перешлите данные, начиная с пакета Х". И это сообщение надо обработать на стороне 1С.
Что такого сложного в работе с шиной?

(133) это уже RPC описываешь

(0)

Мысль верная, только надо понимать, что передать файл или постучаться во внеш систему - это транспорт. А то как вы сформируете данные - это второй вопрос, который будет одинаковым для обоих реализаций.

А в целом логичнее взять БСП, забрать от туда п/с ОбменыДанными (+ обязательные подсистемы) и использовать типовой функционал, там уже есть и транспорт через WS, и через файл, и через FTP, почту...

(127) Да, кафка для каких-то задач уже юзается, либо собираются на неё переходить. Руководство высшее ИТ-шное там уже всё решило, они за кафку.

(125) ну вообще как я понял, главная причина - это стабильность. Типа сервис ляжет и кури бамбук. Кафка масштабируемая, производительная, безглючная) Ну и если она объединит в целом всё по компании, то наверное это всё же лучше, чем каждый сервис будет сам по себе барахтаться.

(132) тогда  можно подумать)

(0) "Если все в одной сети веб сервисы, как по мне, не нужны."
А что надо? Лампово-древний COM?
Откуда стереотипчик?

(4) "разработчики внешней базы против прямого подключения. Говорят, что это не правильно, что это прошлый век. "
Все правильно говорят. Ибо покупать мотыгу вместо мотоблока (или древние инструменты против современных) - это так себе.
Даже если площадь маленькая и "кажется что все будет на одном участке в 2 сотки".

(139) Правильно. Давайте ставить кролика для передачи сообщений между двумя соседними комптютерами

(140) правильно давайте плюнем на концепцию API и будем напрямую в базы писать.
А когда контора вырастет в несколько раз и разными базами будут заниматься разные люди (команды), мы полностью все переделаем в авральном режиме (ресурсов и денег ведь докуа, да и не скучно хоть будет). И сделаем наконец так, как нужно было в самом начале.

(141) А если не вырастет, а деньги уже потрачены и создано грандиозное, никому не нужное, сооружение по ГОСТ 26074-84 ?

(47) Чем это отличается от варианта прямого доступа к базе SQL? OData - это не про обмены с внешними системами.

(142) веб сервисы в 1С делать проще, чем с COM и прямыми селектами ковыряться.
- делать проще
- архитектура прозрачнее
- поддержка проще
- изоляция одного от другого - меньше потенциальных багов

+(144) Даже самую малую фигню передать - лучше сразу сделать правильно.
Т.к. даже если контора не вырастет, то хотелки вырастут многократно.
И безобидный "прямой коннектор" превратится со временем в генератор проблем, который к тому же и развивать будет экспоненциально сложнее по мере роста.
А кому оно надо?
Нормально делай, нормально будет.

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

(128) Ничто не мешает настроить 2 очереди. Первая - данные от 1С к внешней системе, вторая - от внешней системы к 1С с квитанциями об успешной обработки. Но тут уже не удастся реализовать на планах обмена, так как уже 3 состояния у объекта: зарегистрирован, отправлен, получено подтверждение.

(142) Что грандиозного в обычном REST или SOAP API? Нет в инфраструктуре шины или брокера и нет уверенности ,то он будет нужен - ну и не надо его вводить. А простые API - это нормально. COM и прямой доступ к БД - это дно.

(148) Что днового в обычном COM-соединении?

(149) долго устанавливается и отваливается по истечении определенного интервала.

(149)
1. Работа COM сильно зависит от окружения. REST или SOAP API универсальны и стабильны.
2. Если для COM-соединения не написан программный интерфейс в приемнике (а если выбрали COM для новой интеграции, то его, скорее всего, не будет), то имеем все риски после обновления нарваться на ошибки, связанные с изменением методов. И система приемник может даже не знать, что ее изменения что-то сломают. REST и SOAP API в этой части намного прозрачнее.
3. COM - это медленно и ресурсоемко.

Вопрос был что вместо COM без шлюза в интернете в качестве сервера для обмена между двумя базами на одном носителе с тем же интерфейсом что и для разных компов в локальной сети?

Офигеть
Казалось бы простейший вопрос и столько обсуждений.
План обмена + шареная папка в сети + там две папки inbox и outbox + файлы json с именем дата в формате ddmmyyyyhhMMss_guid.json - всё! файл загрузил и положил в архивю

(149) Это прям вопрос на собеседование =)
Уже выше писал несколько минусов прямых подключений. Это я ещё забыл проблемы с отладкой.
Самое простое: Если приёмник "Лежит" - у тебя копится очередь - это как минимум.

Проще файлами на шару.

То есть, папка с файлами с некоторых пор надёжнее чем РИБ.

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

(155)
Сам Риб не делал, но других обменов делал очень много
Я чё то запутался, РИБ же вроде тоже через папку с файлами делается?

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

(141) "А когда контора вырастет в несколько раз и разными базами будут заниматься разные люди (команды) ..."

У нас уже всё так)
Контора очень большая, во многих регионах, 20 тысяч сотрудников.
Много команд разработчиков под разные системы.

(153) Вариант неплохой только тем что достаточно быстро переделывается на http/rest или брокер

Если хочется надежную систему,то передачу данных нужно отделить от момента изменения данных,а в изменении просто регистрировать объект к обмену.
Есть такая вещь - правила регистрации объектов в стандартной КД,очень удобно,если можно использовать их.

Если хочется,то можно и свой велосипед,например регистр,где будет ссылка на объект и хэш от его передаваемых полей, если хэш поменялся,то объект нужно отправить.
Только хэш можно рассчитывать или при записи или уже при отправке - это определяется требованием к производительности.
Если,например,из номенклатуры передается несколько полей,а записывается она часто,то каждый раз при записи считать хэш смысла нет - просто регистрируем к отправке,а вот при отправке считаем хэш,и если он поменялся,то отправляем.

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

Ну и формат файла двнных не важен - есть только два формата:
Файлы с последовательным доступом (txt,json,xml и т.п.)
Файлы с произвольным доступом (dbf,pdf и т.п.)
Для передачи данных файлы с произвольным доступом преимущество не дают,т.к.все равно читаются все данные,поэтому,формат может быть любой,если грамотно написаны функции помещения объекта в файл и чтение объекта обратно,то никаких проблем.

Это ж очевидно, вам нужна событийная архитектура, делаете обмен через очередь сообщений на ваш вкус. Однако, если нужна синхронность в обеих системах, то тут без REST никак.

(164) кроме REST есть куча других методик
например gRPC прекрасный штук

Grpc из 1с? 1c может в HTTP/2?

(166) gRPC и без HTTP/2 пашет
через ВК вполне можно

Тут основной вопрос в синхронности - если нужна можно любой синхронный способ, если нет - очередь. Не представляю как в 1с писать protobuf и использовать кодогенерацию для gRPC.

(161) очень разумно на  счет хэша, спасибо

(164) это пока не очень понимаю. REST-интерфейс, как я понял, слегка ограничивает возможности HTTP-сервиса. Если речь о протоколе OData

(137) Тут стандартный trade-off синхронность vs асинхронность. Асинхронность теоретически прикольнее, но она небесплатна. И надо понимать, когда она хорошо окупается, а когда не окупается вообще. В твоей ситуации на первый взгляд она окупается плохо. Но я не знаю всех деталей и могу ошибаться.
(169) Не надо хэш. В том смысле, что хранить его не надо и именно хэш нет необходимости вычислять. Нужен обычный план обмена, только с отключенной автоматической регистрацией. А в перед записью объектов сравниваешь новые данные объекта с хранящимися в БД. И если эти изменения критичны с точки зрения внешней системы - тогда разрешаешь регистрацию изменения к обмену (добавляешь нужные узлы в ОбменДанными.Получатели).

(171) А что в плане производительности? Реализовывали уже такую штуку в нагруженной базе, где тысячами документов в день регистрируют? Так же надо где то структуру проверяемых реквизитов хранить еще и в разрезе объектов, чтобы не по всем проверять.

(172) Типа еще один простой запросик в перед записью станет бутылочным горлышком интегральной производительности? Пфффф.

(126) "угу и ВК добавить обязательно для работы с брокером"
Да, ВК для кафки нужна, и походу она только одна существует, и стоит очень дорого...
А через REST с кафкой нельзя работать? Ну т.е. как я это представляю, дергать её API-методы, через http-запросы...

(174) можно все
и ВК на заказ и через REST с чем угодно, если нельзя напрямую то через прокладку микросервис

На стороне 1С реализуйте как вам нравится, на стороне сайта не ваша проблема. Логично что там API и вам все на блюдечке преподнесли, что туда отправлять. С вашей стороны WEB сервисы для получения данных с сайта. Настройка регистра сведений отправки изменений или план обмена, это ваше решение. Не думаю , что у вас там мега объемы данных, чтобы обсуждать всякие сложности.

(176) У нас мегаобъемы данных)
И уже решено кафку. Решение свыше, не обсуждается. Но оно обдуманное, кафка уже есть в организации, в ней море разных сервисов крутится. Нет там только 1С пока)

(174) Способы дергать Kafka из 1С:
1. Confluent REST Proxy - фирменный REST API, но он глючный - в одной версии норм работал, а в другой по таймауту отваливался.
2. Написать свой REST Proxy на Java, Python, Golang, you name it. Мы написали на Flask.
3. ВК от Серебрянной Пули, у меня она есть, использовал. Но видимо я "неасилил" просто.

В итоге на проде используется способ №2, я там уже не работаю, инфа может быть уже неактуальна.
RabbitMQ удобнее для 1Са, для него есть аж 2 компоненты, и одна использовалась на проде, на одном из прошлых мест работы.

В итоге реализация может быть следующей:
На стороне 1С правила обмена для каждого справочника и т. д, потом реализуете обработчики - обработчики отдают JSON без пробелов и это дело пуляется в Kafka регламентным заданием.
Обратный путь - загружаете сообщения в справочник одним заданием, обходите справочник другим.
По какому-нибудь стандартному заголовку - типа "type" загружаете сущности в БД через обработчики завязанные на этот type.

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

-


НУ ВЫ БЛИН ДАЕТЕ
Столько флуда)


-

Какие веб-сервисы 1С, если 1С передает данные?
Если во внешней системе реализовано API - работать через это API - если нет, то вариантов как бы то и нет))

_

(181) это нормально для мисты, было бы странно, если бы ответили сразу ))

(178) "По какому-нибудь стандартному заголовку - типа "type" загружаете сущности в БД через обработчики завязанные на этот type."
Не понял этого, можно поподробнее?

ну и web-сервисы - это уже давно не "новое" и не такое уж и "удобное".
сейчас более в ходу и востребованы и безглючны и быстры http-сервисы.

(182) не архитектуру же мне за вас придумывать. у нас было сделано на rabbitmq и обработчиках.
в обработчиках в зависимости от отправляемых сущностей формируется json, 1 объект имеет 2 обязательных реквизита.
id, type.
id может быть null, type идетифицирует что мы посылаем.
в attributes лежат данные сущности. вот и посылаем через RabbitMQ массив сущностей в json:

"sender": "petya",
"timestamp": 123 unix time,
"data": [
{"id": 1, "type": "penoplast", "attributes": {"blaBlaBla": "BlaBla"}},
{"id": 112, "type": "sosnovyeShishki", "attributes": {"blaBlaBla1": "BlaBla1"}}
]

вот и все...
а что делать с данными решает принимающая система, ваше дело малое - пульнуть изменения