Acknowledgements not getting to R3

[Former Member]

Hello,

We have a scenario as follows:

IDOC -> XI -> XI (IDOC).

(We send an IDOC from our R3 system, through the XI, and the other side recieves it as IDOC through their XI).

The IDOC reaches OK and acks are coming back as expected, but the problem is that they don't seem to get back to the R3 system (they "get suck" in the XI).

I have looked at the trace of the message and it says the usual "Error in back routing Error in communication channel".

I have gone through several blogs and documents about how to use acks, and what I understood from them is that the only thing I need as the sender of the original IDOC is to configure the communication channel (through which the ack is to return to the R3).

Is there something I missed?

Please note that for every IDOC that we receive, we map the header so that the sender system name is our XI's name (that way the R3 doesn't need to know about other systems). So it's possible that the problem occures because there is no header mapping for the ack (since there is no reciever agreement). Could it be the problem? And if so, how can it be solved (is there a way to force the message to go through the receiver agreement?).

Regards.

[Former Member]

Hello,

My problem was solved.

The probelm was that I created the communication channel for the wrong service - as I mentioned, the messages we send go through a header mapping. Therefore, when the ack is returned, the receiver it goes to is the name in the header mapping and not the original sender.

I solved this by creating a communication channel for the sender specified in the header mapping (and also creating that service itself...) and now the ack does return to the R3.

It should be noted that in the error message in the ack, it mentioned the name of the service in the header mapping (although there was no explanatory text).

Thanks to everyone who tried to help.

[former_member181962]

Hi Udi,

Check this thread if you havent done already:

Regards,

Ravi

[Former Member]

Hello,

Thank you for your reply. I have looked at that thread (and the links in it) and did not find a solution to my problem.

[Former Member]

Hi,

try below thread...Hope you may find an idea to go ahead from this thread..

[Former Member]

Hello,

Thank you but this did not answer my question. I don't have a BPM on this scenario and I don't wish to create one if it isn't necessary.

I'm not trying to do something complicated, just use the acks the way they are meant to be used, so I don't think I will need to use something like a BPM.

All I want in addition is to have the ack go through the header mapping. And because that might not even be the problem, I want to know if there's something missing in my solution.

Is there anything else besides a communication channel that should be done in order to receive the ack in the R3?

[Former Member]

Hi Udi,

Please check whether your Original Sender Interface ( IDoc Sender ) is of Abstract type . If not it needs to be abstract .

Regards,

Sarat

[Former Member]

Hello Sarat,

Please check whether your Original Sender Interface ( IDoc Sender ) is of Abstract type . If not it needs to be abstract .

What do you mean by Original Sender Interface? Do you mean that the Idoc which I send (and want to receive an ack for) should be abstact?

Right now, I receive the Idoc from our R3, it goes through a message mapping and then sent to the receiver. In what step should it be abstract?