EOIO - failure - resend - alternatives

Question

Hello,
For some of our interfaces, we are using the QoS as EOIO but this is quite problematic:
If the message gets stuck in the queue, the message has to be canceled manually, then only the messages can move forward:
I would like to know the following:
1. What should be the decision criteria in selecting QoS as EOIO? Are there other criterias other [than|/thread/294241 [original link is broken]; mentioned by Ronald.
2. Can the message which resulted in error be resend?
3. Can the stuck message, not block the whole queue and generate kind of warning?
4. How can one tackle locking in ECC, which happens due to multiple messages being generated from PI from multiple queues?
5. How can EOIO messages monitored efficiently?
Appreciate your inputs.
Best regards,
Dharmi

Answer 1

1. What should be the decision criteria in selecting QoS as EOIO? Are there other criterias other than mentioned by Ronald.
yes that applies to EOIO in general. You can decide to use use it or not or how to use it in efficient way is based on the integration that you are working in.
2. Can the message which resulted in error be resend?
yes find out the root cause, fix it and re process the message. Please be informed that we cannot re send few messages.
3. Can the stuck message, not block the whole queue and generate kind of warning?
No actually.Alternaetly, If you get a error realted to code then you can handle that in your code to generate a warning from next time.
4. How can one tackle locking in ECC, which happens due to multiple messages being generated from PI from multiple queues?
provide same QueueID to all relevent messages that might lock up on ECC
5. How can EOIO messages monitored efficiently?
by understanding about it more in detail.
Venkat.