Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Why so many FM's without Function Module Documentation?

Former Member
0 Likes
802

I'm fairly new to SAP ABAP and learning there are many function modules provided by SAP which are very helpful.  However, I am very dismayed that I'm finding so many without basic information about what they do and how to use them.  If SAP has gone to the trouble of developing and testing them, can't they spend the extra few minutes letting us know the purpose and results?

Case in point:  I'm looking for a function module that will tell me the result of a workflow/work item decision step.  Did the approver approve, reject, or did something else happen which caused the workflow to terminate?  I need to access that information to accurately display a workflow's history and current status.  I am using Google and finding many FM's that *may* provide what I want (based on their FM Name), but the only way to find out what an undocumented FM might provide is to run it and look at the output.  That seems a terrific waste of time (because I have to run all the different scenarios and compare the output to see if I can use the results), especially when I'm expected to provide quick solutions.  A 30 minute task can change to a half day because I'm trying FM's that end up being dead ends because they don't provide the information I need.

If anyone has any recommendations for me on how I can more efficiently discover which FM's might be useful to me, I'll be very appreciative.  Thank you.

1 ACCEPTED SOLUTION
Read only

matt
Active Contributor
0 Likes
753

Generally speaking, if a function module or class isn't documented, it's "use at your own risk". It isn't released to customers.

So you have to try various ones until you find the right one. Of course, you can use other people's expertise, as the most commonly used FM are well known.

Other strategies are to see what gets called when you run the functionality with some standard SAP process, using debug. Look at the source code of the FM and read the comments. Do a "where-used" and find example programs (there are some FM that are like this, though not released to customers... which is a bit odd). As you gain experience, it becomes easier to find the right component.

Welcome to the wonderful world of SAP programming...

3 REPLIES 3
Read only

matt
Active Contributor
0 Likes
754

Generally speaking, if a function module or class isn't documented, it's "use at your own risk". It isn't released to customers.

So you have to try various ones until you find the right one. Of course, you can use other people's expertise, as the most commonly used FM are well known.

Other strategies are to see what gets called when you run the functionality with some standard SAP process, using debug. Look at the source code of the FM and read the comments. Do a "where-used" and find example programs (there are some FM that are like this, though not released to customers... which is a bit odd). As you gain experience, it becomes easier to find the right component.

Welcome to the wonderful world of SAP programming...

Read only

Former Member
0 Likes
753

Hi Russ,

I feel your pain, I agree it makes the SAP developers look bad/untrained/inexperienced/lazy when they can't be bothered to document their own code, or at least consistently flag things as obsolete so we can ignore them.

I have 2 suggestions:

I would ignore any FM that isn't already used by SAP, in case it becomes obsolete.

In ECC I tend to look for a BAPI theat reads/writes the data I need. BAPIs are probably used somewhere and are hopefully documented. You usually get some kind of error handling with BAPIs too.

(run se37 and search for *BAPI*  to start, then refine your search)

Stuart.

Read only

0 Likes
753

Thank you for the replies.  Very good suggestions.