Supply Chain Management Blogs by SAP
Expand your SAP SCM knowledge and stay informed about supply chain management technology and solutions with blog posts by SAP. Follow and stay connected.
Showing results for 
Search instead for 
Did you mean: 

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:

  1. Simple but not obvious error in a custom enhancement
  2. Custom enhancement calls BOPF methods incorrectly
  3. Custom enhancement calls BOPF methods incorrectly

Other often seen root causes (and not yet described)

  • duplicate keys in modify
  • Using a BO key as an Instance key or vice versa
  • Exceptions not propagated or catched (CX_SY_NO_HANDLER)
  • ...

Basic information and general steps

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 analysisit sayssee application info“.

In the sectionApplication 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:

  1. Simple but not obvious error in a custom enhancement
  2. Custom enhancement calls BOPF methods incorrectly
  3. Custom enhencement calls incompletely configured BOPF action