[Constantus]

Приветствую, Форумчане!
УФ, самопис

Приветствую, Форумчане!

Сделал РС, независимый. непериодический
Заполнение этого РС должно происходить в подписке на событии при проведении документа. Это что-то вроде Журнала выполнения операций и запись в РС должна происходить при любом случае (разрешено проведение или нет)
Создал процедуру его заполнения:

Процедура ЗаполнитьРезультатПроверки(Источник, РезультатПроверки, Ошибка, ТипПроверки)
    
    Запись = РегистрыСведений.РезультатыПроверок.СоздатьМенеджерЗаписи();
    Запись.Дата = ТекущаяДата();
    Запись.ОбъектДанных = Источник;
    Запись.ОписаниеОшибки = ?(РезультатПроверки, Ошибка, "");
    Запись.Результат = ?(РезультатПроверки, "Ошибка", "Успешно");
    Запись.ТипПроверки = ТипПроверки;
    Запись.Записать(); 
    
КонецПроцедуры

Отладчик показывает, что данные все заполняются правильно, но сам регистр оказывается пустым, т.е. не записывается.
Что я не так сделал? Вроде всё как по учебнику, ну и раньше вроде такое делал... Что я забыл?

Обращение к этой процедуре идет так:

 Пока Выборка.Следующий() Цикл
***************    
            ЗаполнитьРезультатПроверки(Источник.Ссылка, РезультатПроверки, Выборка.ОписаниеОшибки, Выборка.ТипПроверки);
        КонецЦикла;

Если Отказ = Ложь, т.е. проведение разрешено, то запись в регистр происходит. Но если проведение запрещено, то запись в регистр не происходит. Я так понял откатываются в небытиё все транзакции. Хотя отладчик показывает правильность заполнения данными в регистр, запись не происходит.

Как можно справится с ситуацией? Т.е. чтобы запись в РС происходила при любом раскладе...

[Batchir]

Стартовать фоновое задание, которое будет писать регистр вне транзакции проведения

[Constantus]

Batchir @ Сегодня, 4:03 ,

И как это всё сделать? Даже не понимаю дальнейшие действия...

[andr_andrey]

Constantus @ 27.11.21, 19:46 ,
Вам, оказывается, уже на инфостарте ответили.

Сообщение отредактировал andr_andrey - 29.11.21, 9:23

[Vofka]

Constantus, если документ не проводится, то записывайте туда из процндуры ПриЗаписи(), например.

[Batchir]

Constantus @ Вчера, 0:10 ,\

В общем модуле описываешь свою процедуру записи и затем стартуешь фоновое задание с этой процедурой
Можно запустить вручную, написав что-то типа ФоновыеЗадания.Выполнить("ТвояПроцедура", МассивПараметровТвоейПроцедуры, Ключ, Наименование)
Детально в справке описано

Если в конфигурации используется БСП, то есть механизм длительных операций (я лично всегда его использовал, т.к. все конфигурации с которыми работаю используют БСП)

[Constantus]

andr_andrey @ Сегодня, 13:18 ,
Я к тутошним больше прислушиваюсь

Спасибо. Вроде получилось через фондовую биржу (фоновые задания). Получается таким макаром можно наладить проведение документа при любом раскладе...

[Batchir]

Получается таким макаром можно наладить проведение документа при любом раскладе..

Ну тут логика проста.
Если идет отмена транзакции то все изменения данных которые были в рамках этой транзакции откатываются.
Фоновое задание запускается и выполняется отдельным сеансом вне транзакции проведения/записи документа, поэтому не откатываются.

Но тут есть проблема на самом деле. Нужно быть уверенным что проводимый/записываемый документ гарантированно попадет в базу.
Например, нажимаете кнопку ЗаписатьПровести в новом документе.
В подписке ссылка на объект уже есть. Вы стартуете фоновое для того что бы записать данные в регистр.
Но потом где-то в рамках транзакции записи/проведения документа происходит какая-то ошибка (или предусмотрен логикой ОТКАЗ)
и документ не записывается/проводится.
В результате имеем что ссылки на объект для нового документа в базе не появилось, а в регистре фоновым заданием данные появились по ссылке <Объект не найден>.

[Vofka]

Я, честно говоря, не могу придумать сценария, когда понадобилось бы что-то куда-то писать в случае, когда запись документа не отработала (транзакция отменилась). Поэтому я бы не выносил это за рамки транзакции и делал бы это в ПриЗаписи().

[Batchir]

Ну мало ли какая логика может быть заложена.
Например, не важно провелся документ или нет - нужно запустить обновление данных какого-то регистра (к примеру состояний заказов).
И это обновление не нужно делать именно в транзакции проведения.

У меня лично часто происходит следующий кейс.
Нужно делать так что бы именно после удачной фиксации транзакции проведения запускался какой-то алгоритм.
К сожалению стандартного события "после проведения" нет и приходится изощряться с помощью рег. задания (но это отдельная история).
В обычной системе в этом нет необходимости, но всё меняется для высоконагруженных систем.
Приходится для увеличения пропускной способности выносить формирование некоторых движений после проведения документов.
Общий сценарий такой
- проводится документ, начинается транзакция проведения
- оперативные регистры необходимые для работы пишутся самим документом
- заканчивается проведение, фиксируется транзакция
- если транзакция успешна, то стартует фоновое задание, пишутся не оперативные регистры по документу

В итоге транзакцию проведения можно разогнать в несколько раз, соответственно так же увеличить в несколько раз количество проводимых документов в системе.

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

[andr_andrey]

... но всё меняется для высоконагруженных систем ... стартует фоновое задание, пишутся не оперативные регистры по документу

Если система действительно высоконагружена, может уже писать в очередь сообщений, или пока куча фоновых успевает отрабатывать на сервере 1С?

[Constantus]

Vofka @ 01.12.21, 15:11 ,

Это была учебная задача. Даже сами авторы признали, что это всё нежизнеспособно.
Просто решили проверить сможу ли я это сделать или нет...

[Batchir]

andr_andrey @ Сегодня, 11:00 ,
На самом деле так и делается))) В самой транзакции проведения фиксируется сам факт необходимости формирования отложенных движений в отдельном регистре сведений. А затем стартует алгоритм формирования движений. Этот алгоритм уже обрабатывает эту очередь многопоточно N фоновыми заданиями.
Сам алгоритм управления фоновыми достаточно сложный. Если в двух словах, то он должен уметь запускать определённое количество фоновых и так что бы наборы не пересекались чтоб не ловить блокировки. Огромная куча фоновых заданий так же положит систему. В общем как я и написал - это отдельная история)))

[andr_andrey]

фиксируется сам факт необходимости формирования отложенных движений в отдельном регистре сведений

Спасибо. Я думал вы уже RabbitMQ/Kafka и им подобные используете.