Разберем ситуацию, которая часто встречается при построении сложных инфраструктур доступа к базам 1С: когда веб-сервис опубликован на внутреннем сервере, а доступ к нему осуществляется через офисный сервер-прокси (например, с использованием IIS и модуля ARR). Часто возникает проблема, когда файл описания веб-сервиса (WSDL) успешно получается клиентом, но при попытке вызвать любой метод (даже самый простой Ping) система выдает ошибку: "Превышено время ожидания". Проанализируем причины этой проблемы и найдем способы её решения.
Выясним, как работает механизм обращения к веб-сервису. Когда мы создаем объект WSПрокси в 1С, платформа сначала обращается по указанному URL, чтобы скачать WSDL-файл. Этот файл содержит описание всех доступных методов, типов данных и, что самое важное, точки подключения (endpoints).
Рассмотрим структуру секции service в типичном WSDL-файле 1С:
<service name="API">
<port name="APISoap" binding="tns:APISoapBinding">
<soapbind:address location="http://192.168.1.50/v1.0/api.1cws"/>
</port>
</service>
Проанализируем ситуацию: если ваш прокси-сервер пробрасывает запрос на внутренний сервер с IP-адресом 192.168.1.50, то 1С сформирует WSDL, в котором в атрибуте location будет указан именно этот внутренний адрес. Когда клиентское приложение (внешний пользователь) получает этот файл, оно пытается отправить собственно SOAP-запрос на выполнение метода напрямую по адресу из location. Естественно, внутренний IP-адрес недоступен из интернета, что и приводит к глухому зависанию и последующему таймауту.
Для того чтобы 1С генерировала правильные ссылки в WSDL, нам необходимо явно указать внешний адрес публикации. Для этого отредактируем файл default.vrd, который находится в каталоге публикации веб-сервиса на стороне сервера базы данных. Нам нужно добавить атрибут publishURL в секцию point.
Рассмотрим пример настройки файла default.vrd:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/v1.0"
ib="Srvr="localhost";Ref="MyBase";"
publishURL="https://api.mysite.ru/v1.0/api.1cws">
<ws>
<point name="API" alias="api.1cws"/>
</ws>
</point>
Важный момент: указание publishURL заставит сервер 1С подставлять в WSDL именно этот адрес. Теперь клиент, получив описание сервиса, поймет, что обращаться нужно к https://api.mysite.ru, запрос попадет на ваш прокси-сервер, а тот уже перенаправит его внутрь сети.
Часто прокси-сервер принимает входящие соединения по защищенному протоколу HTTPS (с SSL-сертификатом от Let's Encrypt), а внутри локальной сети передает запрос на сервер 1С по обычному HTTP. Это называется SSL Offloading. Если сервер 1С не знает, что исходный запрос пришел по HTTPS, он может некорректно обрабатывать сессию или формировать обратные ссылки.
Нам необходимо убедиться, что модуль проксирования (Application Request Routing в IIS) передает информацию об исходном протоколе. Проверим настройки на офисном сервере-прокси:
X-Forwarded-Proto: https.Также проверим, что на сервере 1С в настройках IIS разрешено анонимное управление (Anonymous Authentication), если аутентификация пользователя 1С прописана непосредственно в строке соединения файла api.1cws.
Проанализируем специфику работы IIS. Иногда запросы к веб-сервисам 1С содержат в URL или параметрах специфические символы, которые IIS считает потенциально опасными. Это может приводить к блокировке запроса еще на уровне веб-сервера прокси, что внешне выглядит как таймаут или ошибка 404.
На обоих серверах (прокси и сервере базы) выполним следующие действия в консоли управления IIS:
iisreset в командной строке.Посмотрим на настройки времени ожидания. По умолчанию в модуле Application Request Routing (ARR) установлено время ожидания 30 секунд. Если база 1С долго выполняет запрос (например, при первом обращении происходит "прогрев" кэша или долгая авторизация), прокси-сервер просто разрывает соединение раньше времени.
Для изменения этого параметра выполним шаги:
Рассмотрим, как быстро локализовать проблему, если вышеописанные действия не помогли:
https://api.mysite.ru/v1.0/api.1cws?wsdl. После импорта посмотрите, какой адрес указан в поле Endpoint в самой утилите. Если там локальный IP — возвращайтесь к настройке publishURL.C:\inetpub\logs\LogFiles\). Код ответа 200 означает успех, 502.3 — проблемы с получением ответа от внутреннего сервера (таймаут шлюза).WSПрокси вы правильно используете защищенное соединение. Посмотрим на пример кода:
// Использование защищенного соединения для работы через HTTPS
Соединение = Новый ЗащищенноеСоединениеOpenSSL();
// Создание определения веб-сервиса
Определение = Новый WSОпределения("https://api.mysite.ru/v1.0/api.1cws?wsdl", , , , , Соединение);
// Создание прокси
// Обратите внимание на пространство имен и имя сервиса
WSПрокси = Новый WSПрокси(Определение, "http://api.mysite.ru", "API", "APISoap12");
WSПрокси.Пользователь = "MyApiUser";
WSПрокси.Пароль = "MyPass";
Попытка
Результат = WSПрокси.Ping();
Сообщить("Связь установлена: " + Результат);
Исключение
Инфо = ИнформацияОбОшибке();
Сообщить("Ошибка вызова: " + Инфо.Описание);
КонецПопытки;
Выясним важную деталь: использование WSОпределения позволяет платформе 1С заранее проанализировать структуру сервиса. Если на этапе создания WSОпределения ошибок нет, а WSПрокси зависает на вызове метода — значит, проблема именно в маршрутизации трафика между клиентом, прокси-сервером и сервером 1С, либо в неверных адресах внутри WSDL.
Подведем итог: чаще всего проблема кроется именно в адресе точки подключения. Платформа 1С "честно" сообщает клиенту в WSDL-файле свой локальный адрес, не подозревая о существовании прокси-сервера. Использование атрибута publishURL в файле default.vrd является самым быстрым и правильным способом решения этой задачи.