Есть сеть из РИБ и 10 узлов.
На узлах хотят дать доступ к отчетам из центральной базы.
Набор отчетов небольшой.
Пользователь заполняет значения полей и нажимает кнопку "Запросить отчет".
В центре формируется отчет по переданным параметрам и отправляется назад в виде MXL-макета и визуализируется в 1С.

Как можно решить задачу несложными путями?

Пока видится каталог обмена в локальной сети VPN/FTP, где формируется заявка и выкладывается ответ. И регламентное задание, запускающееся раз в 20 секунд, проверяющее заявки и выполняющее их, выкладывая ответ в каталог.

Но может быть есть более изящное решение?

(0) если канал хороший, то делается отдельная база для отчетов, в которую через терминалку/VPN лезут юзера

засунуть отчет в моксель стрёмно
первый же чудак поставивший группировку по регистратору выгрузит гигабайт

если получится сделать отчет на СКД через веб-сервисы - сколько платите?

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

(2) назовите свою цену. однако хотелось бы понимать сразу лицензионную картину вопроса - должен ли сервер 1с тратить одну дополнительную лицензию при каждом запросе с узла?
В решении через каталог не требуется.

(3) лицензия будет тратится только на момент формирования отчета

главное не крутить особенно большие отчеты

(4) в этом видится недостаток. Хотя с другой стороны, может быть и не такой сильный.
Так сколько стоит Ваше решение?

(6) решения еще нет. просто, сколько вы готовы отдать за такое решение, допустим, если оно тиражное?

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

Думаю, такой сервис несложно написать. Можно оценить по максимуму трудозатрат в два рабочих дня - 16 часов.

Тиражное решение, должно стоить дешевле за счет тиражности, наверное.

вебсервис
отправляем туда настройку для СКД конкретного варианта
получаем результат в виде табличного документа
отправляем обратно
показываем пользователю результат

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

(9) кроме веб-сервисов решения есть? Хотелось бы обладать различными вариантами для выбора.
Веб-сервис - понятное решение, но не простое. Как минимум надо поднять интернет-сервер.

(10)в 7.7 сделано через  netaInet :-)

(10) все остальное с точки зрения организации, отказоустойчивости и трудозатрат представляется более сложным ИМХО

>> ... сервис несложно написать. ...по максимуму трудозатрат в два рабочих дня - 16 часов.

А в чем вопрос-то, раз так несложно? Напиши сам такой сервис.
Можешь заодно в два трудодня попробовать нафигачить через каталог обмена на ФТП.

Потом расскажешь опять про два трудодня.

DCOM внутри VPN. Работало даже на 8.0

(14)+ http://kb.mista.ru/article.php?id=362

(14) так это параметры подключения к центру на филиалах хранить надо

(16) это сложно?

(0) Сделать авторассылку, которая в почту будет рассылать нужные отчеты по расписанию. Все.

(18) нельзя предсказать момент потребности в отчете, получится много спама. Не годится
(15) Т.е. COM-объект создается на узле? В центре SQL-база. Не знаю, как решить проблемы доступа к SQL базе из точки. К тому же это - потенциальная дыра в безопасности. Если можно попасть в центральную базу через COM под роботом, то можно и пароль пользователя подобрать и зайти под приложением.

И вопрос траффика? Хотя если код выполняется на сервере, то может быть.

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

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

вроде в макете скд можно указывать удаленный сервер.
простите если кому халтурку обломал)

(15) DCOM - вообще дыра жуткая.
Причём, некоторые вирусы ищут именно возможность создания удалённого объекта, которому потом "кормят", кривые таблицы интерфеса.
Поэтому, проще пользователям дать подключение к базе, чем DCOM.
Кстати, можно сделать "нетрадиционно" - берётся какой-то экземпляр SQL-сервера, к которому можно подключаться из сети.
Каждый клиент подключается к этому серверу и в определённых таблицах складывает задание.
Робот, запущенный в основной базе, тоже лезет в эту базу и ждёт готовности данных к запросу - потом его исполняет и складывает назад результат или сообщение "дофига данных".
Подключение к SQL висит всегда, режим транзакций позволяет одновременно писать в таблицу, создавая непересекающиеся записи.
Плюс, не надо никаких шар, а только открытые порты - если хочется шифрования, то можно посмотреть в сторону аналогов ZBDee http://sourceforge.net/projects/zebedee/

(22) если огород городить, то сделать как у нормальных людей: взять, например, rabbitmq, написать к нему native ВК для реализации подписок, и гонять по зайцу всё, что надо

(23) Для простого протокола с невысокими требованиями сторонний сервис очередей нафиг не нужен.

Я думаю веб-сервис отличное решение для этой задачи

Получилось в VPN подключиться по COM к центральной базе, так что остановимся на COM-подключении. ;-)