При интеграции систем 1С:Предприятие со сторонними внешними сервисами разработчики часто сталкиваются с необходимостью использования COM-компонентов. Классическим примером такой интеграции является взаимодействие с автоматизированной системой централизованной подготовки и оформления перевозочных документов (АС ЭТРАН) ОАО «РЖД» с использованием библиотеки EtranASUGO.dll.
Типичная проблема возникает в распределенной серверной инфраструктуре. Предположим, у нас есть два сервера: DB-01 (на нем развернут сервер 1С, настроен защищенный канал VipNet и установлена компонента ЭТРАН) и DB-02 (дополнительный сервер 1С, на котором выполняются регламентные задания). Когда регламентное задание запускается на сервере DB-02 и пытается инициализировать объект EtranASUGO.EtranASUGO на сервере DB-01, система выдает ошибку: «Класс не зарегистрирован» или «Интерфейс не поддерживается». Выясним причины такого поведения платформы и разберем по шагам три альтернативных способа решения этой проблемы.
Перед тем как перейти к настройке, проанализируем физический смысл происходящего. Ошибка инициализации COM-объекта на удаленном сервере при выполнении кода Новый COMОбъект("EtranASUGO.EtranASUGO", "trnh-db-01") чаще всего обусловлена следующими техническими факторами:
rphost.exe), как правило, функционирует в 64-битной среде. Если библиотека EtranASUGO.dll является 32-битной, то 64-битный процесс сервера 1С не сможет загрузить ее напрямую в свое адресное пространство.regsvr32.Ниже мы подробно рассмотрим три метода решения этой задачи: от классической настройки распределенного COM (DCOM) до современных архитектурных подходов.
Если мы хотим оставить архитектуру вызова COM-объекта с удаленного сервера без изменений, нам необходимо настроить специальную обертку на сервере DB-01 (где установлена компонента ЭТРАН). Это позволит запускать 32-битную DLL в суррогатном 64-битном процессе операционной системы и управлять правами доступа по сети.
Рассмотрим по шагам процесс настройки службы компонентов Windows:
C:\Windows\SysWOW64\regsvr32.exe "C:\PathToComponent\EtranASUGO.dll"
dcomcnfg и нажмем Enter.Etran_COM_Bridge, и установим способ активации как «Серверное приложение». Это критически важно, так как приложение будет запускаться в отдельном системном процессе dllhost.exe.EtranASUGO.dll.Etran_COM_Bridge и выбрав «Свойства»). На вкладке «Безопасность» снимем флажок «Принудительная проверка доступа для приложений» и установим уровень аутентификации в значение «Отсутствует» (или настроим роли для пользователя, под которым запускается сервер 1С на машине DB-02).После выполнения этих настроек программный код инициализации COM-объекта из базы 1С на сервере DB-02 будет успешно отрабатывать на удаленном сервере DB-01:
ИмяСервераЭтран = "trnh-db-01"; // Имя или IP-адрес удаленного сервера
Попытка
Etran = Новый COMОбъект("EtranASUGO.EtranASUGO", ИмяСервераЭтран);
// Дальнейшая работа с объектом
Результат = Etran.GetSomeData();
Исключение
ЗаписьЖурналаРегистрации("ЭТРАН.Подключение", УровеньЖурналаРегистрации.Ошибка,,,
"Ошибка инициализации COM на сервере " + ИмяСервераЭтран + ": " + ОписаниеОшибки());
ВызватьИсключение "Не удалось подключиться к системе ЭТРАН.";
КонецПопытки;
Важное примечание: Инициализация COM-соединения по сети между двумя серверами может происходить достаточно медленно (в среднем от 5 до 15 секунд). Если регламентное задание запускается часто, этот метод может создать существенные задержки в работе системы.
Если серверы DB-01 и DB-02 объединены в единый кластер 1С:Предприятия, мы можем полностью избежать сетевых вызовов DCOM. Вместо того чтобы вызывать компоненту удаленно, мы заставим саму платформу 1С выполнять конкретное регламентное задание строго на том сервере, где физически установлена DLL и настроен защищенный канал VipNet (в нашем случае это DB-01).
Для реализации этого сценария настроим требования назначения функциональности кластера 1С:
После применения этих правил менеджер кластера 1С будет автоматически перенаправлять выполнение данного регламентного задания исключительно на рабочий процесс сервера DB-01. Код инициализации внутри задания вернется к стандартному локальному вызову, что полностью решит проблему сетевого взаимодействия:
Попытка
Etran = Новый COMОбъект("EtranASUGO.EtranASUGO");
Исключение
ЗаписьЖурналаРегистрации("ЭТРАН.Локально", УровеньЖурналаРегистрации.Ошибка,,, ОписаниеОшибки());
КонецПопытки;
Важное лицензионное ограничение: Возможность гибкой настройки требований назначения функциональности (включая фильтрацию по конкретным именам баз данных и фоновым задачам) доступна пользователям только при наличии серверных лицензий уровня 1С:Предприятие КОРП. На лицензиях уровня ПРОФ данные настройки заблокированы для детальной конфигурации.
Использование COM-технологий постепенно уходит в прошлое. Самым стабильным, быстрым и платформонезависимым подходом является интеграция с АС ЭТРАН через встроенные SOAP веб-сервисы ОАО «РЖД». В этом случае нам не нужно регистрировать библиотеки в реестре Windows, настраивать COM+ и зависеть от разрядности серверов.
Однако возникает другая техническая сложность: защищенный канал VipNet для доступа к ресурсам РЖД настроен только на сервере DB-01. Как же серверу DB-02 отправлять SOAP-запросы, если у него нет прямого доступа в сеть VipNet?
Для решения этой проблемы разберем архитектуру с использованием прокси-сервера:
WSОпределения и WSПрокси, передавая в них параметры нашего прокси-сервера.Посмотрим на пример реализации подключения к SOAP веб-сервису через прокси-сервер:
// 1. Настройка параметров прокси-сервера, развернутого на DB-01
ПроксиПараметры = Новый ИнтернетПрокси;
ПроксиПараметры.Установить("http", "192.168.1.10", 8080); // IP-адрес DB-01 и порт прокси
ПроксиПараметры.Пользователь = "ProxyUser"; // Если на прокси настроена авторизация
ПроксиПараметры.Пароль = "ProxyPassword";
// 2. URL-адрес WSDL-описания веб-сервиса АС ЭТРАН (предоставляется РЖД)
АдресWSDL = "http://etranserver.rzd/AppServer/IEtranSysservice?wsdl";
Попытка
// Инициализация WS-определений с использованием прокси-сервера
Определения = Новый WSОпределения(АдресWSDL, "ИмяПользователяЭтран", "ПарольЭтран", ПроксиПараметры);
// Создание прокси-объекта для вызова методов веб-сервиса
// Параметры: Определения, ПространствоИмен, ИмяСервиса, ИмяТочкиПодключения
ПроксиЭтран = Новый WSПрокси(Определения, "http://tempuri.org/", "IEtranSysservice", "IEtranSysport");
ПроксиЭтран.Пользователь = "ИмяПользователяЭтран";
ПроксиЭтран.Пароль = "ПарольЭтран";
// 3. Подготовка XML-запроса по схеме АСУ-АСУ ЭТРАН
ТекстЗапросаXML = "<EtranRequest>...</EtranRequest>";
// Вызов удаленного метода веб-сервиса через защищенный канал
РезультатОтвета = ПроксиЭтран.ExecuteBlock(ТекстЗапросаXML);
// Анализ полученного XML-ответа
ПроанализироватьОтветЭтран(РезультатОтвета);
Исключение
ЗаписьЖурналаРегистрации("ЭТРАН.SOAP", УровеньЖурналаРегистрации.Ошибка,,,
"Ошибка выполнения SOAP-запроса к ЭТРАН: " + ОписаниеОшибки());
ВызватьИсключение "Не удалось отправить запрос в систему ЭТРАН через SOAP-прокси.";
КонецПопытки;
Этот подход обладает огромными преимуществами. Во-первых, скорость выполнения SOAP-запроса через локальный прокси-сервер занимает доли секунды по сравнению с медленным DCOM-соединением. Во-вторых, код становится полностью кроссплатформенным, что позволит в будущем безболезненно перевести серверы 1С на операционную систему Linux.
Мы детально рассмотрели три способа обхода ограничений при удаленной работе с компонентами интеграции. Выбор конкретного метода зависит от технических требований вашей инфраструктуры, версии лицензий 1С и долгосрочных планов по модернизации систем автоматизации бизнеса.