Перенос доработок с копии базы на рабочую среду — стандартный процесс, однако именно на этапе публикации веб-сервисов программисты часто сталкиваются с трудностями. Ситуация, когда веб-клиент успешно открывается, а веб-сервис «не видит» внешние запросы, является классической. Разберем детально, почему это происходит и как восстановить обмен данными.
Прежде чем изменять программный код или настройки базы, необходимо выяснить, «слышит» ли веб-сервер запросы к конкретному сервису. Самый быстрый способ это сделать — попытаться открыть описание сервиса (WSDL) напрямую через браузер. Рассмотрим, как это сделать правильно.
Сформируем ссылку по следующему шаблону:
http://<Имя_Сервера>/<Имя_Публикации>/ws/<Имя_Веб_Сервиса>?wsdl
Проанализируем возможные результаты этого действия:
.1cws не обрабатывается веб-сервером.Файл default.vrd является связующим звеном между веб-сервером и информационной базой. При переносе публикации на рабочую базу ручное редактирование этого файла часто приводит к ошибкам. Проанализируем структуру этого файла.
Убедимся, что путь к базе данных указан корректно в параметре ib. Для файловой базы это путь к каталогу, для серверной — строка соединения с сервером 1С. Рассмотрим пример правильной секции для веб-сервисов:
<ws>
<service name="ИмяСервисаИзКонфигуратора"
alias="service.1cws"
enable="true"
publishExtensionsByDefault="true" />
</ws>
Важный момент: Имя сервиса в атрибуте name должно строго (с учетом регистра) соответствовать имени объекта ВебСервис в дереве метаданных конфигурации 1С. Если на копии и рабочей базе имена различаются, сервис не будет доступен.
Выясним причину, по которой веб-клиент может работать, а веб-сервис — нет. Для работы веб-клиента используются стандартные HTTP-запросы, а для веб-сервисов (SOAP) требуется специальное расширение wsisapi.dll. Если это расширение не зарегистрировано для конкретной публикации или указывает на старую версию платформы, обмен не взлетит.
Выполним следующие действия в консоли управления IIS:
.1cws.bin текущей версии платформы (например, C:\Program Files\1cv8\8.3.XX.XXXX\bin\wsisapi.dll).Если сервер 64-битный, а вы используете 32-битную платформу 1С, обязательно включите разрешение на работу 32-битных приложений в настройках соответствующего пула приложений (Application Pool).
Часто пользователь обмена не виден в списке «Активные пользователи», потому что запрос «отсекается» еще на уровне IIS. Проанализируем настройки проверки подлинности.
В настройках IIS для публикации должны быть включены те методы, которые поддерживает вызывающая сторона (сайт). Если сайт передает авторизационные данные в заголовке запроса, в IIS должна быть включена «Основная проверка подлинности» (Basic Authentication). Если она выключена, IIS может возвращать 401 ошибку, даже не передавая запрос в 1С.
Также проверим права на уровне операционной системы. Пользователь, от имени которого запущен пул приложений IIS (обычно это IIS_IUSRS), должен иметь полные права на чтение и выполнение в папке, где лежит файл default.vrd, а также доступ к каталогу с самой базой 1С (в случае файлового варианта).
Если запрос доходит до 1С, но сессия не создается, проверим карточку пользователя, под которым происходит подключение:
Веб-сервиса.Иногда после внесения изменений в default.vrd или настройки IIS старые параметры продолжают действовать из-за кэширования. Рассмотрим процедуру «жесткого» обновления публикации:
iisreset /stop.default.vrd с диска.iisreset /start.Если технические шаги не помогают, воспользуемся методом, предложенным опытными коллегами. Попробуем объяснить алгоритм работы сервиса «на пальцах» постороннему предмету или коллеге. В процессе детального проговаривания того, как данные идут от сайта к IIS, затем к wsisapi.dll, далее в default.vrd и, наконец, в модуль 1С, часто обнаруживается пропущенная мелочь — например, лишний пробел в пути к базе или неверно указанный порт в настройках брандмауэра.