Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at [email protected].
Why Use SAP Tools for Quality and Performance
ABAP is a powerful language for building sophisticated applications. But as any developer understands, even the most carefully written and tested objects can wind up terminating with a runtime error, producing unexpected messages, returning incorrect results, or causing application performance problems. As a result, SAP provides a comprehensive set of specialized tools for performing static code checks, coverage analysis, post-mortem analysis, runtime traces, and debugging as part of the standard delivery of SAP Web Application Server (Web AS).
A Systematic Approach to Testing ABAP Objects
Let’s assume that you have already removed all syntax errors from your SAP ABAP Program, so you can at least activate and execute it. However, you still cannot be sure that the program will not produce a runtime error or that the program will deliver the intended results. What are the next steps? What tools are available for further source code checks and runtime testing to validate the runtime behavior of the program?
This is the goal of this blog series. We will look at each available tool (Static and Run-time) and over the course of this Blog series, distill the building blocks of a comprehensive and successful test strategy that minimizes the risk of unexpected errors. Combining static and runtime checks is a powerful approach to ensuring reliable code. OK, we have our objective, lets get to it!
Tools for Performing Static Checks
Of course, the best troubleshooting tool is prevention. Remove as many potential sources of runtime errors as possible by performing static code checks during development. In addition to the standard syntax check, SAP provides more sophisticated static checks for evaluating performance and verifying the consistency.
You can call these tools as standalone transactions to check a specific program or a complex object set of your choice (Code Inspector will be discussed in the next Blog). They are also integrated into the ABAP Workbench so you can execute them directly on the program that you are editing. Let’s review how the extended program check can support your overall testing approach.
Executing the Extended Program Check
After making sure that a program is free of syntax errors (and, ideally, free of syntax warnings, which could indicate runtime problems), your next step should always be to run the extended program check — at least after any major code modifications or additions. The extended program check contains many static code checks that verify the consistent use of form and function interfaces, proper calls to external programs, field attributes, and more.
You can execute the extended program check on a main program at any time. Call transaction SLIN, enter the program name, and select the checks to be performed (see below). To see a detailed explanation for any check, mark the name of the check and press F1. You can also call the extended program check from the ABAP Workbench when you are editing a program in the ABAP Editor, Function Builder, or Class Builder.
The result of an extended program check (see below) is a summary of errors, warnings, and messages for each check category. By double-clicking on any line you can display a detailed list of identified issues, including source code positions. From there, you can navigate directly to the source code display in the ABAP Editor and correct the code as necessary. After correcting the code, please rerun the extended program check to test your corrections, continuing this iterative cycle until no errors remain.
Please at least try and always examine and correct all the errors found by the extended program check, because they are quite likely to result in runtime errors (such as a type mismatch when calling a function module). That said, not every error, warning, or message indicates code that needs to be corrected. Because SAP is aware of this, developers can easily exclude the source of a error, warning, or message from a check by adding a special comment to the relevant program line. For example, to exclude a program line from the ASCII/EBCDIC portability check, you would add the comment “#EC PORTABLE.
If a message can be suppressed by such a special comment, the message details (accessed by double-clicking on the message line) will contain the comment you could use to suppress it. Comments for every message appear in the results display of transaction SLIN. (see below)
OK, now lets get this straight…. PLEASE use special comments judiciously. Using too many increases the risk of true sources of runtime errors slipping through and remaining unresolved.
Summary and what’s next…
We learned that while all developers, OK most developers, have the best of intentions… there are supplied SAP Tools they can use to further the quality of the code being delivered. One such tool, the Extended Program Check, can help us identify some coding errors and potential run-time problems. We should execute this STATIC Check during the development phase in our newly forming framework of our Life Cycle of ABAP Development and Test Strategy. It’s also a good idea to run the extended program check on your programs regularly (such as before releasing a major new version of your program).
Now there are some limitations we need to highlight…
Although the extended program check is useful for checking your code on a program-by-program basis, checking many programs with this tool would be very tedious. You would have to execute the extended program check separately for each program, and you would have no collected display of the test results. Let’s assume that you want to check a complete package of all your own programs. Perhaps you want to repeat this check regularly to control the quality of your code over time. Let’s also say that you want to perform additional static checks (performance checks, security checks, and search functions, for example) that are not part of the extended program check. How can we do this?
Well, with Web AS 6.10, SAP provides the Code Inspector (transaction SCI) as a framework for defining and executing elaborate static test suites on object sets of your choice. This will be the topic of discussion in our next Blog.
