Как найти HTTP-сервис в 1С и настроить права доступа, если он не виден в списке публикаций?

Программист 1С v8.3 (Управляемые формы) 1C:Бухгалтерия IT и автоматизация бизнеса
← На главную

Часто в практике интеграции систем на базе «1С:Предприятие» возникает ситуация, когда одна база (например, «Управление торговлей») пытается обратиться к веб-сервису другой базы (например, «Бухгалтерия предприятия»), но при анализе приемника администратор или программист не может обнаружить следов публикации этого сервиса. Рассмотрим детально, как устроена механика публикации HTTP-сервисов, где искать «пропавшие» объекты и как правильно настроить права доступа, чтобы обмен работал стабильно.

Анализируем структуру URL-адреса

Для начала разберем адрес, по которому происходит обращение: http://sqlxxx.xxx.local/BUHv2/hs/obmen_ut. Проанализируем его составляющие, чтобы понять, где именно «живет» этот сервис:

  1. sqlxxx.xxx.local — сетевое имя сервера, на котором развернут веб-сервер (IIS или Apache).
  2. BUHv2 — имя публикации (виртуального каталога) на веб-сервере. Если при переходе по ссылке http://sqlxxx.xxx.local/BUHv2 открывается 1С, значит, база успешно опубликована.
  3. hs — этот сегмент однозначно указывает на то, что мы имеем дело с HTTP-сервисом (от англ. HTTP Service). Если бы там было ws, мы бы искали SOAP Веб-сервис.
  4. obmen_ut — это Корневой URL конкретного HTTP-сервиса, заданный в свойствах метаданных 1С.

Выясним причину, по которой сервис может быть не виден в стандартном окне публикации. Чаще всего это происходит потому, что в настройках публикации установлен флаг «Публиковать HTTP-сервисы по умолчанию». В этом случае все HTTP-сервисы, созданные в конфигурации или расширениях, становятся доступными автоматически без необходимости их ручного перечисления.

Поиск публикации на сервере и файл default.vrd

Если в консоли управления веб-сервером (например, IIS) всё кажется чистым, нам необходимо найти физическое местоположение файла описания публикации. Проанализируем действия по поиску:

Перейдем на сервер sqlxxx и найдем каталог, в котором лежат файлы веб-публикации. Обычно для IIS это путь C:\inetpub\wwwroot\ИмяПубликации\. Нас интересует файл default.vrd. Это XML-файл, в котором хранятся все параметры подключения веб-сервера к базе 1С.

Рассмотрим пример типичного содержимого секции HTTP-сервисов в default.vrd:


<httpServices publishByDefault="true">
    <service name="obmen_ut" rootUrl="obmen_ut" enable="true"/>
</httpServices>

Если атрибут publishByDefault установлен в значение true, то отдельные теги <service> могут отсутствовать, но сервис всё равно будет работать. Если же вы видите конкретную строку с вашим сервисом, это подтверждает его существование и активность.

Где искать сервис в конфигураторе: скрытые ловушки

Когда мы убедились, что публикация существует, перейдем в конфигуратор базы-приемника. Посмотрим на дерево метаданных. Если поиск в ветке Общие -> HTTP-сервисы не дал результатов по имени obmen_ut, проанализируем ситуацию глубже:

  1. Имя в дереве vs Корневой URL: Имя объекта в дереве конфигурации может называться ИнтеграцияСУТ, а его свойство Корневой URL может быть obmen_ut. Рекомендуем использовать глобальный поиск (Ctrl+Shift+F) по всей конфигурации, введя строку "obmen_ut".
  2. Расширения конфигурации: Это самый вероятный сценарий для современных типовых баз. Разработчики часто выносят кастомные обмены в отдельные расширения, чтобы не снимать основную конфигурацию с поддержки. Откройте Конфигурация -> Расширения конфигурации и последовательно проверьте ветку HTTP-сервисов в каждом из них.

Решение проблем с авторизацией и правами доступа

Если при обращении к сервису система запрашивает логин и пароль — это хороший знак. Это означает, что веб-сервер успешно передал запрос расширению 1С (модулю wsapch.dll или isapi_1c.dll), и платформа 1С опознала путь. Однако, если после ввода корректных данных возникает ошибка 401 или 403, дело в правах доступа.

Разберем, какие настройки необходимы для успешной авторизации:

Для каждого HTTP-сервиса в метаданных существует право Использование. Чтобы пользователь мог запустить сервис, это право должно быть явно назначено его роли. Если сервис находится в расширении, то и роль должна быть создана в этом же расширении или расширение должно использовать роли основной конфигурации.

Проанализируем важный нюанс работы с Библиотекой стандартных подсистем (БСП), о котором упоминалось в обсуждении. В современных конфигурациях (БП 3.0, УТ 11) права работают через механизм Идентификаторов объектов метаданных.

Особенности прав в расширениях (предостережение)

При использовании расширений часто возникает проблема «слетающих» прав. Рассмотрим, почему это происходит:

  1. При обновлении конфигурации или самого расширения БСП может пересчитывать справочник идентификаторов объектов.
  2. Если роли из расширения не прописаны в коде расширения специальным образом (через API БСП для регистрации ролей), они могут временно «исчезать» из профилей групп доступа.
  3. Основная роль расширения: Часто разработчики ставят флаг «Основная роль» в свойствах расширения. Будьте осторожны: это может конфликтовать с типовыми механизмами безопасности БСП, которые ожидают программной регистрации прав.

Для исправления ситуации в случае «слетающих» прав, выполните следующие действия:

  1. Убедитесь, что у пользователя 1С, под которым идет обмен, назначена роль из расширения, дающая право на Использование HTTP-сервиса.
  2. В некоторых случаях помогает запуск процедуры Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника() для принудительного обновления списка прав.
  3. Если используется типовая конфигурация, лучше всего создать специальный Профиль групп доступа, включить в него роль из расширения и назначить этот профиль пользователю.

Техническая отладка HTTP-сервиса

Если права настроены, но сервис ведет себя некорректно, мы можем применить механизм отладки. Разберем шаги:

  1. Проверьте файл default.vrd. В нем должен быть разрешен режим отладки для публикации: <debug enable="true" ... />.
  2. В конфигураторе перейдите в меню Отладка -> Подключение -> Автоматическое подключение и установите флаг HTTP-сервисы на сервере.
  3. Установите точку останова в модуле HTTP-сервиса (обычно это метод ЛюбойМетод(Запрос)).
  4. Выполните запрос из внешней системы — конфигуратор должен «поймать» сеанс, и вы сможете проанализировать содержимое объекта Запрос.

Таким образом, поиск «невидимого» сервиса всегда сводится к проверке default.vrd, анализу расширений и контролю прав доступа через механизмы БСП. Помните, что расширения — это мощный, но требующий внимания инструмент, особенно в части сохранения прав доступа при обновлениях системы.

← На главную