Com-соединение между базами 1С через интернет #678861

Добрый день! Это мое первое сообщение в данном форуме, прошу извинить, если невольно отступлю от принятых традиций. Кратко о проблеме: com-соединение между двумя базами 1С, расположенными на разных машинах. Есть проблема. Имеются три базы, 2 - файловые 8.1, 1 - серверная 8.2. Эти три базы служат "донорами" данных для четвертой "сводной" базы (8.2 - файловая) В "сводной" базе, по мере необходимости запускается обработка, которая выкачивает данные из предыдущих трех баз, используется com-соединение, объект V82.COMConnector и V81.COMConnector (для соответствующих платформ). Все работает прекрасно, пока файловые базы физически находятся на одной машине, ну и сервер 1С - на ней же (все это стоит на Win 2008) Возникла задача: убрать сводную базу на другой сервер №2, находящийся далеко, за границей. И ВСЕ, никакими путями не получается установить соединение между базами, не смотря на указанный второй параметр - ip-адрес удаленного компьютера. Трудно вспомнить все попытки настроить, в данный момент ошибка следующая "class is not registered" в момент соединения по инициативе базы сервера №2 к базам сервера №1 (неважно, к файловым или серверной базе). Это сообщение относится к серверу №1, с которой пытаемся установить соединение. На самом деле классы на нем зарегистрированы, т.к. локально на сервере №1 сводная база продолжает работать. И на сервере №2 локально - все работает нормально - com-соединения с локальной базы с локальными - осуществляются корректно. При любой попытке обратиться  из бд машины №2 к бд на машине №1 - соединение не осуществляется. После многих поисков в интернете, сложилось впечатление, что ни у кого не стояло подобной задачи. Во всех "примерах работы с com" даже наличие второго параметра (адреса com-сервера) не упоминается. Прошу подсказать возможные решения проблемы именно тех людей, кто решал подобную задачу или хотя бы точно знает, что подобное соединение работает, НА ПРАКТИКЕ. С уважением, Роман

>>Com-соединение между базами 1С через интернет Это как так?? Вы в курсе, что COM работает только в одной сети?

ком через интернет работать не будет, используйте VPN или распределёнку

Почитайте про работу COM, и чем она отличается от маршрутизации.

_3 не вам.

>>используйте VPN тогда уж пусть делают выделенный канал. Надежней будет.

Спасибо за оперативный ответы! VPN сделано - могу, например, указать путь к базе на удаленном компьютере \192.168.0.3d$ase (правда, работать невозможно в таком варианте, тормозит), но com-соединение возвращает ошибку. Теперь вот что-то типа: "сервис RPC не найден" В описаниях по com и dcom я нигде явно не встретил сведений о том, что все это работает только в одной сети. "DCOM через интернет и решение проблемы XP SP2 В 2009 году DComLab опубликовал коммерческий продукт ComBridge. При использовании ComBridge для работы по DCOM через интернет не требуется CIS, не используется 135 порт, в локальной сети не требуются настройки dcomcnfg. ComBridge встраивается в транспортный уровень DCOM, полностью выделяя весь трафик созданного объекта и всех полученных из него объектов в отдельный поток."

dcomcnfg настроен? На веб-сервисах написать обмен не думал?

И еще интересно то, что текст сообщений об ошибке на машине, с которой осуществляется соединение - изменяется, в зависимости от настроек удаленной машины. Если на удаленной машине отменить регистрацию класса или остановить сервис RPC - то ошибки в момент соединения отличаются вариантами. Это означает, что попытка соединения все-таки происходит. В системном журнале так же возникает ошибка DCOM, именно: Параметры разрешений для конкретного приложения не дают разрешения Локальный Запуск для приложения COM-сервера с CLSID и APPID {B292921D-AF50-400C-9B75-0C57A7F29BA1} пользователю NT AUTHORITYсистема с SID (S-1-5-18) и адресом LocalHost (с использованием LRPC). Это разрешение безопасности можно изменить с помощью служебной программы управления службами компонентов.

а у вас что - ComBridge работает? Делайте выделенку.

Придется, видимо, переписывать все на веб-сервисах. Просто работы очень много

>>Это означает, что попытка соединения все-таки происходит это значит всего-навсего - что компонентов DCOM столько, что ошибки возникают в разных местах, но по одной причине.

Если VPN поднят подключайся к базе как обычно. Не нужен тебе никакой DCOM

Да ладно, расковыряй уже эту ошибку, тут же в правах дело

как это как обычно, если она на другой машине?

цитату про ComBridge я упомянул в том смысле, что из контекста фразы следует, что com-соединение, теоретически, должно работать не только в локальной сети. Хотя об этом я и так знаю, когда-то писал программу на Дельфи из пяти строк, запускающую MS Word на чужой машине из другой сети, создающую пустой doc-файл и сохраняющую ее на локальном диске. Тут действительно дело в настройках прав, я думаю. Скорее, нужен спец по dcom. Знание встроенного языка 1С не поможет :)

Ну а ты толстым клиентом как подключаешься к Серверу приложений или путь к файловой? Правда для локальных баз DCOM предпочтительней. Можно использовать прослойку для соединения с базой написанной на другом языке. А начинать надо с настройки DCOM

Кстати если работал с Delphi то там помню был TSocketConnection суть его была в том, что на сервере загружалать прога, которая подгружала нужный ком объект и через IDispatch организовывала транспорт по Tcp/IP и хранение ссылок на объекты. Если есть проблемы с COMConnector можно самому написать самому сервер который будет подгружать "V81.COMConnector". То есть можно решить через прослойки

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

Кстати тебе проще работать через v81.Application для V82.COMConnector  нужно создавать COM+ сервис , так как вызывается DLL При этом все равно нужно свести в минимуму количество вызовов, поэтому лучше организовать внешюю обработку которая будет передавать данные через ХранилищеЗначения Дерево список итд, что будет сериализоватся и не будет объектам хранения в БД (справочники,Документы ..) и на клиенте

УРА. Сердечное спасибо всем откликнувшимся. Решена проблема, на которую было убито куча времени. Теперь файловая база на иностранном выделенном сервере нормально подключается ко всем трем базам (две файловые 8.1 и одна серверная 8.2) на московском сервере и качает нужные данные. Правда, был сделан vpn при помощи KerioVpnClient и использованы рекомендации Serginio1 (19-сообщение в этой ветке). Еще мешал встроенный брандмауэр на win2008 на московском сервере, хотя, вроде бы, не должен был. Думаю, при помощи этих рекомендаций возможна настройка соединения и без VPN, но к сожалению, мне недоступны настройки аппаратного комплекса защиты сервера (брандмаэура), а взаимодействие с человеком, который управляет сетью и железками - затруднено. Поэтому моя битва без VPN была проиграна :) Спасибо всем!