При проектировании интеграций через Web-сервисы (SOAP) или HTTP-сервисы (REST/JSON) у разработчиков и системных администраторов часто возникает вопрос: как именно расходуются лицензии 1С при входящих запросах и сколько лицензий необходимо приобретать. Разберем эту тему детально, разделив техническую сторону работы платформы и юридические требования Лицензионного соглашения «1С».
Рассмотрим, как физически ведет себя платформа «1С:Предприятие» при поступлении входящих HTTP- или SOAP-запросов в различных режимах работы.
В клиент-серверной архитектуре для работы Web- и HTTP-сервисов клиентские программные или аппаратные лицензии сервером напрямую не захватываются и из общего пула пользовательских лицензий не списываются. Однако для функционирования кластера серверов 1С обязательно требуется наличие серверной лицензии (1С:Лицензия на сервер). Сервер 1С принимает запрос через веб-сервер (Apache, IIS) и выполняет код сервиса в серверном контексте.
Если информационная база опубликована на веб-сервере в файловом режиме, модуль расширения веб-сервера физически запускает ядро платформы на самом веб-сервере. В этом случае для успешной инициализации соединения требуется как минимум одна клиентская лицензия (локальный файл программной лицензии или сетевой ключ HASP), доступная веб-серверу.
Если внутри обработчика сервиса программно вызывается фоновое задание через метод ФоновыеЗадания.Выполнить, оно запускается в отдельном серверном потоке кластера и также не требует дополнительной клиентской лицензии.
Проанализируем, как сервер 1С распределяет сеансы между входящими запросами. Чтобы не создавать сеанс и не выполнять модуль УстановкаПараметровСеанса заново на каждый входящий HTTP-запрос, платформа использует механизм повторного использования сеансов (session pooling).
Поведением сеансов можно управлять в конфигураторе при публикации или напрямую в файле default.vrd. Рассмотрим основные параметры управления сеансами:
reuseSessions):
Значение autouse позволяет платформе автоматически переиспользовать свободный сеанс из пула с теми же учетными данными (пользователь, пароль). Значение dontuse заставляет сервер создавать и закрывать сеанс под каждый отдельный запрос, что существенно увеличивает накладные расходы. Значение use фиксирует сеанс за конкретным клиентом по заголовку IBPR-SessionId.
poolSize, poolTimeout, sessionMaxAge):
Параметр poolSize определяет максимальное количество сеансов, удерживаемых в памяти для сервиса. Если количество одновременных запросов превышает размер пула, последующие запросы ожидают освобождения сеанса в течение времени poolTimeout. Параметр sessionMaxAge задает время неактивности сеанса в секундах до его автоматического уничтожения.
Выясним, какие правила действуют с точки зрения правообладателя. Техническая возможность отправлять неограниченное число запросов без списания лицензий не означает правомерность такой эксплуатации.
В Лицензионном соглашении фирмы «1С» действует правило запрета мультиплексирования. Мультиплексирование — это использование аппаратных или программных прослоек (веб-серверов, шлюзов, пулов соединений, промежуточных порталов и сайтов), которые объединяют или перенаправляют соединения, скрывая реальное число пользователей.
Разберем, как рассчитывается необходимое количество лицензий в зависимости от архитектуры:
Если к Web/HTTP-сервису обращается внешний сайт (например, интернет-магазин, B2B-портал для дилеров, личный кабинет клиента), и эти запросы генерируются действиями реальных людей, то организация обязана иметь клиентские лицензии 1С по количеству одновременно работающих с системой пользователей. Если сайт посещают 500 человек в сутки, но одновременно запросы к сервису генерируют до 10 пользователей, требуется наличие не менее 10 клиентских лицензий.
Если сервис используется исключительно для технической интеграции типа «сервер-сервер» (например, регулярная выгрузка остатков в стороннюю систему логистики или обмен с фискальным регистратором по расписанию без участия живого оператора), дополнительные клиентские лицензии под этот обмен не требуются.
Для обеспечения стабильности работы базы 1С и снижения рисков взаимоблокировок при интеграциях через сервисы рассмотрим следующие архитектурные подходы:
Внешние системы отправляют события и данные в очередь, а 1С забирает сообщения асинхронно через регламентные задания с контролируемой интенсивностью, что защищает рабочий процесс rphost от пиковых нагрузок.
Для операций частого чтения (каталог товаров, цены, остатки) данные из 1С предварительно выгружаются во внешнюю быструю СУБД (PostgreSQL, Redis). Веб-сайт читает данные напрямую из внешней СУБД, снимая нагрузку с 1С и исключая вопросы лицензирования публичных посетителей сайта.
Установка обратного прокси перед веб-сервером 1С позволяет настроить Rate Limiting (ограничение частоты обращений), отсекать неавторизованные запросы и кэшировать типовые GET-ответы.