Performing an External Data Transfer (SAP Library

Performing an External Data Transfer

Purpose

You use this component to transfer data from an old/legacy system into the R/3 system, and process it in the R/3 system.

Prerequisites

Before you begin with an external data transfer, you must have selected the necessary data in your source system. You also need to make the relevant system settings in Customizing.

Process Flow

Transferring data from the source system into the R/3 data pool involves the following steps:

Preparation of Source Data

Using a data selection program, you first create a sequential input file (for example, an Excel file which you must save in CSV format, or a UNIX text file). The data record structure in this file reflects that of the sender structure you defined in Customizing. You can do this in the following ways:

Define the sender structure based on the data setup in your source system. The sender structure data is then converted to fit in the receiver structure data using transfer rules defined by you.
You define the sender structure identically to the receiver structure in the R/3 system. The sender structure data is then converted to fit in the receiver structure data using transfer rules defined by SAP. In this case, the data selection program has to import the data corresponding to the sender structure.

The file has to be available on the presentation or application server. You should have assigned a logical file name to the physical one in Customizing (the physical file name being the path(s) where the file(s) are found). See under Assign File Name Independent of Platform in the implementation guide (IMG) of the relevant component. This prevents difficulties resulting from having to make changes dependent on your operating system.

The data requirements in the R/3 system are dependent on the transfer categories and other Customizing settings (See under Transfer categories in the implementation guide (IMG) of the relevant component, or under Display Optional/Required Fields in the Treasury component and in the Industry Business Solution for banking, SAP Banking). Make sure that you don’t have two data records (or logical units for header and item structures) for the same information (transaction, for example) in a single input file. If, for example, you create a new loan and change it shortly thereafter, you can not put both of the resulting data records in the same sequential file. If the same data records are processed in the same block (see below), it could lead to runtime errors or to error entries in the error log.

External Data Transfer

First, a check is made of the parameters which were assigned at the start of the external data transfer. This checks the name of the transfer program (corresponds to the sender structure) and the date specifications. After this, the input file is split into "blocks", which are processed one after another. This ensures that before anything else happens, all blocks have been through the conversion stage. When this has been completed successfully (i.e. without terminations or conversion errors), all blocks then go through the function stage.

Conversion Stage

Every run begins with importing the prepared data to an internal table. After that, you can trigger a customer exit for sender structures (see under Additions to External Data Transfer in the IMG of the relevant component). Subsequently, the sender records are converted to receiver records in accordance with the transfer rules and other conversion settings made in Customizing (such as currency translation). In some components you can trigger a customer exit for receiver records at this point.

If an error appears during conversion, the transfer is terminated. When this happens, no records are written to the database. The error is noted in the conversion log.

If conversion takes place without any errors, an internal table is generated which holds all of the receiver records. This table is used in the external data transfer to complete the function stage.

This graphic is explained in the accompanying text

Function Stage

In the function stage, the receiver records are also read in blocks, and processed one after another.

In the processing stage, the delivered converted sets are checked to make sure they are complete, and that they are logically filled with the correct values. Erroneous data records are separated out, and you can postprocess them later. The data record of a transfer category, consisting of both header and position structures, is completely rejected if for some reason even a small part contains errors.

Correct data records are completed in an additional step. When this happens, certain unfilled fields (such as the date and time of transfer) are filled in for some transfer categories. Afterwards, the records are written to the data pool and the error handling routine is triggered.

Data records containing errors are written to an output file. You assign this file a name at the start of the external data transfer. The program uses this name and adds additional data (such as the date and time) to the name. This makes later identification of the output file easier. in addition, the records containing errors are noted in the error log.

This marks the end of this run. If the program terminates during the function stage, you can restart it. You can find further information under Evaluation of Logs: Restart.

It is theoretically possible to repeat the entire external data transfer. Data records already successfully imported are recognized by the system and ignored.

Logs and Error Processing

A log is generated for every transfer, whether there were errors or not. This is the starting point for rectifying errors. There are several ways to do this. You can find further information under Evaluation of Logs.

The following diagram describes the entire course of an external data transfer from a technical view:

This graphic is explained in the accompanying text

Result

The data from your old/legacy systems is in the R/3 data pool and can be processed there.

Special Features of the Release Upgrade in some Components

It is possible that a modified receiver structure will be delivered with a new release. If a new field were added, then it would not be filled without you making the appropriate adjustment. It is possible that you will need to adjust the sender structure and the sequential input files or the transfer rules to accommodate the new field(s) (see under Transfer Categories in the IMG of the relevant component, or under Display Optional/Required Fields in Customizing in the Treasury component and in the Industry Business Solution for banking).

If a field were removed in a new release, then an existing rule would point to a target field which no longer exists. The transfer could then result in termination. We therefore recommend that you make a test run and check the transfer rules before performing any real transfers after a release change. If you have created complex rules for a transfer program, we recommend you print them out before a release change.