Bookshelf Home | Contents | Index | PDF     

Siebel Connector for SAP R/3 > Customizing Integrations > Defining Your Business Interface >

Selecting the Right SAP Interface for the Job

Siebel applications currently support two types of interfaces to SAP: BAPIs/RFCs and IDOCs through ALE.

BAPIs and RFCs

SAP R/3 provides a Remote Function Call (RFC) interface for use by external applications. This interface allows an external application to call ABAP functions defined in SAP. It also allows SAP to call functions defined in the external application. The function call interface can support the interchange of:

  • Scalar parameters
  • Tables
  • Exception strings

Any ABAP function that is defined to be remotely callable is referred to as an RFC function and can be executed in SAP by an external application such as the Siebel application. Function calls can also be made from SAP to an external application such as the Siebel application. In that case an RFC interface that defines the function call must be created in SAP along with ABAP code to invoke the function in the external application from SAP. The function's implementation must then be in the external application.

The Siebel application takes full advantage of SAP's RFC interfaces that allow you to call functions within SAP as well as call workflows in the Siebel application from SAP through the RFC interface. Figure 17 shows the Siebel architecture surrounding SAP's RFC interface. The Siebel application to SAP data flow consists of a Siebel workflow using the Siebel BAPI adapter to communicate with the SAP R/3 Application Server. The SAP R/3 Application Server uses an ABAP function or other program to process the incoming information. The SAP to Siebel data flow consists of the SAP R/3 Application Server using an ABAP RFC function to send data to the Siebel tRFC BAPI Receiver, which uses a C++ RFC function. The data is then passed to a Siebel workflow to complete the processing.

Figure 17.  SAP's RFC Interface

The RFC interface is a standard part of SAP R/3. Upon the RFC foundation, SAP created the Business Application Programming Interface (BAPI). BAPIs are the methods of SAP Data Objects. While BAPIs can be viewed as part of a data object within SAP, their implementation is an ABAP function. Therefore, BAPIs, which are defined to be remotely callable, are used and invoked in the same manner as RFC functions. For this reason, the Siebel applications' interface to BAPIs and RFCs is the same.

What You Should Know About BAPIs and RFCs

When considering how best to interface to SAP keep the following information in mind.

  • The Siebel application supports BAPI/RFC calls in either synchronous or transactional mode.
    • Synchronous calls contains return parameters or table information that is returned to the caller of the function.
    • Transactional calls do not contain return parameters or table information to be returned to the caller.
    • Synchronous calls are invoked immediately.
    • Transactional calls may not be invoked immediately.
  • BAPI/RFC calls should be kept short in duration so that SAP is not overloaded.
  • A large number of BAPI/RFC calls performed at the same time can have a very detrimental impact on SAP performance. The number of calls your system can support will be determined by your hardware and network configuration and the number of dialog processes in your application servers.
  • Tables passed through a BAPI or RFC call are passed as a single block of memory, therefore passing large tables through the interface is not recommended.
  • SAP's Transactional RFC (tRFC) interface is used to make transactional BAPI/RFC calls. This assures the safe and secure transit of data from the calling application to the called application.
  • BAPI/RFC calls that are not made with tRFC can result in loss of data if a network problem occurs during the call. For example, if an external application makes a call to an RFC function in SAP R/3 and the network goes down before the return information is received by the caller, the external application has no way of knowing if the call completed in SAP or not.
  • SAP has provided many standard BAPIs. Use a standard BAPI when possible as these interfaces are supported by SAP and change minimally from version to version. The level of support for a BAPI or RFC can be determined from the administration area of SAP transaction SE37 for the specific BAPI or RFC.
  • Using SAP transaction SE37, you can create your own BAPI/RFC ABAP functions.
Finding the Right BAPI or RFC

It can be difficult to determine if SAP has a BAPI or RFC function call that is useful for your particular purpose. Here are some ways you can view information on BAPIs and RFC functions:

  • BAPIs can be browsed through the SAP transactions SWO1, SWO2, and BAPI.
  • SAP's web site provides information through the SAP Interface Repository
    http://ifr.sap.com.
  • RFCs and BAPIs can be viewed through SAP transaction SE37.
  • A test run of the BAPI or RFC with sample data can be done through the function debugger under SAP transaction SE37. In many cases, this is the only way of determining the exact functionality of an RFC or BAPI.

ALE and IDOCs

SAP supports the passage of Intermediate Documents (IDOCs) between external applications and SAP through Application Link Enabling (ALE). IDOCs are hierarchical structures that contain information for a data object in SAP. For example, IDOCs exist as containers for SAP customers, vendors, materials, purchase orders, quotes, and sales orders, to name just a few. The ALE technology used to pass IDOCs from one application to another is based on RFC. ALE consists of specific transactional RFC functions whose interfaces pass IDOC data containers. These functions are called using tRFC so that the safe transit of the data across the network can be assured.

What You Should Know About ALE and IDOCs

When considering how best to interface to SAP keep the following information in mind.

  • ALE calls are usually not real-time
    • ALE calls out of SAP can be in immediate or batch mode.
      • If a call is made out of SAP in immediate mode, an attempt is made to send this to the external application at the time the IDOC is created using a dialog process. However, if the external application is busy, the call is placed in the tRFC queue and may be handled by background processes or by user configured batch jobs. For example, calls defined to be immediate may not actually be performed immediately. This is an important design consideration.
      • If a call is made out of SAP in batch mode, a batch job needs to be scheduled to flush the IDOCs from SAP to the external application.
    • ALE calls into SAP can use immediate or batch mode.
      • If a call is made into SAP in immediate mode, SAP adds the IDOC to the IDOC queue and application level functionality is immediately invoked to process the IDOC into SAP. This processing is often slow and can affect SAP's performance.
      • If a call is made into SAP in batch mode, the IDOC is added to the IDOC queue and application level functionality needs to be triggered with the scheduling of a background job.
  • ALE works through the tRFC layer of SAP.
    • Before sending IDOCs from SAP, SAP bundles IDOCs together into a "transaction." The number of IDOCs in each transaction depends upon the packet size set in the Partner Profile.
      • Each transaction is passed to the external application as a single packet.
      • Transactions which error in transmission are kept in the tRFC layer and can be viewed with SAP transaction SM58.
      • SAP provides utilities for viewing and resending these transactions. This mechanism prevents data loss between SAP and the external application.
    • When an external application sends IDOCs into SAP, they are also sent as a transaction. If the send of this data fails, it is the external application's responsibility to resend the data as the same transaction to make sure that the data reaches SAP and is not processed twice. After SAP receives the IDOCs, they are visible in the IDOC layer.
  • Because ALE works through RFC, one transaction packet is passed within a single RFC call. For this reason keep the packet size relatively small as the tables passed through the RFC call are passed as a single block of memory. This is an inherent limitation of SAP's RFC interface. A packet size of 2-3 megabytes works well. Each data record in an IDOC is a little over 1 kilobyte. For example, if you are sending IDOCs with an average of 10 data records in each IDOC, you can send 200-300 IDOCs per packet.
  • SAP has provided many standard IDOCs. These can be extended in SAP using the IDOC Editor (WE30). Modification can be made to SAP's standard programs through user exits to populate IDOC information or modify the processing of the IDOC. You can also create your own custom IDOCs.
Finding the Right IDOC

SAP has developed many Standard IDOCs. In addition you can develop your own custom IDOCs. Here are some ways you can view information on IDOCs and ALE:

  • IDOC Type structure and documentation can be viewed through SAP transaction WE60.
  • Development of IDOCs is performed through SAP transaction WE30 and associated transactions under WEDI.
  • ALE configuration is centralized under transaction SALE.
  • ALE monitoring and processing can be found under transaction BALE.
  • SAP's web site provides information through the SAP Interface Repository
    http://ifr.sap.com.
    
Siebel Connector for SAP R/3