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

Salas

Доброе утро!
Предстоит реализовать следующую программу:
пользователь вводит позицию документа и на каждый ввод выполняется как минимум одна Бапишка(обязательное требование). Хочется иметь возможность откатить назад фиксированное ко-во шагов(скажем, по нажатию кнопки делать ROLLBACK последнего шага).

Посоветуйте, как подобное реализовать или, если знаете, какой-нибудь пример отчёта.
Предполагаю, что можно на каждый ввод запускать новый (асинх.)процесс и в нем в обновлении проводить изменения. Конечно, новых TASK-ов плодить много не буду, но как откатить какой-нибудь конкретный :?:

Если робастно это не реализуется, то другие варианты имеются.
Скажем, при нажатии UNDO буду делать Бапи с противоположной операцией (изменение - изменение на старое значение; удаление - вставить предыдущую позицию; вставка - удаление) - комбинаций не так много, но хочется сделать поинтереснее.

Заранее спасибо!

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

Вообще несколько бредовое требование.
Но если пользователям нужна такая иллюзия - я бы прогонял все BAPI'шки в тестовом режиме (если такого нет, то без коммита и с роллбэком).
И уже по выходу из транзакции - весь список в обычном и с коммитами.

Salas

Насчёт бредовости отчасти согласен.
Но задачу поставили с самого верха :lol:

, да и смысл могу прояснить.
Пользователи вбивают позиции сбытового заказа - только материал и кол-во, которые внутри уже бьётся по секторам, СКК и проч., попадая в разные "реальные" заказы.
Суть в том, что на ходу происходит подбор партий и расчёт цен, при этом оператор, видя что запасов не хватает или превышен лимит - делает UNDO нескольких позиций.
При этом на каждой вбитой позиции запускается BAPI*ORDER*CHANGE и BAPI*ORDER*SIMULATE и их надо откатить :cry:

Вообщем, пока делаю оболочку(т.е. приближаюсь к стене) и лбом пока не ударился

111

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

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

Сань, теоретически это возможно, и по путям реализации мыслишь верно:
=============
If a particular application requires you to write a complex transaction, it can often be useful to arrange logical processes within the SAP transaction into a sequence of individual SAP LUWs. You can structure SAP transactions as follows:

· With one or more SAP LUWs.

Transactions in this form consist entirely of processing blocks (dialog modues, event blocks, function module calls, and subroutines). You should be careful to ensure that external subroutines or function modules do not lead to COMMIT WORK or ROLLBACK WORK statements accidentally being executed.

· By inserting an SAP LUW

The ABAP statements CALL TRANSACTION (start a new transaction), SUBMIT (start an executable program), and CALL FUNCTION ... DESTINATION (call a function module using RFC) open a new SAP LUW. When you call a program, it always opens its own SAP lUW. However, it does not end the LUW of the SAP transaction that called it. This means that a COMMIT WORK or ROLLBACK WORK statement only applies to the SAP LUW of the called program. When the new LUW is complete, the system carries on processing the first SAP LUW.

· By running two SAP LUWs in parallel

The CALL FUNCTION ... STARTING NEW TASKstatement calls a function module asynchronously in a new session. Unlike normal function module calls, the calling transaction carries on with its own processing as soon as the function module has started, and does not wait for it to finish processing. The function call is asynchronous. The called function module can now call its own screens and interact with the user.
=====================

Только, ИМХО, отговаривать нужно юзеров от таких требований. Иначе им понравится - тогда тебе во всех разработках придется так извращаться

.

Salas

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

111

Исходя из задачи, которую ты описал, тебе, похоже после ввода каждой позиции придется делать COMMIT WORK по этой позиции. Иначе остатки для последующих позиций будут (скорее всего) считаться неправильно. А если уж закомметил - то откатить точно не удастся .
Поэтому, боюсь, вряд ли чего получится с этими извратами .

Salas

С остатками как раз нормально работает.

В 2-х потоках запустил - легли в разные партии(хотя документов в базе нет). Комитить нельзя 100 пудово, т.к. документы могут и создаваться в процессе ввода :cry:

Сейчас хочется теоретически узнать о возможности частичного отката.
А потом уже выбирать из зол, что хуже :wink:

111

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

С остатками как раз нормально работает.

Я про остатки в общем смысле сказал.
Остатки, стоимости, лимиты, обороты и сальдо каких-нибудь счетов, etc...
Какие-нибудь проверки могут пройти криво.

Tetty

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

Насчёт бредовости отчасти согласен.
Но задачу поставили с самого верха :lol:

, да и смысл могу прояснить.
Пользователи вбивают позиции сбытового заказа - только материал и кол-во, которые внутри уже бьётся по секторам, СКК и проч., попадая в разные "реальные" заказы.
Суть в том, что на ходу происходит подбор партий и расчёт цен, при этом оператор, видя что запасов не хватает или превышен лимит - делает UNDO нескольких позиций.
При этом на каждой вбитой позиции запускается BAPI*ORDER*CHANGE и BAPI*ORDER*SIMULATE и их надо откатить :cry:

Вообщем, пока делаю оболочку(т.е. приближаюсь к стене) и лбом пока не ударился

Давайте упрощать! :wink:

Что будет, если вбивать заказы будут одновременно ДВА (или более) пользователя? Каким образом они будут, видя, что запасов не хватает, отклонять и потом опять набирать? Может быть один пользователь будет просто ждать, пока у другого сдадут нервы и тот отменит заказы, а первый сможет их подцепить? Может быть они перебегают друг от друга, хлопая по плечу и договариваясь о заказах? Подумайте! И попробуйте описать этот процесс по шагам!

Или можно точно разделить сферу ответственности пользователей по какой-нибудь аналитике? Может быть пользователь будет вообще ОДИН?

Моё предложение (idea redesign) следующее:
1) Когда пользователь начинает работать с этой программой, то происходит БЛОКИРОВКА в нужных разрезах, чтобы никто не смог одновременно ничего провести.
2) Считываются текущие остатки.
3) В обычном ALV пользователь играется в рамках остатков (без какого-либо сохранения).
4) Когда нажимает кнопку "Спасти", то для введённых и выбранных записей осуществляется проводка без отмены.

Вам не нужно будет морочить голову по поводу отмены, а руководство увидит тот интерфейс, который хочет.

Чем не устраивает подобное решение?

sibrin

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

Сейчас хочется теоретически узнать о возможности частичного отката.

Вот, например, теоретические способы отката:
1) красивый объектно-ориентированный: Transaction Service;

2) корявый таблично-ориентированный: считать vbkey и зачистить таблицу VBMOD (в случае локального обновления — внутренню таблицу %_vb_calls из глобальной памяти главной сессии).

3) сделать третий уровень абстракции, SUPER LUW: таблицы zvbmod и zvbdata, регистрировать в них вызовы BAPI-шек, для отката удалять несколько последних, а потом вызывать по-очереди. При этом updta-модули в рамках SAP LUW зарегистрируются в vbmod и vbdata (второй уровень), а после commit work откроется DB LUW (первый уровень).

Salas

2 Tetty
Вообще-то не в тему!
Попробуйте в Va01 создавать с 2-х сессий заказы на один и тот же материал с одного завода и склада. Если у вас в позиции заказа настроена проверка доступности, то второй вызов заказа либо ругнется, либо подберётся объём из другой партии(если всю израсходовали в первом заказе). Там кстати блокировка сама создается(в аргументе есть даже количство!) Поэтому и я ДОЛЖЕН вызывать бапи после каждого изменения, чтобы поменять текущий "резерв" :!:

Просто "колбасить позиции" не в тему! Заказ может состоять из сотни позиций - на одной ошибка (логики сапа) и пиши пропало!

Salas

2 sibrin
Спасибо! Очень круто! Буду разбираться!
Вех живи!

Tetty

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

Вообще-то не в тему!

Возможно, что мы говорим о разных вещах :oops:

. Вы создаёте оболочку, которая запускает VA01, где (каким образом?) запускается пара BAPI для каждой позиции, после чего пользователь хочет откатить некоторые из них стандартными способами через оболочку, так?

sibrin

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

Буду разбираться!

Вот только я боюсь, что все способы чисто теоретические:
1) если не ошибаюсь, работает только с Persistent Objects;
2) вполне рабочий, но довольно опасный (коллеги по форуму сейчас заклюют) и возможен, только если не нужно после отдельных вызовов BAPI делать COMMIT WORK;
3) непонятно, как обрабатывать ошибки прикладных проверок из BAPI.

Salas

2 Tetty.
Не совсем, но спасибо! Сейчас углублюсь в теорию :roll:

, предлдоженную sibrin.

2 sibrin.
Ещё раз спасибо. Решил оттестить первый вариант и в IDES след. пример запустил, немного подредактировав

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.

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.

CLASS TH DEFINITION.
  PUBLIC SECTION.
  METHODS HANDLE FOR EVENT FINISHED OF IF_OS_TRANSACTION
  IMPORTING STATUS.
ENDCLASS.

CLASS TH IMPLEMENTATION.
  METHOD HANDLE.
    IF status = OSCON_TSTATUS_FIN_SUCCESS.
      MESSAGE 'Update commited ...' TYPE 'I'.
    ENDIF.
  ENDMETHOD.
ENDCLASS.

DATA H TYPE REF TO TH.

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( ).

CREATE object H.
SET HANDLER H->HANDLE FOR T.

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.

  WA_SPFLI-DISTANCE = CONNECTION->GET_DISTANCE( ).
  WA_SPFLI-DISTANCE = WA_SPFLI-DISTANCE + 1000.
  CONNECTION->SET_DISTANCE( WA_SPFLI-DISTANCE ).

  CONNECTION->SET_DEPTIME( WA_SPFLI-DEPTIME ).
  T = T->UNDO_AND_CHAIN( ).  "Это тоже вставил!
  CONNECTION->SET_ARRTIME( WA_SPFLI-ARRTIME ).

  T->END( ).

CATCH CX_ROOT INTO EXC.

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

ENDTRY.

Насчёт Persistent Objects - да придётся создавать свой класс(чем внутри его заполнять ещё вопрос :?:

).
Сейчас вот попробовал пример, где вставл свой откат - вроде срабатывает, но откатывает всё равно с момента T->START( ).
Неужели придётся несколько их делать?
Как разберусь, расскажу чем всё закончится

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

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

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