BAPI_TRANSACTION_COMMIT и SQL

trop

иногда на commit work вешаются подпрограммы (perform ... on commit),
например в сбытовом заказе иногда так обрабатывается протокол сообщений (nast),
такие подпрограммы вызываются сразу в commit work и используют
актуальный на момент вызова сегмент данных программы,
commit work запускает задачу update, поднимает некоторые системные события,
и как-то обрабатывает блокировки (в задаче update в конце тоже вызывается commit work).
если запускать программу в цикле и в конце будет единственный commit, то
подпрограммы perform .. on commit запустятся только для последней итерации,
т.к. в памяти программы находится последний обработанный документ.
функции вызываемые в задаче update скорее всего отработают, т.к.
при вызове они ставятся в очередь задачи update (vbmod) с врем. сохранением
параметров вызова в кластере б/д, т.е. порядок вызова не нарушится

QValD

ArmAnn написал:

QValD написал(а):

Сделал, как описано выше.
В цикле BAPI на сторно документов -> ФМник на удаление записей из z-таблиц IN UPDATE TASK -> следом BAPI_TRANSACTION_COMMIT (WAIT = 'X').
Бывают случаи (пока не понял от чего зависит), что данные из z-таблиц удаляются, но бапишки не коммитятся. Как исключить эту ситуацию?
В sm13 всё чисто.

А вы анализируете как отработала бапишка на сторно? Т.е. в случае ошибки вызываете BAPI_TRANSACTION_ROLLBACK ?

Да, конечно. Сообщения типа A,E,W отлавливаются.

trop

rollback work сбрасывает sap luw и соотв. очередь update задачи,
по хорошему нельзя вешать один commit на кучу вызовов bapi, перемежая их rollback-ами

QValD

trop написал(а):

rollback work сбрасывает sap luw и соотв. очередь update задачи,
по хорошему нельзя вешать один commit на кучу вызовов bapi, перемежая их rollback-ами

Rollback так же, как и коммит стоит после цикла.

trop

отладьте задачу обновления (в отладке сохр. в собств. параметрах две первые галочки)
и смотрите на содержимое (rsm13000)vbmod_tabl[], если там ничего не потерялось,
то тогда надо проверить в стандарте какие подпрограммы вызываются on commit,
если там что-то есть, то вы рискуете получить неконсистентность данных/событий
даже если документы создадутся

ArmAnn

QValD написал(а):

trop написал(а):

rollback work сбрасывает sap luw и соотв. очередь update задачи,
по хорошему нельзя вешать один commit на кучу вызовов bapi, перемежая их rollback-ами

Rollback так же, как и коммит стоит после цикла.

Покажите код

QValD

ArmAnn написал:

QValD написал(а):

Покажите код

Code:

  
  *** ....до этого циклы с бапи BAPI_ACC_ACT_POSTINGS_REVERSE, lt_return_sum - таблица со всеми сообщениями из бапи.
  DATA: l_subrc TYPE sy-subrc.
  READ TABLE lt_return_sum WITH KEY type = 'E' TRANSPORTING NO FIELDS. l_subrc = sy-subrc.
  READ TABLE lt_return_sum WITH KEY type = 'A' TRANSPORTING NO FIELDS. l_subrc = l_subrc + sy-subrc.

  IF l_subrc < 8.
    CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
    MESSAGE 'Обнаружены ошибки во время обработки документов. Проверьте журнал сообщений.' TYPE 'E'.
  ELSE.
    READ TABLE lt_return_sum WITH KEY type = 'W' TRANSPORTING NO FIELDS.
    IF sy-subrc = 0.
      DATA: l_answer TYPE c.
      PERFORM continue_or_show_dialog USING l_answer. IF l_answer <> '1'. EXIT. ENDIF.
    ENDIF.
  CALL FUNCTION 'ZFF_UPD' IN UPDATE TASK
      EXPORTING
        i_operation       = 'D'
      tables
        table1            = gt_zt1_del
        table2            = gt_zt2_del.
    CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' EXPORTING WAIT = 'X'.
    CLEAR: gt_zt1_del, gt_zt2_del.
  ENDIF.

ArmAnn

QValD, по этому куску кода все вроде ок. Возможности дистанционной диагностики исчерпаны

Мои предположения:
1. В lt_return_sum у вас не все сообщения от бапишек, а например только от последней
2. BAPI_ACC_ACT_POSTINGS_REVERSE в какой то момент отрабатывает некорректно, но сообщения об ошибке не выдает

trop

ещё можно поставить break на rollback и commit, всякое бывает.. ниндзя-код в других разработках.
и перед вызовами bapi попробовать set update task local,
но всё таки imho лучше запускать по отдельности и при ошибке сторнировать
красным ,в общем консультант пусть ломает голову )

QValD

ArmAnn написал:

QValD, по этому куску кода все вроде ок. Возможности дистанционной диагностики исчерпаны

Мои предположения:
1. В lt_return_sum у вас не все сообщения от бапишек, а например только от последней
2. BAPI_ACC_ACT_POSTINGS_REVERSE в какой то момент отрабатывает некорректно, но сообщения об ошибке не выдает

1. Не, в ней точно от всех.
2. Скорее всего.

trop написал(а):

ещё можно поставить break на rollback и commit, всякое бывает.. ниндзя-код в других разработках.
и перед вызовами bapi попробовать set update task local,
но всё таки imho лучше запускать по отдельности и при ошибке сторнировать
красным ,в общем консультант пусть ломает голову )

Проблема в том, что повторить те ситуации, мягко говоря, не всегда получается

Пока проблема решена (уж лучше так, чем никак) с помощью SET UPDATE TASK LOCAL ->Коммит бапишек-> селект с проверкой сторнирован ли документ-> удаление документа.

ArmAnn

QValD написал(а):

Проблема в том, что повторить те ситуации, мягко говоря, не всегда получается

Пока проблема решена (уж лучше так, чем никак) с помощью SET UPDATE TASK LOCAL ->Коммит бапишек-> селект с проверкой сторнирован ли документ-> удаление документа.

Для более точной диагностики можно прикрутить сохранение логов в SLG1 (если бапишка не выдала сообщений - это обязательно отметить отдельной строчкой). Если ситуация повторится - то по крайней мере хоть будет видно как отработала бапишка

Правила форума

BAPI_TRANSACTION_COMMIT и SQL

Кто сейчас на конференции