• an SAP TM Developer or Consultant.
• familiar with the ABAP programming language, BOPF framework.

You have already

• faced the difficulties of GUIDs, determination/validation cycles.
• debugged TM ABAP code.
• got lost in the call stack / complexity of a debugger session.

You would like to understand

• which BOPF action is responsible for setting a certain field?
• how does the TM application work within the BOPF framework?
• what is the actual execution sequence of actions and determinations?

Introduction

In this blog post I would like to show you how I use the following tools in SAP TM maintenance:

• Notepad++:                     to deal with GUIDs.
• Change Documents:      to investigate the crime scene.
• TM BOPF Navigator:     for free style search, navigation, and where-used-list of BOPF objects.
• Debugger script /SCMTMS/DS_TRACE: to quickly identify, which code is responsible for certain changes, and to visualize the program flow.

Disclaimer:

Debugger script /SCMTMS/DS_TRACE was written as an internal support tool. Though officially not supported, any feedback is highly appreciated and will be considered. Please be aware that certain gaps, features, fixes to bugs – that would absolutely make sense – may never be implemented.

Notepad++

As a complementary tool, I use application Notepad++ from https://notepad-plus-plus.org/ to find identical GUIDs with a double click:

Figure 1: Notepad++ * Click to enlarge *

In this screenshot, you can see the data I have copied from database tables and double clicked on one of the ROOT GUID. When working in a debugger session, I regularly copy the content of internal tables into Notepad++ and use this feature to quickly identify TOR documents with PARENT_KEY or item hierarchy with ITEM_PARENT_KEY, for example

Change Documents

Whenever someone asks: “This field value was changed, why?”, your first task is to identify when it has happened. So that we could identify the exact process as a first step to provide a step-by-step reproduction.

This can be identified from the “Change Documents” tab, Transaction Code:

Figure 2: Change Documents * Click to enlarge *

As column “Transaction Code” is hidden by default, you will need to add it to the displayed columns. In this screenshot, I have also replaced the description columns with “Node” and “Field Name”, as for me, the technical names are more informative.

Now, what corrections are needed and how can the values under “Transaction Code” be interpreted?
Consulting note #2951038 -How to use Change Documents, field Transaction Code
describes possible values and the existing correction notes.

On the screenshot under column Transaction Code, value /SCMTMS/FRE_ORDER means, that the change was done on the Freight Order maintenance WebDynpro application. Value /SCMTMS/FWD_ORDER means the Forwarding Order maintenance WebDynpro application.

Sometimes it is not that easy to identify the origin of a Transaction Code even with the help of consulting note #2951038. Maybe a prefix character could be added to quickly identify the source, in this example “Web Dynpro Application”. What do you think? Can you use “Transaction Code” on the “Change Documents” tab “as is” or would you welcome a prefix character? Please share your opinion in the comment section of this blog!

TM BOPF Navigator

Start TM BOPF Navigator with transaction code /SCMTMS/BONAV.
This is what I would call a fine tool, as it does not need any documentation.
Enter any search term and explore the functionality yourself!

I frequently use it to

• navigate with a double click into ABAP source code directly after vaguely remembering an action name.
• discover the usage of actions via “Where-Used” List

Figure 3: TM BOPF Navigator * Click to enlarge *

Please share your improvement ideas for this tool in the comment section, let’s make this even better together!

The latest correction was delivered in the following correction note:
#3234950 – Technical correction, TM BOBF Navigator 3.

Debugger Script /SCMTMS/DS_TRACE

Some thoughts on debugger scripts if you have not used them before. It can be used to automate what you can also do manually in a debugger session. Here is a blog post how it works: https://blogs.sap.com/2010/12/14/abap-debugger-scripting-basics/

You do need a debugger session to be able to execute a debugger script. It means, that you cannot use it to investigate a “not reproducible issue”. It can also not be used for example to trace all users in the background.

It can be used in the following situations/cases:

• A reproducible example is available.
• It is known at which interaction step the issue occurs.
• It can be used to trace a single interaction step.

Selecting “Start New Trace” in transaction /SCMTMS/DS_TRACE creates a breakpoint in the WebDynpro framework. When you execute the step that you would like to trace in the TM application, the breakpoint will start a debugger session. Then you can load and start the debugger script to trace the execution of that interaction step.

Why was it important to understand the technical background? Because this breakpoint may also start the debugger for other reasons:  For example, a “Proposal Search” aka “Type-ahead Search”, that is being executed as you type, may involuntarily start the debugger session. Be mindful and exit the debugger if it was accidentally started for a “Proposal Search”!

Now let me show you the use of debugger script /SCMTMS/DS_TRACE.

The STORY is a mystery to be solved:

There is a freight order having a “Proof of delivery” execution event already reported.
After reporting the “Arrival at destination” event, “Proof of delivery” event was deleted:

Figure 4: Freight document, Execution events tab

Let’s find out together why this has happened!

• Prepare a freight order with a “Proof of delivery” execution event.
  Enter “Arrival at destination” event (do not save it yet).
• In an SAPGUI session start transaction /SCMTMS/DS_TRACE.
  Select button “Start New Trace”. Enter a trace name, Continue.

Figure 5: Transaction /SCMTMS/DS_TRACE, start new trace

• When the next window is displayed, a breakpoint was set in the WebDynpro framework so that a debugger session could be started. Switch back to the freight order screen now!

Figure 6: Transaction /SCMTMS/DS_TRACE, take the trace now

• Select “Save” in the freight order. This is the interaction step that we shall trace with debugger script /SCMTMS/DS_TRACE.
  Remember: “Proof of Delivery” event was already saved on the document, we have entered now an “Arrival at Destination” event and shall check what happens during save.

Figure 7: Freight document, Execution events tab before save * Click to enlarge *

• A debugger session is started automatically. In the debugger session select tab “Script”, load and start script /SCMTMS/DS_TRACE.

Figure 8: Debugger session, load and start script /SCMTMS/DS_TRACE * Click to enlarge *

• The debugger script is expected to run silently. It is expected that the freight order session is returned with a saved freight order. The “Proof of delivery” event was deleted:

Figure 9: Freight document, Execution events tab after save

• Switch back to the SAPGUI session, select “Continue” to close the last window. The trace file is displayed in the file list.

Figure 10: Transaction /SCMTMS/DS_TRACE, trace file

It is time for the analysis of the trace file!

• Open the file and select tab “Modifications” to show the modifications of the document(s). Column “Change” shows, that only changes occurred for the events (no delete/insert). Double-clicking on one of the modifications reveals that field EVENT_REVOKED was updated.
• Using the free style search, we mark all modifications that have updated field EVENT_REVOKED.

Figure 11: Transaction /SCMTMS/DS_TRACE, Modifications tab * Click to enlarge *

From the “Modifications” tab, we have learned that the “Proof of Delivery” event was not deleted but revoked. Where did it happen?

• Select tab “Hierarchy” to show the executed actions/determinations. The search is still active for field EVENT_REVOKED, so it shows the same modifications as on the “Modifications” tab, but also displays the action that has created them.It shows that action TOR-EXECUTIONINFORMATION-REVOKE_EVENT has created these modifications that revoked the “Proof of Delivery” event.

Figure 12: Transaction /SCMTMS/DS_TRACE, Hierarchy tab * Click to enlarge *

Now we know, which action was responsible for this change.
Lastly, we would like to identify when this action was called.

• Select tab ‘Time Stream’ to show the trace data in the execution time sequence. The hierarchy displayed is the call hierarchy (like “ABAP Call Stack” in a debugger session): The parent level executes the actions/determinations of the child level.On the screenshot the red arrows show the call stack / execution hierarchy of action REVOKE_EVENT.

Figure 13: Transaction /SCMTMS/DS_TRACE, Time Stream tab * Click to enlarge *

What has happened?

• Seq 3  Action REPORT_EVENT has created the “Arrival at destination” event.
• Seq 6  Determination DET_EXEC_AM has started processing event modifications (in this case the event creation of “Arrival at destination” event).
• Seq 11 and 21  Freight order stops and items were updated with handling statuses (in response to the new event). This led to the removal (EVENT_REVOKED = X) of the “Proof of Delivery” event at Seq 22.

Now we know that the “Proof of Delivery” event was revoked based on an item level handling status change.

• The following screenshot shows the changes of the stop / item handling statuses:

Figure 14: Transaction /SCMTMS/DS_TRACE, Time Stream tab * Click to enlarge *

We can see that Handling Execution Status on Item Level (TOR-ITEM_TR-HANDLING_EXEC) was set to value 04 – Not Unloaded. Meaning, that if the item is “Not Unloaded”, the Document cannot have a “Proof of Delivery”, thus the event was revoked!

Concluding Remarks

As we saw, there is not only a debugger script to create a trace file, but also a powerful visualization and navigation transaction for the analysis of the trace files.

I hope you have enjoyed following this example!

I encourage you to further discover both the tool and its other powerful features:

• Read the built-in “How to Guide” and “Good to Know” for more information.
• Use the “Where-used-List” and “BOBF”, jump into the source code via double click.
• Discover even more data and functions by double-clicking on the trace lines.

The latest correction of the tool was delivered in SAP Note: #3281444 – Technical correction, Debugger Script: TM generic 3.

Last, but not least: With the latest corrections, we have new options for “Start New Trace” to avoid a timeout of the debugger session:

Figure 15: Transaction /SCMTMS/DS_TRACE, new options on Start New Trace window

Both “Simple trace” and “Forced trace write” are empty by default and can be set to X.

• “Simple trace”:
  When too much data is processed, the debugger script slows down the processing so much, that the debugging session times out. Set “Simple trace” to X to avoid this time out. The trace file shall contain less data, but at least it does finish.
• “Forced trace write”:
  The other solution to avoid time outs was to write the trace file only once at the end of the processing. It works most of the time. However, when it misses writing the trace file, then there is no trace file at all!
  Thus we needed the second parameter “Forced trace write” to fall back to regularly write out the trace file. Setting it to ‘X’ means, that you will always have the trace file with the time-out handicap in case of too much data is processed.