SAP Authorization Requirements

Overview

In order to run various NLINK SAP Connectors® and Wizards, the NLINK User Id will need authorizations in SAP for certain function modules, transaction codes and/or data dictionary objects. The NLINK user should ultimately be a background (communications) user.

In addition to these technical authorizations, the NLINK user will require the same functional and organizational authorizations that a regular user would need to perform the various tasks that the interfaces are replicating, e.g., create purchase orders. We cannot recommend any particulars in this area, as authorization schemes vary wildly across SAP systems. This article covers only the technical authorizations specific to configuring and running an NLINK Server.

Note

An SAP service user is not appropriate.

Generally, a separate dialog user will be needed during development and testing. Whoever is configuring the NLINK Server will use this account to access the SAP system via the SAPGUI to find and create test data, verify interface results, etc. This dialog user will need full access to the relevant functional areas, and also access to ABAP Workbench areas such as SE37 (display and test), SE11 (display), SE16 (display), etc.

If you want to keep the authorizations for the background user to a minimum, or if you do not want to provide additional authorizations to the background user in the development environment, the NLINK meta-database can be configured to use the dialog user account during development (in order to run the Wizards, etc.). Then you can switch to the background user for testing.

As of NLINK 6.0.0.107, you may specify two separate user ids for NLINK–one with system-type authorizations, called the Data Dictionary User Id, and one with business-type authorizations, called the Business User Id. In this case, NLINK uses the Data Dictionary account for system tasks such as determining function module signatures and configuration tasks such as running the various SAP Wizards, while it uses the Business account for actual functional processing.

In most cases, we see a permanent (production-level) Data Dictionary User Id specified only in ADC environments, where multiple individuals log on to SAP through interactive screens, and the SAP Administrators want to limit the additional authorizations they must grant to each of those individuals. In non-interactive environments, we see the Data Dictionary User Id either not specified at all, or only specified during development (while configuring the NLINK Server). In the latter case, the dialog user account mentioned above can be used for this purpose.

Authorization Objects for NLINK User Id(s)

Data Dictionary User Id

If you are not specifying a separate Data Dictionary User Id, include these authorizations in the Business User Id profile.

Production

The following authorizations are required in all environments.

Object	Field 1	Value 1	Field 2	Value 2	Field 3	Value 3
S_RFC	ACTVT	16	RFC_NAME	RFC1, SDIFRUNTIME, SUSR, SYST	RFC_TYPE	FUGR

Configuration

The following authorizations are required, in addition to the Production authorizations above, in the Development environment to allow the NLINK User to use the various Wizards for configuration.

Object	Field 1	Value 1	Field 2	Value 2	Field 3	Value 3	Field 4	Value 4	Field 5	Value 5
S_RFC	ACTVT	16	RFC_NAME	*	RFC_TYPE	FUGR
S_TABU_DIS	ACTVT	03	DICBERCLS	*
S_DEVELOP	ACTVT	03	DEVCLASS	*	OBJNAME	*	OBJTYPE	TABL	P_GROUP	*
S_CTS_ADMI	CTS_ADMFCT	TABL
S_IDOCDEFT	ACTVT	03	EDI_CIM	*	EDI_DOC	*	EDI_TCD	WE30

Business User Id

The following authorizations are required in all environments. If you are not specifying a separate Data Dictionary User Id, the authorizations from the previous section are also required.

IDoc Connector

Object	Field 1	Value 1	Field 2	Value 2	Field 3	Value 3
S_RFC	ACTVT	16	RFC_NAME	ARFC, ERFC, SYST, SYSU	RFC_TYPE	FUGR
S_CTS_ADMI	CTS_ADMFCT	TABL
B_ALE_RECV	EDI_MES	all configured message types

Query Connector

Object	Field 1	Value 1	Field 2	Value 2	Field 3	Value 3
S_RFC	ACTVT	16	RFC_NAME	SDTX, SYST	RFC_TYPE	FUGR
S_RFC	ACTVT	16	RFC_NAME	function module for custom RFC_READ_TABLE, if implemented	RFC_TYPE	FUNC
S_TABU_DIS	ACTVT	03	DICBERCLS	&NC&
S_TABU_NAM	ACTVT	03	TABLE	all configured tables and views

RFC and BAPI Connector

Object	Field 1	Value 1	Field 2	Value 2	Field 3	Value 3
S_RFC	ACTVT	16	RFC_NAME	BAPT, SYST	RFC_TYPE	FUGR
S_RFC	ACTVT	16	RFC_NAME	all configured function modules	RFC_TYPE	FUNC

RFC Listener Connector

Object	Field 1	Value 1	Field 2	Value 2	Field 3	Value 3
S_RFC	ACTVT	16	RFC_NAME	SYST	RFC_TYPE	FUGR

Transaction (BDC) Connector

Object	Field 1	Value 1	Field 2	Value 2	Field 3	Value 3
S_RFC	ACTVT	16	RFC_NAME	MRFC, SYST	RFC_TYPE	FUGR
S_ADMI_FCD	S_ADMI_FCD	NADM
S_TCODE	TCD	all configured transaction codes

SAP Authorization Trace Transactions

The transaction ST01 (or STAUTHTRACE in newer systems) in SAP will let you run an authorization check trace, which can be helpful in determining the necessary authorization objects and values. You can also use transaction SU53 to analyze an access-denied error that has just occurred.

Limitations of SU53

Note that SU53 only shows the results of the most recent authorization check. This means that a failed authorization may be masked if a successful authorization occurs afterwards. For this reason, ST01 or STAUTHTRACE are more likely to provide the missing information.

For example, when you add a BAPI or RFC to your configuration, you will need at least the S_RFC authorization that lets you call the function. Then you may or may not need additional authorizations to run the ABAP code contained in the function. Generally speaking, determining any additional authorizations is a process of trial and error.

What/whether NLINK can report anything useful about RFC/BAPI authorizations past the initial S_RFC requirement is dependent on the ABAP code of the functions you’re trying to call, making authorizations a typically frustrating topic. It often takes a few iterations to find out everything that you need.

Additional Requirements

Some additional requirements (depending on the type of NLINK configuration) that aren't strictly authorization-related may include the following:

Activation of change documents for objects being monitored through the CDHDR table
Creation of views in the data dictionary for performance enhancement
ALE configuration if IDocs are being used
Workflow and/or output determination configuration if SAP is sending IDocs to NLINK, or if SAP Listener is being used
Preparation of a triggering function module if SAP Listener is being used

Function Modules

Object S_RFC

ACTVT = 16
RFC_NAME = substitute function group value here
RFC_TYPE = FUGR

To get the authorization value for an RFC/BAPI:

Display the RFC in transaction SE37
Go to the Attributes tab
The value in the Function Group field in the Classification section is what you need for the RFC_NAME parameter of an S_RFC authorization object

It is also possible to specify RFC_TYPE = FUNC and provide individual function module names in RFC_NAME. This provides more granular control, but there are some cases where the FUGR authorization is explicitly called in the SAP system, so it is simpler to use the wider authorization.

Data Dictionary Tables/Views

Object S_TABU_DIS

ACTVT = 03
DICBERCLS = substitute authorization group value here

To get the authorization value for a data dictionary table/view:

Look at view V_DDAT_54 in transaction SE16
Find the table or view in question
The value in the Authorization column is what you need for the DICBERCLS parameter of an S_TABU_DIS authorization object
If the table or view is not listed, assume &NC& (not classified)

It is also possible to use authorization object S_TABU_NAM and provided individual table names in the TABLE parameter. This provides more granular control, but there are some cases where the S_TABU_DIS authorization is explicitly called in the SAP system, so it is simpler to use the wider authorization.

NLINK Knowledgebase