При организации процесса коллективной разработки и непрерывной интеграции (CI/CD) в среде 1С часто возникает необходимость получать мгновенные уведомления (веб-хуки) в момент, когда программист помещает измененные объекты в хранилище конфигурации. Это позволяет сразу запускать автоматическую сборку мусорных конфигураций, синтаксический контроль, запуск автотестов или выгрузку изменений в Git-репозиторий с помощью утилиты gitsync.
Платформа 1С не имеет встроенного функционала триггеров или подписок на события хранилища. Стандартные регламентные задания, работающие с определенной периодичностью (например, раз в 5 минут), не обеспечивают мгновенной реакции и создают лишнюю нагрузку на сервер. В этой статье мы подробно разберем, как решить эту задачу и настроить эффективные хуки как для TCP-хранилища, так и для хранилища, опубликованного на веб-сервере (IIS/Nginx).
---
Если ваша команда работает с хранилищем по протоколу TCP через стандартный сервер хранилища crserver, оптимальным архитектурным решением является перехват сетевых пакетов «в разрыве» между Конфигуратором разработчика и сервером хранилища. Для этого применяется специализированное решение — TCP-прокси сервер хранилища конфигураций (oproxy), написанный на OneScript.
Рассмотрим подробнее принцип его работы:
crserver.crserver. При этом он анализирует структуру сетевых пакетов.Преимущества данного метода:
Пример простейшего обработчика на OneScript, который отправляет HTTP-запрос (веб-хук) в систему CI/CD:
// Файл ПроверкиПроксиСервера.os
Процедура ПередПомещением(Контекст) Экспорт
Комментарий = Контекст.Комментарий;
// Проверяем наличие комментария
Если ПустаяСтрока(СокрЛП(Комментарий)) Тогда
ВызватьИсключение "Ошибка коммита: Помещение объектов без комментария запрещено!";
КонецЕсли;
// Отправляем асинхронный веб-хук в Jenkins/GitLab
Запрос = Новый HTTPЗапрос("/webhook/1c-repo-trigger");
Запрос.УстановитьТелоИзСтроки("commit_detected");
Соединение = Новый HTTPСоединение("ci-server.local", 8080);
Попытка
Соединение.ОтправитьДляОбработки(Запрос);
Исключение
// Логируем ошибку, но не прерываем коммит разработчика
ЗаписьЖурналаРегистрации("ХукХранилища", УровеньЖурналаРегистрации.Предупреждение,,, ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
КонецПопытки;
КонецПроцедуры
---
Если ваше хранилище работает по протоколу HTTP/HTTPS и опубликовано на IIS, напрямую внедриться в процесс обработки веб-сервера штатными средствами сложно. Однако 1С при совершении коммита отправляет POST-запрос с XML-структурой, содержащей уникальную строку-сигнатуру: DevDepot_commitObjects.
Мы можем установить легковесный веб-сервер Nginx в качестве обратного прокси (Reverse Proxy) перед веб-сервером IIS. С помощью модуля Lua Nginx будет анализировать тело запросов «на лету» без ущерба для производительности.
Проанализируем конфигурационный файл Nginx для реализации этой схемы:
server {
listen 80;
server_name 1c-repo.company.local;
location / {
proxy_pass http://iis_backend_ip:80; # Адрес вашего IIS с хранилищем
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
# Разрешаем передачу больших конфигурационных файлов
client_max_body_size 1000M;
# Внедряем анализ тела запроса через Lua
access_by_lua_block {
ngx.req.read_body()
local body = ngx.req.get_body_data()
if body and string.find(body, "DevDepot_commitObjects") then
-- Выполняем асинхронный вызов нашего веб-хука
local http = require "resty.http"
local httpc = http.new()
local res, err = httpc:request_uri("http://ci-server.local:8080/generic-webhook-trigger/invoke", {
method = "POST",
body = "{\"event\": \"commit\"}",
headers = {
["Content-Type"] = "application/json",
}
})
end
}
}
}
Преимущества подхода Nginx + Lua:
---
Если хранилище развернуто в файловом варианте (каталог общего доступа в локальной сети Windows), и вы не хотите использовать прокси-серверы, можно пойти путем мониторинга изменений файлов файловой системы сервера.
Суть метода заключается в отслеживании изменения файла базы данных хранилища 1cv8ddb.1CD (или файлов в каталоге data для новых версий платформы) с помощью инструментария WMI (Windows Management Instrumentation) и последующего разбора структуры утилитой tool1cd.
Выясним пошаговый алгоритм настройки такой схемы:
Шаг 1. Настройка триггера файловой системы
В планировщике задач Windows (Task Scheduler) или через собственный PowerShell-скрипт настраивается подписка на событие изменения файла хранилища. Пример WMI-запроса для мониторинга изменения файла:
SELECT * FROM __InstanceModificationEvent WITHIN 5
WHERE TargetInstance ISA 'CIM_DataFile'
AND TargetInstance.Name = 'C:\\Shares\\1C_Repo\\1cv8ddb.1cd'
При срабатывании этого события операционная система запускает ваш исполняемый скрипт.
Шаг 2. Разбор версий хранилища через tool1cd
Чтобы понять, действительно ли произошло помещение объектов (а не просто блокировка или чтение), скрипт должен прочитать таблицу версий. Для этого используется консольная версия утилиты tool1cd, которая выгружает таблицу VERSIONS в формат XML:
tool1cd.exe "C:\Shares\1C_Repo\1cv8ddb.1cd" /export VERSIONS /out "C:\Temp\versions.xml"
После выгрузки скрипт считывает полученный XML-файл, находит максимальный номер версии и сравнивает его с сохраненным ранее значением. Если номер версии увеличился, фиксируется факт коммита, запускается веб-хук, а новый номер версии сохраняется в текстовый файл-кэш для последующих сравнений.
Важное ограничение метода: Этот способ отлично подходит для небольших и средних баз. Однако на крупных конфигурациях (например, 1С:ERP) регулярный вызов утилиты tool1cd для многогигабайтного файла хранилища может приводить к задержкам дисковой подсистемы и временным блокировкам файла базы данных, что сделает работу программистов некомфортной.
---
Выбор оптимального способа зависит от инфраструктуры вашей разработки: