Возможно ли использовать 1С в качестве SOAP-сервера при высокой нагрузке и как правильно его настроить?

← На главную

Рассмотрим ситуацию интеграции 1С с внешними сторонними системами по протоколу SOAP (веб-сервисы). В корпоративных инфраструктурах часто возникает задача, когда платформа 1С:Предприятие выступает в роли SOAP-сервера и принимает синхронные и асинхронные запросы от сторонних сервисов (например, написанных на Python, PHP, Java или C#). При этом критически важно сохранить высокую производительность и стабильность базы данных, особенно если система обслуживает непрерывный поток данных.

Проанализируем технические особенности работы веб-сервисов 1С, оценим предельные нагрузки и разберем архитектурные решения, которые позволят системе выдерживать интенсивный поток запросов.

Ограничения и потенциальные проблемы при работе 1С как SOAP-сервера

Платформа 1С:Предприятие поддерживает механизмы веб-сервисов и работы с XDTO нативно. Однако при выполнении десятков запросов в секунду с передачей больших массивов данных (таблиц с тысячами строк) проявляются следующие узкие места:

Затраты на инициализацию сеанса: При поступлении каждого входящего SOAP-запроса платформе требуется создать или инициализировать сеанс, выдав вызов модулю сеанса и обработчику УстановкаПараметровСеанса. Если запрос длится несколько миллисекунд, а сам сеанс создается дольше, сервер перегружается накладными расходами.
Высокое потребление ресурсов XML/XDTO: SOAP базируется на формате XML. Сериализация и десериализация больших табличных частей вызывают высокую нагрузку на ЦП и оперативный память рабочих процессов rphost.
Таймауты веб-сервера: Если внешняя система запрашивает выгрузку большого объема данных в рамках одного синхронного вызова, запрос может зависнуть. Это приводит к исчерпанию пула соединений на IIS или Apache и ошибкам соединения со стороны клиента.

Решение 1: Двухшаговая асинхронная схема обработки через фоновые задания

Если планируется нагрузка порядка 10–30 запросов в секунду с получением массивов данных в тысячи строк, удерживать постоянное синхронное подключение не рекомендуется. Наиболее надежный подход — разделение обработки на два коротких запроса с использованием механизмов платформы ФоновыеЗадания.

Разберем по шагам алгоритм этой схемы:

Первый запрос (регистрация задачи): Сторонняя система отправляет SOAP-запрос с параметрами требуемой выборки. Модуль веб-сервиса 1С принимает параметры, создаёт запись в специальном регистре сведений с состоянием "В обработке", генерирует уникальный идентификатор задачи (GUID) и запускает асинхронное фоновое задание через метод ФоновыеЗадания.Выполнить(). Метод SOAP-сервиса моментально возвращает клиенту ответ со статусом и полученным GUID задачи.
Обработка на стороне 1С: Запущенное фоновое задание выполняет выборку данных в фоновом режиме, формирует результат и сохраняет его (например, в сжатом виде или JSON/XML строкой) в регистре сведений или хранилище настроек, меняя статус задачи на "Готово".
Второй запрос (получение результата): Внешняя система обращается к SOAP-сервису 1С во втором легком запросе, передавая полученный GUID. Если статус "Готово", сервис отдаёт подготовленный результат и удаляет запись из временного хранилища.

Рассмотрим пример реализации фонового выполнения подготовки данных в коде 1С:


Функция СоздатьЗадачуНаВыгрузку(ПараметрыЗапросаXML) Экспорт
    
    ИдентификаторЗадачи = Новый УникальныйИдентификатор;
    
    МассивПараметров = Новый Массив;
    МассивПараметров.Добавить(Строка(ИдентификаторЗадачи));
    МассивПараметров.Добавить(ПараметрыЗапросаXML);
    
    // Запуск фонового задания для тяжелой выборки
    ФоновыеЗадания.Выполнить("ИнтеграцияСервис.ПодготовитьДанныеВыгрузки", 
        МассивПараметров, 
        КлючЗадания, 
        "Подготовка данных для SOAP " + Строка(ИдентификаторЗадачи));
        
    Возвращать Строка(ИдентификаторЗадачи);
    
КонецФункции

Решение 2: Настройка пула сеансов (Session Pooling) в default.vrd

Для предотвращения постоянного повторного создания сеансов и сокращения времени отклика при частых вызовах SOAP необходимо настроить параметр повторного использования сеансов. Это делается в файле публикации веб-сервиса default.vrd.

Выясним параметры настройки пула сеансов в секции публикации:


<point name="WebExchange" 
       alias="WebExchange.1cws" 
       enable="true" 
       ib="File="C:\Bases\Trade";">
    <reuse sessions="autouse" 
           poolSize="10" 
           poolTimeout="5" 
           maxAge="60"/>
</point>

Проанализируем значения ключевых атрибутов:

sessions="autouse" — переводит режим использования сеансов в повторный доступ.
poolSize — определяет максимальное число сеансов в пуле, удерживаемых для выполнения вызовов сервиса.
poolTimeout — время ожидания освобождения сеанса из пула при высокой интенсивности вызовов.
maxAge — максимальное время жизни сеанса в секундах, после которого он корректно перезапускается.

Альтернативные архитектурные решения при сверхвысоких нагрузках

Если планируемый поток данных превышает 50–100 запросов в секунду или 1С является критической учетной системой (например, обслуживание таможенного терминала или склада), целесообразно рассмотреть дополнительные варианты архитектуры:

Использование HTTP-сервисов вместо SOAP: Встроенные HTTP-сервисы 1С поддерживают работу с JSON-форматом. Сериализация JSON проходит значительно быстрее, чем XDTO/XML, и не создаёт больших служебных оберток в теле запросов.
Брокеры сообщений (RabbitMQ, Apache Kafka): Внешняя система отправляет сообщения в шину данных, а 1С забирает их порционно через регламентные задания по мере освобождения ресурсов сервера. Это полностью изолирует учетную систему от пиковых всплесков нагрузки внешних систем.
Промежуточный веб-сервис (Middleware): Создание прослойки на Python, Go или Node.js, которая принимает SOAP-запросы, выполняет первичную валидацию, сохраняет данные во временную базу данных (PostgreSQL/Redis) и передает их в 1С пакетным методом.