Особенности в поведении реализаций BAdI HRPAD00INFTY
Всем знакома незаменимая BAdI HRPAD00INFTY, играющая роль верного помощника в реализации различных бизнес-требований при работе с инфо-типами кадрового администрирования. И все бы ничего, если бы не один нюанс, про который следует знать функциональному консультанту. В этой заметке я постараюсь обратить ваше внимание на специфические особенности в поведении реализаций BAdI HRPAD00INFTY.
Для чего нужна BAdI HRPAD00INFTY?
См. заметку Как определить дополнительную логику для PA инфо-типа?
Ну и что за особенность в каком-то там поведении?
Особенность работы BAdI HRPAD00INFTY заключается в том, что при создании/просмотре записи любого инфо-типа кадрового администрирования происходит вызов всех реализаций этой самой BAdI (метод определяется в зависимости от операции, производимой над инфо-типом). В этом скотстве уличен класс CL_EX_HRPAD00INFTY.
Убедиться в этом можно благодаря отладке одного из используемых методов этого класса. Для демонстрации того, о чем идет речь, я воспользуюсь, к примеру, методом BEFORE_OUTPUT этого класса. Для начала убеждаюсь, что для BAdI присутствует n-ое количество реализаций. Сделать это можно посредством транзакции SE18
Затем устанавливаю точку остановок в методе BEFORE_OUTPUTкласса CL_EX_HRPAD00INFTYи пробую открыть любой из инфо-типов.
На видеофрагменте, надеюсь, понятно отражена следующая последовательность действий:
- В начале выполнения метода BEFORE_OUTPUT класса CL_EX_HRPAD00INFTY, происходит сбор информации об активных внедрениях и их реализующих классов (внутренняя таблица EXIT_OBJ_TAB)
Чем это чревато?
Вы можете не задумываться над работой вашей новой реализации, до тех пор, пока не случится какой-нибудь казус, связанный с транзакциями работы с основными мастер-данными работников PA20/PA30/PA40. И под казусом я понимаю не много не мало, а конечно же дампы. Ну да я забегаю несколько вперед. Давайте по порядку.
Допустим, у вас есть очередная реализация BAdI HRPAD00INFTY, в которой происходит что-то важное. Вы бережно определили соответствующую ABAP-проверку исключительно для своего инфо-типа, чтобы исключить, как вам кажется, вызов новой реализации для другого инфо-типа. Например,
При тестировании вы не находите к чему придраться, учитывая, что тестирование проходит применительно к инфо-типу, для которого создана реализация. Да и никто из коллег не был недоволен. Например,
Допускаем, что ваша разработка переезжает в продуктив, и по каким-то причинам, до него (продуктива) не доезжает один из объектов, который использовался в вашей реализации. Ситуация, скажете вы, маловероятная, но тут я посмею с вами не согласиться, так как она вполне себе может произойти. Причины, по которым какой-либо из объектов может не доехать до целевой системы, здесь рассмотрены не будут.
Итак, один из объектов не доезжает в продуктив, и бизнес-пользователь начинает исполнять свои основные обязанности по работе с мастер-данными персонала. Важно здесь то, что бизнес-пользователь начинает работать с инфо-типами, которые не относятся к вашему внедрению. Вы думаете, что ничего страшного произойти, в общем-то, не может. Например, создается запись инфо-типа 0006 - "Addresses"
На выше представленном видеофрагменте:
- В момент создания записи инфо-типа 0006 - "Addresses" транзакции PA30 формируется дамп, информирующий о том, что какого-то объекта, который участвует в новой реализации BAdI, нет в системе.
И да, это тот самый момент, о котором шла речь выше. Какого бы качества не был ваш ABAP код в новом внедрении, и сколько бы проверок не было реализовано на ограничение инфо-типа, для которого код должен выполниться, если в какой-либо из реализаций содержится критическая ошибка, работа основных транзакций по работе с мастер-данными персонала будет нарушена. Забыли про PA40. Исправляемся,
У меня все. Как всегда, обнимаю. Ваш, ignatov.