EOIO - failure - resend - alternatives

[Former Member]

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

[Former Member · Accepted solution]

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.

[Former Member · Accepted solution]

Hello Venkant,

Thank you for your reply.

What kind of messages "we cannot re send few messages." cannot be resend?

We do have the queueid, mentioned for the EOIO type of messages but this kind of messages are tedious to handle by the support organization. If they cancel the message in the queue, the other stuck messages are processed and then the order is not maintained.

Do you happen to have documentation on EOIO?

Best regards,

Dharmi

[Former Member]

Hi,

The report RSXMB_RESTART_MESSAGES can be scheduled from SM36 like any other.

first go to se38 execute this report and create variant with the interface details.

Then you can can schedule this as a backgroud job from sm36 with the variant.

Regarding monitoring, yes the adapter engine EOIO backlog can be monitored via CCMS.

Go to RZ20 -> XI overviewExchange infrastructure -> SID -> services -> adapter framework -> messaging system.

here you will see the for each receiver system

EOIO backlog

Processing Backlog (with error)

Processing Backlog (without error)

error

Then you can assign a auto reaction method like send email in case of it reaches threshold.

This information in CCMS monitor can also be viewed manually from RWB as below,

RWB-ComponentMonitoring-AdapterEngine-Enginestatus(last tab)-Backlog

regards,

francis

[Former Member]

Hello Francis,

In de transaction RZ20, I could not find "XI overview Exchange infrastructure -" . However I did find in RWB.

So once that is set, it would be easy to monitor!

Regards,

Dharmi

[VijayKonam]

>

> 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.

If one message failure/lag does not really affect your system integrity, then you do not need EOIO.

>

> 2. Can the message which resulted in error be resend?

Yes. This is true for all async messages. You can edit the payload too. But it always good to correct the data at the source and resend it from there by cancelling errored out message in PI.

>

> 3. Can the stuck message, not block the whole queue and generate kind of warning?

That is against the def of EOIO. If you feel, that one message should not stop other messages to be processed, remove EOIO and use EO instead.

>

> 4. How can one tackle locking in ECC, which happens due to multiple messages being generated from PI from multiple queues?

>

Your ECC coding should be intelligent enough to handle this. Especially with the critical section (multiple threads using the same data at a time)

> 5. How can EOIO messages monitored efficiently?

>

RWB is the best place as per me.

VJ

[Former Member]

Hi,

Resending the message-

If its a temperary and frequent issue then you may prefer to schedule a restart job to restart those messages.

This would avoid manual intervention and delays in processing the rest of the messages in the queue.

For Integration engine the report RSXMB_RESTART_MESSAGES can be scheduled with interface specific details.

For adapter engine this can be scheduled via RWB-componentmonitoring-adapterengine-background processing-create (job type restart). hope this helps!!

[Former Member]

Hello VJ,

Thank you for you reply.

The Synch messages (fire and confirm) cannot be resend? How can the payload be edited? "But it always good to correct the data at the source and resend it from there by canceling errored out message in PI." The order is not maintained in this case!

Point 4: I am not an ABAP-er so do not know about it, but this needs to be coded and there is no standard way of doing it?

Point 5: Support uses sxmb_moni frequently!

Regards,

Dharmi

[Former Member]

Hello Francis,

Thank you fro yuor reply. Can you provide documentation on how this can be done? The RWB seems to be easy...

Do you know if CCMS alert monitor can help?

Regards,

Dharmi