tuning outbound RFC (TCP/IP, "registration")

[Former Member]

We use RFC from SAP R/3 (Rel 4.6C) to an external application.

The RFC-destination is of type T (TCP/IP) of course, with activation 'registration'. This means that the other application has registered with the gateway process of the SAP-system (sapgw) and said it would be listening for calls.

We are looking for documentation on tuning on the SAP side (we are looking at the other side, too).

I have found documentation for tuning inbound RFC (RFC-calls into SAP R/3 or more generally into the SAP ABAP-stack), but I have not found anything in outbound RFC.

Yet something must be tuned - we notice that the hard way.

Obvious questions are:

1. How can we increase the number of simultaneous connections the SAPGW can handle?

2. If the other application does not respond swiftly, how can we increase the timeout in SAP?

[Former Member · Accepted solution]

Hi,

The only tuning, I'm aware of, for this configuration is the number of registrations done by the external application and the number of physical servers hosting the external application.

We use this setup in my company to be able to call web wervices from R/3 4.7.

A .NET RFC server has been written and is a web service client. So it is a kind of RFC to web service connector.

This RFC server is hosted on 2 physical hosts. Each of these 2 RFC servers has 4 threads. Each of these threads register on the SAP central lnstance gateway with the same registration name.

From transaction SMGW (logged on clients) we see 8 registrations.

In SM59 for the TCP/IP RFC destination, the central instance gateway host and service are entered in the gateway options fields.

The result is that is possible to call the external RFC (web service in our case) from all 5 app servers from R/3 and the calls are load balanced on the 8 RFC server threads.

For the gateway parameters, have a look at SMGW --> goto --> parameters --> Change

You have several parameters about several timeouts and connection numbers....

Hope this helps,

Olivier

[Former Member · Accepted solution]

Thank you, that is certainly useful.

Any idea which parameters in particular?

Where could I find a guide / whitepaper / blog on this subject?

[Former Member · Accepted solution]

Hi Peter,

I'm sorry but I don't have experience on these parameters. Our outgoing external RFC generate only a few calls par day. So, as we did not have any performance problem we did not try to fix something that was not broken.

Ou need was high availability and not high load.

I am not aware of any whitepaper on the subject but you should check the OSS notes on the subject.

The only other way is to experiment on a test system...

Good luck,

Olivier

[Former Member · Accepted solution]

Thank you for your reply.

We are now focusing on the following:

when SAP calls another application via RFC (type T, "registration"),

how long will it wait for a reply from that other application and

how can we increase this timeout?

[Former Member · Accepted solution]

Hi,

Help in RZ11 gave me the following for parameter <b>gw/reg_timeout</b>

********************************

This parameter acts as a time limit for communication with a

registered program.

The reason for the timeout is that this program was occupied

and could not handle new tasks.

1. Start the registered program more frequently.

2. Minimize the work steps of the registered program if possible.

Work can thus be done faster, and the program is available

earlier for new tasks.

********************************

The default value is 60 seconds.

Regards,

Olivier

[Former Member]

In the end, the business rules were changed, making it easier for the other application to find an answer within a reasonable time.

On the other hand, we programmed an error message stating very clearly to the user that the other application had been unable to find an answer within the allotted time. It was then up to the user to simplify his query.

After all, if we had been able to increase the timeout (we were never allowed to try it) to e.g. 3 minutes, it would have meant that the SAP users would sometimes wait for 3 minutes before getting any response.

[Former Member]

>In the end...

Well, 3 years later I hope this was the end of your project !

Regards,

Olivier

[Former Member]

Well, 3 years later I hope this was the end of your project !

Actually, it dd not take that long. I've just been revisiting some of my old questions.