Versions Compared
| Version | Old Version 4 | New Version 5 |
|---|---|---|
| Changes made by | ||
| Saved on |
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Overview
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 much 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
...
| title | Note |
|---|
...
.
...
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 User for configuration account for system tasks such as determining function module signatures and configuration tasks such as running the various SAP Wizards. This means that the Data Dictionary User can have more open authorizations in the Development environment, and less in Test and/or Production. Meanwhile, the Business User keeps the same authorizations in all environments.
By default, only the Business User is specified, so all authorizations would go to it.
Additional , while it uses the Business account for actual functional processing.
In most cases, we see a permanent (production-level) Data Dictionary User Id 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, the Data Dictionary User Id is either not used at all, or is 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.
Only the Business User is required, so by default, all authorizations would go to it.
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 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.
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 code contained in the function. Generally speaking, that’s 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
Authorization Object Details
The following formats may be used as a guideline to add authorization objects for the necessary Function Modules, Data Dictionary Tables and Transaction Codes.
| title | Note |
|---|
.
Function Modules
| Panel | ||
|---|---|---|
| ||
ACTVT = 16 |
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
| Panel | ||
|---|---|---|
| ||
ACTVT = 03 |
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.
Transaction Codes
| Panel | ||
|---|---|---|
| ||
| TCD = substitute transaction code value here |
To get the authorization value for a transaction:
- The transaction code itself is what you need for the TCD parameter of an S_TCODE authorization object
SAP Authorization Trace Transactions
The transaction ST01 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.
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 code contained in the function. Generally speaking, that’s 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). However, chances are good that your customer is not going to give you access to ST01.
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.
In order to run various NLINK SAP CoNNectors® and Wizards, the NLINK user id User Id will need authorizations in SAP for certain function modules, transaction codes and/or data dictionary objects. The extent of required authorizations decreases as the project progresses from development through testing to production. The following sections describe how NLINK uses the various SAP objects.The NLINK user should ultimately be a background (communications) user. It
In addition to these technical authorizations, the NLINK user will require the same authorizations functional and organizational authorizations that a regular user would need to perform the various functional 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.