Version 2.3.1.18
 —  SAP R/3 Gateway Documentation  —

Configuration Parameters

The following parameter list describes the system requirements for IDoc XML Gateway.


Web Application Server

The transformation from IDoc to XML and vice versa needs memory in your web application server. The default memory settings of the JVM are insufficient.

If the web server runs with SAP R/3 Gateway and IDoc XML Gateway alone on the gateway machine, you can assign 70% of the real memory to JVM. For example, if the gateway machine has 1GB of real memory, assign 700MB to the JVM of the web application server

To set the avaliable memory for the JVM, use the -Xms (for initialization) and -Xmx (for maximum) options. Depending on your platform, set the parameters as described in the table below.

Location Description
Tomcat on UNIX Add or set the JAVA_OPTS environment variable for memory requirements in the startup script as described in the section Startup at Boot Time.
Tomcat on Windows defined as service Add parameters for JVM in the registration database (regedit) on the path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Apache Tomcat 4.1\Parameters
Tomcat on Windows with manual startup Add or set the JAVA_OPTS environment variable in startup.bat of Tomcat's bin directory.
JBoss on UNIX Add or set the JAVA_OPTS environment variable in the script that calls run.sh in JBoss's bin directory.

Top of page

Length of Received Messages

To receive large outbound IDocs from SAP R/3, the maximum message size must be set on the JVM Property page. Add a property with the name pmq.resource.maxReceiveLength and the value 100000. This length must in any case be greater than the internal buffer size of Rfc2Rpc kernel.

In case of error, if you do not set (or to less) this parameter or set it to a value less than the internal buffer size of the Rfc2Rpc kernel, the message API: Msg truncated to fit receive-buffer will occur in the System Log.

Top of page

Configuring the Rfc2Rpc Kernel

The Rfc2Rpc kernel receives the outbound IDoc and delivers it to an webMethods EntireX Broker Message Queue. The following parameters must set for message handling.

Internal Buffer

The Rfc2Rpc kernel needs a buffer size large enough to generate a UOW (Unit of Work) message. This buffer is defined statically on the stack at compilation time. To define the buffer size add the following CFLAG compile parameter -DPMQ_SEND_BUFFER_LENGTH=<Size in Bytes> to the makefile.

CFLAGS= -c \
	-DPMQ_SEND_BUFFER_LENGTH=100000 \
...

The default is 32000 bytes if this CFLAG parameter is not set. If the generated message is larger than the defined buffer size, the UOW will contain multiple messages. In this case, check the webMethods EntireX Broker parameter UOW-MSGS and increase its size if necessary (refer to the section webMethods EntireX Broker Parameters for details).

IDoc Queue

Start of instruction setTo address the message queue

This parameter, the EntireX Client User ID and the EntireX Client Password are reused for identification.

IDL

To work with one IDoc in one UOW (Unit of Work), the working memory size of the function IDOC_INBOUND_ASYNCHRONOUS must be increased. Edit the asynchronous IDL of Rfc2Rpc kernel on the development page.

Top of page

webMethods EntireX Broker Parameters

Asynchronous communication needs some configuration parameters in the webMethods EntireX Broker Attribute File. To handle IDocs like units of work (UOWs) in persistent store (refer to the webMethods EntireX documentation Concepts of Persistent Messaging (Primary Store)), the following parameters must be checked in the existing Broker or set for a new Broker. For more information refer to the topic Attributes used for Unit of Work in the webMethods EntireX Documentation "Using Persistence and Units of Work".

Parameter Recommended Value Description
PSTORE HOT Start Broker with restore.
DEFERRED YES Server does not have to be active.
STORE BROKER Store UOWs persistent
UWTIME 3D Define the lifetime for UOW.
UWSTATP 1 Remember UOW status.
MAX-UOWS 100000 Max UOWs
UOW-MSGS 100000 Max number of messages in one UOW.
MAX-MSG 1000000 Defines the maximum message size.
NUM-LONG-BUFFER MAX-UOWS * SizeOfOneUOW / BlockSize Defines the number of blocks to receive and to keep in the UOWs in memory.
NUM-SERVICE Add 20 to existing Defines the number of services (=queues). Calculate 7 per environment (test, integration, production).
NUM-SERVER Add 20 to existing Defines the number of servers. Calculate 7 per environment (test, integration, production).

All parameters are set as default or as maximum in the section Broker-specific Attributes. In addition, you can redefine the parameter settings for each service in the section Service-specific Attributes.

Note:
webMethods EntireX has two modes for handling service-specific attributes. In service update mode, service-specific attributes can be changed during runtime; in non-update mode, the Broker needs to be restarted to effect any changes. Refer to the webMethods EntireX documentation Broker Attribute File (All Platforms) for further details.

Add the following lines to define the queues in the service-specific attributes (refer to the Broker Attribute File (All Platforms) for more detail):

DEFAULTS         = SERVICE
   CONV-NONACT   = 5M
   SERVER-NONACT = 5M
   TRANSLATION   = SAGTCHA

   CLASS = QUEUE ,   SERVER = * ,   SERVICE = TEST   * Test environment
   CLASS = QUEUE ,   SERVER = * ,   SERVICE = INT    * Integration environment
   CLASS = QUEUE ,   SERVER = * ,   SERVICE = PROD   * Production environment

Tip:
If you decide to use one Broker for all environments (test, integration and production) then define a resource limit for each queue environment. For example: The following line defines only a limit of 100 UOWs for each TEST queue. Add the additional parameter for restriction to the same line of service.

CLASS = QUEUE ,   SERVER = * ,   SERVICE = TEST , MAX-UOWS = 100

Top of page