EWM - Checking Queue Status

 Checking Queue Status

Use

Depending on the processing procedure of a Logical Unit of Work (LUW) , a queue in the qRFC Monitor or a LUW in the ARFCRSTATE table can have different status settings. Depending on the status, you can check whether it is necessary to edit it manually.

Process

To check the status of a queue, proceed as follows:

qRFC Monitor

  1. Execute transaction SMQ1 (outbound queue) or SMQ2 (inbound queue).

  2. Determine the current queue status using the following:

Status

Description

ARETRY

During LUW execution the application has diagnosed a temporary problem and has prompted the qRFC Manager in the sending system via a specific qRFC call to schedule a batch job for a repetition based on the definition in transaction SM59.

ANORETRY

During the LUW execution, the application has found 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. To solve the problem, you need to inform the relevant application here.

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 more information on this error, see the syslog (SM21), the trace files dev_rd or dev_rfc*. A batch job is scheduled for the resend depending on the definition in transaction SM59 for the destination used. 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 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.

EXECUTED

The first LUW of this queue has been processed. The system waits for a qRFC-internal confirmation from the target system before processing further LUWs. 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 been terminated. In contrast to status RUNNING, this current LUW has definitely been executed successfully. You can reactivate this queue without any problems. The qRFC Manager will automatically delete the LUW already executed and send the next LUW.

MODIFY

Processing of this queue is locked temporarily because the LUW data is being modified.

NOSEND

LUWs of this queue are not sent but retrieved by a special application. NOSEND queues are only used internally at SAP for communication between components BW or CRM with Mobile Clients. Even if a LUW has been read by the corresponding application (BW, CRM), this NOSEND status does not change. This LUW is only deleted from the queue once this application confirms collection (collective confirmation possible).

Under no circumstances should this NOSEND status be reset using transaction SMQ1 and the queue activated.

NOSENDS

NOSEND is used to debug the execution of an LUW via transaction SMQ1. During the qRFC call, the application determines at the same time that the current LUW is not sent immediately.

READY

The queue is ready for transferring and processing.

This status is normally temporary.

There can however be the data status where a queue was locked manually or by a program using transaction SMQ1/SMQ2 and can then only be unlocked without simultaneous activation. This queue must be activated explicitly in this case.

RUNNING

The first LUW in 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 been terminated. If this is the 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 still being processed in the target system at that time. We therefore recommend a waiting time of at least 30 minutes before you reactivate the queue.

STOP

On this queue or a generic queue (for example BASIS_*) a lock was set explicitly (SMQ1 or programs). Note that the processing of qRFC never locks a queue. After having informed the corresponding application, you can unlock and activate this queue using transaction SMQ1.

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. For more information on this error, see the corresponding short dump in the target system (ST22). No background job is scheduled for a retry and the queue is no longer processed. To solve the problem, you need to inform the relevant application here.

See SAP note 335162 Information published on SAP site for the special error text connection closed.

WAITING

The first LUW of this queue has dependencies to other queues, and at least one of these queues currently still contains other LUWs with higher priorities.

WAITSTOP

The first LUW of this queue has dependencies to other queues, and at least one of these queues is currently still locked.

WAITUPDA

This status is set if qRFC is called within a transaction that also contains one or more update functions. As a result of this status, the LUW and thus the queue is blocked until the update has been completed successfully.

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 retroactive update, the blocked LUW is sent automatically.

You can reset this status using transaction SMQ1 or by report RSTRFCK7 and then reactivate the queue. Note that an inconsistency can occur between both systems in the application data as a result of a reactivation.

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 the status WAITUPDA. This error has been corrected with a kernel patch (see SAP Note 333878 Information published on SAP site).

VBERROR

If an update process relating to a LUW was terminated, the status changes from WAITUPDA to VBERROR . By double clicking on the related error text you can branch to transaction SM13 to display the update record and, if necessary, to delete it.

If you delete an update record, then all related LUWs are also deleted.

Table ARFCRSTATE

Check the status of a LUW in table ARFCRSTATE.

  1. Execute transaction SE16.

  2. Determine the LUW status using the following:

Status

Description

EXECUTED

Execution of the related LUW was completed in the target system. The system waits for an internal tRFC/qRFC confirmation from the sending system before this entry is deleted.

HOLD

The receiving application has processed this LUW in part and does not want it to be retried if subsequent network or communication errors occur (see SAP Note 366869 Information published on SAP site if a large number of entries have this status).

WCONFIRM

During a LUW execution the application has prompted the tRFC/qRFC Manager to set status HOLD. WCONFIRM is set when the LUW execution is complete but the internal tRFC/qRFC confirmation has not yet been received.

If the relevant application informs the tRFC/qRFC Manager about the logical LUW end, this entry is deleted (see SAP Note 366869 Information published on SAP site for more details).

Comments

Popular posts from this blog

SAP MM -- Movement Types and Account determination made easy by flow diagram

All Important Tables of SAP MM Module.