Function modules (FuBa) are used everywhere in the SAP system. The standard already delivers a large number of FuBas. In addition, developers can create customer-specific function modules. These do not always have to be authorized separately. But if you need to authorize function modules, you can find out how here.
What are function modules?
For developers, function modules are like text modules for office administrators: a shortcut to avoid having to retype frequently used, recurring “texts” every time. However, function modules aka FuBas do not contain text for cover letters and the like, but code.
Code that is required at various points in the system is encapsulated in a function module. If developers need precisely this code, they do not have to write it themselves, but simply insert the relevant function module at the appropriate point in their program. This saves time, makes the code clearer, and reduces the risk of errors. Function modules also always have an interface for data exchange and are uniquely named throughout the system so that they can be used system-wide for all applications.
For FuBas to function in the system, they must be included in a function group. These are ABAP programs that serve as containers. What is special about them is that function groups can not only bundle several function modules at the same time. They can also contain other subroutines, screens, etc. that are available to all function modules within the function group.
Authorize function modules
Let’s assume that a developer in your company has created a Z-transaction that is used to control complex operations. Within this Z-transaction he has used a function module. In order to execute the Z-transaction, the FuBa must also be authorized. You have several options for this:
Maintain SU24
In the best case, the SU24 for the Z-transaction is correctly maintained. This means that all authorization objects that are checked when the transaction is called and executed have default values. If you now insert the Z-transaction into the role menu, these objects including the default values are already pulled into the role.
However, this is more likely to be the exception than the rule, especially in the case of in-house development. Therefore, you may well have to authorize the function module separately.
Maintain FuBa in the role menu
You can simply add RFC function modules to the role menu – just as you are used to doing with transactions.
To do this, open the role in the PFCG, click on the small arrow in the lower right corner of the “Transaction” button. A selection menu will open. Select “Authorization proposal” here. In the table you now see, open the drop-down menu at the top and select “RFC function module”. You can then enter the function module(s) in the table. And add them to the role menu by confirming.
This simultaneously creates an entry in the authorization object S_RFC. This is necessary so that the authorization can take effect.
The advantage of this method is that you can clearly see in the role menu which function modules are authorized in this role and can also remove them again relatively easily. Tip: Create a “FuBas” folder in the menu so that you can keep track of everything – especially if the menu contains a large number of entries.
Disadvantages of this method: You can only authorize function modules. It is not possible to authorize function groups or a range of function blocks via the menu entries, such as all Z-FuBas.
Maintaining FuBa via S_RFC
Therefore you can also maintain the function modules directly in the authorization object S_RFC. The object contains 3 authorization fields:
RFC_TYPE:
Here you specify the type of RFC object, that is, whether you want to authorize a function module (FUNC) or a function group (FUGR).
RFC_NAME:
Here you specify the name of the FuBa or the function group. And here you can also authorize a whole range at once. To take up the example of the Z-FuBas: If you want to authorize all customer-specific function modules across the board, you can work here with entries such as “Z*”, for example, or you can authorize “Z_A*” to “Z_G*”.
ACTVT:
Here you specify the activity, where only ACTVT 16 is available. With this activity, the user in the target system can use the function module entered above.
Consider further authorizations
Let’s return to our initial example. Your developer has built a Z-transaction. Of course, for it to work, it’s not enough to authorize the function module. And since function modules can be used in all possible places in the system for all possible applications, you have to check again in each case which authorizations you also have to assign.
In the case of the Z transaction, you need at least one entry in S_TCODE for the start authorization of the transaction itself. In addition, depending on what the transaction is executing, you will need other (functional) authorization objects. If a program is executed, S_PROGRAM or S_PROGNAM may also need to be written out, and so on.
Excursus: BaPi
BaPis (Business Application Programming Interface) are methods based on function modules. They are necessary to call data from SAP business objects. For example, if you want to see all cost centers that your system knows, this listing is only possible because the business object “CostCenter (cost center)” provides a BaPi “GetList”.
Basically, not every function module is a BaPi, but every BaPi is a function module. Accordingly, they are also authorized in the same way where necessary.