В процессе разработки сложных механизмов интеграции или оперативного учета в среде 1С мы часто сталкиваемся с событийной моделью проведения документов. При проведении одного документа платформа выполняет цепочку вызовов: сначала очищаются старые движения (события ПередЗаписью и ПриЗаписи наборов записей регистров), затем записывается сам документ, а после формируются и записываются новые движения. В результате один и тот же обработчик подписок на события может вызываться множество раз в рамках одной транзакции.
Если перед нами стоит задача собрать список всех измененных товаров (например, для последующего обновления остатков на сайте или во внешней системе) во всех этих вызовах, возникает закономерный вопрос: где хранить этот массив данных, если стандартное свойство ДополнительныеСвойства принадлежит конкретному объекту и недоступно в обработчиках других объектов?
В этой статье мы подробно проанализируем различные архитектурные подходы, разберем их плюсы и минусы, а также предложим готовые шаблоны кода для решения этой задачи.
---
Параметры сеанса представляют собой глобальные переменные, которые живут на протяжении всего времени работы пользователя с базой данных. Они доступны в любом контексте (и в модуле документа, и в общих модулях, и в подписках на события).
Для реализации этого подхода выполним следующие шаги:
ИзмененныйИмпортТоваров) с типом ФиксированныйМассив или ХранилищеЗначения (так как обычные массивы передавать напрямую в параметры сеанса в некоторых случаях нельзя из-за требований к сериализации).ПередЗаписью документа) инициализируем этот параметр сеанса.Недостатки метода:
---
Один из самых элегантных способов сымитировать глобальную переменную "на время вызова сервера" — это использование общего модуля с включенным свойством Повторное использование возвращаемых значений.
Рассмотрим, как это работает на практике. Мы можем создать общий модуль КэшСобытийПроведения со свойствами:
Внутри модуля напишем функцию, которая возвращает мутабельное значение (например, структуру или соответствие):
Функция ПолучитьКонтейнерДанных() Экспорт
Контейнер = Новый Структура;
Контейнер.Вставить("МассивТоваров", Новый Массив);
Возврат Контейнер;
КонецФункции
Поскольку включен режим повторного использования на время вызова сервера, при первом обращении к функции КэшСобытийПроведения.ПолучитьКонтейнерДанных() платформа создаст структуру в памяти. При всех последующих обращениях в рамках этого же серверного вызова (включая все 8 подписок на события) платформа будет возвращать ссылку на тот же самый объект в памяти.
Пример использования в подписках:
// В обработчике ПередЗаписью набора записей регистра
Контейнер = КэшСобытийПроведения.ПолучитьКонтейнерДанных();
Для Каждого СтрокаЗаписи Из Источник Цикл
Если Контейнер.МассивТоваров.Найти(СтрокаЗаписи.Номенклатура) = Неопределено Тогда
Контейнер.МассивТоваров.Добавить(СтрокаЗаписи.Номенклатура);
КонецЕсли;
КонецЦикла;
Плюсы метода: Данные гарантированно уничтожаются после завершения вызова сервера, не засоряя оперативную память. Не требуется создавать дополнительные объекты в метаданных конфигурации.
---
Если задача состоит в гарантированной доставке измененных данных во внешнюю систему, то использование планов обмена является классическим и наиболее надежным решением.
Разберем этот механизм по шагам:
ИнтеграцияСВнешнейСистемой).Номенклатура) или сами документы.ПриЗаписи регистрируем изменения для конкретного узла плана обмена с помощью метода ПланыОбмена.ЗарегистрироватьИзменения().Преимущества: Полная транзакционность. Если транзакция проведения документа откатится, регистрация изменений также не запишется в базу данных. В случае сбоя сети или падения внешней системы данные никуда не исчезнут и будут отправлены при следующем сеансе обмена.
---
Для гибкого управления выгрузкой данных часто используют промежуточный регистр сведений, работающий по принципу очереди задач. Это решение сочетает в себе простоту и транзакционную надежность.
Создадим непериодический независимый регистр сведений ОчередьОбновленияОстатков со следующей структурой:
Номенклатура (Тип: СправочникСсылка.Номенклатура)ДатаИзменения (Тип: Дата)Схема работы выглядит следующим образом:
// В подписке ПриЗаписи набора записей регистра
НаборЗаписей = РегистрыСведений.ОчередьОбновленияОстатков.СоздатьНаборЗаписей();
Для Каждого Товар Из СписокИзмененныхТоваров Цикл
НоваяЗапись = НаборЗаписей.Добавить();
НоваяЗапись.Номенклатура = Товар;
НоваяЗапись.ДатаИзменения = ТекущаяДатаСеанса();
КонецЦикла;
НаборЗаписей.Записать(Истина); // Перезаписываем данные, избегая дублей
Фоновое или регламентное задание периодически (например, раз в 10 секунд) считывает этот регистр, обрабатывает порцию товаров и очищает записи из регистра.
---
Независимо от выбранного способа сбора данных, вы неизбежно столкнетесь с фундаментальной проблемой платформы 1С: нельзя запускать фоновое задание напрямую из транзакции проведения документа, если этому заданию требуются актуальные движения из базы данных.
Выясним причину: фоновое задание запускается в отдельном сеансе на сервере. В тот момент, когда в первом сеансе выполняется транзакция (код внутри подписок), эти изменения еще не зафиксированы в СУБД. Запустившись параллельно, фоновое задание попытается прочитать движения документа или записи в регистре сведений и ничего там не обнаружит (либо наткнется на старые данные), так как для него эта транзакция еще "не существует".
Как решить эту проблему? Рассмотрим два наиболее эффективных паттерна.
Этот метод позволяет синхронизировать работу фонового задания с моментом окончания транзакции в основном сеансе без использования периодических опросов базы данных.
Алгоритм работы:
ПриЗаписи документа мы запускаем фоновое задание и передаем ему ссылку на документ-регистратор в качестве параметра.Посмотрим на пример кода внутри фонового задания:
Процедура ВыполнитьОбработкуОстатков(СсылкаНаДокумент) Экспорт
НачатьТранзакцию();
// Накладываем управляемую исключительную блокировку на документ
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("Документ.РеализацияТоваровУслуг");
ЭлементБлокировки.УстановитьЗначение("Ссылка", СсылкаНаДокумент);
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
Попытка
Блокировка.Заблокировать();
Исключение
// Обработка ошибки блокировки, если превышено время ожидания
ОтменитьТранзакцию();
Возврат;
КонецПопытки;
// Проверяем, существует ли документ в базе (на случай, если транзакция отменилась)
Если ОбщегоНазначения.СсылкаСуществует(СсылкаНаДокумент) Тогда
// Здесь выполняем чтение движений и отправку во внешнюю систему
ОбработатьДвиженияДокумента(СсылкаНаДокумент);
КонецЕсли;
ЗафиксироватьТранзакцию();
КонецПроцедуры
---
Если в системе происходит массовое перепроведение документов (например, восстановление последовательности за месяц), динамический запуск фонового задания на каждый документ приведет к лавинообразному росту нагрузки на сервер 1С. Сервер быстро исчерпает лимиты рабочих процессов и зависнет.
Для таких сценариев по стандартам разработки 1С рекомендуется использовать Очередь отложенной обработки:
Этот подход гарантирует стабильность системы при любых пиковых нагрузках и обеспечивает надежную передачу данных без потери транзакционной целостности платформы 1С.