The tables ARFCSSTATE, ARFCSDATA, ARFCRSTATE, TRFCQDATA, TRFCQIN, TRFCQOUT or TRFCQSTATE contain a large number of entries. This leads to in poor performance during tRFC and qRFC processing.
The system has a very high interface load and/or a large number of tRFC/qRFC entries have the status "Error" and/or there is a large number of tRFC/qRFCs waiting to be processed.
Before you correct the problem, you must analyze the problem in more detail.
1. Outgoing t/qRFCs
Check that you are using tRFC or qRFC:
- Use transaction SE16 to check how many entries are contained in the table ARFCSSTATE.
- Now determine for how many entries the field ARFCRETURN is empty in the table ARFCSSTATE. These entries represent tRFCs that have either not yet been processed or that have the status "Error". This affects the tables ARFCSSTATE and ARFCSDATA. These tables contain a large number of entries (see also point 5).
- All of the entries of the table ARFCSSTATE, for which the field ARFCRETURN is not empty, come from qRFCs that either have not yet been processed or that have the status "Error". Here, the tables ARFCSSTATE, ARFCSDATA and TRFCQOUT are affected by the growth (see also point 3).
2. Incoming t/qRFCs
a) The table ARFCRSTATE contains a large number of entries (it does not matter if these were written by tRFC or qRFC).
b) The tables TRFCQIN, TRFCQDATA or TRFCQSTATE contain several entries.
These are qRFCs (see also point 4).
We will now describe known solutions. If there is no solution for the problem that you are experiencing in your system, open a message under the component of the affected SAP product (CRM, SRM, and so on). If you know the affected application within the SAP product, then specify the message component more precisely.
Generally, you should not delete tRFC entries or (especially not) qRFC entries because the applications that the databases use to communicate will become inconsistent. (Only some cases mentioned in Note 366869 are exceptions). Apart from that, the following always applies: After deletion, you must check and restore the consistency of the databases involved.
3. Known solutions for outgoing (sending) qRFC
a) Example APO
When you call transaction SMQ1, there is a large number of queues on CPICERR. The system writes this error if the data required by the liveCache was blocked during execution. Normally, the system automatically post processes this error (every 15 minutes by default). If you want this postprocessing to occur immediately, you can send the queue manually from transaction SMQ1. The sequence of the queues is irrelevant because the qRFC automatically identifies which other queues must be processed and in which sequence within the same LUW.
However, if it is not a lock but an actual CPIC error that causes the CPICERR (for example, the target system is not started, the destination is not maintained in SM59 and so on), you must correct the error before post-processing.
b) Example CRM Mobile Sales
In transaction SMQ1, there is a large number of entries for queues with the name CRM_Site_00....XX in the status NOSEND. Generally, these queues have a large number of entries (more than 100) and the first date (oldest queue entry) is older than one week.
These queues are the queues of the Mobile Client. The owner of the Mobile Client has not logged on to CRM (CONTRANS not started) from transaction SMQ1 since the "first date". The system constantly places queue entries into the outbound queue for each individual mobile client, as a result, the queues and therefore the qRFC table grow (this is due to the delta load from the OLTP and data replication in the middleware). This has a negative effect on performance for all qRFC users and especially on the communication with the OLTP system.
Above all, the growth per queue depends on the quantity of data subscribed for the Mobile Client.
We recommend that you limit the quantity to the minimum from the outset.
The only solution here: The Mobile Clients must log on to CRM and start CONTRANS on a regular basis (at least once a week). IMPORTANT: If one or more clients are no longer required or have no owner, they must be logged off from the admin station by the administrator. This actually causes a temporary load on the system, but consistently removes the queues.
4. Known solutions for incoming qRFC:
a) CRM: In transaction SMQ2, queues have the status STOP.
Either the CRM application writes this STOP or it is set manually.A short STOP triggered by the application is normal.
If, however, the queues have the status STOP for a long time and were not deliberately deregistered in SMQR, there is an application problem. This may either have been caused by a short-term lock of the application object where a simple status reset and subsequent processing helps.
Alternatively, a real application error may exist and you can determine its cause using transaction SMW01: Here select the date according to the queue STOP date, select the corresponding line and choose the "Error" pushbutton. The system displays the application error that has to be corrected by the user department. Afterwards, you can trigger the queue again from SMW01 by following the menu "Message -> Process -> Retry to process".
If you have deliberately deregistered the queue, note that stopping several queue entries for a long period of time may also affect performance.You should register and process the queues again as soon as possible.
Known solutions for incoming and outgoing qRFC:
b) All SAP products that use QRFC: The QRFC performs poorly after you import Supplement 11, QRFC 6.30.060.
On ORACLE, this supplement also requires database statistics for the tables TRFCQIN and TRFCQOUT. You may experience considerable performance problems if you forget to generate these statistics after you upgrade to Supplement 11 (see doc 742950 and 371068).
5. Known solutions for outgoing tRFC:
For all users, use transaction SM58 to check which function module should be processed by the TRFCs:
a) For the function module: "SWW_WI_*" and a status text indicating an error, there is a workflow problem.First use transaction SWU3 to check the workflow Customizing and continue to search for possible workflow errors.
If the error has been corrected, try to post process the tRFC.If that does not work technically, you must first contact your workflow application department to clarify which steps to take to ensure the business flow before you use the "Reorganization" in transaction SM58 to delete the entries that cannot be post processed.
b) For the function module: "IDOC_INBOUND_ASYNCHRONOUS" (Release 4.X and higher) or "INBOUND_IDOC_PROCESS" (Release 3.X) and a status text that refers to an error, there is an ALE/EDI RFC transmission problem.
Check the technical function of the interface (destination test in transaction SM59, checking the ALE/EDI Customizing for this interface).
Correct the error and then post process the tRFC, otherwise this IDoc is lost for the business process.
c) A common cause of the error if you are using ALE/EDI in your system in Releases as of 4.6 is that the error workflow is delivered for these interfaces, but the general workflow Customizing is not delivered. Since the workflow for error handling cannot be deactivated in EDI, in this case carry out the workflow Customizing and define processors for the work items.
In ALE, you have the choice to perform error handling either in the workflow or in transactions BD87 and BD88. If you choose BD87/88, you can deactivate the workflow for troubleshooting. As a result, the TRFC entries for the error workflow are suppressed.
To deactivate the error workflow for ALE and EDI, proceed as follows:
Transaction WEDI -> Control -> System Process Code. Here you can deactivate each standard task by selecting "Inactive".
Deactivate the event linking in transaction SWE2 by removing the cross in the "Type Linkage active" field. Here you can deactivate the error workflow at message type level. You may only be able to deactivate the event linking for certain message types.
Always set the PROCESSSTATEREACHED event to "Active" for the IDoc object if you are communicating using the file interface, otherwise no immediate processing is possible.
If you have deactivated the error workflow and you have corrected the IDOC errors with BD87/88, you can use transaction SM58 to delete the relevant entries in the TRFC tables.