Presentation is loading. Please wait.

Presentation is loading. Please wait.

Tp & R3trans Roland Hamm SAP AG.

Similar presentations

Presentation on theme: "Tp & R3trans Roland Hamm SAP AG."— Presentation transcript:

1 tp & R3trans Roland Hamm SAP AG

2 Advanced Transport Management
Contents: Transport directory naming conventions Transport tools and communication mechanisms Import process and troubleshooting Objectives: At the end of this unit you will be able to: Outline the files in the transport directory Explain transport tools and their intercommunication Perform imports and troubleshooting with tp Clean-up the transport directory

3 Transport Directory File Name Conventions
Development System (DEV) Transport Directory actlog DEVZ DEVZ900074 sapnames SMITH data R DEV cofiles K DEV buffer QAS log ULOG 98_1 SLOG9803.DEV ALOG9803 DEVE DEV DEVP DEV DEVI QAS N QAS ….. User SMITH creates change request DEVK900073 DEVK is released and exported to QAS Quality Assurance System (QAS) As the transport control program tp runs on many different operating systems, restrictive naming conventions are required. Change requests are named <source SID>K9<5 digits>, where K9 indicates a customer request. The six digits (including the 9) are a serial number. The transport directory contains, for example, the following subdirectories: actlog with files named <source SID>Z<6 digits> recording each action on a request or task (for example, creation, release, or change of ownership). sapnames with files named after the user's logon name. A file is created for each R/3 user who performs transport actions, and updated when the user releases a request. buffer with an import buffer for each R/3 System named after the SID. When a change request is released, the import buffer of target systems is updated. data with files named R9<5 digits >.<source SID> containing the exported objects, and files beginning with D9 if application defined objects (ADOs) are transported. cofiles with command files named K9<5 digits>.<source SID> (containing, for example, import steps to be performed) log with all log files, such as ULOGs, ALOGs, SLOGs, log files named <source SID><action>9<5 digits>. <action SID> for each executed step, and log files named <action><date>. <action SID> for steps that are collectively executed, for example, step N (structure conversion) and step P (move nametabs). For a list of possible actions and related letters, see the Appendix.

4 Introducing tp Export Import Quality Assurance Development R/3
Release and export calls tp tp ABAP communication R/3 Operating system Insert table entries into control tables Insert table entries into control tables database DEV database QAS tp tp Buffer, logs, cofile, TPPARAM Buffer, logs, cofile, TPPARAM Calls Calls R3trans R3trans The transport control program tp is a tool for controlling transports between R/3 Systems and for performing R/3 Release upgrades. tp tracks transports by controlling exports and imports of objects between R/3 Systems, ensures that the steps in exporting and importing objects are performed in the correct order, and ensures that imports into a target system are done in the same order as the exports from the source systems. tp is an operating system level tool using special programs (such as C programs), operating system commands, and ABAP programs in R/3. tp performs exports and imports separately. In the export phase, the objects to be transported are extracted from the database of the source system and stored in files in the transport directory. In the import phase, the objects are added to the database of the target system. An export should always take place immediately after the change request has been released, so that the objects can be freed for further modification. There is no automatic mechanism that imports a request into a target system immediately after export. In R/3 Releases before 3.1H (without TMS functionality), imports are performed using tp commands at the operating system level. After 3.1H, using the TMS, imports are instead performed from within R/3. Although most transport activities can be performed using TMS, you may find the need to use tp commands for exceptional cases. Because import buffers and import queues are identical, using tp and using TMS produces consistent results. Transport Directory

5 Helpful tp Commands tp help Display help on tp functionality
tp go <SID> tp connect <SID> tp showinfo <request> tp count <SID> tp checkimpdp <SID> tp showparams <SID> tp status <SID> Display help on tp functionality Display help on specific tp-command Check the database destination Check the database connection Display info on a transport request Display number of registered requests Display scheduling type of import dispatcher Display current setting of parameters Display status of serialization tp commands are executed in the transport subdirectory bin by user <SID>adm, and are written 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 display a count of all requests registered for import into a specific system, use tp count <SID>. To display the environmental variables required for logging on to the correct database of a specific system with the help of the values in the global parameter file, use tp go <SID>. Note that this command does not perform a connect; tp executes this command before a connect. To test whether a connection to an R/3 System's database was successful, use tp connect <SID>. To display how the import dispatcher RDDIMPDP is scheduled for a specific R/3 system, use tp checkimpdp <SID>. To display all current settings of the parameter file, use tp showparams <SID>. To display status information on the serialization of a specific system, use tp status <SID>.

6 tp import all QAS client=200
tp Import Commands DEV QAS database database Release and Export Import Transport Directory tp import all QAS client=200 DEVK900004 DEVK900008 DEVK900016 DEVK900013 Imports performed using tp at the operating system level should be restricted to exceptional cases, such as imports to multiple clients. There are two commands for importing to a target system using tp at the operating system level: tp import all <target SID> client=<client_number>. Analogous to the default import of TMS, this command imports all waiting change requests in the correct sequence (their export sequence). tp import <change request> <target SID> client=<client_number> u0. Analogous to the TMS preliminary import, this command enables you to give individual change requests priority. Importing individual requests is not recommended as the correct order of requests is not necessarily maintained, and thus newer versions of objects may be overwritten by older versions through the regular import of all waiting requests. To ensure that the objects imported through an individual transport are not overwritten by an older version, only use unconditional mode 0 (option u0) when starting individual imports. Using this mode is analogous to the TMS preliminary import and causes the change request to remain in the list of requests to be imported. When the regular transport takes place, the request will automatically be imported again in the export sequence. Individual imports only should be performed in exceptional cases. Processing imports out of order can result in severe inconsistencies in the target system. These are hard to diagnose. If you wanted to import single requests not as preliminary import (NOT recommended), you would use tp import <change request> <target SID> client=<client_number> (without the option u0). tp import DEVK QAS client=200 u0

7 tp Commands for Accessing Buffers
tp showbuffer <SID> tp addtobuffer <request> <SID> [u<digit(s)>] tp delfrombuffer <request> <SID> tp cleanbuffer <SID> tp setstopmark <SID> tp delstopmark <SID> Buffer for QAS TASK UMODE DEVK DEVK900057 DEVK900053 STOPMARK Is a special entry (not a change request) DEVK The contents of import buffer files in the transport subdirectory BUFFER are organized as a table. Each line contains information on a specific transport request that is specified in column TASK. 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> displays buffer entries. tp addtobuffer <change request> <target SID> registers the request as the last request to be imported. If the request has already been added for import, it is placed at the end of the queue. tp delfrombuffer <change request> <target SID> deletes a single request from the buffer. tp cleanbuffer <SID> removes successfully imported change requests from the buffer. This functionality is included in the command tp import all <target SID>. tp setstopmark <SID> places a stopmark at the end of a buffer so that subsequent tp import commands only process the requests that are located before the stopmark. tp delstopmark <SID> deletes the stopmark from a buffer.

8 Introducing R3trans Export Import Quality Assurance Development R/3
Operating system database QAS database DEV tp tp exit code exit code write data files, logs read data files, write logs connect, update, delete and insert connect, read R3trans R3trans Transport Directory R3trans is a transport tool at the operating system level used to transport data between R/3 Systems. R3trans is also used when installing new R/3 Systems, performing R/3 Release updates, and for logical backups. R3trans is usually called by other programs such as tp and the upgrade control program R3up. For transports between R/3 Systems, to access the database, tp indirectly calls R3trans – by causing Unix to issue a forc(), Windows NT 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 through tp. Import steps differ for the different object types. Further activities may be required in addition to R3trans activities. tp ensures that all export and import steps, including R3trans activities, are completed successfully. Upward compatibility: R3trans writes data using a standard R/3 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. Note that although exports and imports are independent of the R3trans version, the database platform, or the operating system, SAP does not support using tp or R3rans for transports between different R/3 Releases.

9 ABAP Programs used in Performing Transports
Export Import RDDMASGL Quality Assurance RDDGENBB RDDVERSL ... RDD*- Jobs RDDIMPDP Development starts schedules write logs RDDNEWPP R/3 triggers Operating system TRBAT TRJOB tp Transport steps implemented using ABAP programs include activating the ABAP Dictionary, converting structures, and generating reports and screens. To execute these steps, tp use the tables TRBAT and TRJOB to communicate with the various ABAP programs. As these ABAP programs are run as background processes, there must be at least two background work processes running in R/3. 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 and each client that is to receive imports, user DDIC must schedule the job RDDIMDP with event-based scheduling. RDDIMPDP can be scheduled by running the ABAP program RDDNEWPP. Normally, RDDIMPDP is automatically scheduled after a client copy. To verify if the required import dispatchers are scheduled, check the job overview using Transaction SM37. The correct name of the import dispatcher for each client is RDDIMPDP_CLIENT_<nnn> where nnn represents the client's name. The corresponding event is SAP_TRIGGER_RDDIMPDP_CLIENT. tp and the background jobs needed for transports communicate using table TRBAT, which contains temporary data. tp inserts information into TRBAT specifying the steps to be performed for a specific request. tp then triggers RDDIMPDP to read TRBAT and execute the required programs as background jobs whose names start with RDD. For example, RDDMASGL is for mass activation, RDDGENDB for conversion, and RDDVERSL for versioning. Each RDD* job receives a job number that is recorded in table TRJOB. The jobs report their current status back to TRJOB. Transport Directory database QAS

10 tp Processing Sequence
! tp collectively processes each import step for all requests before proceeding with the next import step. tp does NOT process all import steps for only a single request before proceeding to the the next request. 1st 2nd 3rd 4th 5th 6th 7th 8th 9th TASK DDIC | ACTIV | MAIN I | MC ACT | ADO I | LOG I | VERS F | XPRA | GENERA | UMODE DEVK | | | | | | | | | DEVK | | | | | | | | | DEVK | | | | | | | | | DEVK | | | | | | | | | DEVK | | | | | | | | | DEVK | | | | | | | | | DEVK | | | | | | | | | DEVK | | | | | | | | | tp processes each import step collectively for all requests in the import queue. The required steps for each request are listed in the import buffer file. The contents of the buffer file is organized as a table. Each column represents an import step. The numbers in the columns indicate either if the import step is necessary, or the number of objects in the request that require the step. In the example above, first the import step DDIC is processed for requests where it is required (DEVK and DEVK900092); then the ACTIV step (for DEVK and DEVK900092); then the MAIN I step (for all requests); and so on. The 'tp import all' command does NOT process all steps for one request before moving on to the steps for the next request. For example, if you detect an error in an object that has already been released, you correct the object and release it again. 'Import all' then imports the whole buffer in the correct sequence and the faulty object is overwritten. Because the generation step is the last step and is performed only once for all objects in the requests, the faulty object does not affect your production system. Only the correct version of the report is activated and generated.

11 (*) = generic steps not dependent on requests
Steps during Import ABAP Dictionary import ABAP Dictionary activation Distribution Structure conversion(*) Move nametabs(*) Main import Activation of the enqueue definitions Enqueue conversion (*) Import of application defined objects (ADOs) Logical import Versioning Execution of user defined activities (XPRAs) Generation of ABAP programs and screens DDIC I ACTIV Import process MAIN I MC ACT MC CONV ADO I LOG I VERS F XPRA GENERA ABAP Dictionary import with R3trans: All ABAP dictionary structural data is imported inactively, thus enabling you to import into an active R/3 System. Activation of ABAP dictionary and distribution: Runtime descriptions (nametabs) are written inactively. After activation and running logical checks for the new dictionary structures, the distribution program decides what actions are required to bring the new objects into the running system. Structure conversion: If necessary, changes are made to table structures. Move nametabs: After the new ABAP runtime objects are put into the active runtime environment, database structures are adjusted if necessary. From the beginning of this step until the end of the main import, inconsistencies may occur in the R/3 System that are removed at the end of the main import. Main import with R3trans: All data is imported and the R/3 System returns to a consistent state. Activation and conversion of enqueue objects: Objects that were not previously activated are activated in this separate step after the main import. They are used immediately in the running system. Import of application defined objects (ADOs): These objects include forms, styles, and printer definitions. Logical imports: This phase is currently not active and is ignored during the import process. The intentions of this phase will be to import data to a shadow client prior to performing required Customizing transactions in the target client. Versioning: Versions of Repository objects are only created on the R/3 System from which the objects was exported. However, the import process does modify the object’s Version counter which is incremented for all Repository objects during import. Execution of user-defined activities (XPRAs): XPRAs are objects that can be used to start reports in the target system. The XPRA object has the same name as the report. Generation of ABAP programs and screens: During this step, you can resume normal business activities in the system. (*) = generic steps not dependent on requests

12 Appendix: Log Files for Importing DEVK900021
DEVH QAS Dictionary import Dictionary activation Distribution(*) Structure conversion(*) Move nametabs(*) Main import Activation of the enqueue definitions Enqueue conversion(*) Import of application defined objects (ADOs) Logical import Versioning Execution of user defined activities (Xpra) Generation of ABAP programs and screens DDIC I DEVA QAS DS QAS ACTIV N QAS P QAS MAIN I DEVI QAS DEVMS QAS MC ACT N QAS MC CONV DEVD QAS ADO I DEVU QAS LOG I DEVV QAS VERS F DEVR QAS XPRA DEVG QAS GENERA

13 Import Process: tp and the Import Buffer
dispatcher RDDIMPDP ABAP DDIC activation Conversion Generation ... Database TRBAT TRJOB database ../tmp - Log file(s) OS Level tp R3trans Buffer 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. To ensure that all transport requests stored in the buffer begin the import process automatically, each time a ‘tp import’ call is made, a ‘tp setstopmark’ is executed. 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 import buffer. After all involved tools have finished their work, tp exits to the operating system level and writes a return code to the appropriate log file for the activity. For example, ‘tp import’ and ‘tp setstopmark’ commands are recorded in the ULOG file. Note: The command 'tp import' is reentrant. If an error occurs during import, after you eliminate the error condition and restart tp, tp finds the correct point to restart. By default, tp aborts if one import phase receives a return code larger than 8. The TPPARAM parameter stoponerror defines what return code value should cause tp to abort. ../log - Log file(s)

14 Import Process: R3trans
dispatcher ABAP RDDIMPDP DDIC activation Conversion Generation ... TRBAT TRJOB Database database DD import Main import ../tmp - Log file(s) OS Level tp R3trans Buffer During the import process, tp reads the command file that includes all the necessary steps for the specific request and calls R3trans at the operating system level through a forc() for Unix systems, a CreateProcess() for Windows NT, or a spawn() for AS/400 environments. For each import step, tp passes a control file to the transport subdirectory tmp for use by 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 to tp. For each transport action, R3trans writes a log file in transport subdirectory tmp. After R3trans completes its work, tp moves this log file to the transport subdirectory log. During the import process, R3trans is called by the import steps ABAP dictionary import (for the import of ABAP dictionary definitions), and main import (for the import of table contents). ../log - Log file(s)

15 Import Process: tp / ABAP Communication (1)
dispatcher ABAP RDDIMPDP DDIC activation Conversion Generation ... Database TRBAT TRJOB database Inserts entries Triggers ../tmp - Log file(s) Reads OS Level tp R3trans 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. For a list of TRBAT function codes, see the Appendix. In the example below, there are 3 change requests waiting for DDIC activation in the table TRBAT. tp inserts a header entry to tell RDDIMPDP to start processing. Some activities that are independent of transport requests, such as distribution and structure conversion, only have a header entry in 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. Request Function Return Code Timestamp T11K J T11K J T11K J HEADER J B To trigger the transport daemon RDDIMPDP in R/3, tp uses the operating system level tool sapevt. Buffer ../log - Log file(s)

16 Import Process: tp / ABAP Communication (2)
dispatcher starts RDD*-jobs ABAP RDDIMPDP DDIC activation Conversion Generation ... Checks and writes table Writes status Inserts job number Database TRBAT TRJOB database ../tmp - Log file(s) OS Level tp R3trans When RDDIMPDP is started, it checks the table TRBAT to find out if there is an action to be performed 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) sets the status of the first entry in TRBAT to active (return code 8888): Request Function Return Code Timestamp T11K J T11K J T11K J HEADER J R Each of the required background tasks receives a job number generated by R/3 background processing. This job number and the step ID are inserted into table TRJOB by the RDD* jobs. Buffer ../log - Log file(s)

17 Import Process: tp / ABAP Communication (3)
dispatcher restarts RDD*-jobs RDDIMPDP ABAP DDIC activation Conversion Generation ... Writes status Checks tables Deletes entries Database TRBAT TRJOB Writes logs database Deletes entries Restarts Monitors tables ../tmp - Log file(s) OS Level Buffer tp The background tasks write their return codes in TRBAT and delete the corresponding entry in TRJOB. Return codes of 12 or less indicate that the step is finished. In TRBAT, the column TIMESTMP 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 Request Function Return Code Timestamp T11K J T11K J T11K J HEADER J F All the background jobs log the steps they perform either in the database or in transport subdirectory TMP. tp monitors the entries in TRBAT and TRJOB. When the header entry in TRBAT is set to F and TRJOB is empty, tp copies the logs of the completed steps from directory tmp to log and deletes the corresponding TRBAT entries. If problems are detected by tp when monitoring TRBAT and TRJOB, tp re-triggers RDDIMPDP through sapevt. RDDIMPDP automatically recognizes if a previous step is still active or was aborted by checking TRJOB and TRBAT. If a step was aborted, RDDIMPDP restarts this step. Two background work processes must be available. R3trans ../log - Log file(s) Moves logs

18 Monitoring and Analysis: tp Log Files
Transport subdirectory log ULOG SLOG ALOG For long-running imports, it may be helpful to monitor the log files written at the operating system level. All logs in the transport environment are stored in the transport subdirectory log. These logs include logs created by tp (ULOG, SLOG and ALOG), and logs created by the various transport tools. The current ULOG file records all tp commands that are free of syntax errors, and is named using the name convention ULOG<YY>_<one digit>. Each line in the ULOG file represents a tp command. The SLOG file is used to monitor the transport activities of a specific R/3 System. It contains a general overview of performed imports indicating the return code and thus the success of each import. The name of the SLOG file can be set in the parameter file TPPARAM using the global parameter syslog. The default setting is SLOG<YY><WW>.<SID>. The ALOG file records the return code for all transport steps handled in the common transport directory. The name of the ALOG file can be set in the parameter file TPPARAM using the global parameter alllog. The default value is ALOG<YY><WW>.

19 Monitoring and Analysis: Transport Tool Log Files
Directory tmp Directory log R3trans DEVI QAS DEVI QAS tp DEVV QAS DEVI QAS RDD* ... ... Import process The various transport tools write a log for each transport action to the transport subdirectory tmp. After completion of the step, tp moves these logs from tmp to log. The log files are named <source SID><action><6 digits>.<target SID>, where the 6 digits are taken from the corresponding change request, and the performed action is represented by a single character (see also Appendix). Each log file contains a table with seven columns showing: The level for the transport protocol display in R/3. The possible levels are: Performed actions and return code Additional error messages End-user logs Details for developers and hotline Whether the text is information, a warning, an error, or a program abort. The language ID of the following text. The message type, that is, the work area relating to the information. The message ID in the related work area. The message text. Up to 1000 message texts for each work area are defined in the R/3 repository.

20 Transport tool return codes
tp Return Codes tp return codes (rc) Transport tool return codes 0 < rc < rc = max (tool-rc) 16 < rc < 100 Combination of tool-rc and tp warning 100 < rc < 200 tp warning 200 > rc tp error 0 Successful transport 4 Warning 8 Error 12 Fatal error File system Database tp receives return codes from all the transport tools involved in an import process. tp's own return code following exit is interpreted as follows: 0 to 16 indicates the maximum values of all return codes from transport tools. 17 to 99 is a value that has been calculated from the return codes of the transport tools and a tp warning, for example, that the buffer of the target system has no write permission. 100 to 199 indicates warnings. Warnings mean that something went wrong and tp could not perform all tasks. 100 to 149 are "normal" tp warnings, for example, that RDDIMPDP cannot be triggered by sapevt. Return codes of 150 to 199 are rare and indicate incorrect operation by a user. For example, a return code of 152 is received if tp tries to import a request that is not included in the buffer. 200 or more indicates tp errors. For example, if a file could not be accessed as required by the import process, the return code is 212. More significant than the value of a return code is the accompanying text. To display the text of a specific tp return code, use the tp command tp explainrc <value of return code>.

21 Troubleshooting (1) Alert Monitor System Log (SLOG) Action Log (ALOG)
View tp connection errors Locate permission problems See RFC failures View all tp return codes Locate what change request or generic phase produced a warning or error Review individual log files at the operating system level. The first step in troubleshooting transport errors is to eliminate the obvious setup issues using the alert monitor, which records all TMS transport actions. To use the alert monitor, use Transaction STMS and choose Monitor ® Alert monitor. The following information is displayed for each TMS function: the date and time, the user name, the TMS status message, and the target R/3 System. To display the full text of an error message, double-click on the error message. R/3 logs are shown in a tree structure with three-levels: The top level shows the SLOG file, used to monitor the transport activities of an R/3 System and determine the success of import requests. If import failures are recorded in the SLOG file, drill down to the ALOG file and locate what particular import step produced the return code listed in SLOG. From ALOG, to locate the log file for the specific request that produced the error and evaluate the cause of the problem, use either the import monitor or the relevant Change Organizer (the Workbench, Transport, or Customizing Organizer). All log files that are not dependent on a specific requests (such as the log files for structure conversion and nametab moving) cannot be displayed in R/3. An import may abort and yet the log files displayed in TMS reveal no errors. This means the error was produced by one of the request-independent steps. To locate the step that recorded a failure, check the transport directory on the operating system level.

22 Transport Directory Troubleshooting (2) log actlog sapnames buffer
SM37 check protocols of RDD* jobs SM31 - check tables TRJOB Job overview V V : Job started : Step 001 started : Fatal Error : Job aborted C11K N C11K N TRBAT R/3 Operating System Transport Directory tp R3trans log sapevt actlog sapnames In R/3, check if the transport daemon RDDIMPDP is scheduled correctly and event-triggered. To check on the success of all related background processes (RDD*-jobs), go to the job overview (Transaction SM37). Monitor the job protocols. The import buffer in subdirectory buffer provides information about the progress and success of imports. Problems may result from wrong versions of tp or R3trans; tp not running (UNIX: ‘ps -ef | grep tp’); permission or share problems with the common transport directory; or not enough free disk space. When analyzing a problem, compare the logs and buffer entries with the entries in tables TRBAT and TRJOB (Transaction SM31). If required, insert the transport request or header in TRBAT (use the codes in the Appendix) and restart RDDIMPDP. If a communication problem between tp and R/3 is indicated, try calling sapevt on operation system level and see if it triggers RDDIMPDP. File system buffer

23 Appendix: tp Steps Mnemonic Step Program Environment
E main export R3trans OS P test import R3trans OS H DD objects: import R3trans OS A DD objects: activation RDDMASGL R/3 S DD objects: distribution RDDGENBB R/3 N DD objects: conversion RDDGENBB R/3 6 DD objects: move nametabs pgmvntabs OS I main import R3trans OS T import of table entries R3trans OS M enqueue activation RDDGENBB R/3 G repository objects: generation RDDIC03L R/3 V version update RDDIC R/3

24 Appendix: Complete List of tp Action Types

25 Appendix: TRBAT Function Codes
Header JOBNAME Report Explanation ===================================================================== X RDDDIC0L RDDDIC0L ADO export J RDDMASGL RDDMASGL Mass activator (new) B RDDTACOL RDDTACOL TACOB activator S RDDDIS0L RDDGENBB Distributor N RDDGEN0L RDDGENBB Import converter M RDDMASGL RDDMASGL Mass activator (Enqueue) Y(n) RDDGEN0L RDDGENBB Matchcode converter O RDDGEN0L RDDGENBB Batch converter (not in Upgrade) D RDDDIC1L RDDDIC1L ADO import V RDDVERSL RDDVERSL Create version R RDDEXECL RDDEXECL XPRA execution G RDDDIC3L RDDDIC3L Generation Function codes The function codes in TRBAT describe the actions being performed on a change request during import: B: Activating all dictionary objects in table TACOB with mass activation. D: Importing application defined objects (ADO). G: Generating reports and screens. J: Activating all dictionary objects – other than enqueue objects – with mass activation. M: Activating enqueue objects in the change request with mass activation. N: Converting all structure changes generated by the import and recorded in table TBATG, other than the structure changes to matchcode objects. O: Converting all structure changes recorded in the table TBATG and generated by actions in the online system and not by the import. R: Executing reports after put (XPRA). S: Distributing actions – required to transfer the new dictionary structures into the runtime environment – to different steps. X: Exporting application-defined objects. Y: Converting structure changes to matchcode objects which were generated by the import and are recorded in table TBATG. Note that actions B (TACOB activation), N, O, Y (structure conversion), and S (distribution program) only have header entries and no entries in field FUNCTION as they are change request independent.

26 tp & R3trans Questions & Answers Roland Hamm SAP AG

27 Copyright 2000 SAP AG (All rights reserved)
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft®, WINDOWS®, NT®, EXCEL®, Word® and SQL-Server® are registered trademarks of Microsoft Corporation. IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation. OSF/Motif® is a registered trademark of Open Software Foundation. ORACLE® is a registered trademark of ORACLE Corporation, California, USA. INFORMIX®-OnLine for SAP is a registered trademark of Informix Software Incorporated. UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of The Open Group. ADABAS® is a registered trademark of Software AG. SAP, SAP-Logo,, R/2, R/3, RIVA, ABAP, SAP-EDI, SAP Business Workflow, SAP EarlyWatch, SAP ArchiveLink, ALE/WEB, BAPI, SAPPHIRE, Management Cockpit, SEM, are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.

Download ppt "Tp & R3trans Roland Hamm SAP AG."

Similar presentations

Ads by Google