Interface knowledge in short

Idoc and Proxy difference

IDOC : When you populate an IDOC and send the IDOC, receiver receives the IDOC and then processes it using a
Function Module.
Proxy : Proxy is a structure which is filled by the sender. This structure is placed at a predefined place or directory
from where the receiver can pick it up and use it further. There is no processing function module associated with the
proxy.
IDOC :It has Standard Structure,Sender Communication Channel is not required,Used only for asyncronous
Communication.
Proxy: Depending upon the requirement have to create the structure,It supports huge volume of data
processing,Can be used for both sync & async .

Different Adapters for different Scenarios

In picking the right adapter, sometimes there is a confusion, while integrating with SAP systems. Here we will try to explore the options
available and the points that one should consider before deciding  the adapters for a given scenario.
The list of Adapters given by SAP can be classified, based on the type of systems that these adapters are going to communicate with.

One system with which XI is going to communicate will definitely be the SAP system (SAP R/3 - 4.6C, 4.7, ECC 5.0, CRM, SRM, etc). Now
these systems could be on the sending side or on the receiving side or could be on both sides where R/3 is integrating with SRM / CRM .... or
vice versa.
Now, the options that SAP gives us to communicate with SAP systems.

1. IDOC Adapter
2. RFC Adapter
3. Proxy

 How do you choose the right one for a given scenario:

- Use Proxies only if the WAS version is >= 6.20. Use Proxies only if the WAS version is >= 6.20. (SAP Web Application Server 6.20,)

We will also look into other reasons where we should go for a proxy.

Let's take a case and discuss the same.

The immediate question that probably you are getting is:
I am on WAS 6.2 or higher and also at the same time either I have a standard BAPI / Remote enable function module for the given functionality
on the application system. So, what should I do now?

In this case, there are 2 ways in which the implementation can happen.

1. Configure a RFC Adapter and call the BAPI / RFC. However the potential problem that I could see is that the RFC adapter existing on the
Java stack communicating with the BAPI existing on the SAP application system.
2. The second option that I have got is to write a proxy on the SAP application system (which will be called by XI) and internally the proxy will
call the BAPI.
At this point of time if your question is, as long as I am dealing with the latest versions of SAP systems, should I totally avoid using RFC
Adapters - MY TAKE on this would be, YES. Do NOT use RFC Adapter, rather go ahead and use the proxy.
However, the problem could be that the pre-built meta data and the mapping that SAP delivers might not be useful as the BAPI is wrapped with
a PROXY now. But as the proxy is also expected to have the same message interface as that of the BAPI, we might still be able use the pre-
defined mapping. This is something that we need to try out and then decide how do I go about this interface.

But for whatever reasons, if you are not getting advantage of the pre-defined integration content, PROXY is the way to go.
Now, if you are dealing with SAP systems < 6.20, we do NOT have choice of PROXY anyway, so go ahead and use a RFC adapter.
Now, as far as the IDOC adapter is concerned I think the choice would be straight forward. Where ever there is a standard IDOC given by SAP
(usually mapping also will be delivered for SRM / CRM system integrations), so go ahead and use the same.
The questions that you might be having now is that for a standard object if I have an IDOC as well as a BAPI, which one do I go for.
My opinion would be its going to be dependent on the specific scenario that you are trying to develop. We can think of multiple variations of
design for this case.For Example

1. Send one IDOC at a time.

2. Club multiple IDOCS and send as a single IDOC.

3. Make one single RFC call, for each business transaction.

4. Avoid making multiple calls to the same BAPI / RFC, rather have a wrapper BAPI and send all the records in one time.

5. Use the PROXY and send all the data in one shot and make single calls to the BAPI from the PROXY on the application system -
only if you can use PROXIES.

The biggest advantage of the proxy is that it always by passes the Adapter Engine and will directly interact with the application system and
Integration engine - so it will and should give us a better performance.

So, there are the choices that you have while designing a SAP interface, so take a close look at the interface and identify your priorities for the
interfaces. The parameters could be something like PERFORMANCE, ERROR LOG, AUDIT LOG, MONITORING OF THE TRANSACTIONS
INDIVIDUALLY. Do a comparison of the pros and cons of the choice of adapters that you have for the parameters for the specific interface and
then make a call.

Initially, it might look alike - what's the big deal, it's a simple case of sending / receiving data from SAP - especially if you are coming from R/3
world, but believe me, you have got good chances of landing up in trouble, if you don't take care of your priorities of the interface.

Could any one tell me why we some time use BAPI, and some times use RFC and some times use IDOC while
communicating with the SAP systems.
Is there any differences while using the same.
RFC and BAPI are same as per the technical point of view both are remote enabled function module..
BAPI is provided by SAP while RFC is created by a developer..
IDoc is another proprietary technology of SAP for exchnaging messages .
Difference lies here :
1. For RFC/BAPI you need to use RFc adapter while for IDoc you need to use IDoc adapter..
2. For RFC you need to create RFC destinations not for Idoc
3. For Idoc you also need to manage Partners Profiles..inn R3..
These are few differences in using RFC/BAPI and Idoc...not the only ones..
RFCs are used when the caller and the called function module run in the same system.
In the SAP system, these functions are provided by the RFC interface system. The RFC interface system enables
function calls between two SAP systems, or between an SAP system and an external system.We get information in
response to RFC no functional acknowledgement will b received.
IDOC is just a predefined structure like where in u would post them to your peer in distributed environment.As a
response u can get functional acknowledgement for the IDOC which is being sent.
RFC is used when we need to get the details from the Rs system.
For example you have a company number coming from the file and you need to get the company information from
R3 system for that company number that time you use the RFC. SO you send a request to R3 system and you get
the response back from R3 system to XI.
As said IDOC is async its intermidiate doucments which has the predetrmined strucutre and which holds data for
transfer between systems.
This blog describes the steps involved in Inbound/server Proxy Development.

 
ABAP  Proxies

 ABAP Client Proxy

 
ABAP client proxies are generated from outbound message interface, and are used to send message from SAP WAS to XI. Client proxy
generation creates an ABAP class with the method EXECUTE_SYNCHRONOUS/ EXECUTE_ASYNCHRONOUS depends on the mode of the
interface. Along with the class it also generates structures and table type with the specified name prefix. The maximum length of 30 characters
is allowed while allotting names for the generated objects. 

 ABAP Server Proxy

 
ABAP server proxies are generated from inbound message interface. Server proxy generation creates an interface along with the
implementation class. The business functionality is defined in the implementation class. Upon receipt of a message, the ABAP proxy runtime
calls the method EXECUTE_SYNCHRONOUS of implementing class (in asynchronous communication EXECUTE_ASYNCHRONOUS).    

IDOC is good if its a standard IDOC, so that you don't have under go the pain doing the modifications for the custom
one.
In your case, PROXY might make more sense as you are saying that you have to do some custom processing as
well. So, you can call the BAPI / Function for the standard processing and then do the custom processing in your
Proxy code. And more over, if you have want to have a Synch interface, then you cannot use IDOC.
So, the options in this case boil down to PROXY / RFC.
PROXY will definitely have the advantage as its going to bypass the adapter engine and directly interact with the
Integration server. And moreover, even if you already have a RFC, you can always call that inside your PROXY.
However, the only flip side here compared to IDOC, is that you will have to create all your IR objects manually.

XI sends an IDOC to SAP. IDOC is processed at a later stage. Now a response is sent out to XI ( I think only ALE
audit is out of the box for acknowledgements. ) Now XI reads the original message which was sent to SAP and the
ALE audit message and then builds a response message to the Original Sender
Ans : Let take the case of a ORDERS IDOC, that you are sending to your business partner. Now, in this case if you
get a technical acknowledgement (ALEAUDIT) that the IDOC has been delivered. Now, ideally the business partner
should have configure an IDOC ORDRSP (Order Acknowledgement) to let you know that he has recieved the order
and everything is fine with the data. This is at a functional level.
Apart from this I am not aware of any other options. XI cannot read the IDOC from the target system as you are
expecting, unless the target system initiates the same.

Synchronus data processing is that in which the program calling the update task waits for the update work process
to finish the update before it continues processing.

In Asynchronus update the callng program does not wait for update work process to finish the update and
continues as normal.

Synchronous Update : This means say if u have 10 records to update and the processing is going on in a loop the
Synchronous update will wait till each update is actually done in the data base and then it will move on the next
record's updation.
Asynchronous : In This mode, the updates are lined one after the other and the system doesn't wait for the updates
to actually happen. These updates are then triggered by an internally scheduled job which then actually updates the
data in the databse.
Adapters are part of the Adapter Framework. Adapters provide the technical connectivity to enable the integration of
SAP and non-SAP applications through XI’s Integration Engine.Again, Adapters are used for connectivity from and
to external systems with XI that cannot communicate via proxies. Adapters are only required in SAP systems older
than 6.20 and external systems.
Systems based on 6.20or higher can communicate directly with proxies.
Proxies
The literal definition of a proxy is an object / process authorized to act for another; an agent or a substitute. In
simpler terms, proxies in the XI context are objects used to encapsulate the creation (from a sender system) or
parsing of XML (at a receiver system) as well as the communication with the relevant runtime components required
to send or receive those messages.
Proxies are generated from Message Interface in IR.
The Proxy Runtime controls these objects / processes, and can itself be controlled by the applications it
communicates with. The Proxy Runtime currently has the following components available: 1. ABAP Proxy Runtime –
Communication using XI or Web Services a. Web Service Runtime 2. Java Proxy Runtime – Communication using
XI (J2EE) The objects that the Proxy Runtime then controls are created via Proxy Generation, for both ABAP and
Java. In the following sections a ‘client’ proxy is used by an application to send messages outside of the system it
resides in (normally to the IS in this context). Conversely, a ‘server’ proxy is used by an application to receive
messages from sources outside itself (again, normally the IS in this context).
Proxies are interfaces which will get executed in the application system. They can be created only in the system
from message interfaces using the proxy generation functions. You can use proxies for systems with WAS >=6.20
XI will communicate in native language with SAP systems via proxies. Proxies uses XML - SOAP based
communication for both ABAP and Java Proxies.
mainly we go for proxies for adapters less communicaton there
Client Proxy: Proxies created out of Outbound message Interfaces.Here XI is receiving some information and is
acting as a client.
Server Proxy : Proxies created out of Inbound message Interfaces.Here XI sends the information to some other
system acting as the Server.
we can create the ABAP proxy in ABAP workbench.
Use
Using ABAP the proxy generation function you can generate ABAP proxy objects to an SAP system from an
interface description in the SAP Exchange Infrastructure Integration Repository.
Prerequisites
ABAP proxy objects can only be generated for SAP systems that are based on SAP Web Application Server
6.40.The proxy generation retrieves the WSDL description of the interface from the Integration Repository using
HTTP. The address of the appropriate server is taken from the exchange profile (parameters 1, 2, and 3 u2013 see
below). Queries to the Repository are subject to authentication. The user and password for these queries are also
taken from here (parameters 5 and 6). Information used to navigate from the ABAP Proxy Generation to the initial
page of the Integration Builder is also taken from the exchange profile (parameters 1, 2, and 4).