Получение данных сторонней программой из 1С #719883

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

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

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

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

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

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

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

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

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

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

Например тут )

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

в контексте всем устраивает.

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

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

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

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

вот

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