Skip to Content
0

Both ICO and Receiver Determination exist for a Sender Interface and sender service.

May 01 at 05:15 AM

27

avatar image
Former Member

Hello Experts,

In our PI 7.31 SP08 system, I am able to create both ICO and Receiver Determination objects for the same sender interface and service. Can you confirm if this is standard behavior?

Also, before creating the ICO, the configuration overview for the Receiver Determination object, showed the Interface determination, agreements and channel. Whereas after creating ICO, ICO is being shown in the configuration overview.

How does this work at runtime, does the routing happen on java stack or ABAP stack?

Regards,

Diptee

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

2 Answers

Best Answer
Liz Jin
May 01 at 05:35 AM
0

Hello Diptee,

Since your PI 7.31 SP08 is dual stack, so you have two choices to process XI messages, one is dual stack mode, the other is AAE mode(java only). If you want to use the message processing with dual stack mode, i.e. with Integration server(ABAP) involved, you should create the classical configuration objects, e.g. receiver determination, interface determination and etc.

If you want XI message processed only in java stack, then please configure the ICO, then the messages will be processed on AAE, no Integration Server(ABAP) will be involved. ICO - A configuration object which decides the sender,mapping,routing,receiver rules.

http://castdemy.com/whats-the-different-between-ae-vs-aae-vs-aex/

Please let me know if anything unclear.

Best Regards,

Liz

Show 4 Share
10 |10000 characters needed characters left characters exceeded
Former Member

Hello Liz,

My question is that the system is allowing me to create both the classical configuration and ICo objects, for the same sender interface at the same time, which I think should not be allowed. As per my understanding, at one point in time, I should be allowed to use either the classical config or ICO and not both.

However, our system is currently allowing us to do this. PFB the screenshot of how the receiver determination object looks like, after creating ICO for the same interface.

ico.png (17.0 kB)
0

Hello Diptee,

From the screenshot, I only found the sender and receiver channels, no sender agreement found. The sender agreement is the key object to check the duplicate entries of ICO and classical configuration. Now ICO exists, if you create the sender agreement, it will be not allowed, the classical configuration will not work without sender agreement. If you have created the sender agreement, the ICO will not be allowed to create, vice versa.

Best Regards,

Liz

1
Former Member

So essentially, in our case, both the java stack and ABAP stack configurations will work normally, i.e. if the idocs are sent to the respective ports?

0
Former Member

Yes exactly ..the old interfaces which are configured with type G port will run via ABAP stack and if you planning to use ICO then redirect it via changing the port to tRFC type.

1
Manoj K May 01 at 06:47 AM
0

Just too add here , even though you have created RD and ICO for the outbound idoc only one gets triggerd thid depends on the Port configured in Partner profile in the backend ECC system if its tRFC port then ICO gets triggerd if Type G then classical .

Share
10 |10000 characters needed characters left characters exceeded