Skip Headers
Oracle® Fusion Middleware Application Adapter Best Practices Guide for Oracle WebLogic Server
11g Release 1 (

Part Number E17059-04
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

2 Oracle Application Adapter for SAP R/3 Best Practices

This chapter lists and describes best practices that are specific to the Oracle Application Adapter for SAP R/3 (using SAP JCo 2.1.x and 3.x). It contains the following topics:

Understanding Connection Pools

A connection pool is a set of client-connections to a certain destination. The pool may automatically create new connections to the specified remote system or return an existing connection. It also provides methods to return a connection back to the pool when it is no longer needed. The following list describes several key points:

To monitor the number of connections that are being made to SAP from the Oracle Application Adapter for SAP R/3, you can use the SMGW transaction from your SAP GUI.

Optimizing a connection pool effectively requires knowledge about the application and its users. The following questions should be discussed:

It is not unreasonable to configure multiple connection targets with different connection pools for different functions. For example, a sales order inquiry that checks if an item exists may execute quickly, it does not need maximum resources. However, a sales order creation that creates a header and line items that is executed by many people may require a greater execution time, so configuring a larger connection pool is recommended.


The following list describes several key points regarding security best practices:

Load Balancing

There are two types of load balancing mechanisms that are available (logon load balancing and load balancing for registered programs). Logon load balancing logs users to SAP using an SAP Message Server. The Message Server distributes logons to Application Servers and can even distribute logons by specific application groups. Oracle Application Adapter for SAP R/3 supports connections to SAP using Message Servers. Load balancing for registered programs is a technique employed when sending a large amount of data out from SAP to remote destinations. As a best practice, only an SAP Gateway administrator should attempt to change the named parameters in the SAP Gateway that affect load balancing.

Since iWay registered servers (channels) connect to a SAP Gateway and not to specific application servers, they are enabled for load balancing by default through the SAP Java Connector (SAP JCo). The mechanism for message delivery depends on how the SAP Gateway in enabled by the administrator, but it is generally the following forms:

When there is a one-to-one relationship between a SAP Gateway server and an instance of the iWay channel, the singleton is in a non load balanced scenario. The types of messages that are sent to the server are determined by the Interface document style and the RFC destination. The RFC destination is used to hold the program ID inside SAP, and is used to route all messages to the iWay channel. For this reason, it is recommended that the SM59 transaction that controls the RFC destination is locked to hide the IP address of the remote server inside SAP. Inside SAP, RFC function modules are routed to the iWay channel by specifying the DESTINATION parameter in the CALL FUNCTION invocation, passing the RFC destination that holds the iWay server. For example:


Where MYDEST is defined as a remote TCP (T) destination in the SM59 transaction and holds a Registered Server Program as one its parameters.

The iWay channel connects to the SAP Gateway and exposes the same Program ID to the SAP Gateway. At this point, one or more servers accept the connection.

SAP IDocs need additional configuration to define the sending and receiving systems. They are contained in a SAP Logical System. All IDocs routed through Message Control use the Logical System linked to a RFC destination to process through the channel. BAPI objects have no outbound form, to use a BAPI outbound object from SAP, use the RFC function form of the BAPI. For example, you can replace Company.GetDetail with BAPI COMPANY_GETDETAIL.

All messages sent to a Program ID arrive at a channel configured to listen to a SAP Gateway and Program ID. Any final destinations configured to receive messages from the channel receive all messages from the channel. This may have important implications in configuring business processes. Consider using different Program IDs for different messages, message filters or message splitters as coding techniques to route messages based on type or content.

When multiple channels or servers are configured with the same Program ID, messages can be duplicated or never arrive, depending if load balancing is enabled on the SAP system. Use caution when deploying and using Program IDs and assign them in a logical and coordinated manner (for example, by department or by message type).


iWay channels on Unicode systems work only in Unicode mode. In the SM59 transaction, ensure that the RFC Destination Parameter, Unicode, is selected when creating the destination in SAP GUI.

The RFC components of SAP Java Connector (SAP JCo) automatically determine the target code page of the sending (client) and adjust the code page translation between the client and server accordingly. The only way to modify this is to change the target system code page, in Windows using Regional and Language Options in the Control Panel. For other systems, it is recommended to consult the administrator. In general, a system must have a code page and a language pack. Encoding is used to map one code page to another. This is straightforward in Unicode systems, but can be difficult or not possible on non-Unicode systems. As a general rule, in non-Unicode systems, you are limited to the code page and language pack you have on the system for the display of data. However, because of the Java language Unicode support, transmission can occur correctly if the remote system has the correct configuration.

Receiving document from SAP, especially IDocs, can have segments containing multiple languages. It is usually not possible to get all languages correct. For example, setting the Java encoding variable to ISO-8859-2 correctly sends German umlauts, but distorts Japanese Kanjii. The only solution for this situation is multiple sends of the text segments and combining them into one result.