cancel
Showing results for 
Search instead for 
Did you mean: 

SMQ2 Queue Monitering and stuck up problem

anup_deshmukh4
Active Contributor
0 Kudos

Hello Experts ,

Below is the situation

u2022 An interface is asynchronous In bound in ECC from PI as a PROXY message and the quality of message is EOIO (Exactly once in order) i.e. it has a definite queue.

u2022 The actual method of the Provider class has the code which posts the data into the ECC system using BAPI.

u2022 If BAPI is successful the message is successfully passed BUT if BAPI returns an Error an exception is raised (CX_AI_APPLICATION_FAULT) and the errors are logged into Zee tables. After the resolution of errors the xml id is reprocessed using SXI_MONITOR Tcode

Concerns

u2022 As the Message quality type is EOIO it has a dedicated queue and if the first message in the queue fails the queue is in status SYSFAIL , as per in tcode SMQ2

u2022 The status text for the ID in the Queue is - An exception occurred that was not caught.

u2022 Due to this all the rest of the messages in the queue get stuck up i.e. Scheduled state, unless and until you go to SMQ2 and delete the message with the exception.

u2022 Expected is that the queue should not stop or not go into SYSFAILT if an application exception is thrown.

u2022 In our situation the message volume in the queue is LARGE may be 5K message a day.

Accepted Solutions (0)

Answers (3)

Answers (3)

anup_deshmukh4
Active Contributor
0 Kudos

Self answered

Former Member
0 Kudos

Hi Anup,

how did you resolved it because I have the same issue...

anup_deshmukh4
Active Contributor
0 Kudos

I didn't find any perfect solution for the said problem ,

what i did was using some function module ( search of TRFC_QIN* in se 37 ) i Wrote on program and scheduled it periodically to delete the error message and restore the queue in running condition .

Thanks and regards,

Anup

former_member854360
Active Contributor
0 Kudos

If you want to cancel alll the error ,messages from Queue at a one go then you can use the following standard report.

RSXMB_CANCEL_MESSAGES Mass cancellation of error messages - XI

anup_deshmukh4
Active Contributor
0 Kudos

Thanks for your comments , but

My problem is that my Queue gets stuck up if one of the xml message has a simple application error ..!

Current situation is like i have to delete the Message with the exception form SMQ2 and the queue is free flowing again after activition ...This over head is to be avoided how do i do it ?

fault mapping is already done ...!


  <  <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
- <!--  Call Inbound Proxy 
  --> 
- <SAP:Error xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="">
  <SAP:Category>Application</SAP:Category> 
  <SAP:Code area="ABAP">APPLICATION_ERROR</SAP:Code> 
  <SAP:P1 /> 
  <SAP:P2 /> 
  <SAP:P3 /> 
  <SAP:P4 /> 
  <SAP:AdditionalText /> 
  <SAP:ApplicationFaultMessage namespace="http://xyx.com/FI/FIARI0007_ReceiptCreate">CX_AI_APPLICATION_FAULT</SAP:ApplicationFaultMessage> 
  <SAP:Stack>Application has thrown an exception</SAP:Stack> 
  <SAP:Retry>M</SAP:Retry> 
  </SAP:Error>

Still waiting for a standard way to do it...!

Former Member
0 Kudos

Hello Experts ,

> Below is the situation

> u2022 An interface is asynchronous In bound in ECC from PI as a PROXY message and the quality of message is EOIO (Exactly once in order) i.e. it has a definite queue.

> u2022 The actual method of the Provider class has the code which posts the data into the ECC system using BAPI.

> u2022 If BAPI is successful the message is successfully passed BUT if BAPI returns an Error an exception is raised (CX_AI_APPLICATION_FAULT) and the errors are logged into Zee tables. After the resolution of errors the xml id is reprocessed using SXI_MONITOR Tcode

> Concerns

> u2022 As the Message quality type is EOIO it has a dedicated queue and if the first message in the queue fails the queue is in status SYSFAIL , as per in tcode SMQ2

> u2022 The status text for the ID in the Queue is - An exception occurred that was not caught.

> u2022 Due to this all the rest of the messages in the queue get stuck up i.e. Scheduled state, unless and until you go to SMQ2 and delete the message with the exception.

> u2022 Expected is that the queue should not stop or not go into SYSFAILT if an application exception is thrown.

> u2022 In our situation the message volume in the queue is LARGE may be 5K message a day.

Why dont you have Fault message mapping , that captures the exception and trigger an alert using the alert framework..

?

Best Regards,

XA