Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 2 Next »

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 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. Generally, a separate (temporary) dialog user will be needed during development and testing. This temporary user id 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, the NLINK meta-database can be configured to use the dialog user during development (in order to run the Wizards, etc.), and switched to the background user for testing.

Note

An SAP service user is not appropriate.
  

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, and one with business-type authorizations, called the Business User. In this case, NLINK uses the Data Dictionary User for 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 requirements (depending on the type of NLINK configuration) 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.

Note

The values shown in examples below may be different in a customized SAP system.
  

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.

 

Transaction Codes          

 

Object S_TCODE
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.

  • No labels