|Oracle® Fusion Middleware Application Adapter for SAP R/3 (SAP JCo 3.0) User's Guide for Oracle WebLogic Server
11g Release 1 (184.108.40.206.0)
Part Number E17656-03
This chapter describes the new usage considerations of the Oracle Application Adapter for SAP R/3 that are associated with SAP Java Connector (SAP JCo) 3.0. It contains the following topics:
SAP JCo 3.0 removes 32-bit support on Unix platforms. Only Linux (with Intel processors) and Windows (with Intel processors) now support the 32-bit SAP JCo. All other platforms require true 64-bit processing throughout. Some JVM settings cause the JVM to read as “mixed mode”, which is not compatible with SAP JCo. Some platforms require a specific flag of –d64 to enable complete 64-bit processing in the JVM.
For more information on supported platforms with SAP JCo 3.0, see Oracle Fusion Middleware Application Adapters Installation Guide for Oracle WebLogic Server.
For supported JVM information that corresponds to each operating system, refer to SAP Note #1077727 in the SAP Service Marketplace. If a specific JVM is not included on the list of supported JVMs, then it is not supported by SAP R/3.
Note:The Oracle JRockit JVM is not supported by SAP JCo 3.0.5.
SAP JCo 3.0 introduces changes in connection management whereby the JCo is now the connection manager, rather than the connection facilitator. These changes are described in the following section for the client (into SAP R/3) and server (outbound from SAP R/3) roles.
SAP JCo 3.0 introduces changes to the connection methodology that is used by the client (connections to SAP R/3). Instead of connecting directly to the SAP R/3 server, clients now open a connection to a logical destination on the SAP JCo, which handles all SAP R/3 connection and pooling tasks. Connection pooling is now done per iWay target destination. However, the total number of all open connections count towards the SAP R/3 open connection limit. The Connection pool size parameter value in the destination target is the maximum number of peak connections that can be opened by the logical destination. The SAP JCo does not allocate connections in advance, instead the initial request opens the first connection. Only if this first connection is busy when the next request arrives does another connection open, up to the peak limit.
If the limit is reached, then the Connection wait time parameter value marks the time when all connections are in use, and another connection request arrives, before a “resource allocation” exception is generated.
In addition, the Connection timeout parameter value is the maximum amount of time for a connection to remain active, whether in use or not. If there are longer running requests, then consider increasing this parameter value. If a number of very short requests are run, then decrease this parameter value for maximum performance and resource utilization.
The SAP R/3 outbound Gateway creates one active connection per RFC destination for non SAP R/3 systems. For maximum throughput, the Thread count parameter is set to three (three server threads per RFC destination). This parameter can be found in the Advanced tab of Application Explorer when configuring channels. Usually, this leaves one thread to listen for requests, one thread to process a current request, and one thread to clean up from processing. In cases where a large amount of traffic on a particular RFC destination is required, there are a few SAP R/3 techniques that can be used for these situations. When more than one Program ID with the same name is registered for one SAP Gateway, the Gateway can be enabled for a "load balancing" scenario, depending on the parameters in the Gateway profile on the SAP R/3 system. It is recommended to consult your SAP R/3 system administrator for more information, but the profile will either be set to 0 (no load balancing), 1 (lowest counter), or 2 (lowest load). Your SAP R/3 system administrator can provide you with the required information on how to configure your destinations to take advantage of each situation.
In addition to Gateway load balancing, the amount of SAP Gateway threads can be increased as well. Consult your SAP R/3 system administrator for more information. If the amount of threads is increased, then try and keep the ratio of Gateway threads to server threads at the same 1:3 ratio. For example, if the Gateway has 3 active threads for destination “X”, on the outbound server channel side, the server thread count is now 9.
If load balancing is not enabled and you register multiple server channels with the same Program without performing Oracle schema validation, then it is possible to receive IDocs in the wrong channel because there is no routing on the channels or destinations.
SAP JCo 3.0 introduces a fundamental design change in the way JCo servers are implemented and run. A single instance of a JCo server is permitted per JCo installation. The Oracle Application Adapter for SAP R/3 maps between ports and channels. The changes are transparent to the end-user, however in load balanced and multi-threaded installations, special care must be taken to match the server thread count of the adapter and the active server thread count of the SAP Gateway. This topic can be investigated further in the SAP R/3 help file “Configuring the SAP Gateway”, where comprehensive information is exposed on load balancing and server threads.
Oracle Application Adapter for SAP R/3 and SAP JCo 3.0 introduce support for SAP Changing parameters in function modules. SAP R/3 Table parameters are limited to Flat data structures (relational) with fixed columns of defined lengths and a required header line. Changing parameters can take almost any SAP R/3type, including nested structures (tables where a column is itself a structure) and data of no fixed length, such as String data types. Changing parameters can be used as input to a function module, exported from a function module, or both. This depends on the requirements of the designer for the specific SAP function.
The XML schemas for functions that use Changing parameters do not list them as a separate category. However, just like Table parameters, they appear in the request and response XML schemas. Depending on the function design, if the parameters are marked as optional, you do not have to supply a value. The optional indicator displays in Application Explorer and in the XML schema. For more information on using Changing parameters, see your SAP R/3 documentation.
Oracle Application Adapter for SAP R/3 (using SAP JCo 3.0) includes a new parameter called Trace level, which can be found in the Advanced tab of Application Explorer, as shown in Figure 3-1.
This parameter indicates the level of detail in the SAP traces. Select a value that ranges from 0 through 10 from the list. The common values that are used include:
0 - nothing
1 - errors and warnings
2 - execution path, errors, and warnings
3 - full execution path, errors, and warnings
4 - execution path, info messages, errors, and warnings
6 - full execution path, info messages, errors, and warnings
7 - debug messages, full execution path, info messages, errors, and warnings
8 - verbose debug messages, full execution path, info messages, errors, and warnings
Path values null, stdout, and stderr are allowed. An existing path is also allowed. If the path is equal to null, stdout, or stderr, then SAP JCo generates a trace to the standard output (error) stream. If at least one JCoTraceListener is registered, then the trace output is sent to the listener only. To redirect the SAP JCo trace into a file, the path value has to be set to an existing directory.
The following environment variables have to be set at ORACLE_JAVA INVOKE_HOME:
The following is an example of a path on a Solaris platform:
The following variables can be set at the operating system level:
RFC_TRACE=1CPIC_TRACE=(1,2,3) RFC_TRACE_DIR= CPIC_TRACE_DIR=
Where 1 is an error trace, 2 is a complete process trace, and 3 is a complete process trace, short data trace.
It is recommended to check your environment settings, especially under a hosted environment.