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.
| Info |
|---|
|
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 (either run an ST01 using an id with full rights or run a series of SU53 checks, granting rights as you go until you get them all)..
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
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.
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.
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
Query CoNNector
RFC and BAPI CoNNector
RFC Listener CoNNector
Transaction (BDC) CoNNector
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.
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 (either run an ST01 using an id with full rights or run a series of SU53 checks, granting rights as you go until you get them all)..
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: