This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

HowTo: Cancel Large Message Stuck in SAP PI/XI Queue

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”:

SAP PI Channel Stopped by Administrative Task

During a routine message mapping using the Java stack with a custom Java class lookup that accessed an RFC communication channel (configured in the Integration Directory), the mapping was failing with multiple errors.

One of the errors stated: “ Channel stopped by administrative task”.

Whilst not completely obvious what the exact problem was, I check the CPA cache in transaction SXI_CACHE and ensured there were no errors during a full cache refresh.
No problems there.

So I moved on to check the communication channel itself. All seemed fine. Using the “check” option from the pull down menu, showed all was well.
No other errors.

Restarting the message from SXMB_MONI resulted in the same error over and over.

The resolution:
Simply editing the RFC communication channel in the Integration Directory and changing it to “Inactive”, saving and applying, then changing it back to “Active” (on the Advanced tab), saving and activating.
This seemed to fix the problem.

Looks like the RFC channel destination hostname was modified and this caused the adapter to throw a slight wobbler, making it think it was inactive.