Import Process

When importing several transport requests simultaneously, tp processes each import step collectively for all transport requests to be imported. The required steps for each request are listed in the transport buffer file. The contents of the transport buffer file are organized as a table in which each column represents an import step. The numbers in the columns indicate either whether the import step is necessary, or the number of objects in the request that require the specific step.

When you import all transport requests listed in the figure "tp Processing Sequence", together, the first import step DDIC is processed for transport requests where it is required (DEVK900827, DEVK900840 and DEVK900865), then the ACTIV step is processed (for the same transport requests), then the MAIN I step for all transport requests, and so on.

The tp import all command, therefore, does not process all steps for one transport request before moving on to the steps for the next transport request. For example, if you detect an error in a program that has already been exported, you will need to correct the program and release the corresponding transport request for the correction. Import all requests then will import the transport requests of the whole transport buffer in the correct sequence and the faulty program will be overwritten. Because the generation step is the last step and is performed only once for all programs in the trnsport requests, the faulty program does not affect your production system. Only the correct version of the program will be generated.

There are four major steps when importing transport requests (see the figure "Steps During Import"):

1. Importing dictionary objects
2. Handling of dictionary objects
3. Importing "everything else"
4. Handling of "everything else"

These steps in the import process are, in detail:

DDIC: ABAP Dictionary import

In an import with R3trans, all ABAP Dictionary structural data is imported inactively, thus enabling you to perform this import step in an SAP system that is not yet in downtime.

• Log file: <source SID>H9<number>.<target SID>
• Transport tool: R3trans

ACTIV: ABAP Dictionary activation

Runtime descriptions (nametabs) are generated. This is the beginning of the downtime.

• Log file: <source SID>A9<number>.<target SID>
• Transport tool: Job RDDMASGL (starting report RDDMASGL)

ACTIV: ABAP Dictionary distribution

After activation and running logical checks for the new dictionary structures, the distribution program decides what actions are required to adopt the object on database level.

• Log file: DS<date>.<target SID>
• Transport tool: Job RDDIS0L (starting report RDDGENBB with variant DIST)

ACTIV: Structure conversion

If necessary, changes are made to table structures.

• Log file: N<date>.<target SID>
• Transport tool: Job RDDGEN0L (starting report RDDGENBB with variant CONV)

ACTIV: Move nametabs

The new ABAP runtime objects are put into the active runtime environment, database structures are adjusted, if necessary.

• Log file: P<date>.<target SID>
• Transport tool: Job RDDMNTAB (starting report RDDMNTAB)

MAIN I: Main import

All other objects and data are imported.

• Log file: <source SID>I9<number>.<target SID>
• Transport tool: Job R3trans

VERS: Versioning

Versions of repository objects are only created if tp parameter VERS_AT_IMP is active.

• Log file: <source SID>V9<number>.<target SID>
• Transport tool: Job RDDVERS* (starting reports RDDVERS*)

XPRA: Execution of Reports after import and of "After Import Methods"

XPRAs are programs that are started during import in the target system. The XPRA object has the same name as the program.

• Log file: <source SID>R9<number>.<target SID>
• Transport tool: Job RDDEXECL (starting report RDDEXECL)

GENERA: Generation of ABAP programs

During this step, the ABAP programs are generated.

• Log file: <source SID>G9<number>.<target SID>
• Transport tool: Job RDDDIC3L (starting report RDDDIC3L)

R3trans is a transport tool at operating system level used to transport data between SAP systems. R3trans is usually called by other programs such as tp, the transport control program.

For transports between SAP systems, to access the database, tp indirectly calls R3trans by causing UNIX to issue a fork(), Windows to issue a CreateProcess(), and AS/400 to issue a spawn(). During export, R3trans stores the object data extracted from the database in data files in the transport subdirectory data. The format of these data files, R3trans format, is independent of the platform. During import, R3trans reuses these data files.

Direct use of R3trans is not supported but may be required in exceptional cases. In case of transports, R3trans should always be used via tp.

R3trans writes data using a standard transport format. Thus you can export data with an old R3trans version and import data with a new version of R3trans. You can also transport between different databases or operating systems.

The first step of an import process is the tp call, triggered by starting an import through TMS or by a tp import command at operating system level.

During the whole import process, tp reads the transport buffer file that includes all the necessary steps for the specific request.

If you trigger a tp import all, tp has to ensure that only all transport requests are imported that are stored in the transport buffer at the beginning of the import process. This is done by executing command tp setstopmark each time a tp import all process is started. After the steps of the import process are completed, the command tp delstopmark is performed automatically, and a tp cleanbuffer deletes the transport requests from the transport buffer.

After all involved tools have finished their work, tp exits to operating system level and writes a return code to the appropriate log file for the activity. For example, tp import commands are recorded in the ULOG file.

By default, tp aborts if one import phase receives a return code larger than 8. The transport profile parameter STOPONERROR defines what return code value should cause tp to abort.

tp reads the transport buffer file that includes all the necessary steps for the specific transport request(s) and calls R3trans at operating system level.

For each import step, tp passes information from the transport buffer file to R3trans. R3trans reads the corresponding data files in the transport subdirectory data and connects directly to the database to perform inserts or updates to the included objects. After R3trans finishes performing inserts or updates, it passes an exit code (return code) to tp.

For each transport action, R3trans writes a log file in transport subdirectory tmp. After R3trans has completed its work, tp moves these log files to the transport subdirectory log.

During the import process, R3trans is executed by the import steps ABAP dictionary import (for the import of ABAP dictionary definitions) and main import (for the import of other repository objects and table contents).

In addition to the steps performed by R3trans, tp triggers the so-called import dispatcher. The import dispatcher is a background job with the name RDDIMPDP in the SAP system, which performs steps in the import process. It is a job and program in the SAP system, that controls post import activities, such as table structure activation and conversion, program generation and versioning

tp and RDDIMPDP communicate via table TRBAT. For every transport request, tp writes an entry in table TRBAT. The import function currently being performed for the request is represented by a character.

In the example below, there are three transport requests waiting for activation of DDIC objects (Function = J) in the table TRBAT.

tp inserts a header entry to request RDDIMPDP to start processing. Some activities that are independent of transport requests, such as distribution and structure conversion, only have a header entry in table TRBAT. Return code 9999 indicates that the step is waiting to be performed. For the header entry, tp inserts a B (for "begin") as return code.

To trigger the job RDDIMPDP in the SAP System, tp uses the operating system level tool sapevt.

When RDDIMPDP is started, it checks the table TRBAT to find out if there is an action to be performed for the transport requests such as mass activation, distribution, or table conversion. It sets the header entry to R (for run), and starts the appropriate RDD* program as a background task, reschedules itself, and exits.

The activated program (in this example, the mass activator for dictionary objects) sets the status of the first entry in TRBAT to active (return code 8888):

Each of the required background tasks receives a job number generated by background processing. This job number and the step ID are inserted into table TRJOB by the RDD* jobs.

The background tasks write their return codes in table TRBAT and delete the corresponding entry in table TRJOB. Return codes of 12 or less indicate that the step is finished. In TRBAT, the column TIMESTAMP contains the finishing time. When all the necessary actions are performed for all transport requests, the header entry is set to F (for "finished") by the RDD* jobs.

All the background jobs log the performed steps either in the database or in transport subdirectory tmp.

tp monitors the entries in table TRBAT and table TRJOB. When the header entry in table TRBAT is set to F and table TRJOB is empty, tp copies the logs of the completed steps from directory tmp to directory log and deletes the corresponding entries in table TRBAT.

If problems are detected by tp when monitoring the TRBAT and TRJOB tables, tp re-triggers RDDIMPDP through sapevt. RDDIMPDP then automatically recognizes if a previous step is still active or was aborted by checking the TRJOB and TRBAT tables. If a step was aborted, RDDIMPDP restarts this step.

tp uses the tables TRBAT and TRJOB to communicate with the various ABAP programs started by the background jobs. Note that there must be at least two background work processes configured in the SAP system.

When imports are performed, tp triggers the import dispatcher RDDIMPDP by sending the event SAP_TRIGGER_RDDIMPDP with the help of the tool sapevt. In client 000, user DDIC must schedule the job RDDIMPDP with event-based scheduling.

For AS ABAP based systems of SAP Business Suite, RDDIMPDP can be scheduled by running the ABAP program RDDNEWPP in client 000 with a user that has the CTS administration authorization S_CTS_ADMIN.

Due to the Job Repository and the profile parameter rdisp/job_repo_activate_time, for SAP S/4HANA Server systems, it is not necessary to run report RDDNEWPP in client 000, but it might take some time until the job is scheduled again.

The transport control program tp is used for controlling transports between SAP systems, applying SAP Support Packages, and for performing release upgrades. The tp program tracks transports by controlling exports and imports of objects between SAP systems. The program also ensures that the steps for exporting and importing objects are performed in the correct sequence and that imports into a target system are done in the same sequence as the exports from the source system.

tp is an operating system level program, which uses special programs, such as C programs, operating system commands, and ABAP programs in the SAP system.

Exports and imports are performed separately:

• In the export phase, the objects to be transported are extracted from the database of the source system and are stored in files in the transport directory. An export always takes place immediately after the transport request has been released so that the objects are freed for further changes. tp uses the program R3trans at operating system level to establish a connection to the database and to perform the necessary steps in the database.

• In the import phase, the objects are added to the database of the target system.

Although most transport activities can be performed using TMS, you may find the need to use tp commands for exceptional cases. Because the import queues are the representation of the import buffer file in the SAP system, the use of tp on operating system level and from within TMS produces consistent results.

tp commands are executed in the transport subdirectory bin by user <SID>adm. tp commands are called using syntax tp <command> [argument(s)] [option(s)].

• To display general information on the syntax of all tp calls, use tp help. To display a description of the syntax and function of a specific command, use tp <command> without any options.
• To count the number of all transport requests registered for import into a specific SAP system, use tp count <SID>.
• To test whether a connection to an SAP system's database was successful, use tp connect <SID>.
• To display how the import dispatcher RDDIMPDP is scheduled for a specific SAP system, use tp checkimpdp <SID>.
• To display all current settings of the tp parameter file for a specific SAP system, use tp showparams <SID>.

Imports performed using tp at operating system level should be restricted to exceptional cases, for example if the TMS is not available or special tp commands are needed.

There are two commands to start an import using tp at the operating system level:

• tp import all <target SID> client=<client number> pf=TP_<domain name>.PFL

  Analogous to the use of the Import All Requests button in TMS, this command imports all waiting transport requests in the correct sequence.

• tp import <transport request> <target SID> client=<client number> u0 pf=TP_<domain name>.PFL

  Analogous to the use of the Import Request button in TMS, this command imports a single transport request into the target system (and leaves it in the queue for later import).

Importing individual transport requests should only be performed in exceptional cases as the correct sequence of transport requests is not necessarily maintained and thus newer versions of objects may be overwritten by older versions through the regular import of all waiting transport requests. To ensure that the objects imported through an individual transport request are not overwritten by an older version, make sure that you use unconditional mode 0, that is, the option u0, when starting individual imports (see figure above). Using this mode is analogous to the TMS preliminary import and causes the transport request to remain in the list of transport requests to be imported. When the regular (mass) transport takes place, the transport request will automatically be imported again in the sequence of the import queue.

The contents of transport buffer files in the transport subdirectory buffer are organized as a table. Each line contains information on a specific transport request. One column includes the unconditional mode that is linked to the transport request. Other columns specify import actions.

tp offers several commands for accessing buffers:

• tp showbuffer <SID>

  This command displays transport buffer entries for system <SID>.

• tp addtobuffer <transport request> <target SID>

  This command registers the transport request <transport request> at the end of the import queue of system <target SID>.

• tp delfrombuffer <transport request> <target SID>

  This command deletes the single transport request <transport request> from the transport buffer file of system <target SID>.

• tp cleanbuffer <SID>

  This command removes successfully imported transport requests from the transport buffer file of system <SID>. This function is included in the command tp import all <target SID>. This action can be started in transaction STMS by choosing the menu paths Overview → Imports and then (after selecting a queue) Import Queue → Display and finally Extras → Delete Imported Requests.

• tp setstopmark <SID>

  This command places a stopmark at the end of the transport buffer for system <SID> so that subsequent tp import commands only process the transport requests that are located before the stopmark.

• tp mvstopmark <transport request> <SID>

  This command moves the stopmark in front of the transport request <transport request> in the transport buffer file for system <SID>.

• tp delstopmark <SID>

  This command deletes the stopmark from a transport buffer file for system <SID>.