Professional Documents
Culture Documents
Rev-Trac 7 Advanced Guide To Transport Management 1.01 PDF
Rev-Trac 7 Advanced Guide To Transport Management 1.01 PDF
Table of Contents
Purpose .................................................................................................................................................................. 1
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
Preventing non transport owners from adding tasks to unreleased transports .......................................... 29
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.
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.
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.
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.
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
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.
BW R/3
BWD equivalent to R3D
BWD R3D Development
systems
BWQ equivalent to R3Q
BWQ R3Q QA 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
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.
Field Value
Field Value
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.
The New Entries: Overview of Added Entries’ screen is displayed.
13. Repeat step 4 to 9 and complete the fields with the following values.
Field Value
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.
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.)
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.)
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.
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.
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.
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
QA1K900371 QA2K900520
DV1K900167 DV2K900481
DV1K900269 DV2K900493
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
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.
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:
For a status where automatic bundling is to occur, the Status and TX Status fields of the
strategy will usually be identical.
Field Value
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.
Bundling system It is mandatory to type the system 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.
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.
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.
QA1K900371 QA2K900520
DV1K900167 DV2K900481
DV1K900269 DV2K900493
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.
Terminology Meaning
• Verify the Rev-Trac strategy of the parent request permits transports to be added to it at the
relevant status.
• 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.
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.
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-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.
6. Select New entries from the toolbar and complete the following fields.
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.
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.
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
Field Value
Rev-Trac request Type the parent Rev-Trac request to which the transports will be
copied.
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.
Field Description
Parameter SYSTEM_PARAMETER
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