Прошу совета в способе реализации

Salas

Попробовал: если "плодить" объёкты интерф. IF_OS_TRANSACTION и внутри вызывать

Т->Start( ).
Т1->Start( ).
* Здесь сделать откат
T1->END( ).
T->END( ).

то действительно, сделается UNDO последней версии.
Сейчас буду разбираться как зрегистрировать этот "Persistent Objects"

Code:

REPORT DEMO_TRANSACTION_SERVICE.

CLASS CL_OS_SYSTEM DEFINITION LOAD.

DATA TM TYPE REF TO IF_OS_TRANSACTION_MANAGER.
DATA: T  TYPE REF TO IF_OS_TRANSACTION,
     T1 TYPE REF TO IF_OS_TRANSACTION.

DATA WA_SPFLI TYPE SPFLI.

DATA: CONNECTION TYPE REF TO CL_SPFLI_PERSISTENT,
      AGENT      TYPE REF TO CA_SPFLI_PERSISTENT.

DATA: EXC TYPE REF TO CX_ROOT,
      TEXT TYPE STRING.

LOAD-OF-PROGRAM.

CL_OS_SYSTEM=>INIT_AND_SET_MODES( I_EXTERNAL_COMMIT = OSCON_FALSE
I_UPDATE_MODE = OSCON_DMODE_DEFAULT ).

start-OF-selection.

TM = CL_OS_SYSTEM=>GET_TRANSACTION_MANAGER( ).
T  = TM->CREATE_TRANSACTION( ).
T1 = TM->CREATE_TRANSACTION( ).


WA_SPFLI-CARRID     = 'LH'.
WA_SPFLI-CONNID     = '0401'.

AGENT = CA_SPFLI_PERSISTENT=>AGENT.

TRY.

  T->START( ).

  CONNECTION = AGENT->GET_PERSISTENT( I_CARRID = WA_SPFLI-CARRID
  I_CONNID = WA_SPFLI-CONNID ).
  WA_SPFLI-DEPTIME = CONNECTION->GET_DEPTIME( ).
  WA_SPFLI-ARRTIME = CONNECTION->GET_ARRTIME( ).
  WA_SPFLI-DEPTIME = WA_SPFLI-DEPTIME + 3600.
  WA_SPFLI-ARRTIME = WA_SPFLI-ARRTIME + 3600.

  CONNECTION->SET_DEPTIME( WA_SPFLI-DEPTIME ).
  CONNECTION->SET_ARRTIME( WA_SPFLI-ARRTIME ).

WA_SPFLI-CARRID     = 'LH'.
WA_SPFLI-CONNID     = '0400'.

  T1->START( ).
    CONNECTION = AGENT->GET_PERSISTENT( I_CARRID = WA_SPFLI-CARRID
      I_CONNID = WA_SPFLI-CONNID ).

    WA_SPFLI-DEPTIME = CONNECTION->GET_DEPTIME( ).
    WA_SPFLI-ARRTIME = CONNECTION->GET_ARRTIME( ).
    WA_SPFLI-DEPTIME = WA_SPFLI-DEPTIME + 3600.
    WA_SPFLI-ARRTIME = WA_SPFLI-ARRTIME + 3600.

    CONNECTION->SET_DEPTIME( WA_SPFLI-DEPTIME ).
    CONNECTION->SET_ARRTIME( WA_SPFLI-ARRTIME ).
    T1 = T1->UNDO_AND_CHAIN( ).
  T1->END( ).

  T->END( ).

CATCH CX_ROOT INTO EXC.

  TEXT = EXC->GET_TEXT( ).
  MESSAGE TEXT TYPE 'I'.

ENDTRY.

111

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

Сейчас буду разбираться как зрегистрировать этот "Persistent Objects"

SE24->Создать->Постоянный класс.
Только, IMHO, PERSISTENT OBJECT's - это для трудоголиков.

sibrin

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

Только, IMHO, PERSISTENT OBJECT's - это для трудоголиков.

Согласен. А ещё для больших проектов и сложных задач, когда много функциональных слоёв. Эти start и end вкладываются друг в друга как скобки в математическом выражении и позволяют создавать сложные транзакции. При этом верхний слой не заканчивается COMMIT'ом, поэтому можно без проблем добавить ещё один и т.д.

2 Salas: вот только есть подозрение, что все эти вкусности работают при условии, что в Persistent Object делаются безошибочные updat'ы таблиц. Прикладные проверки туда не вставишь и ошибки не обработаешь, а значит BAPI не вызовешь.

Salas

Как раз сейчас пытаюсь переопределить GET_PERSISTENT.
Возможно не получится, но не хочу уж начатое бросать :wink:

Потом детям смогу сказать, что хотя б потытался :lol:

Спасибо за помощь!

111

sibrin написал:

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

Только, IMHO, PERSISTENT OBJECT's - это для трудоголиков.

Согласен. А ещё для больших проектов и сложных задач, когда много функциональных слоёв. Эти start и end вкладываются друг в друга как скобки в математическом выражении и позволяют создавать сложные транзакции. При этом верхний слой не заканчивается COMMIT'ом, поэтому можно без проблем добавить ещё один и т.д.

Идея неплохая, но реализация...
Впрочем, как и везде в SAP'е - идеи гениальные, а реализация хромает.
Хотя возможно, просто сыровато еще - доработают.

ЗЫ. Как раз на текущем проекте намучался с этими персистентами, реализованными другими разработчиками.
Не дай Бог, нужно изменить тип какого-нибудь поля... Гемора на полдня. Штатно методы не перегенеряются корректно. Нужно все грохать, вместе с "друзьями", и создавать заново.

Пономарев Артем

Что-то мне не нравятся такие механизмы... Атомарность транзакции еще никто не отменял. А здесь теряется смысл "от одного соглассованого состояния в другое". Получаются промежуточные.

Если говорить формально (т.е. использовать ACID), то:
Если есть одна внешняя транзакция, внутри которой запускается еще одна внутренняя, то ACID durability требует, чтобы изменения, комитнутые внутренним commit'ом, были навсегда. Но тогда неясно, что должен делать случившийся позже внешний rollback: он ни оставить внутренние изменения не может (иначе это не rollback), ни откатить (иначе нарушается внутреннее durability).

Вообщем решая подобную задачу я бы послал лесом все эти PERSISTENT OBJECT's и сделал обертки, использующие глобальную память для накапливания всех изменений. И один общий POST в итоге.
Как пример в SAP стандарте: смотрите пакет HANDLING_UNITS.

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

Прошу совета в способе реализации

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