Sapforum.Biz
Инструменты => ABAP - Инструментальные средства => SE18/SE19 - BAdI-Builder => Тема начата: Uukrul от Май 25, 2009, 03:14:26 pm
-
Начиная с версии 4.5 кажется, появилась альтернатива экзитам создаваемым в транзакции CMOD/SMOD, в принципе это фактически тот же экзит до версии кажется 6.0, только теперь реализованный на классах, из плюсов ну их стало больше как точки хода в коде, но как и для экзита, если вам какие-то параметры не передали, то достучаться до них можно путем хака, что не очень полезно для здоровья системы. Вообще-то как по мне то это готовилось как замена для экзитов, но почему-то с версии 6.0 на бади немножко подзабили или точнее их перевели в плоскость энхансментов, которые на порядок круче, чем экзиты и бади и похоже, что все пойдет по новому пути.
В версии 6.0 кстати бади, разделили на две части, одну назвали классическим бади, другую точкой расширения, но по факту и то и то уже энхансмент, отличия в транзакции ведения.
В качестве примера берем такую вещь как бади при проводке документа материала, ну я все таки от ММ, так что мне оно ближе :-), задача подменить по определенным правилам завод и склад отпуска в документе материала в транзакции MIGO. В общем виде типа автоматом аля искать нужный запас и подставлять завод склад. До версии 6.0 ну я смотрел в 4.6 такого расширения нет, поэтому пример идет на версии 6.0. Идем по пути: Инструменты -> ABAP-инструментальные средства -> Утилиты -> Бизнес-add-ins - SE19-Внедрение.
Экран как на рисунке SE19-01.png и там идем в нижнюю часть экрана, создание внедрения. Выбираем имя бади, которое будем создавать, все ММ-ные бади похоже называются с имени MB* а там их не много, так что быстро определяемся, что для транзакции MIGO, бади называется MB_MIGO_BADI, и нажимаем кнопку создать внедрение. Система спросит теперь имя нашего внедрения, имена как и положено с Z или Y, и само собой лучше давать имена по смыслу, рисунок SE19-02.png. Ну так как я буду чего-то там мутить с заводом, то имя дал ZTV_MB_MIGO_BADI_WRK. На следующем экрана даем краткий текст, SE19-03.png и переходим в закладку интерфейс.
Как видим методов у данного бади много, но вот тот метод LINE_MODIFY это таки создание/изменение позиции документа, вот за него и возьмемся. Сохраняем созданное расширение и делаем клик мышью на строке LINE_MODIFY. При сохранении нас там попросят за пакет, запрос и все как полагается и тут попадаем в создание определения энхансмента, т.е. получаем подтверждение того что бади, это таки механизм энхансментов. Ну создаем свое внедрение, хотя если у вас уже есть созданное внедрение, то можно записать туда, а иначе жмем кнопку новое имя внедрения, рисунок SE19-05.png, далее как в примере SE19-06.png даем имя ZMB_WERKS и краткий текст, сохраняем и на предыдущем экране уже видим наш ZMB_WERKS в списке расширений. Выбираем его и сохраняем определение и попадаем в метод LINE_MODIFY.
Чтобы посмотреть какие параметры нам передаются можно воспользоваться транзакцией SE18 и посмотреть что из себя представляет данное бади, пример на рисунке SE18-01.png, так как уже и так ясно что бади и точка расширения с 6.0 это одно и тоже, ну чуток экраны ведения будут отиличаться, то по большому счету все равно что выбирать, ну ставим имя в точке расширениня и жмем просмотр, а там по дереву слева выбираем интерфейсы и находим в таблице справа наш LINE_MODIFY, рисунок SE18-02.png и там клик мышью на имени, попадаем в определение класса IF_EX_MB_MIGO_BADI, а дальше как и положено ставим снова курсор на LINE_MODIFY и жмем кнопку параметры, рисунок SE18-03.png и попадаем в список переменных которые передаются в метод, ну нам передается строка позиции документа CS_GOITEM, типа GOITEM.
Теперь можно вернутся в редактор кода, там где вошли в создание метода LINE_MODIFY, ставим комментарий что у нас на входе, так сказать себе памятка и ставим точку останова, ну чтобы посмотреть в отладчике что и когда реально вызывается, после чего активируем все эту кухню, чтобы отсечь ошибки дальнейшего абапа, от ошибок создания расширения. Объектов для активации будет много, выделяем их все и активируем, пример на рисунке SE19-09.png. Если все делалось по описанию то ошибки быть не должно. Затем делаем шаг назад из редактора и активируем свое бади ZTV_MB_MIGO_BADI_WRK, ну теперь оно вызывается при создании документа в MIGO. Кстати если это так то после запуска MIGO будет выполнена компиляция нашего внедрения.
Если текст внедрения будет такой как на экране:
METHOD if_ex_mb_migo_badi~line_modify.
* Входящие параметры
* I_LINE_ID Importing Type MB_LINE_ID
* CS_GOITEM Changing Type GOITEM
IF cs_goitem-bwart = '301' AND cs_goitem-matnr(2) = 'M1' AND
( cs_goitem-werks = space AND cs_goitem-lgort = space ).
* Если завод и склад пустой, то делаем подставноку (Так сказать гуманно!)
cs_goitem-werks = '1000'.
cs_goitem-lgort = '0088'.
ENDIF.
ENDMETHOD.
то, в принципе для материала M1 всегда будет автоматом прописываться завод 1000, склад 0088. При этом в качестве гуманной меры, если пользователь заполнил эти поля с экрана, то подстановки происходить не будет. Теперь идем в MIGO и проверяем как это работает, а работает это замечательно, т.е. система автоматом для 301 вида движения и материала М1 заполняет завод и склад отпуска.
В общем это было о приятном, а теперь о не очень приятном. Заменить все поля документа к сожалению система не дает. Есть динамический пул переменных, которые с точки зрения системы разрешено менять, все остальное идет лесом, о чем и выдается предупреждение системой, что изменение поля запрещено поэтому игнорируется. Как это обойти?
Ну обойти это зачастую сложно и не очень тривиально, в общем виде в коде после вызова наших изменений в модуле LMIGOKL3 идет вызов вот такого вот класса CALL METHOD lcl_migo_screenmodification=>get, рисунок MIGO.png и если после вызова переменная l_status <> '06', то изменения будут проигнорированы. К сожалению комментарий о том, что если поле: Field is 'visible + input' (-> change in BAdI allowed), не соответствует действительны, для проверки попробуйте изменить принимающие завод и склад, хотя они видимы и готовы к вводу, система посылает лесом. В общем как это можно накрутить, смотрим в код реализации... но это уже будет другая тема, точнее тема уже обсуждалась тут http://sapforum.biz/index.php/topic,375.0.html, решения есть... ::)
-
Типа как их искать ...... будет время переведу ....
Finding a BADI using Repository Information System - SE84 (Screenshots)
https://www.sdn.sap.com/irj/scn/wiki?path=/display/ABAP/Finding%2ba%2bBADI%2busing%2bRepository%2bInformation%2bSystem%2b-%2bSE84%2b(Screenshots) (https://www.sdn.sap.com/irj/scn/wiki?path=/display/ABAP/Finding%2ba%2bBADI%2busing%2bRepository%2bInformation%2bSystem%2b-%2bSE84%2b(Screenshots))
-
Начиная с версии 4.5 кажется, появилась альтернатива экзитам создаваемым в транзакции CMOD/SMOD, в принципе это фактически тот же экзит до версии кажется 6.0, только теперь реализованный на классах
я правильно понимаю, что это основное отличие или есть еще?
-
Есть еще Enhancement Spot
http://sapforum.biz/index.php/topic,546.0.html (http://sapforum.biz/index.php/topic,546.0.html)
-
я правильно понимаю, что это основное отличие или есть еще?
Ну как вам сказать... в принципе если смотреть глобально то отличий как бы нет, в итоге вы получаете точку входа, где пишете свой код, который изменяет логику работы системы. А если детально, то различие в реализации через классы или через функциональные модули конечно есть, но к SAP это как бы мало относится, это больше относится к различиям в стилях программирования по процедурному методу и объектно-ориентированному.