The following parameter list describes the system requirements for IDoc XML Gateway.
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. |
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.
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.
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).
To address the message queue
In the Rfc2Rpc kernel, set the parameter described in the table below. Refer to the sectionRunning Task Rfc2Rpc (SAP calls External) Kernel Environment for more details.
Parameter | Environment Variable | Description |
---|---|---|
webMethods EntireX PMQ Server address | EXX_PMQ_SERVER_ADDR | Send asynchronous units of work to this
webMethods EntireX Broker address. Use the value
localhost@QUEUE/OUTBOUND-IDOC/TEST to send the IDoc queue of
localhost Broker.
|
This parameter, the EntireX Client User ID and the EntireX Client Password are reused for identification.
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.
The index of array IDOC_DATA_REC_40
corresponds to the
segments of an IDoc. Set the index to the maximum number of segments, for
example to 100.
1 IDOC_DATA_REC_40 (/1:100) In /* EDI_DD40
The index of array IDOC_CONTROL_REC_40
must be changed
to 1, because only one IDoc can be received per transaction.
1 IDOC_CONTROL_REC_40 (/1:1) In /* EDI_DC40
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