Как откатить транзакцию с фоновыми заданиями
1С:Предприятие 8.3 (8.3.23.1865)
Управляемые формы
Привожу проблему на упрощенном примере для понимания
Суть проблемы:
Начинаем транзакцию
Создаем документ РТУ (пока не записываем)
Фоновыми заданиями параллельно создаем 100 номенклатур
Заполняем РТУ этими номенклатурами
(В каждом фоновом задании созданные номенклатуры помещаются в буфер - регистр сведений. Оттуда мы берем при заполнении РТУ и тут же очищаем регистр сведений)
Записываем РТУ
Если РТУ записывается, то все ок.
Если РТУ не записывается, тогда выполняем отмену транзакций
Но номенклатуры остаются, т. к. они были созданы фоновыми заданиями.
(Регистр сведений Буфер, естественно, тоже остается заполненным, т. к. произошел * транзакций)
Как можно откатить эти действия тоже? Чтобы не создавались номенклатуры
Фоновые задания используются, чтобы распараллелить процесс. Без них выполняется в разы дольше
Управляемые формы
Привожу проблему на упрощенном примере для понимания
Суть проблемы:
Начинаем транзакцию
Создаем документ РТУ (пока не записываем)
Фоновыми заданиями параллельно создаем 100 номенклатур
Заполняем РТУ этими номенклатурами
(В каждом фоновом задании созданные номенклатуры помещаются в буфер - регистр сведений. Оттуда мы берем при заполнении РТУ и тут же очищаем регистр сведений)
Записываем РТУ
Если РТУ записывается, то все ок.
Если РТУ не записывается, тогда выполняем отмену транзакций
Но номенклатуры остаются, т. к. они были созданы фоновыми заданиями.
(Регистр сведений Буфер, естественно, тоже остается заполненным, т. к. произошел * транзакций)
Как можно откатить эти действия тоже? Чтобы не создавались номенклатуры
Фоновые задания используются, чтобы распараллелить процесс. Без них выполняется в разы дольше
По теме из базы знаний
- Как работает 1С размером 13 ТБ в условиях непрерывной разработки
- Обработчик "После завершения транзакции" своими руками
- "Откат" данных без транзакций. Расширение для легкого возврата к "исходному" или выбранному состоянию после любых изменений данных
- Мастер-класс SonarQube. В омут с головой
- Конвейеры обработки сообщений
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(6)Перечитал правила использования транзакций. Про фоновые задания там, к сожалению, нет примеров.
Может не совсем правильно использовать фоновые задания в транзакции, но без них будет долго обрабатываться процесс.
Возможность отменять транзакцию в любом случае нужна.
Я написал упрощенный проблем для пониманию сути, реальный процесс намного сложнее чтобы обойтись без транзакций.
Может не совсем правильно использовать фоновые задания в транзакции, но без них будет долго обрабатываться процесс.
Возможность отменять транзакцию в любом случае нужна.
Я написал упрощенный проблем для пониманию сути, реальный процесс намного сложнее чтобы обойтись без транзакций.
(6)Опишу по подробнее. Номенклатуры в моем примере - это расходные ордера
Есть пул заказов клиента. Может быть от 10 до 500 документов.
По этим заказам нужна создать расходные ордера по определенному принципу. Их может быть меньше чем заказов, а может быть столько же.
Сначала нужно создать пересчеты товаров не все номенклатуры из заказов клиента, которых не хватает на складе.
Затем нужно создать эти расходные ордера. Вот туда код выполняется долго, если не использовать фоновые задания.
Затем нужно поместить все созданные расходные ордера в табличную часть самописного документа и записать самописный документ.
Затем нужно заполнить регистр со статусом этого документа.
Затем нужно очистить другой регистр с этим документом, чтобы он не обрабатывался второй раз.
Затем в случае необходимости нужно создать перемещения товаров.
Только потом зафиксировать транзакцию.
Если хотя бы что-то не запишется, то все это нужно вернуть.
Есть пул заказов клиента. Может быть от 10 до 500 документов.
По этим заказам нужна создать расходные ордера по определенному принципу. Их может быть меньше чем заказов, а может быть столько же.
Сначала нужно создать пересчеты товаров не все номенклатуры из заказов клиента, которых не хватает на складе.
Затем нужно создать эти расходные ордера. Вот туда код выполняется долго, если не использовать фоновые задания.
Затем нужно поместить все созданные расходные ордера в табличную часть самописного документа и записать самописный документ.
Затем нужно заполнить регистр со статусом этого документа.
Затем нужно очистить другой регистр с этим документом, чтобы он не обрабатывался второй раз.
Затем в случае необходимости нужно создать перемещения товаров.
Только потом зафиксировать транзакцию.
Если хотя бы что-то не запишется, то все это нужно вернуть.
(5)Ну просто можно же изменить подход и не завязываться на транзакции.
Документ заполняем номенклатурой с помощью ПолучитьСсылку(), пытаемся записать документ. Если все ок, передаем в фоновые гуиды и создаем номенклатуру через УстановитьСсылкуНового(). Если не ОК, то ничего и не создавали.
Документ заполняем номенклатурой с помощью ПолучитьСсылку(), пытаемся записать документ. Если все ок, передаем в фоновые гуиды и создаем номенклатуру через УстановитьСсылкуНового(). Если не ОК, то ничего и не создавали.
(7)Мне нравится твоя идея, но есть ряд трудностей.
Номенклатуры в моем примере - это расходные ордера
Я заранее не знаю, сколько будет расходных ордеров, чтобы записать документ сначала.
Вдруг часть ордеров создадутся, а часть нет. Хотелось бы возможность отмены этих документов тоже. И по том в ТЧ останется битая ссылка, следовательно ее надо удалить, опять записывать документ.
Номенклатуры в моем примере - это расходные ордера
Я заранее не знаю, сколько будет расходных ордеров, чтобы записать документ сначала.
Вдруг часть ордеров создадутся, а часть нет. Хотелось бы возможность отмены этих документов тоже. И по том в ТЧ останется битая ссылка, следовательно ее надо удалить, опять записывать документ.
(13)Функция создания РО стандартная (из БСП).
Туда передаешь склад, поставщика и массив заказов. Она возвращает массив или таблицу созданных расходных ордеров.
Скорре всего, массив из 1 значения, тогда можно подставить туда ГУИД. Но может же создадутся несколько ордеров. Я подумаю над этим
Туда передаешь склад, поставщика и массив заказов. Она возвращает массив или таблицу созданных расходных ордеров.
Скорре всего, массив из 1 значения, тогда можно подставить туда ГУИД. Но может же создадутся несколько ордеров. Я подумаю над этим
(14) переделывайте свою логику
1.вообще сделайте регламентное задание, которое как раз и работает в фоне
2.Начните транзакцию
2.соберите/создайте свои РО или что там еще
3.если создались исходные данные, создайте РТУ и проведите его
4.если успешно фиксируйте транзакцию, если не успешно отменяйте ее (при этом отменится и п.2)
все эти действия в рамках одного рег.задания
рег.задание работает по расписанию, его так-же можно запускать и по необходимости (интерактивно)
1.вообще сделайте регламентное задание, которое как раз и работает в фоне
2.Начните транзакцию
2.соберите/создайте свои РО или что там еще
3.если создались исходные данные, создайте РТУ и проведите его
4.если успешно фиксируйте транзакцию, если не успешно отменяйте ее (при этом отменится и п.2)
все эти действия в рамках одного рег.задания
рег.задание работает по расписанию, его так-же можно запускать и по необходимости (интерактивно)
(14) еще вариант обхода
если фоновое задание выполнилось и внутри его не отработала отмена транзакции
созданные там объекты зафиксированы в базе.
(как у нас было)
если у вас при обработке РТУ возникает необходимость отмены транзакции
то в этой ветке просто надо ЯВНО удалить все созданные объекты в фоновом задании
тем более что у вас есть их список в регистре РС
если фоновое задание выполнилось и внутри его не отработала отмена транзакции
созданные там объекты зафиксированы в базе.
(как у нас было)
если у вас при обработке РТУ возникает необходимость отмены транзакции
то в этой ветке просто надо ЯВНО удалить все созданные объекты в фоновом задании
тем более что у вас есть их список в регистре РС
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот