Difference between Synchronous & ASynchronous.

Hi All,
I few queries:
1) Difference between Synchronous & ASynchronous communication?
2) How should we decide whether it is a Sync or Async scenario?
Regards,
Sreedhar.

Hi Sreedhar,
Apart from the points already added by experts, i would like to add something.....
Synchronous Communication:
In synchronous communication, thereu2019s nothing like scheduling. Sender application executes a u2018singleu2019 Function call, receiver system immediately processes this function call dispatching the response to sender and then it performs implicit database commit.
However this communication is based on assumption that receiver system is available when function call is made. If this is not the case, the communication is seriously disrupted.
Asynchronous Communication:
Here receiver system is not necessarily required to be active at the time of function call. Instead, the call is placed in outbound queue of the sender system and then this call is repeated at regular intervals until receiver system processes the call.
Also Error handling in Synchronous communication: error messages sent back to sender. In Asynchronous communication: errors made persistent.
So conclusion: Queues play central role in asynchronous communication. Further in asynchronous communication, the calls can be executed either by tRFC (Transactional RFC) or qRFC (Queue RFC).
If business requirement is such that your sender system need to know the successful posting of message in the receiver system then approach for synch communication else asynch communication.
Regds,
Pinangshuk.

Similar Messages

Difference between synchronous and asynchronous

Hi, i´m doing a t01 syncbo... what is the difference between synchronous and asynchronous?
What is better for syncbo t01, and for syncbo s01?
Thanks,

Hi
There are two options available:
Synchronus in which the data is exchanged while the mobile is online. The mobile sends the messages to the middleware and gets the response there and then, while it is online.
ASynchronus in which the mobile sends the messages to the middleware and goes offline. The responses are calculated and stored in the outbox. When the mobile again comes online and syncs, it gets the response messages.
The choice depends actually on the type of the syncBO, like if there is an Order being created on the mobile and its approval (which will come from the backend) is needed, most of the time immediately. This SyncBO must be Synchronus.
The other data, to which response is not immediately needed can be made as Syncronus.
The choice has serious performance considerations, So it should be made wisely.
Please ask if you need more information.
Thanks
Ankur
(Award Points if the info is useful)

Diff between synchronous & asynchronous updates of database with call trans

Hi Everyone,
I want to know the difference how synchronous and asynchronous
database update in call transaction method.
thanks

Hi,
In batch session interface: - Asynchronous processing means Transfers data for multiple transactions - Synchronous database update means during processing, no transaction is started until the previous transaction has been written to the database.
In CALL TRANSACTION: - Synchronous processing means Transfers data for a single transaction. Synchronous and asynchronous database updating both possible The program specifies which kind of updating is desired. Separate LUW for the transaction The system performs a database commit immediately before and after the CALL TRANSACTION USING statement.
Difference between Synchronous and Asynchronous processing?
Re: synchronous........
Suggest you to Search in SDN with key - Synchronous or asynchronous .
Will get few more useful related Posts.
Reward points if this Helps.
Manish

Differences between Synchronized methods and blocks

Hi all,
I would like to differences between Synchronized methods and blocks.
- Muni

Well, you'll get so many of right answers in next ten to thirty minutes.
I like to yield :)
Oooo... Ten minutes has passed.
Synchronized block is a toilet room with a lock in a public lavatory.
Only one person(running thread) can have the lock at a time.
And, she/he have to receive the lock from a particular object obj like:
synchronized(obj){.....} // one object has only one lock for this {} toilet and for any other toilets how many there are... *
(*: In other words, while a thread is executing a synchronized(obj){} block, other threads can't enter other synchronized(obj){} blocks.)
Synchronized method is a kind of synchronized block.
This special block is defaulted to have lock from the object on which the method is defined.
public class Foo{public synchronized Method(){}}
use the lock of a Foo object.
Message was edited by:
hiwa
Message was edited by:
hiwa

Differences between Synchronous and Asynchronous updates

can any one tell me the differences between these updates

Hi
Look at this tread it can help:
https://www.sdn.sap.com/sdn/collaboration.sdn?contenttype=url&content=https%3A//forums.sdn.sap.com/search%21default.jspa%3FforumID%3D131%26threadID%3D67445

Synchronous & asynchronous ---- very urgent

Could any one answer my question.What is the difference between 1.Asynchronous and synchronous process.
2.Asynchronous and synchronous database update.
3. Asynchronous and synchronous method
Thanks & Regards
sai

Asynchronous Update The program does not wait for the work process to finish the update. Commit Work.
Synchronous Update The program wait for the work process to finish the update. Commit Work and Wait.
Check this link for more details.
http://fuller.mit.edu/tech/sync_asynchronous.html
Regards,
Maha

Difference Between ASYN-RFC and TRFC

What is the difference between ASYNCHRONOUS RFC and TRANSACTIONAL RFC. 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 BATCH & RUNTIME ,SYNCHRONOUS & ASYNCHRONOUS

REPORT_EXECUTION_MODE has two values BATCH & RUNTIME.
what is the difference ? pls expalin in detail
REPORT_COMM_MODE has two values SYNCHRONOUS & ASYNCHRONOUS
what is the difference ? pls expalin in detail
Thanks in advance

Tony is right.
Anyway
Forms applications calling a report synchronously make the user wait while the
report is processed on the server.
For long-running Reports, it is best that you run the report asynchronously by
setting the REPORT_COMM_MODE property to asynchronous and the
REPORT_EXECUTION_ MODE to batch:
SET_REPORT_OBJECT_PROPERTY(report_id,REPORT_EXECUTION_MODE,BATCH);
SET_REPORT_OBJECT_PROPERTY(report_id,REPORT_COMM_MODE,ASYNCHRONOUS);Regards

Re : what is diffrent Between Synchronies and Asynchronies process

Hi ,
what is diffrent between Synchronies and Asynchronies process in session Method and call Transcation method pls give one Example...
Thanks
Arief .S

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.
A BDC done with sessions is always synchronus.
A BDC with call transaction is by default asynchronus
unless you define it explicitly as
call transaction 'XXXX' ...... update 'S'.
( If you donot define update option it is defaulted to "A" ).
The update method is of importance when one transaction locks data which may be required by a subsequent transaction . The subsequent transaction will fail if data is locked from previous one. An example would be you are creating sales order for same material in succession ( with asynchronus update ). Quite likely that some of transactions would fail due to material locked.
For large volume of data Call Transaction will be faster but you have no restart capability here. Suppose from 1000 transactions 100 fails . You will have to run the BDC program again exclusing the ones which wrere successful. However with session method you have the option to process the error transactions again in SM35 . So if you are sure that errors will not occur use call transaction else use session method.

HT1351 Two days ago most of my music dissapeared from my Ipod, however all of it is still in my iTunes Library. After synchronizing the Ipod there is ahuge difference between both music inm my library and the one in the Ipod.

Two days ago most of my music dissapeared from my Ipod, however all of it is still in my iTunes Library. After synchronizing the Ipod there is a huge difference between both music in my library and the one in the Ipod.

Hi Rodobaldo,
Let's try to clear up this issue for you, I'd like to clear out the music on your iPod first. You'll want to find the Sync Music Checkbox, uncheck it, then Apply or Sync:
Once you have done that, recheck the "Sync Music" checkbox, and apply the changes once more. This will instruct iTunes to completely remove all music from your iPod nano, and then copy the files once more. If you have a large amount of music, this initial sync may take a while.
If the above does not resolve your issue, see the following article:
iTunes: Syncing media content to iPod
http://support.apple.com/kb/HT1351
Thanks,
Matt M.

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

Differences between LSMW and BDC

Hi All
Please can you give me the few points about the differences between LSMW and BDC?
Awaiting for your Responce
Praveen

Hai Check with the following document
GOOD
THERE IS THREE TYPE OF METHOD IN BDC
BDC SESSION
CALL TRANSACTION
CALL DIALOG
What is BDC or batch input
The Batch Input is a SAP technic that allows automating the input in transactions. It lies on a BDC (Batch Data Commands) scenario.
BDC functions:
· BDC_OPEN_GROUP : Opens a session group
· BDC_CLOSE_GROUP : Closes a session
· BDC_INSERT : Insert a BDC scenario in the session
· The ABAP statement "CALL TRANSACTION" is also called to run directly a transaction from its BDC table.
It runs the program RSBDCSUB in order to launch automatically the session. The session management is done through the transaction code SM35.
The object itself is maintanable through the transaction SE24.
BDC methods:
Method
Description
Parameters
OPEN_SESSION
Opens a session
SUBRC (Return Code 0 OK)
SESSIONNAME (Session to be created)
CLOSE_SESSION
Closes a session
None
RESET_BDCDATA
Resets the BDC Internal Table...
None. Normally, for internal purpose
BDC_DYNPRO
Handles a new screen
PROGNAME (Name of the program)
DYNPRONR (Screen Number)
BDC_FIELD
Puts a value on the screen
FIELDNAME (Name of the field)
FIELDVALUE (Value to be passed)
CONSTRUCTOR
Constructor - Initializes NO_DATA
NODATA (No data character). The constructor is called automatically when the object is created.
RUN_SESSION
Launches a session with RSBDCBTC
None
CALL_TRANSACTION
Calls a transaction with the current BDC Data
MODE (Display Mode)
UPDATE (Update Mode)
TCODE (Transaction to be called)
BDC_INSERT
Inserts the BDC scenario in the session
TCODE (Transaction to be called)
BDC techniques used in programs:
1) Building a BDC table and calling a transaction,
2) Building a session and a set of BDC scenarios and keeping the session available in SM35,
3) Building a session and lauching the transaction right after closing the session.
BDC using Call Transaction
BDC using Call transaction involves calling an SAP transaction in back ground from within the ABAP
program. The process involves building an Internal BDC table containing the screen information needed to
execute the required transaction and then passing this to the Call transaction command (See code example).
The full procedure for creating a BDC program is as follows:
What is the difference between batch input and call transaction in BDC?
Session method.
1) synchronous processing.
2) can tranfer large amount of data.
3) processing is slower.
4) error log is created
5) data is not updated until session is processed.
Call transaction.
1) asynchronous processing
2) can transfer small amount of data
3) processing is faster.
4) errors need to be handled explicitly
5) data is updated automatically
BATINPUT/DIRECT INPUT
A: Batch-inputs can not be used to fill the "delivery due list" screen because it is not a dynpro. This is a standard SAP report. A SAP report (check with "System -> Status") may be called using SUBMIT sentence with the appropriate options . It is preferred to call a report than create a Batch-input program.
GO THROUGH THIS LINK
http://www.guidancetech.com/people/holland/sap/abap/zzsni001.htm
The LSM Workbench is an SAP R/3 based tool that supports the one-time or periodic transfer of data from non-SAP systems ("legacy systems") to SAP systems.
The LSM Workbench helps you to organize your data migration project and guides you through the process by using a clear sequence of steps.
The most common conversion rules are predefined. Reusable conversion rules assure consistent data conversion for different data objects.
LSMW vs DX Workbench
The LSM Workbench covers the following steps:
Read the legacy data from one or several files (e.g. spreadsheet tables, sequential files).
Convert the data from source format to target format.
Import the data using standard interfaces (Batch Input, Direct Input, BAPI, IDoc).
Experiences made in successful implementation projects have shown that using the LSM Workbench significantly contributes to accelerating data migration.
SAP provides this tool along with documentation to customers and partners free of charge.
Users of the LSM Workbench receive the usual support via SAP Net - R/3 Frontend (component BC-SRV-DX-LSM).
Releases:
Version 1.7.2 of the LSM Workbench ("LSMW 1.7.2") available
Attention : LSMW 1.7.2 requires an SAP R/3 system with SAP R/3 4.0 or SAP R/3 4.5.
Version 1.8.0 of the LSM Workbench (1.21mb) ("LSMW 1.8.0") available
Attention : LSMW 1.8.0 requires an SAP R/3 system with SAP R/3 4.6.
Version 3.0 of the LSM Workbench (1.89mb) ("LSMW 3.0") available for Web Application Server 6.10
Attention : LSMW 3.0 requires a SAP WAS 6.10. Functionality of version 1.7.2 and 3.0 are identical !
Version 4.0 of the LSM Workbench ("LSMW 4.0") integrated in Web Application Server 6.20
Attention : LSMW 4.0 is an integrated part of SAP WAS 6.20.
Thanks & regards
Sreenivasulu P
Message was edited by: Sreenivasulu Ponnadi

Differences between rfc and ale/idoc.

hi ..
       will u please send the differences between rfc and ale/idoc's.

Hi,
Please reward with points if helpful................
ALE is SAP proprietary technology that enables data communications between two or more SAP R/3 systems and/or R/3 and external systems. There are three layers in ALE system: application services, distribution services, and communication services.
For communication services, ALE performs a Remote Function Call (RFC) using the port definition and RFC destination specified by the customer model. RFC is used to communicate between applications of different systems in the SAP environment includes connections between SAP systems as well as between SAP systems and non-SAP systems. Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. The RFC calls a function to be executed in a remote system.
Means of creating and operating distributed applications.
The purpose of Application Line Enabling is to guarantee a distributed, but integrated, R/3 installation. This involves business-controlled message exchange with consistent data across loosely linked SAP applications.
Application integration is achieved not via a central database, but via synchronous and asynchronous communication.
Application Link Enabling comprises the following three layers:
application services
distribution services
communication services
Two Development Models
     Distribution using BAPIs
     Distribution using Message type
The programming model "Distribution using message types" contains the definitions of message types and IDoc types and the ABAP code for processing inbound and outbound IDocs.
Defining message types and IDoc types:
If you want to create message type enhancements for master data distribution, you also have to create a new message type for each enhancement.
The ALE interface does not allow you to create different segment data for different IDoc types for the same message type.
Writing ABAP code:
         Outbound Processing
           Inbound Processing
You can find information on other ALE functions under:
                               Master Data Distribution
                              Communicating with Non-R/3 Systems
1. The Remote Function Call facility allows you to call an R/3 Function module on a remote machine.
2. To communicate between two R/3 Systems and also with an External System. External Application program also can call these function module for integration.
3. RFC or sRFC - Synchronous RFC
                 aRFC - Asynchronous RFC
                  tRFC - Transactional RFC
                  qRFC - Queued RFC (I.e. Serialization of tRFC)
Types of RFC Call
Synchronous
CALL FUNCTION Func Destination Dest
CALL FUNCTION func DESTINATION 'NONE' ...
CALL FUNCTION func DESTINATION BACK' ...
Asynchronous
CALL FUNCTION func STARTING NEW TASK taskname
PERFORMING form ON END OF TASK
RECEIVE RESULTS FROM FUNCTION func
Thanks
sivaparvathi

Difference between XI 3.0 and XI 7.0

What is the Difference between XI 3.0 and XI 7.0?
( functionality & architecture wise)

Hi,
There is no new features added in PI7.0, if u have working on XI 3.0, PI7.0 Older versions the features same..
But PI7.1 there is new changes u can find below.....
Integarte SAP & Non-SAP Legacy system
PI 7.1 is based on open, web service enabled standards and
Integrate all SAP and non-SAP, A2A, B2B, BPM, service enabling and BAM
Highlight of enhancement in PI7.1
1) Enterprise Service repository (ESR) contains the design Registry
2) Includes significant high-volume message processing is supported by message processed in a single
Service call
3) Also importantly support for asynchronous messaging based Reliable Messaging (WS-RM) for both
Brokered communication between two systems will be supported in this release.
4) Provide Service Registry benefits based on UDDI 3.0
Enterprise Service Repository
In PI7.1 ES Repository is at the heart of Enterprise SOA
ES Repository is really the master data repository of service objects for Enterprise SOA
It contains the definition & process of services
In ES Repository has two parts, one is the ES Repository and the other being the Services Registry
ES Repository (ESR) is really the master data repository of service objects for Enterprise SOA
Besides service definition the ES Repository also provides you with a central point for finding and
Managing service metadata from different sources, including application deployments - this is
Where the Services Registry comes in. The Services Registry is the UDDI part of the ESR which
Enables service consumers to find services
The SAP XI Integration Repository used by process integration has become the basis of the central Enterprise Service Repository: powering Enterprise SOA and Service Enablement.
Objects in the ES Repository include:
Global Data Types (CCTS based)
Process Component Models
Executable Integration Processes (BPEL)
Integration Scenarios
Service Interfaces (Enterprise Services)
Interface Mappings
Enterprise Services built in the ES Repository
Enterprise Services includes:
Are built using a consistent enterprise model based on: GDTs, Process Components, and Business Objects.
Are based on open standards.
Are mapped to the Service Interface object in the ES Repository.
Global Data Types - Building blocks for Service Interfaces
Defined in the ES Repository
Defined company-wide based on open standards (ISO 15000-5, UN/CEFACT CCTS)
Reusable semantic building blocks for service interfaces and message types
Process Component Models
Drill down from high-level models to service interfaces and operations
Process component architecture models enable SOA governance
Process components expose on enterprise services, which are based on service operations
Web Services Reliable Messaging (WS-RM)
Asynchronous messaging (EO, EOIO) based on open WS standard
Support Business Activity Monitoring (BAM)
Embedded Event Infrastructure: Collecting, pre-filtering and publication of events across SAP and non-SAP systems.
Event handling: cast the local event to an event proxy to send out event messages to event Consumers.
Transaction SWF_BAM for event filtering via filter rules and event handling.
Enhancement for Mapping
Re-usable user defined functions.
Look-up function reads multiple fields.
Synchronous DB RFC lookups: Use graphical function to model look-ups.
Specify mapping parameters at configuration time.
Principle Propagation based on SAML
This feature uses the WS-RM protocol.
The implementation of this feature is based on the open standard SAML and can
be used with backend systems that support the SAML technology.
Forward user context from sender to receiver.
Authorization check in receiving system based on original user.
Support BAM Milestone Modeling (BPEL)
Sub-Process Calls: Integration Process Call,
User Interaction: User Decisions (initially not part of this project, but will be covered as well to draw the complete picture),
Alert Categories
Enhancements for Process Automation
Human interaction:
Integration paradigm (design/ configuration).
Generic user decision.
Language dependent texts for end-user display, enriched with variables.
WS-BPEL 2.0 adoption: Preview and implementation BPEL4People, BPEL-SPE Simple user defined functions can be configured directly in the process.
reward points if helpful...
PrasHanT

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 Synchronous & ASynchronous.

Similar Messages

Maybe you are looking for