Can debugger break on custom functions only?

[carl_korn]

I'm not a programmer.  I'm an analyst who uses the debugger a lot, but I don't use the most sophisiticated breakpoint commands.  I'd like to set a breakpoint on the 'Call Function' Statement, but have the debugger stop only on functions that are customer-written functions.  (I'd like to do the same thing to get the debugger to stop on Methods that belong to custom Classes, too).  I often have to wade through dozens or hundreds of SAP functions before I hit a custom function.  It seems to me the debugger can tell which programs and classes were created by SAP vs. those that are customer-created.  It should be easy to delimit the breakpoints to stop only at customer-generated code.  (It doesn't have to be the Call Statement function.  If there's some other Breakpoint/Watchpoint setup I can use, that's fine.)  Thanks for your help.

Carl

[former_member186746]

Hi,

You might try to use the breakpoint at abap stack + screen command, and then use desktop 2 to see if you're in custom code or not.

Kind regards, Rob Dielemans

[Former Member]

You could add an include in each.  In that include put something like

if sy-subrc = 0.

endif.

Then when ever you want to know if your code is going through any of them. just put a break on that statement.

Neal

[former_member223981]

Hi Carl,

I dont think this is possible (I have never seen anybody do it anyway). However, you can set a breakpoint at the following statements:

> Call Customer-Function

This is the code used to call a user exit. For example, in FM AVAILABILITY_CHECK_CONTROLLER, we have the following code:

****************************************************

* User-Exit before check

  CALL CUSTOMER-FUNCTION '001'

    TABLES

  T_ATPCSX = P_ATPCSX

      T_ATPFIELDX    = P_ATPFIELDX.

****************************************************

This calls EXIT_SAPLATPC_001.

When you breakpoint reaches the Call Customer-Function statement, you can just F5 into the exit to see the custom code.

> Call BADI

This is the code used to call a BADI. For example, in class CL_EX_WORKORDER_UPDATE (Called in CO01), you would have the following:

****************************************************

CALL BADI l_badi->INITIALIZE

  EXPORTING

    IS_CAUFVDB = IS_CAUFVDB.

****************************************************

Again, you can just F5 into the code to see your custom code.

Another option for you would be to user report ZUSEREXIT ( before you begin your debugging - this report should display the relevant exits / badis for the ara you are about to debug. You can se breakpoints at them before you begin your debugging and see if these are hit.

[former_member186746]

Hi,

Another way of getting what you want is simply to execute the transaction/report in SAT (used to be se30) runtime analysis.

and then note which custom code is executed, and use that as a starting point to know where to place your break-points.

Kind regards, Rob Dielemans

[SuhaSaha]

Hello Carl,

I think your problem is a very good use case for 'Layer Aware Debugging' -

But since you are not a technical person maintaining the SLAD configuration will be a challenge for sure.

Edit by: Suhas Saha

You can also create the Debugger Layer in the debugging session. For e.g., you can give the Packages, Programs etc.

Let us know if this helps you in some way.

BR,

Suhas

[carl_korn]

Suhas --

This certainly looks like what I'm heading for.  Unfortunately, when I use the layer-aware debugger using a Program that contains custom function modules the debugger doesn't stop when it hits any of them.  It stops just fine if I use Breakpoint at Function Module to specify the exact functions I'm looking for.  That's what I'm trying to avoid since I don't know every custom function or method we have within our more complex (or old) programs and exits.

I'll see if I can find a programmer to figure this out.

thanks,

Carl

[Former Member]

Hi ,

You need to put debugging filter  criteria on the screen .

For testing custom function module :

Program : SAPLZ*

                 SAPLY*

For testing custom classes:

Class : Y*

            Z*

For all custom codes:

Package = Y*

                  Z*

Regards,

DPM

[carl_korn]

DPM --

I did try variations on all of those themes, but didn't get any breaks.  Is it possible there's an additional debugging authorization object that I need?

thanks,

Carl

[Former Member]

Hi Carl,

I work on older versions. Can you check using tcode SU53, whether any authorization issue is there or not  . Also, from SU24 you can find out all the authorization objects needed for smooth execution of the transaction SLAD.

Regards,

DPM

[carl_korn]

DPM --

SU24 identifies no authorization objects associated with SLAD.

When I use SU53 immediately after setting /h in the command line, I get "all authorizations successful."  I also tried SU53 immediately after entering layer-aware debugger settings and got the same thing.  It doesn't look like security is stopping me.

Carl

[Former Member]

Hi,

Did you tick layer aware debugger active checkbox on the debugger screen.

Regards,

DPM

[carl_korn]

DPM --

Yes, it was the only way I could enter values in Direct Definition of Visible Object fields.

Carl

[carl_korn]

DPM, Suhas, and everyone --

I got the Layer-Aware debugger working.  Naturally, it was a dumb mistake.  After I defined my visible object Program and returned to the debugger, I did not use the Next Object Set button to proceed with debugging.

thanks to everyone.

Carl

[Former Member]

Thanks for letting us know what happened!

Neal