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!
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.
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:
This reduces the coding in the wrapper to one line:
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!).
I just began working with this. There might be things, I just did not think of. I'm looking forward to the discussion!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
4 | |
3 | |
3 | |
2 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 |