cancel
Showing results for 
Search instead for 
Did you mean: 

Old messages stucked in TBDL - status (To Be Delivered)

Former Member
0 Kudos

Hi

I have a number of old XML-messages that are in status TBDL. This in RuntimeWorkbench -> Message Monitor.

The reason for that is that they try to access an ECC system that is not valid anymore.

They are result of a failed test and I just want to get rid of them from the list in RWB.

I.e force them into SystemError state so I can cancel them.

They are stucked in Integration Engine, not in the adaper.

In SXMB_MONI they are processed successfully but have also following statuses

XML status : Transfer to Process Engine

Outbound Status : Message Scheduled on Outbound side

QoS = Exactly Once

I have tried following in PI:

-


  • Executed SE38 -> RSXMB_CHECK_MSG_QUEUE (report to delete the inconsistencies)

  • Executed SXMS_REFRESH_ADAPTER_STATUS (report to update the status)

  • Deleted all workitems in SWWL (se38 -> RSWWWIDE)

  • Even restarted the server (ABAP and Java)

But they still remains untouched... I.e still in TBDL-status.

Does anyone have a tip on how to remove them/turn them into SystemError ?

/BR

Jocke Carlsson

Accepted Solutions (1)

Accepted Solutions (1)

former_member181985
Active Contributor
0 Kudos

Use SMQ2 transaction to delete queues for the stacked messages of your interface.

Former Member
0 Kudos

Hi

Thanks!

However; I started the problemsolving with SMQ2. There was one faulty entry related to the stucked messages. I deleted it (Delete LUW). So, all queues are clean and error-free so that is not the solution I'm afraid.

/BR

Jocke Carlsson

former_member181985
Active Contributor
0 Kudos

select the failed messages in MONI and cancel them using penciled button which is after restart button.

Edited by: Praveen Gujjeti on Apr 20, 2009 5:40 PM

Former Member
0 Kudos

Thanks but one can not cancel messages that are "Successfully processed" or are in status "Tranfer to Process Engine".

/BR

Jocke

former_member181985
Active Contributor
0 Kudos

Once you delete the stacked queues you should be able to cancel the messages which are either with status System Error or Scheduled for outbound

select the failed messages in MONI and cancel them using penciled button which is after restart button.

(or)

select the messages from RWB bench(with Multiple Selection enabled) then click cancel button.

Former Member
0 Kudos

Hi

With :

"...Once you delete the stacked queues..."

Do You mean delete the failing entries? Or, lock the queue?

The actual messages are run at the the outbound queue: XBTO

Despite the fact that that all quese are error-free and empty at the moment, one can not cancel the messages. In RWB I get "Unable to cancel, update the status" and in SXMB_MONI I get "You cannot cancel XML message with this status/type.

BR

Jocke

Former Member
0 Kudos

hello everybody,

was anybody able to figure the reason and/or the solution out in the meantime?!

we have the same issue in our environment, that messages can't be cancelled- neither in the sxmb_moni nor in the RWB- the reason the system states, is that they are already scheduled.

but checking smq2, smqr or executing RSXMB_CHECK_MESSAGE_QUEUE doesn't bring me any further, because there is no message scheduled in the stated queues.

also does the sxmb_moni not show any queue ID or something helpful

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi Jocke,

first and foremost the suggestion in this thread to delete entries from SMQ2 is absolutely wrong. This should never be done under any circumstances.

If you need to remove a queue entry because it is blocking the following messages, then you should use the function 'save LUW' in SMQ2 and not delete. This will temporarily remove the entry from SMQ2 and it will now be visible in SMQ3. After the problem with this LUW has been resolved you can 'restore' the entry from SMQ3 back into SMQ2 for further processing.

There is a direct link between the ABAP persistence layer for the XML messages and the qRFC entries. If you delete the qRFC entry (which you do by deleting the entry in SMQ2) then you create an inconsistency that can not be resolved. That is why the report RSXMB_CHECK_MSG_QUEUE was created (see Note 688147), in order to be able to cancel messages with missing RFC entries.

So, once again DON'T DO IT !

From the original description of your problem, you had run the report RSXMB_CHECK_MSG_QUEUE already, but was that before or after you deleted an entry from SMQ2 ?

As a next step, I would recommend to use the mdt (mesage display tool) in the Java stack to find and cancel the offending message. The mdt can be accessed through the URL http://<PI host>:<port>/mdt

If you find the message here, use the cancel button to set the message to 'failed'.

I would then re-run the report SXMS_REFRESH_ADAPTER_STATUS and check whether the message has then the appropriate status in SXI_MONITOR.

Hope this helps,

Best regards,

Peter

Former Member
0 Kudos

Hi Joakim,

First check the each message status in Message Monitoring.,, There u can find out the error where its occured then u can easily solve the issue,

and TBDM messages u can resend the messages.

Regards,

Sateesh N

Former Member
0 Kudos

Thanks, but I don't want to resolve the messages. I just want to get rid of them (make them go into SystemError). The communicated system will not be used anymore.

/BR

Jocke