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:
  • JCoServer.setRepository(JCoDestination)
  • JCoServer.setRepository(String, String, JCoDestination)
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 -Djco.allow_non_abap_partner=1 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:
  • JCoRepository.load(java.io.Reader)
  • JCoRepository.save(java.io.Writer)
  • JCoCustomRepository.addClassMetaDataToCache(JCoClassMetaData)
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:
  • DestinationDataProvider.JCO_USER_ID
  • JCoRepositoryMonitor.getRespositoryDestinationMonitor(String)
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:
  • JCoDestination.getSncSSO()
  • JCoDestination.getExternalIDData()
  • JCoDestination.getExternalIDType()
  • JCoCustomDestination.SncConfigurationData.setSncWithSSO(boolean)
  • JCoCustomDestination.UserData.setExternalIDData(String)
  • JCoCustomDestination.UserData.setExternalIDType(String)
  • JCoDestinationMonitor.getWaitingThreadCount()
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:
  • JCoDestinationMonitor.isValid()
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:
  • JCoMetaData.setName(String)
  • JCoRecordMetaData.setLineType(String)
  • JCoRecord.write(int, Writer)
  • JCoRecord.write(String, Writer)
  • JCoDestination.isValid()
  • JCoServer.isValid()
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  / sapgwXX
    ERROR       partner ':sapgwYY' not reached
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:
  • Existing JCo properties are now documented
 
 
Release notes 3.0.5
 
New API and constant
The following new API and constant have been added and are available for general use:
  • JCoCustomDestination.setUseSapGui()
  • JCoCustomRepository.QueryMode.DISABLE_REPOSITORY_POOL
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:
  • JCoFunctionUnit
  • JCoRequestUnit
  • JCoUnitIdentifier
  • JCoBackgroundUnitAttributes
  • JCoFunctionUnitState
  • JCoServerUnitIDHandler
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:
  • AbapClassException
  • JCoRemoteContext
  • JCoAbapObject
  • JCoClassMetaData
  • JCoFunction
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:
  • JCoCustomDestination.setTrace()
  • JCoCustomDestination.setCodepage()
  • JCoAttributes.getOwnBytesPerChar()
  • JCoAttributes.getPartnerBytesPerChar()
  • Environment.isDestinationDataProviderRegistered()
  • Environment.isServerDataProviderRegistered()
  • Environment.isSessionReferenceProviderRegistered()
  • Environment.isClientPassportManagerRegistered()
  • Environment.isServerPassportManagerRegistered()
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
  • It was possible that the context which timed out was not removed from the list of existing contexts by the session timeout checker. This could create unnecessary checks for sessions that have already been cleaned up.
  • Contexts that have been initiated by a stateful JCo server were not removed immediately after the connection had been closed by the ABAP client.
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:
  • JCo.getTraceLevel()
  • JCo.getTracePath()
  • JCoConnectionData.getSystemID()
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
  • on the second or any subsequent request during a stateful server communication
  • and if the request data volume was greater than 16000 bytes in the internal RFC representation
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.