При разработке интеграционных решений в 1С часто возникает задача отправки данных во внешнюю систему сразу после их изменения или создания. Наиболее очевидным, но, как мы увидим, не всегда правильным подходом может показаться вызов HTTP-сервиса непосредственно в обработчиках событий записи объекта, таких как ПриЗаписи. Однако такой подход чреват серьезными проблемами, которые могут привести к нестабильности системы, потере данных и ухудшению производительности. Давайте подробно рассмотрим, почему синхронная отправка данных при записи объекта является плохой практикой и какое решение будет наиболее надежным и эффективным.
Вызов внешних систем с использованием HTTP-запросов напрямую из обработчиков событий записи объекта (ПриЗаписи, ОбработкаПроведения и т.п.) — это распространенная, но крайне нежелательная практика. Мы выделяем несколько ключевых причин, по которым следует избегать такого подхода:
Производительность: Синхронные HTTP-запросы могут занимать значительное время. Это время включает в себя установку соединения, отправку данных, ожидание обработки запроса на стороне внешнего сервиса и получение ответа. Если такой вызов происходит в контексте интерактивной записи объекта пользователем, то вся транзакция 1С блокируется на время выполнения HTTP-запроса. Это приводит к:
Надежность транзакций и консистентность данных: Это одна из наиболее критичных проблем. Представим ситуацию: вы отправили данные во внешнюю систему через HTTP-запрос, но затем транзакция в 1С по какой-либо причине отменилась. Например, из-за ошибки валидации в другом обработчике события, или пользователь нажал кнопку "Отмена", или произошел сбой на сервере 1С. В результате мы получаем рассогласование данных:
Находясь в процедуре ПриЗаписи объекта, вы еще не можете быть уверены, что объект будет успешно записан. Транзакция еще не завершена, и любой последующий код или подписка на событие может отменить запись. Событие ПослеЗаписи, которое могло бы гарантировать успешное завершение транзакции, доступно только при интерактивной записи, что не покрывает все сценарии (например, программную запись).
Масштабируемость и устойчивость: При большом количестве записей синхронные вызовы создают значительную нагрузку как на сервер 1С, так и на внешний HTTP-сервис. Если внешний сервис временно недоступен или работает медленно, это напрямую влияет на работоспособность 1С-системы. Также, отправка каждого мельчайшего изменения (например, поставили-сняли галочку, изменили реквизит, добавили-удалили строчку) может быть излишней, создавая 100500 версий одного и того же элемента во внешней системе, что часто не требуется и нагружает обе системы.
Кроме того, вопрос автора темы о возможности единожды создать HTTPСоединение и использовать его повторно, например, в ПараметрахСеанса, также имеет свои нюансы. Даже если бы не было проблем с транзакциями, HTTPСоединение не предназначено для длительного хранения и повторного использования на протяжении всего сеанса. Оно может быть разорвано по таймауту на сервере (обычно 150-300 секунд, если не настроено иное), из-за сетевых проблем или перезапуска сервиса. Соответственно, при каждой отправке данных соединение, скорее всего, придется пересоздавать.
Для обеспечения надежной, производительной и масштабируемой отправки данных из 1С во внешние системы мы настоятельно рекомендуем использовать асинхронный подход. Он базируется на создании промежуточной очереди задач и их последующей обработке с помощью фоновых заданий.
Вместо прямой отправки данных при записи объекта, мы создаем запись в специальном хранилище, которая представляет собой задачу на отправку. Этим хранилищем обычно выступает специальный регистр сведений. Данные, необходимые для HTTP-запроса, временно сохраняются в этом регистре, ожидая своей очереди на отправку.
Регистр сведений должен содержать следующие поля:
ИдентификаторОбъекта (Тип: Строка или УникальныйИдентификатор) — уникальный идентификатор объекта, изменения которого нужно отправить. Это может быть УникальныйИдентификатор ссылки на справочник или документ.ТипОбъекта (Тип: Строка) — имя метаданных объекта (например, "Справочник.Номенклатура").ДанныеДляОтправки (Тип: ХранилищеЗначения) — здесь будут храниться сериализованные данные объекта или его ключевые реквизиты, которые необходимо отправить во внешнюю систему. Это может быть структура, массив, или даже полный объект, помещенный в ХранилищеЗначения.СтатусОтправки (Тип: Перечисление, например: "Новая", "ВОбработке", "ОтправленаУспешно", "ОшибкаОтправки", "Отменена") — текущее состояние задачи.КоличествоПопыток (Тип: Число) — счетчик попыток отправки данных.ДатаСледующейПопытки (Тип: Дата) — дата и время, когда фоновое задание может попытаться отправить данные снова.ТекстОшибки (Тип: Строка) — описание последней ошибки, если отправка завершилась неудачно.ДатаСозданияЗадачи (Тип: Дата) — для аудита.Если речь идет об обмене между конфигурациями 1С, более подходящим может быть использование стандартных механизмов ПлановОбмена. Они автоматически регистрируют изменения объектов и позволяют выгружать их по расписанию. Даже при использовании ПлановОбмена, если целевой системой является внешний HTTP-сервис, рекомендуется комбинировать его с асинхронной отправкой через фоновое задание, которое будет читать данные из таблицы регистрации изменений плана обмена и отправлять их.
В обработчике события ПриЗаписи (или ПослеЗаписи для интерактивных форм) объекта мы добавляем запись в наш регистр сведений.
// В модуле объекта справочника "Номенклатура"
Процедура ПриЗаписи(Отказ)
// Важно: проверяем, что объект не находится в режиме загрузки данных,
// чтобы не создавать задачи при загрузке из других систем.
Если НЕ Свойство("ДополнительныеСвойства") Тогда
ДополнительныеСвойства = Новый Структура();
КонецЕсли;
Если ДополнительныеСвойства.Свойство("БезОтправкиВWebСервис") И ДополнительныеСвойства.БезОтправкиВWebСервис Тогда
Возврат; // Пропускаем отправку, если установлено специальное свойство
КонецЕсли;
// ... ваша основная логика ПриЗаписи ...
// Получаем актуальные данные для отправки.
// Можно сериализовать объект целиком или только нужные реквизиты.
ПередаваемыеДанные = Новый Структура();
ПередаваемыеДанные.Вставить("Ссылка", Ссылка);
ПередаваемыеДанные.Вставить("Наименование", Наименование);
ПередаваемыеДанные.Вставить("Артикул", Артикул);
// ... другие нужные реквизиты ...
// Создаем новую запись в регистре сведений "ОчередьОтправкиДанныхВWebСервис"
ЗаписьОчереди = РегистрыСведений.ОчередьОтправкиДанныхВWebСервис.СоздатьМенеджерЗаписи();
ЗаписьОчереди.ИдентификаторОбъекта = Строка(УникальныйИдентификатор);
ЗаписьОчереди.ТипОбъекта = Метаданные().Имя;
ЗаписьОчереди.ДанныеДляОтправки = Новый ХранилищеЗначения(ПередаваемыеДанные, Новый СжатиеДанных(9));
ЗаписьОчереди.СтатусОтправки = Перечисления.СтатусыОтправкиДанных.Новая;
ЗаписьОчереди.КоличествоПопыток = 0;
ЗаписьОчереди.ДатаСледующейПопытки = ТекущаяДата();
ЗаписьОчереди.ДатаСозданияЗадачи = ТекущаяДата();
Попытка
ЗаписьОчереди.Записать();
Исключение
// Обработка ошибки записи в регистр, если таковая возникнет.
// Это маловероятно, но лучше предусмотреть.
Сообщить("Ошибка при добавлении задачи в очередь отправки: " + ОписаниеОшибки());
КонецПопытки;
КонецПроцедуры
Регламентное задание (которое по сути запускает фоновые задания) периодически опрашивает наш регистр сведений, выбирает задачи со статусом "Новая" или "ОшибкаОтправки" (с учетом ДатаСледующейПопытки) и отправляет данные через HTTP-сервис.
Создайте новое регламентное задание в конфигурации, указав имя метода, который будет его выполнять. Например, "МодульОбменаСWebСервисом.ОбработатьОчередьОтправки". Настройте расписание выполнения (например, каждые 30 секунд или 1 минуту, в зависимости от требуемой оперативности).
Внутри метода фонового задания реализуем следующую логику:
ДатаСледующейПопытки меньше или равна текущей дате), сортируем по дате создания.ДанныеДляОтправки (распаковываем ХранилищеЗначения).HTTPСоединение. Важно: соединение создается и закрывается для каждого запроса или пакета запросов, обеспечивая актуальность и независимость.ТекстОшибки.КоличествоПопыток, записываем ТекстОшибки и устанавливаем ДатаСледующейПопытки с задержкой (см. ниже).Как мы уже обсуждали, если вы добавляете задачу в очередь в процедуре ПриЗаписи, сама транзакция записи еще не завершена. Чтобы гарантировать, что мы отправляем данные только успешно записанных объектов, мы можем немного модифицировать логику.
Вместо того чтобы отправлять сериализованные данные объекта напрямую из ПриЗаписи, мы можем передать в фоновое задание только идентификатор объекта и его тип. Затем, в самом фоновом задании, мы попытаемся прочитать этот объект из базы данных. Если объект успешно читается, это означает, что транзакция записи завершилась успешно и данные доступны. Если объект не читается (например, возвращается Неопределено), значит, транзакция была отменена, и мы можем безопасно удалить задачу из очереди.
// Пример метода для фонового задания в общем модуле
Процедура ОбработатьОчередьОтправки() Экспорт
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ОчередьОтправкиДанныхВWebСервис.ИдентификаторОбъекта,
| ОчередьОтправкиДанныхВWebСервис.ТипОбъекта,
| ОчередьОтправкиДанныхВWebСервис.ДанныеДляОтправки,
| ОчередьОтправкиДанныхВWebСервис.КоличествоПопыток
|ИЗ
| РегистрСведений.ОчередьОтправкиДанныхВWebСервис КАК ОчередьОтправкиДанныхВWebСервис
|ГДЕ
| ОчередьОтправкиДанныхВWebСервис.СтатусОтправки В (&СтатусыДляОбработки)
| И ОчередьОтправкиДанныхВWebСервис.ДатаСледующейПопытки <= &ТекущаяДата
|УПОРЯДОЧИТЬ ПО
| ОчередьОтправкиДанныхВWebСервис.ДатаСозданияЗадачи";
Запрос.УстановитьПараметр("СтатусыДляОбработки", Новый Массив({
Перечисления.СтатусыОтправкиДанных.Новая,
Перечисления.СтатусыОтправкиДанных.ОшибкаОтправки
}));
Запрос.УстановитьПараметр("ТекущаяДата", ТекущаяДата());
ВыборкаЗадач = Запрос.Выполнить().Выбрать();
Пока ВыборкаЗадач.Следующий() Цикл
МенеджерЗаписи = РегистрыСведений.ОчередьОтправкиДанныхВWebСервис.СоздатьМенеджерЗаписи();
МенеджерЗаписи.ИдентификаторОбъекта = ВыборкаЗадач.ИдентификаторОбъекта;
МенеджерЗаписи.ТипОбъекта = ВыборкаЗадач.ТипОбъекта;
// Устанавливаем блокировку на запись регистра, чтобы избежать одновременной обработки
// того же элемента другим фоновым заданием.
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрСведений.ОчередьОтправкиДанныхВWebСервис");
ЭлементБлокировки.УстановитьЗначение("ИдентификаторОбъекта", ВыборкаЗадач.ИдентификаторОбъекта);
ЭлементБлокировки.УстановитьЗначение("ТипОбъекта", ВыборкаЗадач.ТипОбъекта);
ЭлементБлокировки.РежимБлокировки = РежимБлокировкиДанных.Исключительный;
Попытка
Блокировка.Заблокировать();
Если МенеджерЗаписи.Прочитать() Тогда // Проверяем, что запись очереди существует
Если МенеджерЗаписи.СтатусОтправки = Перечисления.СтатусыОтправкиДанных.Новая
ИЛИ (МенеджерЗаписи.СтатусОтправки = Перечисления.СтатусыОтправкиДанных.ОшибкаОтправки
И МенеджерЗаписи.ДатаСледующейПопытки <= ТекущаяДата()) Тогда
МенеджерЗаписи.СтатусОтправки = Перечисления.СтатусыОтправкиДанных.ВОбработке;
МенеджерЗаписи.Записать(); // Обновили статус
РезультатОтправки = Ложь;
ТекстОшибки = "";
Попытка
// ПОПЫТКА ПРОЧИТАТЬ ОБЪЕКТ ПОСЛЕ ЗАВЕРШЕНИЯ ТРАНЗАКЦИИ
СсылкаОбъекта = Неопределено;
Если ЗначениеЗаполнено(ВыборкаЗадач.ИдентификаторОбъекта) Тогда
ТипОбъекта = Метаданные.НайтиПоИмени(ВыборкаЗадач.ТипОбъекта);
Если ТипОбъекта <> Неопределено Тогда
Попытка
УИД = Новый УникальныйИдентификатор(ВыборкаЗадач.ИдентификаторОбъекта);
СсылкаОбъекта = Тип(ТипОбъекта.Имя).ПолучитьСсылку(УИД);
Исключение
// Возможно, неверный УИД
КонецПопытки;
КонецЕсли;
КонецЕсли;
Если СсылкаОбъекта = Неопределено Тогда
// Объект не найден или некорректный идентификатор, транзакция отменена.
// Удаляем задачу из очереди.
ТекстОшибки = "Объект по ссылке не найден в базе данных. Вероятно, транзакция была отменена.";
РезультатОтправки = Истина; // Считаем, что задачу обработали, удалим ее
МенеджерЗаписи.СтатусОтправки = Перечисления.СтатусыОтправкиДанных.Отменена;
МенеджерЗаписи.ТекстОшибки = ТекстОшибки;
МенеджерЗаписи.Записать();
Иначе
// Объект найден, его можно прочитать и отправить актуальные данные.
// Для получения данных, если не сохранили в очередь, можно использовать:
// Объект = СсылкаОбъекта.ПолучитьОбъект();
// Если Объект = Неопределено Тогда
// // Опять же, объект не найден, хотя ссылка получена.
// ТекстОшибки = "Не удалось получить объект по ссылке.";
// РезультатОтправки = Ложь;
// Иначе
// Если данные для отправки уже сохранены в очередь (как в нашем примере ПриЗаписи),
// то используем их. Это снижает нагрузку на БД при чтении.
ДанныеДляОтправки = ВыборкаЗадач.ДанныеДляОтправки.Получить();
// --- Здесь формируем и отправляем HTTP-запрос ---
// Пример:
HTTPСоединение = Новый HTTPСоединение("example.com", , , , , 60, Истина); // Таймаут 60 сек
HTTPЗапрос = Новый HTTPЗапрос("/api/data");
HTTPЗапрос.УстановитьТелоИзСтроки(
JSONСериализатор.Записать(ДанныеДляОтправки),
КодировкаТекста.UTF8, "application/json");
// Дополнительные заголовки, если нужны
HTTPЗапрос.Заголовки.Вставить("Authorization", "Bearer token123");
HTTPОтвет = HTTPСоединение.Отправить(HTTPЗапрос);
Если HTTPОтвет.Код = 200 Или HTTPОтвет.Код = 201 Тогда
РезультатОтправки = Истина;
МенеджерЗаписи.СтатусОтправки = Перечисления.СтатусыОтправкиДанных.ОтправленаУспешно;
МенеджерЗаписи.ТекстОшибки = "";
МенеджерЗаписи.Записать();
Иначе
ТекстОтвета = HTTPОтвет.ПолучитьТелоКакСтроку(КодировкаТекста.UTF8);
ТекстОшибки = "Ошибка HTTP-запроса: " + HTTPОтвет.Код + " " + ТекстОтвета;
РезультатОтправки = Ложь;
КонецЕсли;
// --- Конец формирования и отправки HTTP-запроса ---
КонецЕсли; // Если СсылкаОбъекта = Неопределено
Исключение
ТекстОшибки = "Ошибка при обработке задачи: " + ОписаниеОшибки();
РезультатОтправки = Ложь;
КонецПопытки;
Если НЕ РезультатОтправки Тогда
МенеджерЗаписи.СтатусОтправки = Перечисления.СтатусыОтправкиДанных.ОшибкаОтправки;
МенеджерЗаписи.КоличествоПопыток = МенеджерЗаписи.КоличествоПопыток + 1;
МенеджерЗаписи.ТекстОшибки = ТекстОшибки;
// Устанавливаем дату следующей попытки с экспоненциальной задержкой
МенеджерЗаписи.ДатаСледующейПопытки = ТекущаяДата() + Секунда(60 * Pow(2, МенеджерЗаписи.КоличествоПопыток)); // Например, 1, 2, 4, 8 минут
МенеджерЗаписи.Записать();
КонецЕсли;
КонецЕсли; // Если статус подходит для обработки
КонецЕсли; // Если запись очереди прочиталась
Исключение
Сообщить("Ошибка блокировки или обработки записи очереди: " + ОписаниеОшибки());
КонецПопытки;
КонецЦикла;
КонецПроцедуры
Ключевым преимуществом асинхронной очереди является возможность надежной обработки ошибок. В нашем регистре сведений мы предусмотрели поля КоличествоПопыток и ДатаСледующейПопытки. При возникновении ошибок HTTP-запроса (сетевая ошибка, таймаут, ошибка на стороне сервиса) задача помечается как ошибочная, счетчик попыток увеличивается, и устанавливается дата, когда фоновое задание должно попытаться отправить данные снова.
Мы рекомендуем использовать стратегию экспоненциальной задержки при повторных попытках. Это означает, что интервал между попытками увеличивается с каждой неудачей. Например:
Это позволяет избежать создания избыточной нагрузки на внешний сервис при его временной недоступности и дает ему время на восстановление. Также важно установить разумное максимальное количество попыток, после которого задача помечается как окончательно "ОшибкаОтправки", требующая ручного вмешательства. Например, после 5-10 попыток.
Когда вы добавляете данные в очередь из обработчика ПриЗаписи, важно убедиться, что это происходит только при *изменении данных пользователем или основной логикой*, а не при загрузке данных в 1С из других систем (например, при первоначальной загрузке или синхронизации). Если этого не сделать, каждая загруженная запись также попадет в очередь на отправку, что приведет к дублированию или циклической отправке.
Для предотвращения такой ситуации существуют несколько подходов:
Использование Объект.ЗагрузкаДанных: Это стандартное свойство объекта в 1С, которое принимает значение Истина при программной загрузке данных. Его можно проверить в обработчике:
Процедура ПриЗаписи(Отказ)
Если Свойство("ЗагрузкаДанных") И ЗагрузкаДанных Тогда
Возврат; // Не отправляем данные, если объект загружается программно
КонецЕсли;
// ... остальная логика добавления в очередь ...
КонецПроцедуры
Использование ДополнительныеСвойства: Более гибкий способ. Вы можете программно установить специальное свойство в ДополнительныеСвойства объекта перед записью, и проверять его в обработчике. Это особенно полезно, когда ЗагрузкаДанных не соответствует вашему сценарию (например, вы хотите пропустить отправку при определенном типе программной записи, не связанной с "загрузкой").
// В коде, который программно записывает объект без необходимости отправки
НовыйЭлемент = Справочники.Номенклатура.СоздатьЭлемент();
// ... заполняем реквизиты ...
НовыйЭлемент.ДополнительныеСвойства.Вставить("БезОтправкиВWebСервис", Истина); // Добавляем флаг
НовыйЭлемент.Записать();
// В обработчике ПриЗаписи объекта
Процедура ПриЗаписи(Отказ)
Если НЕ Свойство("ДополнительныеСвойства") Тогда
ДополнительныеСвойства = Новый Структура();
КонецЕсли;
Если ДополнительныеСвойства.Свойство("БезОтправкиВWebСервис") И ДополнительныеСвойства.БезОтправкиВWebСервис Тогда
Возврат; // Пропускаем отправку, если установлен флаг
КонецЕсли;
// ... остальная логика добавления в очередь ...
КонецПроцедуры
Мы рекомендуем использовать комбинацию этих подходов или ДополнительныеСвойства для максимальной гибкости.
При проектировании обмена критически важно обеспечить идемпотентность операций на стороне внешней системы. Это означает, что повторная отправка одного и того же запроса (с одними и теми же данными и идентификатором) должна приводить к тому же результату, что и однократная отправка. Например, если вы отправляете данные о создании нового элемента, внешняя система должна уметь определить, что такой элемент с данным уникальным идентификатором (например, УникальныйИдентификатор из 1С) уже был создан, и не создавать его повторно, а, возможно, обновить или просто проигнорировать дубликат.
Идемпотентность необходима для корректной работы механизма повторных попыток. Если внешний сервис не идемпотентен, каждая повторная попытка будет приводить к созданию дубликатов или нежелательным побочным эффектам.
Обязательно реализуйте подробное логирование всех операций отправки данных. В логах должны фиксироваться:
Помимо логирования, необходимо реализовать мониторинг состояния очереди отправки. Это может быть отдельный отчет, который показывает количество задач в очереди по статусам ("Новая", "В обработке", "ОшибкаОтправки"), или система оповещений (например, по электронной почте) при накоплении критического числа ошибочных задач. Мониторинг позволяет оперативно выявлять проблемы в интеграции и реагировать на них, предотвращая "зависание" обмена данными.
Таким образом, наиболее надежным, производительным и масштабируемым подходом для отправки данных из 1С через HTTP-сервис при записи справочника является использование очереди задач, обрабатываемой фоновыми заданиями. Этот подход позволяет отделить логику отправки от логики записи, гарантировать целостность данных и обеспечить устойчивость системы к временным сбоям внешних сервисов.