Scenario: You have a large message that is stuck in the INBOUND (XBTS*) queue of an integration server (maybe an ABAP proxy).
(This solution is based on SAP note
688147).
The message is visible in transaction SMQ2 (inbound queue) for a few hours/days/months:
and it’s consuming significant resources, visible in SM50:
You may also be blowing the ICM http buffer, visible in the SMICM log file:
But, you can’t cancel the message in SXMB_MONI, as it is still scheduled on the QUEUE (“still scheduled in queue XBTS*”):
SAP notes state that you should NEVER delete messages directly from SMQ1 or SMQ2 as this leaves the messaging system in an inconsistent state.
What to do? What to do?
Instead, in this exceptional case, you can delete the message in SMQ2. This will prevent it retrying.
Once you’ve done this, you can then use report RSXMB_CHECK_MSG_QUEUE to restore the messaging system integrity by resetting the original message status to cancel it.
Delete the entry from the queue:
Now execute the report RSXMB_CHECK_MSG_QUEUE:
Ensure that you enter the specific message ID, then enter the PIPELINE ID (same as that shown in column PIPELINE in SXMB_MONI), select all status to search for and then select TEST RUN:
The log should show that it will flag 1 message for archiving (“No QRFC entry found. Message flagged for archiving”):
Now go back and re-execute the program with “Test Run” un-checked:
You will be prompted to cancel selected messages:
The log will show:
SXMB_MONI now shows the message is “Cancelled Manually”:
