← На главную
При создании внешних веб-страниц, порталов или дашбордов часто возникает задача отображения оперативных данных из базы 1С для широкого круга пользователей. Рассмотрим основные варианты архитектуры, разберем способы публикации сервисов и проанализируем тонкости обеспечения безопасности и лицензирования.
Вариант 1. Использование статичного публичного IP-адреса и проброс портов
Если база данных и веб-сервер (Apache или IIS) развернуты в локальной сети компании, самым простым решением является аренда публичного («белого») IP-адреса у интернет-провайдера.
Разберем по шагам схему настройки:
- Публикация базы на веб-сервере: с помощью конфигуратора 1С или утилиты командной строки выполняем публикацию базы данных, HTTP-сервисов или стандартного интерфейса OData на локальном веб-сервере (IIS или Apache). При этом формируется файл дескриптора публикации
default.vrd.
- Настройка маршрутизатора: на сетевом шлюзе (роутере) настраиваем проброс портов (Port Forwarding). Входящие запросы из внешней сети по защищенному протоколу HTTPS (порт 443) перенаправляются на локальный IP-адрес и порт веб-сервера 1С.
- Привязка домена: к статическому публичному IP-адресу привязывается доменное имя, настраиваются SSL-сертификаты для шифрования трафика.
Важно: прямое выставление базы 1С в открытый интернет несет повышенные риски безопасности. Требуется строгая изоляция прав учетной записи, под которой происходит авторизация в 1С, и ограничение состава публикуемых объектов метаданных.
Вариант 2. Размещение базы и веб-сервера на VPS / VDS
Если локальная инфраструктура не располагает надежным интернет-каналом или бесперебойным питанием, целесообразно перенести базу данных или ее реплику на виртуальный выделенный сервер (VPS).
Рассмотрим особенности этого подхода:
- На сервере VPS под управлением Linux или Windows устанавливается платформа 1С, СУБД и веб-сервер.
- База 1С публикуется непосредственно на внешнем сервере с уже имеющимся публичным IP-адресом.
- Веб-страница обращается к опубликованным сервисам через REST или HTTP-сервисы напрямую по доменному имени сервера.
Вариант 3. Использование промежуточного бэкенда и кэширования (Рекомендуемый подход)
Прямое подключение браузеров пользователей к базе 1С через AJAX или REST API имеет серьезные недостатки: быстрый расход клиентских лицензий 1С, риск компрометации служебных логинов и паролей в коде страницы, а также ограничения браузерной политики CORS (Cross-Origin Resource Sharing).
Проанализируем архитектуру с промежуточным сервером (PHP, Node.js, Python, Go или Nginx):
- Защита учетных данных: фронтенд обращается только к промежуточному бэкенду. Учетные данные от 1С хранятся в защищенном конфигурационном файле бэкенда и не видны конечным пользователям в браузере.
- Экономия лицензий и кэширование: промежуточный скрипт запрашивает данные из 1С, сохраняет результат в оперативный кэш (например, Redis или Memcached) на заданное время (например, 1–5 минут) и отдает пользователям готовую страницу. Даже при одновременном посещении сайта тысячами пользователей к 1С будет уходить всего один запрос за интервал кэширования.
- Защита от DDoS и атак: внешний веб-сервер принимает на себя всю нагрузку и фильтрует некорректные запросы, не перегружая рабочий кластер 1С.
Оптимизация пула сеансов и выбор протокола
Разберем технические нюансы взаимодействия с платформой 1С:
- Выбор между SOAP и HTTP-сервисами: для веб-страниц рекомендуется использовать встроенные HTTP-сервисы платформы с передачей данных в формате JSON вместо классических Web-сервисов (SOAP/XML). Они обеспечивают меньший объем передаваемого трафика и значительно быстрее парсятся в JavaScript.
- Настройка пула соединений: в файле
default.vrd для минимизации задержек на создание сеансов настраиваются параметры пула сеансов (атрибуты pool minSize, maxSize и lifeTime). Это позволяет переиспользовать уже открытые сеансы 1С между быстрыми запросами пользователей.
- Событийная выгрузка данных (Webhooks / Push): альтернативный сценарий — настроить регламентное задание в 1С, которое с помощью объекта
HTTPСоединение само отправляет изменившиеся данные на базу сайта при проведении документов или по расписанию. В этом случае сайт работает автономно, полностью исключая зависимость от доступности 1С в режиме реального времени.