0% found this document useful (0 votes)
24 views2 pages

Symptom: Version: 2, Released On: 20.07.2016

This document describes issues resolved in version 3.0.18 of the SAP .NET Connector. It details 6 issues addressed relating to codepage conversion, performance, SNC name comparison, duplicate monitor entries, default value handling, and IPv6 support. The solution is to upgrade to version 3.0.18 or later to resolve these issues.

Uploaded by

sabir
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
24 views2 pages

Symptom: Version: 2, Released On: 20.07.2016

This document describes issues resolved in version 3.0.18 of the SAP .NET Connector. It details 6 issues addressed relating to codepage conversion, performance, SNC name comparison, duplicate monitor entries, default value handling, and IPv6 support. The solution is to upgrade to version 3.0.18 or later to resolve these issues.

Uploaded by

sabir
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

SAP Note

2297083 - SAP .NET Connector Version 3.0.18


Component: BC-MID-CON-NCO (Basis Components > Middleware > Connector > SAP .Net Connector),
Version: 2, Released On: 20.07.2016

Symptom
1. When calling a function module in a backend system with codepage 6100 and the function module contains a structure
parameter with character-like fields (CHAR, NUMC, DATE, etc.), then the value of those fields is truncated to half its
length.
2. With NCo 3.0.16 and 3.0.17, performance has decreased compared to previous versions, in particular in networks with
high latency.
3. An NCo server program uses the parameter SNC_PARTNER_NAMES, and a backend system is refused access to the
server program, even though its SNC name is included in the SNC_PARTNER_NAMES value.
4. The RfcDestinationMonitor returns duplicate entries in its monitor list.
5. When providing default values for a parameter of data types like FLOAT, BCD, or DECF16, in a function module
definition in ABAP, the value is ignored and 0.0 is used instead.
6. It is not possible to establish an IPv6 connection to an ABAP system via message server, if SNC is used. The connection
simply fails.

Reason and Prerequisites


The problems above have been caused by the following issues in NCo 3.0.17:
1. The codepage converter for codepage 6100 returned an incorrect length (half of the correct length) for the converted
bytes.
2. During the RFC handshake, NCo accidentally "thinks" that the backend does not support data compression and delta
management, if the backend system has ABAP release 7.02 or higher, and therefore turns off those capabilities.
3. NCo used to do a string comparison between the SNC name specified in SNC_PARTNER_NAMES and the SNC name
provided by the backend system. However, SNC names are not unique: they contain optional parts and may or may not
have spaces in certain places. E.g. the following two SNC names refer to the same "identity", even though the strings do
not match: "p/secude:CN=ABC, O=SAP-AG, C=DE" and "p:CN=ABC,O=SAP-AG,C=DE".
4. RfcCustomDestination instances are used and they are created from the same RfcDestination parent. Then, duplicates
could make it in the list for the monitor.
5. The Culture of the NCo program is not using a dot as decimal separator and the metadata is fetched dynamically from
the ABAP system in an RfcRepository. The stored default value is using a dot as decimal separator and is interpreted
Culture dependently and if the Culture uses e.g. a comma as decimal separator, parsing the value fails.
6. Due to a bug in the layer communicating with the message server, the IPv6 address list of available application servers
returned to the NCo layer was empty.

Solution
Upgrade to at least NCo 3.0.18, which is available on the download page under https://service.sap.com/connectors -> SAP
Connector for Microsoft .NET -> Download SAP Connector for Microsoft .NET Version 3.0.
Choose the version for .NET 4.0, when using the .NET runtime 4.0, 4.5, 4.5.1, or 4.5.2, and the version for .NET 2.0, when
using the .NET runtimes 2.0, 3.0, or 3.5.
1. The codepage converter has been corrected to provide the correct result length, and the full byte result is transferred to
the backend system.
2. NCo now recognizes the capabilities of the backend system correctly during RFC handshake.
3. NCo now converts all SNC names into a unique binary representation (SNC ACL Key) and makes a binary comparison of
the keys.
4. When processing RfcCustomDestination instances for the RfcDestinationMonitor, it is made sure that no duplicate entry
is created.
5. NCo now uses a Culture independent parsing of the default values for decimal types in parameters.
6. NCo does now retrieve the correct list of application servers from the layer below. See note 2331363 for details.
In addition, the following enhancements have been added:
1. If an NCo client program calls a function module, and the function module attempts an RFC Callback (CALL FUNCTION
... DESTINATION 'BACK'), then NCo would formerly throw a NotSupportedException, which would a) cause an error
"Connection closed (no data received)" in the backend and b) potentially abort the client program, if the programmer
did not expect such an exception. Now NCo returns a SYSTEM_FAILURE with detail text "Callbacks from ABAP are not
supported" to the backend and throws an exception of type RfcAbapRuntimeException, which a client program needs to
be prepared for anyway.
2. When trying to use the saplogon.ini file for providing logon parameters via SapLogonIniConfiguration, NCo now
additionally checks the registry keys \\HKLM[HKCU]\SOFTWARE\SAP\SAPLogon\Options\ConfigFileOnServer for
the location of the saplogon.ini file. (This registry key has been introduced with SAPLogon 7.30 in order to provide the
ability to use one centrally maintained saplogon.ini file on a Windows Network Share instead of having to maintain
potentially thousands of files on every end-user's frontend machine.)
The locations, where NCo looks for the saplogon.ini file, are now as follows:
1. File given in environment variable SAPLOGON_INI_FILE
2. File SAP\Common\saplogon.ini in the current user's AppData directory
3. The %WINDIR% directory (usually C:\WINDOWS)
4. File given in registry key SAP\SAPLogon\Options\ConfigFileOnServer, where NCo checks both
HKEY_CURRENT_USER and HK_LOCAL_MACHINE, and both \SOFTWARE and \SOFTWARE\Wow6432Node
3. If an NCo program loads the DLLs sapnco.dll/sapnco_utils.dll not from the standard DLL search path, but for
example via the Shadow Copy Feature (e.g. if NCo is used in an Excel plugin), and this NCo program needs to process
function modules that have parameters of type DecFloat (ABAP types decfloat16/decfloat34 or DDIC types
DF16_RAW/DF34_RAW/DF16_DEC/DF34_DEC), then the program could abort with the error message "decfloat
shared library could not be loaded". In order to avoid this, the installation directory of NCo had to be added explicitly to
the PATH. Now NCo will always try to load the library libicudecnumber.dll from its own installation directory.
Note: this is achieved via the Win32 Kernel API SetDllDirectory(). If this causes unwanted side-effects in your program,
so that maybe other required DLLs can no longer be found, you can turn off this feature using the general configuration
parameter LoadDecFloatLibFromInstallDir=false.
4. The exceptions of NCo are now offering an ErrorCode property, in which some more detailed information about the
cause for the exception is encoded. This allows programmatic interpretation of this concrete exception without parsing
the message text, which is in particular useful, when error info of low level components is forwarded by the NCo layer.
See the NCo3 API documentation for details about the available codes.
5. With the property GeneralConfiguration.SocketBufferSize, it is possible to configure the socket buffer size for all sockets
used by NCo. See the NCo3 API documentation for details. In addition, the GeneralSettings section in app.config has
been extended to support socketBufferSize.
6. NCo now sends CPIC keep alive pings in regular time intervals to the SAP gateway during long running RFC clientc calls
in order to prevent firewalls and other network devices from closing the used underlying TCP/IP socket after some
low level network connection idle timeout, although the respective RFC call is still being executed and processed at the
target AS ABAP back-end system. Additionally, this new CPIC keep alive ping feature also helps with promptly detecting
network errors and the loss of the RFC communication partner, so that an appropriate RfcCommunicationException can
be thrown in such cases.
7. Starting with NCo 3.0.18, Windows 10 is a supported platform for the .NET 40 runtime variants.

Software Components
Software Component From To And subsequent

SAP .NET CONNECTOR 3.0 3.0

This document refers to


SAP Note/KBA Component Title

856863 BC-MID-CON-NCO SAP NCo Release and Support Strategy

2352392 BC-MID-CON-NCO SAP .NET Connector Version 3.0.19

2331363 BC-CST-LG IPv6 RFC connection using SNC

2216511 BC-MID-CON-NCO SAP .NET Connector Version 3.0.17

This document is referenced by


SAP Note/KBA Component Title

2216511 SAP .NET Connector Version 3.0.17

2352392 BC-MID-CON-NCO SAP .NET Connector Version 3.0.19

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy