При интеграции систем на базе платформы «1С:Предприятие 8.3» с внешними приложениями разработчики часто используют механизмы Web-сервисов (SOAP). Это проверенный временем и удобный способ организации двустороннего обмена данными. Однако в процессе развертывания и публикации Web-сервисов на веб-серверах (будь то IIS или Apache) можно столкнуться с неочевидным поведением платформы.
Типичный сценарий: при попытке получить WSDL-описание опубликованного веб-сервиса по ссылке вида http://127.0.0.1/erpdemo2/ws/miko_crm_api.1cws?wsdl в браузере или стороннем клиенте возвращается ошибка:
«Session management header or a cookie with session ID is not specified»
В этой статье мы подробно разберем, почему возникает данная ошибка, как работает механизм повторного использования сеансов в платформе «1С:Предприятие», и рассмотрим несколько практических способов решения проблемы для различных сценариев разработки и эксплуатации.
Для того чтобы понять природу этой ошибки, нам необходимо проанализировать файл публикации веб-сервисов — default.vrd. Этот XML-файл располагается в каталоге виртуального приложения на веб-сервере и управляет всеми ключевыми параметрами взаимодействия веб-сервера с платформой 1С.
В файле default.vrd для каждой точки подключения (Web-сервиса) настраивается набор атрибутов. Обратим внимание на пример конфигурации:
<point name="микоПровайдерAPI"
alias="miko_crm_api.1cws"
enable="true"
reuseSessions="use"
sessionMaxAge="3000"
poolSize="10"
poolTimeout="5"/>
Ключевым параметром здесь является reuseSessions (Повторное использование сеансов). Этот параметр определяет, каким образом платформа 1С будет управлять сеансами пользователей при обработке входящих HTTP-запросов к данному веб-сервису.
Платформа 1С поддерживает три режима работы для параметра reuseSessions:
dontuse (Не использовать): При каждом входящем SOAP-запросе платформа создает абсолютно новый сеанс 1С, выполняет требуемый метод и тут же завершает сеанс. Этот режим крайне непроизводителен, так как инициализация сеанса (особенно в тяжелых конфигурациях класса ERP или Комплексная автоматизация) может занимать от 1 до 5 секунд. Тем не менее, в этом режиме получение WSDL-схемы через браузер работает без каких-либо дополнительных условий.use (Использовать / Ручное управление): Этот режим активирует механизм повторного использования сеансов. При этом управление жизненным циклом сессии полностью ложится на плечи вызывающего (клиентского) приложения. Клиент обязан явно управлять сессиями с помощью специальных HTTP-заголовков. Если клиент отправляет обычный GET-запрос (например, из браузера для просмотра WSDL) без этих заголовков, платформа 1С отвергает запрос и возвращает ошибку «Session management header or a cookie with session ID is not specified».autouse (Использовать автоматически): Промежуточный режим, при котором веб-сервер 1С самостоятельно организует пул сеансов. Платформа сопоставляет входящие запросы по параметрам подключения (пользователь, пароль, разделители) и автоматически выделяет свободный сеанс из пула. При этом режиме ручное управление заголовками со стороны клиента не требуется, и WSDL-описание успешно отдается в браузер.Таким образом, когда в файле default.vrd (или в метаданных самого веб-сервиса в конфигураторе) установлено значение use, стандартный браузер не может просто так получить WSDL-схему, так как он не передает обязательные параметры инициализации сессии.
Рассмотрим несколько эффективных способов решения этой проблемы, начиная от быстрой отладки в браузере и заканчивая правильной программной реализацией на стороне интеграционного решения.
Если вам нужно оперативно просмотреть WSDL-структуру или импортировать её в локальный инструмент разработки непосредственно через браузер, мы можем принудительно заставить браузер отправить нужный заголовок инициализации сессии.
Для этого выполним следующие действия:
IBSession.start.http://127.0.0.1/erpdemo2/ws/miko_crm_api.1cws?wsdl.После этого веб-сервер 1С поймет, что мы инициируем новый сеанс, успешно обработает запрос и вернет корректную XML-структуру WSDL-описания.
Если внешняя система интегрируется с вашим веб-сервисом в режиме reuseSessions="use", разработчик этой системы обязан реализовать полноценный жизненный цикл сессии. Разберем этот алгоритм по шагам:
IBSession: start.
Set-Cookie, содержащий уникальный идентификатор сессии, например:
Set-Cookie: ibsession=XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX; path=/;.
IBSession: start. Вместо этого он обязан передавать сохраненные куки в заголовке запроса:
Cookie: ibsession=XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.
IBSession: finish.
Cookie: ibsession=.... Платформа 1С корректно завершит сеанс и освободит лицензию.
Если архитектура интеграционного решения позволяет отказаться от строгого ручного контроля сессий со стороны клиента, мы настоятельно рекомендуем использовать режим autouse. Это избавит вас от необходимости настраивать заголовки в браузере при разработке и значительно упростит код клиентского приложения.
Для перевода публикации в этот режим откроем файл default.vrd текстовым редактором и отредактируем строку описания точки подключения следующим образом:
<point name="микоПровайдерAPI"
alias="miko_crm_api.1cws"
enable="true"
reuseSessions="autouse"
sessionMaxAge="1200"
poolSize="20"
poolTimeout="5"/>
Разберем параметры, которые критически важно настроить при использовании пула сеансов:
sessionMaxAge — время жизни неактивного сеанса в пуле (в секундах). Рекомендуется устанавливать значения от 300 до 1200 секунд (5–20 минут). Если установить 0, то повторное использование сеансов фактически отключится, превратившись в аналог dontuse.poolSize — максимальное количество одновременно удерживаемых сеансов 1С в пуле для данной точки подключения. Настраивается исходя из планируемой частоты запросов и доступных клиентских лицензий.poolTimeout — время ожидания (в секундах) освобождения сеанса из пула, если все сеансы заняты обработкой других запросов.После сохранения файла default.vrd и перезапуска веб-сервера (IIS/Apache) WSDL-описание веб-сервиса станет доступно по прямой ссылке в любом браузере без каких-либо дополнительных манипуляций с заголовками.
При активной разработке постоянная генерация динамического WSDL платформой 1С может замедлять процесс импорта схемы во внешние среды (например, в Visual Studio, SOAP UI или другие базы 1С). Отличной практикой является сохранение структуры веб-сервиса в статичный файл.
Разберем, как это реализовать:
default.vrd в режим reuseSessions="dontuse" или воспользуемся Вариантом 1 с подменой заголовка.http://127.0.0.1/erpdemo2/ws/miko_crm_api.1cws?wsdl.miko_crm_api.wsdl.reuseSessions="use" в файл публикации для обеспечения высокой производительности в продакшене.miko_crm_api.wsdl, а фактический адрес отправки SOAP-запросов (endpoint) перенаправим на боевой URL веб-сервиса 1С.Этот подход гарантирует стабильность среды разработки и исключает зависимость внешних систем от доступности веб-сервера 1С в моменты обновления конфигурации или изменения сетевых настроек.
Применяя данные подходы, мы сможем эффективно настроить высокопроизводительную интеграцию с базой 1С, избежав досадных ошибок авторизации и управления сеансами.