При проектировании интернет-магазина перед разработчиками и архитекторами всегда встает ключевой вопрос: как связать учетную систему 1С и CMS сайта. На практике часто используются устаревшие или небезопасные методы, такие как прямая запись в базу данных СУБД сайта. Давайте подробно разберем, какие технологии обмена существуют, проанализируем их плюсы и минусы, а также рассмотрим современные надежные архитектурные паттерны для организации бесперебойного обмена данными.
На первый взгляд, метод прямой записи данных из 1С в СУБД сайта (например, MySQL через ODBC-драйвер) кажется самым простым и быстрым в реализации. Разработчик напрямую манипулирует таблицами CMS, минуя создание каких-либо интерфейсов на стороне сайта. Однако этот подход таит в себе серьезные архитектурные риски:
Классический подход, проверенный временем. Обмен происходит путем выгрузки xml-файлов в определенном формате (чаще всего это отечественный отраслевой стандарт CommerceML) на FTP-сервер. Скрипт на стороне сайта по расписанию (cron) считывает эти файлы и обновляет информацию в интернет-магазине.
Преимущества:
1С:Управление нашей фирмой или 1С:Управление торговлей, поддерживают обмен по CommerceML «из коробки»).Недостатки:
Современным стандартом веб-разработки является использование HTTP-сервисов. В платформе 1С начиная с версии 8.3 есть мощный встроенный инструмент для создания собственных API — объект метаданных HTTP-сервисы. Обмен в данном случае строится на передаче компактных пакетов данных в формате JSON или XML по протоколу HTTP/HTTPS.
Давайте разберем по шагам, как устроен этот процесс. Сайт отправляет POST-запрос с данными о новом заказе на URL-адрес опубликованной базы 1С. Встроенный HTTP-сервис 1С мгновенно обрабатывает запрос, создает документ и возвращает сайту ответ со статусом выполнения.
Рассмотрим пример кода на стороне 1С для обработки входящего JSON-пакета с заказом покупателя:
Функция СоздатьЗаказНаСайте(Запрос)
Ответ = Новый HTTPСервисОтвет(200);
Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
// Получаем тело запроса в виде строки
СтрокаТела = Запрос.ПолучитьТелоКакСтроку("UTF-8");
// Читаем JSON данные
ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(СтрокаТела);
ДанныеЗаказа = ПрочитатьJSON(ЧтениеJSON);
ЧтениеJSON.Закрыть();
Попытка
НачатьТранзакцию();
// Создаем новый документ в базе 1С
НовыйЗаказ = Документы.ЗаказПокупателя.СоздатьДокумент();
НовыйЗаказ.Дата = ТекущаяДата();
НовыйЗаказ.Контрагент = НайтиКонтрагентаПоID(ДанныеЗаказа.ИдентификаторКлиента);
НовыйЗаказ.Комментарий = "Заказ с сайта № " + ДанныеЗаказа.НомерЗаказа;
// Заполнение табличной части товары
Для Каждого СтрокаТовара Из ДанныеЗаказа.Товары Цикл
НоваяСтрока = НовыйЗаказ.Запасы.Добавить();
НоваяСтрока.Номенклатура = НайтиНоменклатуруПоКоду(СтрокаТовара.КодТовара);
НоваяСтрока.Количество = СтрокаТовара.Количество;
НоваяСтрока.Цена = СтрокаТовара.Цена;
КонецЦикла;
НовыйЗаказ.Записать(РежимЗаписиДокумента.Проведение);
ЗафиксироватьТранзакцию();
// Формируем успешный ответ
СтруктураОтвета = Новый Структура("success, message", Истина, "Заказ успешно создан с номером " + НовыйЗаказ.Номер);
Исключение
ОтменитьТранзакцию();
СтруктураОтвета = Новый Структура("success, message", Ложь, ОписаниеОшибки());
Ответ.КодСостояния = 500;
КонецПопытки;
// Записываем ответ в формате JSON
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, СтруктураОтвета);
Ответ.УстановитьТелоИзСтроки(ЗаписьJSON.Закрыть(), "UTF-8");
Возврат Ответ;
КонецФункции
Преимущества HTTP-сервисов:
Если нет желания или возможности писать программный код API на стороне 1С, мы можем задействовать стандартный интерфейс OData. Начиная с платформы 8.3.5, 1С умеет автоматически предоставлять REST-доступ к объектам конфигурации.
Для активации достаточно запустить публикацию информационной базы на веб-сервере и отметить галочкой флаг "Публиковать стандартный интерфейс OData". После этого внешние системы (в том числе CMS сайта) смогут отправлять запросы для чтения, создания и изменения справочников и документов напрямую, используя стандартные HTTP-методы (GET, POST, PATCH, DELETE).
Однако помните о безопасности: доступ к OData необходимо строго разграничивать на уровне ролей специального пользователя интеграции, чтобы сайт не имел доступа к конфиденциальным финансовым регистрам.
Если ваш интернет-магазин обрабатывает сотни заказов в час, а номенклатурный ряд превышает десятки тысяч позиций, архитектура прямого обращения «сайт -> 1С» может не справиться с нагрузкой. В пиковые часы (распродажи, праздники) 1С может зависнуть из-за обилия входящих HTTP-запросов, а сайт начнет выдавать пользователям ошибку "504 Gateway Timeout".
Для решения этой проблемы применяют архитектуру с использованием промежуточного ПО (Middleware) — брокеров сообщений (RabbitMQ, Apache Kafka) или специализированной 1С:Шины.
При таком подходе сайт при создании заказа не стучится напрямую в 1С. Он быстро сбрасывает JSON-пакет в очередь брокера (например, в RabbitMQ) и сразу подтверждает клиенту, что заказ принят. База 1С асинхронно, по мере своей производительности, забирает сообщения из очереди и обрабатывает их последовательно. Если база 1С будет временно отключена для проведения технического обслуживания или обновления конфигурации, сайт продолжит бесперебойно работать, аккумулируя заказы в очереди брокера. Ни одна продажа не потеряется.
Вне зависимости от выбранного технического транспорта, при проектировании надежного обмена обязательно закладывайте следующие принципы:
/hs/site_exchange/v1/orders). Когда вам потребуется обновить структуру обмена, вы сможете запустить версию v2 параллельно со старой, не прерывая работу сайта.Подводя итог, можно сказать: для небольших проектов с низкой частотой заказов отлично подойдет стандартный обмен файлами по расписанию или публикация OData. Однако для создания масштабируемой, быстрой и безопасной системы интеграции с произвольной CMS лучшим выбором будет разработка собственных HTTP-сервисов 1С на базе JSON или использование асинхронных очередей RabbitMQ.