SAP .Net Nco 3.0.18 Windows 全平台 32bit 64bit

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