SAP System Program Debug

场景：

系统程序某个screen中的数据字段异常，其值是经过系统程序多次处理得到，这种情况下要求分析出数据的来源。

 

Debug方法（逐步逼近法）：

1. 在screen的 PAI 起始处设断点

2. 在screen PAI处开始单步调试，找到目标数据变化的位置从而界定初始Debug范围，在变化前一位置设断点

3. 重启新一轮调试, 从上次最后设的断点处开始debug

4. 重复步骤2,3 直到找到最后的具体变化点

 

若数据在进入PAI之前数据已经变化成不期望的数据，可能过Call Stack上溯到以前的调用处并设断点，然后按上述debug方法操作. 另设断点时要善用ST05, (Field, Subroutine) Where-used, FIND来辅助找出可疑位置。

 

其它一些技术手段:

Watch-Point的使用(当变量=某值时进入Debug状态, 分析系统程序时非常有用!感谢波波):

Sometimes, an SAP process will stop working with an error message, or an abend. Unlike with a dump, it can be difficult to find exactly where the problem occured. What you should do, is get the technical name and number of the message - e.g. RS 100. Set a breakpoint at the start of the process (or run the process with the debugger switched on). As soon as the debugger is in some abap code, set a watchpoint for sy-msgno. In this example, you should set a watch point for sy-msgno = 100. Then hit F8.

The process will continue to run until sy-msgno has the value 100.

Check that the message ID is correct, according to the message - RS in this example. If it is, then you are at the place where the error occurs. You can usually back trace a few steps to find out precisely what was causing that error to be triggered.

原文地址: http://searchsap.techtarget.com/tip/0,289483,sid21_gci1314665,00.html

 

Active ITABs in Memory(Only in Classic Debugger)

1. In debug mode follow menu path: GOTO -> System Areas -> Internal Information

2. Enter "DSEG" to Area field

You will get a list of all the tables active in that program along with some other attributes. The type and size of the records determine if they are internal tables and how many records there are.
You can play around and try the other area than DSEG, some are interesting.

 

Memory Use

1. In debug mode follow menu path: GOTO->Status Display->Memory Use
2. Select tabstrip: Memory use

Ranked list You will see all variables used in the program sorted by size