При интеграции крупных систем, таких как 1С:ERP и 1С:Документооборот, часто возникают технические сложности на уровне публикации веб-сервисов. Стандартная связка с использованием IIS (Internet Information Services) может выдавать ошибки таймаутов или некорректно обрабатывать тяжелые XDTO пакеты, особенно после обновления платформы. Рассмотрим, как использование автономного сервера 1С (исполняемый файл ibsrv.exe) помогает стабилизировать работу системы и выясним нюансы его совместной работы с основным кластером серверов.
Проанализируем типичную ситуацию: после обновления платформы в журнале регистрации начинают появляться ошибки вида DMPutChangesRequest. Это сигнализирует о том, что при вызове операции execute() веб-сервиса DMService превышено время ожидания. Разберем, почему это происходит. Веб-сервер IIS имеет собственные настройки ограничений по времени выполнения запроса, которые могут вступать в конфликт с длительностью обработки данных внутри самой 1С. Если пакет данных большой, IIS разрывает соединение до того, как 1С успевает вернуть ответ.
Кроме того, часто фиксируются ошибки блокировок при попытке записи объектов через веб-сервис. Посмотрим на пример лога ошибки:
{ОбщийМодуль.ОбработкаЗапросовXDTOДокументы.Модуль(3680)}: ОбъектДО.Заблокировать();
по причине:
Не удалось заблокировать запись. Действие (изменение, удаление или блокировка записи) не выполнено.
Ошибка блокировки объекта. Объект уже заблокирован:
пользователь: Администратор, сеанс: 761692, приложение: WS-соединение
Эта ситуация часто вызвана тем, что несколько потоков интеграции пытаются одновременно модифицировать один и тот же объект, либо возникают коллизии в управлении сеансами на стороне веб-сервера.
Выясним, что представляет собой Автономный сервер (ibsrv). Это легковесное приложение, которое объединяет в себе функции сервера приложений 1С и веб-сервера. Его ключевая особенность — независимость от основного кластера rmngr/rphost и отсутствие необходимости в установке IIS или Apache для публикации баз.
Разберем основные характеристики этой технологии:
Рассмотрим критически важный вопрос: могут ли автономный сервер и обычный сервер 1С работать с одной и той же базой данных одновременно? Ответ — да, могут. Однако проанализируем риски такой архитектуры.
Для СУБД (например, MS SQL Server или PostgreSQL) автономный сервер выглядит как еще одно отдельное приложение, подключающееся к базе данных. Основная проблема заключается в управляемых блокировках. Поскольку автономный сервер — это отдельный инстанс, он ничего не знает о блокировках, установленных в основном кластере 1С. Управляемые блокировки (Managed Locks) работают только в рамках одного кластера. Если пользователь в ERP заблокирует объект на основном сервере, автономный сервер об этом не узнает, пока не произойдет попытка физической блокировки таблицы на уровне SQL. Это может привести к нарушению логической целостности данных, если бизнес-логика опирается исключительно на программные блокировки 1С.
Рассмотрим шаги, которые необходимо предпринять для миграции публикации 1С:Документооборота на автономный сервер.
Автономный сервер настраивается через файл в формате YAML. Создадим файл config.yaml и определим в нем параметры подключения к базе данных и параметры публикации. Пример структуры файла:
# Настройки базы данных
database:
type: mssql
server: sql-server-name
name: dm_database
user: db_user
password: db_password
# Настройки публикации веб-сервисов
publishing:
services:
- name: DMService
alias: dm
type: web-service
Запуск осуществляется через командную строку. Найдем исполняемый файл ibsrv.exe в каталоге bin установленной платформы. Выполним команду запуска, указав путь к конфигурационному файлу:
ibsrv.exe --config="C:\1C\Autonomous\config.yaml"
Для постоянной работы рекомендуется зарегистрировать это приложение как службу Windows с помощью стандартных средств sc create или через параметры самого ibsrv.
Проанализируем важный аспект: выполнение фоновых и регламентных заданий. По умолчанию автономный сервер может пытаться выполнять те же задания, что и основной кластер. Это приведет к дублированию действий и конфликтам блокировок. Обязательно отключите выполнение регламентных заданий на автономном сервере, если он используется только для публикации веб-сервисов интеграции. Это делается в параметрах запуска или через файл конфигурации.
Переход на автономный сервер позволяет нам решить ряд проблем:
DMPutChangesRequest.Важно помнить, что использование автономного сервера не требует покупки отдельной «серверной» лицензии (она включена в лицензию на сервер 1С:Предприятие). Однако каждый сеанс через автономный сервер (включая WS-соединения) потребляет клиентские лицензии. Убедитесь, что ваш сервер лицензирования доступен автономному серверу или вставьте аппаратный ключ защиты.
Подведем итог: использование автономного сервера — это отличный способ обойти проблемы настройки IIS и повысить отказоустойчивость интеграционных механизмов. Главное — помнить о разделении регламентных заданий и учитывать отсутствие общих управляемых блокировок между серверами.