This blog will give tips and trick on the basis part of qRFC (queued RFC).
Questions that will be answered are:
- How to assign a specific server group to qRFC?
- How to correct host ID in SMQS?
- What to do with the scheduler error RES_LACK?
- What to do when inbound entries in SMQ2 stay in status RETRY?
- How to check performance of qRFC?
- How to check consistency of qRFC?
- How can I activate the application log to detect manual actions performed on qRFC?
Assigning specific server group for qRFC
In RZ12 you have defined a specific server group. In SMQR or SMQS you can assign that server group with menu option Edit / Change AS group:
Check also note: 3159931 – SM58 tRFC failed with “Error when opening an RFC connection (CPIC-CALL:”.
How to correct host ID in SMQS?
After a system copy the host ID in SMQS might be still pointing to the old system. To solve this, goto SM51 and select menu option Goto / Host Name Buffer / Reset / Entire System. Then go back to SMQS and re-activate the scheduler via menu option Edit / Activate Scheduler. See also OSS note 2377064 – How to correct the host ID in SMQS.
Empty host ID in SMQS
Initially the host ID in SMQS is empty. After the first message is sent, the host ID will be filled. See OSS note 2915187 – SMQS Host ID is blank or empty.
Outbound scheduler in status RES_LACK
If the outbound scheduler SQMS has the status RES_LACK, then the amount of DIA versus BTC processes is not balanced. Follow the instructions from OSS note 1970757 – Outbound qRFC scheduler with status RES_LACK to balance the processes.
Deletion of queued messages
Deletion of queued messages is possible, but should be done with care. After deletion, support can be lost on certain functions. See for example OSS note 2375304 – Deleted queues from SMQ2. You can apply OSS note 2837536 – Customer Connection – Improvement Request 217719 – Authorization check for message deletion in Smq2 / Smq3 to restrict the access to message deletion via special authorization object.
Inbound queues SMQ2 stay in status RETRY
When inbound entries in SMQ2 queue remain in status RETRY, this is normally caused by lack of authorization for launching batch job. This can happen to background user and user reprocessing the jobs. Check the authorization trace to see what needs to be fixed. More background in OSS note 1862256 – Inbound queues (SMQ2) stay in status RETRY.
Queue in the inbound queue scheduler SMQ2 with “Name or password is incorrect (repeat logon)”
When you get this issue a password change of the RFC might be required. Read more in OSS note 2474161 – Queue in the inbound queue scheduler SMQ2 with “Name or password is incorrect (repeat logon)”.
Queue resets via batch jobs
Report RSQOWKEX can be used to reset the outbound queue. RSQIWKEX can be used to reset the inbound queue. The goal is to reprocess messages in error state like SYSFAIL, CPIERR. More details are in OSS note 2552322 – RSQOWKEX and RSQIWKEX. Note 2195856 – Double message execution explains to be careful with using these programs with status RETRY.
These programs can be scheduled in batch mode to automate reprocessing.
Consistency checks of qRFC
Consistency checks of qRFC:
- You can identify and delete inconsistencies in the outbound queue using report RSTRFCEG.
- You can identify and delete inconsistencies in the inbound queue using report RSTRFCEH.
Background is described in OSS note 779664 – Consistency check of qRFC queues with deletion.
Deletion of unprocessed LUW’s in qRFC
Deletion of unprocessed LUW’s in qRFC: background is described in OSS note 760113 – Delete unprocessed LUWs in the qRFC.
Application log for qRFC manual processing
In SMQ1 and SMQ2 manual actions can be done, which are normally not logged. Apply OSS note 3031450 – Application log for inbound qRFC monitor such as SMQ2 to get the actions logged in the application log.
Alerting of failed qRFC in EWM systems
qRFC is very important in EWM systems. In EWM systems there is a built in program for alerting on qRFC failures: /SCWM/R_QRFC_QUEUE_ALERT. More on this feature you can read in OSS note 2226372 – EWM – Alerting for Failed Queues.
Issues with destination NONE
When using qRFC with SQMS for destination NONE, you can have unwanted interference with tRFC. See OSS note 1813159 – Hanging LUW´s in SM58 with the function module IDOCS_OUTPUT_TO_R3. Set the registration of NONE with flag ‘w/o tRFC’ on. And make sure the max connections is not set to 1, but much higher.
Issues with performance of qRFC
OSS note 2183108 – t/qRFC processing: general performance verifications contains program Z_RFC_QUEUE_PERF. This program can be run to check for potential performance issues. Output example:
Reference OSS notes
Reference OSS notes:
- 3299462 – qRFC Queues remaining on status READY
- 3299538 – How to set the Max.Conn. value in SMQS
- 3303429 – How to check SMQS/SMQR action log
Bug fix OSS notes
Bug fix OSS notes: