Иногда разработчики блокируют программу от модификации другими разработчиками с помощью установки соответствующей "галки" в свойствах программы/ФМ/класса.
Как правило, это бывает когда копируют CUSTOMER-EXIT ФМ в Z - на CUSTOMER-EXIT эта галка стоит (это даже где то в коде захардкожено, что если ФМ начинается на EXIT_ - то галку поставить).
В большинстве случаев это не проблема, поскольку все разработчики работают под одним пользователем. Но есть богатые компании, которые каждому разрабу заводят своего юзверя.
И бывает, что разработчик увольняется, возвращается на свою старую галеру, например, а на проекте его пользователя блокируют или вообще удаляют нафиг.
И бывает, что за уволившимся приходится допиливать что-то.
И вот когда все это (блокировка редактора, удаление уникального пользователя, допилки) складывается воедино, возникает проблемка - как поправить то, что править не дают?
Не, конечно, вариантов решения масса, можно писать письма базисникам, чтобы те опять завели/разблокировали юзера, сбросили ему пароль, выслали тебе, аргументировать зачем. Можно попробовать обойти это в отладке, если вам дают это обходить в отладке (да есть такие "оригинальные" компании, где в системе разработке по умолчанию нельзя менять переменные и порядок выполнения. Это они типа про безопасность думают, в итоге, как ни удивительно, но они почти единственные полностью "ложаться" под WannaCry или как его там... но речь не об этом). На крайняк, можно в Z прогу вкорячить неявное расширение...
Но вообще, по мне так самое верное - это снять эту чертову галку прямо в БД. Хотя на истину в последней инстанции, конечно не претендую.
И тут есть тоже загвоздка. Вообще данные по проге лежат в таблице REPOSRC. За блокировку отвечает поле EDTX. (ФМ-ники ищите по группе функций типа LZ*). Но таблица помечена системной и править вам ее не дадут. Даже через собственную прогу - все ваши UPDATE REPOSRC даже активироваться не будут, ну или будут падать, если принудительно активируете.
На таблицу есть довольно известный ракурс TRDIR - но с ним та же история - ридонли.
Но сам то SAP как-то работает с этой таблицей, и недолгий поиск выводит на ракурс PROGDIR.
Править наверное можно и через SE16N, но мне удобнее прожку набросать типа вот такую
пятница, 18 августа 2017 г.
пятница, 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-ФМ. И заодно проверим вызовется ли 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 г.
Подписаться на:
Сообщения (Atom)