cancel
Showing results for 
Search instead for 
Did you mean: 

JCo RFC Provider's pool

Former Member
0 Kudos

Hello,

I have a business scenario, where iDoc (with ALEAUS) is going to a sync SOAP interface. I'm not a big fan of BPM, so I've used Java Mapping that makes the sync message and send it and after transform it into the ALEAUD message. This solution works fine, however I found a problem, which I can't solve. During high load the JCO Destination AI_RUNTIME_<SID> breaks the limit on the number of processes. I tried to increase it, however 20 is the limit for that. In the SAP Help I found that I can only change this value from 1 to 20. So, does anybody have other solutions?

Accepted Solutions (1)

Accepted Solutions (1)

iaki_vila
Active Contributor
0 Kudos

Hi Dimitry,

Correct me if im wrong, is your scenario  IDOC (async) - SOAP (sync) - IDOC(async)?

Async-Sync scenarios are possible, adding the adapter module responseoenwaybean http://help.sap.com/saphelp_nwpi71/helpdata/EN/45/20cc5dc2180733e10000000a155369/content.htm, without ccBPM of course

Check this wiki with file -rfc -file, it could be helpful with your scenario http://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=69331

Regards.

Former Member
0 Kudos

Iñaki Vila wrote:

Hi Dimitry,

Correct me if im wrong, is your scenario  IDOC (async) - SOAP (sync) - IDOC(async)?

It's true. However, I can use this scenario only with iDoc AAE. I'm not sure how I can use another sender iDoc AAE adapter only for this scenario. Therefore, right now it is not the solution, but I like the idea.

Answers (1)

Answers (1)

marksmyth
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hello Dmitry

Assuming you currently have only one Java Server node, if you add an extra Java Server node, you will have 2 x 20 AI_RUNTIME_<SID> processes.

Regards

Mark

Former Member
0 Kudos

Yeah, in the DEV landscape I have only one Java Node. However, in PRD or QAS there are 2 nodes in each one. I don't think that it is optimal solution for perfomance. 2 AI_RUNTIME_<SID> processes in the one node would be better.

I think, it's the problem with the product architecture, so there isn't any fine solutions.