Стоит ли переходить на веб-сервисы для обмена EnterpriseData в БСП для ускорения синхронизации?

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

Особенности работы стандартного транспорта через Web-сервисы (SOAP)

Переход с файлового обмена на стандартные веб-сервисы БСП часто воспринимается как панацея для ускорения процесса, однако проанализируем внутреннюю механику этого процесса. Разберем по шагам, что происходит при вызове стандартного метода веб-сервиса Exchange_3_0_1_1:

1. Инициализация сеанса: При каждом обращении к веб-сервису система должна проверить права доступа и поднять сеанс. Если на стороне веб-сервера (IIS или Apache) не настроено агрессивное использование пула сеансов, это может занимать от 0.5 до нескольких секунд, что уже отдаляет нас от понятия «мгновенный обмен».
2. Оверхед протокола SOAP: Стандартные веб-сервисы 1С используют протокол SOAP. Это означает, что полезная нагрузка (ваш XML с данными EnterpriseData) оборачивается в массивный «конверт» со служебной информацией. Для малых пакетов данных объем служебных тегов может составлять значительную часть трафика.
3. Работа с временными файлами: Это ключевой момент, который часто упускают. Даже при передаче через веб-сервис, платформа 1С на принимающей стороне сначала получает двоичные данные, сохраняет их во временный файл в каталоге профиля пользователя и только потом начинает чтение этого файла. Таким образом, мы не избавляемся от дисковых операций, а лишь переносим их из сетевой папки в локальную временную директорию сервера.

Проанализируем ситуацию: если ваша цель — избавиться от «тормозов» дисковой подсистемы, то стандартный веб-сервис БСП даст лишь незначительный выигрыш за счет исключения задержек сетевого протокола SMB (общей папки), но сохранит логику работы через файлы.

Почему «онлайна» не будет на стандартных механизмах БСП

Выясним причину, по которой смена транспорта сама по себе не гарантирует мгновенной синхронизации. Архитектура EnterpriseData в БСП опирается на ПланыОбмена и последовательную обработку сообщений. Рассмотрим основные узкие места:

Регистрация изменений: Данные сначала должны быть зарегистрированы в плане обмена. Даже если мы инициируем выгрузку сразу после записи объекта, системе требуется время на формирование пакета через XDTO-сериализацию. Для старых или сильно кастомизированных конфигураций процесс сопоставления объектов с форматом EnterpriseData может быть крайне ресурсоемким.

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

Альтернатива: Использование HTTP-сервисов для «быстрого» обмена

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

• Отсутствие жестких схем: HTTP-сервис не требует разбора тяжелого WSDL-описания при каждом обращении.
• Потоковое чтение: Мы можем читать тело POST-запроса напрямую в объект ЧтениеXML, не сохраняя данные во временный файл. Это критически важно для производительности при частых запросах.
• Минимальный оверхед: Передается только «чистый» XML или JSON без лишних оберток.

Разберем пример логики простейшего HTTP-сервиса, который принимает данные в формате EnterpriseData и сразу отправляет их на загрузку, минуя стандартную очередь сообщений:

Функция PostData(Запрос)
    
    // Получаем чтение XML напрямую из тела запроса
    ЧтениеXML = Новый ЧтениеXML;
    ЧтениеXML.УстановитьСтроку(Запрос.ПолучитьТелоКакСтроку());
    
    // Вызываем менеджер обмена напрямую для мгновенной обработки
    ПараметрыЗагрузки = ОбменДаннымиСервер.ПараметрыЗагрузкиДляУниверсальногоФормата();
    МенеджерОбмена = ОбменДаннымиСервер.МенеджерОбменаЧерезУниверсальныйФормат(ВерсияФормата);
    
    // Запускаем загрузку без создания сообщения обмена в планах обмена
    МенеджерОбмена.ЗагрузитьДанныеДляПриложения(ЧтениеXML, ПараметрыЗагрузки);
    
    Возврат Новый HTTPСервисОтвет(200);
    
КонецФункции

Практические рекомендации по оптимизации

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

1. Использование Fast Infoset: Если вы решите остаться на стандартных Web-сервисах, включите в настройках публикации на веб-сервере поддержку Fast Infoset. Это бинарный формат XML, который платформа 1С понимает нативно. Он значительно сокращает объем передаваемых данных и ускоряет их парсинг.
2. Оптимизация регистрации: Вместо типового механизма регистрации изменений для всех объектов, попробуйте внедрить событийную модель. При записи критически важного объекта (например, заказа клиента) программно инициируйте выгрузку только этого конкретного объекта через HTTP-запрос к принимающей базе.
3. Разделение потоков: Настройте разные узлы плана обмена для «оперативных» данных (документы) и «тяжелых» данных (справочники, остатки). Это позволит мелким пакетам не застревать за большими выгрузками.
4. Прямые вызовы: Для реализации полноценного «онлайна» лучше всего подходит архитектура, где одна база вызывает HTTP-сервис другой базы, передавая данные в теле запроса, а принимающая база обрабатывает их в том же сеансе (или быстром фоновом задании).

Резюме

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