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

через COM или web - как больше нраицца

(1) webservice универсальнее чем com.

ком, веб-сервис, прямой доступ к базе - по степени извращённости заказчика

(2) согласный, но в случае с com не нужно разворачивать web-сервер и править конфу.

в 7.7 был ещё DDE сервер, извращенно конечно, но бухитоги в екселе можно было посмотреть :)

к (3). прямое соединение не ест клиентские лицензии.

это как преимущество перед com и web

Подскажите где прочитать про ком.

(8) у тебя внешняя программа в какой среде работает?

(8) Например тут ) http://msdn.microsoft.com

(9) Если честно даже не в курсе, у нас есть чувачек который её программирует.

(11) Ну так ты спроси. А то ты предложишь ему через COM получать данные, а окажется, что он на линуксе живет.

(12) под виндой работает (Win 2008)

Я бы предложил вебсервисом.ИМХО самый лучший вариант.
По ресурсам самый незатратный.
Перспективный.
Ошибиться сложнее

Подумай куда и как он будет подключаться? Будет ли стоять 1Ска на каждой машине с установленной внешней программой?

Вебсервис гораздо удобнее. Из затрат всего то написание 1 функции + поднять вебсервер.

(15) 1С стоят на компах со сторонней программой стоять не будет. Веб-сервер вариант для одной базы которая в офисе (серверная), а остальные базы РИБ (65 шт) они стоят локально на точках не вариант.

(16) учитывая кол-во баз рекомендую завести отдельное хранилише (sql, web - что удобнее), куда каждая база будет слать по расписанию либо остатки либо остатки на начало периода + движения.
При запросе к этому хранилищу отдавать сами остатки и "момент актуальности" этих остатков.

я бы на веб запилил - доступ и из 1С и из браузера. Универсально.

Хм, совсем все запутывается.

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

(17) Дык стопудово есть центральная база. Пусть в нее и шлет все и из нее и берет данные.

(19) судя по описанию у него что-то типа сети магазинов, где на каждой точке периферийка.
Если часто слать в центр стандартным методом через РИБ - в центре работать будет нереально.
(16) если я угадал - то лови еще один вариант: отказать от перифериек, всех загнать в одну базу терминально. Тогда все остатки будут в центре всегда онлайн.
Но тут узкое место - блокировки и наличие инета.

по штучке.пицот исполнителям/час
ЗЫ может за мес. и управятся справочники причесать к синхронизации

(20) Подождем топикстартера, что он нам поведает.

(20) а что нереального-то? у меня 60 узлов периодичность раз в полчаса примерно. в центре еще 100 юзеров сидят при этом.

(23) не пробовали уменьшить периодичность до 5 минут? у нас живет без проблем. юзеры довольны.

(24) по некоторым данным (по которым требуется оперативность) так и есть - по отдельному плану обмена. остальное просто не нужно так быстро в ЦО.

(20) угадал

Схема баз у меня такая
Рабочая база -> Обменная база -> Периферийные базы

такая схема сделана из-за блокировок

Вот с периферийных и надо брать актуальную информацию. Но информацию не по всем товарам, а по 1-му. Типа справки.
У меня настроена выгрузка 3 раза в день всего остатка. Но руководству этого мало.

Программер который облаживает прогу предложил вариант обмена файлами, ему якобы проще. в 1С я делаю проверку на этот файл каждые 5 сек. и отдаю другой файл с остатком.
На сколько жизнеспособна данная идея?
Мне что-то она не сильно нравится.

(27) Облажи своего программера матом.

(27)
пародия на "named pipes".

(27) работать будет.
Хотя я бы сделал так:
в конфе (на всех 65-ти базах) подписка на событие при проведении дока - если в доке есть товар, остатки по которому надо отслеживать пишем в базу флаг "нужно обновить данные" (пусть даже константа).
Регламентное задание проверяет флаг и при необходимости обновляет остатки во внешней БД. В случае удачного обновления - флаг сбрасывается.
Вместо флага даже лучше отдельный регистр/справочник - сразу писать туда товары, по которым нужно обновление.

В качестве бд можно сайтик с формочкой на пхп "Номера магазина", "Код товара", "остаток" - сразу есть обратная связь обновили или нет. Можно и просто в скуль писать через адо - тут уже что лучше знаешь - на том и пиши.
Можно конечно и файлики на фтп/smb кидать - но тогда еще нужен сервис, которое это будет проверять и импортировать + учесть возможность файловых блокировок/неполной закачки на фтп и тп.

ИМХО.

(30) спс, идея очень интересная.

(30) а почему сразу из документа фоновое задание не стартовать?

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

(32) а если связи нет? а если проводят пакетно 100 доков?
проще флаг использовать и порциями слать.
(33) не принципиально где - главное в транзакции, что бы при откате флаг вернулся в исходное положение.

(34) если нет связи - само себя стартует через паузу :)

опять же - зачем возвращать флаг? план обмена решает. если нет ничего на обмен - ничего и не передавать

(36) план обмена решает если 1С->1С, а вот если 1С->прога, здесь всё туманно.

(36) при чем тут план обмена? то что я советую - это внешнее место хранения данных - не 1С.
Просто выгрузка не по регламенту а по событию+регламент.
Ну или если узких мест нет - можно просто по событию - так вообще полный реалтайм.
Как именно описать событие на 1С - вопрос вторичный.

(37) планы обмена заруливают в любом случае не-онлайн обмена. в случае онлайн - заруливают вебсервисы, но тут стабильность и скорость канала важна, а то тормозить будет.
(38) план обмена + регл задание, которое по этому плану обмена генерит запросы в вашу внешнюю прогу раз в 10 секунд, допустим.

(39) ты предлагаешь использовать план обмена как индикатор необходимости выгрузки?
Тут есть трабл - например создали документ расхода на 10 единиц - в план очередь на обмен попадает этот документ - регламентное задание обновляет остатки. потом документ снимают с проводки - очередь на обмен не меняется - документ все равно нужно отправлять - соответственно регламентная процедура не выполняется - имеем неправильные остатки во внешней бд.
То есть нужна какая-то чистка плана обмена при выполнении регламентного задания.
Мне проще регистр/справочник завести.

(40) и как это решит константа? провели документ - константа взвелась. провели другой докумнет - она осталась. Распровели первый документ - что делать с константой?

а про "чистку" плана обмена (одна строка кода вообще-то) написано, например, в проф. разработке неплохо. Да и вообще про организацию обменов/интеграций с внешинми системами

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

(43) и чем план обмена тогда не устраивает?

вообщем это не принципиально - кому с чем удобнее работать - то тем и пользуется. Хоть файлик на диске Це создавать.

(44) в контексте (42) всем устраивает.
см (45)

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

из сторонней программы остается только запустить 1С с определенным пользователем и дождаться ответа...

(47)+ работает где угодно, никаких сервисов не нуна писать и через com обращаться, все просто и прозрачно

из минусов тока тормоза на запуск 1С

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

(49) причем тут минус по РБД не понял?

(0) вот http://infostart.ru/public/297399/

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