- SAP Managed Tags:
Only an ABAP consultant knows his/her lethal friendship with debugging, not lifelong but truly "a career-long friendship".
This blog is result of my students, freshers asking the following questions:
Numerous Questions isn't it? And answer is "Approach"
Below are the different scenarios and the approach of debugging.
Before jumping to scenario, we should learn to distinguish type of issues we've got to knock out. As this only will help in defining the best approach to fix the same in minimum possible time.
Issues/Incidents in ABAP support projects can be of following types:
Type or Scenario 1:
Report failing with dump or IDoc failed to process with an error message
Such type of issues are called, close ended issues, because we know the line/position where the report program is failing.
Approach:
Open ST22 (if dump)-> Navigate to the respective line, triggering error. Now comes the approach.
If code is failing at any line, obviously it was not supposed to come here means, it has missed the correct path back, which would have lead it to success.
Lets have an example, If you started from your home (source) for the office (destination, here in ABAP Success message), but somehow missed the correct path and reached to some other place (in ABAP context error message).
Bottom line here is, not the whole path that you took was wrong, but while the journey there must be a point bifurcated (one success other failure), and we took the wrong one.
Now, in order to fix the issue or reach to office, all we need to do is, to find the point where we went wrong.
Now come back to debugging session, here Standard tab is nothing but the path that our program followed to reach to error (below image). Double click on each predecessor (right hand side in the below image 2nd quadrant, a numbered stack can be seen). Here 25 point is what that throwing error or dump, then start your analysis and trace back which wrong entry lead this to point no. 25.
Suppose you checked point 24 and found all entries/conditions are true or as per expectation, go back to 23.
Trick: Ask functional folk to share a good case, debug it, check the path (Standard Tab) followed by that and compare the same with the error file. This will help a great deal in identifying the correct spot which has further lead to error.
Scenario 2:
Process completed successfully but with wrong field/table values/entries
These are open ended issues, where exact spot/point is not known where things went wrong.
Approach:
This section will answer, when to do F5 and F6, also helpful while debugging standard report.
Get into debug mode, type or select the field, which populated with incorrect value. Start doing F6, keep skipping blocks/modules/sub routines keeping an hawk eye on the field value.
Note: If system allows to set a watch-point, then that's the best way to go with, as the same will directly yield the point/spot, we're looking for.
While doing the F6 process, we're actually narrowing down our area of analysis, this is also know as narrow down approach.
The module/block which changes the field value or populating the incorrect value, is the point from where F5 will come into picture, (note down the module name or block where change happened, set the break point and restart the analysis) means now we start doing F5 traversing through each line of code and figure out the correct spot to know the root cause.
Scenario 3:
System taking more time to finish the Job than expected
These are not errors or dumps rather kind of analysis needed, to check why the same report taking more time than what it was consuming earlier.
Approach:
First thing, ask for the time from when system started showing this unusual behavior, check for the latest changes made if any in the program and examine the respective block of code.
Ask basis team to perform SQL Analysis (open shared document in HTML format if contents are not organized), something in below fashion would appear. Check the SQL syntax corresponding to the maximum time, look if any modification can be made like sorting, binary search, more filters can be given and what not.
HH:MM:SS.MS — Time when the process was executed
Duration — Duration of the Process
Program — Name of the ABAP program
ObjectName — Name of the affected table
Op. — Database operation performed
Curs — Cursor used
Array — Number of records that can be transferred in one step from the database
Recs — Number of records that were read or sent to the database
RC — Return code from the database
Conn — Name of the database connection
Statement — Statement Processed at the database
Sometimes the line which indicates the duration of the operation is shaded in red, which means that the duration time exceeds 100 ms. Here, this doesn't necessarily mean there is a performance problem, as we always have to take the number of processed records into consideration for context. For example, reading 500 records in 100 ms is a good result, but reading only 5 records in 80 ms is not very good.
Above are the frequent issues assigned to a technical folk to debug and later fix.
If there is any other type of issue/errors you are coming across, do share in comment section, will try to add that as well in this blog. Again, this blog is mainly for beginners who starting their career as SAP ABAP Consultant.
This blog is result of my students, freshers asking the following questions:
- Why the same report debug and fix, took them long hours whereas same is done in minutes by the seniors
- How they know, which module to get into i.e. doing F5 and which to be skipped i.e. F6, while debugging
- Why there is sense of 'diving down into the deep ocean', when we get into debug mode
Numerous Questions isn't it? And answer is "Approach"
Below are the different scenarios and the approach of debugging.
Before jumping to scenario, we should learn to distinguish type of issues we've got to knock out. As this only will help in defining the best approach to fix the same in minimum possible time.
Issues/Incidents in ABAP support projects can be of following types:
Type or Scenario 1:
Report failing with dump or IDoc failed to process with an error message
Such type of issues are called, close ended issues, because we know the line/position where the report program is failing.
Approach:
Open ST22 (if dump)-> Navigate to the respective line, triggering error. Now comes the approach.
If code is failing at any line, obviously it was not supposed to come here means, it has missed the correct path back, which would have lead it to success.
Lets have an example, If you started from your home (source) for the office (destination, here in ABAP Success message), but somehow missed the correct path and reached to some other place (in ABAP context error message).
Bottom line here is, not the whole path that you took was wrong, but while the journey there must be a point bifurcated (one success other failure), and we took the wrong one.
Now, in order to fix the issue or reach to office, all we need to do is, to find the point where we went wrong.
Now come back to debugging session, here Standard tab is nothing but the path that our program followed to reach to error (below image). Double click on each predecessor (right hand side in the below image 2nd quadrant, a numbered stack can be seen). Here 25 point is what that throwing error or dump, then start your analysis and trace back which wrong entry lead this to point no. 25.
Suppose you checked point 24 and found all entries/conditions are true or as per expectation, go back to 23.
Trick: Ask functional folk to share a good case, debug it, check the path (Standard Tab) followed by that and compare the same with the error file. This will help a great deal in identifying the correct spot which has further lead to error.
Scenario 2:
Process completed successfully but with wrong field/table values/entries
These are open ended issues, where exact spot/point is not known where things went wrong.
Approach:
This section will answer, when to do F5 and F6, also helpful while debugging standard report.
Get into debug mode, type or select the field, which populated with incorrect value. Start doing F6, keep skipping blocks/modules/sub routines keeping an hawk eye on the field value.
Note: If system allows to set a watch-point, then that's the best way to go with, as the same will directly yield the point/spot, we're looking for.
While doing the F6 process, we're actually narrowing down our area of analysis, this is also know as narrow down approach.
The module/block which changes the field value or populating the incorrect value, is the point from where F5 will come into picture, (note down the module name or block where change happened, set the break point and restart the analysis) means now we start doing F5 traversing through each line of code and figure out the correct spot to know the root cause.
Scenario 3:
System taking more time to finish the Job than expected
These are not errors or dumps rather kind of analysis needed, to check why the same report taking more time than what it was consuming earlier.
Approach:
First thing, ask for the time from when system started showing this unusual behavior, check for the latest changes made if any in the program and examine the respective block of code.
Ask basis team to perform SQL Analysis (open shared document in HTML format if contents are not organized), something in below fashion would appear. Check the SQL syntax corresponding to the maximum time, look if any modification can be made like sorting, binary search, more filters can be given and what not.
HH:MM:SS.MS — Time when the process was executed
Duration — Duration of the Process
Program — Name of the ABAP program
ObjectName — Name of the affected table
Op. — Database operation performed
Curs — Cursor used
Array — Number of records that can be transferred in one step from the database
Recs — Number of records that were read or sent to the database
RC — Return code from the database
Conn — Name of the database connection
Statement — Statement Processed at the database
Sometimes the line which indicates the duration of the operation is shaded in red, which means that the duration time exceeds 100 ms. Here, this doesn't necessarily mean there is a performance problem, as we always have to take the number of processed records into consideration for context. For example, reading 500 records in 100 ms is a good result, but reading only 5 records in 80 ms is not very good.
Above are the frequent issues assigned to a technical folk to debug and later fix.
If there is any other type of issue/errors you are coming across, do share in comment section, will try to add that as well in this blog. Again, this blog is mainly for beginners who starting their career as SAP ABAP Consultant.
1 Comment
