This "How-To" is intended to guide consultants (that know how to debug in TM) and developers on how to investigate one famous runtime error in SAP TM:
The basic motivation of this post is to reduce number of OSS tickets, messages, service requests, incidents, name it... , which are submitted by consultants or developers, who are onsite at customers, but which could be avoided if an educated investigation resulted in the conclusion that a customer enhancement caused this system dump. Maybe this guide also prevents (as a side-effect) developers from doing those preferred programming errors...
Disclaimer: I certainly know that there are many knowledgeable people out there that know even better than it could be documented here and as usual there's more than one way to skin a cat....
In this post I summarize basic information and general steps, which always apply.
In a series of sub-posts specific error patterns are identified.
The following examples are described via screenshots in the linked sub-posts:
Other often seen root causes (and not yet described)
The user receives an error screen. The details provided and the call hierarchy do not help to identify a root cause.
Example: User clicks on save in the FWO UI.
Here a first indication is that a determination caused the error.
The runtime error in ST22 „MESSAGE_TYPE_X“ tells you that this system dump was enforced by the application and most often it indicates the BO for that the determination was executed.
Actually not the application "TM" enforced the system dump, but the BOPF framework decided to do so...
Also the call stack and the code snippet does not tell anything...
The runtime error in ST22 „MESSAGE_TYPE_X“ sometimes also gives more information, which could help. Sometimes reading it carefully could bring you one step further ...
In the section „Error analysis“ it says „see application info“.
In the section „Application Information“ the system actually already tells you the node of the BO and here also class and method and also the root cause might be given, which is usually not the case though.
This is a simple example.
If the application information section is not available in ST22, one of the following notes might be missing n the system: 1770790, 1576400, 1664839
Update: BOPF colleagues provided note 1981590, which enhances the application info for certain cases.
Sometimes you can do a search in the dump for one of the following variables and gain some more insights:
LV_PRE_PREV_PROGNAME, LV_PRE_PREV_INCLNAME => could tell you the "previous" program, which casued the issue
NODE_KEY => any kind of such variable, with different prefixes, tells you the BO node of concern
ACT_KEY => any kind of such variable, with different prefixes, tells you the BO action, which causes the issue
<LV_KEY>, LV_KEY, LS_KEY-KEY => may tell you the instance of the BO => do a search in a /SCMTMS/D_<BO>ROT table
Except for the before mentioned instance key, copy the UID and do a search in the /BOBF/CONF_UI transaction.
Experts tip: Being in the debugger you can gain context insights from cl_frw_int_access->ms_determination, action etc.
===========================================================
All sub-posts of this series:
===========================================================
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
11 | |
11 | |
5 | |
4 | |
3 | |
3 | |
2 | |
2 | |
2 | |
1 |