How to investigate the runtime error „MESSAGE_TYPE_X“ in SAP TM; sub-post 3

[stefan_foerster]

This is the third sub-post of a series, which outlines how to investigate a particular example/pattern of system dump caused by a programmming error.

Here it is about an incorrect call of BOPF methods from a custom enhancement:

• A custom action modifies a node, which is not configured „for update“ and hence was not locked at runtime by application, but is locked when BOPF tries to update

Read first the introduction and general information in the main-post.

As described in the main-post, the information you get from the system dump in ST22 does not help you to identify the root cause, hence you like to debug it.

The system dump looks similar to the ones from the screenshots in the main post and in sub-post 1 and 2.

... except in the call stack you see it is coming from an „end_modify“

This time the application information is completely empty.

This is one of the tricky ones, but it occurs quite often...

Usually users cannot reproduce the system dump or it even happens in batch mode. (It happens actually „by chance“, because someone else or another batch process has locked the object in parallel. But this is still an error of the enhancement.)

Shortcut:

There is a dump „message_type_x“ and nobody has a clue what the root cause could be and there is no info given in the system dump and you don‘t like to go through those steps of debugging, OK, then go to the /BOBF/CONF_UI transaction and click through all the actions of all the enhancements of the BO of concern (mentioned in the dump) and check whether there is an action, which did not declare any update node. 80% of the root causes could have been found this way (faster than debugging).

• In /BOBF/CONF_UI expand the BO for that the dump is triggered so that you see all the enhancements.
• For every enhancement (doubleclick to open) go through all node elements and look for an action, double click it and check whether there are write nodes declared for it. You certainly start with root node and item node.

The debug-way:

Here comes the hard way, in case the shortcut does not help or is not yours because you are the debugging one.

Unfortunately it is essential that the user knows which UI was used and which steps were done OR that you know which batch job to re-run, e.g. /SCMTMS/PROCESS_TRIGGER_BGD . (=> <steps>)

If you don‘t know any <steps>, then you can exit here.

Remember or find this guide and then assume: „Maybe there is a custom enhancement, which changes data, which are not locked explicitely.“

Try to reproduce the system dump systematically as follows.

Note: There are 2 main patterns:

a) Usually there is a cross BO change – so the user (or the batch job) edits one BO instance and the enhancement shall update an instance of a different BO...

b) The user (or the batch job) edits a BO instance and the enhancement changes a node that the standard application does not know (custom node) or does not lock per se.

For b) the node key should be detectable in the system dump. See the main-post on how to search for it. I continue here for a) ...

• In case the user can provide the Number (ID) of the document, good. Otherwise take any document of the BO, which is mentioned in the system dump.
• Open the document of concern and navigate from the document flow to all possible instances of a cross BO association. Go into EDIT mode in all of those newly opened windows.
• Now go into EDIT mode also for the document of concern. In case you get a message that something is locked (e.g. FWO also locks FU-TOR), then close the other window, which holds the lock. Repeat until you are in edit mode finally successfully.
• Now do the <steps> and most often you need to save.
• The system should dump now, otherwise most probably the root cause is not the here assumed missed write node declaration.
• Let‘s assume you can reproduce the system dump and start investigation of root cause via debugging...

• You could also activate the checkpoint group /bobf/frw to break for debugging at foreseen places. But in TM unfortunately it breaks too often in RBAs (retrieve by associations), hence it is usually not used. But if you use it and skip all the RBA breaks you would finally find this code place here too:

• Set a breakpoint in method „DO_MODIFY“ of class „/BOBF/CL_FRW “, at statements like „ASSERT ID /bobf/frw CONDITION 0 = 1. “ – e.g. line 520

• Restart the reproducable example and you actually should get now a debugger window...

• From the lt_failed table – fields node & key – you learn which BO node and which instance is causing it. While the instance key should be no suprise to you as you managed to lock it in a parallel session before, you now know at least which node should have been declared as write node by the enhancement action and you could reconsider the shortcut.
• Because now it could become ugly. You need to find out, which action is „responsible“. Usually the lock issue itself seems to be caused by a determination / validation, but in reality actually an action caused the det./val. to run...
• Start searching for the initial action through debugging in lower call stacks.
• Let‘s assume here a simple case. Go down the call stack until you see the „do_action“ method. Go in there and check out the variable IS_ACTION-ACT_KEY...

• With the action key you go as usual in the /bobf/conf_ui and do a search and .... BINGO !  ==> you found the action, which should have declared a write node...

===========================================================

All posts of this series:

General info and steps in the main-post.

Sub-posts: 

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

===========================================================