Перед сохранением документа материала в badi регистрируем свою подпрограмму: PERFORM z_form1 ON COMMIT (без аргументов).
В этой подпрограмме стартуем параллельный процесс:ну и ждём пока он завершится (по факту от 1 до 10 секунд).

В 99% случаев всё работает, как и задумано.
Но примерно 1 раз из 100 процесс обновления не запускается: ни дампов, ни ошибок в sm13. Соответственно, никаких документов в системе не формируется. При этом ход выполнения программы не меняется (расставлено много контрольных точек) и параллельный процесс выполняется не дольше, чем обычно.

Найдены вторичные признаки этого глюка: если прочитать vbkey до и после цикла ожиданияокончания асинхронного вызова, то два значения не совпадают тогда и только тогда, когда происходит глюк. Ну, понятное дело, всё, что зарегистрировано in update уходит в небытие. (Вообще говоря, vbkey вещь туманная и может в определённых случаях менять свои значения, например, когда ещё не зарегистрировано ни одного update модуля.) Значения vbkey читаются с помощью ф.м. TH_GET_VBKEY.

Вопрос: не использовал ли кто-нибудь aRFC в perfrom on commit и не наблюдались ли подобные глюки?

Извиняюсь, но ответа я не знаю. Вопрос: мог ли 99 вызов модуля закончится как-то криво и не почистить за собой? (задаю потому что абсолютно не знаю как выполняется асинхронный RFC).

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

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

А почему не подходит вызов из BAdI CALL FUNCTION ... IN BACKGROUND TASK?
Это как раз решение проблемы обновления данных только после COMMIT.
Кстати, неплохо бы в application log писать контрольную информацию.

Потому что идёт обращение на сервер презентаций. В этом как раз вся суть.

Контрольных точек очень много. Логи пишутся параллельно и в БД (прямые insert'ы в z-log-таблицы, и in update task, и application log), и в файлы.

Кстати, application log — самое неудобное место для таких вещей. Потому что записей очень много и найти там что-то нереально. Всё равно туда пишется, конечно, кое-что, чтобы пользователь по окончании транзакции увидел номера созданных документов или причины ошибок. Вот z-таблица, где вся нужная информация по полочкам разложена и можно хитрые select'ы делать, чтобы проанализировать результаты, — то, что надо. Но, чтобы иметь независимую от многочисленных неявных DB commit'ов и rollback'ов информацию, полезно писать кое-что в файл.

мда..
Тогда информации маловато. Что же в этом ФМ делается такое?

ЗЫ: кстати, ...in background task запускается в диалоговом режиме.

А не мог ли файл на клиенте не закрыться? (Уууу бредовое предположение)...

Опять в десятку. В асинхронном ФМ создаётся OLE-объект на фронтенде, который качает информацию в БД локальной сети юзера.

Вариантов сделать по-другому много — это не вопрос. Вопрос в том, неужели тёмные дела, творящиеся в асинхронном диалоговом процессе, могут повлиять на SAP LUW в родительском процессе? Не может же WAIT сам по себе порушить SAP LUW.

Ещё немного приоткрою карты. Сначала асинхронный ФМ вызывался не on commit, а в середине SAP LUW между 7-м и 8-м update-модулем, то первые семь тоже корова языком слизывала. Специально делали в V2-модуле дамп, чтобы в sm13 увидеть следующую картину:

Можно предположить, что VBKEY поменялся, а счётчик позиций VBMODCNT не сбросился. Подробные z-логи тогда ещё не велись, поэтому достоверно поведение vbkey не зафиксировано.


В диалоговом процессе, но в отвязанном от GUI режиме.[/img]

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

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

Но, есть ощущение, что если у пользователя ЭТО произошло, то ОНО может длиться некоторое время. Т.е. если юзер успевает быстро сбацать ещё один документ, то глюк может повториться. Впрочем, это документально не подтверждено.

Как смог понять из описания, успешность выполнения задачи зависит от настроек доступа к локальной базе данных на рабочей станции пользователя (ODBC, OleDB, ...). И поскольку сеть очень разветвленная, есть вероятность, что у какого-то пользователя неправильныяе настройки доступа к DB (или прав недостаточно). Видимо это можно отловить логированием успешности создания OLE объекта.
Так же может и саповскими правами конкретного пользователся где-то ошибки. Нет ли в в коде авторизационных объектов?

Если так, то было бы здорово. Тогда бы была консистентность: документа нет ни там, ни здесь.

А в реалии OLE отрабатывает без ошибок, что документально установлено кодом возврата каждого OLE-метода и фактом попадания данных в локальную БД. Повтрюсь: контрольные точки с записью в z-логи маньячно расставлены повсюду. Прямые insert'ы в z-логи попадают, т.е. DB rollback'ов нет. А большой ROLLBACK в perfrom on commit запрещён по определению.

PS. Локальная БД не на рабочей станции, а в локальной сети юзера, что в общем-то сути не меняет.

Вообще есть такое ощущение, что проявление ошибки привязано к времени выполнения параллельной задачи. Также есть ощущение, что запуск UPDATE модулей с помощью COMMIT WORK и выполнение параллельной задачи тоже имеют связь. Т.е. если выполнение параллельной задачи уложилось в какой-то срок, то запуск происходит, если нет - то нет. Глубже копать сейчас времени нет, однако проблема очень интересная.

Мда, а факт выставления zg_job_finished всегда успешно фиксируется в родителе?

Нет, глюк может быть при задержке в 2 сек., а нормальное обновление при задержке в 8 сек. Ну и, соответственно, наоборот.