干了SAP开发这么多年，我都积累了哪些程序调试技巧

• Tip1. Rubber Duck Debugging

• Tip1.1 blog your finding out

• Tip1.2 Index your raw material into your knowledge repository

• Tip2. Comparison

• Tip3. The Mini-System methodology for issue-isolation

• Tip4. Google the error message

• Tip5. Try to be a master about the trouble shooting tool you use

• Tip6. “I don’t know where to set breakpoint?”

One of my new colleague is asking me whether I have some best practice which could be followed as a general way to analyze some issue more efficiently.

Although I have assembled a list to try to share my trouble shooting tip with more than 25 concrete examples in UI5 development in this blog My UI5 debugging tips and experience collection – how to resolve UI5 issues through debugging by yourself, currently I haven’t done the same thing in ABAP. Nevertheless I think there are still some common best practice regardless of programming language difference. I list those best practice below.

Tip1. Rubber Duck Debugging

Figure out the detail of each step via debugging.

The official name of this approach is so called “Rubber Duck Debugging“, which is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line-by-line, to the duck.Many programmers have had the experience of explaining a programming problem to someone else, possibly even to someone who knows nothing about programming, and then hitting upon the solution in the process of explaining the problem.

For me, I prefer to make extensive screenshots when I debug, which contain the important callstack and variable content. Every developer his / her favourite tool to record these screenshots, here I call those screenshot as “raw materials” in the left part of this blog. Here what I would like to emphasize is, I know some developers simply discard these raw materials once they found out the root cause and finished correction, which from my point of view is a great pity that they lose the chance to make more thorough learning on the related area. Here below is how I deal with those raw materials:

How to deal with raw materials generated in your debugging process

Tip 1.1. Make induction on the knowledge / lessons-learned behind the debugging, and blog them out in community

Normally if I meet with a issue I would always search in SAP community first, if nothing helpful found, I will do trouble shooting myself. Once the debugging is done, if I find the knowledge / experience I gained through this trouble shooting
is systematic and inspirational enough to be probably helpful in the future, I will spend additional time to write them into blog in community, which brings two benefits:

In the future in case I need to look back to those issues for whatever reasons, I can efficiently find the blog and quickly recall what I have once done, even if there is always a long time passed. It means the original effort I spent in the trouble shooting is NEVER wasted.

I am always happy to see the comment in my blog that some guys have met with similar issue and get inspired by my blog to finally resolve their issue.

Tip 1.2. Index your raw material to ensure they could be quickly located with whatever approach you prefer

Every developer should know the meaning of “Index” here.

You spend additional effort to “index” those raw materials, and you can get far more reward in return.

If the knowledge is too trivial to blog it out in SAP community, I will store the raw materials into my knowledge repository. In the early phase of my SAP career life I choose Microsoft word to store all those materials, which later proves it is a bad choice due to the following drawbacks:

It is impossible to search the word document content by keyword. Only search by word file name is possible.

All word documents are stored locally. You have to backup them regularly. As time goes by the size of those word documents increases as well.

Fortunately thanks to the evolving technology, nowadays we can choose cloud based knowledge repository like Evernote or GitHub.

You can create issues in the github repository which provides powerful label and full text search functionality, which could enable you to find the very content you need within almost 1 second’s time. With the support of my knowledge, when I have a new issue to trouble shoot, I never hurry up to start debugging, but always check from my knowledge repository whether there is some related stuff, if I am fortunately enough, in the past I have already made some debugging and wrote down the debugging screenshot, so this time I can continue with those callstack to debug, without debugging from the entry point of the issue, which could save me a lot of time.

Summary

When you find out the root cause of your issue and finish the correction, this isnot an end but just a beginning – it is time to start your knowledge build-up, and raw material indexing into your knowledge repository. The KPI to evaluate your knowledge repository: a good knowledge repository enables the stored stuff to be quickly located and efficiently reused.

Tip2. Comparison

This tip is actually an complement to tip 1. I usually heard the complains that “SAP application has some complex logic, I keep on debugging for hours and get lost in the code”. On the one hand I agree with this statement “SAP application is complex”, and it is also all in a day’s work to me to have several hours debugging for one issue. On the other hand, it is helpful if you can find the case that “the issue occurs in system A but could not be reproduced in system B”. In this case, you can debug simultaneously in both system, to compare the execution difference via single step debug. Sometimes it is also necessary to check the customizing in both system.

I have used this approach to resolve many tricky issue in my daily work. My experience is as long as you have successfully located the deviating place starting from which the two system behave differently, you are normally not far away from finding the root cause.

Some examples to practice the comparison approach:

• Inside AET: why “create field” button is visible in some UI while invisible in others?
• Contact Support button display logic in Fiori
• Why Adapt UI button is visible in some system but missing in some other system

Tip3. The Mini-System methodology for issue-isolation

In the early ten years of 21 Century, it is very popular in China to assemble a PC by ourselves via DIY approach. It means we buy CPU, memory chip, hard disk, motherboard and other stuffs from different hardware manufacturers and assemble them by ourselves. Most common issue is that after assembly, the computer cannot boot at all. Then we use “Mini-System” approach for trouble shooting: as first step we only try to boot computer with LEAST necessary hardware ( CPU + Power + Motherboard: these three components constitute a so called “Mini-System” ). If the first attempt succeed, we can append additional component, but ensure only ONE new component is added in EACH step. Such iteration could enable us to find which hardware makes the boot failed.

This methodology can also be applied to issue trouble shooting in our daily work.

See one example how I resolve one tricky issue in ABAP using this approach from this blog: My Tips about how to handle complex and tricky issues.

For another example, during my two year’s life as an Fiori application developer in SAP, the most common issues I have resolved are such as “after a button is clicked, the UI does not work as expected”.

By analyzing what exactly components are involved in the scenario, we can easily come to the conclusion that in theory there are only three possible reasons:

• Fiori UI sends the wrong request to backend – UI issue
• Fiori UI successfully receives the correct response from backend, but fail to react to this response correctly – UI issue
• Backend sends incorrect response to UI – backend issue

So as first step I will isolate the issue to figure out whether this is a frontend or backend issue.

If it is a frontend issue, I will switch Fiori UI to use mock server instead. In this case, I manipulate some test data and feed it to my frontend with mock server, so that I can debug without backend server any more. It could usually save time when backend server has to take some time to handle the request.

If it is a backend issue, I will use Chrome extension postman to send the request to backend directly, without having to repeat lengthy steps in Fiori UI to send request.

Furthermore, if it is possible to construct the request sent from UI in ABAP, I always prefer to do it in ABAP side as it saves more time to fire the request directly in ABAP than from browser.

This week ( 2017-06-05 ) I am investigating on one issue in CRM Interactive report:

I need to manually set input characteristic and filters for report and click “go” button again and again to send request to ABAP backend. I could not stand to waste time on such labor work in UI so I write the following report to fire the report query. Now I simply click F8 to execute this report and the breakpoint I set in query handler gets triggered immediately

REPORT crm_bw_read_data.
TYPES:
  BEGIN OF rsurfcdata,
    clustr TYPE indx_clstr,
    clustd TYPE indx_clust,
  END   OF rsurfcdata,
  lty_t_container TYPE STANDARD TABLE OF rsurfcdata WITH DEFAULT KEY.
DATA: lv_max TYPE int4,
 l_t_selections    TYPE sbiwa_t_select,
    l_t_fields        TYPE sbiwa_t_fields,
    ls_field          LIKE LINE OF l_t_fields,
    l_t_container     TYPE lty_t_container,
    l_t_msg TYPE rs_t_msg.
PARAMETERS: logsys TYPE logsys OBLIGATORY DEFAULT 'QHDCLNT504',
             date TYPE sy-datum OBLIGATORY DEFAULT sy-datum.

DATA: ls_selection LIKE LINE OF l_t_selections.

ls_selection = value #( fieldnm = 'APP_SERVER' sign = 'I' option = 'EQ' low = 'ldciqhd'  ).
APPENd ls_selection TO l_t_selections.

ls_selection = value #( fieldnm = 'LOG_SYSTEM' sign = 'I' option = 'EQ' low = logsys  ).
APPENd ls_selection TO l_t_selections.

ls_selection = value #( fieldnm = 'REPORT_AREA' sign = 'I' option = 'EQ' low = 'SERVICEORDER'  ).
APPENd ls_selection TO l_t_selections.

ls_selection = value #( fieldnm = 'SELECTION_ID' sign = 'I' option = 'EQ' low = '0000'  ).
APPENd ls_selection TO l_t_selections.

ls_selection = value #( fieldnm = 'USERNAME' sign = 'I' option = 'EQ' low = sy-uname  ).
APPENd ls_selection TO l_t_selections.

ls_selection = value #( fieldnm = 'POSTING_DATE' sign = 'I' option = 'EQ' low = date  ).
APPENd ls_selection TO l_t_selections.

ls_field-fieldnm = 'APP_SERVER'.
APPEND ls_field TO l_t_fields.

ls_field-fieldnm = 'LOG_SYSTEM'.
APPEND ls_field TO l_t_fields.

ls_field-fieldnm = 'REPORT_AREA'.
APPEND ls_field TO l_t_fields.

ls_field-fieldnm = 'SELECTION_ID'.
APPEND ls_field TO l_t_fields.

ls_field-fieldnm = 'USERNAME'.
APPEND ls_field TO l_t_fields.

ls_field-fieldnm = 'POSTING_DATE'.
APPEND ls_field TO l_t_fields.

ls_field-fieldnm = 'STAT_OPEN'.
APPEND ls_field TO l_t_fields.

ls_field-fieldnm = 'N_OF_SRV_ORDER'.
APPEND ls_field TO l_t_fields.

CALL FUNCTION 'RSOA_DSOURCE_READ_REMOTE_DATA'
            EXPORTING
              i_datasource       = '/CRMBW/OLTP_SRV_ORDER'
              i_slogsys          = logsys
              i_maxrows          = lv_max
            TABLES
              i_t_selections     = l_t_selections
              i_t_fields         = l_t_fields
              e_t_container      = l_t_container
              e_t_msg            = l_t_msg
            EXCEPTIONS
              remote_read_failed = 1
              x_message          = 2.

WRITE:/ lines( l_t_container ).

Tip4. Google the error message

Suppose there are some error messages raised in the involved scenario of the issue, and if you are not the first poor guy who has suffered from the issue, once you google the error message, you could probably find some hint. This tip does not always help since there are some possibilities that other guys were just asking help in community but no answer is provided till now.

Tip5. Try to be a master about the trouble shooting tool you use

There is an idiom in ancient China by Confucius (a Chinese teacher, editor, politician, and philosopher of the Spring and Autumn period of Chinese history): 工欲善其事，必先利其器 – A workman must sharpen his tools if he wants to do his work well.

In my opinion every minute you spend on researching the trouble shooting tool you are using is really worth it and in return the expertise will make your trouble shooting more efficient.

In ABAP, besides ABAP debugger, SAT and ST05 are also important tools for trouble shooting. I will explain them in more detail in next tip.
In UI5 development, I prefer Chrome development tool than Firebug in Firefox. Here below are some of my blogs which introduces how to use Chrome development tool to finish trouble shooting, self study and research task.

Chrome Development Tool tips used in my daily work

Currently ( 2017-06-11 ) up to 19 tips I learned about Chrome development tool are collected in this blog.

• Use Chrome development Tool to compare Rendering performance between SAPUI5 and React – the “SAT” tool for JavaScript

• An useful Chrome extension – UI5 Inspector – A must-to-have tool for UI5 development

• An example of using Chrome Development Tool to analyze JavaScript garbage collector If you have read here, you might also be interested about how to research the garbage collection behavior in ABAP and Java, then maybe you could continue to read this blog: An small example to learn Garbage collection in Java and in ABAP

• Useful Chrome Tool chrome://net-internals to monitor http request detail

• Use Chrome development tool to do self-study on some JavaScript function native implementation

• How to send Batch request to backend with Chrome extension postman

Tip6. “I don’t know where to set breakpoint?”

Suppose you have persisted in accumulating your raw materials in knowledge repository, you should never meet with such situation, as you should always know some entry point where you could set breakpoint.

Instead, this trouble usually occurs in the area which is new to you.
As I said in previous tip 5, in such case some trouble shooting tool could always give you some hint. In ABAP, you could simply run your scenario with SAT or ST05, and then inspect trace result and find an appropriate position to set a breakpoint.

It is always a breakthrough to manage to find the exact code position where the related error message is raised for trouble shooting. It is more helpful if you can find some domain specific trace tool which can enable you to do trouble shooting in a more professional way, for example:

• Webdynpro trace tool WD_TRACE_TOOL
• Wedynpro runtime performance trace tool
• One order trace tool CRMD_TRACE_SET
• OData performance trace and payload trace functionality
• how to create and consume web service in ABAP system
• One approach to trace a dedicated workprocess
• How to deal with error message raised from UI component workbench
• How to persist the UI exception so you can view them later

You can even build your own domain specific trace tool by yourself to ease your trouble shooting, for example you can see my blog:
Use ABAP Channels to build a trace tool used in my daily work.

In ABAP I have accumulated some tips to efficiently deal with error message raised by leveraging all kinds of tools.

• Six kinds of debugging tips to find the source code where the message is raised
• How to quickly locate the code where the error message is raised for Business Transaction Application
• Three ways to achieve conditional break point in your ABAP program
• A real example: how to leverage ABAP breakpoint with type “Exception”
• How to efficiently find the code position where settype table COMM_PRMAT is accessed without debugging
• Do SAT trace on applications which could not be launched by SAT

Welcome to also list your favorite trouble shooting tips which are not mentioned so far.

要获取更多Jerry的原创文章，请关注公众号"汪子熙":