SMQ2 Queue Monitering and stuck up problem

Question

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.

Answer 1

Anup Deshmukh wrote:
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