Как организовать обращение веб-сервера на Linux к 1С и как при этом расходуются лицензии?

При построении архитектуры взаимодействия внешнего веб-сервера (работающего под управлением Linux) и информационной базы 1С часто возникает задача передачи оперативных данных о событиях в режиме реального времени. В операционных системах семейства Windows разработчики нередко применяли прямое COM-соединение, однако в среде Linux этот механизм недоступен. Разберем наиболее эффективные способы интеграции, выясним правила расходования лицензий 1С при внешних вызовах и рассмотрим механизм управления пулом сеансов.

1. Варианты интеграции внешнего сервера с 1С

Для инициации обращений со стороны внешнего веб-сервера к базе 1С проанализируем основные подходы платформы:

1. HTTP-сервисы (REST API): Стандартный и наиболее производительный подход в современной разработке. Платформа 1С позволяет опубликовать REST API, принимающий и возвращающий данные в формате JSON или XML через стандартные глаголы HTTP (GET, POST, PUT, DELETE). Работает быстрее классического SOAP за счет меньших накладных расходов на сериализацию.
2. Web-сервисы (SOAP): Традиционный протокол обмена на основе WSDL-описания и XML-пакетов. Внешний веб-сервер использует стандартный SOAP-клиент для вызова экспортных операций сервиса.
3. Автоматический REST-интерфейс OData: Позволяет выполнять прямое чтение и запись в прикладные объекты (справочники, документы, регистры) без необходимости писать собственный программный код сервиса.
4. Брокеры сообщений (RabbitMQ, Kafka, Redis): В сценариях с высокой нагрузкой веб-сервер отправляет события в очередь сообщений, а 1С считывает их регламентным фоновым заданием или через специализированные компоненты. Это гарантирует сохранение сообщений даже в моменты перезапуска или недоступности кластера 1С.

2. Как расходуются лицензии при вызовах веб-сервисов

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

1. Клиент-серверный вариант (сервер 1С:Предприятия): При вызове опубликованного сервиса в кластере создается сеанс с типом WS-соединение или HTTP-сервис. Обычные клиентские лицензии 1С на такие сеансы не расходуются — платформа проверяет только наличие действующей лицензии на сервер 1С:Предприятия.
2. Файловый вариант базы: При публикации файловой базы через веб-сервер веб-расширение использует одну клиентскую лицензию на рабочий процесс веб-сервера.
3. Множественные параллельные запросы: Если несколько внешних запросов поступают одновременно, сервер 1С распределяет их по доступным сеансам пула или создает новые служебные сеансы внутри серверного кластера, не блокируя пользовательские клиентские лицензии рабочих мест.

3. Механизм переиспользования сеансов (Session Pooling)

Выясним, как платформа 1С обрабатывает частые обращения без постоянных задержек на инициализацию сеанса. Начиная с версии 8.3.9, платформа автоматически включает механизм переиспользования сеансов (session pooling).

При первом запросе пользователя создается рабочий сеанс, который после отправки ответа не уничтожается мгновенно, а помещается в кэш (пул). При поступлении следующего запроса от того же пользователя платформа мгновенно передает обработку уже готовому сеансу, исключая затраты времени на повторный запуск и авторизацию.

Если запросы выполняются быстро (доли секунды), один и тот же сеанс из пула способен легко обслуживать поток в 10–50 вызовов в минуту.

4. Тонкая настройка пула сеансов в default.vrd

Параметры работы опубликованных веб- и HTTP-сервисов определяются конфигурационным файлом default.vrd. Разберем ключевые атрибуты элемента point, с помощью которых можно оптимизировать нагрузку:

1. reuseSessions — режим переиспользования сеансов. Может принимать значения autouse (автоматически), use (принудительно переиспользовать) или dontuse (закрывать сеанс после каждого вызова).
2. sessionMaxAge — максимальное время жизни простаивающего сеанса в пуле в секундах (по истечении времени неактивный сеанс завершается).
3. poolSize — предельное количество одновременно удерживаемых сеансов в пуле для одного пользователя базы.
4. poolTimeout — время ожидания освобождения существующего сеанса в пуле перед созданием нового.
5. waitTimeout — максимальное время ожидания ответа клиентом при полной занятости всех доступных сеансов.

Посмотрим на пример фрагмента файла default.vrd с явным указанием параметров пула сеансов:

<service name="IntegrationService"
    rootUrl="api"
    enable="true"
    reuseSessions="use"
    sessionMaxAge="60"
    poolSize="10"
    poolTimeout="5"
    waitTimeout="30"/>

5. Практические рекомендации по стабильности и безопасности

Проанализируем важные аспекты надежности при вызове 1С из внешней среды:

1. Разделение длительных операций: Если обработка входящего события требует тяжелых расчетов или проведения объемных документов, не удерживайте HTTP-соединение открытым. Сервис должен быстро записать входящие данные (например, во вспомогательный регистр или документ) и сразу вернуть статус 200 OK или 202 Accepted. Саму обработку следует переложить на фоновое регламентное задание 1С.
2. Безопасность учетных записей: Не рекомендуется хранить логин и пароль пользователя в открытом виде в параметре ib файла default.vrd. Надежнее настроить авторизацию по заголовку (Basic Authentication) со стороны вызывающего сервера или проверять Bearer-токены непосредственно в коде модуля HTTP-сервиса.
3. Прямые вызовы из браузера (CORS): Если планируется обращение к сервисам 1С напрямую из JavaScript-клиента браузера, стандартный веб-сервер 1С заблокирует кросс-доменные запросы. Для корректной работы перед 1С устанавливают Reverse Proxy (например, Nginx), который проставляет необходимые заголовки Access-Control-Allow-Origin и методы OPTIONS.