Performing Imports 

Prerequisites

Imports are normally not performed by the developer who requested an export, but by the system administrator.

The administrator imports all change requests from a buffer of the SAP System into the target system. To do this, the administrator must log onto the operating system of a host in the target system as the "owner" of the system ( <sapsid>adm for AS/400).

Procedure

You can start a complete import with the following command:

UNIX:

cd /usr/sap/trans/bin
tp import all <sapsid>

Windows NT:

cd \usr\sap\trans\bin
tp import all <sapsid>

AS/400:

cd ‘/usr/sap/trans/bin’
tp ‘import all <sid>’

The command processes all change requests in the <SAPSID> system buffer that have not yet been imported successfully. All necessary import steps are executed automatically.

Result

The steps in a complete import are as follows:

The command file (the list of transport objects) is imported into the SAP System. This step is only executed if the transport profile parameter VERS_AT_IMP is not set to NEVER .

In the SAP System, versions are created of the objects contained in the transport requests if there is no current version in the version database. This step is only executed if the transport profile parameter VERS_AT_IMP is not set to NEVER .

ABAP Dictionary data is imported inactively. This makes it possible to import into an active SAP System.

Nametabs are written only inactively. The SAP System can keep running until the activation step is completed. Enqueue modules are an exception.

Once the activating program has executed the logical checks for the new ABAP Dictionary structures, the distribution program decides which actions are still needed to bring the new runtime objects into the running SAP System.

If changes to a table structure require their conversion, this is done here.

In this step the new ABAP Dictionary runtime objects, which were only inactive up to now, are moved into the active runtime environment. The structures in the database are adjusted if necessary. Inconsistencies can occur in the SAP System beginning with the start of this step. These can only be corrected at the end of the main import.

All the data is imported. The SAP System should be in a consistent state again when this step has ended successfully. If so, the automatic transport to other systems takes place.

These objects cannot be activated in the same way as the rest of the ABAP Dictionary and therefore have to be activated after the main import in this separate step. They are then used directly in the running SAP System.

As of Release 4.5A, versions of the objects in the transport requests are created in this step if the transport profile parameter VERS_AT_IMP is not set to NEVER . Otherwise, version flags are set for all objects in this step.

During this step, you can work in the SAP System again.

This step is not performed for single imports ( tp import <change request> <sapsid> ). These change requests remain in the buffer until the next complete import takes place or cleanbuffer is called and they are not shown when you call showbuffer .

In SAP Systems with Releases prior to 3.0, some of the steps described cannot be executed during operation. If the target system of an import request has a Release level lower than 3.0, these steps are not executed. In this case, use the call tp put <sapsid>.

For a short description of the steps performed in target systems with Releases prior to 3.0, see Online Help for tp.

Generally, you can restart all tp import commands ( import, put, ...).

If an error occurs during the import causing tp to cancel further actions, you can correct the error and restart the same tp call again. The transport control program tp records the point at which processing should restart. When tp uses the default parameters delivered, the import is interrupted whenever a step has a return code greater than 8.