← На главную
При построении крупных торговых систем с большим количеством daily-заказов и постоянными изменениями товарных остатков стандартный periodic-обмен через файлы (например, по протоколу CommerceML) перестает справляться. Возникает необходимость в проектировании архитектуры близкого к режиму real-time (онлайн) обмена. Рассмотрим, какие технологии 1С и архитектурные паттерны необходимо применить для решения этой задачи.
1. Выбор протокола интеграции: HTTP-сервисы (REST API) против SOAP
Для обеспечения высокого лимита запросов и минимальной задержки разберем два основных подхода к созданию интерфейсов взаимодействия со стороны 1С:
- Web-сервисы (SOAP): Поддерживают строгую типизацию данных через XDTO-пакеты и WSDL-описания. Однако SOAP-запросы генерируют объёмные XML-структуры, что требует дополнительных ресурсов процессора на сериализацию и десериализацию как на стороне 1С, так и на стороне веб-сервера (PHP).
- HTTP-сервисы (REST API + JSON): Нативное решение для интеграции с веб-системами. Формат JSON передается с минимальным оверхедом по объему данных. В 1С обработка JSON выполняется встроенными объектами
ЧтениеJSON и ЗаписьJSON на аппаратном уровне, что снижает нагрузку на CPU сервера приложений.
Рекомендация: Для высоконагруженных систем предпочтительно использовать нативные HTTP-сервисы 1С с передачей данных в формате JSON.
2. Архитектура выгрузки остатков и цен через Планы Обмена
Выполнять полную выгрузку каталога и остатков при каждой транзакции недопустимо. Проанализируем оптимальную схему передачи номенклатурных остатков и цен:
- Ночная полная синхронизация: Раз в сутки (в период наименьшей активности системы) выполняем регламентный полную выгрузку базового каталога товаров, иерархии и первичных остатков.
- Инкрементальная (дельта) выгрузка: Для отслеживания изменений используем объект конфигурации
ПланыОбмена. На регистры накопления остатков и регистр сведений ЦеныНоменклатуры настраивается состав плана обмена. При изменении документа или проведении продажи зарегистрированные изменения передаются на сайт регламентным заданием (например, раз в 2–5 минут) только по тем позициям, по которым были движения.
- Запрос точного остатка по требованию: Если клиенту на сайте требуется получить остаток «здесь и сейчас», веб-сервер делает точечный запрос к HTTP-сервису 1С для конкретной номенклатурной позиции.
3. Предотвращение транзакционных блокировок при приеме заказов
Прямое создание и оперативное проведение документов ЗаказКлиента непосредственно в моменте выполнения синхронного HTTP-запроса с сайта создаёт высокую вероятность блокировки СУБД (ошибки вида «Превышено время ожидания предоставления блокировки»).
Рассмотрим, как правильно организовать асинхронный прием заказов:
- Буферизация incoming-запросов: HTTP-сервис 1С принимает структуру заказа с сайта, быстро записывает ее в буферный регистр сведений (или справочник-очередь) без проведения торговых документов и сразу возвращает веб-серверу ответ
200 OK.
- Обработка фоновыми заданиями: Отдельное регламентное задание 1С считывает заказы из буферного регистра и последовательно формирует и проводит документы
ЗаказКлиента и резервирование товара, гарантируя отсутствие транзакционных заторов.
- Использование брокеров сообщений: При экстремальных нагрузках между 1С и сайтом размещают внешнюю очередь (RabbitMQ, Kafka, Redis), куда сайт складывает заказы, а 1С забирает их пакетами.
4. Настройка безопасности и оптимизация пула сеансов
При публикации HTTP/Web-сервисов 1С во внешнюю сеть необходимо защитить базу от несанкционированного доступа и нагрузочных пиков:
- Проксирование запросов: На стороне веб-сервера (Nginx/Apache) настраивается обратный прокси-сервер или PHP-обертка. Внешние клиенты сайта обращаются только к PHP API. Сам сайт авторизуется в 1С под отдельным технологическим пользователем с ограниченными правами.
- Ограничение доступных методов: Сервисный пользователь 1С должен иметь права только на исполнение методов конкретного HTTP-сервиса, без прямого доступа к таблицам базы.
- Пул сеансов 1С: Платформа 1С поддерживает автоматический пул сеансов для опубликованных сервисов. Это позволяет избежать повторного вызова процедур инициализации (таких как
УстановкаПараметровСеанса) при каждом вызове. На стороне веб-сервера PHP обязательно устанавливаются жесткие таймауты ожидания (не более 2–5 секунд).
5. Выдача печатных форм (счетов на оплату в PDF)
Генерация печатных форм в 1С через метод ТабличныйДокумент.Записать() в формат PDF под высокой нагрузкой сопряжена со значительным расходом оперативной памяти и ресурсов процессора.
Разберем варианты оптимального получения файлов:
- Формирование структуры данных: HTTP-сервис 1С возвращает сайту данные счета (суммы, реквизиты, табличную часть) в JSON, а сам PDF-документ генерируется средствами PHP-библиотек непосредственно на сайте.
- Кеширование PDF на стороне 1С: Если требуется гарантировать идентичность печатной формы из 1С, генерация PDF выполняется асинхронно, а готовые файлы кешируются в файловом хранилище или S3. При повторном запросе выдается готовая ссылка на файл без повторного вызова графического движка 1С.