Друзья, подскажите, как правильно завернуть вызов метода сгенерированного в SPROXY класса, для внешней асинхронной передачи данных в момент сохранения объекта.
Т.е. у нас есть задача в каждый раз при сохранении объекта в ERP, передавать его данные через PI в другую систему. Сначала был вариант завернуть этот метод в tRFC функцию, которая отработает после коммита, т.е. все проверки прошли и объект сохраняется. Но тут нет гарантий, что апдейт по каким-то причинам не прервется, в передача всё равно будет выполнена, что не правильно.
Тогда родился другой вариант, завернуть вызов в aRFC, который вызвать в апдейт функции, поставленной в конец апдейта. Т.е. передача пойдет только если и апдейт успешно выполнен. Вроде похоже на правду, но как то мудрено получается.
Как такое правильно сделать, чтобы велосипед не изобретать?
Спасибо.

последний вариант кажется мудреным, но он проще всего

С aRFC в апдейте наврал. Не пойдет так из-за ДБ коммита, возникающего при вызове aRFC.

См. по поиску IN BACKGROUND TASK.
Гарантии есть. Есть серьезная проблема - IN BACKGROUND TASK выполняется в другом режиме, т.е. при массовой обработке данных (типа LSMW, пакетный ввод, BAPI) система может стать колом из-за нехватки диалоговых процессов.
Лучший способ - фоновое задание, запускаемое с небольшим интервалом, которое выбирает свежесохраненные документы.

Да, спасибо за замечание. Действительно отрабатывает только после удачно выполненного V1.


Сделал следующую тест программку:
DO 500 TIMES.
CALL FUNCTION 'Z_BACKGROUND_TASK_TEST' IN BACKGROUND TASK AS SEPARATE UNIT. "Внутри ФМа WAIT UP TO 10 SECONDS.
ENDDO.
COMMIT WORK.
Наблюдаю, как в SM58 выстроилась очередь на выполнение, но в каждый момент выполняется не более чем 7 записей (похоже на настройку). Система не останавливается, очередь потихоньку рассасывается.

Кстати, тут другой вопрос, сама программа виснет на COMMIT WORK. Вот это как объяснить??? с учетом асинхронного выполнения.

Играюсь дальше.
Если немного поправить код:

CALL FUNCTION 'Z_UPDATE_TASK_V1' IN UPDATE TASK. "Внутри пусто
DO 500 TIMES.
CALL FUNCTION 'Z_BACKGROUND_TASK_TEST' IN BACKGROUND TASK AS SEPARATE UNIT. "Внутри ФМа WAIT UP TO 10 SECONDS.
ENDDO.
COMMIT WORK.

В SM58 все процессы запускаются на выполнение одновременно, программа завершается мгновенно, т.е. стартует асинхронное выполнение. И если наполнить бэкграунд ФМы процессами требующими ресурсов, система действительно начинает подвисать.
Тот же эффект одновременного выполнения будет, если убрать AS SEPARATE UNIT.

[s]насчёт гарантий, что background task выполнится только после v1 можно поспорить,[/s]
если commit work тормозит убедитесь, что перед ним нет вызова set update task local

Именно, что добавление процесса обновления, переводит и BACKGROUND TASK AS SEPARATE UNIT в асинхронной режим. В приведенной изначально программе нет вообще другого кода, а коммит висит пока не выполнится последний BACKGROUND TASK AS SEPARATE UNIT т.е. синхронный режим получается.

Гарантий нет. Поэтому метод вызова ФМ IN BACKGROUN TASK даже внутри ФМ IN UPDATE TASK никакой последовательности не гарантирует.
Обычно внутри ФМ IN BACKGROUN TASK устраивают цикл с задержками в 1с с попыткой прочитать из БД номер сохраняемого докмуента. Вот когда номер прочитали - запускаем процедуру выгрузки во внешнюю систему. Если, скажем, за 10 сек ничего так и не появилось - считаем, что документ не сохранился. Это работает довольно устойчиво, но не в 100% случаев. Пример - перенесли запрос с расширением mseg, при сохранении MM заказа процедура UPDATE TASK может минуту работать, пока все перекомпилится там.

100% гарантия - это при сохранении документа внутри UPDATE TASK писать его номер в z-табличку "очередь отправки" и потом разгребать очередь периодическим фоновым заданием.

достаточно правильно объявить update функцию, чтобы она ушла в очередь V2,
и вызвать её перед самым commit work, чтобы она была в конце очереди,
таким образом можно будет утверждать, что неявный commit бд сессии при
вызове rfc функции [s]ничего уже не испортит.[/s] максимум испортит только выполнение очереди V2,
хотя такой исход невероятен

а если в rfc функции вставить ожидание, то соваться в update задачу нет надобности

Посмотрите справку на COMMIT WORK - там описана последовательность отработки v1, v2 и IN BACKGROUND TASK.
IN BACKGROUND TASK стартует после успешного завершения всех модулей v1

Прочитал, действительно написано. Тем не менее, точно помню, что проблемы с очередностью на практике были. Может БД не успевала комитить данные, может еще что-то, не знаю. Могу и ошибаться, конечно..

Почему не рассматриваете вариант повесить обработчик отправки данных на событие, которое генерится системой к документу изменений?
Гарантированный V2-Update документа изменений после гарантированного окончания обновления основного объекта.

Да, спасибо, очень любопытная идея. Но как, например, быть в случае, если меняют только длинный текст объекта и документа изменений не будет(?).

Я пока остановился на прямом вызове прокси, завернутом либо в V2, либо в V1 в перформ он коммит, т.е. в самом конце обновления. Само прокси асинхронное и не должно помешать процессу обновления объекта. Гарантия, что объект записан, тоже очень большая. Новых процессов при этом не будет и массовое последовательное обновление объектов не повесит систему.