The previous answers are only "partially" correct, because we have to consider that the old SAP note 316877, which is mentioned here, is about SAP ITS, a component that used to run on the same host as the ABAP system. Therefore "client" and "server" are the same host in that case, which confuses matters...
The truth is: there is a limit on both sides, external RFC program as well as ABAP backend. You can see, which limit you are hitting, by checking the LOCATION field of the error message. In your case you are hitting the client-side limit:
LOCATION CPIC (TCP/IP) on local host ... with Unicode
The CPIC library, which is linked into every external RFC program, has a default connection limit of 200. You can change this value by setting the following environment variable in the environment, where the external program is running:
export CPIC_MAX_CONV=300
In addition, most RFC SDKs export an API, which allows setting this value programmatically, e.g.
- NW RFC Library: RfcSetMaximumCpicConversations(300, &errorInfo);
- SAP JCo: JCo.setProperty("jco.cpic_maxconv", "300");
- SAP NCo: GeneralConfiguration.CPICMaxConnections = 300;
I don't know, whether PyRFC also exposes such an API.
Finally, the limit can also be set via a configuration parameter:
NW RFC Library: in sapnwrfc.ini file set MAX_CPIC_CONVERSATIONS=300
(As PyRFC is based on NW RFC Library, this should also work for PyRFC.)
SAP JCo: (doesn't have a central config file)
SAP NCo: in app.config file set
<SAP.Middleware.Connector>
<GeneralSettings cpicMaxConnections=300 />
</SAP.Middleware.Connector>
- The ABAP backend system has a default limit of 500. It can be changed by setting the following profile parameter:
rdisp/max_comm_entries
On the question, whether connections should be closed and when, you not only need to consider the impact on your client program, but also the impact on the ABAP backend system! Every open RFC connection allocates one user session in the backend system, and this consumes quite a significant amount of resources, which are no longer available to other users that want to log on and use the system (either via RFC or via SAPGui).
And also, you need to consider that when leaving a connection open that is no longer used, you are not only consuming a seat in your own program, you are also consuming one of the 500 seats in the backend system. This means, if there are three "misbehaving" programs with such a connection leak, the 500 conversations in the backend are quickly blocked, and then the backend cannot accept further connections from other programs or SAP systems.
So the first point to note is, that you should close a connection as soon as you no longer need it, in order to reduce the strain on the backend.
Next you need to consider that opening a connection, results in the backend kernel performing the "login procedure", which is quite time consuming. I don't believe the above test with 1000 calls in a loop. Something must be wrong here. The performance will definitely be slower, if you open and close a new connection for every single call. This is true especially when using SNC instead of user/password logon, because the SNC handshake (with exchanging and validating certificates on both sides) is very expensive.
So the best way definitely is:
- Open a connection
- Do all RFC calls you currently need to do via this connection
- Afterwards close the connection