|
|||||||
SAP Java Connector 3.0 |
|||||||
Release notes 3.0.11 | |||||||
Bugfix for lost scope types when using JCoCustomDestinations | |||||||
Scope types were lost when using JCoCustomDestination instances. Remote function calls via a
JCoCustomDestination instance were always executed within the default scope type context. In
case that the current JCo context was stateful, this resulted in the same RFC connection being used for all
JCoCustomDestination instances and therefore possibly destroyed the integrity of an LUW
(Logical Unit of Work).Note: This bug was present in JCo release 3.0.10 only. | |||||||
Bugfix for hanging JCoServer connections | |||||||
If an RFC request was immediately sent to a just registered JCoServer RFC connection, this newly
registered RFC server connection could have get into an unrecoverable hanging situation before the incoming
RFC request could have been dispatched and processed. At the communication partner side the RFC request did
not return and the active RFC connection kept hanging in status 'connected'.Note: This bug was present in JCo release 3.0.10 only. | |||||||
Bugfix in connection pool management at program termination | |||||||
When shutting down the JCo application program, pooled idle and still open RFC connections were not closed
properly before the application program terminates. This resulted in these pooled RFC connections being
interrupted instead with getting CPIC error messages"Connection to partner '<host>:<port>' broken / Connection reset by peer"
at the RFC communication partner side.
| |||||||
Bugfix in method JCoRepository.save() | |||||||
A java.lang.NullPointerException was thrown when saving a JCoRepository instance
which contained a remote function module template with an empty import parameter list.
| |||||||
Bugfix in method JCoRepository.load() | |||||||
The meta data information that specifies if a parameter is an optional parameter or not was lost after loading
a JCoRepository instance from a Java I/O character stream. Calling method
JCoListMetaData.isOptional(<name|index>) on any parameter meta data that was loaded by a
JCoRepository always returned false in this case.
| |||||||
Bugfix in error handling when logging on to non-Unicode ABAP systems | |||||||
A java.lang.NullPointerException was always thrown when trying to logon to a non-Unicode ABAP
system with using one of the new logon languages that are available in Unicode SAP systems only. Now an
appropriate JCoException with error group RFC_ERROR_LOGON_FAILURE will be thrown in
such a scenario instead.
| |||||||
Enhancement with transferring the caller program name to the RFC communication partner | |||||||
A caller program name is now sent to the communication partner when opening a new RFC connection. It can be
retrieved from the RFC attributes at the communication partner side. The caller program name 'SAPJCo30'
is used per default. An arbitrary custom program name can be set by specifying the Java system property
-Djco.program_name=<ProgramName> as a JVM startup parameter.
| |||||||
Improvement at starting JCoServer instances | |||||||
Starting JCoServer instances has been improved with now doing lazy initializations of RFC repository
destinations and with ignoring and tolerating RFC communication errors at startup.
| |||||||
Enhancement at runtime initialization with adding a multi-platform library loading feature | |||||||
The JCo runtime initialization has been enhanced with a multi-platform library loading feature which allows
to create a central JCo installation that can be started on various operating systems and with using different
Java Virtual Machines without any configuration change. For example, JCo can now be installed on a single
central network share and be used from several operating systems like Windows, Linux or Mac OS X simultaneously.
Or one can work locally with a single JCo installation and use a 32-bit and a 64-bit JVM simultaneously or
choose one or the other JVM alternately at will. For using this feature it is only required to put all desired platform dependent JCo JNI libraries in specifically named subdirectories of the directory where the sapjco3.jar file resides,
e.g. <sapjco3.jar_DIR>\ntamd64\sapjco3.dll , <sapjco3.jar_DIR>\ntintel\sapjco3.dll
or <sapjco3.jar_DIR>/linuxppc64/libsapjco3.so. See the Configuration and Requirements documentation chapter "Runtime initialization" for further details and the list of valid platform specific subdirectoy names. | |||||||
New APIs | |||||||
The following new APIs have been added and are available for general use:
See the API Documentation for details.
| |||||||
Release notes 3.0.10 | |||||||
Bugfix for hanging JCoServer connections | |||||||
Under certain circumstances RFC connections to a JCoServer could have get into an unrecoverable
hanging situation. Then RFC requests to a registered JCoServer instance did not return and the
appropriate RFC connection could not be canceled but kept hanging infinitely in any status, even in status
'disconnecting'. Please see SAP note 1791529
for further details.
| |||||||
Bugfix removing a memory leak in the JCo session management | |||||||
A memory leak was removed within the internal JCo session management. The memory leak occurred after a custom
SessionReferenceProvider implementation had been registered at the JCo runtime environment. Its
method SessionReferenceProvider.isSessionAlive(sessionId) was never called which resulted in
numerous JCo session objects not getting freed although the sessions already had expired.Note: This bug was present in JCo release 3.0.9 only. | |||||||
Performance bugfix at RFC request dispatching to JCoServers | |||||||
In case of RFC server registrations to some SAP gateway taking a long time for whatever reason (e.g. because the relevant
SAP AS ABAP system or SAP gateway is currently in shutdown or startup phase, the host itself is not reachable via network
or due to network performance issues), the whole RFC request dispatching to all running JCoServer instances
was extremely slow and therefore lead to a performance degradation also of those registered JCo RFC servers and
related SAP AS ABAP systems who actually were not connected to the problematic SAP gateway host.
| |||||||
Support of extern-to-extern RFC communication | |||||||
Support for calling external RFC server programs as well as support for receiving RFC requests from external RFC client
programs has been added. For addressing external RFC server programs the property jco.client.tpname , which specifies the appropriate
registered server program ID, can now be configured for a destination, which then can be used for calling RFC programs
that are registered at a SAP gateway. Additionally, the property jco.destination.repository_destination
should be configured and refer to some destination targeting an appropriate SAP AS ABAP system for retrieving
potentially required RFC meta data.Receiving RFC requests from external RFC client programs is not allowed by default for security reasons. A JCoException with error group JCoException.JCO_ERROR_SYSTEM_FAILURE will be thrown to both
RFC communication partners everytime a JCo RFC server receives such an RFC request. For allowing external RFC client
program calls to be processed by a JCo RFC server an administrator needs to specify the Java system property
as a JVM startup parameter to be already available at JCo
framework initialization time. Please see SAP note 1877907
for further details.Caution: For security reasons SAP discourages to run such extern-to-extern RFC communication scenarios. External or registered RFC server programs are not able to check and authenticate incoming RFC requests from external non-ABAP programs with regard to the pure RFC protocol data. Each of such external RFC requests must be regarded as insecure. | |||||||
Enhancement with providing support for local repository storages | |||||||
A new feature has been added allowing to save and load a complete JCoRepository instance in JSON format
to and from standard Java I/O character streams.
| |||||||
Bugfix for StackOverflowError in JCoRepository | |||||||
Depending on the defined DDIC (Data Dictionary) types and structures and on the defined RFM (Remote Function Module)
interfaces at SAP AS ABAP system side a java.lang.StackOverflowError could have been thrown when a
JCoRepository instance was storing the queried RFC meta data into its internal MetaDataStorage
instance.
| |||||||
Bugfix for avoiding connection interruptions at long running stateful RFC server requests | |||||||
Long running stateful RFC server requests from ABAP to Java were always interrupted after the configured session timeout
interval (default is 10 minutes) without checking at the registered SessionReferenceProvider if the session
would be still alive nevertheless.Note: This bug was present in JCo release 3.0.9 only. | |||||||
Bugfix in method JCoServerContextInfo.getCallType() | |||||||
Method JCoServerContextInfo.getCallType() always returned null instead of the current type of
the incoming RFC request in form of a JCoServerCallType enumeration object.
| |||||||
Bugfix in RFC attribute handling when communicating with non-Unicode ABAP systems | |||||||
A java.lang.NullPointerException was always thrown from the internal JCo method getAttributes()
when trying to communicate with a non-Unicode ABAP system that uses an ambiguous blended code page like SAP code page 6110.
| |||||||
Bugfix for querying structure and record meta data from a JCoRepository in roundtrip optimization mode | |||||||
A JCoRepository instance in roundtrip optimization mode (i.e. the middleware property
jco.use_repository_roundtrip_optimization was set to 1 at its creation time) always returned
null when querying structure or record meta data from an SAP AS ABAP system with methods
JCoRepository.getStructureDefinition(String name) and JCoRepository.getRecordMetaData(String name) .
| |||||||
Bugfix at getting a repository destination ID | |||||||
Under some special circumstances the method JCo.getRepositoryDestinationID(String destinationID) returned
null indicating that the respective JCoDestination instance for the given destinationID
has not been used for repository queries yet although this is not true.
| |||||||
New APIs | |||||||
The following new APIs have been added and are available for general use:
See the API Documentation for details.
| |||||||
Deprecated APIs | |||||||
The following APIs have been declared deprecated and will be removed in a future version of JCo:
The APIs have either become obsolete or there is an equivalent substitution available for them. See the API
Documentation for details.
| |||||||
Release notes 3.0.9 | |||||||
Bugfix removing a memory leak in the JCoTimeoutChecker thread | |||||||
A memory leak was removed at the internal destination management within the JCoTimeoutChecker thread. This memory
leak was created each time that the registered DestinationDataProvider instance updated or deleted a previously
used destination from its destination configuration repository.Note: This bug was present in JCo release 3.0.8 only. | |||||||
Bugfix for CPIC communication error "client with wrong appc header version rejected" | |||||||
A program error in the underlying native CPIC communication software layer has been fixed that sometimes led to RFC connections
getting broken. In this case a JCoException with error group JCoException.JCO_ERROR_COMMUNICATION
was thrown and contained the CPIC error message "client with wrong appc header version rejected". Please see SAP note
1664732 for further information.
| |||||||
Bugfix for RFC callback handling | |||||||
RFC callbacks to the JCo framework were not handled correctly. Although receiving an RFC callback is not an error by itself,
there was always an error of type RfcGetException with message "Received a callback from the communication partner"
logged in the RFC error log file dev_jco_rfc.trc . Despite this log entry, no error or exception was thrown to
the JCo application or signalled to the communication partner. Even if the requested RFC function module was not available
and could not be processed, this was not done and the RFC callback was ignored. If the delta management for RFC table parameters
was active, the erroneous RFC callback handling could furthermore have caused lost table data and table data inconsistencies
between the two communication partners.Now RFC callbacks are handled correctly with throwing a JCoException of error group
JCoException.JCO_ERROR_SYSTEM_FAILURE , if the requested function module is not available, and only in this case
an error is logged to the RFC error log file dev_jco_rfc.trc .
| |||||||
Bugfix for the middleware property 'jrfc.client_connect_timeout' having no effect | |||||||
RFC logon attempts to an SAP ABAP system have not been interrupted if they were running too long and exceeded the time span
that was specified by the JCo middleware property jrfc.client_connect_timeout (default is 60 seconds). Now a
JCoException with error group JCoException.JCO_ERROR_TIMEOUT will correctly be thrown in such a
situation, thus interrupting the currently running RFC logon attempt.Note: This bug was present from JCo release 3.0.5 to 3.0.8 only. | |||||||
Bugfix for setting the default or an empty value into fields of type XSTRING | |||||||
After calling method JCoRecord.setValue([name|index], null) or
JCoRecord.setValue([name|index], new byte[0]) for setting the default or an empty field value on fields of
type JCoMetaData.TYPE_XSTRING , the field was not cleared and empty afterwards but contained one 0-byte value,
i.e. a byte array of length 1 (byte[] = { 0x00 } ). This 0-byte value was also sent via RFC to the
communication partner, if the JCoMetaData.TYPE_XSTRING field was part of an importing, changing or tables
parameter in a JCoFunction or a JCoRequest object.
| |||||||
Bugfix for writing JCo traces when using a JCoServerRequestHandler | |||||||
When using the RFC request/response model at the JCoServer side with a JCoServerRequestHandler
instance processing the incoming RFC requests, JCo neither traced the API calls to the handleRequest(...)
method invocations nor any meta data or content data of these RFC requests, even if the respective JCo trace level was
set for writing such information.
| |||||||
Improved JCo initialization for recognizing additional Java system properties | |||||||
In addition to setting the properties jco.session_timeout and jco.session_timeout.check_interval
with the method JCo.setProperty(String key, String value) , these two properties can now also be set as Java
system properties with the -D argument when starting the JVM and they will be recognized at JCo initialization.
| |||||||
Support of user/password logon while using SNC | |||||||
With the new destination logon property jco.client.snc_sso it is possible to turn off the Single Sign On (SSO)
mechanism of SNC by setting it to the value 0 . Thus, it is possible to log on to an SAP ABAP back-end system
with some other user ID not fitting to the SNC identity, while SNC can still be used for encrypting the network
communication. As a prerequisite, a minimum SAP system kernel patch level is required as mentioned in SAP note
1701870.
| |||||||
Support of logon with external user identification data | |||||||
The destination properties jco.client.extid_type and jco.client.extid_data have been added
for supporting to log on with external user identifaction data to an SAP ABAP back-end system. For this logon variant it is
mandatory to use SNC.
| |||||||
Improved logon procedure for languages available in Unicode SAP systems only | |||||||
Some languages like Armenian, Georgian, Vietnamese, Macedonian and many others are available in Unicode SAP systems only.
If logging on with such a language to an SAP ABAP back-end system, it was mandatory to specify an additional destination
property like jco.client.codepage with indicating a unicode communication type, otherwise such logons failed
with an JCoException.JCO_ERROR_LOGON_FAILURE showing the error message "Select one of the installed languages"
although the appropriate language was installed.This logon procedure has been improved so that it does not require any additional communication code page destination property anymore in this case. The unicode communication type is now automatically detected and used for logging on with such new SAP system language keys. Please see SAP note 895560 for more details on languages that are only available in Unicode SAP systems. | |||||||
New APIs | |||||||
The following new APIs have been added and are available for general use:
See the API Documentation for details.
| |||||||
Release notes 3.0.8 | |||||||
Bugfix removing a memory leak in JCo native JNI layer | |||||||
A memory leak in the native layer existed when receiving data from the back-end. Thus, more and more native memory was allocated and the process could run out of memory. Please check SAP note 1595477 for details. | |||||||
Bugfix removing a memory leak in JCoRepository | |||||||
Under certain circumstances, a memory leak was caused by the internal destination management within a repository. This
could have happened when creating many JCoCustomDestination instances from destinations, which did not
have an associated repository yet. In this situation the first call to JCoCustomDestination.getRepository()
on each of such a JCoCustomDestination instance created a memory leak in the Java heap being located in the
returned JCoRepository object.
| |||||||
Bugfix for connection reset handling against R/3 release 4.6C systems | |||||||
When communicating with an R/3 release 4.6C system which is running with a 4.6D kernel, the reset of pooled connections was not working as expected. Instead of simply resetting the context in the back-end, the connection was closed and re-established again. In networks with high latency this led to an undesired performance degredation. This was caused by wrongly checking the partner release number instead of the kernel release number. | |||||||
Bugfix in JCoServer restart mechanism when processing update events | |||||||
When a server had to be restarted due to a change in the configuration being signaled by an update event, the server did not come up, but was stopped instead. In particular, simply adjusting the trace flag led to this situation. This was caused by the fact, that the new server instance was already started, before the old one had been shutdown completely. | |||||||
Bugfix for usage of the destination and server data connection property 'gwserv' | |||||||
If specifying a gateway service with the destination data connection property 'jco.client.gwserv' or with the server data connection property 'jco.server.gwserv', all property string values of format sapgw##s (with # being a placeholder for a digit) were not accepted and an exception was thrown or an error message was logged saying that the gateway service parameter needs to be of a different format. Contrary to this error message, gateway service parameters of format sapgw##s are valid and may be specified alternatively to parameter values of format sapgw## or #### for directly specifying the TCP port number. | |||||||
Bugfix for JCoCustomDestination instances not getting invalidated | |||||||
A JCoCustomDestination instance was never invalidated and remained usable, even if the destination configuration,
which it is based on, was changed or deleted. Now a JCoException with error group
JCoException.JCO_ERROR_DESTINATION_DATA_INVALID will correctly be thrown, if a JCoCustomDestination
instance will be used in such a situation.
| |||||||
Bugfix for SSO-Tickets and X.509-Certificates not being used with JCoCustomDestination | |||||||
New SSO-Tickets or X.509-Certificates that are set for a JCoCustomDestination instance were not used, in case
that there was already another SSO-Ticket or X.509-Certificate previously being used for this destination. The previously
set SSO-Ticket or X.509-Certificate was cached and still used instead of the new one. This led to a JCoException
with error group JCoException.JCO_ERROR_LOGON_FAILURE being thrown, if the SSO-Ticket or X.509-Certificate
has been expired in the meantime.
| |||||||
Bugfix for wrong repository destination being used with JCoCustomDestination | |||||||
After setting a repository destination with method JCoCustomDestination.setRepositoryDestination(JCoDestination) ,
the JCoCustomDestination instance used the passed destination's client connections instead of the desired
repository connections. Depending on the destination configuration this might have led to a wrong repository being
returned on a subsequent call to JCoCustomDestination.getRepository() and/or wrong targeted connections
and logon parameters being used for future meta data queries of the returned JCoRepository instance.
| |||||||
Improved JCoCustomRepository destination setting | |||||||
The setting of a destination for a JCoCustomRepository instance has been improved. Now it is possible to change
the destination for remote meta data queries with method JCoCustomRepository.setDestination(JCoDestination) .
Before this improvement, it was only allowed to set a destination once and subsequent calls to
JCoCustomRepository.setDestination(JCoDestination) led to a JCoRuntimeException with error group
JCoException.JCO_ERROR_ILLEGAL_STATE being thrown.
| |||||||
Bugfix at creation of JCoDestinationMonitor objects | |||||||
The method JCoDestination.getMonitor() threw a JCoRuntimeException with error group
JCoException.JCO_ERROR_RESOURCE saying that the destination would not be initialized or would have been already
removed, although this was not true and the JCoDestination instance was actually valid. This error situation
only occurred if the JCoDestination instance's getMonitor() method was called for the first time
and there was no connection pool available for this destination at that time.
| |||||||
Bugfix in JCoDestinationMonitor returning wrong data | |||||||
JCoDestinationMonitor instances returned wrong data after the connection pool being associated to the monitored
JCoDestination instance was temporarily removed due to inactivity on this destination. In such an error
situation the JCoDestinationMonitor instance always reported that there would not be any open connection and
consequently the number of pooled and used connections would both be 0 . But that potentially did not reflect
the real situation where several new connections for the monitored destination meanwhile might have been opened again.
| |||||||
New API | |||||||
The following new API has been added and is available for general use:
See the API Documentation for details.
| |||||||
Bugfix for creation of JCoRepository objects | |||||||
The method JCoDestination.getRepository() threw a JCoRuntimeException with error group
JCoException.JCO_ERROR_CONFIGURATION saying that the configuration for this destination would be invalid
in case there was a repository user defined, but no standard user, user alias or logon ticket were configured. Contrary
to this error message, a destination configuration containing only a repository user is sufficient at least for the
creation of and usage by a JCoRepository instance.
| |||||||
Improved default behavior with connection pooling | |||||||
The default behavior regarding the connection pooling has been improved. If the DestinationDataProvider
does not specify the property jco.destination.pool_capacity for a certain destination, the default value
1 is used for this property now instead of 0 . This means that connection pooling is enabled
by default now and thus dramatically increases the performance of typical single threaded applications who do not care
about connection pooling.
| |||||||
Release notes 3.0.7 | |||||||
Support for scope types in the default implementation of the session reference provider | |||||||
The default implementation of the SessionReferenceProvider was re-implemented as DefaultSessionReferenceProvider and is now exposed in
com.sap.conn.jco.ext package and supports scopeTypes by default. If an application/infrastructure that uses the default implementation wants
to disable scopeType support again it has to register new DefaultSessionReferenceProvider(false) via the Environment class.
Find more details in the JavaDoc. | |||||||
Deprecations | |||||||
Some methods in the JCoDestinationManager , the JCoServerFactory , and JCo
have been deprecated. Adjust your coding accordingly so that you don't run into trouble, if those methods are
removed from the public API in future versions of JCo.
| |||||||
New APIs | |||||||
The following new APIs have been added and are available for general use:
See the API Documentation for details.
| |||||||
Bugfix in SimpleSessionReferenceProvider | |||||||
Under high load, an exception could occur signalling a concurrent modification within an internal HashMap. The exception
callstack could look like as follows:
java.util.ConcurrentModificationException at java.util.HashMap$AbstractMapIterator.checkConcurrentMod() at java.util.HashMap$AbstractMapIterator.makeNext() at java.util.HashMap$KeyIterator.next() at java.util.HashMap.analyzeMap() at java.util.HashMap.rehash() at java.util.HashMap.rehash() at java.util.HashMap.putImpl() at java.util.HashMap.put() at com.sap.conn.jco.rt.SimpleSessionRefProvider.jcoServerSessionPassivated() at com.sap.conn.jco.rt.DefaultServerWorker.callFinishedInternal() | |||||||
Bugfix in JCoRepository with regard to destination handling | |||||||
A repository is shared between several destinations that all establish own connections to the
ABAP system. The destination that is actually used for the lookup causes a JCoException with group
JCoException.JCO_ERROR_LOGON_FAILURE . This exception is thrown due to an incorrect configured repository
user/repository password combination or because the user is locked (e.g. due to running out of the validity period).
Hence, repository queries failed, as repeatedly the "bad" destination is used instead of switching
to the next valid one, which could be used successfully for the query, even though such a mechanism exists in the repository.
Moreover, it could happen that a working back-end user used for metadata lookup is locked after several metadata query tries,
and you will get the message "Password logon no longer possible" when trying to logon with this user.
| |||||||
Enhancement: special ThreadGroup for Threads created by JCo | |||||||
When JCo is creating Threads internally (e.g. in a JCoServer without a special JCoServerRunnable
implementation or for the Timeoutchecker thread), they are now assigned to a dedicated ThreadGroup belonging to JCo. Thus,
the threads are no longer belonging to random thread groups of the runtime environment, depending on the creation point in
time of the concrete thread.
| |||||||
Enhancement: DataProviderException | |||||||
Now, an implementation of DestinationDataProvider and ServerDataProvider may throw a DataProviderException to report an exceptional situation, it encountered while a certain configuration has been requested. | |||||||
Bugfix in JCoServer setup | |||||||
When using SNC for a JCoServer and using 9 as value for
jco.server.snc_qop , JCo complained wrongly about an invalid value.
This was due to a wrong range usage, when checking the properties: JCo used [0..8] instead of [1..9].
| |||||||
Bugfix in JCoServer transaction and unit processing setup | |||||||
When there is no JCoServerTIDHandler or no JCoServerUnitIDHandler set for a JCoServer ,
and a tRFC/qRFC or bgRFC unit is received by a server, a NullPointerException without descriptive
message is thrown. If such a handler is missing and a corresponding request shall be processed, JCo now throws a
a JCoRuntimeException with group JCoException.JCO_ERROR_ILLEGAL_STATE that provides a clarifying message.
| |||||||
Bugfix in JCoServer called by 3.1I ABAP Server | |||||||
Since JCo 3.0.5, if a 3.1I ABAP System made a request to a JCoServer, it caused an exception with a message similar to RFC_ERROR_SYSTEM_FAILURE: You cannot adjust the state of a ServerConnection with this method. | |||||||
Bugfix for deployment errors | |||||||
Sometimes a JCo standalone was deployed accidentally into a NetWeaver AS Java. This could lead to strange error situations that were randomly occuring. Hence, JCo standalone is now denying to be loaded within a NetWeaver AS Java. If JCo should be used within that environment, the embedded JCo variant should be used (can be referred to as tc/bl/jco/api, an application only needs to set this reference in its deployment descriptor). | |||||||
Bugfix for JCoSessionReferenceProvider server event jcoServerSessionFinished() | |||||||
In a stateless server context, the event method jcoServerSessionFinished() received always null as session ID and not
the expected session ID that was originally provided by the JCoSessionReference returned by jcoServerSessionStarted() .
| |||||||
Release notes 3.0.6 | |||||||
Connect failure on load balanced logon under heavy load | |||||||
Caused by a race condition, the JCo runtime could use wrong service if connection was being
established via the message server, that means using load balanced logon. In such cases,
JCo throws an exception with the following error text
LOCATION SAP-Gateway on host | |||||||
Data element names missing in metadata since JCo 3.0.5 | |||||||
If in a structure, table or function module a scalar type (e.g. CHAR, NUMC, etc) is refering to a data element, the name of that data element is not returned in getRecordTypeName() in JCo 3.0.5, though this worked fine in JCo 3.0.0 to 3.0.4. | |||||||
Bugfix in JCoRepository | |||||||
If a vector of a domain was looked up directly, it did not contain the linetype, hence was not handled like a table type properly. | |||||||
Bugfix for JCoCustomDestination | |||||||
A JCoDestination is associated with a scopeType via JCoDestinationManager.getDestination(destName, scopeType) .
When now creating a JCoCustomDestination from the retrieved destination, the scopeType
information is ignored, when executing a function module.
| |||||||
Enhancement for tracing | |||||||
When tracing at high trace levels and large data volumes, the memory footprint of JCo was
increasing stronger than necessary leading to OutOfMemoryErrors too early. Now, the
memory consumption has been reduced and such errors should come up only with even higher data
volumes.
| |||||||
Enhancement for session timout checking | |||||||
It was impossible to adjust JCo session timeout checking independently from the timeout interval.
This was changed by introducing jco.session_timeout.check_interval that allows specifying a value
in minutes and defaults to 5.
| |||||||
Roundtrip reduction for repository | |||||||
When JCo is looking up metadata in a back-end for a certain function module, it calls several function modules
providing metadata for the function and the involved structures. In slow networks, e.g. a VPN connection
crossing longer distances, this can lead to bad performance in case of design time scenarios, where the
repository cache is typically not filled and many roundtrips to the back-end are needed.
SAP note 1456826 introduces
RFC_METADATA_GET , with which the number of roundtrips per function is reduced to 1.
JCo now uses this function module, if it's available in the back-end and if the JCo property
jco.use_repository_roundtrip_optimization is set to 1. Please note, that you need
to adjust authorization profiles for your metadata user in that case.
| |||||||
Bugfix in XRfcParser | |||||||
When table type FOO has a table type BAR as line type and one of the rows of FOO contains simply an
empty table BAR, then an expeption occured that looks similar to:
JCO_ERROR_XML_PARSER: Parameter PARAM_FOO: After a value an end tag must follow. That did not
happen in "em> | |||||||
Bugfix in initialization of RFC parameter defaults | |||||||
RFC function module parameters might not have been initialized correctly when an ABAP system field
(e.g. SY-DATLO or SY-TIMLO ) was defined as its default value. This also
might have led to some ConversionException being thrown when trying to read these
values with the JCoParameterList.getValue() or the various JCoParameterList.get<type>()
methods.
| |||||||
Bugfix in server registration | |||||||
If a gateway is protected with a reginfo file, a JCoServer is not allowed
to register itself from a certain host and/or a certain program ID with that gateway. Unfortunately, the
JCoServer did not recognize such a registration failure as an unrecoverable configuration error,
and hence tried to re-register again immediately. This was certainly failing again, which was leading to
rapidly growing dev_jco_rfc.trc files.
| |||||||
Bugfix when degistering DestinationDataProvider | |||||||
When a DestinationDataProvider is deregistered from JCo, the connections established by
destinations created from this provider should be closed. However, this did not work for repository
connections. If afterwards the JCo application is terminated, the ABAP system wrote an
entry containing "SAP-RC=223" into the syslog.
| |||||||
Bugfixes in server configuration processing | |||||||
When processing changes in server configurations signalled by the ServerDataProvider , not all changes were recognized by the JCoServer .
Even if a change was recognized, and a running server was updated, it was no longer running after that update, but
was simply stopped. In case of restarts, the setting for the maximum restart delay time was ignored.
| |||||||
Documentation improved | |||||||
Documentation was added and enhanced at different locations, in particular in the cases mentioned below:
| |||||||
Release notes 3.0.5 | |||||||
New API and constant | |||||||
The following new API and constant have been added and are available for general use:
See the API Documentation for details.
| |||||||
NullPointerException in Delta Management on ABAP callbacks | |||||||
If an ABAP function module executes a function via destination BACK, a NullPointerException could be thrown
by delta management in JCo. The exception is raised only, if the function module invoked in ABAP has some table parameters.
| |||||||
Support of multiple repositories for a single JCoServer | |||||||
It is now possible to specify more than one repository for JCoServer and thus be able to
handle requests from various ABAP systems, even if requests base on incompatible function module definitions.
In order to define multiple repositories, JCo introduces a new configuration property: jco.server.repository_map .
Examples how to use it are available in the API documentation of ServerDataProvider .
| |||||||
Support of dynamic worker thread allocation for JCoServer | |||||||
It is now possible to specify the minimum and maxmimum number of worker threads that shall be used for a JCo Server
via the new server properties jco.server.worker_thread_min_count and jco.server.worker_thread_count.
Mor edetails are available in the API documentation of ServerDataProvider .
| |||||||
Invalid characters accepted for BCD | |||||||
When setting a value for a field that is containing a BCD value, and that value contains an invalid character, e.g. an 'a', this value is accepted without error instead of throwing an exception. | |||||||
Support for cancelling function invocations on session end | |||||||
When a function module invocation is lasting very long, and as a consequence the session, in which that call was executed, has been finished in the meantime, JCo now requests on the ABAP server that the function module execution shall be cancelled, in order to free resources. | |||||||
Loss of tRFC requests | |||||||
When executing multiple tRFCs in parallel threads, some of the tRFCs get lost without any error message. In particular, this can lead to data loss during IDoc communication between a JCo 3.0 based program and the ABAP back-end system. See also note 1438660. | |||||||
Performance improvement for stateless function module calls | |||||||
By default, function module invocations are done stateless within JCo 3.0. This means that the context in the ABAP back-end associated with a connection used for a function module invocation is reset after finishing the request. Unfortunately, this is much slower for many small requests than executing stateful due to the existing reset mechanism. With a small improvement within the JCo runtime the reset mechanism could be improved, but requires also an enhancement in the ABAP back-end side. If that enhancement is not available, the behavior will stay like before. Note 1433584 describes which kernel patch level is necessary for the ABAP server. | |||||||
Release notes 3.0.4 | |||||||
JCoException with text "Incorrect size of TID encountered [null]" thrown for synchronous client call | |||||||
If a destination is set to stateful, a qRFC call is executed, and afterwards a synchronous call is executed for the same destination, the JCoException with the message mentioned above is thrown though this should work fine without any problem. | |||||||
Exception JCO_ERROR_CONFIGURATION on JCoCustomDestination | |||||||
JCoException with the key JCO_ERROR_CONFIGURATION is thrown on a JCoCustomDestination, if the original JCoDestination it was created from does not contain any user authentication parameters. | |||||||
Unnecessary refresh on deregistration of DestinationDataProvider | |||||||
If a DestinationDataProvider is changed or removed, the JCo runtime refreshes the cached destinations. Due to a bug in the refresh operation, the instance of the DestinationDataProvider was used that was just in being deregistered, and not the new one as it should be. | |||||||
z/OS: ERROR hostname 'abcd' unknown | |||||||
Even though the technical connection to a certain host was working fine outside JCo, establishing a connection with JCo to an SAP system failed. This was caused by some EBCDIC/ASCII translation issues in a very low level API. See also note 1406061. | |||||||
Release notes 3.0.3 | |||||||
Support for dealing with bgRFC units | |||||||
It is now possible to interact with SAP AS ABAP back-ends supporting the successor of tRFC and qRFC
completely in native bgRFC mode, both for client and server applications. Certainly, the back-end release
has to support bgRFC as well. For details check out the API documentation of the interfaces and enums below:
| |||||||
Support for ABAP class exceptions | |||||||
Starting with ABAP application server release 7.11 it is possible to use function modules throwing an
abap class exception between two ABAP systems. With 7.20 the support was extended to connectors as well,
including JCo 3.0. Hence, more context of the application in the ABAP system can be transferred in
such an exception object, which makes it easier to find causes of undesired behavior of the application.
For details check out the API documentation of the classes and interfaces below:
| |||||||
Changing parameters are not updated | |||||||
When a function module had a changing parameter, and the application did not set any value to it, before invoking function module in the back-end, the updates to it in the back-end were not received by the Java application. | |||||||
StackOverflowError in MetaDataStorage | |||||||
Under certain circumstances it could occur when some metadata object is stored in a
repository's data store. The call stack of the error included the following sequence very often:
at com.sap.conn.jco.rt.MetaDataStorage.updateParents() at com.sap.conn.jco.rt.MetaDataStorage.saveRecordMetaData() at com.sap.conn.jco.rt.MetaDataStorage.storeNestedMetaData() at com.sap.conn.jco.rt.MetaDataStorage.saveFunctionTemplate() at com.sap.conn.jco.rt.MetaDataStorage.updateParents() at com.sap.conn.jco.rt.MetaDataStorage.saveRecordMetaData() at com.sap.conn.jco.rt.MetaDataStorage.storeNestedMetaData() at com.sap.conn.jco.rt.MetaDataStorage.saveFunctionTemplate() at com.sap.conn.jco.rt.MetaDataStorage.updateParents() at com.sap.conn.jco.rt.MetaDataStorage.saveRecordMetaData() at com.sap.conn.jco.rt.MetaDataStorage.storeNestedMetaData() | |||||||
JCo cuts off the last field of a structure or table row | |||||||
See also note 1358698. If a table or strufture definition was extended compatibly between two releases by simply extending the last field, e.g. by extending a CHAR 5 field to CHAR 10, and JCo was only aware of the shorter version of the metadata, but the longer one was sent to JCo, the value of that field was simply not stored, and the field remained initial. In particular, this occurred as well, if there was only a single field in the structure or table row. | |||||||
Exception text was not sent to caller | |||||||
When an implementation of a JCoServerTIDHandler threw an exception within checkTID, the text was
not sent to the caller.
| |||||||
NullPointerException in JCoServer | |||||||
When a JCoServer was started twice, because of some minor changes, and was not stopped properly before,
and the ServerDataProvider did not support events, this could lead to a NullPointerException, when a
new request for this server was coming in.
| |||||||
Release notes 3.0.2 | |||||||
New APIs | |||||||
The following new APIs have been added and are available for general use:
See the API Documentation for details.
| |||||||
Bugfix for hanging JCoServer if connections were set to stateful | |||||||
See also note 1298438.
When setting its connections to stateful, a JCoServer could hang completely when the gateway on which the server has been registered is
sending a ping to the server connection because the ABAP client has not been sending requests for a while. The JCoServer connection then
ends up in a call stack for server threads in a thread dump that looks similar to the following one:
"sap.rfc.Listener SAPBC 10.20.3.20" cpu=136953.28 [reset 136953.28] ms allocated=30367383456 B (28.28 GB) [reset 30367383456 B (28.28 GB)] prio=6 tid=0x0000000015328b50 nid=0x1960 runnable [0x000000001922f000..0x000000001922f7d0] java.lang.Thread.State: RUNNABLE at com.sap.conn.rfc.driver.CpicDriver.nativeCpic_coxread([BI[B[I)I(Native Method) at com.sap.conn.rfc.driver.CpicDriver.cpic_coxread(I[B[I)I(CpicDriver.java:692) at com.sap.conn.rfc.driver.RfcTypeRegisterCpic.listen([BI[II)I(RfcTypeRegisterCpic.java:70) - locked <0x000000018b411e68> (a com.sap.conn.rfc.driver.RfcTypeRegisterCpic) at com.sap.conn.rfc.engine.RfcIoOpenCntl.ab_rfclisten(I)I(RfcIoOpenCntl.java:1293) at com.sap.conn.rfc.engine.RfcIoOpenCntl.RfcListen(I)I(RfcIoOpenCntl.java:2194) at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.listen(LServerWorker;)V(MiddlewareJavaRfc.java:2060) at com.sap.conn.jco.rt.DefaultServerWorker.dispatch()V(DefaultServerWorker.java:259) at com.sap.conn.jco.rt.DefaultServerWorker.loop()V(DefaultServerWorker.java:321) at com.sap.conn.jco.rt.DefaultServerWorker.run()V(DefaultServerWorker.java:220) at com.wm.util.TimeWrappingProvider$TimeMesuredTask.run()V(TimeWrappingProvider.java:40) at com.wm.pkg.sap.rfc.ListenerThread.run()V(ListenerThread.java:70) - locked <0x000000017757a778> (a java.lang.Thread for sap.rfc.Listener BCSAPPRD 172.27.1.23) | |||||||
Bugfix in treatment of one-digit BCD value | |||||||
BCD fields were filled incorrectly if a one-digit value was set (e.g. 4 or 7). The resulting value was always 0 (or 0.0 - with n 0 after the dot if the number of decimals is n in the metadata definition). | |||||||
Bugfix for exception group in case of wrong credentials | |||||||
Error group JCO_ERROR_CANCELLED was used instead of JCO_ERROR_LOGON_FAILURE , moreover the error message was misleading.
| |||||||
Bugfixes in session context handling | |||||||
| |||||||
Bugfix for clear-text password in trace | |||||||
The trace file of could contain a trace entry, in which you find the string 'jco.destination.repository.passwd=' followed by the password for the repository user, i.e. the user with which metadata information is looked up in the SAP system. See also security note 1312880 | |||||||
Bugfix for stateful JCoServer connections | |||||||
Stateful server connections could not be set to stateless again. | |||||||
Bugfix for session events triggered by JCoServer connections | |||||||
The events for sessions started by a JCoServer could be triggered more often than necessary. In particular, this was
true for the jcoServerSessionStarted() event, for which then there did not exist a corresponding jcoServerSessionFinished()
event. As a consequence too many idling sessions were created in the runtime environment.
| |||||||
Bugfix for JCoServerMonitor information | |||||||
Under very high load both getUsedServerThreadCount() and getMaximumUsedServerThreadCount() were increasing above
the configured maximum until the load was lower again and then remained at the wrong high level.
| |||||||
Bugfix in numeric handling of signed or empty field values | |||||||
A ConversionException was thrown when trying to get an empty or signed value
from a field of type CHAR as a converted numeric value. The following JCoRecord
methods were affected: getInt() , getShort() , getLong() ,
getBigInteger() , getDouble() , getFloat() and getBigDecimal() .
| |||||||
Bugfix in repository for nested vector types | |||||||
Table types that referred to a table type as line type which itself refers again to a table type as line type and table types that referred to a table type as line type which referse to a domain as line type were not correctly stored in the repository, when being looked up from an ABAP system. As a consequence function modules that had parameters of such a type could not be processed correctly. | |||||||
Bugfix for java.lang.UnsatisfiedLinkError | |||||||
A java.lang.UnsatisfiedLinkError occurred with the message com.sap.i18n.cp.ConverterJNI.ConvertCToXArrR([B[CII[BII[I)I , when a blended
codepage such as 6100 is used.
| |||||||
Bugfix for starting SAP GUI on Unix and MacOS | |||||||
If the path to the SAP GUI contained blanks, starting the Java GUI failed. On MacOS, in addition some startup parameters needed to be adopted. | |||||||
Bugfix for tables in changing parameter lists | |||||||
If a table was part of the changing parameter list, and was not containing any row when executing the function module, then the table was always returned empty. | |||||||
Enhancement for destination and server configuration management | |||||||
If a configuration was updated, and someone uses a cached instance of a JCoServer or JCoDestination, an exception will be thrown to signal that this instance is outdated. | |||||||
Release notes 3.0.1 | |||||||
Improved documentation | |||||||
An example for a CustomDestinationProvider has been added.
API Documentation has been extended and improved. | |||||||
New APIs | |||||||
The following new APIs have been added and are available for general use:
See the API Documentation for details.
| |||||||
Support for SAPGUI | |||||||
JCo is now able to start a SAP GUI on the local machine and associate it with a newly opened RFC connection.
The back-end prerequisites for this new feature are listed in note
1258724. Starting the SAP GUI can be controlled
by the additional destination parameter jco.client.use_sapgui .
| |||||||
Bugfix in dispatcher worker thread | |||||||
The dispatcher worker thread might have been finished after errors occurring under heavy load. The thread dump
does not contain a thread called JCoDispatcherWorkerThread in this case.
The dispatcher worker thread might be started more than once due to insufficient synchronization. The thread dump contains more than one thread called JCoDispatcherWorkerThread in this case.
| |||||||
Bugfix for functions containing more than 127 non-scalar parameters | |||||||
Functions with more than 127 non-scalar parameters caused an ArrayIndexOfBoundsException . The fix required a change for the
serial version UID of many data containers and metadata instances so that serialized instances of these classes can no longer be exchanged
with previous releases.
| |||||||
Bugfix for ArrayIndexOutOfBoundsException on receive | |||||||
ArrayIndexOutOfBoundsExceptions might be thrown while receiving data (output parameters in client scenario or
input parameters in server scenario). The exception is thrown if the ABAP side has extended the data strcutures used
by the current function module compared to JCo's own metadata definition.
| |||||||
Bugfix for JCO_ERROR_DSR_PASSPORT_NOT_RECEIVED | |||||||
A JCoException with the key JCO_ERROR_DSR_PASSPORT_NOT_RECEIVED was thrown in a JCo server on second
and subsequent stateful requests.
| |||||||
Bugfix in treatment of default BCD value | |||||||
BCD fields were filled incorrectly if the default values was set. On the ABAP side the incorrect content of the BCD field caused short dumps (ABAP runtime error BCD_BADDATA). | |||||||
Bugfix in firing of server events | |||||||
The event ALIVE was not fired by the JCo runtime, if the ABAP system/gateway hase gone online when
the server was in the state DEAD . That might cause that the server application remained in the
the waiting state.
| |||||||
Bugfix for native crash during stateful server communication | |||||||
A native crash occurred on stateful requests from ABAP to Java
| |||||||
Bugfix for server connection leak | |||||||
The JCo server did not release the internal connection handle properly, if the gateway was protected
with an ACL and the connection was declined. After a while all internal handles were used and either an ArrayIndexOutOfBoundsException: 10000 was thrown and
logged to dev_jco_rfc.trc each time a new connection was required. This is the same issue like described in note 1252962 | |||||||
|
|||||||
Copyright © 2008-2013 SAP AG. All Rights Reserved. |