Posted: Thu Oct 04, 2007 9:05 pm Post subject: Особенности асинхронных, синхронных и локальных апдейтов
Особенности и отладка асинхронных, синхронных и локальных апдейтов.
Для понимания работы различных режимов создадим в системе апдейтный функциональный модуль
Z_TEST_UPDATE со следующими атрибутами:
Processing type
- Update module
- Start immed.
Code:
FUNCTION Z_TEST_UPDATE.
*"----------------------------------------------------------------------
*"*"Update Function Module:
*"
*"*"Local Interface:
*" IMPORTING
*" VALUE(I_BUKRS) TYPE BUKRS
*" VALUE(I_BELNR) TYPE BELNR
*" VALUE(I_GJAHR) TYPE GJAHR
*" VALUE(I_BKTXT) TYPE BKTXT
*" EXCEPTIONS
*" ERROR
*"----------------------------------------------------------------------
UPDATE bkpf
SET bktxt = i_bktxt
WHERE bukrs = i_bukrs
AND belnr = i_belnr
AND gjahr = i_gjahr.
IF NOT sy-subrc IS INITIAL.
RAISE ERROR.
ENDIF.
ENDFUNCTION.
Для отладки вызываемого функционального модуля установим
в отладчике флажек Debug mode - Update Debugging
Для понимания запускаемых в системе процессов воспользуемся транзакцией SM50. До запуска тестовых примеров на экране SM50
видим следующее состояние процессов:
- In asynchronous update, the dialog program and update program run separately.
The dialog program writes the update requests into the log table VBLOG in the database.
You conclude the dialog part of the SAP LUW with the COMMIT WORK statement. A new SAP LUW immediately starts in the dialog program, which can carry on processing user dialogs without interruption. The dialog program does not wait for the update program to finish.
The update program is run on a special update work process. This need not be on the same server as the corresponding dialog work process.
The SAP LUW that began in the dialog program is continued and then closed by the update program.
- The log table VBLOG can be implement as a cluster file in your system, or be replaced with the transparent tables VBHDR, VBMOD, VBDATA, and VBERROR.
- Asynchronous updates are useful in transactions where the database updates take a long time and the "perceived performance" by the shorter user dialog response time is important.
- Asynchronous update is the standard technique for dialog processing.
- The entries that have a HEADER can be analyzed in SM13.
Запустим на выполнение программу:
Code:
REPORT Z_UPDATE_TEST.
CALL FUNCTION 'Z_TEST_UPDATE' IN UPDATE TASK
EXPORTING I_BUKRS = '1000'
I_BELNR = '0000001081'
I_GJAHR = '2004'
I_BKTXT = 'test'.
COMMIT WORK.
WRITE: / 'End'.
В результате выполнения COMMIT WORK при включенной в отладчике опции Debug mode - Update Debugging откроется новое окно в отладчике, где мы попадем на сформированную Update-программой подпрограмму, запускающую наш ФМ:
Code:
*******************************************************************
* THIS FILE IS GENERATED BY THE FUNCTION LIBRARY. *
* NEVER CHANGE IT MANUALLY, PLEASE! *
*******************************************************************
FORM Z_TEST_UPDATE USING %_KEY.
* Parameter declaration
DATA %_P0000000001 TYPE
BUKRS
.
DATA %_P0000000002 TYPE
GJAHR
.
DATA %_P0000000003 TYPE
BELNR
.
DATA %_P0000000004 TYPE
BKTXT
.
DATA: %_STATE.
* Assign default values
* Get mode for update task
CALL 'GET_SWITCH_UTASK'
ID 'MODE' FIELD 'S'
ID 'STATE' FIELD %_STATE.
IF %_STATE EQ 'N'.
* Import from memory
IMPORT
I_BUKRS TO %_P0000000001
I_GJAHR TO %_P0000000002
I_BELNR TO %_P0000000003
I_BKTXT TO %_P0000000004
FROM MEMORY ID %_KEY.
ELSE.
* Import from logfile
IMPORT
I_BUKRS TO %_P0000000001
I_GJAHR TO %_P0000000002
I_BELNR TO %_P0000000003
I_BKTXT TO %_P0000000004
FROM LOGFILE ID %_KEY.
ENDIF.
* Call update task
CALL FUNCTION 'Z_TEST_UPDATE'
EXPORTING
I_BUKRS = %_P0000000001
I_GJAHR = %_P0000000002
I_BELNR = %_P0000000003
I_BKTXT = %_P0000000004
.
ENDFORM.
После попадания в ФМ, SM50 показывает следующие запущенные процессы:
SAPLZGTEST - программа, содержащая FM Z_TEST_UPDATE.
состояние Abap стека:
Как видно, асинхронный апдейт запускается в собственном диалоговом процессе.
- In local update, the update functions are run on the same dialog process used by the dialog program containing the COMMIT WORK statement.
- To do this, you must include the SET UPDATE TASK LOCAL statement in the dialog program. The effect of this is that update requests are kept in main memory rather than being written into table VBLOG in the database.
- When the system reaches the COMMIT WORK statement, the corresponding update modules are processed in the dialog work process currently being used by the dialog program. If all of the update modules run successfully, a database commit is triggered. If not, a database rollback occurs.
- Once the update function modules have been processed, the dialog program resumes with a new SAP LUW.
- The SET UPDATE TASK LOCAL flag can only be set if no other update requests were generated for the same LUW before the program was called up.
- The SET UPDATE TASK LOCAL flag is effective until the next COMMIT WORK or ROLLBACK WORK command.
Запустим на выполнение программу:
Code:
REPORT Z_UPDATE_TEST.
SET UPDATE TASK LOCAL.
CALL FUNCTION 'Z_TEST_UPDATE' IN UPDATE TASK
EXPORTING I_BUKRS = '1000'
I_BELNR = '0000001081'
I_GJAHR = '2004'
I_BKTXT = 'test'.
COMMIT WORK.
WRITE: / 'End'.
Запущенные процессы:
состояние Abap стека:
Локальный апдейт запускается в тот же диалоговом процессе, что и вызвавшая его программа.
- With synchronous updates, the dialog program waits for the end of the update modules. The dialog program does not begin to process the new SAP LUW until the update modules have terminated.
- To switch from asynchronous to synchronous update, use the AND WAIT addition in the COMMIT WORK statement.
- The entries that have a HEADER can be analyzed in SM13.
Запускаем программу:
Code:
REPORT Z_UPDATE_TEST.
CALL FUNCTION 'Z_TEST_UPDATE' IN UPDATE TASK
EXPORTING I_BUKRS = '1000'
I_BELNR = '0000001081'
I_GJAHR = '2004'
I_BKTXT = 'test'.
COMMIT WORK AND WAIT.
WRITE: / 'End'.
Запущенные процессы:
состояние Abap стека:
Синхронный апдейта отличается от асинхронного только тем, что ожидается завершение вновь созданного диалогового процесса.
SAP LUW
Состояние SAP LUW в процессе апдейта приведено в книге:
SAP Press: Enhancing the Quality of ABAP Development
Коллеги, выскажу здесь свое сугубо личное мнение на вопрос с сапфорума.
В обоих случаях обновление происходит в рамках одного SAP LUW и двух DB LUW. SAP LUW охватывает основной процесс и процесс апдейта V1 функциональных модулей.
Jelena wrote:
Вариант 1 (не рекомендуется):
1. Standard SAP: CALL FUNCTION <update order header> IN UPDATE TASK
2. Standard SAP: CALL FUNCTION <update order item> IN UPDATE TASK
3. User Exit: UPDATE <customer table>
4. Standard SAP: COMMIT WORK
В первом варианте создается новый рабочий процесс для выполения апдейт-программы. При этом основной рабочий процесс переходит в режим ожидания, что согласно курса bc414 вызывает неявный DB commit, завершающий первый DB LUW. После чего создается второй DB LUW в котором происходит обновление двух V1 модулей.
Итого в процессе обновления используется два DB LUW.
Jelena wrote:
Тут все понятно. Теперь вариант 2 (рекомендуется):
1. Standard SAP: CALL FUNCTION <update order header> IN UPDATE TASK
2. Standard SAP: CALL FUNCTION <update order item> IN UPDATE TASK
3. User Exit: CALL FUNCTION <update customer table> IN UPDATE TASK
4. Standard SAP: COMMIT WORK
Обновление трех V1 модулей происходит в рамках апдейт рабочего процесса и второго DB LUW. В первом DB LUW никаких изменений в базе не происходило.
- V2 update function modules are not processed until all V1 update function modules have been successfully processed.
- The V2 update function modules run in a separate DB LUW. They are executed in a V2 update work process. If there are no V2 update work processes set up in your system, the V2 update function modules run in a V1 update work process.
- Once all of the V2 update function modules have been executed successfully, the V2 update requests are deleted from VBLOG.
- If an error occurs in a V2 update function module to which the function module reacts with a termination error message, the system triggers a database rollback. All of the V2 changes in the SAP LUW are undone and an error flag is set in table VBLOG for all of the V2 update requests.
- V2 update function modules run without SAP locks.
- The division between V1 and V2 update function modules allows you to set 'high priority' and 'low priority' updates.
- V2 update function modules are used for low-priority tasks, such as writing statistics to the database.
Коллеги, а чем отличается локальный и синхронный апдейты в плане результата? Если я правильно понимаю - после COMMIT и в том и в дргуом случае мы можем быть уверены, что данные уже в БД? Или есть тонкости?
Age: 70 Joined: 04 Oct 2007 Posts: 1218 Location: Санкт-Петербург
Posted: Tue Mar 18, 2008 6:43 pm Post subject:
Привет. Для локального апдейта пишешь COMMIT WORK,
а для синхронного COMMIT WORK AND WAIT.
В обоих случаях операторы возвратят управление в диалоговую программу только после окончания апдейта.
Quote:
For local update:
As is the case with synchronous updates, the user must wait while the update modules are being executed.
For synchronous update:
Unlike asynchronous updates, the dialog part of the transaction is stopped while the update modules are being executed.
Разница в случае возникновения ошибок в апдейтном процессе. Если будешь производить прямой апдейт таблиц прямо в диалоговой программе, то в случае возникновения ошибки в апдейтном процессе для локального апдейта в диалоговом процессе тоже откатятся изменения.
Для синхронного апдейта, если в диалоговом процессе не будет ошибок, изменения в базу запишутся, а если в апдейтном возникнут ошибки, то они не запишутся.
Это связано с тем, что в случае локального апдейта изменения происходят в рамках одного DB LUW, а в случае синхронного апдейта, вызов апдейтного процесса вызывает неявный DB LUW и V1 модули будут выполняться в новом DB LUW.
Quote:
Unlike the normal update task, the local update task does not run in its own LUW. If a rollback occurs, any changes made in the dialog part are also reset.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
All product names are trademarks of their respective companies. SAPNET.RU websites are in no way affiliated with SAP AG. SAP, SAP R/3, R/3 software, mySAP, ABAP, BAPI, xApps, SAP NetWeaver and any other are registered trademarks of SAP AG. Every effort is made to ensure content integrity. Use information on this site at your own risk.
