Stop IDOC receiver channel

[Former Member]

Hi folks,

I have what seems like a simple question about IDOC receiver channels, but I have yet to find an elegant answer.

My scenario is a Non-SAP system with an http sender through XI to an R/3 IDOC receiver. My R/3 system will go down for upgrade for a 2 day period but the external system will continue to send messages.

I suspect the IDOCs will queue in XI while R/3 is down because the RFC destination is unreachable, but I would like to stop attempts to send while the R/3 system is down.

I know about availability times for other channels but this technique is not available for IDOC. Is there some way of scheduling the IDOC distribution from XI so that no attempt to send to R/3 is made during the outage ???

Thanks in advance,

Guy

[Former Member · Accepted solution]

you can put a wrong target server string in the RFC destination in SM59 or a wrong password in the logon tab or specify a wrong port .

there's no other way to deactivate an RFC destination

[Former Member · Accepted solution]

Thanks Karthik,

That's exactly what I did to demonstrate what might happen (used the wrong password). The message went into error, I reset the password and re-processed and all was fine.

It just seems to me that there should be a cleaner way - maybe something in QOut scheduling ??

Thanks,

Guy

[Former Member · Accepted solution]

I think I may have found the answer I'm looking for.

In SXMB_ADM, I can de-register outbound queues. In this condition, the message status is not errored but 'scheduled for outbound processing' . Once the queues are re-registered, the messages are sent without any further action. More elegant I think (but of course the same net effect !)

Thanks,

Guy

[Former Member · Accepted solution]

If you de-register then it will get stuck in the outbound queue .

[Former Member]

As IDOC Adapter does not give Adapter Status option to make it inactive . The above suggestion can only help you my friend , there is no other way as IDOC adapter is from ABAP stack.