CODEWITHSUNDEEP
abapcall-graphbapifunction-module
Suncatcher
Suncatcher

Reputation: 10621

How to build a call graph for a function module?

A while ago during documenting legacy code I found out there is a tool for displaying call graph (call stack) of any standard program. Absurdly I wasn't aware of this tool for years :D

enter image description here

It gives fancy list/hierarchy of calls of the program, though it is not a call graph in a full sense, it is very helpful in some cases.

enter image description here

The problem is this tool is linked only to SE93 so it can be used only for transactions. I tried to search but didn't find any similar tool for reports or function modules. Yes, I can create a tcode for report, but for function module this approach doesn't work.

If I put FM call inside report and build a graph using this tool, it wraps this call as a single unit and does not analyze deeper. And that's it

enter image description here

Anybody knows a workaround how we can build graph for smth besides transaction?

Upvotes: 3

Views: 718

Answers (2)

Sandra Rossi
Sandra Rossi

Reputation: 13628

The call hierarchy displays also works for programs and function modules.

In my S/4HANA system, for VA01, it displays: enter image description here

Clicking the hierarchy of function module CJWI_INIT displays: enter image description here

I get exactly the same result by calling the function module RS_CALL_HIERARCHY this way: enter image description here

The parameter OBJECT_TYPE may have these values:

  • P : program
  • FF : function module

The "call graph" is not maintained anymore since at least Basis 4.6, and it doesn't work for classes and methods.

But the tool is buggy: in some cases, a function module containing a PERFORM at the first line, it may not be displayed, whatever the call graph is launched from SE93 or directly from RS_CALL_HIERARCHY.

Upvotes: 1

phil soady
phil soady

Reputation: 11308

The cynic in me thinks RS_CALL_HIERARCHY was left to rot. Sandra is right, it definitely used to work. Once OO came to abap, interfaces and dynamic/generic code became possible. So a call heirarchy based on static code analysis was pushing proverbial up hill.

IMO the best way to solve this is a FULL trace and then to extract the data from the trace. There are even external tool that do that. This is of course, still limited as running a trace on every execution path can be very time consuming. Did I hear someone say small Classes please ?

Trans SAT. Make sure teh profile you use isnt aggregating, and measure the blocks you are interested.

Trace profile Make sure the profile isnt aggregating calls And set to measure the relevant callable blocks

Now wade you way through the trace. https://help.sap.com/doc/saphelp_ewm93/9.3/en-US/4e/c3e66b6e391014adc9fffe4e204223/content.htm?no_cache=true

Have fun :)

Upvotes: 3

Related Questions