Как сделать сервис 1С: от конфигуратора до публикации

Сервис в 1С — это способ открыть доступ к данным и функциям информационной базы извне: из других программ, сайтов, мобильных приложений или других баз 1С. Платформа 1С:Предприятие поддерживает два основных вида: web-сервисы (SOAP, обмен по WSDL) и HTTP-сервисы (REST-подобный обмен произвольными данными, чаще всего JSON). Оба создаются в конфигураторе и публикуются на веб-сервере — IIS или Apache.

Прежде чем приступать, важно понимать: создание сервиса — это не только написание кода. Нужно спроектировать структуру обмена, продумать авторизацию, опубликовать сервис на веб-сервере и проверить его работу. Ошибка на любом этапе приведёт либо к неработающему обмену, либо к дыре в безопасности базы.

Ниже разобран полный цикл: выбор типа сервиса, создание в конфигураторе, публикация, тестирование и типичные проблемы. Инструкция ориентирована на платформу 8.3 — актуальную версию для большинства рабочих баз.

Выбираем тип сервиса: web-сервис или HTTP-сервис

Web-сервис (SOAP) — классический вариант, работающий по строгому контракту WSDL. Клиент получает описание сервиса и вызывает операции с типизированными параметрами. Подходит для интеграций с корпоративными системами, где важна строгая типизация и автоматическая генерация клиентского кода по WSDL.

HTTP-сервис — более лёгкий вариант: вы сами определяете URL-шаблоны, методы (GET, POST и другие) и формат данных. Чаще всего используется связка HTTP-сервис + JSON, по сути это REST API вашей базы. Такой вариант проще отлаживать (достаточно браузера или curl), легче читать и удобнее для мобильных приложений и сайтов.

Практическое правило: если вы не уверены, что выбрать, — делайте HTTP-сервис. SOAP имеет смысл, только если внешняя система явно этого требует. Если же задача — просто отдать справочники и документы наружу без логики, рассмотрите стандартный OData-интерфейс: он включается без единой строки кода.

Создаём HTTP-сервис в конфигураторе

Откройте конфигуратор, в дереве конфигурации найдите ветку «Общие» → «HTTP-сервисы» и добавьте новый объект. Задайте имя, например MobileAPI, и синоним. В свойствах сервиса укажите корневой URL — это часть адреса, по которой сервис будет доступен после публикации, например api. Тогда полный адрес будет выглядеть как http://server/base/hs/api/....

Далее создайте шаблоны URL. Шаблон — это относительный путь с параметрами, например /catalog/{id}. Для каждого шаблона добавьте методы (GET, POST и т.д.) и напишите обработчики. Обработчик — это функция, которая получает объект ЗапросHTTP и должна вернуть объект ОтветHTTP.

Функция ПолучитьТоварGET(Запрос)
	Ответ = Новый HTTPСервисОтвет(200);
	Ид = Запрос.ПараметрыURL["id"];
	Ссылка = Справочники.Номенклатура.ПолучитьСсылку(Новый УникальныйИдентификатор(Ид));
	Если НЕ ЗначениеЗаполнено(Ссылка) Тогда
		Ответ.КодСостояния = 404;
		Возврат Ответ;
	КонецЕсли;
	Данные = Новый Структура("Наименование, Артикул", Ссылка.Наименование, Ссылка.Артикул);
	Запись = Новый ЗаписьJSON;
	Запись.УстановитьСтроку();
	ЗаписатьJSON(Запись, Данные);
	Ответ.УстановитьТелоИзСтроки(Запись.Закрыть());
	Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
	Возврат Ответ;
КонецФункции

Ключевые моменты при написании обработчиков: всегда задавайте код состояния (200, 400, 404, 500), устанавливайте заголовок Content-Type с кодировкой UTF-8, иначе кириллица на клиенте превратится в «кракозябры», и оборачивайте логику в попытку/исключение, чтобы сервер не отдавал клиенту внутренние тексты ошибок платформы.

Для web-сервиса логика похожа: добавляется объект в ветке «Web-сервисы», создаются операции с параметрами, а платформа сама генерирует WSDL-описание. Код операции — обычная функция, возвращающая значение простого типа или XDTO-объект.

Публикуем сервис на веб-сервере

Сервис, созданный в конфигураторе, недоступен извне, пока база не опубликована на веб-сервере. Для файловых баз публикация обязательна в любом случае (сервисы в файловой базе работают только через веб-сервер), для клиент-серверных — тоже, поскольку обращение идёт по HTTP.

Порядок публикации: установите веб-сервер (IIS на Windows или Apache), убедитесь, что установлены модули расширения веб-сервера платформы 1С (ставятся вместе с платформой). Затем в конфигураторе откройте «Администрирование» → «Публикация на веб-сервере», укажите имя публикации, каталог и отметьте флажки «Публиковать HTTP-сервисы» (или web-сервисы). Нажмите «Опубликовать» и перезапустите веб-сервер.

1. 1
   Установите IIS или Apache и модули расширения веб-сервера 1С
2. 2
   В конфигураторе откройте Администрирование → Публикация на веб-сервере
3. 3
   Укажите имя публикации и отметьте публикацию HTTP-сервисов или web-сервисов
4. 4
   Нажмите «Опубликовать» и перезапустите веб-сервер (iisreset или перезапуск Apache)
5. 5
   Откройте URL сервиса в браузере и проверьте ответ
6. 6
   Для web-сервиса проверьте доступность WSDL по адресу .../ws/ИмяСервиса?wsdl

Частая проблема на этом этапе — ошибка 404 после публикации. Причины: не установлены модули расширения веб-сервера, публикация выполнена не от имени администратора, либо в адресе перепутан регистр символов (для Apache регистр важен). Проверьте файл default.vrd в каталоге публикации — в нём должны быть строки с именами ваших сервисов.

Настраиваем авторизацию и безопасность

Открытый сервис без авторизации — прямой путь к утечке данных: любой, кто узнает URL, сможет читать или изменять данные базы. Минимум, который нужно сделать, — включить аутентификацию. В свойствах HTTP-сервиса есть параметр «Режим использования аутентификации»: оставьте требование аутентификации и создайте в базе отдельного пользователя с минимально необходимыми правами только для сервиса.

Не используйте для сервиса учётную запись администратора или реального сотрудника. Выделенный технический пользователь позволит ограничить права ровно до нужных объектов и отозвать доступ при компрометации, не ломая работу людей.

Дополнительные меры: ограничьте доступ по IP на уровне веб-сервера или файрвола, если интеграция идёт с фиксированного адреса; логируйте обращения в отдельный регистр сведений, чтобы видеть, кто и когда обращался к сервису; не передавайте в ответах лишние данные — только то, что реально нужно клиенту.

Тестируем и проверяем работу сервиса

Простейшая проверка GET-метода — прямо в браузере: откройте адрес вида http://server/base/hs/api/catalog/значение. Браузер запросит логин и пароль пользователя 1С и покажет JSON-ответ. Для POST-запросов браузера недостаточно — используйте curl, Postman или аналогичный инструмент.

curl -u serviceuser:password -H "Content-Type: application/json" -X POST -d "{"art":"A-100"}" http://server/base/hs/api/stock

Проверяйте не только «счастливый путь». Убедитесь, что сервис корректно отвечает на неправильный параметр (код 400), на несуществующий объект (404), на запрос без авторизации (401). Если сервис возвращает 500 с текстом ошибки платформы — значит, где-то не обработано исключение.

Типичные ошибки и ограничения

Первая типичная ошибка — тяжёлые запросы в обработчиках. Каждый вызов сервиса создаёт сеанс на сервере 1С, и если обработчик выполняет запрос по всей базе без индексов, несколько одновременных обращений положат производительность для всех пользователей. Оптимизируйте запросы и по возможности ограничивайте объём выборки.

Вторая ошибка — забытая переустановка публикации после изменения конфигурации. Если вы добавили сервис, а публикация не обновлена, веб-сервер о нём не узнает. Третья — работа с кодировкой: тело запроса нужно читать с учётом UTF-8, а в ответе явно указывать charset.

Помните и об ограничениях: в файловой базе сервисы работают только через веб-сервер, а не напрямую; анонимная синхронная обработка больших объёмов данных через сервис — плохая идея, для массового обмена лучше подходят планы обмена или очереди сообщений.

Частые вопросы