Data Transfer Techniques

To load data into your SAP System, you can use the standard techniques BAPIs, batch input or direct input:

• BAPIs as interfaces

  Business Application Programming Interfaces (BAPIs) are standardized programming interfaces that provide external access to SAP business processes and data.

  BAPIs are defined in the Business Object Repository (BOR) as methods of SAP business objects or SAP interface types. BAPIs enable an object-oriented access to SAP application components.

  BAPIs are implemented and stored as RFC-enabled function modules in the Function Builder of the ABAP Workbench.

  For more information about BAPIs, see the BAPI User Guide.

  When using BAPIs as interfaces to the SAP System, the Workbench uses the same technology as used with permanent data transfer via ALE between SAP Systems or between SAP Systems and non-SAP systems. The data to be loaded must be in IDoc format (see Creating Example Files and Analyzing Structures). The IDoc numbers in the file must be unique.

  When the task is started, the IDocs from the specified input files are read and transferred to the BAPI.

  The following prerequisites must be satisfied:

  • If parallel loading is used, a separate process is started on one of the application servers in the server group for each input file.

    Note

    If more than one application server is assigned to the server group, you have to make sure that the files can be accessed with the specified path from each of these servers.

  • If you load the data sequentially, the input files are edited in sequence in the same process.

    If errors occur during loading (and the BAPI can therefore not process certain objects), the corresponding error message is recorded in the log of the run.

  • If you store these objects as IDocs in the SAP System, you need to transfer the Idocs to the application again after the cause of the error has been removed. You can then terminate the task manually and continue the run with the subsequent task.

  • If you write the objects with errors to files, you can continue the run after the cause of the error has been removed. The input files are then overwritten by the error files and the system reads from these new input files.

    Caution

    This means that the original input files are deleted if the run is continued, even if you did not choose the Delete input files after processing option.

• IDoc

  Loading using the program type IDoc is essentially the same as loading using BAPIs.

  The only difference is that ALE inbound processing and the Idoc type are not generated from a BAPI but instead have to be programmed by the relevant application itself.

• Batch input

  Batch input is a standard technique for transferring large volumes of data into the SAP System. The transaction flow is simulated and the data is transferred as if it were entered online. The advantage of this procedure is that all the transaction checks are performed, which guarantees data consistency.

  The batch input process is divided into two steps:

  1. The data transfer program creates a batch input session that contains all the relevant data.

  2. The batch input session is processed and the data it contains is transferred into the SAP System.

  The data transfer program creates a batch input session that contains all the relevant data.

  The majority of SAP standard data transfer programs use the batch input technique. The data transfer program creates a batch input session which is processed later. Batch input sessions can be processed in various ways:

  • In the foreground

  • In background processing

  • During processing, with error display

  You should process batch input sessions in the foreground or using the error display if you want to test the data transfer. If you want to execute the data transfer or test its performance, you should process the sessions in the background.

  For more information, see the Basis documentation on Batch Input Sessions.

• Direct Input

  With direct input, data from the data transfer file undergoes the same checks as with the online transaction and is then transferred directly into the SAP System. The database is updated directly with the transferred data.

  For more information, see the relevant program documentation.

  There are two types of direct input programs:

• Direct input programs supported by transaction BMV0.

  There are two ways to trigger direct input:

  • Start the program directly: Note that the system does not generate error logs and that it is not possible to restart the system if an error occurs. This is only appropriate for test purposes.

  • Direct input in the background (transaction BMV0): In this case, you can restart processing if the program terminates or logical errors occur (material missing, for example). The ability to restart the system ensures that data cannot be posted twice to the database, as the program can be reset to where it terminated. Using the trace you can correct any errors that occurred. Direct input also has the advantage that it places little load on the system.

    Note

    If you are working with test data, start the direct input directly. For the final data transfer, SAP strongly recommends that you use Transaction BMVO.

• Direct input programs that are not supported by transaction BMV0.

  Theses programs always provide error handling.