Интеграция систем через 1С:Шину открывает широкие возможности для построения отказоустойчивых архитектур. Однако начинающие разработчики часто сталкиваются с трудностями при попытке «забрать» данные из Шины на внешний сайт или в стороннее приложение. В этой статье мы подробно разберем, как правильно организовать взаимодействие по протоколу HTTP, настроить параметры запросов и что делать, если очередь сообщений «застряла» из-за ошибок сервера. Для более глубокого освоения базовых протоколов начинающим разработчикам будет полезен интерактивный курс по работе с HTTP-запросами.
Прежде всего, проанализируем базовый принцип работы 1С:Шины. Важно понимать, что Шина по своей сути не является хранилищем данных, из которого внешний сайт может в любой момент «вытянуть» (Pull) информацию, если это не настроено специфическим образом. Рассмотрим два основных сценария:
HTTP-сервис. В этом случае Шина будет выступать сервером, а сайт — клиентом.В большинстве случаев разработчики используют первый вариант, когда 1С отправляет данные в Шину, а Шина мгновенно пересылает их на сайт. Разберем настройку этой схемы подробнее.
При настройке процесса интеграции в среде разработки 1С:Шины мы используем узел Http. Начиная с версии 3.1, параметры адресации разделены на URL и API. Разберем по шагам, как их заполнить:
URL: Здесь мы указываем базовый адрес сервера, например, https://mysite.ru.
API: Здесь указывается относительный путь к конкретному методу вашего сервиса, например, /v1/integration/update_data. Если вам нужно передать динамические параметры (например, идентификатор ресурса), можно использовать шаблоны пути.
Часто возникает вопрос: как управлять телом запроса и его заголовками? По умолчанию Шина помещает тело сообщения в тело HTTP-запроса автоматически. Однако для корректной работы принимающей стороны (сайта) часто требуются специфические заголовки, такие как Content-Type: application/json или токены авторизации.
Рассмотрим пример кода на языке Шины (основанном на языке 1С:Исполнитель), который позволяет модифицировать запрос перед отправкой:
метод ПодготовитьЗапрос(Контекст: Sample.КонтекстВызова, Сообщение: Sample.Сообщение, Запрос: ЗапросHttp): ЗапросHttp
// Добавляем необходимые заголовки
Запрос.Заголовки.Добавить("Content-Type", "application/json");
Запрос.Заголовки.Добавить("Authorization", "Bearer your_token_here");
// Можно добавить пользовательский заголовок для отладки
Запрос.Заголовки.Добавить("X-Source-System", "1C-Bus");
возврат Запрос;
КонецМетода
Если в мониторинге Шины вы видите, что счетчик входящих сообщений растет, а исходящих — нет, и при этом фиксируется Ошибка 500, это означает, что запрос дошел до сайта, но сайт не смог его обработать. Проанализируем основные причины:
Выясним причину через логи. В консоли администратора 1С:Шины можно посмотреть детальный текст ответа от сервера. Часто там содержится подсказка: например, сообщение о том, что какое-то обязательное поле в JSON отсутствует. Для ручной проверки отправки запросов и анализа ответов сервера удобно использовать обработку для тестирования HTTP-сервисов.
Одной из ключевых особенностей 1С:Шины является гарантированная доставка. Если сайт временно недоступен или вернул ошибку, Шина не удаляет сообщение, а пытается отправить его снова. По умолчанию количество попыток может быть неограниченным, что приводит к «засорению» очереди «плохими» пакетами.
Чтобы пакеты, пришедшие с ошибкой, не блокировали последующие нормальные сообщения, проанализируем следующие настройки:
Рассмотрим ситуацию, когда вам нужно передавать разные типы данных (например, Группы пользователей и Подразделения) на разные URL одного и того же сайта. Как лучше поступить?
Проанализируем два подхода:
Вариант 1: Параллельные ветки в одном процессе. Вы можете разветвить схему внутри одного процесса интеграции. Однако помните, что в этом случае все ветки будут делить общие ресурсы потоков и одну очередь. Если возникнет критическая ошибка в одной ветке, это может косвенно повлиять на мониторинг всего процесса.
Вариант 2: Отдельные процессы интеграции. Это более надежный подход. Создание отдельного процесса для каждой сущности (Группы, Подразделения, Товары) позволяет настраивать их независимо. Вы сможете останавливать, обновлять или очищать очередь для одного справочника, не прерывая синхронизацию других. Также это позволяет задать разные интервалы повторов и адреса API для каждого типа данных.
В заключение отметим, что при работе с динамическими параметрами в URL (например, когда нужно подставить resourceId прямо в строку адреса), следует активно использовать программную подготовку запроса в скриптах. Это позволяет гибко формировать путь вызова, исходя из содержимого самого сообщения, приходящего из 1С.