SAP GUI 7.50
SAP GUI 7.50
Patch Level 1
Patch Level 1
пятница, 21 июля 2017 г.
пятница, 3 марта 2017 г.
Когда вызывается ФМ, если он IN BACKGROUND TASK?
Вызывается он после завершения UPDATE процессов (CAL FUNCTION ... IN UPDATE TASK). И вот доказательство.
Создаем вот такую табличку:
Создаем вот такой ФМ типа RFC:
Еще один типа UPDATE TASK немедленного запуска (обратите внимание что в нем еще раз запускается BG-ФМ со своим ID):
И еще один UPDATE TASK отложенного запуска:
И выполняем вот такой код для проверки
Наша задача доказать что BG-ФМ выполнится последним, несмотря на то, что зарегистрирован первым, и главное выполнится только после всех UPD-ФМ. И заодно проверим вызовется ли BG-ФМ из UPD-ФМ без COMMIT.
Запускаем и смотрим в таблицу (таблица для наглядности отсортирована по времени выполнения):
Итак, какие можно сделать выводы.
Создаем вот такую табличку:
Создаем вот такой ФМ типа RFC:
FUNCTION zfm_krs_test_bg.
*"--------------------------------------------------------------------
*"*"Локальный интерфейс:
*" IMPORTING
*" VALUE(ID) TYPE CHAR10
*"--------------------------------------------------------------------
DATA ls_data TYPE zkrs_test_bgto.
ls_data-id = id.
GET TIME STAMP FIELD ls_data-tst.
MODIFY zkrs_test_bgto FROM ls_data.
COMMIT WORK.
ENDFUNCTION.
Еще один типа UPDATE TASK немедленного запуска (обратите внимание что в нем еще раз запускается BG-ФМ со своим ID):
FUNCTION zfm_krs_test_upd.
*"----------------------------------------------------------------------
*"*"Функциональный модуль обновления:
*"
*"*"Локальный интерфейс:
*" IMPORTING
*" VALUE(ID) TYPE CHAR10
*" VALUE(IV_WAIT) TYPE INT4 DEFAULT 5
*"----------------------------------------------------------------------
DATA ls_data TYPE zkrs_test_bgto.
ls_data-id = id.
WAIT UP TO iv_wait SECONDS.
GET TIME STAMP FIELD ls_data-tst.
MODIFY zkrs_test_bgto FROM ls_data.
ls_data-id = |BG{ id }|.
CALL FUNCTION 'ZFM_KRS_TEST_BG'
IN BACKGROUND TASK
EXPORTING
id = ls_data-id.
ENDFUNCTION.
И еще один UPDATE TASK отложенного запуска:
FUNCTION zfm_krs_test_upd2.
*"----------------------------------------------------------------------
*"*"Функциональный модуль обновления:
*"
*"*"Локальный интерфейс:
*" IMPORTING
*" VALUE(ID) TYPE CHAR10
*"----------------------------------------------------------------------
DATA ls_data TYPE zkrs_test_bgto.
ls_data-id = id.
* WAIT UP TO 5 SECONDS.
GET TIME STAMP FIELD ls_data-tst.
MODIFY zkrs_test_bgto FROM ls_data.
ENDFUNCTION.
Для наглядности где какой тип ставить картинка:
И выполняем вот такой код для проверки
CALL FUNCTION 'ZFM_KRS_TEST_BG'
IN BACKGROUND TASK
EXPORTING
id = 'BG'.
CALL FUNCTION 'ZFM_KRS_TEST_UPD'
IN UPDATE TASK
EXPORTING
id = 'U0'
iv_wait = 0.
CALL FUNCTION 'ZFM_KRS_TEST_UPD'
IN UPDATE TASK
EXPORTING
id = 'U1'
iv_wait = 5.
CALL FUNCTION 'ZFM_KRS_TEST_UPD2'
IN UPDATE TASK
EXPORTING
id = 'U2'.
COMMIT WORK.
Как видите, тут мы вначале регистрируем BG-ФМ, потом UPD-ФМ с нулевой задержкой внутри, потом UPD-ФМ с задержкой в 5 секунд перед обновлением и завершением, и, наконец, UPD-ФМ с задержкой обновления.Наша задача доказать что BG-ФМ выполнится последним, несмотря на то, что зарегистрирован первым, и главное выполнится только после всех UPD-ФМ. И заодно проверим вызовется ли BG-ФМ из UPD-ФМ без COMMIT.
Запускаем и смотрим в таблицу (таблица для наглядности отсортирована по времени выполнения):
Итак, какие можно сделать выводы.
- BG-ФМ запускается после выполнения всех UPD-ФМ (даже после UPD-ФМ с задержкой запуска)
- BG-ФМ, вызванный из UPD-ФМ, не нуждается в дополнительном COMMIT для запуска
- BG-ФМ, вызванный из UPD-ФМ, также запускается только после выполнения всех UPD-ФМ (даже после UPD-ФМ с задержкой запуска)
- BG-ФМ, зарегистрированный до COMMIT, вызывается позже чем BG-ФМ, вызванные из UPD-ФМ
ЧТД.
пятница, 16 декабря 2016 г.
вторник, 15 ноября 2016 г.
понедельник, 26 сентября 2016 г.
пятница, 1 июля 2016 г.
четверг, 21 апреля 2016 г.
Подписаться на:
Сообщения (Atom)