on 08-25-2005 12:41 PM
Hi ,
If a message gets stuck in the Adapter Engine due to an error, say, due to, the target application is down. After the target application is up , when the next message comes in , i want the current message plus the previous message(s) also to be processed. rite now i dont see this happening , a manual restart from RWB is what i do . Now Is there a way to auto restart these messages stuck ?
Thanks in advance
Saravana
First I would reactivate the specific adapter.
Then try restarting that specific adapter in Visual Admin (Ex: Visual Admin --> Server --> Services --> SAP XI: File).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
SKM , Even if there is no issue with the adapter , you mean to say i should restart it and once restarted, all the messages get processed ?
But then assuming a message is delivered to the adapter when its temporarily down & restarted , those messages are goin to get stuck in IS rite ?
Thanks
Saravana
Hi there,
After having read the last replies on this topic , I get the impression that this VERY crucial aspect from the integration engine remains unclear for most of us.
Can someone from SAP please try to explain this issue? As asked before; what will be the effect of having a infrastructure failure (i.e receiver application temporary down...adapter cannot deliver message(s)) like this in one of your interfaces running on XI?
A Couple of questions that one can have are:
1) When this kind of situation occurs; are the messages automatically stored/queued on XI?
1a) Does this apply for both asynch/synchr communication?
2) Is this an automatically procedure built-in on XI, or do you need to configure it somewhere in the integration engine?
3) When the receiver system is again available, are the queued messages then automatically sent to the receiver system or do you nedd to start this process manually?
Tnx for your answers!
Message was edited by: Roberto Viana
Hi Roberto , i ve answered based on my understanding , hope it helps
> 1) When this kind of situation occurs; are the
> messages automatically stored/queued on XI?
> 1a) Does this apply for both asynch/synchr
> communication?
If its EO/EOIO , they are definitely stored. For Synch scenarios , my understanding is that your source application will timeout without getting a response from middleware, now you chk this, if timedout, then send the request again
>
> 2) Is this an automatically procedure built-in on XI,
> or do you need to configure it somewhere in the
> integration engine?
The QOS(Quality of Service) you choose will determine the behaviour in XI.
> 3) When the receiver system is again available, are
> the queued messages then automatically sent to the
> receiver system or do you nedd to start this process
> manually?
No , you need to schedule RSXMB_RESTART_MESSAGES , refer note 813029 . For messages stuck in Adapter Engine, select the errored out messages in MDT , reprocess them(this was a suggestion for a note we raised to SAP)
cheers
Saravana
Hi Saravana:)
have you tried scheduling report RSXMB_RESTART_MESSAGES
Regards,
michal
Message was edited by: Michal Krawczyk
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Michal,
I have not tried scheduling this report, one clarification , is this report goin to restart messages stuck in adapter framework also or only in the Integration Engine ?
I was thinking , it will help if somehow we can trigger autorestart based on the next message. Say, the target appln is down, messages will get stuck undelivered. Now i will troubleshoot the issue , bring the appln up again, then only send the next message(assumin i will stop furthur publishing of messages from source until then), now all the messages get picked up. Is this possible ?.
Scheduling the report will mean it will run at a regular time intervals picking all errored out messages and push them again rite!!.
cheers
Saravana
User | Count |
---|---|
87 | |
10 | |
10 | |
10 | |
7 | |
6 | |
6 | |
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.