The Harlem Function Module Shuffle

How to improve error handling in function modules.

As really good series of blogs recently was “The Hassle with Function Modules, man” by Jorg Krause.

As with all good blogs it got me thinking, and made me look at something in a new way.

The blog was all about wrapping methods around function modules.

I had been against this, and what had poisoned me here was that in the early days of OO at SAP, I reckon the developers were paid by how many classes and methods they could create. So they took hundreds of function modules and put them inside static methods of classes with the exact same interface (or as close as they could get given the absence of TABLES).

That is why (I think) methods can have the “classic” exceptions which set SY-SUBRC, and can be called in a syntax almost identical to a function module call.

That whole exercise seemed pointless, as the methods were static they could not be subclassed, and you lost the ability to do an RFC call. Just to add insult to injury the name of the class/method often bore no relationship to the name of the function module, with both names being equally non-intuitive.

However looking at this again, the problem was not wrapping the subclass; it was wrapping it in a silly way. I can now turn the entire argument on its head.

Jorg mentioned the following benefits:-

  • Inline declaration become possible, they ae not for function modules
  • Better syntax checking, avoiding the dump at runtime from passing a variable of the wrong type
  • Possibly simplified interface
  • Less cluttered code by use of exception classes rather than long strings of exceptions
  • Exception classes are better than classic exceptions (I did not think so at first, after a year I was 100% convinced)

I have also thought of some more. First and foremost make all the methods (that wrap function modules) instance methods, so they can be subclassed, thus enabling unit tests. I think unit testing was also mentioned in the above blog as a further benefit.

Also, I think I want to wrap any (if there are any) standard SAP methods which raise classical exceptions in custom methods as well, so they can use exception classes and can be subclassed.

Name and Shame

In the example in the blog above were some class names like CA03 e.g. ZCL_CA03_DDIC. I have never been a big fan of secret codes in the name of anything, inside and outside of computer systems.

In Australia a Fringe Benefit Tax form is called a Fringe Benefit Tax form. In the UK it is called a P11D. I still would not call a class to deal with this ZCL_P11D even if I was still working in the UK. I would give it a name which described what it was actually about.

SAP Function group names are often utterly meaningless e.g. SPO3, and whilst the names of function modules are such that you can guess what they are doing at least 50% of the time, there is no consistent naming convention throughout the system.

The example I always give is BAPIS where there did not seem to be a firm decision what the “READ” operation should be called, leading to dozens of variations and thus making it difficult to do a search.

Another example would be, when it comes to database read buffering function modules:-





On the positive side, the word SINGLE almost always comes before the word READ. However even know I keep trying to insert the function VBAK_SINGLE_READ and forget the silly prefix and thus fail. There are also function modules with a similar purpose with an entirely different naming convention.

If I was going to wrap such functions, I would give a consistent naming convention, and also say MATERIAL rather than MARA and so forth.

What you want is the line of code to read like English as in the following example:-


Some people would say I am being far too wordy there e.g. do I really need the word “OF”? Everyone has a different opinion on what is simultaneously the most compact and also the clearest code to read.

I can RFC Clearly Now

As we know only function modules can be used for an RFC. As classes came out in the year 2000 and SAP from that point started telling us not to use function modules, you would think they could have done some magic in that 16 year period to find a way to execute a method of a class on a remote system, there are some languages where you can only have classes and they seem to manage OK.

SAP methods and Excel methods seem to be able to execute inside each other’s system to an extent. Anyway, if this is forever in the too hard basket, how we get around this is to call an RFC function from within a wrapper method. A lot of standard SAP example Gateway classes do RFCS inside methods for example, as the Gateway wants the code to execute on a different system to the hub.

Putting the RFC call inside a method allows you to subclass for unit testing, and all the code inside the function module can be OO if that is so important. The function module wrapper superclass (we will come to that in a minute) could have a method to set the RFC destination. I am just blue-skying here.

Go to the Top of the Wrapper Class

The blogs talk about using a generic mechanism to transform the messages that come from function modules into class based exceptions, without having to do a load of coding each time. This has to handle both the cases where an actual SYST (T100) message is passed, as well as just a SY-SUBRC getting set by the function module.

Luckily for us SAP provides us with some great mechanisms to do this, especially in the latest releases. Once we settle on some generic code, then sticking that in a top level abstract interface/class would seem to be the way to go so you do not have to repeat it each time.

I will give a possible implementation right now. In the future, every time I can think of something that could be used by a wide range of function modules e.g. an instruction to execute on a different system, that could be added to the abstract superclass.

Fireman Code Sample

I can think of three results a function module call could result in:-

  • Happy path, all is well, desired result is returned
  • An exception is raised, together with a T100 message
  • An exception is raised, with no message

To start off, let us create a function module with some nonsense code inside, which returns all three possible results I just mentioned, depending on what monster number is input.

FUNCTION zmonster_golf_scores.
*”*”Local Interface:

IF id_monster_number = 15.
ed_golf_handicap = 3.
ELSEIF id_monster_number = 1.
RAISE monster_only_one_inch_tall.
“004 = Monster &1 has no Silly Trousers!
MESSAGE e004(zmonsters) WITH id_monster_number
RAISING monster_has_no_silly_trousers.


The idea is to write a small test program which passes in three different monster numbers, to result in the happy path, the exception with the message, and the exception without the message.

What do I want? The Moon on a Stick. When do I want it? Now. I am just like an end user.

I want my test program to call one method, and it handles all three situations. In this example my user name is David Win (WIND) but when you try this replace WIND with your actual name I want a break point just after the exception is raised so you can have a look at the exception object.

The calling program needs to decide what to do with the exception e.g. if online output a message to the user, if running in background write to the application log, or send an email, or sing a song and dance, whatever is appropriate. As always the job of the exception is to give as much information to the calling program as possible, and then its work is done here.

Here is my test program:-

DATA: wrapper TYPE REF TO zcl_get_monster_golf_handicap.


PERFORM get_handicap USING :
‘0000000001’, “Exception – No T100 Message
‘0000000002’, “Exception – T100 Message
‘0000000015’. “Happy Path

*&      Form  GET_HANDICAP
FORM get_handicap USING id_monster_number TYPE zde_monster_number.

DATA(handicap) = wrapper->golf_handicap_of_monster( id_monster_number ).

CATCH zcx_function_module_error INTO DATA(function_module_error).
BREAK wind.


You will notice straight away that I am not calling the function module directly. I have created a wrapper class around it, with a more meaningful name than the original function module, according to my oh-so-logical naming convention as opposed to the random naming convention used by many programmers, and indeed SAP itself.

To keep things simple for this example class ZCL_GET_MONSTER_GOLF_HANDICAP only has one method, namely GOLF_HANDICAP_OF_MONSTER. Let us have a look at the code, which consists of a number of calls to other routines, each of which we shall deal with in due course.

METHOD golf_handicap_of_monster.

remove_existing_messages( ).

id_monster_number             = id_monster_number
ed_golf_handicap              = rd_golf_handicap
monster_only_one_inch_tall    = 1
monster_has_no_silly_trousers = 2
OTHERS                        = 3.

IF sy-subrc <> 0.
throw_exception_on_error_from( ‘ZMONSTER_GOLF_SCORES’ ).


Clearly the main piece of business is to call the function module itself. The parameters of the method are the same as the function module, and you can rename them if the original SAP module had silly or German abbreviation names, and skip ones that never get used (use constants or something in the wrapper method), to make the life of the calling program easier.

I have all my wrapper classes inheriting from abstract class ZCL_FUNCTION_MODULE_WRAPPER.

This has methods which will never change regardless of which function module I am wrapping. By the way, one of my favourite songs for the yuletide season is “Christmas Rapping” by The Waitresses. First off, I have determined that when you call a function module and no errors occur; the values of SYST remain unchanged, which makes perfect sense. Nonetheless I want them cleared. Why? Because I said so. I could get a job writing documentation for SAP with that attitude. There is an actual reason – see if you can guess it based on what follows.

METHOD remove_existing_messages.

CLEAR: sy-msgid,


That’s them gone! Ha-Ha! Serves them right! Now if they change to non-initial values it is because my function module call has changed them.

If the function module call turns pear shaped because an exception has been raised, or an unexpected error message has been directly raised inside the function module (the ERROR_MESSAGE exception) then the value of SY-SUBRC will not be zero, as we all learned on our first day on the job, and so my THROW_EXCEPTION_ON_ERROR_FROM method will be called, passing in the function module name.

This method is implemented in the abstract superclass, as are all the private helper methods I will discuss shortly. My spell checker just suggested that “Pirate Method” was better than “Private Method”. As we all know, when defining a “Pirate Method’ in ABAP the first line of code has to be “Arrrrrrrrrrrrrrrrrrrrrr!”.

METHOD throw_exception_on_error_from.

md_function_name = id_function_module.

DATA(return_code)    = sy-subrc.
DATA(exception_name) = the_exception_mapped_to_the( return_code ).
DATA(exception_text) = description_of( exception_name ).

IF no_t100_message_was_raised( ).
RAISE EXCEPTION TYPE zcx_function_module_error
function_module = id_function_module
exception_name  = exception_name
exception_text  = exception_text
no_t100_message = abap_true.
RAISE EXCEPTION TYPE zcx_function_module_error
MESSAGE ID sy-msgid
TYPE sy-msgty
NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4
function_module = id_function_module
exception_name  = exception_name
exception_text  = exception_text
no_t100_message = abap_false.


This is in a 7.50 system, by the way. Some of the exception handling used here is not available in lower releases i.e. the releases used by 99.9999999999% of SAP customers at the moment, so ha-ha-ha stuff you! I could definitely get a job writing SAP documentation However the day will dawn when most people are on this release albeit that day is ten years away.

Just in case there is no T100 message raised it would be a good idea to get the name and description of the actual exception raised, as follows:-

METHOD the_exception_mapped_to_the.

SELECT  parameter
FROM  fupararef UP TO 1 ROWS
INTO  rd_exception_name
WHERE funcname  = md_function_name
AND   r3state   = ‘A’
AND   paramtype = ‘X’ “It’s an exception
AND   pposition = id_subrc.

IF sy-subrc <> 0.
CLEAR rd_exception_name.


METHOD description_of.

INTO  rd_exception_text
FROM  funct
WHERE funcname  EQ md_function_name
AND   parameter EQ id_exception_name
AND   kind      EQ ‘X’.

IF sy-subrc <> 0.
rd_exception_text = id_exception_name.

IF rd_exception_text IS INITIAL.
rd_exception_text = id_exception_name.


What have I got? I’ve got the lot! I have both the technical name of the exception and any text description that may have been entered. The latter is not compulsory so when it is blank I just set it to the technical name. Blankety Blank, Blankety Blank, Blankety Blank. Blankety Blank! Supermatch game, Supermatch game, Supermatch game. Supermatch game!

The next question, the burning question on all our minds, is whether a T100 message was raised either the correct way via MESSAGE xxx RAISING or via a direct error message. We cleared SY-MSGID and all its friends earlier so if they now have a value then the function module must have created that value.

METHOD no_t100_message_was_raised.

rf_no_t100_message_was_raised = abap_false.

sy-msgno IS INITIAL.

rf_no_t100_message_was_raised = abap_true.


It just occurred to me you could declare a classical exception called ARIZONA and then you could actually have in your code RAISING ARIZONA without a syntax error. Don’t do that. It’s silly. Forget I mentioned it.

Next we come to the custom exception class ZCX_FUNCTION_MODULE_ERROR. This inherits from CX_NO_CHECK which is my favourite of root exception classes.

CX_STATIC_CHECK is all well and good when I really want to highlight to the calling program that something is almost certainly likely to go wrong so you had better deal with it, and CX_DYNAMIC_CHECK  I use when I have had fifteen pints of beer and then been hit over the head with a baseball bat many times. Even then I hesitate.

The “interfaces” section looks like this:-


In addition, I have added some custom attributes:-

Custom Attributes

Hopefully the calling program, when confronted with an exception, can work out what to do based on the T100 data (if any) coupled with the classical exception details from the function module which was been “wrapped”.

Donna Summary

So, the artist formerly known as the function module can be wrapped up like a mummy, and then you can use inline declarations, the syntax check works better, silly naming can be improved, the interface (signature) can sometimes be simplified, you can still do an RFC, the error handling is a lot better, and the code in the calling program is drastically simplified.

Is that right? What do you think? Is this whole idea free energy crazy? Or is there an even better way to achieve the same goal?

Cheersy Cheers





To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Andre Schüßler

    I like your idea.

    Maybe you can extend your logic to handle some additional ways of how function modules can return errors.
    Just think of BAPIRET, BAPIRET2, BAPIRETTAB and so on.

    And I often have to deal with an exporting (or table) parameter of type FIMSG in combination with classical exceptions. This is widely used in FI-CA.

  2. Naimesh Patel

    Hello Paul,

    Thanks for the post.

    I however, would try to avoid a wrapper which actually has a RAISE EXCEPTION TYPE statement. By doing this, I lose the ability to trace back from exactly the exception was raised. During debugging, I can use the button “Display Trigger Location” to identify from where the error was raised, but there is no callstack to point if it was raised from a specific method.

    When this wrapper method is called from so many places, it would be difficult to identify the place. You can do other logic in the wrapper method, but the raising should be right from where the error is raised.


    1. Paul Hardy Post author

      This is what the SCN (I still call it that) is for. Discussions on new and better ways to handle problems.

      In this case I am starting from a function module that raises the old fashioned type of Exception which sets the SY-SUBRC and maybe does not even have the function module wrapper I could be 100% sure where the error occurred, as the program flow stops right there and then.

      With a proper exception of course the program can jump as far up the call stack as is needed.

      So if I have a function module that raises a SY-SUBRC and then throw an exception, that is the exception that gets caught higher up the call stack.

      I think what you are saying, is that because the exception is raised within it’s own method, you lose track of where that method was called from. Is that correct? You have no idea which wrapper class called that method which raises an exception, you just have an exception which came from “somewhere”?

      So my aim is now still to not have to write boiler plate code all the time, but in addition to keep track of where the exception was raised.

      I shall do some experiments, and let you know how I go on.I already have some ideas.

      1. Paul Hardy Post author

        I have made a minor change to the class that wraps the function module, and now, when the exception is raised, and I press the button mentioned above to get the “trigger location” I am taken to the point just after the function module raised the exception, as in the below screen shot:-

        Nothing clever there, just catching the exception locally and passing it on,  but with not much code cluttering up the place. I now know that the wrapper method raised the exception just after the function module went into error, and what the error was. But where was the wrapper method called from?

        As someone somewhere once said “I’ll be Back”.

        Also, I wonder how long it will be till I like the new SCN as well as the old one. Probably the day email notifications are restored and they take that stupid picture off the log on screen, with it’s incorrect instructions. And yes, I have logged all this with the powers that be.

        1. Paul Hardy Post author

          Next, I add the call stack table as an attribute of my exception class, and just before raising the exception i.e. just after the function module has come back with a SY-SUBRC other than zero I use the good old ‘SYSTEM_CALLSTACK’ function module to get the current state of play call stack wise, so it can be passed into the exception.

          Then, when debugging, not only can I get to the exact point the exception was raised i.e. just after the function module call, but I can also click on the call stack table attribute of the exception object, and it tells me what called my wrapper method in the first place.

          I expect you or someone will tell me the call stack information is already there every time an exception is caught, but I could not find that information in the debugger for the life of me. Tell me anyway, I’d like to know the proper way of finding this.

          Cheersy Cheers


  3. Christian Guenter

    Hi Paul,

    interesting stuff as always. One little side note to the results of function module calls.

    I can think of three results a function module call could result in:-

    • Happy path, all is well, desired result is returned
    • An exception is raised, together with a T100 message
    • An exception is raised, with no message

    You can also raise class based exceptions within function modules. Of course they are in minority. 2.172 FMs with class based exceptions compared to 463.637 without class based exceptions in our ERP system.

    Regards Christian

    1. Paul Hardy Post author

      If the function module raises exceptions “properly” i.e. class based, you could still wrap it, to get the benefit of inline declarations and what have you, but no need to convert the exception at the end of the wrapper method.

      I think it very funny that in the new world e.g. 7.40+ not only do function modules still default to “classic” exceptions, but so do method definitions in SE24. I would have thought by now that “class based exceptions” should be the default, at least in SE24.

  4. Ged Hurst

    This is not going to push the sum total of ABAP knowledge any further but your ‘RAISING ARIZONA’ suggestion reminded me that there was once an ABAPer on a project long ago who got told off but generated much mirth by calling an internal table ‘willy’ so he could write ‘free willy.’



Leave a Reply