2021 Feb 26 11:50 AM
We would like to better control the number of RFC-enabled function modules created in our systems (SAP NW 7.50 EHP8). I already checked the options provided for authorization object S_DEVELOP but it doesn't seem to have attributes which would allow us to define something to specifically prevent creation of RFC-enabled function modules (but allows changes of existing ones and creation of non-RFC enabled modules). Does something like this exist off the rack or could be put into a user exit somewhere in SE37/SE80 or before objects are added to transports?
I searched SAP Community and SAP Help but looking for "restrict creation rfc-enabled function modules site:sap.com" mostly brought back articles related to restricting the execution of RFC-enabled function modules but not their creation.
Thanks much for any leads you may have!
Cheers
Bärbel
2021 Feb 26 1:15 PM
Create an authorisation object that switches on or off authorisation to develop RFC function modules.
Write a small utility procedure (method or FM) that takes the name of a FM, checks if it is RFC enabled, and if so, does an AUTHORITY-CHECK on the most recent editor of the FM.
In the BADI for transport release (or perhaps elsewhere), run this function module. If the auth check fails, then refuse the release.
You could also create an ATC check. Run it regularly and get a report on all custom FM in your system. It doesn't prevent creation of RFC enabled FM, but it does stop them going further and allow action to be taken.
I'm intrigued why people would be creating so many RFC FM; but that's a management issue.
2021 Feb 26 12:48 PM
Hi 8b889d0e8e6f4ed39f6c58e35664518f,
it you run the SU24 for the transaction SE37, sap will give you the object : S_RFC_ADM
did you check it ?
Did you try to make a trace with STAUTHTRACE on the RFC activation ?
BR
Fred
2021 Feb 26 1:15 PM
Create an authorisation object that switches on or off authorisation to develop RFC function modules.
Write a small utility procedure (method or FM) that takes the name of a FM, checks if it is RFC enabled, and if so, does an AUTHORITY-CHECK on the most recent editor of the FM.
In the BADI for transport release (or perhaps elsewhere), run this function module. If the auth check fails, then refuse the release.
You could also create an ATC check. Run it regularly and get a report on all custom FM in your system. It doesn't prevent creation of RFC enabled FM, but it does stop them going further and allow action to be taken.
I'm intrigued why people would be creating so many RFC FM; but that's a management issue.
2021 Feb 26 2:13 PM
matthew.billingham
Hi Matt,
thanks for your feedback!
I was somehow hopeing for a user-exit kind of option as exists when you call SE11 (ZXSEUU19) but haven't yet found one for SE37 (and yes, I know that this would only catch activities triggered in the GUI and not Eclipse but this is not much of a concern as Eclipse isn't yet used much).
The need for RFC FMs is due to our system landscape where for example creating an order in one system triggers a delivery in another system. These are often exchanged via IDOCs but there are also cases, where you need to query the data available in the "counterpart" system to for example get the original order number or some master data or whatever (options abound!).
Cheers
Bärbel
2021 Feb 26 2:34 PM
If you need to use FMs in OData projects you must create RFC enabled FMs. It's not so uncommon, at least in the projects that i've worked on.
2021 Feb 26 2:56 PM
I guess really I was wondering why you'd need to control it. Yes, I create RFC FMs fairly frequently!
8b889d0e8e6f4ed39f6c58e35664518f You could always do an enhancement. Or a repair! But you'd need to consider also that you can create FMs by copying or creation from the object list (e.g. SE80).
2021 Feb 26 3:23 PM
Sounds as if there's no "out-of-the-box" quick means to check what I'd like to do.
We'll discuss internally if we actually want to only allow the creation of RFC-enabled function modules for some individuals just to keep this in check and to enforce some naming conventions. If we do, I may go down the route which I already used (see this comment) to avoid the creation of or changes to DDIC-objects in the wrong systems or with the wrong user-ids.
Cheers
Bärbel
2021 Feb 26 1:18 PM
frdric.girod
Hi Fred,
from the description S_RFC_ADM seems to be related to setting up RFC-connections between systems "Authorization check in transaction SM59 and when calling remote function modules based on the destination". It also makes an appearance when I run SU24 for SE38 or SE11 where I guess it's rather unlikely to have anything to do with creating a new RFC-enabled function module.
But thanks for making me try a transaction I hadn't yet known!
Cheers
Baerbel
2021 Feb 26 2:17 PM
Did you check in your system if the Enhancement Spot FB_RFC_FUNCTION_EXIT / BAdI BADI_FB_RFC_FUNCTION_EXIT are available and implemented?
(They are SAP restricted, but there are implicit Enhancement available in standard implementation class of the BAdI...)
NB: Use of matthew.billingham's solution is much cleaner than this one
2021 Feb 26 2:56 PM
Oh I don't know. I'd be quite happy going for an implicit enhancement if it suited my needs!