Rev-Trac 7 Advanced Guide To Transport Management 1.01

Advanced Guide to Transport Management
Document version: 1.01
Copyright © Revelation Software Concepts Pty Ltd. All rights reserved.

Table of Contents
Purpose .................................................................................................................................................................. 1
Transport creation rules ....................................................................................................................................... 1
Controlling what transports may be added to Rev-Trac requests ................................................................... 2

Adding transports from different systems or clients to the same Rev-Trac request ............................................... 2
Adding only transports from certain systems and/or clients.................................................................................... 2
Transport dependencies ....................................................................................................................................... 5

How to configure transport level transport dependencies ....................................................................................... 6
How to configure request level transport dependencies ......................................................................................... 7
Configuring equivalent system groups for dependencies checking between different landscapes........................ 8
Unsatisfied transport dependencies report ............................................................................................................. 9
Using over-rides to bypass transport dependencies checking.............................................................................. 10
Transport dependencies reports ........................................................................................................................... 11
Quarantining transports ..................................................................................................................................... 12

How to quarantine transports or restore quarantined transports .......................................................................... 13
Quarantined transports report ............................................................................................................................... 14
Transport bundling.............................................................................................................................................. 14
Automatic transport bundling ................................................................................................................................. 15
How to configure an automatic transport bundling process .................................................................................. 17
Step 1. Configuring the prerequisites .......................................................................................................... 17
Step 2. Configuring automatic transport bundling ....................................................................................... 18
Manual transport bundling ..................................................................................................................................... 20
Bundled transports reporting ................................................................................................................................. 21
How does OOPS work with bundles ..................................................................................................................... 21
Transport copying ............................................................................................................................................... 22

Prerequisites for transport copying........................................................................................................................ 23
Creating a child reference type ................................................................................................................... 23
Defining parent/child relationships between parent and child requests ..................................................... 23
Verify the Rev-Trac strategy supports transport copying............................................................................ 24
Automatic transport copying .................................................................................................................................. 24
How to configure an automatic transport copying process ......................................................................... 26
Manual transport copying ...................................................................................................................................... 28
Uploading and downloading transports from PC ............................................................................................ 29
Preventing non transport owners from adding tasks to unreleased transports .......................................... 29
Transport related reports ................................................................................................................................... 30

Transports per requests ........................................................................................................................................ 30
List orphan transports ............................................................................................................................................ 30
Transports only on deleted requests ..................................................................................................................... 30
Missing or unreleased transports .......................................................................................................................... 30
Adding third party vendor transports to Rev-Trac requests .......................................................................... 31
Managing CTS+ transports................................................................................................................................. 31

Managing dual stack CTS+ transports .................................................................................................................. 31
Managing single stack CTS+ transports ............................................................................................................... 31
Document version: 1.01 Page i

CTS+ enforcement ................................................................................................................................................ 31

How to deactivate CTS+ enforcement ........................................................................................................ 33
Document version: 1.01 Page ii

Purpose
This guide describes the configurations and functionalities related to the creation and management of
transports in Rev-Trac. It is intended for Rev-Trac administrators.
The guide is organised in the following sections:
• Transport creation rules describes how to configure rules to determine where transports
can be created.
• Controlling what transports may be added to Rev-Trac requests describes how to
configure to control from which systems and/or clients, transports can be added to Rev-Trac
requests.
• Transport dependencies explains the functionality of transport dependencies and
describes how to configure them at transport and Rev-Trac request level.
• Quarantining transports explains the process of relocating transport data files from their
standard location in the transport directory, and describes how to use the Rev-Trac
quarantine transports utility.
• Transport bundling explains the concept of merging contents of selected transports into a
new transport (also called bundle or transport of copies), and describes how bundles can be
created automatically and manually.
• Transport copying explains the concept of copying transports of ‘child’ Rev-Trac requests
to a ‘parent’ Rev-Trac request and describes how copying can be performed automatically
and manually.
• Uploading and downloading transports from PC describes how to move transport files
between a PC and the Rev-Trac master’s transport directory.
• Preventing non-transport owners from adding tasks to unreleased transports
describes how to use the Rev-Trac protect transport and remove protection functions.
• Transports related reports provides a summary of reports relating to transports.
• Adding third party vendor transports to Rev-Trac requests explains how to add third
party vendor transports to Rev-Trac requests.
• Managing CTS+ transports explains how to manage single and dual track CTS+
transports, and the use for CTS+ enforcement.
Transport creation rules

Rev-Trac uses transport creation rules to determine:
• In which client, a user can create a new, empty transport of a specified type for a Rev-Trac
request.
• If applicable, what CTS project and CTS target, a user has to assign to the newly created
transport.
• Which development system will control the activities related to a specific Rev-Trac
Project/Request type/Transport type combination during Rev-Trac lock checking. Rev-Trac
then uses this information to determine if the transport in question should be taken into
consideration when checking for Intra landscape and Cross landscape locks.
To configure the rules, from Rev-Trac Console, go to menu path Configuration > Process > Advanced
> Transport creation rules.
Document version: 1.01 Page 1

Controlling what transports may be added to Rev-

Trac requests
The following topics describe settings you can use to limit the sources from where transports may be
added to Rev-Trac requests.
Adding transports from different systems or clients to the same

Rev-Trac request
You can control whether transports from more than one system or more than one client within your
Rev-Trac installation may be added to the same request by setting the Tx Add global parameter via
menu path Configuration > Global > Global parameters from Rev-Trac Console.
Here are the available options for the Tx Add global parameter:
Tx Add Effect
0 Rev-Trac prevents users from adding transports from different clients to the same
request, and displays warning if user adds transports from different systems.
1 Rev-Trac prevents users from adding transports from different clients or systems
to the same request.
2 Rev-Trac allows users to add transports from different clients and systems to the
same request.
3 Rev-Trac displays warning if users add transports from different clients and
systems to the same request.
Adding only transports from certain systems and/or clients

You can also configure migration source restrictions to restrict from which source system and/or
client, transports may be added to a request of a particular project/request type combination. See
Figure 1-1 below.
One purpose for using Migration source restriction is to prevent users from accidentally adding
transports from certain systems and/or clients to an unsuitable Rev-Trac request.
Figure 1-1: Migration source restrictions configuration for a particular project/request type combination

Inexperienced Rev-Trac administrators sometimes confuse migration source restrictions with transport
creation rules.
By contrast, the usage of transport creation rules is to control in which system and client Rev-Trac can
create new, empty transports.
To configure migration source restrictions, perform the following steps:
1. From Rev-Trac Console, go to menu path Configuration > Process > Assign process.
2. Switch to Change mode.
The ‘Change View “Process assignment”: Overview’ page is displayed.
3. Select a project and double-click Assignments per project / request type from Dialog Structure
on the left.
The ‘Change View “Assignments per project / request type”: Overview’ page is displayed.
4. Select a request type and double-click Migration source restrictions from the Dialog Structure on
the left.
The ‘Migration source restrictions’ screen is displayed.
5. Complete the following fields:
Field Value
Status If this field is blank, you can add a transport originating from the system/client
(Optional) allowed, at any request’s status.
If this field has a value, you can only add a transport originating from the
system/client allowed when the request is at this status.
Note: You may most likely complete this field if you are using automatic
transport bundling. In a typical transport bundling scenario, you would
configure one restriction for each status within a strategy at which it is
permissible to add a transport to a request (hint: the Tx Status field of the
relevant strategy is not blank).
Sys. name Type the source system from where transports are allowed.
Client Type the source client from where transports are allowed.
Note for single stack non-ABAP system
Rev-Trac may be used in conjunction with CTS+ to migrate non-ABAP
changes either to single stack systems, or dual-stack systems.
A single stack system does not actually have a client, but its ABAP host
system does. When configuring a migration source restriction for a single
stack system, be sure to specify in this field the client of the associated ABAP
host system, as configured in TMS.
For details on how to manage CTS+ transports in Rev-Trac, please refer to
the Managing CTS+ transports section of this guide.
Status text The description of the status is displayed when you press Enter or click Save.
Comment Type a description to remind the Rev-Trac administrator of the purpose of

(Optional) this restriction.
This comment is not displayed to Rev-Trac users when the restriction is
enforced.

Effect of migration source restrictions on TX source dropdown list

When users add a new or an existing transport to a Rev-Trac request via the Rev-Trac Workbench,
they are required to complete the TX source field as shown in Figure 1-2 below. Users can type or
select a value from the dropdown list.
Figure 1-2: Migration source restrictions may affect dropdown list for TX source field in this dialog
When adding an existing transport (rather than creating a new, empty transport), users must
subsequently select in the Transport field a transport that is present in the system specified in the TX
source field.
If the migration source restrictions is configured, the dropdown list for the TX source field shows only
the restricted systems.
If source-specific migration is configured in the Mig Source field in Migration method and target but
migration source restrictions is not configured, the dropdown list for the TX source field shows only
systems explicitly configured in the Mig Source field as shown in Figure 1-3.
Figure 1-3: An example of source-specific migration configuration
If neither source-specific migration nor migration source restrictions is configured, the dropdown list for
the TX source field shows the Rev-Trac master and all development systems.
When adding an existing transport (versus creating a new transport), users must complete the
Transport field by selecting a transport that is present in the system specified in the TX source field.

Transport dependencies
Rev-Trac uses the concept of transport dependency to ensure that pre-requisite transports are
imported into their target systems or equivalent systems before dependent transports can be migrated
to the same systems, or equivalent systems.
The dependencies can only be applied to transports attached to Rev-Trac requests.
The transports involved do not have to be attached to the same request, or even relate to the same
landscape.
Transport dependencies can be useful if, for example:
• Related changes (such as changes to DDIC data elements and program changes that
reference these) need to be migrated in a specific sequence.
• Related changes in different landscapes (i.e. R/3 and BW) need to be synchronised.
You can configure transport dependencies at two different levels:
• Transport level
Transport level transport dependency refers to explicitly defining one transport as a pre-
requisite of another transport to ensure the pre-requisite transport must have been migrated
before the dependent transport can be migrated to the same systems.
For configuration instructions, please refer to the How to configure transport level
transport dependencies section.
• Rev-Trac request level
Request level transport dependency refers to defining one request as a pre-requisite of
another request to ensure all transports / xDeploy packages of the pre-requisite request
must have been migrated / deployed before any transport / xDeploy package of the
dependent request can be migrated / deployed to the same systems.
For example, if Rev-Trac request 156 is defined as the pre-requisite request for Rev-Trac
request 289, this would mean that all transports on request 156 would have had to be
imported into the target systems or equivalent systems before any transport on request 289
can be migrated. Transports of request 156 will precede the transports of request 289 in the
Rev-Trac migration queue.
All additions and deletions of request level transport dependencies will be reported in the
request change log.
This guide does not cover information on xDeploy packages. For xDeploy information,
please refer to the Rev-Trac 7 xDeploy Administrator and User Guide available via Rev-
Trac support portal at www.xrsc.com/support.
For configuration instructions, please refer to the How to configure request level transport
dependencies section.
To check transport dependencies between systems belonging to different landscapes, additional
configuration is required to associate the systems to equivalent system groups. For the additional
configuration instructions, please refer to the Configuring equivalent system groups for checking
dependencies between different landscapes section.
If both transport and request level transport dependencies are defined for the same transport, the
transport level transport dependency will take precedence over the request level transport
dependency for the same transport, in the Rev-Trac migration queue. This means that the queue is
first sequenced to satisfy the request level transport dependency and sequenced again to satisfy the
transport level transport dependency.
A transport dependency checking routine will validate if all applicable transport dependencies are
satisfied when a user tries to approve a migration status. A migration status, if approved, will trigger

migration activity such as releasing or queuing a transport. If an unsatisfied transport dependency is

found, a report will be displayed and the approval may or may not be allowed. Please refer to the
Unsatisfied transport dependencies report section for more details.
Transport dependencies reports are also available to list dependencies defined at transport and
request level. For details, please refer to the Transport dependencies reports section.
How to configure transport level transport dependencies

The following steps describe how to define a transport level transport dependency between a
dependent transport and its pre-requisite transport. For this purpose, the dependent transport is
referred to as transport A and its pre-requisite transport is referred to as transport B.
1. On the ‘Rev-Trac Workbench’ screen, double-click transport A.
The ‘Display transport details’ screen is displayed.
2. Click the Change button at the bottom of the screen and click the Dependencies button.
The ‘Dependencies’ screen is displayed.
3. Click the Add button on the Pre-requisites screen to define the pre-requisite for transport A.
If a request level transport dependency has been defined for this transport, a pop-up message
will appear such as in Figure 2-1 below. Select Yes to continue.
Figure 2-1: Request level transport dependency validation message
4. The ‘Please choose an entity type’ screen is displayed.

5. Double-click the T (CTS Transport) option.
The ‘Dependency details’ screen is displayed.
6. In the Transport source system field, select the source system of transport B.
7. Type transport B number in the Transport field and press Enter.
8. Select Continue. If no error was found, transport B will appear in the Pre-requisites list.
9. Select Continue. The ‘Change transport details’ screen is displayed.
10. Select Save. The dependency relationship will be created.
The ‘Rev-Trac Workbench’ screen is displayed. You will see a dependency icon displayed on
the left of transport A.
11. If you are checking dependencies between systems belonging to different landscapes, please
proceed to the Configuring equivalent system groups for dependencies checking between
different landscapes section to configure the equivalent system group for the systems.

How to configure request level transport dependencies

The following steps describe how to define a request level transport dependency between a
dependent request and its pre-requisite request. For this purpose, the dependent request is referred to
as request 1 and its pre-requisite request is referred to as request 2.
1. From Rev-Trac Console, go to Rev-Trac Workbench.
2. Display request 1 and request 2 using Rev-Trac Workbench.
3. Double-click request 1 and switch to Change mode.
4. Go to menu path Request > Dependencies.
The ‘Dependencies’ screen is displayed. You will see all existing pre-requisite and dependent
requests of request 1.
5. Click the Add button on the Pre-requisites screen to define the pre-requisite for request 1.
The ‘Dependency details’ screen is displayed.
6. Enter request 2 in the Rev-Trac Request field and press Enter.
6.1. The ‘Rev-Trac Dependency validation’ screen may pop-up to display the validation
result of the proposed dependency. The results can contain warning or error
messages. If an error is found, you are not allowed to define request 2 as the pre-
requisite. Possible warnings and errors are as follow:
Warnings
• Pre-requisite request has no transport.
• One identical transport is found on both pre-requisite and dependent requests.
Errors
• Dependency is not allowed if more than one identical transport are found on both
pre-requisite and dependent requests.
• Dependency is not allowed between Rev-Trac requests that contain transport
source systems belonging to different landscapes unless the systems are defined
in the equivalent system group.
• You cannot define a dependent request to itself.
• You cannot define an existing pre-requisite request as a pre-requisite request
again.
• You cannot define its dependent request as a pre-requisite request.
6.2. Close the ‘Rev-Trac Dependency validation’ screen.
7. Select Continue. If no error was found, request 2 will appear in the Pre-requisites list.
8. Repeat step 5 to 7 to add more pre-requisite requests.
9. Select Continue to return to the request details screen.
10. Select Save. The dependency relationships will be created.
11. The ‘Rev-Trac Workbench’ screen is displayed. You will see a dependency icon displayed on
the left of request 1.
12. Click the Refresh icon. You will see a dependency icon displayed on the left of request 2 (the
pre-requisite request).

13. If you are checking dependencies between systems belonging to different landscapes, please
proceed to the Configuring equivalent system groups for dependencies checking between
different landscapes section to configure the equivalent system group for the systems.
Configuring equivalent system groups for dependencies checking

between different landscapes
Rev-Trac uses the concept of equivalent system groups to check transports controlled by defined
transport dependencies, between systems belonging to different landscapes (i.e. R/3 and BW).
Figure 2-2 below describes an environment in which each BW system in a three-system landscape
has been configured as an equivalent system to an R/3 system for the purpose of enforcing transport
dependencies.
BW R/3
BWD equivalent to R3D
BWD R3D Development
systems
BWQ equivalent to R3Q
BWQ R3Q QA Systems
BWP equivalent to R3P
BWP R3P Production

systems
Figure 2-2: Example of equivalent systems
The following steps is an example of how the equivalent BW systems to the R/3 systems as depicted
in Figure 2-2 above can be configured.
1. From the Rev-Trac Console, select Configuration > Process > Advanced > Equivalent system
groups.
The ‘Display View “Equivalent system groups": Overview’ screen is displayed.
2. Switch to Change mode.
The ‘Change View “Equivalent system groups": Overview’ screen is displayed.
3. Click the New Entries button from the toolbar.
The New Entries: Overview of Added Entries’ screen is displayed.
4. To define an equivalent system group for the BW and R/3 development systems, complete
the following fields:
Field Value
Equivlnt syst group SAP_DEV
Equivalent system group text SAP Development systems
5. Press Enter.
6. Select the group and double click Systems from the Dialog Structure on the left.
The ‘Change View “Systems”: Overview’ screen is displayed.

7. Click the New Entries button from the toolbar.

8. Complete the following fields.
Field Value
Sys. name R3D
Sys. name BWD
9. Save your changes.

10. To define an equivalent system group for the BW and R/3 QA systems, double click Equivalent
system groups from the Dialog Structure on the left.
11. Repeat step 4 to 9 and complete the fields with the following values.
Field Value
Equivlnt syst group SAP_QA
Equivalent system group text SAP QA systems
Sys. name R3Q
Sys. name BWQ
12. To define an equivalent system group for the BW and R/3 production systems, double click
Equivalent system groups from the Dialog Structure on the left.
13. Repeat step 4 to 9 and complete the fields with the following values.
Field Value
Equivlnt syst group SAP_PROD
Equivalent system group text SAP Production systems
Sys. name R3P
Sys. name BWP
Unsatisfied transport dependencies report

When a user tries to approve a migration status and if any unsatisfied transport dependency is found,
Rev-Trac displays the ‘Unsatisfied dependencies’ report as shown in Figure 2-3 below.

Figure 2-3: The Unsatisfied dependencies report shows a pre-requisite transport has not been imported
The report will display details of all applicable unsatisfied transport dependencies. Depending on
applicable over-rides, the user may or may not be able to approve the status. For details on the over-
rides, please refer to the Using over-rides to bypass transport dependencies checking section.
Using over-rides to bypass transport dependencies checking

The transport dependency checking routine also verifies applicable transport dependency related
over-rides and by default, an error will occur and prevent the user from approving the status if any
applicable transport dependency is not satisfied. However, you can change the default by configuring
the over-rides with suitable values.
There are two types of over-rides:
• PREREQ_NOT_SATISFIED for transport level transport dependency.
• PREREQ_SUPPRESS_RT_CHECK for request level transport dependency.
To change the over-rides, perform the steps below:

1. From Rev-Trac Console, go to menu path Configuration > Global > Advanced.
The ‘Display View “Over-rides”: Overview’ screen is displayed.
2. Switch to change mode and press Enter.
The ‘Change View “Over-rides”: Overview’ screen is displayed.
3. Modify the over-ride below for transport level transport dependency.
Field Value
Parameter PREREQ_NOT_SATISFIED
Sub Blank
Parameter 1
Sub User=*
Parameter 2 This parameter can also be set to a specific SAP user to limit the scope of
this instruction to a single user.
Value ERROR (This is the default setting. User cannot continue to approve status
if any transport dependency is not met.)
OFF (Do not check for any transport dependency.)
WARNING (User can choose to continue or not.)
4. Modify the over-ride below for request level transport dependency.

Field Value
Parameter PREREQ_SUPPRESS_RT_CHECK
Sub Blank
Parameter 1
Sub User=*
Parameter 2 This parameter can also be set to a specific SAP user to limit the scope of
this instruction to a single user.
Value OFF (This is the default setting. User cannot continue to approve status if
any transport dependency is not met.)
ON (Transport dependency validation is bypassed and user may continue
to approve status.)
Transport dependencies reports

Dependencies reports are available to list defined transport dependencies.
1. From Rev-Trac Console, go to menu path Migration > Reports > Dependencies.
The ‘RSC – Dependencies report’ selection screen is displayed.
2. Select an option from the Pre-requisite type pull-down selection list.
• R for request level transport dependency reports.
• T for transport level transport dependency reports.
3. Execute the report. Figures 2-4 and 2-5 show examples of transport dependencies reports.
Figure 2-4: An example of a transport level transport dependencies report

Figure 2-5: An example of request level transport dependencies report
Quarantining transports
In Rev-Trac, quarantining transports is a process of relocating data files of selected released
transports from their standard location in the transport directory.
Quarantining transports can be useful, for example:
• To prevent migrating transports by accident.
• Quarantining a to-be-overtaken transport can be used to suppress a Rev-Trac OOPS
overtake warning since OOPS normally does not report an overtake of a transport whose
data file is missing from the transport directory.
The Rev-Trac quarantine transport utility is an alternative to manually quarantining transports using
operating system commands. It moves just the transport data files and not the cofiles and transport log
files.
You can use the utility to:
• Perform a mass quarantine by selecting a particular group of transports to be moved from
the transport directory of any system to a central quarantine directory.
• Restore quarantined transports from the quarantine directory to their previous locations.
• List quarantined transports.
In Rev-Trac Workbench, a quarantined transport will have a red X symbol displayed beside it (see
Figure 3-1 below.
Figure 3-1: A quarantined transport is displayed with a red X symbol beside it.

How to quarantine transports or restore quarantined transports

Before using the quarantine utility for the first time, you need to first create a quarantine directory
where the quarantined files will be stored on the Rev-Trac master.
By default, this directory is a quarantine sub-directory of the SAP transport file system with the
TRANSDIR parameter for the Rev-Trac master, via transaction STMS.
For example, if the TRANSDIR parameter is /usr/sap/trans, the default quarantine directory will be
/usr/sap/trans/quarantine.
The Rev-Trac master must be able to read and write to this directory.
To quarantine one or more transports using the quarantine utility, perform the following steps:
1. From Rev-Trac Console, go to menu path Migration > Tools > Quarantine transports.
The ‘RSC - Quarantine transports’ screen is displayed.
2. To select transports to be quarantined or restored, complete one of the selection methods listed
below.
Selection method Description
Transport number Enter transport numbers.
Rev-Trac request Enter Rev-Trac request numbers.
Transport list Enter a Rev-Trac transport list ID.
Transports imported into Enter the SID of the system concerned and more than
system / more than x days ago how number of days ago.
3. If necessary, change the default Quarantine directory name. This field contains the SAP
directory where the quarantined files will be stored on the Rev-Trac master.
4. Clear the Test (no update) checkbox.
5. Perform one of the steps below:
• To quarantine selected transports, select the Quarantine radio button and click
Execute.
The ‘RSC - Quarantine transports’ screen lists files that are moved with text ‘Move verified’
as shown in Figure 3-2 below.

Figure 3-2: Transport data files that are quarantined are indicated with text ‘Move verified’.
• To restore selected transports, select the Restore from quarantine radio button and
click Execute.
Quarantined transports report

The Quarantined transports report can be executed from Rev-Trac Console via menu path Migration >
Reports > Quarantined transports.
The report lists transports from any system whose data files are no longer present due to one of the
following reasons:
• Transport data files are manually moved using an operating system command.
Note: If this method is used, orphan transports (those not attached to Rev-Trac requests)
are not reported.
• Transport data files are quarantined using the Rev-Trac quarantine utility. The report shows
who performed the quarantine, and when.
Transport bundling
Transport bundling in Rev-Trac allows you to merge the contents of selected transports from one or
multiple Rev-Trac requests into a new transport. The new transport is referred to as a transport of
copies or a bundle.
Typically, this function is used to reduce the number of transports to be migrated in order to reduce the
overall import time. This helps to improve the cutover period to Production for large projects.
A bundle can be created using the following methods:
• Automatic transport bundling
• Manual transport bundling

Automatic transport bundling

You can configure Rev-Trac to automatically create a bundle, when a Rev-Trac request is approved.
Using this method, the bundle is always created on the same Rev-Trac request (also referred to as the
container request) as the original transports.
Automatic transport bundling may be combined with the source-specific migration feature to ensure
that only the new bundle is delivered to a production system, while the original transports are not
progressed.
Figure 4-1 below illustrates a scenario where automatic transport bundling and source-specific
migration are used together.
QA1K900371 QA2K900520
DV1 QA1 DV2 QA2 QA3 PRD
DV1K900167 DV2K900481
DV1K900269 DV2K900493
= Non-development system where bundles were created
Figure 4-1: In this scenario, automatic transport bundling is combined with source-specific migration
In this scenario, users worked with a single Rev-Trac request to manage and migrate a set of
functionally related changes that went through the following order of actions:
1. Originally developed in DV1.
2. Imported into QA1, where they were merged into a bundle that was migrated to DV2.
3. Further developed in DV2.
4. Imported into QA2, and then merged into a bundle that is then migrated to QA3 and PRD.
In this scenario:
• QA1 and QA2 are referred to as bundling systems.
• Transports from four different systems (DV1, QA1, DV2 and QA2) were all saved on one
Rev-Trac request that originated from DV1.
• Transports from DV1 (DV1900K167, DV1900K269) never reached DV2, QA2, QA3 or PRD,
and transports (DV2900K481, DV2900K493) from DV2 never reached QA3 or PRD.
After approving a request into a status where automatic transport bundling occurs, a selection screen
similar to the one shown in Figure 4-2 below is displayed.

Figure 4-2: A selection screen is displayed when a request reaches a status where automatic transport bundling
occurs
At this point, the user can proceed to:

1. Select the transports to be merged into a new bundle.
2. Decide whether the bundle will be released immediately after it is created. By default, the
bundle is released immediately.
3. Click the Create bundle button to create the bundle.
To configure the same automatic transport bundling process as explained in the above scenario,
please refer to the How to configure an automatic transport bundling process section.

How to configure an automatic transport bundling process

Step 1. Configuring the prerequisites
Prior to configuring the automatic transport bundling process, the administrator has to configure the
appropriate system parameters and Rev-Trac strategy.
• Configuring the system parameter to support transport bundling

It is assumed that you are familiar with configuring Rev-Trac system parameters, otherwise
please refer to the How to configure system parameters section of the Rev-Trac 7
Advanced Guide to RFC Destinations and System Relationships document available via
Rev-Trac support portal at www.xrsc.com/support.
Table T-1 below shows how Rev-Trac system parameters are configured in regards to the
Rev-Trac landscape used in the previous scenario.
Sys. name Active Landscape Rep Func Enforce Lock System

typ
DV1 X R3_TEMPL 1 1 1 2 0
QA1 X R3_TEMPL 2 8 0 0
DV2 X R3_PROJ 3 2 1 2 0
QA2 X R3_PROJ 4 8 0 0
QA3 X R3_PROJ 5 4 0 0
PRD X R3_PROJ 6 6 0 0
Table T-1: Example of Rev-Trac system parameters setting for the landscape in Figure 4-1
Note:
• To turn a system into a bundling system, set the Func value to 8 (Bundling system).
• Bundling systems can only be used to create bundles and cannot be used for
development.
The normal functions of the systems as explained in the Rev-Trac terminologies:
landscape, master, slave and monitored system section of the Rev-Trac 7 Advanced
Guide to RFC Destinations and System Relationships document continue to apply.
• Verify the Rev-Trac strategy supports transport bundling

The strategy that is assigned to the Rev-Trac request must allow transports to be added to
the request.
It is assumed that you are familiar with configuring a strategy, otherwise please refer to the
How to assign the status paths of a strategy section of the Rev-Trac 7 Basic
Configuration Guide document available via Rev-Trac support portal at
www.xrsc.com/support.
Verify the TX Status field of the strategy is not blank.

If this field is blank, Rev-Trac displays an error message if you try to add any transport to the
request, for example, as shown in Figure 4-3 below:
Figure 4-3: Error message
For a status where automatic bundling is to occur, the Status and TX Status fields of the
strategy will usually be identical.
Step 2. Configuring automatic transport bundling

After the prerequisites are set, you can proceed with the steps below:
The ‘Display View “Process assignment”: Overview’ page is displayed.
2. Select a project and double-click on Assignments per project / request type from the Dialog
Structure on the left.
3. Switch to Change mode and press Enter.
4. Select the request type and double-click on Bundling instructions from the Dialog Structure on
the left.
The ‘Change View “Bundling instructions”: Overview’ page is displayed.
5. Select New entries from the toolbar and complete the following fields.

Field Value
Status A transport of copies or bundle will be created when a Rev-Trac request

reaches this status.
Select a status from a list of statuses defined by the strategy assigned to
this request type.
Bundle Source It is mandatory to type the source system of the transports whose
contents are to be copied into the bundle.
Note: The source system for a transport is usually the system where the
transport was created, unless, the transport was provided by a third
party.
If transports are to be merged from more than one source systems,
create a new entry for each source system. This way, you can ensure
that the contents of transports on a Rev-Trac request from multiple
sources may be merged into a new bundle.
Bundle mode Select Merge.

Note: The Copy mode is unrelated to this transport bundling concept.
Selecting the Copy option will activate automatic transport copying. To
learn about this feature, please refer to the Transport copying section
of this guide.
Bundling system It is mandatory to type the system where bundles will be created.
Bundling client Type the client where bundles will be created.
Bundle target This field is mandatory. It determines what system name will appear as
the nominal target system for bundle that Rev-Trac will create when the
status has been approved.
Rev-Trac uses this value to complete the mandatory Target field when
creating a bundle.
Note: The target can be a real or virtual system that is known to TMS in
the system where the bundles are created (Bundling System). Usually,
the target is the next system to which the bundles will be migrated.
Bundle Ref type This field is optional.

If blank, only transports attached to the current approved request can be
merged into a bundle.
Enter the reference type of referenced requests of which transports will
be selected in addition to transports attached to the current approved
request.
Reference Use default value ‘Container request references subordinates’.

direction
You may review the effect of the configuration by executing the Check Rev-Trac Configuration report
which is accessible via menu path Configuration > Check configuration > Check configuration from
Rev-Trac Console.

Table T-2 below shows the configurations to manage the transport bundling scenario depicted in the
previous Figure 4-1.
Status Bundle Bundle Status text Bundling Bundling Bundle

Source mode system client target
Q1- DV1 Merge Bundle in QA1 100 VRT

BUNDL QA1
Q2- QA1 Merge Bundle in QA2 200 VRS

BUNDL QA2
Q2- DV2 Merge Bundle in QA2 200 VRS

BUNDL QA2
Table T-2: Example bundling instructions for scenario shown in Figure 4-1
When a Rev-Trac request reaches status Q1-BUNDL, a bundle will be automatically created in system
QA1 client 100, with transports originating from system DV1.
When the same Rev-Trac request reaches status Q2-BUNDL, a bundle will be automatically created
in system QA2 client 200 with transports merged from system QA1 and DV2.
Manual transport bundling

A suitably authorised person may also manually create a transport of copies (bundle) using the Rev-
Trac transport bundling utility. Using this method, the bundle may be created on a different request
from the sourced transports.
To utilise the Rev-Trac transport bundling utility, use transaction code SE38 to execute the program
/RSC/MF_MERGE_TX_UTILITY, as shown in Figure 4-4 below.
Figure 4-4: Selection screen for Rev-Trac transport bundling utility

After the user executes the program, a selection screen similar to the one shown in previous Figure 4-
2 is displayed. The user should proceed with steps 1 to 3 as described after the illustration.

Bundled transports reporting

There is no specific report that identifies what transports were merged into new transports of copies.
Rev-Trac stores bundled transports information in table /RSC/T_MF_4M (RSC - Merged transports
index) which could form the basis of such a report.
The Rev-Trac Propagation report includes a selection option that allows users to see the destinations
a transport has reached as a result of its inclusion in a bundle. Please refer to the Rev-Trac migration
reports section of the Rev-Trac 7 Advanced Guide to Migration document available via Rev-Trac
support portal at www.xrsc.com/support.
How does OOPS work with bundles

Figure 4-1 shown earlier is used again for illustration purpose here.
QA1K900371 QA2K900520
DV1 QA1 DV2 QA2 QA3 PRD
DV1K900167 DV2K900481
DV1K900269 DV2K900493
= Non-development system where bundles were created
When importing a transport into a bundling system, OOPS does not report ‘Will overwrite foreign’
against the last transport originating from the bundling system that affects common objects or table
entries. For example, in Figure 4-1, OOPS does not report ‘Will overwrite foreign’ if transports
imported from DV1 into QA1 will affect the common objects or table entries belonging to a bundle
created in QA1.
When importing a bundle into another system, OOPS does not report ‘Will overtake’ against transports
originating from the bundling system that affects common objects or table entries. For example, in
Figure 4-1, when importing a bundle from QA1 to DV2, OOPS does not report ‘Will overtake’ against
transports created in QA1 that affect common objects or table entries.

Transport copying
The concept of transport copying in Rev-Trac refers to copying transports of ‘child’ Rev-Trac requests
to a ‘parent’ Rev-Trac request.
This function allows a manager to associate changes (represented by ‘child’ requests) to a release or
project (represented by a ‘parent’ request) and effectively migrate all approved changes in a single
release into production. This strategy helps to deliver system changes in a standardised manner.
Tip:
From Rev-Trac 7 SPS00 onwards, a new tool called Release Management has been introduced to
help accelerate change deliveries and minimise risks caused by manual work. The module comes with
a workbench to allow you to view and manage the ‘parent’ and ‘child’ Rev-Trac requests by simply
‘drag and drop’.
For more information on Rev-Trac Release Management, please read the Rev-Trac 7 Introducing
Release Management document available via Rev-Trac support portal at www.xrsc.com/support or
call the Rev-Trac consulting team or email consulting@xrsc.com.
Transport copying can be performed using one of the following methods:

• Automatic transport copying by approving the parent request into a defined status.
Note: Automatic transport copying from a child request to a parent request is not possible by
approving the child request into a defined status.
• Manual transport copying
For transport copying to work, you need to setup the appropriate prerequisites. You will also need to
perform some configuration if you want automatic transport copying to be carried out.
The Rev-Trac GUI uses different terminologies for parent and child requests. It is important that you
are familiar with these terminologies before performing any configurations.
Transport copying terminologies
Terminology Meaning
Container and target request Equivalent to parent request.
Subordinate and selected request Equivalent to child request.

Prerequisites for transport copying

• Create a child reference type to define the parent/child relationships between Rev-Trac
requests.
• Create references to define parent/child relationships between parent and child requests.
For example, see Figure 5-1 below.
Figure 5-1: Parent request 391 references to 3 child requests
• Verify the Rev-Trac strategy of the parent request permits transports to be added to it at the
relevant status.
Creating a child reference type

This guide assumes you are familiar with creating reference types. For instructions on how to create
reference types, please refer to the Rev-Trac 7 Advanced Guide to References document available
via Rev-Trac support portal at www.xrsc.com/support.
When creating a child reference type:

• Choose a distinctive identifier that indicates the purpose of the reference type. In the
example used in the previous Figure 5-1, the reference type Child was used.
• Set the Len attribute of the new reference type to 10
• Set the Edit attribute of the new reference type to 4
The usage of this reference type should be reserved only for the purpose of defining parent/child
relationships.
Defining parent/child relationships between parent and child

requests
Once you have created a child reference type, you can define the parent/child relationships between
Rev-Trac requests using one of the following methods:
• On the parent request, create a reference to each child request using the child reference
type. This method is used in the example shown in the previous Figure 5-1.

• Alternatively, on each child request, create a reference to the parent request using the child
reference type.
Note: Regardless of the method you have chosen, please stick to the same method in the future.
Verify the Rev-Trac strategy supports transport copying

The Rev-Trac strategy that is assigned to the parent Rev-Trac request must allow transports to be
added to the request.
It is assumed that you are familiar with configuring a Rev-Trac strategy, otherwise please refer to the
How to assign the status paths of a strategy section of the Rev-Trac 7 Basic Configuration
Guide document available via Rev-Trac support portal at www.xrsc.com/support.
Verify the TX Status field of the strategy is not blank.
If this field is blank, Rev-Trac displays an error message if you try to add any transport to the request,
for example, as shown in Figure 5-2 below:
Figure 5-2: Error message
Automatic transport copying

In an automatic transport copying process, transports are automatically copied from the referenced
child requests to the parent request after the parent request has been approved into an appropriate
status.
Figure 5-3 below shows the parent request 391 references to 3 child requests.
Figure 5-3: Example of parent request before transports are copied from child requests
The parent request does not have any transports to begin with.
When a user starts approving the status, Rev-Trac displays a dialog similar to the one shown in 5-4
below to inform the user that transport copying will occur after the approval of the status is successful.

Figure 5-4: Rev-Trac alerts the user that transport copying will occur if the approval of the status is successful
If the user goes ahead with the approval, Rev-Trac lists all the child requests from which eligible
transports will be copied to the parent, as shown in Figure 5-5 below.
Figure 5-5: Rev-Trac lists child requests from which eligible transports will be copied to parent request
After the user approves both the status and transport copy, Rev-Trac automatically copies eligible
transports along with any target group sent indicators, from the selected child requests onto the parent
request. The transports are not removed from the child requests.
Figure 5-6 below shows the parent request is now in status ‘Copy TX from children’ and the transports
of the child requests have been added to it.
Figure 5-6: Parent request 391 now has transports copied from child requests
The sequence of transports on the parent request is the same as how Rev-Trac would have added
them to the Rev-Trac migration queue.
To configure automatic transport copying upon approval, as illustrated above, please refer to the How
to configure an automatic transport copying process section.

How to configure an automatic transport copying process

To configure an automatic transport copying process from a child request to a parent request, perform
the steps below:
1. Verify the prerequisites for transport copying are set up. For details, please refer to the
Prerequisites for transport copying section.
The ‘Display View “Process assignment”: Overview’ page is displayed.
3. Select a project and double-click on Assignments per project / request type from the Dialog
Structure on the left.
5. Select the request type and double-click on Bundling instructions from the Dialog Structure on
the left.
The ‘Change View “Bundling instructions”: Overview’ page is displayed.

Field Value
Status Select a status from a list of statuses defined by the strategy assigned to
this request type.
Transports are copied to the parent request when it reaches this status.
Bundle Source This field is optional.

Specify a source system only if transports from a specific source system
should be copied from the referenced requests. Otherwise, leave the
field blank.
Warning: Specifying both blank source system and specific source
system entries for the same status will result in an error.
Bundle mode Select Copy.
Bundling system Leave this field blank.
Bundling client Leave this field blank.
Bundle target Leave this field blank.
Bundle Ref type This field is mandatory.

Select the reference type used to define the parent/child relationships
between Rev-Trac requests. For example, reference type Child used in
previous Figure 5-3.
Reference If references are created on the parent (or container) request to point to
direction child requests, select 'Container request references subordinates'.
Otherwise, select 'Subordinate request references container'.
Note:
We recommend that you use only one of these reference directions
consistently.
Regardless of which reference direction used, the copying of the
transports to the parent will occur only when the parent request is
approved, not when the child request is approved.

Manual transport copying

Rev-Trac administrators can manually copy transports from child requests to the parent request by
following the steps below:
1. Verify the prerequisites for transport copying are set up.
2. Start transaction /n/rsc/mf20.
3. The ‘RSC - Copy transports between requests via reference’ screen is displayed.
4. Complete the following fields:
Copy transports on requests with the following attributes
Field Value
Reference type Select the reference type used to define the parent/child relationships
between Rev-Trac requests. For example, reference type Child used
in previous Figure 5-3.
Target request If references are created on the parent (or container) request to point
contains ... / to child requests, select the top radio button.
Selected Otherwise, select the bottom radio button.
request(s)
contains...
Rev-Trac request Complete any of these fields to select the child requests from which
Project transports will be copied to the parent request.
Request type
Project release
Module
Class
Status
Test mode Clear this checkbox.
Copy transports to the target Rev-Trac request
Field Value
Rev-Trac request Type the parent Rev-Trac request to which the transports will be
copied.
1. Execute the program.

2. The ‘RSC - Copy transports from selected Rev-Trac requests’ dialog is displayed. The dialog
lists all child requests that are linked to the parent (target) request and are selected by default.
2.1. If necessary, deselect any child request you wish to exclude from the copy process.
2.2. Click the Copy tx on request(s) button.

3. A report is displayed with the following information:

• All transports copied to the parent (target) Rev-Trac request as a result of this program
run.
• Transports that were already present on the parent (target) and were not a result of this
program run. These may include:
o Transports currently present on the child requests.
o Transports not present on the child requests.
Uploading and downloading transports from PC

The transport upload and download function allows you to move transport files between your PC and
the Rev-Trac master's transport directory.
Among other things, this will allow you to upload transports that contain the latest Rev-Trac hotpacks
from your PC onto the Rev-Trac master’s transport directory when you need to update your Rev-Trac
installation.
To use this function, from Rev-Trac Console, go to menu path Migration > Tools > Upload / download
transports.
Preventing non transport owners from adding tasks

to unreleased transports
Protecting an unreleased transport attached to a Rev-Trac request refers to preventing any person
other than the transport owner from adding a task to the transport. In Rev-Trac, unreleased transports
are unprotected by default.
A protected transport can also be unprotected. Only a transport owner or a Rev-Trac administrator can
protect or unprotect a transport.
To protect or unprotect a transport, perform the following steps:
1. Select the transport in Rev-Trac Workbench.
2. Select Transport from the menu, then select Protect transport or Remove protection.

Transport related reports

Transport related reports can be executed from Rev-Trac Console by going to menu path Request
Management > Reports > Transports and selecting the corresponding option as listed in Table T-3.
Reports Menu options
Transports per Rev-Trac Request Transports per requests
List orphan transports Orphan transports
Transports only on deleted Rev-Tracs Transports only on deleted Rev-

Tracs
Missing or unreleased transports on Rev-Trac requests Missing or unreleased transports
Table T-3: Transports related reports
Transports per requests

This report lists details of transports that exist in the Rev-Trac installation and are attached to Rev-
Trac requests.
List orphan transports

This report lists details of transports that exist in any development system within the Rev-Trac
installation and are not attached to any Rev-Trac request.
Transports only on deleted requests

This report lists details of transports that exist in the Rev-Trac installation and are attached to Rev-
Trac requests that are in status DELT (Deleted).
Missing or unreleased transports

This report lists details of transports within the Rev-Trac installation that are either:
• Missing, or
• Unreleased and attached to Rev-Trac requests

Adding third party vendor transports to Rev-Trac

requests
Rev-Trac allows you to add third party vendor transports to Rev-Trac requests (i.e. via Rev-Trac
Workbench) and the transports can be moved through the landscape the same manner as transports
created in your development systems.
As a prerequisite, the third party vendor transports must first be imported into at least one of your own
development systems via transaction STMS or TP command.
Managing CTS+ transports

Managing dual stack CTS+ transports
No extra configurations are required in Rev-Trac to manage dual stack (ABAP + Portal) CTS+
transports.
Transports created on the ABAP stack continue to be added to a Rev-Trac request in the same way
as an ABAP-only transport because CTS+ handles the migration and deployment of the changes.
Managing single stack CTS+ transports

Versions of SAP NetWeaver 7.00 SPS 12 onwards support non-ABAP systems in the TMS
configuration.
As a non-ABAP system does not have an ABAP stack, it needs to be hosted by an ABAP system
configured in TMS. TMS uses this host for all RFC communications with non-ABAP system.
The following setup is required to manage single stack CTS+ transports in Rev-Trac.
• Define each non-ABAP system and the ABAP system that hosts them in TMS via menu path
Configuration > Systems > Systems > System names from Rev-Trac Console.
• When configuring their system parameters, set the System typ. field of each system as
follows:
• Select 0 for the ABAP host system in TMS.
• Select 1 for non-ABAP systems.
• When configuring migration source restrictions for a non-ABAP system, specify as the client
of the non-ABAP system the corresponding client of its ABAP host system in TMS.
CTS+ enforcement
Rev-Trac includes a feature that allows user to activate Rev-Trac enforcement for transports created
in CTS+ using the Transport Organizer Web UI (involving either CTS_ORGANIZER or
CTS_BROWSER) for single and dual stack development systems.
This feature is called CTS+ enforcement.

If CTS+ enforcement is enabled, users who are currently required to link new standard transports to a
Rev-Trac request will also be required, by default, to link new CTS+ transports to a Rev-Trac request
as shown in the Figure 6-1 and Figure 6-2 below.
Figure 6-1: The Rev-Trac enforcement heading in the ‘Create a transport request’ dialog indicates CTS+
enforcement is activated for CTS_ORGANIZER
Figure 6-2: The Rev-Trac enforcement heading in the ‘Create a transport request’ dialog indicates CTS+
enforcement is activated for CTS_BROWSER
CTS+ enforcement for CTS_ORGANIZER is available only for SAP systems running SAP Basis 701
or greater while enforcement for CTS_BROWSER is available only for SAP Basis 700 or greater.
To implement CTS+ enforcement, you will need to implement a Rev-Trac enhancement in each
communication system where you intend to use the feature.

For more details on how to implement CTS+ enforcement, please refer to the Rev-Trac 7 How to
enable CTS+ Transport Organizer enforcement document available via Rev-Trac support portal at
www.xrsc.com/support.
How to deactivate CTS+ enforcement

If standard Rev-Trac enforcement is turned off, by default, enforcement for CTS+ will be automatically
turned off.
However, you can create an over-ride to disable the CTS+ enforcement while leaving standard Rev-
Trac enforcement active.
To create the over-ride, perform the steps below:
1. From the Rev-Trac Console, go to menu path Configuration > Global > Advanced.
The ‘Display View “Over-rides”: Overview’ page is displayed.
Note: To view the Value column, you may need to resize the other columns.
Field Description
Parameter SYSTEM_PARAMETER
Sub Parameter 1 CTS_PLUS_ENFORCEMENT
Sub Parameter 2 To deactivate CTS+ enforcement for all systems, type ALLSYS.
To deactivate CTS+ enforcement for a specific system, type its SID.
Note: To deactivate CTS+ enforcement for multiple (but not all)
systems, create a separate over-ride for each system.
Value OFF
4. Save your new entries.

5. Activate the change by going to menu path Configuration > Activate changes from Rev-Trac
Console.
If CTS+ enforcement is deactivated, either using the above over-ride or because standard Rev-Trac
enforcement is turned off, the Rev-Trac request field in the ‘Create a transport request’ dialog in the
CTS_ORGANIZER or CTS_BROWSER will be inaccessible.

Rev-Trac 7 Advanced Guide To Transport Management 1.01

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Rev-Trac 7 Advanced Guide To Transport Management 1.01

Diunggah oleh

Hak Cipta:

Format Tersedia

Advanced Guide to Transport Management

Document version: 1.01

Copyright © Revelation Software Concepts Pty Ltd. All rights reserved.

Transport creation rules ....................................................................................................................................... 1

Controlling what transports may be added to Rev-Trac requests ................................................................... 2

Transport dependencies ....................................................................................................................................... 5

Quarantining transports ..................................................................................................................................... 12

Transport copying ............................................................................................................................................... 22

Uploading and downloading transports from PC ............................................................................................ 29

Transport related reports ................................................................................................................................... 30

Adding third party vendor transports to Rev-Trac requests .......................................................................... 31

Managing CTS+ transports................................................................................................................................. 31

Document version: 1.01 Page i

CTS+ enforcement ................................................................................................................................................ 31

Document version: 1.01 Page ii

Transport creation rules

Document version: 1.01 Page 1

Controlling what transports may be added to Rev-

Adding transports from different systems or clients to the same

Adding only transports from certain systems and/or clients

Document version: 1.01 Page 2

Comment Type a description to remind the Rev-Trac administrator of the purpose of

Document version: 1.01 Page 3

Effect of migration source restrictions on TX source dropdown list

Figure 1-3: An example of source-specific migration configuration

Document version: 1.01 Page 4

Document version: 1.01 Page 5

migration activity such as releasing or queuing a transport. If an unsatisfied transport dependency is

How to configure transport level transport dependencies

Figure 2-1: Request level transport dependency validation message

4. The ‘Please choose an entity type’ screen is displayed.

Document version: 1.01 Page 6

How to configure request level transport dependencies

Document version: 1.01 Page 7

Configuring equivalent system groups for dependencies checking

BWP equivalent to R3P

BWP R3P Production

Figure 2-2: Example of equivalent systems

Equivlnt syst group SAP_DEV

Equivalent system group text SAP Development systems

Document version: 1.01 Page 8

7. Click the New Entries button from the toolbar.

Sys. name R3D

Sys. name BWD

9. Save your changes.

Equivlnt syst group SAP_QA

Equivalent system group text SAP QA systems

Sys. name R3Q

Sys. name BWQ

Equivlnt syst group SAP_PROD

Equivalent system group text SAP Production systems

Sys. name R3P

Sys. name BWP

Unsatisfied transport dependencies report

Document version: 1.01 Page 9

Using over-rides to bypass transport dependencies checking

To change the over-rides, perform the steps below:

4. Modify the over-ride below for request level transport dependency.

Document version: 1.01 Page 10

Transport dependencies reports

Figure 2-4: An example of a transport level transport dependencies report

Document version: 1.01 Page 11

Figure 2-5: An example of request level transport dependencies report