Question regarding Receiver Determination and Differente Namespaces

[Former Member]

Dear sirs,

I have the following scenario:

I have a mail account read by a sender communication channel IMAP4 in namespace http://a. The message is sent to a receiver communication channel type XI delivering to an ABAP Proxy at the same namespace. Everything works fine here.

I need to split the route: Reading the same mail account and depending on the message received send it to an ABAP Proxy of namespace http://A or namespace http://B. The receiver determination does not allow to configure destinations of different namespaces.

Please someone could give me an idea how to solve this issue?

Thank you in advance.

Fabio Purcino

[Former Member]

Hi,

There is the same ECC System with different ABAP Proxies.

Depending on a value of a TAG the message has to be delivered to an ABAP Proxy or the other.

Thanks,

Fabio

[rajasekhar_reddy14]

Develop two different mappings , check condition in interface determination , based on that mapping program will be executed, two receiver agrements required thats it.

Regards,

Raj

[Former Member]

Hi,

I have already two receiver agreement and two mapping programs but I'm not able to set these programs on interface mapping because it's on a different namespace.

I attached a image of my interface determination configuration.

[http://img683.imageshack.us/img683/7909/imagenamespacepi.jpg]

Best Regards,

Fabio Purcino

[Former Member]

Is the target is two different proxy ECC system???

I didnt understand the requirement of sending the information to two different namespace??

why the requirement is like that??

If the target is same ECC with two proxy structure then why r u creating two name space???

Chirag

[Former Member]

Hi,

maybe I did not understand correctly but you can do this with conditions in the interface determination.

There, you enter two lines. One for Namespace A and one for one for Namespace B. For each line you enter the corresponding condition.

Hope this was helpful.

Best regards,

Markus