Queues indound blocked

Question

I wanted to ask what can I check on my XI, because I often block queues indound, blocking the process of my interfaces.
thanks
umberto

Answer 1

Hi,
check in  RWB and Message Monitoring for specific interface.
or
check in TCode  SMQ2 for Inbound Queue monitoring
http://help.sap.com/saphelp_nw70/helpdata/EN/76/e12041c877f623e10000000a155106/frameset.htm
Queue Status in SMQ1 and Table ARFCRSTATE
Use
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 permanent: A queue has been 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 may mean that the work process responsible for sending this LUW has been 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 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.
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.
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, information from the affected application is required. See 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 more information on this error, see the syslog (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 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 processing of qRFC never locks a queue. After having informed the corresponding 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 currently still 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 has been 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.
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 in the qRFC Monitor SMQ1, and reactivate the queue. Note that this can lead to possible inconsistencies in the application data between the two systems.
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).
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, information from the affected application is required.
MODIFY
·        Processing of this queue is locked temporarily because the LUW data is being modified.
Table ARFCRSTATE
You can use transaction SE16 to display the status:
EXECUTED
·        The related LUW is completely executed in the target system. The system waits for an internal tRFC/qRFC confirmation from the sending system before this entry is deleted.
HOLD
·        The corresponding application has processed this LUW in parts and wants this LUW to not be repeated in the case of subsequent network or communication errors (see SAP Note 366869 if there are many entries with this status).
WCONFIRM
·        During a LUW execution the application has prompted the tRFC/qRFC Manager to set status HOLD. If the LUW execution has already been completed but this application has not yet signaled the logical LUW end and if the tRFC/qRFC-internal confirmation from the sending system has been received, then this LUW receives status WCONFIRM.
If the respective application informs the tRFC/qRFC Manager about the logical LUW end, then this entry is deleted (see also SAP Note 366869 for more details).
Queue Status in SMQ2 and Table ARFCRSTATE
Use
Depending on the way a Logical Unit of Work (LUW) is processed, an inbound queue or the table ARFCRSTATE (status table of the LUWs in the tRFC/qRFC target system) can have different statuses.
Inbound Queue
The following statuses may be displayed 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 permanent: A queue has been locked manually using transaction SMQ2 or using 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 processing this LUW has been 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 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.
·        SYSFAIL
A serious error occurred while the first LUW of this queue was being 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 (transaction ST22). No background job is scheduled for a retry and the queue is no longer processed. To solve the problem, information from the affected application is required. See SAP Note 335162 for the error text "connection closed".
·        CPICERR
A network or communication error occurred while the first LUW was being executed. When you double-click on this status, the system displays an error text. For more information on this error, see the syslog (transaction SM21) or the trace files dev_rd and dev_rfc*. Depending on the registration of this queue (SMQR), a background job is scheduled for a retry. See SAP Note 369524 for the error text u201CLogon failed". 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.
·        STOP
On this queue or a generic queue (for example BASIS_*) a lock was set explicitly (SMQ2 or programs). Note that the processing of qRFC never locks a queue. After having informed the corresponding application, you can unlock this queue using transaction SMQ2.
·        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 currently still contains other LUWs with higher priorities.
·        ARETRY
When the LUW was processed, the application diagnosed a temporary problem and has prompted the qRFC Manager with a specific qRFC call to schedule a background job for a retry, based on the registration in SMQR.
·        ANORETRY
When the LUW was processed, the application diagnosed a serious error and has prompted the qRFC Manager with a specific qRFC call to stop processing this LUW. To solve the problem, information from the affected application is required.
·        MODIFY
Processing of this queue is locked temporarily because the LUW data is being modified.
Table ARFCRSTATE
You can use transaction SE16 to display the status:
·        EXECUTED
The related LUW is completely executed in the target system. The system waits for an internal tRFC/qRFC confirmation from the sending system before this entry is deleted.
·        HOLD
The corresponding application has processed this LUW in parts and wants this LUW to not be repeated in the case of subsequent network or communication errors (see SAP Note 366869 if there are many entries with this status).
·        WCONFIRM
During a LUW execution the application has prompted the tRFC/qRFC Manager to set status HOLD. If the LUW execution has already been completed but this application has not yet signaled the logical LUW end and if the tRFC/qRFC-internal confirmation from the sending system has been received, then this LUW receives status WCONFIRM.
If the respective application informs the tRFC/qRFC Manager about the logical LUW end, then this entry is deleted (see also SAP Note 366869 for more details).
PS reward me if usefull
reg,
suresh