Sample SAPNWRFC.INI File
- Darcy Curtin
Analytics
/*********************************************************************/* */* SAPNWRFC.INI */* */*********************************************************************
/*===================================================================*/* DEFAULT Section */* */* The default section defines some default or global properties */* regarding connection management and tracing. Here is a sample */* configuration. */* */*===================================================================*
DEFAULT# Trace all connections/destinations, which do not explicitly define# their own trace level, with level 1. If this value is not set, the# default is 0. Possible values are 0(off), 1(brief), 2(verbose), 3(full)RFC_TRACE=0
# The following three parameters are evaluated only once at process# startup, not when reloading the sapnwrfc.ini file at a later point.
# By default, all trace files are written into the current working# directory of the process. If you want to change that location, use#RFC_TRACE_DIR=/absolute/path/to/tracedir
# By default, the NW RFC library creates one trace file per thread, in# order to avoid multiple threads interleaving their trace output.# If you want one trace file for the entire process, specify#RFC_TRACE_TYPE=PROCESS
# When tracing data that contains non-ISO-8859-1 characters, the trace# file becomes corrupted. In that case use the following parameter to# change the file encoding of the trace file. Possible values are# UTF-16 and UTF-8. If the parameter is not specified, the default platform# encoding is used, which is CP1252 or ISO-8859-1 on most Windows systems,# and UTF-8 on most Linux systems.# On Windows UTF-16 shows better performance than UTF-8, because no additional# conversion is required. On Linux, UTF-8 is recommended.RFC_TRACE_ENCODING=UTF-16
/*===================================================================*/* Destination Sections */* */*===================================================================*
/*===================================================================*/* */* The following is a list of all supported parameters. */*===================================================================*
# 1. General Connection parameters# These can be used with client and server programs
# SAPROUTER : If the connection needs to be made through a firewall via a SAPRouter, specify the SAPRouter parameters in the following format: /H/hostname/S/portnumber/H/# SNC_LIB : Full path and name of third-party security library to use for SNC communication (authentivation, encryption and signatures) Alternatively you can set the environment variable SNC_LIB.# SNC_MYNAME : Token/identifier representing the external RFC program# SNC_PARTNERNAME : Token/identifier representing the backend system# SNC_QOP : One of the following values: 1 Digital signature 2 Digital signature and encryption 3 Digital signature, encryption and user authentication 8 Default value defined by back-end system 9 Maximum value that the current security product supports# TRACE : One of 0(off), 1(brief), 2(verbose), 3(full)# PCS : "Partner character size". In 99.9% of the cases you don't need to bother with that. During the initial handshake the RFC library obtains the correct value from the backend and uses it from then on. One rare usecase is as follows: you know that the backend is Unicode and want to use a non-ISO-Latin-1 username or password for the initial logon. As the initial handshake is done with ISO-Latin-1, the characters in username/passwd would break, resulting in a refused logon. In that case set PCS=2 and the RFC library will use Unicode for the initial handshake.# CODEPAGE : Similar to PCS above. You only need it if you want to connect to a non-Unicode backend using a non-ISO-Latin-1 username or password. The RFC library will then use that codepage for the initial handshake, thus preserving the characters in username/password. A few common values are: 1401: ISO-Latin-2 1500: ISO-Latin-5/Cyrillic 1600: ISO-Latin-3 1610: ISO-Latin-9/Turkish 1700: ISO-Latin-7/Greek 1800: ISO-Latin-8/Hebrew 1900: ISO-Latin-4/Lithuanian/Latvian 8000: Japanese 8300: Traditional Chinese 8400: Simplified Chinese 8500: Korean 8600: Thai 8700: ISO-Latin-6/Arabic However, please note that these values can be customized in the backend. Better consult the backend sysadmin first, as otherwise things may go terribly wrong...# NO_COMPRESSION : By default the RFC protocol compresses tables, when they reach a size of 8KB or more. On very rare occasions you may want to turn this off, for example if you are transporting huge integer/binary tables with "random" data, where compression would have no effect except for burning CPU...# ON_CCE : "On Character Conversion Error". What shall the NW RFC lib do, when it encounters a character that does not exist in the target codepage, a broken character or a control character (0x00 - 0x19)? This parameter can take three values: 0: Abort with an error message (default behaviour). Note that in this case control characters (e.g. tabulator, carriage return or linefeed characters) are not considered "illegal" and will therefore not cause an abort. 1: Copy the character in a "round-trip compatible way". The resulting output character may be "garbage" in the target codepage, but when converted back to the source codepage, it will be the original character. 2: Replace the character with a substitute symbol (usually a # character). Note that in this case the control characters are replaced as well. If you need the control characters, then you'll have to use option 0 or 1, depending on whether you want the NW RFC Lib to abort the call in case of broken characters or not.# CFIT : "Conversion Fault Indicator Token". The substitute symbol used if ON_CCE=2. Needs to be given as hexadecimal value of a Unicode codepoint. The default is 0x0023 ("# character").
# 2. Parameters used in client programs
# USER : Username# PASSWD : Password# CLIENT : The Client or "Mandant" to which to logon.# LANG : Logon Language. Either specify the two-character ISO-Code (like EN for English, KO for Korean) or the one-character SAP-specific code (like E for English, 3 for Korean). Note that the ISO-codes are case-insensitiv, while the SAP codes are not! So 'D' logs you on in German, while 'd' logs you on in Serbian, if that language is installed in your system... # MYSAPSSO2 : Use this parameter instead of USER&PASSWD to log on with an SSO2 ticket (Single-Sign_On) or with an "Assertion" ticket (starting with backend release 7.00).# GETSSO2 : Set this to 1, if the backend should generate an SSO2 ticket for your user. If RfcOpenConnection() succeeds, you can retrieve the ticket with RfcGetPartnerSSOTicket() and use it for further logons to systems supporting the same user base. !!! Note: No longer supported! SAP systems shall no longer issue tickets during user logon!!!# X509CERT : Use this parameter instead of USER&PASSWD, if you want to logon with an X.509 certificate. The certificate needs to be Base64 encoded and needs to be mapped to a valid user in the backend's user configuration.# EXTIDDATA : Old logon mechanism similar to SSO. No longer recommended.# EXTIDTYPE : See EXTIDDATA.# LCHECK : If you set this to 0, RfcOpenConnection() only opens a network connection but does not perform the logon procedure. I.e. no user session will be created inside the backend system. Note that such a connection is not particularly useful: the only function module you can execute over it is RFC_PING...# USE_SAPGUI: Specifies whether a SAPGui should be attached to the connection. Some (old) BAPIs need this, because they try to send screen output to the client while executing. Possible values are: 0: no SAPGui (default) 1: attach a visible SAPGui. 2: attach a "hidden" SAPGui, which just receives and ignores the screen output. Note that for values other than 0 a SAPGui needs to be installed on the machine, where the client program is running. This can be either a normal Windows SAPGui or a Java Gui on Linux/Unix systems. Note on USE_SAPGUI=2: this type has a negative performance impact. If you are using only one function module that needs a Gui, and a large number of "normal" function modules, you should consider the following alternatives: a) Open the connection with USE_SAPGUI=1, and immediately after each RFC call that may invoke SAPGui, make an RFC call to the FM SYSTEM_INVISIBLE_GUI on the same connection to hide the SAPGui. Call your other FMs as usual. b) Open two connections, one without USE_SAPGUI parameter and one with USE_SAPGUI=2. Use the first connection for executing all "normal" FMs and the second connection whenever you need to call the FM that uses the Gui.# ABAP_DEBUG: Can be used for R/3 systems with release < 6.20, where "external breakpoints" are not yet available. The connection is opened in debug mode and the invoked function module can be steped through in the debugger. Possible values: 0: no debugging (default) 1: attach a visible SAPGui and break at the first ABAP statement of the invoked function module. Note that for debugging a SAPGui needs to be installed on the machine, where the client program is running. This can be either a normal Windows SAPGui or a Java Gui on Linux/Unix systems. For backend releases >= 6.20 use "external breakpoints" instead (see note 668256), as this is more convenient and allows the debugger to run on any host, not only the host on which the RFC client program is running.
# In addition you need parameters from one of the following two groups:
# 2.1 Parameters for direct application server logon
# ASHOST : Hostname of the application server.# SYSNR : The backend's system number. (E.g. "01")
# 2.2 Parameters for load balancing
# MSHOST : Hostname of the message server, which is doing the loadbalancing.# MSSERV : Not needed in most cases. Specify this parameter only, if the message server does not listen on the standard service "sapms<SysID>", or if this service is not defined in the services file and you need to specify the network port directly. Note: on Unix the services are defined in /etc/services, while on Windows they are defined in C:\WINDOWS\system32\drivers\etc\services.# R3NAME or SYSID : The backend's system ID. (E.g. "H9C"). If this parameter is not specified, the value of DEST is used instead.# GROUP : The logon group from which the application server should be chosen. If this parameter is not specified, "PUBLIC" is used.
# 3. Parameters used in server programs
# GWHOST : Hostname of the RFC gateway at which to register. Usually some application server host.# GWSERV : Either specify "sapgw<SysNr>" or the port number directly, if that service is not defined in the services file. (Also see MSSERV.)# TPNAME or PROGRAM_ID : The program ID used to identify the SM59 RFC destination, for which we want to receive requests.
Related articles