CIF - deleting qRFC entries

Former Member · ‎05-16-2007

Hi Gurus,

Is anyone know is there a standard program to delete SMQ1 entries at background. Other than manually deleting from SMQ1-SMQE, we will need a batch to schedule it at background regularly.

thanks in advance,

Siir

kenneth_snyder · ‎06-06-2007

For those interested... I like to keep track of oss notes:

This info is in OSS 378903 - Queue status in SMQ1, SMQ2 and table ARFCRSTATE

Ken Snyder

Former Member · ‎06-06-2007

Try these programs in se38

RSTRFCIDS-delete inbound queues

RSTRFCQDS-delete outbound queues

Former Member · ‎05-18-2007

Queues have different statuses depending on which you have to take appropriate actions.

Look at the document - at the end to understand the differnt statuses and what actions you have to do

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

If you want to restart the queues, use the report RSQOWKEX ( For Outbound Queues) and RSQIWKEX( For INbound Queues) to restart the queues automatically.

The program names, I have mentioned applies to both R3 and APO system

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

There is a report which does delete the QUEUEs

Program: RSTRFCQD

You can use this report to delete a single LUW or all the LUWs in an outbound queue.

Features

When you execute the report, you have several options for deleting the LUWs:

1) You can delete a single LUW.

2) You can delete one or more queues. You select a queue using its name.

When you enter a TID and a queue name, both the TID and the complete queue are deleted. You cannot search for a specific TID in a queue.

The Package parameter enables you to restrict the number of LUWs that are deleted before a commit is performed. This parameter is significant for system load (when the value is low) and for performance (when the value is high).

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

OUTBOUND QUEUES and STATUS

Depending on the way a Logical Unit of Work (LUW) is processed, an inbound

queue, outbound queue or table ARFCRSTATE (status table of the LUWs in the

tRFC/qRFC target system) can have different statuses.

Outbound queue:

==============

The following statuses may be displayed in transaction SMQ1:

READY

The queue is ready for transmission. This status should only be a temporary

status. However, in the following case this status can also be a permanent

status: A queue was locked manually via transaction SMQ1 or via a program

and then unlocked without being activated at the same time. This queue must

be activated explicitly.

RUNNING

The first LUW of this queue is currently being processed. If a queue in

this STATUS hangs for more than 30 minutes, this might mean that the work

process responsible for sending this LUW has terminated. In this case, you

can activate this queue again. Note that activating a queue in status

RUNNING may cause a LUW to be executed several times if this LUW is

processed in the target system at that time. We therefore recommend a

waiting time of at least 30 minutes before you activate the queue again.

EXECUTED

The first LUW of this queue is processed. The system waits for an

qRFC-internal confirmation from the target system before further LUWs are

processed. If a queue in this STATUS hangs for more than 30 minutes, this

might mean that the work process responsible for sending this LUW has

terminated. In contrast to status RUNNING, this current LUW has definitely

been executed successfully. You can activate this queue again without

problems. The qRFC Manager will automatically delete the LUW already

executed and send the next LUW.

SYSLOAD

At the time of the qRFC call, no DIALOG work processes were free in the

sending system for sending the LUW asynchronously. A batch job for

subsequent sending has already been scheduled (see note 319860 for more

details).

SYSFAIL

A serious error occurred in the target system while the first LUW of this

queue was executed. The execution was interrupted. When you double-click on

this status, the system displays an error text. You can find additional

information on this error in the corresponding short dump in the target

system (transaction ST22). No batch job is scheduled for a repetition and

the queue is no longer processed. Information from the affected application

is required to solve the problem. Refer to note 335162 for the special

error text "connection closed".

CPICERR

During transmission or processing of the first LUW in the target system, a

network or communication error occurred. When you double-click on this

status, the system displays an error text. You can find additional

information on this error in the syslog (transaction SM21), the trace files

dev_rd or dev_rfc*. Depending on the definition in transaction SM59 for the

destination used, a batch job is scheduled for subsequent sending.

Status CPICERR may also exist in the following cases although no

communication error occurred: A qRFC application finds out that a LUW

cannot be processed any further due to a temporary error in the application

and therefore calls the RESTART_OF_BACKGROUNDTASK function module in order

to prompt the qRFC Manager to cancel the execution of this LUW and to

repeat this LUW later in accordance with the specification in transaction

SM59. In this case, qRFC simulates a communication error with the text

"Command to tRFC/qRFC: Execute LUW once again.". If this error occurs very

often, you must contact the corresponding application.

STOP

On this queue or a generic queue (for example, BASIS_*) a lock was set

explicitly (SMQ1 or programs). Note that the qRFC never locks a queue in

its processing. After having informed the relevant application, you can

unlock and activate this queue using transaction SMQ1.

WAITSTOP

The first LUW of this queue has dependencies to other queues, and at least

one of these queues is currently still locked.

WAITING

The first LUW of this queue has dependencies to other queues, and at least

one of these queues contains other LUWs with higher priorities.

NOSEND

LUWs of this queue are never sent but retrieved by a special application.

These queues are only used internally at SAP (BW or CRM during

communication with Mobile Clients). Even if a LUW was read by the

corresponding application (BW, CRM), this status does not change. This LUW

is only deleted from the queue if this application confirms collection

(collective confirmation possible). Under no circumstances should this

status be reset using transaction SMQ1 and the queue activated.

NOSENDS

During the qRFC call, the application determines at the same time that the

current LUW is not sent immediately. This is used to debug the execution of

an LUW via transaction SMQ1. Contact the corresponding qRFC application to

clarify this status since this is either a programming or configuration

problem.

WAITUPDA

This status is set if qRFC is called within a transaction that also

contains one or more update functions. This status blocks the LUW and and

therefore the queue until the update has successfully terminated.

If this status takes longer than a few minutes, check the status of the

update or the update requests using transaction SM13. After a successful

update, the blocked LUW is sent automatically.

You can also restart the LUWs manually in the WAITUPDA status without a

successful retroactive update (via transaction SMQ1, Reset status, Activate

queue). However, to avoid possible inconsistencies, you may only carry out

this action following consultation with the qRFC application (such as APO,

BW, CRM).

This WAITUPDA problem may be avoided as follows: If both qRFC calls and

update calls occur within a transaction, qRFC must be executed exclusively

within the update. In this case, the qRFC LUW is only created after the

update has been completed successfully.

CAUTION:

========

If you are using Releases 4.0x, 4.5x, 4.6A or 4.6B, and an update function

with the "collective run" type exists in a LUW, an error in the kernel may

cause this status. The queue also hangs in this case. This error has

already been corrected with a kernel patch (see note 333878).

VBERROR (only applies to Basis Releases 6.20 or higher)

This status is set if qRFC is called within a transaction that also

contains one or more update functions. This status is set if the update not

could be executed due to an error. Within the SMQ2 monitor, you can branch

directly to SM13 on the LUW level by double-clicking on the error message,

to determine the cause of the update termination.

RETRY

During LUW execution, the application has diagnosed a temporary problem and

has used a specific qRFC call to prompt the qRFC manager in the sending

system to schedule a batch job. This batch job schedules a repetition after

two minutes. You can use the definition in transaction SM59 (TRFC options)

to suppress this batch job.

ARETRY

During LUW execution the application has diagnosed a temporary problem and

has used a specific qRFC call to prompt the qRFC Manager in the sending

system to schedule a batch job for a repetition on the basis of the

definition in transaction SM59.

ANORETRY

During the LUW execution, the application has diagnosed a serious error and

prompted the qRFC Manager via a specific qRFC call to cancel processing of

this LUW. Information from the affected application is required to solve

the problem.

MODIFY

Processing this queue is locked temporarily because the LUW data is being

modified.

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

INBOUND QUEUES and STATUS

Depending on the way a Logical Unit of Work (LUW) is processed, an inbound

queue, outbound queue or table ARFCRSTATE (status table of the LUWs in the

tRFC/qRFC target system) can have different statuses.

Inbound queue:

==============

You can display the following statuses in transaction SMQ2:

READY

The queue is ready for processing. This status should only be a temporary

status. However, in the following case this status can also be a permanent

status: A queue was locked manually via transaction SMQ2 or via a program

and then unlocked without being activated at the same time. This queue must

be activated explicitly.

RUNNING

The first LUW of this queue is currently being processed. If a queue in

this status hangs for more than 30 minutes, this may mean that the work

process responsible for sending this LUW has terminated. In this case, you

can activate this queue again. Note that activating a queue in status

RUNNING may cause a LUW to be executed several times if this LUW is

processed in the target system at that time. We therefore recommend a

waiting time of at least 30 minutes before you activate the queue again.

SYSFAIL

A serious error occurred in the target system while the first LUW of this

queue was executed. The execution was interrupted. When you double-click on

this status, the system displays an error text. You can find additional

information on this error in the corresponding short dump in the target

system (transaction ST22). No batch job is scheduled for a repetition and

the queue is no longer processed. Information from the affected application

is required to solve the problem. Refer to note 335162 for the special

error text " connection closed".

CPICERR

During transmission or processing of the first LUW in the target system, a

network or communication error occurred. When you double-click on this

status, the system displays an error text. For additional information on

this error, refer to the dev_rd or dev_rfc* trace files in the syslog

(transaction SM21). being referred for to dev_rfc*. Depending on the

registration of this queue (SMQR), a batch job is scheduled for repetition.

Refer to note 369524 for the error text "R/3 logon failed".