Release Notes for SAP .NET Connector (NCo)
==========================================
Please read the license terms and release notes carefully.
--------------------------------------------------------------------------------
This product is property of SAP SE. You are granted usage of this product in
your development environment. Deploying this product with your application in a
production environment is only valid with the sufficient amount of SAP Software
Licenses according to the terms and conditions of SAP Software.
THIS SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.
SAP SE further does not warrant the accuracy or completeness of the information,
text, graphics, links or other items contained within these materials. SAP SE
shall not be liable for any special, indirect, incidental or consequential
damages, including without limitation, lost revenues or lost profits, which may
result from the use of these materials. The information in this software is
subject to change without notice and does not represent a commitment on the
part of SAP SE in the future.
--------------------------------------------------------------------------------
Release Notes 3.0.18:
* Bugfix: codepage converters
When calling function module in a backend system with a blended codepage such
as 6100 and the function module contained a structure parameter with
character-like fields (CHAR, NUMC, DATE, etc.), then the value of those fields
was truncated to half its length, because the codepage converter has provided
the an incorrect result length, and thus not the full byte result was
transferred to the backend system.
* Bugfix: communication runtime
With NCo 3.0.16 and 3.0.17, data compression and delta management was always
turned off, if the backend system had ABAP release 7.02 or higher. This was
caused by a bug in the handshake that determines the capabilities of the
partner system. Thus, performance was decreased significantly in networks with
high latency.
* Bugfix: Server authorization checks
If an NCo server program uses the parameter SNC_PARTNER_NAMES, it could happen
that a backend system was refused access to the server program, even though its
SNC name was included in the SNC_PARTNER_NAMES value. NCo used to do a string
comparison between the SNC name specified 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".
* Bugfix: Destination Monitor
When using CustomDestination instances, the RfcDestinationMonitor could contain
duplicate entries, if different CustomDestination instances were created from
the same parent.
* Bugfix: default values for decimal fields
When providing default values for a parameter of data types like FLOAT, BCD, or
DECF16 in a function module definition in ABAP, which is retrieved via an
RfcRepository, the value was ignored, if the Culture used for the NCo program
is not using a dot as decimal separator. NCo was using the Culture specific
conversion of string values for those numbers, but should have interpreted it
Culture independently, which is the case now.
* Bugfix: IPv6 communication
When using IPv6 and configuring a load balanced connection to a message server,
the list of servers for SNC was simply empty so that NCo fails to establish
a connection to that system. Find more details in SAP Note 2331363.
* Enhancement: communication stability
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.
* Enhancement: Runtime behavior
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.
* Enhancement: SapLogonIniConfiguration
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
* Enhancement: Server API
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.
* Enhancement; Exception handling
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 API documentation for details about available the
codes.
* Enhancement: General configuration
With the property GeneralConfiguration.SocketBufferSize, it's possible to configure
the socket buffer size for all sockets used by NCo. See API documentation for
details. In addition, the GeneralSe
