Customer wants to schedule transports that require actions in a running R/3 System with the event-controlled background job RDDIMPDP.
This procedure can be activated optionally from Release 2.1G onwards.
Transports are imported faster with the new procedure.
A new background job RDDIMPDP is not started every 5 minutes.
When the Transport System is used to transport objects between two SAP systems, you must make sure that:
- For transports containing SAPscript or other SDO objects (for example forms) the background job RDDIMPDP is scheduled during the export in the source system and during all imports in the target system. If this is not the case, the export or import will not be performed completely.
- If you forgot to schedule the job, you can still do so during the export/import, as described below.
From Maintenance Level 2.1G there are two ways in which the background job RDDIMPDP can be scheduled.
Levels < 2.1G):
Before the export/import, log on as user DDIC in client 000 of the source/target system and execute report RDDPUTPP (Transaction SE38). This schedules background job RDDIMPDP, which is started automatically every 5 minutes.
If transports are only performed occasionally, we recommend descheduling job RDDIMPDP again after the successful transport. To do this, log on again as user DDIC in client 000 and call Transaction SM37. Select the following selection criteria:
Job name: RDDIMPDP
User name: DDIC
Only jobs with status: Released
and then "Execute".
To delete the selected job, use menu 'Job' -> 'Delete'.
If transports are performed often, then job RDDIMPDP can always be scheduled in the source and target systems.
To avoid overflows in the job table and job log files, you should delete outdated jobs regularly (around once a month).
To do this, execute report RSBTCDEL (user DDIC, client 000, Transaction SE38). Enter the following selection parameters:
Job name RDDIMPDP
User name: DDIC
Older than (days): 07
Status complete: X
" terminated: X
Delete w/forced mod: X
Background job RDDIMPDP is no longer started automatically every 5 minutes; instead, it only runs when the transport control program, tp, triggers a specific SAP event.
To schedule the event-controlled background job RDDIMPDP, log on to the source/target system as user DDIC in client 000 and execute report RDDNEWPP (using Transaction SE38).
As of Release 3.0, transport of client-dependent application-defined objects is considerably simplified. If you want to transport these objects, the background job RDDIMPDP must be scheduled in the source and target clients as well as in client 000. Log on to these clients as user DDIC and execute report RDDNEWPP (see also Note 34964).
You only schedule the job once per client; descheduling the job after completion of the transport or deleting old jobs is not required.
In Release levels 2.1 and 2.2, some configuration work is required by the system administrator at the operating system level (once only)
before the new procedure can be used. The transport control program tp and the participating computers must also fulfill some requirements.
Note the following points:
- 1. You must add the following new entries to the tp parameter file for each system (not required in Release 3.0):
under UNIX:
<>/impdp_by_event = yes
<>/sapevtpath = /usr/sap/$(system)/SYS/exe/run/sapevt
under OpenVMS:
<>/impdp_by_event = yes
<>/sapevtpath = MCR SAP_
under Windows NT:
<>/impdp_by_event = yes
<>/sapevtpath = \\
<>/system_pf =
\\
(each statement has to be one line)
The entry
Replace
Enter the TCP/IP service port for every system for which an event is to be triggered remotely. Use the port number which was also specified in the Services file in the target system.
Example: sapms
The standard name of the tp parameter file is:
under UNIX: /usr/sap/trans/bin/TPPARAM
under OpenVMS: SAP_TRANS_ROOT:[BIN]TPPARAM.PAR
under NT:
- 2. When the transport control program (tp) is called from the operating system (for example during an import), you must make sure that a 2.1G (or later) Version of tp is used.
This can be seen in the message displayed when you call up tp:
This is tp Version 126.2 ... (Release 2.1G)
(or message stating a later release).
- 3. For exports, tp should be called from an application server of the source system. For imports, it should be called from an application server of the target system.
- 4. On UNIX and WINDOWS NT platforms tp can also, in certain circumstances, be called from another computer. In this case the message
sapparam (1c): no profile used
appears on the screen several times after the tp call, but it is not an error message and may be ignored.
If tp is called from a computer that is not set up as an application server for the corresponding system, the following requirements must
be met:
- a) that the SAP executable directory of the corresponding system
/usr/sap/
is available on this computer (for example as NFS mount).
- b) that the SAP default profile of the corresponding system
/usr/sap/
is available on this computer (for example as NFS mount)
- c) that for the value of the SAP profile parameter
rdisp/msserv
(in the SAP default profile of the corresponding system) there is, on this computer, a suitable entry in the file
UNIX: /etc/services
WINDOWS NT:
with the correct port number.
- d) That no port number in the file
UNIX: /etc/services
WINDOWS NT:
is used for more than one SAP System.
event-controlled, ADO
Key word: R3SLTRA
No comments:
Post a Comment