I posted this content on LinkedIn a while back, but this is obviously where it belongs... If I recall the story correctly, since it was a few years ago now, I was working in a WM project the first time I needed to know what I'm about to describe here.
We were building a couple of SAPUI5 apps to support the warehouse process and one of the the function modules we used was failing from time to time without even causing short dumps. After we had scratched each others heads for a while, the debugger was the way forward and there it was at last: a MESSAGE statement of type E in the code. (And just a note: "from time to time" might sound random, but when we found out the root cause here, it was obviously fully logcal in itself, as always)
To demonstrate, here is an demo example of a function module that adds a number of days to a todays date:
If the supplied number of days to add is 0, no_number is raised. (line 13-15). And if it's below zero, negative_number is raised. (line 17-19). These two would be caught and affect the sy-subrc for program flow after the normal FM call.
But then we also have the case where the supplied number of days is 73. (line 21-23). For some reason the demo FM does not want to handle this, but instead of using a declared FM exception, a MESSAGE is raised. Now, if this is run inside of the SAP GUI, the message will be displayed in the message bar, as expected, and the program flow will be stopped, as expected. But now that we are calling the FM without the GUI, like for instance when we are building SAPUI5 that is living outside of the SAP GUI, there is nowhere to display this message and then we got the abrupt crash of the FM without the short dump.
Typically, I use the CALL FUNCTION template to get the entire signature of the function module in the code, enter needed and remove what is not needed. And I expect to get the errors from the function module or BAPI call as exceptions to investigate in the sy-subrc (or a separate table or structure in some cases).
Like for no_number and negative_number in the example here:
This is what is provided from the template of the CALL FUNCTION. However in our case with the WM apps, and I have seen a couple of more after that, this error was not part of the exception handling of that function module.
Well, first off, if you are writing Function Modules like my example above, please stop! 😎 Don't MESSAGE out into the void like that if there is no SAP GUI. But here's what to do to catch-them-all...
As the documentation of CALL FUNCTION, parameter list, addition 6, clearly states:
In other words, this is the way to call the function module in order to also catch these abominations of FM errors:
By adding the error_message exception to the CALL FUNCTION we will also catch any MESSAGE of type A or E and we will have the detailed information about the message in the sy structure.
Even though the vast majority of Function Modules behave properly in this aspect I would think that the more we move outside of the SAP GUI, the more we might see these cases. And most of them will probably be to user exits and enhancements.
I hope that this might save somebody from some debugging and troubleshooting. 😊
We were building a couple of SAPUI5 apps to support the warehouse process and one of the the function modules we used was failing from time to time without even causing short dumps. After we had scratched each others heads for a while, the debugger was the way forward and there it was at last: a MESSAGE statement of type E in the code. (And just a note: "from time to time" might sound random, but when we found out the root cause here, it was obviously fully logcal in itself, as always)
Explanation
To demonstrate, here is an demo example of a function module that adds a number of days to a todays date:
If the supplied number of days to add is 0, no_number is raised. (line 13-15). And if it's below zero, negative_number is raised. (line 17-19). These two would be caught and affect the sy-subrc for program flow after the normal FM call.
But then we also have the case where the supplied number of days is 73. (line 21-23). For some reason the demo FM does not want to handle this, but instead of using a declared FM exception, a MESSAGE is raised. Now, if this is run inside of the SAP GUI, the message will be displayed in the message bar, as expected, and the program flow will be stopped, as expected. But now that we are calling the FM without the GUI, like for instance when we are building SAPUI5 that is living outside of the SAP GUI, there is nowhere to display this message and then we got the abrupt crash of the FM without the short dump.
Expectation
Typically, I use the CALL FUNCTION template to get the entire signature of the function module in the code, enter needed and remove what is not needed. And I expect to get the errors from the function module or BAPI call as exceptions to investigate in the sy-subrc (or a separate table or structure in some cases).
Like for no_number and negative_number in the example here:
This is what is provided from the template of the CALL FUNCTION. However in our case with the WM apps, and I have seen a couple of more after that, this error was not part of the exception handling of that function module.
Solution
Well, first off, if you are writing Function Modules like my example above, please stop! 😎 Don't MESSAGE out into the void like that if there is no SAP GUI. But here's what to do to catch-them-all...
As the documentation of CALL FUNCTION, parameter list, addition 6, clearly states:
Messages of the type E and A raise the exception error_message and set sy-subrc to n_error. The message class, message type, message number, and the content of any placeholders of the MESSAGE statement are in the fields sy-msgid, sy-msgno, sy-msgty, and sy-msgv1, ... sy-msgv4.
In other words, this is the way to call the function module in order to also catch these abominations of FM errors:
By adding the error_message exception to the CALL FUNCTION we will also catch any MESSAGE of type A or E and we will have the detailed information about the message in the sy structure.
Even though the vast majority of Function Modules behave properly in this aspect I would think that the more we move outside of the SAP GUI, the more we might see these cases. And most of them will probably be to user exits and enhancements.
I hope that this might save somebody from some debugging and troubleshooting. 😊
- SAP Managed Tags:
11 Comments
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
