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
Security
Load Balancing
Encoding

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:

The maximum number of connections specified can never be increased while the application is running. As a best practice, you must choose a number that is large enough for your application.
A connection pool can have any name. Since a connection pool is global within the Java Virtual Machine (JVM), it is recommended that different applications running in the same JVM follow a naming convention standard to avoid any issues.
If multiple users share a connection pool, then they share the SAP authorization permissions of the underlying user ID that created the connection pool.
When a target is created using Application Explorer during design time, the specified connection parameters are used during run time for all objects created using the target. Ensure that the connection properties are capable of supporting your environment.
The general parameters for calculating a connection pool size are: TIME=(SAP Application Server execution time for called function) + (size of document) + (network lag). It is recommended to check with a SAP Gateway administrator about the maximum size of allowed connection pools for a particular landscape.
Larger documents or long running transactions need a larger value for the Connection Timeout parameter. Extremely long running documents should not be run in the foreground. It is recommended to check with a system administrator about establishing a batch job that can be called by the Oracle Application Adapter for SAP R/3.
By default, SAP Java Connector (SAP JCo) opens one initial connection for a connection pool. If that initial connection is busy when another request arrives, then SAP JCo opens an additional connection, leading up to the maximum pool size. When the maximum pool size is reached, the Connection Wait Time parameter is called, which determines how long SAP JCo must wait for a free connection without aborting the task.

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:

How much time does it normally take to execute this function?
How much data is returned by this function?
How many users are going to use this function?

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.

Security

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

The SAP Java Connector (SAP JCo) default is plain text. If the SAP JCo communication has an insecure network path, then it is recommended that the RFC communication is encrypted.
Restrict the ability of users to monitor or access the SAP Gateway and its functions. Ensure that the run time user ID for SAP JCo communications is not an SAP dialog user but a communications type user.
As a best practice, consider using the SAP router mechanism for communications between systems that are behind firewalls.

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:

0: No load balancing, the first free registered program is used.
1: The program with the lowest counter is used. Every time a registered program is assigned a request, the counter is increased by one.
2: The program with the least load is used, which is determined by SAP.

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:

CALL FUNCTION 'RFC_GET_SYSTEM_INFO DESTINATION ' DESTINATION 'MYDEST'

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).

Encoding

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.