Debugging Any program via User parameters
This is just a step to think over how do we allow the programs to be debuggable. Its one of the ideas that i come to think over. We keep writing lots of code but at the end we need to debug them especially in the Production system. So debugging becomes an important issue!!.
DEBUGGING CONFIGURATION VIA USER PARAMETERS
Step 1- We will enable the program to be debugged thru the user parameters!!
This way we can add or remove the parameters and enable the code to be debugged in any system.
Lets say: we create parameters like: debug level, debug tcode and debug program name.
Some code snippet is:
CONSTANTS: c_param_debug_level TYPE memoryid VALUE ‘DEBUG_LEVEL’,
c_param_debug_tcode TYPE memoryid VALUE ‘DEBUG_TCODE’,
c_param_debug_prog TYPE memoryid VALUE ‘DEBUG_PROG’.
We will put a debug point in the program smth like this _debug_level 1. For more please see the implementation code i will attach!!
Step 2- We need to create a Function or a object that is going to be reading the parameters and checking the level of debugging and loading the details for debugging. Object that will be loading all the required data for debugging!!.
This should be called first then everything in the code! For example at the Standard report at initialization section.
As the code the name of this class is zcl_debug.
Step 3- We need to write a Macro in the code we want it to be debugged, so that we can stop the code at that execution point.
Why macro? Because via macro we can put Break-point and as macros can not be debugged thats the best candidate for this.
Code snippet: ***Writing the MAcros!!!
DEFINE _debug_level.
if zcl_Debug=>get_instance( )->is_debug_level_correct( iv_debug_level = CONV string( ‘&1’ ) ) = abap_true. “#EC USER_OK BREAK-POINT. “#EC NOBREAK
endif.
END-OF-DEFINITION.
Step 4- we could be able to configure the level? We can use config table but that will complicate the debugging and most often its forgotten. So why not we use a pop up screen where we can change the debugging level dynamically!!
DEFINE _debug_configure.
zcl_Debug=>get_instance( )->configure_debug_level( ).
END-OF-DEFINITION.
Step 5- Final Look Report zxxx.
DEFINE _debug_configure.
zcl_Debug=>get_instance( )->configure_debug_level( ).
END-OF-DEFINITION. …
İnitialization.
_debug_configure.
Start-of-selection.
_debug_level 3. …
By this way we can enable the code to be debuggable which will make our life much easier!!
Any suggestions, please feel free to suggest me
I am sorry for the formatting guys somehow even i formatted it, it keeps losing the formatiing.
Certainly it looked awful in chrome. But when I went into edit mode (using my moderator superpowers) it looked - well, not brilliant, but better.
So I cut and paste your text into notepad, and the then cut and paste it back again, and then used the editor to format it a bit. It's still not great, but at least it's readable now.
I am sory Matt yes the formatting in Chrome really looks terrible.
I need to find out the way to correct it, even i tried formatting after i save it still gets lost.
Mozilla it looks different i didnt know
Why not using standard Checkpoints (Activatable breakpoints)?
Thats a great way too but sometimes you need to activate that on server side and you may not have permission for that user.
If you debug in the Production server authorization becomes a problem.
if not thats also good way:)
How does your solution bypass it?
Won't you need also debug authorization?
(If not, it may be a security hole)
It's an enhancement of the BREAK-POINT statement - just switchable according to your parameter ids. I don't really see a need tor it.
If you need to debug in production, then you need to debug in production and in any rational, sensible organisation, you get the authority to debug in production. If a problem cannot be reproduced in test or development, then debugging in production is the only answer. If someone has put in place an immovable rule that you can never debug in production, then I'd like to introduce them to that irresistibly force "business requirement"!
And what will happen when the irresistibly force of "business requirement" will meet the immovable object of "security requirement"
Hi
Security versus business reqirement:)
What could go wrong, if someoen goes and updates and adds user parameters to each user in production.
Then all the users will suddenly start going into the Debug Mode!!
if they do have debug Mode
that will cause a big problem sure.
So in this case represents a security hole
Since it's the business that runs the business,and not the security team, business requirement trumps everything. Even if it is massively risky, violates regulations, the law and every moral principle in the universe. If after explaining all of that the business decides to go ahead, then we have a choice - help them or quit.
Fortunately, most businesses aren't pathologically suicidal and do change their requirements in the face of things that could material harm them!
yes you are so right Matt:)
One day when they experience it they will take security seriosly:)
The classic solution that avoids the paradox is the destruction of the immovable object...
hi Sinai
Sure you need debug authorization but in complicated programs debugging and bypassing the unnecessary code is a need.
And as you mentioned SAP provide Check point groups which you can log.
The way this breakpoint is controlled is thru user parameters which makes it dynamic in a sense.
You can activate and deactivate depending on the level you want.
Hi,
Unless I've missed something, this is exactly the same functionality that standard activatable breakpoints offer: Dynamic activation of breakpoints for users/servers.
I'm also quite confused why would anyone need this... Even when our company was public and much stricter regulated I had authorization to debug in Production. Had no SE38 or SE80, which I think is pretty stupid, but /h worked.
I can appreciate the creativity here but really it just shouldn't have come to this. If assistance is needed from an ABAPer and it requires debugging then give them authorization. In the worst case there is the Firefighter concept that could be used.
The debugger authorization would still be needed to use this stuff - there is no way to bypass it, I believe.
If I understand it correctly - which I doubt, having gotten this far:
this "debug API" would enable the programmer to embed predefined break-points, which then get triggered depending on the "debug level" entered by programmer... What escapes me is: how will the popup be suppressed for normal users..?
I wouldn't program something like this into applications either... it may, however, be somewhat useful, if the application is built using some framework (like the "notorious" Business Data Toolset, the framework for Sap Business Partner) where one would want an easy way to skip debugging all the framework code. Still, the task this is trying to ease is: setting breakpoints at "all the necessary places", and if something like this really needs to be built into application, the Checkpoints mentioned bu Shai Sinai would be the way to do it, I feel...
solen dogan
Just an idea how to trigger popup - SAP Mass Activities framework uses command field function DBUG to activate the "debug mode".
Yes, first we control the breakpoints thru the user parameters!!
we can add the level of debuging we need and the code will read these parameters and enable all the breakpoints at that level.
And the po up is to change the level of debugging dynamically without going to user parameters and changing it!!
I hope ı didnt confuse you!!
🙂
It can be useful in times and for basic code it may not!!
But for complex things it will be!!
Another idea is the layer aware debugging in SAP!!
Check:
http://scn.sap.com/people/stephen.pfeiffer/blog/2010/07/27/layer-aware-debugging-in-nw-70-ehp2
Aaah, ok, I think I got it 🙂
Yes, layers look interesting too.
Jelena
This is just an attempt to find another way
You may never need this
But there will be time you will need this too.
depending how complex code you write
We use firefighter at work but its a big problem to get it and takes long time.
As i provide production support this makes life easier.
Hello, please have also a look at standard class CL_DEBUG which provides some kind of similar functionality.
Tapio
Thanks alot
I will have a look at it now, interesting !!
Well,
checkpoint groups with transaction SAAB is still a very powerful tool. Even without debugging, you may set logpoints and store interesting data (The way we used before debugging was invented - remember that times?).
A good hint for every developer: SAP already created more than 1.700 checkpoint groups in the standard. Try to activate group ALV_GRID - now you have a break-point i.e. in method SET_TABLE_FOR_FIRST_DISPLAY, just in case you want to find out where the data for a grid are coming from.
It's always good to invent a needed functionality, it's never wrong to find thatv it's already integrated in ABAP 🙂
Regards, Clemens
Very good tip Clemens! You can also check the checkpoint group in the debugger -
I have found them very helpful in debugging the BP transaction, which IMO is not easy to debug.
BR,
Suhas