on 06-22-2007 2:25 PM
Hi all,
we have got a bit of a problem with a message stuck in the adapter engine. The message display tool says that the message can't be stopped since its predecessor is not in final state. Is there an intelligent way to find the predecessor? We have gone back several weeks without success
Any help would be appreciated.
Kind regards,
Heiko
have you checked the queues? SMQ1 and SMQ2?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
hi heiko,
message waiting for it's Predecessor,this shouldn't occur for a long time.
just uncheck the box "MAINTAIN ORDER AT RUNTIME" in interface determination,if order is not important for you.
if you want the order and avoid holding then ensure the condition flag values for any two interfaces are not the same and if this doesnt work then ensure order from sender system i.e if batch reports are run then schedule them according to the order required.
request you to check condition flags at INTERFACE DETERMINATION, this should overcome your problem.
Thanks & Regards,
Rama Krishna
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Heiko,
did you try the hint of Stefan Grube?
/people/stefan.grube/blog/2006/04/27/how-to-deal-with-stuck-eoio-messages-in-the-xi-30-adapter-framework
If you are using an older SP version and the mentioned fields are not available on your RWB screen (like for me), than just go back in time and search for messages with status "Holding". Cancel the very first one, and you'll be able to cancel/resend the others as well.
It worked for me
Best regards,
Andras
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
what is the adapter error your getting. what adapter it is?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Sreeram,
the refered adapter is the file adapter. I don't know which error I get since my problem is that I can't find the message which stops all other subsequent messages waiting in the adapter engine. QS is EOIO hence there are two inbound interfaces involved in the interface determination, being processed subsequently.
Cheers,
Heiko
User | Count |
---|---|
88 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.