Доброго дня,

Есть обработчик входящего IDOC-a, который вносит изменения в delivery (LIKP-ZFIELD, скажем так) и отправляет исходящий IDOC, который отсылает эти обновленные данные (LIKP-ZFIELD).

При этом, для изменения поставки используется BAPI_CHANGE_OUTBOUND_DELIVERY, а он в свою очередь вызывает LIEFERUNG_WRITE_DOCUMENT, который объявлен как модуль отложенного старта V2 (не V1!!). То есть, если сразу после обновления LIKP вызвать отправку IDOC-a, читающего из базы данных LIKP-ZFIELD, то нет гарантии что на момент выполнения SELECT это поле будет обновлено в ДБ.

В голове вертятся несколько путей решения проблемы, и все они несколько корявы:
1) сделать отправку IDOC-a тоже внутри UPDATE TASK. Минус в том, что обработчик изначального (входящего) айдока уже не получит номер отправленного айдока и не запишет его в лог. Можно попробовать из обработчика исходящего айдока добавлять статусы для изначального айдока через EDI_DOCUMENT_OPEN_FOR_PROCESS, но терзают смутные сомнения что возникнет конфликт - обработчик входящего айдока еще будет держать открытым документ, а статус для того же документа попробует записать обработчик исходящего.

2) плюнуть на правила хорошего тона и поменять BAPI на UPDATE likp SET zfield = blabla WHERE vbeln = p_vbeln. Это с гарантией будет означать, что обработчик выходящего айдока получит обновленные данные, но до сих пор я UPDATE родных саповских таблиц считал табу и признаком хинди-кода.

3) Передавать значение поля LIKP-ZFIELD в UPDATE TASK через дополнительное поле в структуре NAST, чтобы исключить селект как таковой. Но это значит, что придется добавлять ZFIELD в структуру NAST, а она и так уже замусорена.

Что посоветует уважаемая аудитория? Есть ли какой-то прогрессивный способ?

Обрабатывать входящие IDOC по расписанию, отправлять IDOC после обработки всех входящих IDOC.

Залезть в спул и смотреть, выполнялся ли модуль в последнее время или нет. Если выполнялся - можно отправлять айдок.

Ключевое слово здесь - после. Отправлять IDOC после того, как убедились, что изменения действительно сохранены в БД, а не после того, как вызвали БАПИ и сделали коммит.
Я видимо как-то неудачно объяснил, что ли.
В коде это выглядит примерно так:



То есть, нет гарантии что к тому моменту как RV_MESSAGE_UPDATE (он добавляет OUTPUT TYPE задекларированный как EDI и собственно через это и генерируется исходящий айдок) начнет работу, изменения будут уже в ДБ (напоминаю, ФМ с отложенным стартом V2 не сработают сразу после ждущего коммита как это делают V1). На практике это все происходит все равно очень быстро, но чисто теоретический шанс остается, что низкоприоритный V2 протормозит и RV_MESSAGE_UPDATE уйдет раньше. Случай из жизни - чинил программу, в которой индусы делали Post Goods Issue и сразу же отправляли IDOC. IDOC смотрел значение LIKP-WADAT_IST, не находил его, считал что PGI не сделано и отменял отправку.

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

А все потому, что 'BAPI_CHANGE_OUTBOUND_DELIVERY' вызывает для записи в ДБ ФМ LIEFERUNG_WRITE_DOCUMENT, которую сумрачный тевтонский гений зачем-то оформил как V2 a не V1.

Все это можно решить, если заменить CALL FUNCTION 'BAPI_CHANGE_OUTBOUND_DELIVERY' на тупо UPDATE likp SET zfield = my_value WHERE vbeln = my_vbeln. Какие риски можно поиметь в таком случае, кроме утраты репутации?

Как вариант, можно поставить цикл с таймером - проверять через каждые 5 секунд, не записались ли наконец заветное значение в LIKP-ZFIELD, но это выглядит еще ужаснее чем UPDATE LIKP

п.с. дальше-больше: обнаружил стандартную(!) САПовскую функцию UPDATE_XBLNR_IN_LIKP, которая по сути, обертка для вызова UPDATE LIKP SET XBLNR

Я извиняюсь, а в чем сакральный смысл этого ZFIELD и всех этих IDoc? У меня смутное подозрение, что возможно тут вообще можно как-то по-другому и проще сделать.

Если это ваш собственный ZFIELD, у которого нет никаких зависимостей (например, просто нужно для отчетности), то, честно говоря, ничего особо плохого в UPDATE именно в этом случае я не вижу. Если это поле ничего не делает, то IMHO без разницы как вы его обновите. Не забудьте lock, конечно.

LIEFERUNG_WRITE_DOCUMENT пишет документы изменений, поэтому он в v2 (2),
Z-поле запишется в вызове RV_DELIVERIES_SAVE в очереди v1 (3).
если правильно понял, исходящий idoc вызывается вручную (не через указатели изменений),
просто дождитесь завершения sap luw и отправляйте idoc,
или отправляйте idoc в background task в том же sap luw.
если отправляется через указатели изменений, то надо убедиться, что
на эл. данных z-поля стоит галка изменений, и проверить пишется ли поле в док.изменений

Если входящий Idoc это DESADV, то я бы попытался использовать события БО IDOCDESADV (тр. SWO1), к примеру, IDOC.inputSuccess "IDoc успешно проведен". По этому событию постарался бы запустить мини поток WF, куда бы поместил это обработчик в виде фоновой задачи.