Есть 2 системные транзакции. Тр.№1 генерит некий объект\номер\документ. Тр№2 представляет этот объект немного "в профиль" и включает этот объект в сложную иерархию. Заказчик желает автоматическое включение в иерархию в конце тр№1. Очевидным представляется вариант вызова тр№2 "где-то в конце" тр№1.
Финал тр№1 выглядит так:

Финал тр№2:

Вопрос: получится ли врезать call transaction №2 в районе commit тр№1. Напрямую после в имплиците когда номер\объект уже есть в системе? Или где-то 'до' commitа включив вызов CT№2 в perform in update task? И не будет ли конфликтов COMMITов?
Спасибо.

если правильно понял, нужно во второй тр-ии использовать результаты первой,
следовательно вторую транзакцию нужно запустить тлько после того как данные
первой транзакции запишутся в таблицы бд, чтобы вторая видела с чем работать

варианты:

1) до commit work
1а)
создать ф/м обновления v2 (в свойствах: модуль обновления, радио 3 или 4 - запуск в очереди обновления v2 (2,4))
и вызвать его call function z_.. in update task,
внутри него вызвать call transaction или call function .. в другом процессе (destination NONE | in background task | ...),
смысл - отвязать процесс от задачи обновления, т.к. в ней запрещено трогать luw (операторы commit и rollback)
2а)
получить ключ обновления ,сохранить его
и после commit work ожидать завершения обновления с таким ключом,
запустить вторую транзакцию
3a)
создать ф/м с возможность удаленного запуска (RFC), вызвать call function z_.. in background task и
передать в него ключ обновления, дождаться завершения обновления любым способом ,
и вызвать вторую транзакцию,
ожидать нужно т.к. взависимости от вида процесса задача background обычно стартует ранее задачи update

2) после commit work
дождаться появления данных в бд через select или enqueue,
запустить вторую транзакцию

Спасибо! Вариант 2 как-то "добрее" выглядит. Осталось проверить остаются ли данные после первого commitа и вспомнить какая из областей памяти не затирается для использования export to, import from.

транзакция в v2 - не то, для чего придуман процесс v2. вместо этого лучше использовать tRFC, запланировав его перед первым коммитом.
ровным счетом так, например, работает связка MM-WM при автоматических проводках

call function ... in background task вам в помощь

Поддерживаю holocron: имхо tRFC более правильный подход, нежели v2-update

Можно написать свою программу с 2-мя последовательными вызовами транзакций 1 и 2, создать для нее свою транзакцию и вызывать ее вместо 1-й транзакции.
С tRFC могут быть проблемы при массовом вводе данных, т.к. вызов 2-й транзакции идет в отдельном диалоговом процессе.

а с двумя транзакциями вы будете принудительно ждать окончания первой или вызывать ее с синхронным обновлением. проще решить возможные проблемы с trfc

Так по другому и не получится выполнить эту задачу. Даже с tRFC

как раз trfc будет исполнено, если есть, ресурсы диалоговые, немедленно после v1. ничего ждать и не надо

А V1?
Еще раз: если есть возможность, то лучше использовать последовательный вызов транзакций.
Если нет, то можно использовать tRFC, но осторожно. Лет 10 назад из-за tRFC продуктив колом встал - закончились диалоговые процессы при обработке банковской выписки (F.110).
После этого пришлось переписывать обработку документов по банковской выписке в отдельную программу

tRFC не начнется, пока не выполниться V1. а если V1 упадет в дамп, то tRFC даже не начнется.
диалоговые процессы закончились? что ж, бывает, базису, вероятно, надо иногда тоже работать, установив предел доступный для RFC.

И чем это отличается от call transaction по сути?

Ну конечно, легче на базис кивать, если будет ошибка

Предлагаю закончить на этом

тем, что это стандартный механизм. ну ок, давайте закончим

Бывает очень забавно когда напихают сложную логику в v1/v2, а потом внезапно кончаются update-процессы и модули ждут своей очереди на обновление.
Вызывает массу интересных эмоций у пользователей (ошибок нет, но и документа нет... надо провести еще раз), админов (что за фигня у вас там работает??) и поддержки (которой прилетает от всех участников процесса плюс от руководства)

Всем спасибо за комментарии. Давно не мучил tRFC и даже подзабыл подробности почему при упоминании о нем начинает слегка мутить . Года 3 назад случилась по сути аналогичная ситуация описанная ув. Удавом.
Здесь же удалось после COMMITа в имплиците по рабоче-крестьянски вставить цикл с WAIT UP TO и SELECT. Тестовые 10 примеров отработали сразу, не добравшись до первого WAIT UP. Первые 100 реальных документов проскочили без ошибок.