Difference between IDOC & RFC

1. Can someone explain the difference between IDOC & RFC
2. from processing point of view which one would be the best performance

IDOC      BAPI
IDocs are text encoded documents with a rigid structure that are used to exchange data between R/3 and a foreign system.
BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.
Idocs are processed asynchronously and no information whatsoever is returned to the client,
BAPIs are called synchronously and (usually) return information
The target system need not be always online. The IDOC would be created and would send the IDOC once the target system is available (tRFC concept). Hence supports guaranteed delivery
whereas for BAPIs the client code needs to do the appropriate error handling.
With asynchronous links the sub-process on the client can be finished even if the communication line or the server is not available. In this case the message is stored in the database and the communication can be done later
Problems with synchronous links occur if the communication line or the server is temporarily not available. If this happens, the sub-process on the client cannot be finished (otherwise there would be data inconsistencies).
The disadvantage of asynchronous links is that the sub-process on the server cannot return information to the calling sub-process on the client. A special way for sending information back to the client is required. In addition, a special error handling mechanism is required to handle errors on the receiving side.
Synchronous links have the advantage that the sub-process on the server can return values to the sub-process on the client that has started the link.
IDOCs may
be more changeable from release to release.
BAPIs are not totally immune to upgrades
IDOCs are poorly documented
BAPIs are reasonably well documented.

Similar Messages

Difference between idoc and rfc

what is the difference between idoc and rfc? when and where it is used? when there is idoc, why rfc vice versa?

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program. IDocs serve as the vehicle for data transfer in SAP's Application Link Enabling (ALE) system.
IDocs are used for asynchronous transactions: Each IDoc generated exists as a self-contained text file that can then be transmitted to the requesting workstation without connecting to the central database.
Another SAP mechanism, the Business Application Programming Interface (BAPI) is used for synchronous transactions.
A large enterprise's networked computing environment is likely to connect many geographically distributed computers to the main database. These computers are likely to use different hardware and/or operating system platforms. An IDoc encapsulates data so that it can be exchanged between different systems without conversion from one format to another.
IDoc types define different categories of data, such as purchase orders or invoices, which may then be broken down into more specific categories called message types. Greater specificity means that an IDoc type is capable of storing only the data required for a particular transaction, which increases efficiency and decreases resource demands.
An IDoc can be generated at any point in a transaction process. For example, during a shipping transaction process, an IDoc may be generated that includes the data fields required to print a shipping manifest. After a user performs an SAP transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The communication
layer performs a Remote Function Call (RFC), using the port definition and RFC destination specified by the customer model.
The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external system
RFC
Remote Function Calls (RFC) and data exchange through IDoc message documents. RFC makes direct and synchronous calls of a program in the remote system. If the caller is an external program it will call an RFC-enabled function in R/3 and if the calling program is the R/3 system it will call an RFC-function in another R/3-system or it will call a non-R/3 program through a gateway-proxy (usually rfcexec.exe). BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.
note:reward points if solution found helpfull.....
regards
chandrakanth.k

Difference between IDOC Bundling and IDOC Packaging

Hi,
Can anybody please explain the difference between IDOC bundling and IDOC packaging?
Thanks,
Loveena.

Hi,
IDoc Bundling is the changing the occurance of IDoc.
In a scenario If there is a necessitity for changing the Occurance of some segment of the IDOC u have to perform this steps
1.Import the IDoc to XI.
2.Export the IDoc(i.e XSD format) and save it to the local machine.
3.Make changes to the IDoc structure by modifying the XSD file in the local machine.
4.Save it as an XSD file Itself.
5.Import the XSD file in the IR under the External Defination.
6.Use this XSD in your Message Interface/Mapping which is same as IDoc structure but with some changes that u have made.
Go Thru this Blog <a href="/people/michal.krawczyk2/blog/2005/12/04/xi-idoc-bundling--the-trick-with-the-occurance-change Bundling - Trick without BPM</a> BY Michal Krawczyk where the Occurance of the IDoc is changed to 1...Unbounded from 1...999999999 by using the XSD.
IDoc Packing is collecting of IDoc
<a href="/people/pooja.pandey/blog/2005/07/27/idocs-multiple-types-collection-in-bpm of Multiple type IDOCs in BPM</a> BY Pooja
Regards
Santhosh
Remember to set the thread to solved when you have received a solution
[url=Use a Good Subject Line, One Question Per Posting - Award Points; Use a Good Subject Line, One Question Per Posting - Award Points[/url]

Difference between Adaptive RFC and Adaptive RFC2 model

Hi,
What is the difference between Adaptive RFC and Adaptive RFC2 model ?
Regards,
Sunaina Reddy T

Hi
Main difference are
1.JCo 3.0 to connect to SAP Systems
2.Improved connection management
3.Faster performance
4.Lower memory consumption
5.SystemLandscape API is no longer needed
6.Compatible to ARFC1 to allow easy migration
Check the thread for further input
1.[Whatu2019s New in Web Dynpro Java?|https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/8062c7d3-c86f-2b10-4894-a9a323da20b3]
Best Regards
Satish Kumar

Difference Between IDOC Message Type PORDCH & ORDCHG

Hi
Could anybody clarify me difference between Idoc types PORDCH & ORDCHG.
For PO Change (Can be adding new line item, deleting existing line item, Change existing line item )
which IDOC is suggested.
Can i use ORDCHG Idoc for this purpose, But i find many fields are not exist in this segment.
Pl clarify.
Rams.

Use ORDCHG message type with basic type ORDERS03

Difference between IDOC segments starting with E1 and E2

Hi all,
What is the difference between IDOC segments starting with E1 and E2
Thanks

Hi Kajol,
A segment in SAP system is technically implemented as three physically separate pieces.
1. Segment type u2013 the version-independent name of the segment. Standard SAP names begin with E1.
2. Segment definition u2013 contains the fields which represent the data. Its maximum size is 1000 bytes. Standard SAP definitions start with E2 with the last 3 characters implying the version of the segment.
3. Segment documentation u2013 represents the data dictionary documentation for each field in the segment definition. It begins with E3 for SAP provided segments.
For example, E1EDP01 will be your segment type and E2EDP01003 will be your segment definition with 003 indicating its version.By default, the segment type points to the latest segment definition.
Kindly do reward points if you find this as useful.
Regards,
Aswin

Difference between IDOC Type WBBDLD06 and WP_PLU03

Hello Friends,
Can you please suggest me the difference between IDOC Types WBBDLD06 and WP_PLU03.
Regards,
Narendra Goyal

No Answer

Difference between Idoc Adapter and Proxies..

HI XI Guru's,
I am new to XI, I wanted to know what is the difference between Idoc adpater and proxies. When and what should be preffered ?
Warm Regards,
- Priya R

idocs which mean - (intermediate documents) are standard document formats which sap systems use to store as well send data from one system to another. If this is the format in which data has to received by R/3 then you will use idoc adapter in XI. idoc adapter can be used to communicate between systems is with SAP release higher than 3.1.X. Communication using idoc adapter is always asynchronous.
proxies are available for communication between SAP systems with version WAS 6.20 and above. They support both synchronous as well as asynchronous modes of communication. Generally when you are looking at developing new application using WAS 6.20 and above then you can design the interfaces for this new applications in SAP XI and generate the required code for these interfaces automatically in SAP systems using transaction code - SPROXY in the case of ABAP Proxy and in the case of Java proxies the code is generated by SAP XI system itself. You only have to implement these interfaces in your new application. So, basically you have to only worry about building the application and the interface part is taken care by XI itself. you can also look at using proxies when data has to be inserted or fetched from custom/standard tables in R/3 using XI.
,idoc adapter can be used for commuincation between ABAP stacks only but Proxy can be used for both ABAP as well JAVA stack.

Difference between IDOC Type and Message Type

Hi, please let me know the difference between IDOC type and Message Type?
Thanks

Hi,
Message type is business name for IDOC you are sending hiding all technical details of the IDOC.
IDOC type gives more technical information about structure of the IDOC.
You will be linking IDOC type to message type while processing IDOC in runtime. You will be specifying message type and IDOC type in WE20 trasaction which says which message will go to which partner whether it is outbound or inbound.
Best Regards,
Krishna

Difference between Idoc ACC_INVOICE_RECEIPT03 & INVOIC

Hi
I am a total FI ignorant (I know SD so I can answer questions there!); I was asked to think of an interface that posts AP invoices.
Some invoices have a purchase order (and we need to finish the MM flow) so the interface can use Idoc INVOIC01/02 I believe. But some invoices do not have a PO number and need to be either posted or parked.
Can I use the same Idoc for that (with dummy PO), or should I use ACC_INVOICE_RECEIPT03 ? of course I would prefer to use the same Idoc for everything if possible...
I don't understand the difference between the 2 Idocs.
Thanks for your help.
Agathe

Hi,
Chekc the IDoc received, may the amounts are in proper format, check with the ABAPer for correct format.
VVR

Difference between different RFCs

Hi All,
Could you please provide me with some useful material or brief knowledge where i can find out :
what is an s-RFC, t-RFC and q-RFC ? ?
Where all these are used ? ?
And what is the Difference between them ? ?
Regards,
Arkesh Sharma

Please check this link
http://help.sap.com/saphelp_nw2004s/helpdata/en/62/73241e03337442b1bc1932c2ff8196/content.htm
http://help.sap.com/saphelp_nw2004s/helpdata/en/6f/1bd5b6a85b11d6b28500508b5d5211/content.htm
The qRFC Communication Model
qRFC Properties and Possible Uses
All types of applications are instructed to communicate with other applications. This communication may take place within an SAP system, with another SAP system, or with an application from a remote external system. An interface that can be used for dealing with this task is the Remote Function Call (RFC). RFCs can be used to start applications in remote systems, and to execute particular functions.
Whereas the first version of the RFC, the synchronous RFC, (sRFC) required both systems involved to be active in order to produce a synchronous communication, the subsequent generations of RFC had a greater range of features at their disposal (such as serialization, guarantee for one-time-only execution, and that the receiver system does not have to be available). These features were further enhanced through the queued RFC with inbound/outbound queue.
Communication between applications within an SAP system and also with a remote system can basically be achieved using the Remote Function Call (RFC). Here, the following scenarios are possible:
· Communication between two independent SAP systems
· Communication between a calling SAP system and an external receiving system
· Communication between a calling external system and an SAP receiving system
The following communication model shows what these communication scenarios may look like in reality. The actual sending process is still done by the tRFC (transactional Remote Function Call). Inbound and outbound queues are added to the tRFC, leaving us with a qRFC (queued Remote Function Call). The sender system is also called the client system, while the target system corresponds to the server system.
Scenario 1: tRFC
This scenario is appropriate is the data being sent is independent of each other. A calling application (or client) in system 1 uses a tRFC connection to a called application (or server) in system 2. In this scenario, data is transferred by tRFC, meaning that each function module sent to the target system is guaranteed to be executed one time only. You cannot define the sequence in which the function modules are executed, nor the time of execution. If an error occurs during the transfer, a batch job is scheduled, which sends the function module again after 15 minutes.
Scenario 2: qRFC with outbound queue
In this scenario, the sender system uses an outbound queue, to serialize the data that is being sent. This means that function modules which depend on each other (such as update and then change) are put into the outbound queue of the sender system, and are guaranteed to be sent to the target system one after each other and one time only. The called system (server) has no knowledge of the outbound queue in the sender system (client), meaning that in this scenario, every SAP system can also communicate with a non-SAP system. (Note: the programming code of the server system must not be changed. However, it must be tRFC-capable.)
Scenario 3: qRFC with inbound queue (and outbound queue)
In this scenario, as well as an outbound queue in the sender system (client), there is also an inbound queue in the target system (server). If a qRFC with inbound queue exists, this always means that an outbound queue exists in the sender system. This guarantees the sequence and efficiently controls the resources in the client system and server system. The inbound queue only processes as many function modules as the system resources in the target system (server) at that time allow. This prevents a server being blocked by a client. A scenario with inbound queue in the server system is not possible, since the outbound queue is needed in the client system, in order to guarantee the sequence and to prevent individual applications from blocking all work processes in the client system.
Properties of the Three Communication Types
To help you decide which communication type you should use in your system landscape for your requirements, the advantages of the three communication types are listed below:
1. tRFC: for independent function modules only
2. qRFC with outbound queue: guarantees that independent function modules are sent one after each other and one time only (serialization). Suitable for communication with non-SAP servers.
3. qRFC with inbound queue: in addition to the outbound queue in the client system, an inbound queue makes sure that only as many function modules are processed in the target system (server) as the current resources allow. Client and server system must be SAP systems. One work process is used for each inbound queue.
The qRFC Communication Model
Purpose
Communication within an SAP system or with a remote system can take place using Remote Function Call (RFC). This enables the following scenarios:
· Communication between two independent SAP systems
· Communication between a calling SAP system and an external receiving system
· Communication between a calling external SAP system and an SAP system as the receiving system
Implementation Considerations
The following communication model shows how these communication scenarios can occur in practice. tRFC (transactional Remote Function Call) is still responsible for actually sending communications. tRFC is preceded by inbound and outbound queues, which have led to the name qRFC (queued Remote Function Call). The sending system is called the client system, and the target system represents the server system.
There are three data transfer scenarios:
Scenario 1: tRFC
This scenario is suitable if the data being sent is not interrelated. A calling application (or client) in system 1 uses a tRFC connection to a called application (or server) in system 2. In this scenario, the data is transferred using tRFC. This means that each function module sent to the target system is guaranteed to be processed once. The order in which the function modules are executed, and the time they are executed, cannot be determined. If a transfer error occurs, a background job is scheduled that resends the function module after a defined period of time.
Scenario 2: qRFC with Outbound Queue
In this scenario, the sending system uses an outbound queue to serialize the data being sent. This means that mutually dependent function modules are placed in the outbound queue of the sending system and are guaranteed to be sent in the correct sequence, and only once, to the receiving system. The called system (server) has no knowledge of the outbound queue in the sending system (client). Using this scenario, every SAP system can communicate with a non-SAP system (the program code of the server system does not need to be changed, but it must be tRFC-compliant).
Scenario 3: qRFC with Inbound Queue (and Outbound Queue)
In this scenario, in addition to the outbound queue in the sending system (client), there is also an inbound queue in the target system (server). qRFC with an inbound queue always means that an outbound queue exists in the sending system. This guarantees that the sequence of communications is preserved, and at the same time the resources in the client and in the server system are controlled efficiently. The inbound queue is processed using an inbound scheduler, which only processes as many queues in parallel as the current resources in the target system (server) will allow, This prevents a server from being blocked by a client.
Features
Features of the Three Communication Types
To help you decide which communication types you need to implement according to your system landscape and your requirements, the advantages of the three types of communication are explained below:
· tRFC
Suitable only for independent function module calls; the sequence of the calls is not preserved
· qRFC with outbound queue
Function modules in a queue are guaranteed to be processed only once and in sequence (serialization). Also suitable for communication with non-SAP servers.
· qRFC with inbound queue
The function modules created in the outbound queue are transferred from the outbound queue to the inbound queue; the sequence of the function modules is preserved. An inbound scheduler processes the inbound queues in accordance with the specified resources. Both the client and the server system must be SAP systems. One work process is used for each inbound queue.
Queued Remote Function Call (qRFC)
Purpose
All types of applications are instructed to communicate with other applications. This communication may take place within an SAP system, with another SAP system, or with an application from a remote external system. An interface that can be used for dealing with this task is the Remote Function Call (RFC). RFCs can be used to start applications in remote systems, and to execute particular functions.
Integration
In contrast the first version of RFC, synchronous RFC (sRFC), which required both participating systems to be active to form synchronous communication, subsequent generations of RFC now provide a considerably extended range of functions (for example, serialization, guarantee that processing occurs once, and the receiving system does not have to be available). These features were further enhanced through the queued RFC with inbound/outbound queue.
Contents:
The information about qRFC is organized into the following main sections, with more detailed subsections:
The qRFC Communication Model
· qRFC with Outbound Queues
· qRFC with Inbound Queues
qRFC Administration
· qRFC Administration: Introductory Example
· Outbound Queue Administration
· Inbound Queue Administration
qRFC Programming
· qRFC Programming: Introductory Example
· Outbound Queue Programming
· Inbound Queue Programming
· qRFC API
For an introduction to the new bgRFC (Background RFC), use the following links:
bgRFC (Background RFC)
· bgRFC Administration
· bgRFC Programming
Using Asynchronous Remote Function Calls
Asynchronous remote function calls (aRFCs) are similar to transactional RFCs, in that the user does not have to wait for their completion before continuing the calling dialog. There are three characteristics, however, that distinguish asynchronous RFCs from transactional RFCs:
· When the caller starts an asynchronous RFC, the called server must be available to accept the request.
The parameters of asynchronous RFCs are not logged to the database, but sent directly to the server.
· Asynchronous RFCs allow the user to carry on an interactive dialog with the remote system.
· The calling program can receive results from the asynchronous RFC.
You can use asynchronous remote function calls whenever you need to establish communication with a remote system, but do not want to wait for the functionu2019s result before continuing processing. Asynchronous RFCs can also be sent to the same system. In this case, the system opens a new session (or window). You can then switch back and for between the calling dialog and the called session
To start a remote function call asynchronously, use the following syntax:
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname
DESTINATION ...
EXPORTING...
TABLES ...
EXCEPTIONS...
The following calling parameters are available:
§ TABLES
passes references to internal tables. All table parameters of the function module must contain values.
§ EXPORTING
passes values of fields and field strings from the calling program to the function module. In the function module, the corresponding formal parameters are defined as import parameters.
§ EXCEPTIONS
See Using Predefined Exceptions for RFCs
RECEIVE RESULTS FROM FUNCTION Remotefunction is used within a FORM routine to receive the results of an asynchronous remote function call. The following receiving parameters are available:
§ IMPORTING
§ TABLES
§ EXCEPTIONS
The addition KEEPING TASK prevents an asynchronous connection from being closed after receiving the results of the processing. The relevant remote context (roll area) is kept for re-use until the caller terminates the connection.
Transactional RFC (tRFC)
Transactional RFC(tRFC, previously known as asynchronous RFC) is an asynchronous communication method that executes the called function module just once in the RFC server. The remote system need not be available at the time when the RFC client program is executing a tRFC. The tRFC component stores the called RFC function, together with the corresponding data, in the SAP database under a unique transaction ID (TID).
If a call is sent, and the receiving system is down, the call remains in the local queue. The calling dialog program can proceed without waiting to see whether the remote call was successful. If the receiving system does not become active within a certain amount of time, the call is scheduled to run in batch.
tRFC is always used if a function is executed as a Logical Unit of Work (LUW). Within a LUW, all calls
· are executed in the order in which they are called
· are executed in the same program context in the target system
· run as a single transaction: they are either committed or rolled back as a unit.
Implementation of tRFC is recommended if you want to maintain the transactional sequence of the calls.
Disadvantages of tRFC
· tRFC processes all LUWs independently of one another. Due to the amount of activated tRFC processes, this procedure can reduce performance significantly in both the send and the target systems.
· In addition, the sequence of LUWs defined in the application cannot be kept. It is therefore impossible to guarantee that the transactions will be executed in the sequence dictated by the application. The only thing that can be guaranteed is that all LUWs are transferred sooner or later

Difference Between ASYN-RFC and TRFC

What is the difference between <b>ASYNCHRONOUS RFC</b> and <b>TRANSACTIONAL RFC</b>. I'm totally confused.

Hi
Asynchronous remote function calls (aRFCs) are similar to transactional RFCs, in that the user does not have to wait for their completion before continuing the calling dialog. There are three characteristics, however, that distinguish asynchronous RFCs from transactional RFCs:
·        When the caller starts an asynchronous RFC, the called server must be available to accept the request.
The parameters of asynchronous RFCs are not logged to the database, but sent directly to the server.
·        Asynchronous RFCs allow the user to carry on an interactive dialog with the remote system.
·        The calling program can receive results from the asynchronous RFC.
You can use asynchronous remote function calls whenever you need to establish communication with a remote system, but do not want to wait for the functions result before continuing processing. Asynchronous RFCs can also be sent to the same system. In this case, the system opens a new session (or window). You can then switch back and for between the calling dialog and the called session
RECEIVE RESULTS FROM FUNCTION Remotefunction is used within a FORM routine to receive the results of an asynchronous remote function call. The following receiving parameters are available:
        IMPORTING
        TABLES
        EXCEPTIONS
The addition KEEPING TASK prevents an asynchronous connection from being closed after receiving the results of the processing. The relevant remote context (roll area) is kept for re-use until the caller terminates the connection.

Difference between idoc and .txt

What would be the main difference between managing an interface with txt files and creating idocs to make a connection on SAP and an external system.

Refer this thread -
what are the advantages of idoc compare to flat file. how data is secure
Regards,
Amit

DIFFERENCE BETWEEN iDOC MESSAGING AND bDOC MESSAGING

hI
gurus what is the diffrence between idoc messaging and bdoc messaging?
K. Mangalum

Hi Kumara,
BDOC:
Container of business data that belongs together, for example customer, contact person, order or activity. This means that it contains all required information for a business process. The technical representation of a BDoc type is completely independent. There are many possible representations for a BDoc type.
For example, a BDoc type can be represented as follows:
as a collection of internal ABAP table structures (on the CRM Server),
by ADO record sets (on mobile clients),
as an XML form (for non-SAP systems), or,
as an IDoc.
Therefore a BDoc type is a semantic collection of business data and not a syntactical description.
There are three classes of BDoc types:
BDoc types exclusively used for mobile applications
They consist of a hierarchical data segment structure with assignment to database tables.
BDoc types for synchronization between the consolidated database in the CRM Server and mobile applications
They consist of a hierarchical segment structure with assignment to database tables.
BDoc types exclusively used for non-mobile applications
They consist of:
a hierarchical segment structure with no assignment to database tables,
additional data (complex data type modeled in the ABAP Dictionary)
Standard BDoc types are provided by SAP. Additional BDoc types can be modeled by customers.
Idoc:
IDOC: An intermediate document, container for exchanging data between R/3 and other SAP and non-SAP applications. Structured collection of segments. Segments are structured collection of data elements.
General Structure
IDocs contain administration information for technical processing, as well as the actual application data, which is stored in segments. A segment comprises segment fields as the smallest unit of the IDoc - comparable with the data elements from the EDIFACT standard.
In the SAP System, the processing status ("what has happened to the IDoc before now?") is stored in the IDoc status information. The status information also contains details about errors and indicates the data in which the error occurred. This status information is not forwarded as part of the IDoc but separately using "status processing".
IDoc types (special structure)
An IDoc type is defined through its permitted segments. Segments can be dependent on each other (parent and child segments). For example, segment E1EDPT1 (document item text identification) is a child segment of segment E1EDP01 (document item data, general) in IDoc type EXPINV01 (export billing) and a child segment of E1EDP07 (order data shipping notification) in IDoc type DESADV01 (shipping notification). The segment, therefore, is used in several contexts and is the "child" of several "parents".
CRM Bdoc and IDoc are both persisted data structures.
Idoc works on a particular technology called ALE and is used for data exchange between two R/3 systems
Regards,
Satish Mathala

Difference between IDOC for creation, change and deletion

Hi,
As per the requirement, an IDOC will be generated for PO, Vendor Masters and Goods receipt when ever a PO or Vendor or Goods receipt is created or changed. How can we identify whether the IDOC has been created for creation or change of a particular thing? Is there any identifier where in we can check whether the IDOC generated is for creation or change?
And also how to identify that a particular PO or VM or GR has been deleted or cancelled?
Thanks & Best Regards,
Phani.

hi,
to check the idoc status ie idoc created or changed --use transaction WE05
we02 to diplay idoc
please rewrd points if helpful,
shylaja

Difference between IDOC & RFC

Similar Messages

Maybe you are looking for