Что бы вы выбрали?
Есть Центральная база (серверная) и несколько периферийных баз (файловых) на локальных (умеренно удаленных) машинах. Конфигурации совпадают (самописные). Обмены проходят каждые 15 минут. Появилась необходимость в центре получить актуальную информацию из периферии по нажатию кнопки. Первое, что приходит в голову - запрос по COM. Препятствие только в том что базы файловые на локальных компах, до них надо достучаться - надо расшаривать в сеть папки с базами, вроде и взлететь должно без проблем, но и костылями попахивает.
Второй вариант напоминает стрельбу из пушки по воробьям. Поднять на локальных машинах Апач, опубликовать базу в WEB, создать объект XDTO и пользоваться WSПрокси итд.
Или может есть что-то лучше?

(0) Сделай им большую кнопку "Выполнить обмен прям щас!" и всё.

(0) О, это опять ты!))) Плагиаторщик...))

(2) Ага - как-то вот нам не повезло жить в похожих часовых поясах)

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

(0) Сделать обмены каждые 5 минут и объяснить бухам, что секунда в секунду данные они увидят только при терминальном доступе к центральной базе.

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

(4) Так ты добавь своему обмену функционала. Сейчас у тебя обмен по расписанию, сделай ещё и по событию: наличие файла-маркера. И мониторь этот файл-маркер каждые 30 сек.
Появился фай-маркер - пошел обмен.
Создать файл-маркер можно в пару строк кода из любой базы.

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

(6) Идея интересная конечно.

В общем специфика такова, что вся система состоит из 5 центральных и более 15 периферийных баз и обмены - это одно из слабых мест. И нагружать их больше я бы не хотел. При этом мы стремимся к идентичности конфигураций, поэтому решение принятое для этих баз - будет актуальным и для всех остальных.

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

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

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

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

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

(8) Действительно сейчас в центральной базе (в той, в которой возникла необходимость получения инфы по кнопке) периодически фоновое задание обменов блокирует всю работу. Мы боремся с этим. Именно поэтому дополнительный функционал я хотел бы возложить на клиента. Т.е клиент делает запрос по COM в файловую базу - тырит оттуда инфу и показывает в виде отчета - на первый взгляд никакой доп нагрузки на сервер.
(9) Опять же в системе не достаточно гибкости. Переферийных точек много, качество сети у всех разное, к тому же на каждой надо работать с оборудованием. Решение использовать отдельную базу для каждой точки было принято ещё до меня, но мне оно кажется логичным. Да и всех такая система устраивает. С этими 15 базами работает близко к 100 человек - и объяснять каждому, что вы работайте  с этой базой, а если сеть печалька, то запускайте эту и продолжайте с такого-то места. (10) опять же менять/дооборудовать надежную систему потому что так правильнее никто не станет - хотя бы ИБП на всех локальных машинах поставить - уже счастье)

(0) Первое что приходит в голову - это нормальный интернет канал, RDP и отключение периферийных баз.

(12) Это конечно идеальный вариант)
У самой крупной центральной базы 9 перифирийных узлов, на периферийном узле от 1 до 3 устройств на com портах, общение происходит через разные dll-ки. периодичность общения 1 секунда. Видиться мне, что это всё нестабильный гемморой будет, если всё это запустить по RDP.

Еще можно по кнопке создавать флаг  и опрашивать этот флаг периодически из периферийной. На сервере поднять WS, когда флаг появился, периферийная через WS отдает нужные данные в центр.

(13) Ну так можно же не RDP, а TCP/IP... Поднял VPN-туннель и работаешь, как по сети...

Мне одному кажется, что выбранный инструмент (1С) не соответствует масштабу задач?

(16) В смысле, надо вести в Экселе? Или в том смысле, что надо САП внедрять?
В любом случае, я с тобой не согласен :)

(17) САП конечно вариант, но возможно тут что-то самописное нужно или поискать готовое решение. Критериям информационной безопасности такое решение не отвечает. Чуть что упадет и предприятие (я так понимаю серъезное, если вагонами грузят) целиком или частично встанет.

(15) Что не сообщение, так интересная идея)
Жаль, что не эффективно в условиях нестабильной сети.  
(16) Отчего же. Нужна учетная программа по производству и продаже и мониторингу качества продукции. 1С как раз прям.
Причем конфа не крупная получилась и всё работает. Просто потребности растут постоянно, но даже на уровне прогнозов не выходят за пределы возможностей 1С.

(18) Пока всё лежит в отдельных базах и есть бэкапы - всё не так страшно. Сейчас, чтобы не случилось с сетью - можно спокойно продолжать работать.

Скажите уже кто-нибудь, какие недостатки есть в способах, описанных в (0)?

Могу предложить что то типа такого http://infostart.ru/public/297399/
Конечно придется под себя переделывать, зато апач не надо поднимать и настраивать.

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

(21) Я WS поднимал, скажу что это вовсе несложно, но отлаживать трудно, зато работает железобетонно даже при плохих условяих связи. Правда клиент для 1С был на Java написан.

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

периодически - раз в минуту

(23) У меня тут чит) Я только разрабатываю ПО - администрируют другие люди.
(25) ну вот это уже логично и не из пушки по воробьям

(0) я бы сделал на com

Апач недолго поднять - удобно и надежно.

(22) Крутое решение. Я так понимаю написана собственная служба.
(28) похоже и правда самый простой, а главное подходящий путь
(29) Да вроде, но на локальных машинах конечных исполнителей мне кажется, что это уже лишнее.

Где то независимый сервис всегда онлайн который опрашивается регламентным заданием из 1С. На get запрос, прилетает ответ, "выгружайся", post запросом туда выгрузиться, флаг "выгрузился" устанавливать автоматом после успешной выгрузки.

"к тому же на каждой надо работать с оборудованием." ЦЫ(11) Для работы с оборудованием перейти на нормальную SCADA и не пытаться подставлять костыли в виде 1С.
1С - учетная система и с оборудованием да еще распределенным работает только на костылях. Изобретать лисапед конечно можно. Только колеса в таком варианте всегда будут квадратными.

(0) перевести периферийки в терминал, чтобы они работали в онлайне там, где данные нужны, - не вариант?

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

(33) собственно (13) об этом
(34) надо понимать, что получение данных онлайн - это очень маленький % функционала. Это далеко не основная схема работы - это просто спросить "как дела?" у удаленной базы. Просто передать УИД документа, а в ответ получить 30 строк табличной чати этого документа - не надо сразу всю систему под это перекраивать

(35) и для этого вы планируете каждый раз запускать отдельный экземпляр 1с-Предприятия?

Есть еще более быстрый вариант по TCP/IP
v8: v8: Использование сборок .NET в 1С 7.x и 8.x

Промахнулся
v8: v8: Использование сборок .NET в 1С 7.x и 8.x

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

(0) Это все равно будет костыль, делай одно базу, и пусть все коннектится,через web/RDP....

(39) Это значительно легковеснее чем Ole or Web

Только недавно выполнял похожую задачу, делал через ком, может и не так виртуозно, но я бы не сказал что 3 секунды затупа при подключении это критично...