smq2 stuck in ecc, how to handle them without affecting subsequent messages.

[former_member188019]

Hi all,

in our scenario:

LegacyApplication--->FileAdapter--->PI--->InboundProxy--->ECC

LegacyApplication sent 1000 messages.

PI is showing that messages are successfully delivered to ECC.

but in ECC, when we checked in sxmb_moni, some of them are processed, and the rest are in scheduled state.

when we checked in smq2 in ECC, few queues are stuck in with SYSFAIL entries.

checked in st22, there are few dumps.

the inbound abap proxy coding was failing for few cases of data.

we could manually fix by deleting the queue and restarting the messages.

but what i need is, just because few messages gave errors, i dont want all others to be waiting for processed in scheduled state.

is there any way, in case of sysfail in a single queue, the remaining messages to use other queues and process further.

or atleast, in case of single sysfail, it should log somewhere, and continue processing further messages.

thanks in advance.

Madhu.

[MichalKrawczyk · Accepted solution]

Hi,

In case you cannot reprocess the entry restarting will not work as suggested.

what you need to do is to do - Edit -> Save LUW on all faulty entries and then reprocess them from SMq3 later on once you know how to deal with them.

Regards,

Michal Krawczyk

[former_member188019 · Accepted solution]

thanks all for your inputs.

we are looking for automating to allow the processing of unprocessed messages (regardlesss-of/ not depending on the success/failure of other previous messages).

simply scheduling RSXMB_RESTART_MESSAGES or RSQIWKEX in the background, does it work.

or manual intervention to save or delete the LUW is required.

if manual intervention is needed, then it may be tedious to do every now and then.

[Former Member]

Hi Madhu,

As suggested this feature(processing rest-error free of the messages in another queue) is not possible, as PI assigns randomly queue to the messages.

The proper way is to find the first error message and confirm on deletion of that message with application/functionality owner and then automatically process rest of the messages.

--Divyesh

[nageshwar_reddy]

>>> but what i need is, just because few messages gave errors, i dont want all others to be waiting for processed in scheduled state. is there any way, in case of sysfail in a single queue, the remaining messages to use other queues and process further. or atleast, in case of single sysfail, it should log somewhere, and continue processing further messages.

There is no inherent functionality in PI queues to handle your requirement. As the messages come in, the messages are assigned to queues randomly and if the message in a queue has error, rest of the messages assigned to that queue have to wait.

The functionality you are asking for should be handled by the receiving application. The proxy should just receive the message and trigger a posting program(or processing program)  that should be capable of handling errors and message persistence. You should always try to separate out application and integration logic. PI should just deliver the message and the posting program(or processing program) should handle the rest.

[former_member188019]

>>You should always try to separate out application and integration logic. PI should just deliver the message and the posting program(or processing program) should handle the rest.

I think this is the best way, not to have any possibility of dumps in the inbound proxy, if we just use PI inbound proxy for inserting data into few tables. and let separate programs process the data.

but i am in a middle of a complex project, in which this is not taken care, and looking for just automating the  processing/reprocessing queued up messages, with least possible or no manual intervention.

thanks,

Madhu.

[baskar_gopalakrishnan2]

You can use program RSXMB_RESTART_MESSAGES to restart the messages.