Как организовать непрерывный и отказоустойчивый обмен заказами между сайтом и 1С?

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

Архитектурный подход: Прямой HTTP-сервис и RabbitMQ

Один из наиболее современных способов передачи данных — отправка JSON-структуры с данными заказа напрямую в HTTPСервисы платформы 1С. Для обеспечения гарантированной доставки между сайтом и 1С устанавливают брокер сообщений (например, RabbitMQ).

Рассмотрим схему работы через брокер сообщений:

1. Покупатель оформляет заказ на сайте.
2. Сайт формирует событие и публикует сообщение с данными заказа в очередь RabbitMQ.
3. Специальный обработчик (воркер) забирает заказ из очереди и вызывает HTTP-сервис 1С.
4. 1С принимает JSON, создаёт документ ЗаказПокупателя и возвращает статус ответа (HTTP 200 OK).
5. После успешного ответа 1С брокер удаляет сообщение из очереди. Если 1С недоступна (упала база или перезапускается сервер), сообщение остается в RabbitMQ и будет повторно отправлено после восстановления системы.

Гибридная схема с резервным каталогом (Фолбэк)

Если развертывание полновесного брокера RabbitMQ избыточно, проанализируем гибридный подход. В этой схеме сайт пытается передать заказ в 1С напрямую через HTTP-сервис, а при возникновении сбоя переключается на локальный файловый буфер.

Разберем алгоритм по шагам:

1. В момент создания заказа сайт дергает HTTP-сервис 1С, передавая структуру заказа в формате JSON.
2. Если 1С доступна и успешно записала заказ, процесс завершается.
3. Если 1С не отвечает (или возвращает HTTP 500), сайт записывает JSON-файл заказа во временный локальный каталог на веб-сервере.
4. Регламентное задание в 1С периодически (например, раз в 5–10 минут) подключается по FTP к аварийному каталогу на сайте, скачивает пропущенные файлы и загружает заказы в систему.

Оптимизация производительности HTTP-сервисов в 1С

При высоком потоке обращений к HTTP-сервису 1С можно столкнуться с задержками из-за инициализации параметров сеанса и повторной авторизации. Каждая сессия без настройки пула соединений тратит ресурсы сервера на старт сеанса.

Чтобы избежать этой проблемы, выделим основные рекомендации по оптимизации:

1. Настройка пула сеансов на веб-сервере

В файле конфигурации публикации default.vrd на веб-сервере (IIS или Apache) настраивают параметры повторного использования сеансов:

<point httpServices="true">
    <reuseSessions>autouse</reuseSessions>
    <sessionMaxAge>20</sessionMaxAge>
    <maxSessions>8</maxSessions>
</point>

Параметр reuseSessions="autouse" позволяет платформе переиспользовать уже созданные сеансы 1С для последующих HTTP-запросов, исключая накладные расходы на постоянный вход в систему.

2. Легковесный модуль внешнего соединения

Для ускорения обработки входящих запросов необходимо минимизировать тяжелые вычисления в модуле МодульСеанса и при инициализации параметров сеанса, если вызов идет от имени сервисного пользователя обмена.

3. Асинхронная обработка (Pattern 202 Accepted)

Если при получении заказа требуется проводить сложную бизнес-логику (расчет скидок, проверка остатков, создание контрагента), не выполняйте эти действия синхронно в теле HTTP-сервиса. Быстро сохраните полученный JSON во временный регистр сведений или запустите фоновое задание через ФоновыеЗадания.ВыполнитьВФоне и сразу верните сайту код 202 Accepted.

Функция ПринятьЗаказ(Запрос)
    
    ЧтениеJSON = Новый ЧтениеJSON;
    ЧтениеJSON.УстановитьСтроку(Запрос.ПолучитьТелоКакСтроку());
    СтруктураЗаказа = ПрочитатьJSON(ЧтениеJSON);
    ЧтениеJSON.Закрыть();
    
    // Быстрая запись сырых данных в регистр буфера
    МенеджерЗаписи = РегистрыСведений.БуферВходящихЗаказов.СоздатьМенеджерЗаписи();
    МенеджерЗаписи.Период = ТекущаяДатаСеанса();
    МенеджерЗаписи.ИдентификаторЗаказа = СтруктураЗаказа.ID;
    МенеджерЗаписи.ДанныеJSON = Запрос.ПолучитьТелоКакСтроку();
    МенеджерЗаписи.Записать();
    
    // Запуск асинхронной обработки
    МассивПараметров = Новый Массив;
    МассивПараметров.Добавить(СтруктураЗаказа.ID);
    ФоновыеЗадания.ВыполнитьВФоне("ОбработкаЗаказов.ОбработатьЗаказИзБуфера", МассивПараметров);
    
    Ответ = Новый HTTPСервисОтвет(202);
    Возврат Ответ;
    
КонецФункции

Альтернативные способы обмена

Выделим другие распространенные технологии обмена между 1С и внешними системами:

1. Обмен через FTP / Специфические папки: Классический способ. Сайт выгружает XML/JSON файлы в FTP-каталог, а 1С с помощью объекта FTPСоединение сканирует каталог по регламентному заданию. Способ прост в реализации и изолирует 1С от прямого доступа из внешнего интернета, однако не обеспечивает моментальной доставки (присутствует задержка между запусками регламента).
2. Встроенные Сервисы интеграции («1С:Шина»): В современных версиях платформы 1С 8.3 присутствуют механизмы работы с брокерами сообщений на уровне платформы. Продукт «1С:Шина» позволяет нативно связывать 1С с RabbitMQ или Apache Kafka по протоколу AMQP без написания собственных кастомных прослоек.
3. Использование Native API компонент: Для прямого подключения 1С к RabbitMQ в качестве Consumer (подписчика) используются внешние компоненты на C++ или C#, дергающие события 1С при появлении новых сообщений в очереди.

Проанализировав все способы, можно сделать вывод: комбинация HTTP-сервиса 1С + брокера сообщений (RabbitMQ / 1С:Шина) либо HTTP-сервиса с фолбэком в файлы является наиболее изящным, надежным и масштабируемым решением для непрерывного обмена данными.