The hassle with function module calls – part 2

In the last blog post I wrote about my approach to standard function module wrappers. See The hassle with function module calls

Thanks to your participation, there was a lot of very helpful input about this matter from the community. This lead me to a better understanding of exception classes and I now set up a handy mechanism to transform the function module exceptions into appropriate class-based exceptions. Hoping the fruitful discussion is going on, I’d like to share it!

With or without message?

Most function modules pass system messages when raising classical exception. For example, look at function SX_INTERNET_ADDRESS_TO_NORMAL, that can validate mail addresses:

Others, like KNA1_READ_SINGLE, do not so:

Since I didn’t want to loose information, I wanted a mechanism, that transfers the messages into the exception class, if present. If not, the exception should be raised with a simple TEXTID.

With sy-msgid and sy-msgno

Step one: the static coding

When the FM sets a message together with an exception raised, I include the IF_T100_MESSAGE interface in the exception class and create one textid for each message that could be raised in the function module:

As you certainly guess, the name of the textid is a concatenation of message id and message number. For each textid, I assign the appropriate message:

The parameter attributes are to be created first

Now, the coding in the wrapper could look like this:

The name of the textid is created dynamically using the system message fields. Then, a field symbol for it is created and the exception is raised giving the variable parts of the message. It works. But…..

Do I really want to cut/copy this coding block in each wrapper? Of course not. So here comes the next step:

Step 2: the generic exception raiser method

This reduces the coding in the wrapper to one line:

Without a message

In this case, the error is identified by the exception id of the function module. I create one textid for each exception of each function module covered by the exception class. It looks like this:

The text id name is just the name of the function module, followed by the sy-subrc. The text is set according to the exception of the FM.

I skip the static version of the wrapper coding and go directly to the dynamic one! Here is my raiser method (as above, a static public method):

Unfortunately, we have three input parameters here, the SAP FM, the exception class type and the subrc. In the wrapper, the coding is:

The FM name might be too long that you could add the subrc with the underscore at the text id name. In this case, just shorten the iv_module parameter a bit (and do this also with your text id names!).

Conclusion

I just began working with this. There might be things, I just did not think of. I’m looking forward to the discussion!