cancel
Showing results for 
Search instead for 
Did you mean: 

Does it mean.....IDOC - XI - File

Former Member
0 Kudos

Hi Experts,

I am very new to XI..

for IDOC to File

If IDOC resides at R/3 side then you don't require sender communication channel and sender agreement. Because it resides at Integration Engine. What does it mean?

My doubt is here if, File to IDOC

then same as like, you shouldn't require receiver communication channel and as well..Am I right??

Regards,

YRaj.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Exactly Seshagiri,

But, both are resides at Integration Server which contains IE and AE where IDOC resides at IE and RFC resides at AE.

So, is there any specific reason behind this to create senderCC for RFC ..if i am wrong??

Regards,

YRaj.

Former Member
0 Kudos

Hi,

IDOC Resides on ABAP Stack

RFC Resides on J2EE Stack

Here I Will tel u the Message Flow Behind this

When u r Using a RFC Adapter

First the adapter Shld Pic the Msg Using the RFC CC.

Then It will give the Msg to IE , the IE Can Post the Msg to IS Using the XI Adapter Internally.

So this is the Mechanism to post the Msg From Sender to IS---This is Onward journey

So If u Consider For IDOC Means

Here IDOC Resides on IE , So Here no Need of Adapter To Process the Steps so that IE can Receive the Msg.

So this is the Flow

Message Flow in XI----Please Go through this

/people/siva.maranani/blog/2005/05/25/understanding-message-flow-in-xi

Reward Points if Helpful

Regards

Sesh

Answers (5)

Answers (5)

Former Member
0 Kudos

Thaks Mr. Seshagiri....

Regards,

YRaj.

Former Member
0 Kudos

Hi Raj,

You said it's built-in adapter and doesn't run in J2EE adapter Framework.

But, XI have so many built-in adapters...like (IDOC, HTTP is ABAP Stack and rest of J2EE stack) so, in this case all the built-in adapters shouldn't require to create communication channels for senders..

And also, in the case of RFC - XI ...then you shouldn't create sender communication channel. Because RFC also built-in Adapter and already we did the configurations at R/3 side. But, we have to create Sender CC and Sender Agreement. Why for RFC?

Regards,

YRaj.

Former Member
0 Kudos

Hi

its not like tat

Incase of idoc, if u trigger idoc from R3 system u r directly posting the message into the integration engine so v r creating sender cc.

but in case of rfc its diffferent.

regards

yugapreetha

Former Member
0 Kudos

Hi,

Even though they both integrate R/3 but their undelying logic is totally different and coz of that they sit on different stacks,moreover SAP designed it that way coz its easier to manage and control them in that fashion.

And RFC Uses Jco Connections in Visual Admin to Communicate with the R/3 System

So that the Situation is like this

Reward points if Helpful

Regards

Sesh

Former Member
0 Kudos

Hi,

>>><i>If IDOC resides at R/3 side then you don't require sender communication channel and sender agreement. Because it resides at Integration Engine. What does it mean?</i>

IDOC And HTTP Resides on Integration Engine, So No Need of Any CC to Send the Data to XI Why Because IDOC Communicates with IS Directly, To Post the IDOC From R/3 to XI We use R/3 .When it comes to Receiver Compulsary We need Sender And Receiver to post the IDOC to R/3

So that we need the IDOC CC in the case of Receiver.

Reward Points if Help

Regards

Sesh

Former Member
0 Kudos

Hi,

The IDOC Adapter is implemented in ABAP and resides directly on the Integration Server. You cannot define a sender IDOC channel in directory due to the fact that the IDOC adapter does not run in J2EE Application Framework but is an built-in adapter

<b>Cheers,

*RAJ*</b>

Former Member
0 Kudos

Hi YRaj,

for IDOC to file, it is not mandatory to create sender CC since the corresponding configuration will be done at R3 side while processing the idocs.

for file to IDOC, you require receiver communication channel to send data from leagcy system to R3 system.

Idoc adapter executes on Integration engine which resides on ABAP stack of XI server.

Regards,

Ravi.