Problem Description
Very often we are confronted with the following cryptic display in the browser.
The "500" indicates that it is an HTTP return code of 500, which is the catchall for every unspecified error-like. Usually the first thing to check is transaction ST22. But a short dump was seldom written.
(The careful reader is asked to please excuse the text in German. Problems tend to arrive in all languages, so we are slightly immune to this. And for some strange reason, our development systems all only speak German.)
What Causes This Problem?
In short, it is the output of the MESSAGE statement that is written to the browser. Many years ago, when the earth was still standing on its feet, and SAP GUI was the only kid on the block, these messages meant that some output is written inside the SAP GUI. Typical example would be the status message written at the bottom of the SAP GUI screen.
However, for BSP applications, no SAP GUI is available. Some types of messages are considered not important, and are silently ignored. Other messages result in exactly the above output. Effectively, an HTTP request is processed in a dark DYNP, and after the MESSAGE statement, the processing is stopped, and the text is converted into a small HTML page.
The table below gives an overview of the different message types and their behaviour, both in SAP GUI, and in BSP
| Message Type | Message Name | SAP GUI Example | BSP Behaviour |
| A | Abort |  | HTTP rc=500 |
| E | Error |  | HTTP rc=500 |
| I | Information |  | Silently Ignored |
| S | Status |  | Silently Ignored |
| W | Warning |  | Silently Ignored |
| X | Exit (see transaction ST22) |  | HTTP rc=500 |
The MESSAGE statement will (obviously?) never be used inside a BSP application. However, quite often BSP applications call function modules, and these modules have a nasty habit of giving visual feedback via MESSAGE statements. Often, these function module calls are layered very deep, and it is not clear where the MESSAGE statement comes from.
Finding a MESSAGE Statement
Once the problem and the cause are understood, one is still slightly frustrated. The message statement per se, and therefore the BSP equivalent output, does not give an answer as to the position of the MESSAGE statement. (One exception is the type X message, which writes a dump. In transaction ST22 all relevant information can be seen, including location of MESSAGE statement.)
The problem is that once the MESSAGE statement of type A, E or X is executed, processing of the ABAP code is stopped, and control returns to the kernel (where the error message is written into the HTTP response). The solution is to stop in the debugger before the MESSAGE statement is executed.
As a first step, set a breakpoint in the BSP application. Once stopped in the debugger, use the menu entry "Breakpoints" and then "Break At Statement…". For the statement, specify "MESSAGE".
With this, breakpoints will be set at all MESSAGE statements. Let the program execute, and check each breakpoint to see if it is a message of type A or E. (Of course messages of type X are just as interesting. However, a dump is written for them in st22, and they can be localized very easily.)
With one small trick, each developer "skilled in the art of debugging" can track the problem message shown in the browser back to the ABAP source. In nearly all cases, our experience has been that these MESSAGE statements are deep inside a (call hierarchy of) function module(s).
Are all existing function modules unusable with this?
Calling Function Modules Without Causing MESSAGE Problems
It is possible to prevent MESSAGE statements from causing an immediate abort of execution in BSP context. This is done by requesting that the called function module will return an indicator of the MESSAGE situation via a sy-subrc error code. Important: this feature is only available for CALL FUNCTION sequence. The user is referred to the official ABAP documentation for the gory details.
A typical example would be:
CALL FUNCTION 'SOME_FUNCTION'
EXPORTING …TABLES …
EXCEPTIONS … = …
ERROR_MESSAGE = 98
OTHERS = 99.
The ERROR_MESSAGE exception is predefined (same as OTHERS), and indicates that when a type A or E message is seen, that the execution of the function is stopped, and the function will return with sy-subrc set to the specified value. No MESSAGE is written. The BSP application will not be terminated, and the program can do the error handling itself. Important: Do not forget to check and handle the sy-subrc! Messages of type X cannot be prevented. They crash and burn.
The interesting part about this EXCEPTION handling for functions is, that it is inherited over a complete call chain of function modules. So it is only necessary to activate the EXCEPTION catching for the top/main function that is called from the BSP page. It is not necessary to change the source of all other functions!
What Is New on the Turnpike?
"Turnpike" is definitely not in the Queen's dictionary! Germanised, it would mean Autobahn. For our non-stateside (non-USA!) readers the question can be translated to "What is new in 6.40?"
The actual complaint that triggered all of this, is the fact that no information is available in the browser to localize the error. (Where 'error' is used very liberally here.) The fact is that if the display in the browser showed the source of the problem, one would not have been sitting in the dark.
While writing this text, I stumbled across a very subtle change in 640. Can you spot the difference?
Someone down in the basement has just been added to my hero list!
Sidebar: How To Test for HTTP Request
Sometimes it would be interesting to have new DynPro based code that can run both in context of the SAP GUI, and also in context of HTTP requests (example in BSP environment). Typically, in SAP GUI, such coding can use popup windows to present additional information to the user.
This can be tested with the function module ICF_IS_PLUGIN_SESSION. It will return a flag to indicate whether we are running inside an HTTP request context or not.
Acknowledgements
At SAP it is not a question of who you are, but more of whom you know. In my opinion, it is much more a question of who is your "teacher"! And in this case, I can only pay tribute to Rüdiger, who wrote the book, and to Holger, who blows my mind time and again with his ABAP knowledge!