Попалось где-то обсуждение загрузки информации с удаленных точек через связные сервера. Речь шла не об 1с. И мера была вынужденная, потому как с выгрузкой были какие-то проблемы.
Но автору однозначно дали понять, что это отстой, чтобы центральный узел сам собирал информацию. Не могу сказать, может быть, "отстой" касался именной связных серверов, а не инициативы центрального узла?

Какие по этому есть авторитетные мнения?

(0)[Какие по этому есть авторитетные мнения?]
херня

(1) почему?

(1) можно поподробнее?
У нас сейчас так и работает, потому как разработчикам SQL все время некогда) А во-вторых, не смогли по-другому решить вопрос с очередностью и устареванием пакетов.
Но у нас нарождается новая система. Надо решить вопрос с обменом.

(0) речь про серевер очередей?

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

Что такое корпоративные шины, например, акселотовский DATAREON. Там есть логика по анализу содержимого пакетов? или это просто для гарантированной доставки?

(0)
План обмена + РИБ (или КД) + веб-сервисы - наше всё
Норм же схема, зачем городить огород?
У Вас какие-то исключительные условия?

(7) План обмена - само самой, но только для 1с и только для выгрузки. И речь идет про обмне фронт-енд на SQL, а не про 1с.  
План выгрузки жестко закрепляет порядок выгрузки, и все-равное приходится логику дописывает на необходимость обновления , да еще пообъектно!!!
Плюс ограничения по таймауту и размеру.

"Обмен 1с с SQL" // Подробнее

На некоторых релизах платформы наблюдаются глюки с внешними источниками. Лучше всего делать через сервер очередей - Rabbit MQ например ну или шину данных использовать

"А во-вторых, не смогли по-другому решить вопрос с очередностью и устареванием пакетов."...

"Ну не шмогла я, не шмогла"(цы)

Если взять АРМ кассира Фронтол,то у них синхронизатор построен на прямом доступе в Sql,как они обьясняли,в случае обрыва связи,транзакция автоматически откатывается.
Если сеть удаленных точее на Vpn,то почему бы и нет,а вот без Vpn-а выставлять Sql в интернет не очень хорошо.
В случае обмена с кассовыми местами важно быстрен доставить на точки товары и цены,поэтому,инициатива передачи со стороны главной станции выглядит разумно,т.к.в противном случае,нужно ждать,пока рабочие места захотят забрать данные.

(10) Rabbit MQ бесплатный для корпоративных целей? какие ограничения?
(10) Насчет косячности ВИД - здравая мысль. На какой платформе вы заметили косяки. Мне кажется, последнее время ВИДы работают идеально.
(12) да, VPN. Плюсы вижу в том, что получается гарантированная доставка без накладных расходов - положено в таблицу, значит отправлено. Как принимающая сторона их получает уже не важно, и, во-вторых, не нужно ждать ответа (принципиально в случае длительных обработок)
Если делать WEB обмен без промежуточного звена, то пакеты могут дойти не в том порядке. Делать ставку на то, что пакет всегда один не приходится - длительные обработки будут, это однозначно.
Если делать с серверами очередей, то полученный пакет придется распарсить и, опять же, положить в таблицу, чтобы соединяться с другими таблицами.

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

"Как принимающая сторона их получает уже не важно..." - мда... sorry, но далее не вижу смысла продолжать общение.

PS: Я бы посоветовал автору смотреть не в сторону "Rabbit MQ" (это всего лишь альтернативный канал обмена данными), а погуглить "DATAREON MQ" (обмен с конвертацией данных и тесная интеграция с "1С:Предприятие")... но подумав, решил ничего не советовать.

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

За DATAREON MQ спасибо) Хороший совет)

(14) 150 тыс за DATAREON MQ на три инф.базы?

(13) RabbitMQ  OpenSource- на нем 90% мессенджеров и микросервисов вертиться. Это сервер обмена сообщениями.  Правда  не уверен, что на винде будет легко поднять.

(14) Да за пару недель можно самому обертку над конвертацией написать.

При правильном подходе - отличное решение. У меня сканер сетчатки глаза для СКУД китайский, на него ПО - это тихий ужас. Но умеет подключать к себе базу реляционную. Сделал полностью клиента для работы с этим сканером - просто вьювер данных. Разработка заняла одни сутки. Решению три года, до сих пор работает как часы.

(18) "отличное решение" - это про что именно?
Можно подробнее про сканер? Получаете COM сканера, а через него COM базы, или как?

(19) "Но умеет подключать к себе базу реляционную"

(19) Сканер и 1С не знают ничего друг о друге. Более того, их несколько, сканеров. Я com недолюбливаю, потому как после обновления платформы или апдейтов виндовса с ним вечно проблемы.

(20) ODBC