Using Jco, Good or Bad ?

[Former Member]

Hi,

I'm using Jco inside my XI mapping to do some table look-ups in R/3. When I have a very high message volume, I see some Jco connection errors since I think I'm reaching the maximum RFC connections. This in causing the XI to queue stop and then all the following messages are crashing... (Not good!)

Is there a way to increase the number of RFC connections when Jco is used inside XI mapping? Is there another way to avoid the connection problems?

Rgds,

Yves

[udo_martens · Accepted solution]

Hi Yves,

you get that connection errors shown in case of memory problems. To avoid that increase the Java Heap size. See [SAP note 723909|https://websmp202.sap-ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=012006153200000099672004]

Regards,

Udo

[Former Member]

Thanks, I will do the changes

[Former Member]

Thanks, I will try.

How many concurrent RFC Jco connections is allowed by SAP when used in XI Mapping?

Rgds,

[udo_martens]

Hi Yves,

Specific to XI is the fact that you sometimes need to process large documents for mapping or when using signatures. This can lead to excessive memory usage on the Java side. Therefore, you must observe Garbage Collection and the available Java heap in order to evaluate performance and pre-vent OutOfMemory exceptions. Since XI mapping is processed by stateless session beans that are called using a JCo interface, this may lead to a reduction of parallel JCo server threads within the JCo RFC Provider service of a J2EE server node (you can compensate for this by adding J2EE server nodes).

Each rfcengine thread of a J2EE server registers at a specific SAP gateway. The mapping service is called by a work process using the RFC destination AI_RUNTIME_JCOSERVER. This ensures load distribution between rfcengine threads. It is important to note that each J2EE server registers the bulk of its rfcengine threads at service startup. This may lead to a suboptimal distribution if using several J2EE server nodes.

The gateway process then dispatches the first mapping requests to server node 0, the next to server node 1. The gateway process is not aware of the J2EE configuration. It only dispatches requests to registered server applications. If you encounter such a situation, you can distribute parallel load to several J2EE servers by:

• Lowering the number of rfcengine threads per server node for destination AI_RUNTIME_* (depending on the number of parallel mapping requests). You configure the number of rfcengine threads (number of processes) for each RFC destination within the JCo RFC Provider service of a J2EE server (using Visual Administrator).

• Using the local gateway. Using local gateways for the mapping runtime instead of one central gateway ensures that more J2EE servers process mapping requests in parallel and prevents overload of the central gateway. To enable the use of an instance’s local gateway, just delete the gateway option of the RFC destination AI_RUNTIME_JCOSERVER in SM59. Mapping requests are then distributed to local J2EE server nodes using the local gateway. Therefore, there must be a configured J2EE server node up and running with every AS instance.

Regards,

Udo