Добрый день!

Господа профессионалы, помогите любителю

Есть некая саповская программа, которая делает некоторые изменения в БД. COMMIT она делает относительно нечасто.

Посреди нее находится вызов метода класса (не BADI), который можно написать самостоятельно. Т.е. класс написан и метод написан мной. В этом методе я делаю запись в собственную Z-таблицу и мне необходимо закоммитить изменения как можно быстрее. В эту таблицу пишет еще N программ и коммитить измененния в ней надо как можно быстрее. И желательно - синхронно, а не в update task. Беда в том, что если я напишу в своем коде COMMIT WORK, то одновременно зафиксирую все изменения, сделанные вышестоящей саповской программой. А это очень нежелательно.

Вообщем мне нужно что-то вроде автономных транзакций ораклового PL/SQL.

Единственная моя мысль - делать свои изменения в отдельном RFC ФМ, вызывая его с параметром DESTINATION 'NONE'. Только я не уверен, что такой ФМ будет выполняться в отдельном LUW.

Подскажите, как вы решаете подобные проблемы?

С уважением,
Евгений

Кажется на форуме подобное предлагалось. Тогда повторюсь.
Заверните свои апдейт-команды в репорт, махните в него нужные данные из своего класса (можно через память, к примеру) и в нем уже коммит сделайте.

Чисто из любопытства - а что будет, если данные в Z таблице "закомиттятся", а потом основные данные - нет? Как будете разруливать?

если невозможно договориться и решено ломать идеологию sap luw

+1 John Doe
если не сработает destination 'NONE', то submit .. in update task.

вызвать commit/rollback внутри update task причем стандартного - это как дернуть аварийный стоп-кран,
управление luw-ом обычно всегда снаружи,
можно разве что вызвать db_commit, по уважительной причине

Ну это мне и в этом случае надо сделать запись в Z-таблице. Такая вот потребность. Долго рассказывать, да и мало кому будет интересно

Ну LUW я не ломаю. Просто следы в Z-таблице нужно оставлять в любом случае, даже если ROLLBACK у саповской программы пройдет (что очень редко и экстраординарно). Другое дело, что саповская прога может COMMIT сделать через минуту, а Z-таблицу надо освобождать быстро.

Update task не нравится своей асинхронностью. При большой очереди запись может случиться еще позже чем сама программа закоммитится.

/me пошел проверять DESTINATION 'NONE" припарку