Современные интеграции часто требуют оперативного получения данных от внешних сервисов, таких как АТС (например, Binotel), мессенджеры или системы эквайринга. Технология Webhook позволяет внешней системе самой «уведомлять» 1С о событии, отправляя HTTP-запрос на заранее подготовленный адрес. Разберем по шагам, как правильно подготовить конфигурацию и веб-сервер для безопасной и стабильной работы с вебхуками.
Прежде всего, проанализируем, из чего состоит процесс обмена данными. Вебхук работает по принципу «сервер-клиент», где внешняя система (сервер) генерирует запрос по определенному событию (например, входящий звонок), а наша 1С (клиент) должна этот запрос принять и обработать. Для реализации этой схемы в 1С необходимо создать и опубликовать HTTP-сервис. Важно заранее выяснить, какой тип запроса генерирует сервис (обычно это POST), в каком формате передаются данные (чаще всего JSON) и какие заголовки используются для авторизации.
Рассмотрим процесс создания механизма приема данных. В дереве метаданных найдем ветку Общие -> HTTP-сервисы и создадим новый объект. Укажем понятное имя, например, ИнтеграцияСАТС. Далее настроим структуру:
v1/* позволит принимать запросы на адрес вида /hs/ИнтеграцияСАТС/v1/event.ПринятьСобытие. В свойствах метода укажем HTTP метод: POST, так как вебхуки почти всегда передают данные в теле запроса.
Функция ПринятьСобытие(Запрос)
// Получаем тело запроса в виде строки
ДанныеСтрокой = Запрос.ПолучитьТелоКакСтроку();
// Читаем JSON
Чтение = Новый ЧтениеJSON;
Чтение.УстановитьСтроку(ДанныеСтрокой);
СтруктураДанных = ПрочитатьJSON(Чтение);
Чтение.Закрыть();
// Здесь должна быть логика обработки (лучше асинхронная)
// Формируем ответ серверу
Ответ = Новый HTTPСервисОтвет(200);
Ответ.УстановитьТелоИзСтроки("OK");
Возврат Ответ;
КонецФункции
Выясним причину опасений многих разработчиков: публикация базы в интернете открывает потенциальный доступ к данным. Чтобы этого избежать, применим комплексный подход к защите. Нам нужно сделать так, чтобы через веб-сервер был доступен только один конкретный сервис, а войти в саму базу под этим доступом было невозможно.
Во-первых, создадим в 1С специального пользователя для Webhook. В его правах (ролях) снимем все галочки, касающиеся запуска клиентов: Тонкий клиент, Толстый клиент, Веб-клиент. Оставим только права на использование нашего HTTP-сервиса и минимально необходимые права на чтение/запись объектов, участвующих в интеграции. Если прав нет совсем (пустой ключ), доступ к сервису также может быть ограничен, поэтому настроим роль точечно.
Во-вторых, разберем настройку публикации. При публикации информационной базы на веб-сервере (через меню Администрирование -> Публикация на веб-сервере) на вкладке "HTTP-сервисы" необходимо снять все флаги, кроме одного — напротив нашего созданного сервиса. Также следует отключить "Публиковать HTTP-сервисы по умолчанию", чтобы не подвергать систему риску через стандартные интерфейсы платформы.
Проанализируем ситуацию, когда внешний сервис не умеет передавать логин и пароль в заголовках авторизации или мы хотим максимально упростить процесс. Для этого используется файл конфигурации публикации default.vrd, который находится в каталоге публикации на веб-сервере.
Найдем в этом файле строку с параметрами соединения и пропишем в ней данные созданного ранее сервисного пользователя. Это позволит внешней системе обращаться к сервису без явного указания учетных данных в URL, при этом авторизация внутри 1С произойдет автоматически под ограниченным пользователем.
<point ...
ib="Srvr="ServerName";Ref="BaseName";Usr="WebhookUser";Pwd="YourPassword";">
<httpService name="ИнтеграцияСАТС" alias="api.v1" enable="true"/>
</point>
Важный момент: использование параметров Usr и Pwd в открытом виде в файле default.vrd требует строгой настройки прав доступа к самому файлу на уровне операционной системы, чтобы его не мог прочитать никто, кроме процесса веб-сервера.
Рассмотрим критический нюанс работы с вебхуками: время ожидания ответа (таймаут). Внешние сервисы (например, АТС Binotel) обычно ждут ответ от вашего сервера не более 2-5 секунд. Если за это время 1С начнет выполнять тяжелые запросы, искать контрагента по всей базе или создавать документы, сервис разорвет соединение и может пометить запрос как неудачный, начав повторные отправки (retry), что создаст лавинообразную нагрузку на базу.
Выясним правильную стратегию: HTTP-сервис должен работать максимально быстро. Получили данные — записали в промежуточный регистр сведений («Очередь событий») — вернули КодСостояния = 200. Сама обработка данных из регистра должна выполняться регламентным заданием или фоновым процессом, который запускается сразу после записи. Это гарантирует стабильность работы внешнего сервиса и отзывчивость 1С.
Разберем дополнительные требования, характерные для телефонии. Большинство современных API работают исключительно через защищенный протокол. Рассмотрим шаги по его внедрению:
https:// в адресе многие сервисы просто откажутся отправлять данные.Проанализируем логику обработки звонка: Binotel присылает события разных типов (ANSWER, DIAL, LOST). В коде 1С мы должны предусмотреть ветвление логики в зависимости от типа события, чтобы, например, открывать карточку клиента только в момент снятия трубки, а не в начале гудков.
Таким образом, правильная работа с Webhook в 1С строится на трех столпах: строгом ограничении прав доступа при публикации, моментальном ответе на входящий запрос и последующей асинхронной обработке полученных данных.