FAQs on OCS (Recommendations for error scenarios)

1. What general rules should I take into account before importing Support Packages?

Since the standard transport function is also used when you import Support Packages, you should first refer to the recommendations that apply to this function (system time of minimal work load, tp and R3trans current, ... from LC 556734). In addition, the current version of the SPAM should also be installed. When importing Support Packages, refer to the corresponding note provided for every release for details on known problems (for example, 97629, 97630 and 173814).


2. During the import, an error was reported which I have now eliminated - how do I proceed?

If the import terminated with an error reported via the SPAM transaction, you can nearly always repeat the phase once you have eliminated the error. To do this, you simply have call the SPAM transaction again and select the import button on the screen. Since the last successfully completed step of import is stored in status tables, the SPAM can be started again with the incorrect phase. As of Version 0031 of SPAM, this also applies to a termination in the main import.
However, if import terminates due to a power failure during the import process, the incomplete import can cause inconsistencies in various programs and transactions. In these cases, it is often impossible to start the SPAM transaction for Basis Support Packages. Send a message to the SAP support team to have the error analyzed.

3. The import terminates in the TESTIMPORT step with an error RC=8. (I)

First, please check the further information which are reported for this error in the log file of the Support Package. Should here a row as "R3TRXXXXYYYY was repaired in this system, is not overwritten" stand, at least a request in which a part of this full cost-object YYYY is edited and that is not released exists. Please you search from that how in note 42379 described the corresponding request. After the release you can repeat the importing of the Support Packages simply.


4. The import terminates in the TESTIMPORT step with an error RC=8. (II)

First check the additional information reported for this error that is contained in the Support Package log file. If this contains a line such as "Function XXXX (YYYY ZZ) does not fit in the existing function group ((AAAA BB)) ", an incorrect Support Package queue may have been created. You should therefore check whether the selected Support Package queue is correct for your release as described in the above note listed under point 1. Changing the queue in the step TEST_IMPORT is straighforward. To do this, use transaction SPAM to go to EXTRAS -> RESET STATUS-> QUEUE to define the correct queue. Once the queue is correctly defined, refer to the information in note 199619.


5. The import terminates in the ADDONCONFLICT step with an error.

This termination only occurs if the objects of the Support Package queue that you want to import are checked on already installed add-ons and the required add-on CRTs are not included in this queue. You should therefore reset the queue with transaction SPAM with EXTRAS -> RESET STATUS-> QUEUE and also incorporate the required CRT for the add-on reported in the error text. The error should no longer occur when you rerun the import.


6. The import terminates during/after the DDIC_IMPORT step - can I reset the queue again from here?

Resetting the queue is no longer possible as of step DDIC_IMPORT because objects have already been imported into the system at that stage. For this reason, the relevant field for resetting is grayed out in the SPAM transaction. Resetting the queue only resets the status of the last successful import step for the SPAM the objects already imported in the system are not rolled back!


7. Can I also import the Support Packages directly with the tp?

This procedure is not generally recommended. This is because the attributes of the Support Packages are not used during the direct import and the Support Packages may be imported in the wrong sequence as a result. All additional steps contained in the SPAM that are required for the modification adjustment, for example, are not executed.


8. After receiving an import error message and eliminating the error, I want to continue importing the queue but get a tp error message with "RC=152"?

This tp return code means that the tp did not find any work. This is because, for example, the import queue was changed by a cyclic tp import call via cron-jobs so that the import cannnot be continued using SPAM. In this case, you should send a message to the SAP support team to check and continue the import process. You should also refer to note 326405 to identify and eliminate the error.


9. After importing the Support Packages, I see the hourglass displayed for a large number of objects what can I do?

These objects are recreated in the corresponding system after you import objects via a normal transport as with as a Support Package. This occurs automatically with every first call and is therefore not an error. If you wish to automatically create Support Packages objects, you can select the following option in the SPAM transaction under EXTRAS -> SETTINGS -> ABAP/SCREEN GENERATION ALWAYS. However, this may increase the length of time required for the import and as part of importing the Support Package, this may stop if an error occurs during the import. However, you can deactivate the generation when continuing the import by setting the following option after a generation error: EXTRAS -> IGNORE GENERATION ERRORS.

FAQs on Transport Management System (TMS)

TMS

1. The status in the TMS is "Import runs" although it is already finished or canceled.

In transaction STMS -> OVERVIEW -> IMPORTS you reach, by double-clicking, the import queue of the corresponding system. From there, via Goto -> Import Monitor, you reach the display of the status of both individual imports and Import all or Import subset. If the tp has already been started, you also see the tp process ID here and you can check at operating system level whether the process still exists (for example ps -ef | grep tp or via the Windows Task Manager). If the tp process still exists, execute the checks for hanging transports from note 556941. Additional notes are 486991 and 505771.


2. Why can I not see all requests in the import history?

See notes 316841 and 375230. In addition, requests whose name is longer than 10 characters can be viewed via transaction SPAM or SAINT.


3. The "large" truck is missing in the TMS symbols

The system is probably set to single import strategy. This can be set up from R/3 Release 4.6C via the transaction STMS -> TRANSPORT ROUTES -> Double-click on the corresponding system -> Tab title System Attributes, area 'Transport strategy' or according to note 194000 for smaller releases.


4. Both the truck and the menu option for the import are completely missing.

Here you must check whether in transaction STMS -> import overview -> double-click on the corresponding system there is an import client field with the requests or whether CTC=1 is set in the transport profile. If there is then also only one request in the import buffer, where there is explicitly no import client, the import does not work. Then add the corresponding import client in the TMS.

Error Scenarios

1. I have error messages about logs not found during the transport.

This is usually caused by incorrect maintenance of the setting for the transport directory. Check in particular the parameters DIR_TRANS and TRANSDIR by referring to the advice given in note 556734, section "What do I need to consider when setting up the transport?".


2. The system reports a DB connect problem! What can I do?

For the test and as a basis for a further analysis, the command "R3trans -d " or "R3trans -x " can be used as user adm. A file trans.log is then also written in addition to the message via the return code of the attempt in the current directory. In the case of a connection problem, this contains details on the error message. R3trans mainly checks environment and database configuration files. If no error is found here, the parameters can also be checked from the transport profile with the call "tp connect pf=DIR_TRANS/bin/" (use backslashes with NT). The connection test can also be carried out from the TMS (OVERVIEW -> SYSTEMS and there R/3SYSTEM -> CHECK -> CONNECTION TEST or TRANSPORT TOOL). There are also additional notes on the respective database systems:
DB2: 152929, 83255, 136806
DB4: 515447, 67213, 69429
DB6: 80292, 53141, 167361
Informix: 85404, 112184
Microsoft SQL Server: 351586, 128126, 116735
Oracle: 193616, 400241, 403004, 134447, 443867, 445029, 437362, 505630
SAP DB: 39439
These notes do not apply to everything! They mostly only apply to certain R/3 or database releases. Only use the relevant notes that apply in each case!


3. When I create transport requests, they are always local!
Check in the TMS at the domain controller whether the transport routes are there. Usually the development system is the source system (the objects are created/changed there). From there, there are consolidation routes into one or several systems that can also be virtual. The consolidation route with transport layer SAP is intended for repairs to SAP objects. With customer transport layers for customer objects, the object must have a development class which is assigned to this transport layer. The corresponding development class can be displayed via transaction SE80.


4. The tp does not write requests to buffers of the subsequent system.

Check whether the transport routes are generally set up and fully activated and distributed. If it only concerns certain transports, check whether these are Workbench or Customizing requests or special transports (transport of copies/relocation). In particular with system copies and restores with incomplete recovery, you must be aware that afterwards the status of the buffer and the database may no longer agree. (For example, you import request C11K901234 into the consolidation system Q11 and then it is displayed in the Q11 buffer that the request is already imported in Q11. The request is not imported into the P11 system. Now you make a system copy from P11 to Q11. Now the request C11K901234 is not contained in Q11 (in SAP), however according to buffer Q11 it is imported).


5. An import seems to hang.

Check in the directory DIR_TRANS subdirectory tmp whether the import process regularly updates a log file for a certain import phase. The last entries in this log file provide information about what the import process is currently doing.
If the import hangs, you may find more error messages in the directory DIR_TRANS subdirectory log in the file SLOG. (YY are the last 2 numbers of the year and WW is the calendar week). The lines at the end of the file often even contain detailed messages on the error, such as RDDIMPDP is not scheduled. The following notes should also be checked: 12746, 71353, 26966, 449270.
If no helpful information has been found in the SLOG, you should check in DIR_TRANS subdirectory tmp whether there is a file there with extension .LO and this should be compared with note 12746. You can also check the tables TRBAT and TRJOB via SE16 or SM30 to see if there are old entries there.


6. Not all clients contain client-specific entries!

For objects that enter the system via ADO or SDO import, you must check whether the corresponding jobs RDDIMPDP_CLIENTnnn were released here with the corresponding authorizations. With transports that are to be imported into several clients of a system, you must check whether you worked here with the correct unconditional modes in each case (the first import must be imported with U0 and the following one in each case with U1). Also, a further point which must be considered is the table delivery class belonging to the table. This controls which entries are imported with the various transports into which clients. You will find further information on this in note 2857.


7. An import supposedly has an error, but I cannot find an error in the log files.

This is usually due to the order-independent logs. In the order-independent steps, DDIC objects of other requests may also be edited. For example, the request to adjust a table remains for so long in the internal transport tables and is therefore also processed during a subsequent transport until the adjustment was successfully completed. An error can then be displayed for the subsequent request although its objects were all imported without any errors. Explanatory notes for this are 413993, 512493, 407116 and 330378. After every import, the order-independent logs should therefore also be checked.
If the system refers to canceled RDD* jobs, check the job log via SM37 and via ST22 the short dumps and via SM21 the syslog of the system.


8. A certain program has syntax errors after a transport into a non-development system.

Check whether the syntax errors also occur in the development system. If this is not the case, compare the versions of the program and of the function modules used by the program with the versions in the development system. Different versions can arise if corrections were not yet transported further in the development system or if the sequence of the import does not correspond to the sequence of the export. To solve the problem, import the last changes from the development system into the subsequent system as well.

Setup & Further Information

1. Are there general recommendations for importing transports?

If possible, the TMS should be used and not direct tp calls.If possible, you should import transports if nothing else is running in the system (online/Batch/Batch Input/Direct input/...)or at least nothing that affects the objects contained in these transport requests.There should be at least two free background work processes in the system (note 26966), that can also be scheduled with high priority as of Release 4.6. All application servers must access the same transport directory which is set via the profile parameter DIR_TRANS.This is possible by attempting the call by double-clicking via the AL11. There are also test options from the TMS via OVERVIEW -> SYSTEMS and there R/3SYSTEM -> CHECK -> TRANSPORT DIRECTORY.Furthermore the programs tp and R3trans should be current.The versions can be checked with tp -V and R3trans -V.A function test of the tools can be checked from the TMS (OVERVIEW -> SYSTEMS and there R/3SYSTEM -> CHECK -> CONNECTION TEST or TRANSPORT TOOL).

2. What do I need to consider when setting up the transport?

All systems that create the same transport group in the TMS must use the same transport directory while systems from different transport groups must use different transport directories.The following notes are helpful when you set up the required directory accesses via share or mount: 28781, 62739, 45516, 117395, 201199, 538268.
Up to R/3 Release 4.0, the file TPPARAM must be edited directly in the DIR_TRANS/bin directory.As of R/3 Release 4.5, the parameters can then be maintained from R/3 in the TMS under SYSTEM OVERVIEW after you double-click on the corresponding system.The parameter TRANSDIR is automatically global (checkmark in column global) in the TMS.This global TRANSDIR can be different than the transport directory used by the group (if there are different groups).With the TPPARAM, TRANSDIR must correspond with DIR_TRANS.Furthermore the batch jobs RDDIMDP (for client 000) or RDDIMPDP_CLIENTnnn (for the respective client nnn) must be scheduled for every client.These jobs must also be released event-dependently and with sufficient authorizations (for example as user DDIC).This can be checked using transaction SM37.


3. Can I use the transport directory between NT and UNIX?

When you refer to note 28781 it is also possible to use a common transport directory between NT and UNIX systems.


4. How can I tidy up my transport directory?

If necessary, before the clean-up the files should be saved first because the logs provide information about system changes and may be needed for the revision.After that the older log files can be deleted via the commands "tp check all" and "tp clearold".You will find more detailed descriptions in notes 41732, 168175, 312843, and in the online documentation.


5. Are transports possible between systems with different Support Package versions?

Such transports are technically possible, but inconsistencies can occur between the versions of the transported objects.For example if you first import the Support Packages in the development system and then change an object with a transport request, the version of the transport request is valid there.If you first import the transport request in the subsequent system and then the Support Packages, the version of the Support Packages is active there.


6. Are transports possible between different R/3 releases?

Technically, such transports are often possible.However, the inconsistencies described above can occur between the object versions.Further technical and logical problems for the various releases are outlined in notes 60928, 120151, 126776 and 330267.


7. Are there any general points to note on switching tp and R3trans?

The versions of the tp and R3trans must always match the respective kernel release of the system and should be in the directory /usr/sap//SYS/exe/run.You can check the version and patch level with the commands tp -V or R3trans -V.See note 19466 for the update of both the R/3 kernel and the tools tp and R3trans.For the release upgrade via an upgrade, additional updates of these tools may be required in other directories.You must then read the information in the corresponding upgrade note or guide.


8. Where can I find more information on the transport?

- Course BC 325
- SAP Online Library -> Basis -> Change and Transport System (BC-CTS)
- SAP Service Marketplace, Alias /SWCHANGEMANAGEMENT

Communication Between tp and ABAP

 

Transport steps that are implemented in ABAP include activation of ABAP Dictionary objects, structure conversion, and report/screen generation. Executing these steps is complicated. tp uses the tables TRBAT and TRJOB to communicate with the ABAP transport programs.

For these steps, the R/3 System must be running with at least two background work processes. Furthermore, the batch job RDDIMPDP must be scheduled with the repeat-start option. SAP recommends that the job be scheduled event-driven and periodically. If the job is not running, then start the program RDDNEWPP once in every R/3 System. Do this as user DDIC in client 000 and in all clients that are used as the source or target for a transport.

Once tp has sent the corresponding event to the R/3 System, RDDIMPDP checks table TRBAT to see if there is anything for it to do. If so, it starts the required programs (for example, mass activation) in the background, schedules itself again, and then stops.

RDDIMPDP automatically recognizes if a previous step was terminated and restarts the action. However, this can only be done with two background work processes.

RDDIMPDP recognizes terminated import steps by checking table TRJOB.

Table TRBAT

Looking at an example is the best way to understand how

tp - ABAP communication works in detail.

Consider three change requests which are to be activated. For each change request,

tp inserts an entry into table TRBAT.

TRKORR	Function	RETCODE	TIMESTMP
T11K004711	J	9999	00000001
T11K004720	J	9999	00000002
T11K003456	J	9999	00000003

The table columns have the following meaning:

• TRKORR: Contains the names of the change requests.

• FUNCTION: Contains a key for the requested action. Possible values are:

• A:
Activate all ABAP Dictionary objects in the change request with mass activation (old activation program).
• B:
Activate all ABAP Dictionary objects in table TACOB with mass activation.
• D:
Import application-defined objects.
• G:
Generate reports and screens.
• J:
Activate all ABAP Dictionary objects other than the enqueue modules in the change request with mass activation (new activation program).
• M:
Activate enqueue modules in the change request with mass activation.
• N:
Convert all structure changes generated by the import and recorded in the table TBATG, other than those of matchcode objects.
• O:
Convert all structure changes that were generated by actions in the online system and not by the import and that are recorded in the table TBATG.
• R:
Execute programs after PUT (XPRA).
• S:
Necessary actions to transfer the new Dictionary structures into the runtime environment are distributed to different steps.
• X:
Export application-defined objects.
• Y:
Convert structure changes to matchcode objects that were generated by the import and are recorded in table TBATG.

• RETCODE: Contains exit codes for finished steps. Possible values are:

• 9999:
This step is waiting for execution.
• 8888:
This step is active.
• <= 12: This step is finished.

• TIMESTMP: Contains the order in which the actions should be done. For finished steps, it contains their completion time.

In addition, a header entry is inserted to tell RDDIMPDP to start (the RETCODE column is set to B(egin)).

TRKORR	FUNCTION	RETCODE	TIMESTMP
T11K004711	J	9999	00000000000001
T11K004720	J	9999	00000000000002
T11K003456	J	9999	00000000000003
HEADER	J	B	19921207130147

When RDDIMPDP becomes active, it sets the header entry to R(unning) and starts the corresponding program (mass activation in this case), which sets the first transport to the active status.

TRBAT now looks like this:

TRKORR	FUNCTION	RETCODE	TIMESTMP
T11K004711	J	8888	00000000000001
T11K004720	J	9999	00000000000002
T11K003456	J	9999	00000000000003
HEADER	J	R	19921207130650

8888 in the RETCODE column means that this change request is active. When it is finished, the column contains the return code of the step and the TIMESTMP column contains the completion time.

When all actions are performed, the header entry is set to F(inished). In the meantime,

tp copies the logs of finished steps from the tp directory to the log directory and removes the corresponding TRBAT entries.

TRBAT may then look like this (the log of the first change request was already copied to the log directory):

TRKORR	FUNCTION	RETCODE	TIMESTMP
T11K004720	J	4	19921207130912
T11K003456	J	0	19921207130945
HEADER	J	F	19921207139945

As soon as the last log has been edited,

tp deletes the header entry, and TRBAT is empty again.

Note that actions B (TACOB activation), N, O, Y (structure conversion), and S (distribution) only have header entries. They work independently of change requests.

Table TRJOB

As soon as RDDIMPDP recognizes that there is work to do, the job number (which is generated by SAP background processing) is inserted into the table TRJOB before the corresponding actions are started.

RDDIMPDP checks whether the job is still running once it has become active again and has found a running job in TRBAT and an entry in TRJOB.

If not, the corresponding step (

retcode = 8888 ) is set to 12, and the next step is executed. The TRJOB entry is deleted as soon as the header entry in TRBAT is set to F(inished).

Transport Guide :: Tips for Different SAP Objects

Question: How can I transport certain SAP objects?

Here are tips for different objects:

LSMW: There are 2 ways for transporting LSMW data from a system to another.

1.                           1.    Export/import this method gives you the opportunity to select the subprojects or objects you want to transfer. LSMW -> Extras -> Export project

2.                           2.   Transport request with this method, you can transport a LSMW project in full (you can not select the objects you want). With this method, the project will be transported as any other SAP object in a transport order. LSMW -> Extras -> Create change request 

Program variants

If you have several program variants in a development system that you want to transport, use the following method to transport them:
Execute program 'RSTRANSP' (via se38) and inform the program and/or variant names (you can transport variant of several programs in one shot).

Layout In some transactions, one can save layout of the screen (sort, filter, ... criteria).

These layouts can be transported: In the required transaction, when your layouts have been saved, go to Settings -> Layout -> Layout Management. Select the desired layouts and go to Layout -> Transport... There you can add your layouts in existing TO or create a new one.

Database data

In some unusual cases, you might have to transport data of a SAP table.
Go to transaction SE16, select your entries and go to Table entry -> Transport entries. It's only possible for some tables...
If you cannot do it that way,you have to create a Workbench transport order with transaction SE10. When created, click on it, go in menu Request/task -> Object list -> Display object list.

Go in modification mode and add a new line with:

PgmID = R3TR
Obj = TABU
Object name = Name of your table

Double-click on the created line and, depending on your need, put '*' in the key field or double-click on it and select the key you need to transport.

Queries

Queries, datasets and user groups can be exported/imported between the systems using the Program RSAQR3TR.

Report template (ALV variants)

There is a button or somewhere in the menu Change/Select/Save/Manage Layout.
Go to Manage Layout, than Layout menu/ Transport.

SAPSCRIPT Files Transport

Use the program RSTXSCRP to upload and Download the SAPSCRIPT files to different systems

Transport SAPSCRIPT

Use the Program RSWBO052 to create the Transport Request for a SAPSCRIPT, In the Selection screen of the program, give R3TR - FORM - Give the Form name and press Execute button, it will ask the Development Class and the transport Request No.

Standard texts

Standard texts used in SAPScript(created with transaction SO10) can be included in transport orders. You have to create a Workbench transport order with transaction SE10. When created, click on it, go in menu Request/task -> Object list -> Display object list. Go in modification mode and add a new line with:

PgmID = R3TR
Obj = TEXT
Object name = TEXT,,ST,

Example :
R3TR / TEXT / TEXT,YMM_MEDRUCK_MAIN_16_EC,ST,F

 

Difference between CMS and CTS

By using two ways we can transport the objects.
1. Change Management System.
2. Change Transport System.

Change Management System (CMS) :
Change Management Service (CMS) is part of SAP Net Weaver Development Infrastructure (NWDI). This serviceenables you to configure your transport landscape and manage the transport of objects between different systems.
Automated procedure for transporting....1. Configure the CMS according to the environment and then no reason to login to the server to copy the files.2. It is very Easier.3. Takes less time compared to the file system.4. Feasible for land scape having more interfaces.5. Configuration has to be done setting various servers according to the server time spent in the configuration may be more.
CMS --> Its runs on J2EE engine.
CMS is generally used to transport Java development objects. The XI Integration Server uses CMS to transport Integration Server content.

Change Transport System (CTS) :
Change Transport System (CTS) is the central tool for managing changes to Customizing and Repository data that you make in the IMG/ABAPWorkbench. The CTS records all changes in change requests. CTS is the Product Completion Level.Shows the production process phase that has been reached by the product.

Transporting Authorizations

User data and authorization data must be exchanged in system landscapes with multiple SAP systems. The data is either exchanged between different clients of an SAP system or between clients of different SAP systems.

In principle, the SAP authorization concept differentiates between the following transport contents.


Which Authorization Components Can Be Transported?

. Usermasterrecords
. Roles
. Authorization profiles
. Check indicators

Authorization profiles can be transported together with their roles.
Working with authorization profiles without an assigned role should remain the exception. The transport connection of transaction SU02 for maintaining authorization profiles is only mentioned here for completeness and is not further discussed.


It is only possible to transport all user master records when performing a client copy. It is not possible to select individual user master records.


User master records can also be distributed using Central User Administration.


If you do not want to transport the user assignments to roles, you can protect the target system with an import lock. To do this, the control table PRGN_CUST must contain the entry (USER_REL_IMPORT:=NO).

Caution: If you transport user assignments, the entire user assignment for the role in the target system is replaced. Existing connections to this role are removed. You must also performa user master comparison for all affected roles in the target system after the import.

(Reference : ADM940)

SAP R3trans Unconditional Modes

By using unconditional modes, you can override the rules of the transport system. The following modes are available:

Export:
· 1: Ignore incorrect status of a change request.
If you do not set this mode, only change requests with the status A (all locked), O (open) or R (released) are exported. If the export is successful, the change request is released by R3trans.
· 8: Allow direct selection of forbidden tables.
Some tables are part of complex objects and generally cannot be exported alone.

Import:
· 1: Ignore that this change request was already imported into this system and import everything again.
If you do not set this mode, only objects that have not already been imported successfully are imported again.
· 2: Overwrite originals
· 6: Overwrite repaired objects
· 8: Ignore the restriction resulting from table classifications and import all table entries into specified clients.

R3trans Return Codes

R3trans sets a return code that shows whether or not the transport has succeeded. You can view details on transports in the log file. Here are the following return codes:

0 : No errors or problems have occurred.
4 : Warnings have occurred but they can be ignored.
8 : Transport could not be finished completely. Problems occurred with certain objects.
12 : Fatal errors have occurred, such as errors while reading or writing a file or unexpected errors within the database interface, in particular database problems.
16 : Situations have occurred that should not have.
Examples:
Constants in the program are too small
Not enough available memory
Internal R3trans error

Other return codes are not set by R3trans itself but point to errors, such as segmentation faults.

TMS : Transports Between Systems : Setup & Maintenance Phases

          The (initial) setup phase, where no relevant client-specific data is yet in the target R/3 System

          The (subsequent) maintenance phase, where a complete dataset exists in the target R/3 System

 

 

Transports Between Systems: Setup Phase

 

·         For the setup phase, R/3 provides the following tools:

The Workbench Organizer and the Transport System

Remote client copy and client transport

 

·         The setup phase involves the following steps:

1.      Replicate the R/3 Repository. Transport any customer-specific software (such as ABAP programs) to the new R/3 System using change requests, which are executed by the Workbench Organizer and the Transport System.

2.      Transport the Customizing settings to the new system. To transport the Customizing data, use the remote client copy or client transport tools.

 

·         Client transport and change requests use the transport directory to reach their target system. Remote client copy transports data using an RFC connection.

 

·         Remote client copy and client transport are not designed for transferring large-scale production clients, or for database migration.

 

·         All the SAP Systems in the system landscape should be in one transport domain.

 

 

 

Transports Between Systems: Maintenance Phase

 

<

·         As soon as the data has been written to the R/3 Systems, and needs to be retained, remote client copy and client transport can no longer be used to transport changes to Customizing.

 

·         Therefore, distribute further changes using the Customizing Organizer (CO). To use the CO, you must first activate automatic recording of changes for the client.

 

·         As with the Workbench Organizer (WBO), the CO records the objects that have been changed. In the case of Customizing, these changes are primarily table settings.

 

·         During the maintenance phase, changes to the R/3 Repository and to cross-client Customizing continue to be transported using the WBO.

 

·         The main difference between CO & WBO is that the CO is used primarily to manage changes to Customizing. However, the CO can also be used to manage Workbench requests. To keep Customizing and Workbench development logically separate, changes to the R/3 Repository should only be managed using the WBO.

 

·         Both Customizing and the WBO allow the recorded objects to be transported to the local transport directory. From there, the data is imported into the target system, using the Transport System.

 

 

TMS : Transports in a Single R/3 System

Transports in a Single R/3 System



After the R/3 Systems and their clients have been created, these systems and clients must be customized and filled with data.
First, we consider the distribution of these adjustments and data within an R/3 System.
The first step in adjusting an R/3 System to a customer's requirements is the Customizing process.Customizing is done in a separate client, from which the settings can be distributed across other clients in the R/3 System.
During this distribution process, you must differentiate between:
Target clients with existing data that must be retained
Empty target clients that are not yet filled with data
For target clients with existing data, distribute the Customizing settings using transaction SCC1. This transaction allows single table entries to be transported without deleting the target client completely.
For empty target clients that need to be newly configured, the Customizing settings should be distributed using a local client copy. A local client copy can transport all of the Customizing settings, possibly even including all application data. Because of the data dependencies mentioned above, the target client is
normally deleted before data is copied to it. Therefore, a local client copy cannot be used to merge the data of several different clients; rather, its purpose is to newly configure empty target clients.

TMS : Setting up an R/3 Transport Landscape

1. Make the transport directory available.
2. Configure the transport domain controller and define the domain.
3. Configuration of the transport program (tp) is done automatically and
must not be done at OS level.
4. In the TMS:
- Include all remaining systems in the domain
- Define the transport routes
- Define QA approval procedure
5. Set the system change options according to the role of the R/3 System.
6. Create clients and set the client change options for the production system,
development system, and so on.

The steps for setting up a transport landscape are summarized below.
To set up an R/3 transport landscape:
Make a transport directory available to every R/3 System that will be ransporting.
The TMS allows a local transport directory for every R/3 System.
To configure the TMS, define the transport domain controller.
In the TMS:
- Include all remaining systems in the domain.
- Define the transport routes.
Set the system change options according to the role of the R/3 System.
Create clients in every R/3 System and set the client change options (production
system, development system, and so on).

TMS: Administering R/3 Systems

To create a transport domain, call the TMS from Client 000. To automatically define the transport domain controller as as the current system choose Tools → Administration → Transports → TransportManagement System.
As soon as the domain has been created, additional systems can apply for acceptance by the domain. For security reasons, these systems are not accepted until they have been authorized by the transport domain controller.
The TMS System Overview displays the various system statuses:
Waiting for acceptance by the domain
Active
System locked for the TMS
System not accepted
System deleted
Technically, TMS can connect systems with different R/3 release statuses. However, SAP does not support any transports between such systems.
Because of its central importance, the transport domain controller should run on an R/3 System with a high availability.


Configuring Transport Routes



To configure the transport routes between systems in the domain, use the hierarchical list editor and graphical editor provided by the TMS. Define these settings in the transport domain controller.
The transport routes can be either consolidation or delivery routes.
For consolidation routes, a transport layer is used, for example to define a
route between the development and the quality assurance system.
Delivery routes connect systems, for example the quality assurance and the
production system. They do not use transport layers.
Create transport routes in the graphical editor using drag and drop.
After the transport routes have been configured in the transport domain
controller, they can be distributed across all systems in the domain.
These setting must be activated in all the systems in the domain. This can also be
done centrally by the transport domain controller.
To enable previous configurations to be reused, you can create versions in the TMS.

Transport Management System (TMS): Basics

Tcode STMS -> Tools → Administration → Transports → Transport
Management System.


The Transport Management System (TMS) allows transports between different R/3 Systems to be administered centrally.
The TMS classifies R/3 Systems into transport groups and transport domains:
A transport group consists of all R/3 Systems that can access a common transport directory.
A transport domain consists of one or more transport groups.
To enable transports to be administered centrally, it must be possible to administer all systems in the transport domain from a designated R/3 System, called the transport domain controller.

For the administration of transports, the following information is stored centrally:
The systems participating in the transports
Their transport routes
This configuration data does not need to be set manually in every R/3 System. Instead, using RFC, the transport domain controller distributes the data to all participating R/3 Systems.