Best practice for handling errors in EOIO processing on AEX?

[Former Member]

Hi,

I'm looing for resources and information describing the best practice on how to handle processing errors of asynchronous integrations with Exactly-Once-In-Order QoS on an AEX (7.31) Java only installation. Most information I've found so far are describing a the monitoring and restart jobs on AS ABAP.

Situation to solve:

multiple different SOAP messages are integrated using one queue with an RFC receiver. On error the message status is set to Holding and all following messages are Waiting. Currently I need to manually watch over the processing, delete the message with status holding and restart the waiting ones.

Seems like I can setup component based message alerting to trigger an email or whatever alert. I still need to decide on how to handle the error and resolve it (ie. delete the errornous message, correct the data at sender and trigger another update). I still need to manually find the oldest entry with status waiting and restart it. I've found a restart job in Background jobs in configuration and monitoring home, but it can be only scheduled in intervals of 1 or more hours.

Is there something better?

Thank you.

Best regards,

Nikolaus

[former_member184720]

Hi Nikolaus -

AFAIK - For EOIO, you have to cancel the failed message and then process the next message in the sequence manually..

Restart job only works the messages which are in error state but not in holding state.. So you have to manually push the message... So there is no other alternative.

But it should not be that difficult to identify the messages in a sequence..

How to deal with stuck EOIO messages in the XI ... | SCN

Though it is for older version, it should be the same.. you should be able to select the additional columns such as sequence ID from the settings..

[Former Member]

Hi Hareesh,

thank you for your answer. It's not what I have hoped for, but it confirms my findings. I have really hoped for better tools to handle such situations and the current state basically makes the usage of EOIO uncomfortable and irrelevant.

Best regards,

Nikolaus