Ouch! Ugh! Never seen something as ugly and embarassing as this!

[former_member181923]

In this thread here:

Sajan Joseph gave me an effective work-around to see custom BADI code in a debugging session even when the BADI is being called from an FM that's being called from an update task in MIGO.

<b>But gee-whiz - this work-around requires coding an infinite loop (temporarily, or course) for debugging purposes.</b>

If SAP can give us external debugging in WDA, surely it can do better with BADI code inside plain old ABAP.

Does SAP really want to be on record as advising the coding of temporary infinite loops to get around a debugger communication problem ????

How about it, Walldorf ????

djh

[Former Member]

Hi David,

Ugly yes, but useful. I used this method developing a FSCD idoc run as I could not predict how many or which processes would be started by the parent application. And as the memory of each function group called in the child processes only had persistance in the LUW of its own instance, the workaround was needed to give us enough of an understanding of what happened in each of the children as opposed to the parent process.

But, as you say, it would be more useful to be able to access the break-points directly if the called process (or update task) could communicate back to your dialog session without having the endless loop. Anyway, the point is that the fact of the case being a BADI is not the full cause - any process where you have steps outside of the main LUW (including Call function.... in update task, or calling any asynchronous process) loses direct control for debugging purposes.

I thought about using a workitem (in Business Workflow) to send back, but this would fundamentally change the nature of the process by running in the same LUW as you are calling from, and thus in most cases, remove the point of debugging.

Sorry, no answers just more questions.

Regards

Gareth

[stephenjohannes]

David,

I am confused on your issue. Over on the CRM application I frequently put hard-break points into BADI's to trigger the debugging. In fact some of those break-points are external/HTTP break-points. I never have an issue with those being triggered provided the ABAP code is not in update task.

I think your issue stems around update debugging which unfortuantely requires it to be turned on in order to hit the break-point. A technique I have used is to place a break-point so i can turn on the update debugging in the debugger and then continue where I can go.

I have never really had any issues with debugging BADI's. In fact if I go too crazy I can actually debug the "instanation" of the badi object inside of the standard program.

Beyond this update task issue(which is true for all ABAP code called in update task), is there a reason why you think BADI's can not be debugged?

Take care,

Stephen

[former_member181923]

Hi Stephen -

Thanks for taking the time to reply.

You're quite correct - the problem appears to be local to executing out of update tasks under certain circumstances. I didn't mean to imply that the regular debugger NEVER plays nice with BAdI implementation code. Sorry if you got that impression.

But to me - this drawback of BAdI<-->debugger communication is bad enough to warrant SAP fixing it - particularly, as I said, since SAP has done such a nice job of giving us an external debugger for WDA.

I can't imagine that making the debugger play nice with BAdI or customer exit code executing out of update tasks is for some reason more difficult than writing code to facilitate external debugging in WDA ...

Best regards

djh

[stephenjohannes]

David,

I can't confirm this, but I think the external debugger for WDA, is really the same external debugger used for BSP. Technically any ABAP code called remotely in a 620 system and up uses the "external-breakpoint" mechanism. I know that the BSP applications use the built HTTP ABAP debugger that popups a SAPGUI debugger window from the web-browser. Since WDA is based on ABAP, I bet the debugging mechanism already leveraged the built in framework in place.

I really think the fundamental problem is update debugging which in my opinion always required some extra pain. I guess I am always of the school if there is a "reasonable" workaround, then it might not be worth a fix. Then again my list of issues with the ABAP runtime in terms of what generally requires someone to fix things is probably different than yours. Don't get me started on the ABAP web service client proxy generation and the fact you can't use it with some of the google web service api's(multi-part messages in the WSDL).

Take care,

Stephen

[former_member181923]

Hi Stephen -

Thanks very much for that interesting information.

I wish there were more discussions like this at SDN, and less on how to make the lights blink in the executive men's bathroom when 4qtr earnings come in above what the Street was told ...

Best regards

djh