Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
I won't tell you directly what the FM is, but it took me about 2 minutes. Instead I'll tell you how to do it.
In SE19, change your BADI implementation. Start the debugger, hit the deactivate button. Debug through till you're in the processing of the okcode. ( Module "ok_code" of SAPLSEXO ). The function module is obvious. When you've found it, post the answer here.
When you've found the name of the function module, look at it through SE37. Then click on "Display Object List" to see the other function modules in the group.
If you find these things out for yourself, you'll develop very useful skills for the future. Anyway - try again, following my guidelines above.
Go into implementation in change mode from SE19. Enter /h in the okcode box. Hit "deactivate". In the classic debugger (though not the new one), I set a breakpoint in the flow logic, to stop at MODULE ok_code.
I then single step into that module. And have a quick look at the ABAP. It appears that the field "ok_code" is the one being tested to decide what to do. It has the value DEACTIVATE. I step into the form common_ok_code, but it appears DEACTIVATEisn't one of them. So I keep single stepping. I get to case ok_code.. Then next step I get to is WHEN seex_deactivate. A quick look at the code below the WHEN, and I see FM: SXO_IMPL_DACTVE - which has one parameter, imp_name, which is my implementation name!
I then look at the function group of SXO_IMPL_DACTVE, and find there is also a function module SXO_IMPL_ACTIVE.
The only wrinkle in this is that there might be some global parameters being set by a previous call to another function module in the same group, earlier on. So you might need to set a breakpoint within a few other FM in the same group, and go through the process again, so you can get the right sequence of function module calls.
Bluesky
