Rev-Trac 7 Basic Configuration Guide 1.02

Basic Configuration Guide
Document version: 1.02
Copyright © Revelation Software Concepts Pty Ltd. All rights reserved.

Table of Contents
Purpose .................................................................................................................................................................. 1
Advanced administrator guides........................................................................................................................... 1
Overview of Rev-Trac ............................................................................................................................................ 2
Configuring basic change management processes .......................................................................................... 3
Rev-Trac Projects .................................................................................................................................................. 5

How to create a project via menu path Configuration > Process > Projects................................................................. 5
How to create a project via menu path Configuration > Process > Assign process .................................................... 6
Rev-Trac Request types ....................................................................................................................................... 6

How to create a request type ................................................................................................................................................ 7
Rev-Trac Organisation structures ....................................................................................................................... 7

Rev-Trac Users ....................................................................................................................................................................... 8
How to create a user .............................................................................................................................................................. 8
Rev-Trac Teams ..................................................................................................................................................................... 9
How to create a team ............................................................................................................................................................. 9
Rev-Trac Positions ............................................................................................................................................................... 10
How to create a position ...................................................................................................................................................... 10
How to create an organisation ........................................................................................................................................ 11
How to define an organisation structure ........................................................................................................................... 12
Rev-Trac Strategies .............................................................................................................................................. 12

Rev-Trac Statuses ................................................................................................................................................................ 13
How to create a status ......................................................................................................................................................... 13
Rev-Trac Approval types ..................................................................................................................................................... 14
How to create an approval type ......................................................................................................................................... 15
Rev-Trac Request classes .................................................................................................................................................. 16
How to create a request class ............................................................................................................................................ 16
How to create a strategy ................................................................................................................................................... 17
How to create a strategy from scratch ......................................................................................................................... 17
How to create a strategy by copying an existing strategy ...................................................................................... 17
How to assign the status paths of a strategy ................................................................................................................... 18
How to assign approvers and workflow message recipients ................................................................................ 21
One approval type versus multiple approval types .................................................................................................. 22
How to assign FYI message recipients ........................................................................................................................ 23
Configuring an auto-approval process .............................................................................................................................. 23
Allowing users to reject requests ....................................................................................................................................... 25
Configuring a post-rejection status path ........................................................................................................................... 27
Rev-Trac Target groups ....................................................................................................................................... 29

How to create a target group .............................................................................................................................................. 29
How to create a target group from scratch ....................................................................................................................... 30
How to assign destinations to a target group ............................................................................................................ 30
Document version: 1.02 Page ii

How to create a new target group by copying an existing target group....................................................................... 32
Process assignments per Project and Request type ....................................................................................... 33

How to access the configuration area .......................................................................................................................... 33
How to assign a strategy and organisation structure .............................................................................................. 33
How to assign migration methods and target groups.............................................................................................. 35
Configuring an auto-migration process ............................................................................................................................. 36
Advanced configurations ................................................................................................................................................. 37
Implementing one-click approval ....................................................................................................................... 37

How to configure a one-click approval .............................................................................................................................. 38
Implementing two-component approval ............................................................................................................ 38

How to configure two-component approval ...................................................................................................................... 38
Document version: 1.02 Page iii

Purpose
This guide is intended for Rev-Trac administrators. It assumes the reader is familiar with standard
SAP migration techniques as well as creating and monitoring batch jobs.
It is set out to give an overview of Rev-Trac and describe how to configure a basic change
management process in Rev-Trac.
Advanced administrator guides

More information on advanced configurations of Rev-Trac functionalities is provided in the following
Rev-Trac 7 Advanced Guides available via Rev-Trac support portal at the www.xrsc.com.
• RFC Destinations and System Relationships - describes how to configure Rev-Trac
landscapes and specify the systems belonging to the landscapes and the roles they play as
well as configure RFC destinations for each system to support Rev-Trac inter-system
communications.
• Authorisations - describes how to control the tasks users may perform in Rev-Trac and what
standard profiles are provided by Rev-Trac.
• Migration - contains information on Rev-Trac migration features including target group sent
indicators, displaying and managing items in the migration queue, controlling the sequence
of the queue, migrating items from the queue, Migration Workbench, re-queuing transports,
managing queued migration pauses, migration-related workflow and over-rides, reporting
and migration-related tools.
• Transport Management - contains information on transport creation rules, transport
dependencies, transport quarantining, transport bundling, transport copying, transport-
related reports and managing CTS+ transports.
• References - describes the functionalities of Rev-Trac references and the configurations
required before they can function.
• Overtake and Override Protection System (OOPS) and Locking System - explains how
OOPS can help to prevent the accidental overtaking or overwriting of changes during
migration as well as how the Rev-Trac locking system can help to prevent overtaking and
overwriting of changes by ensuring changes associated with workbench objects or tables are
tracked using the same Rev-Trac request where possible.
• Request Completion, Relationship and Cloning Rules - describes how you can refine your
change management processes using request completion, relationship and cloning rules as
well as status synchronisation between requests.
• Customising Rev-Trac Screens - describes how the Rev-Trac Console screen tabs and the
request details screen can be customised by adding fields on the request details screen,
setting specific field attributes, adding new Rev-Trac Console screen tabs and hiding
standard tabs.
• Customising Workflow Messages - describes how you can customise workflow messages
i.e. emails by creating your own template and using Rev-Trac customer exits.
Document version: 1.02 Page 1

Overview of Rev-Trac
Rev-Trac is ABAP based application that enables you to continuously monitor all transportable
changes in your SAP landscape. Rev-Trac intercepts every transportable change and requires the
change maker to associate it with a Rev-Trac request. Rev-Trac then progresses each request and its
transports using a predefined approval and migration process.
This overview introduces a number of terms and concepts that are key to understand how Rev-Trac
works. They will be identified in bold italics.
A Rev-Trac request may be thought of as a group of transports, related documentation and approvals
to manage a testable unit of change.
Every request has to be assigned to a Rev-Trac project and Rev-Trac request type.
A request passes through a sequence of approved Rev-Trac statuses before it is migrated to the final
destination system. The Rev-Trac strategy determines the sequence of statuses to be approved,
approval requirements and the positions of nominated teams who can approve the statuses. The
project and request type determine which strategy is used. The Rev-Trac organisation structure
maps the Rev-Trac users to their teams and positions and, determines the actual person who may
give particular approvals at specific statuses for the request.
In summary, the approval process of a request is defined by associating the appropriate strategy and
organisation structure to a project and request type. In addition, you can define when, how and to
where migration of transports occurs upon approval of each status by associating the appropriate
Rev-Trac migration method and Rev-Trac target group to the status.
Rev-Trac also provides migration features that are not available when migrating transports using the
TP command or the standard SAP STMS transaction. These migration features include:
• Automatic overtake and overwrite checking of changes by Rev-Trac Overtake and Overwrite
Protection System before each import.
• Automatic approval of post-migration status of a Rev-Trac request following a successful
migration.
• Providing an audit of who approved each migration (as opposed to who actually migrated the
transport).
Rev-Trac is able to intercept and prevent development and migration errors by using two related
mechanisms to help protect workbench objects and SAP configuration from accidental damage. These
mechanisms are called:
• Overtake and Overwrite Protection System (OOPS)
• OOPS prevents the accidental overtaking or overwriting of changes during migration.
Overtaking occurs when you import a transport before another transport that contains a
previous version of the same object or data. Overwriting occurs when you import a transport
that obliterates all or part of the contents of a more recently released transport that is already
present in the system. The over-written object or data is at risk of being left in an unintended
state.
• Rev-Trac locking system
• The Rev-Trac locking system can minimise the incidence of overtaking and overwriting by
ensuring changes associated with a workbench object or table are tracked using the same
Rev-Trac request where possible. The Rev-Trac locking system can be configured to
maintain locks on objects and tables even after the relevant transport has been released.
Rev-Trac is typically configured to release Rev-Trac locks when the corresponding
transports have been imported into production.

Configuring basic change management processes

A basic change management process will at least, help to determine:
• The sequence of statuses Rev-Trac requests will pass through during their lifetime
• Who can approve each status, and what type of approvals are required
• When, how and to where migration occurs upon each approval
Before you can start configuring a process, you need to configure the following pre-requisites.
• Rev-Trac landscapes and system relationships
• RFC destinations to enable inter-system communications
• Rev-Trac user authorisations
Please refer to the relevant advanced guides available from the Rev-Trac support portal at
www.xrsc.com.
Follow the steps below to help you to configure a basic change management process in Rev-Trac.
The instructions for each step are provided in this guide.
1. Create projects and request types to be used to determine the appropriate approval and
migration processes for different requests.
2. Define an organisation structure to map Rev-Trac users to their positions and teams.
3. Create strategies to define approval processes consisting appropriate statuses, approval

types and approvers.
4. Create target groups and assign destinations to where transports are migrated.
5. Assign appropriate strategies, organisation structures, migration methods and target groups
to project/ request type combinations.

Basic Rev-Trac change management

Begin
process configuration flowchart
Create
projects
Create
request types
Configure Create users

Define organisation Map users to their
organisation Create teams
structure teams and positions
structure Create positions
Create statuses Assign status paths

Configure Create approval Assign approvers
Create strategies
strategies types Assign FYI message
Create request recipients
classes
Configure
Create target groups Define destinations
migration
Assign strategy and

Assign Assign migration
organisation
method and target
process structure per
group to each status
project/ request
type
End

Rev-Trac Projects
Every Rev-Trac request belongs to a Rev-Trac project.
In Rev-Trac, the project might represent:
• All work performed in a particular group of systems
• All work performed by a particular group of staff
• A particular system upgrade
• A functional implementation within a specific timeframe
• The migration path of transports or track in Release Management, i.e. BAU track or N+1
track
Note: A Rev-Trac project is not related to a project defined in the SAP Project System (PS) module
You can choose to create a new Project from two menu paths from the Rev-Trac Console:
• Configuration > Process > Projects, OR
• Configuration > Process > Assign process
• This transaction allows you to create a new project by copying from an existing project
(source) and inherit all the request types from the source project.
How to create a project via menu path Configuration > Process >
Projects
1. From the Rev-Trac Console, go to menu path Configuration > Process > Projects. The
‘Display View “Projects”: Overview’ screen is displayed.
2. Switch to Change mode and press Enter.
3. At the ‘Change View “Projects”: Overview’ screen, select New Entries from the toolbar and
complete the following fields for each project.
Field Value
Project Name of the project. For example, PROD_SUP.
Text Description of the project. For example, Production support.
Deact Leave this field blank.

Note:
When the project is no longer appropriate in the future, check this
field to deactivate it, rather than deleting the record, to help to
preserve data integrity of your configuration.
If this field is checked, this project will not appear in the selection
list during Create requests.
4. Save your changes.

How to create a project via menu path Configuration > Process >
Assign process
You should use this method only if you want to create a new project that will inherit all of the request
types from the source project and make the necessary changes.
1. From the Rev-Trac Console, go to menu path Configuration > Process > Assign process.
The ‘Display View “Process assignment”: Overview’ screen is displayed.
3. At the ‘Change View “Process assignment”: Overview’ screen, select the project to be
copied, then, select Copy As… from the toolbar.
4. Make the necessary changes. For example, change the Project and Text fields.
5. Press Enter and the ‘Specify object to be copied’ dialog is displayed.
6. Click on the copy all button on the dialog. An Information dialog displays the number of
dependent entries copied.
7. Press Enter and save your changes.
8. Proceed to the next step if you want to remove some of the request types that came with the
source project or proceed to the Process assignment per project / request type section to
make the necessary changes to the associated processes.
9. Select the new project you have just created and double-click on Assignments per project /
request type from the Dialog Structure.
10. Select the request types to be removed and select Delete from the toolbar.
The ‘Specify objects to be deleted’ dialog is displayed.
11. Click on the all entries button. An Information dialog displays the number of dependent
entries deleted.
Rev-Trac Request types

Every Rev-Trac request belongs to a Rev-Trac project and request type.
Together, the project and request type of a request will determine what Rev-Trac strategy will be used
to manage the request.
Different request types may also be used to:
• Categorise work into different subsets for reporting processes.
• Clarify the purpose of the request and allows for reporting on the progress of different types
of work, even if several requests share a common strategy.

How to create a request type

1. From Rev-Trac Console, go to menu path Configuration > Process > Request types.
The ‘Display View “Request types”: Overview’ screen is displayed.
3. At the ‘Change View “Request types”: Overview’ screen, select New Entries from the toolbar
and complete the following fields.
Field Value
Req type Enter the name of the request type. For example, DEV.
Text Enter the description of the request type. For example, ABAP
development.

Note:
When the request type is no longer appropriate in the future, check
this field to deactivate it, rather than deleting the record, to help to
If this field is checked, this request type will not appear in the
selection list during Create requests.
4. Create a record for each request type within each strategy. For example:
• DEV (ABAP/4 development)

• CUST (Customisation)
• SAPS (SAP security)
• OSSNOTE (Apply OSS note)
Rev-Trac Organisation structures

A Rev-Trac organisation structure maps the Rev-Trac users to their teams and positions they hold in
their teams. Rev-Trac uses the Rev-Trac strategy and organisation structure jointly to determine who
can approve the statuses of requests.
It is possible but a rare practice to define multiple organisation structures in Rev-Trac.
To configure an organisation structure, perform the following steps.
1. Create the users, their teams and positions held in the teams.
2. Create an organisation.
3. Define the organisation structure.

Rev-Trac Users
A Rev-Trac user is also an SAP user and if equipped with suitable authorisation profiles, the user is
able to create Rev-Trac requests and/or administer Rev-Trac. In addition, the user can also approve
requests if he is associated to a position and team in a Rev-Trac organisation structure.
How to create a user

1. From the Rev-Trac Console, go to menu path: Configuration > Process > Organisations.
The ‘Display View “Users”: Overview’ screen is displayed.
3. At the ‘Change View “Users”: Overview’ screen, select New entries from the toolbar.
4. Complete the following fields for each Rev-Trac user.
Field Value
User id Type the user’s SAP user ID. For example, AANDERSON.
Name of user Type the user's name. For example, Axel Anderson.
Deact This field determines if the user is allowed to approve a Rev-Trac

request.
• Leave this field blank to allow the user to approve Rev-
Trac requests.
• Check this field to prohibit user from approving Rev-Trac
requests.
Ref user Complete this field only if this user will be accessing Rev-Trac
solely from the optional xPack add-on to Rev-Trac.
Type the SAP user against which this user’s Rev-Trac
authorisation will be verified, preferably, a reference type user.
UserType This field determines if the user is subject to system-wide

settings that control whether a new transport must be associated
with a Rev-Trac request.
Leave this field blank. This will allow the system-wide settings to
apply.
AdminAuth Together with the user's security profile, this field determines
whether the user has special privileges to administer Rev-Trac.
Leave this field blank to prohibit the user from performing Rev-
Trac administration.
Recip. type This field determines how Rev-Trac will send workflow
messages to this user.
Select a value from the possible entries.
Email address Type the user’s email address.

Rev-Trac Teams
A Rev-Trac user who is responsible for approving requests must be associated to a position and team
in a Rev-Trac organisation structure. For example, your teams might include a Basis team and an
ABAP team. The members of those teams might be assigned to positions such as ‘member’ and/or
‘team leader’.
How to create a team

1. From the Rev-Trac Console, go to menu path: Configuration > Process > Organisations. The
‘Display View “Users”: Overview’ screen is displayed.
2. Double-click on Teams from the Dialog Structure.

The ‘Display View “Teams”: Overview’ screen is displayed.
4. At the ‘Change View ”Teams”: Overview’ screen, select New entries from the toolbar.
5. You will see the Rev-Trac standard team, <TM>. Do not delete.
6. Complete the following fields.
Field Value
Team Enter the name of the team involved in performing the work
pertaining to a Rev-Trac request. It will be used when creating a
Rev-Trac request.
For example, ABAP.
Text Enter a description of the team. For example, ABAP

Development Team.

Note:
When the team is no longer appropriate in the future, check this
If this field is checked, this team will not appear in the selection
list during Create requests.
7. Create a record for each team required in your organisation. For example:
• CONF (Configuration team)

• DEV (Development team)
• QA (Test team)
• BASIS (Basis team)


Rev-Trac provides a standard team called <TM> that is not to be deleted or used when configuring an
organisation structure. It is only useful in configuring the approvers and workflow message recipients
in Rev-Trac strategies.
Rev-Trac Positions
A Rev-Trac user who is responsible for approving requests must be associated to a position and team
in a Rev-Trac organisation structure. Rev-Trac provides the following standard positions.
<AM> Auto-Mig
This is used by Rev-Trac to automatically approve a post-migration status such as ‘In QAS’ or ‘In
PRD’. This feature is called auto-approval. This means Rev-Trac checks the result of the preceding
migration and approves the status if the return code is 4 or less.
<CS> Request customizer
Approval can only be given by the user whose user id matches the Customizer field of a Rev-Trac
request details.
<NO> No approval required
The status is approved automatically without manual intervention as soon as the previous status has
been approved.
<OW> Request Owner
Approval can only be given by the user whose user id matches the Owner field of a Rev-Trac request
details.
<PG> Request Programmer
Approval can only be given by the user whose user id matches the Programmer field of a Rev-Trac
request details.
These standard positions should never be deleted or modified. In addition, they should not be included
in any Rev-Trac organisation structures but may be assigned while configuring the approvers and
workflow message recipients in Rev-Trac strategies.
You can create your own positions in addition to these standard positions.
How to create a position

2. Double-click on Positions from the Dialog Structure. The ‘Display View “Positions”: Overview’
screen is displayed.
3. You will see the Rev-Trac standard positions provided.
5. At the ‘Change View “Positions”: Overview’ screen, complete the following fields.

Field Value
Position Enter the name of the position a Rev-Trac User holds within a
Rev-Trac Team. For example, IM.
Text Enter a description of the position. For example, Integration

Manager.
Field Value

Note:
When the position is no longer appropriate in the future, check
this field to deactivate it, rather than deleting the record, to help
to preserve data integrity of your configuration.
6. Create a record for each position required for your organisation. For example:
• MEMB (Team member)
• TL (Team leader)
How to create an organisation

2. Double-click on Organisation names from the Dialog Structure. The ‘Display View
“Organisation names”: Overview’ screen is displayed.
4. At the ‘Change View “Organisation names”: Overview’ screen, select New entries from the
toolbar and complete the following fields.
Field Value
Org Enter the organisation structure name. For example, RSC_AU.
Text Enter a description of the organisation structure. For example,

RSC Australia.

Typically, there should only be one organisation in use unless advised otherwise by Rev-Trac support.

How to define an organisation structure

1. At the ‘Change View “Organisation names”: Overview’ screen, select an organisation and
double click on Organisation structure from the Dialog Structure. The ‘Change View
“Organisation structure”: Overview’ screen is displayed.
2. Select New entries from the toolbar and complete the following fields for each user to be
assigned to the organisation structure.
Field Value
Team Enter a predefined Team or choose from the possible entries.

Note: Do not use any standard Rev-Trac Team as these can
only be used when configuring a Rev-Trac strategy.
Position Enter a predefined Position or choose from the possible entries.

Note:
Do not use any standard Rev-Trac Position (<AM>, <CS>,
<NO>, <OW>, <PG>) as these can only be used when
configuring a Rev-Trac strategy.
User id Enter the user’s User id or choose from the possible entries.
Standin This field determines if this user is the alternative approver for
the position owner. This stand-in user will approve a Rev-Trac
request when the position owner is not available.
Check the box to set this user as a stand-in user.
3. Press Enter to display the names and the deactivation flag of the users you have added.
Note: Do not add a user whose Deact box is checked. This means the user can no longer
approve a request.
Rev-Trac Strategies
The Rev-Trac strategy determines the approval process, which includes:
• Stipulating what statuses and their sequences a request will pass through during its lifetime.
• Satisfying pre-requisites and dependencies.
• Ensuring statuses are approved by the appropriate approvers.
• Ensuring appropriate email notifications are sent out either to advise a status is ready for
approval and/or that status has been approved.

Rev-Trac also provides the ability to automatically approve a post-migration status. This feature is
called auto-approval. After all transports associated with a request have been successfully migrated
to their destinations, Rev-Trac can automatically approve the request's next status confirming
successful import so that the following status is available to continue the request’s lifecycle. Auto-
approval and auto-migration are frequently used together. Please read the Configuring an auto-
approval process and Auto-migration sections in this guide.
To configure a strategy, perform the following steps.

1. Create appropriate statuses, approval types and optionally, request classes.
2. Create a strategy.
3. Assign the appropriate status paths of the strategy.
4. Configure the approvers and Work Flow message recipients for each status.
5. Configure the recipients of informative messages for each status, if required.
Rev-Trac Statuses
Every Rev-Trac request passes through a sequence of statuses before it is migrated to the final
destination system.
Statuses need to be defined to represent the different stages to which a request typically progresses
when one of the following activities happens:
• A user has approved the current status
• A user has added a transport to a request
• A transport associated to a request has been successfully migrated
For example, a request will pass through a simple sequence of statuses such as New request,
Development in progress, Development complete, Approved for QA, In QA, Approved for Production
and In Production.
How to create a status

1. From Rev-Trac Console, go to menu path Configuration > Process > Strategies.
The ‘Display View “Statuses”: Overview’ screen is displayed.
3. At the ‘Change View “Statuses”: Overview’ screen, select New Entries from the toolbar and
complete the following fields.

Field Value
Status Status name. For example, D-IP.
Status text Description of the status. For example, In progress.
Lock Mode This field determines whether the request will hold Rev-Trac locks
for the objects in the transports attached to the request when it is
currently in this status.
Typically, leave this field blank to ensure the request will be locked
when it is in this status and will be unlocked when the request is no
longer in this status.
Choose 1 if you want to ensure the request is not locked in this
status. For example, it is common to release Rev-Trac locks when
a request is in a completed (COMP) or deleted (DELT) status.
Deactivate Leave this field blank.

Note:
When the status is no longer appropriate in the future, check this
4. Create a record for each status required in a strategy. For example:
• NEW (New)
• D-IP (In progress)

• D-CM (Development completed)
• D-MG (Approved for QA test)

• Q-IN (In QA)
• Q-PMIG (Approved for production)

• P-IN (In production)
• COMP (Complete)
Rev-Trac Approval types

The Approval type indicates what type of approval is required from the user for each status. For
example, the type of approval can be technical, functional, support, Basis, etc.
Sometimes, more than one approval (sign-off) is required for a status. This can be achieved by
configuring multiple approval types for the status, each requiring an approval from a different
approver. For example, before a transport can be migrated from QA to Production (Q-PMIG status),
the status requires both functional and support approvals. In this case, two approval types must be
configured in the Rev-Trac strategy.

How to create an approval type

2. Double-click on Approval types from the Dialog Structure. The ‘Display View “Approval
types”: Overview’ screen is displayed.
4. At the ‘Change View “Approval types”: Overview’ screen, select New Entries from the toolbar
and complete the following fields.
Field Value
App type Enter the name of the approval type. For example, ABAP.
Class Choose one of the following options:

• Typically, type * (asterisk) to enforce this approval type to be
given regardless of what is entered in the Class field in the
request details screen.
• Enter a new value or choose from the possible entries if this
approval type is required only if the request has a particular
Class.
Note: If a new value is entered, make sure to create the new
request class. For details on how to create a new request class,
please read the next section Request classes.
Description Enter the description of the approval type. For example, ABAP/4
development.

Note:
When the approval type is no longer appropriate in the future,
check this field to deactivate it, rather than deleting the record, to
help to preserve data integrity of your configuration.
5. Create a record for each approval type required in your strategy. For example:
• FUNC (Functional)
• TECH (Technical)
• MGMT (Management)

Rev-Trac Request classes

Request classes are useful to enable the controlled fast tracking of approval process to deal with
emergency situations. In such circumstances, it may be desirable, for example, to bypass
documentation and other steps and, optionally reposition the steps after deployment to production.
When a request class is used when creating a request, it may affect:
• Whether fewer or more approvals or different type of approval are required for this request
than would otherwise would be the case
• The colour in which the request number will appear on the Rev-Trac Workbench.
How to create a request class

2. Double-click on Request classes from the Dialog Structure. The ‘Display View “Request
classes”: Overview’ screen is displayed.
4. At the ‘Change View “Request classes”: Overview’ screen, select New Entries from the
toolbar and complete the following fields.
Field Value
Class Enter the name of the class. For example, E. For more details,
press F1 (Help) for this field.
Colour Leave it blank (the default value) or select a value (0 to 9) from the
possible entries.
The value 0 to 9 represents the colour used to display the request
number for a request of this class on the Rev-Trac Workbench.
Description Enter the description of the class. For example, Emergency.

Note:
When the object is no longer appropriate in the future, check this
5. Create a record for each class required in the strategy.

How to create a strategy

1. From the Rev-Trac Console, select Configuration > Process > Strategies.
2. Double-click on Strategies from the Dialog Structure.
The ‘Display View “Strategies”: Overview’ screen is displayed.
4. You can choose either to:
• Create a strategy from scratch, OR
• Copy from an existing strategy

You may want to use this option to copy the status path and approvers to the new
strategy and make changes.
How to create a strategy from scratch

1. At the ‘Change View “Strategies”: Overview’ screen, select New Entries from the toolbar and
complete the following fields.
Field Description
Strat Name of the strategy. For example, ABAP01.
Text Enter the description of the strategy. For example, ABAP/4

development phase 1.
2. Create a record for each strategy required.
How to create a strategy by copying an existing strategy

You should use this method only if you want to create a new strategy that will inherit all the statuses
and approvers from an existing strategy and make the necessary changes.
1. At the ‘Change View “Strategies”: Overview’ screen, select the strategy to be copied, then
select Copy As… from the toolbar.
2. The selected strategy will appear in an entry screen allowing you to make appropriate
changes to the Strat and Text fields.
3. Press Enter and the ‘Specify object to be copied’ dialog is displayed.
4. Click on the copy all button on the dialog. An Information dialog displays the number of
dependent entries copied.

6. Proceed to the How to assign the status path of a strategy section to change the status
paths.
7. Repeat step 1 to 6 for every strategy required.
How to assign the status paths of a strategy

1. At the ‘Change View “Strategies”: Overview’ screen, select the Strategy and double-click on
Status path from the Dialog structure.
The ‘Change View "Status path”: Overview’ screen is displayed. From here, you can add,
change or remove a status from the Status path.
2. To add a status, select New Entries from the toolbar.
2.1. Complete the following fields.
Field Value
Number Enter an arbitrary number, i.e. 100, 200, 300. This field will set
the sequential order of statuses a Rev-Trac request will pass
through. The sequence starts from the lowest number. Be sure
to increment by large values to allow for later insertions if
required.
Status Select from predefined statuses list.
TX This field determines the status a request will progress to when

Status a transport is added to the request.
Choose one of the following options:
• Enter the next status a request will proceed to when a
transport is added to the request.
Typically, this field should be set to ‘In Progress’ (D-IP) or
similar status whenever a transport is added to the request
to help reflect that development work is still in progress for
this business requirement.
• Leave the field blank if users are prohibited from adding a
transport to the request at the current status. For example,
transports should not be added when the current status is
‘Approved for PRD’ or ‘In PRD’.
Note:
If this field is blank, Rev-Trac displays an error message if a
user tries to add a transport to the request, for example, as
shown in Figure X-1 below:
Figure X-1: Error message

Field Value
Chg This field determines the status a request will progress to when
Status a major change to the request is detected. For example,
(Optional) changes to project and request type of the request are
considered major changes. For more details, select Help or
press F1.
• Leave the field blank.
If the field is left blank, no change is allowed to a ‘major
change’ field when a request is in this status. For example,
if the Status field is NEW and an attempt was made to
change a ‘major change’ field on a request, the following
error will be displayed:
Request has status "New request" (NEW), no changes
allowed
• Enter the next status when a major change to the request
is detected. For example, NEW.
Note:
A major change to a request is detected when a change is
made to the request details screen field which Major change
flag is set to Yes. This setting can be found at Rev-Trac
Console > Configuration > Process > Request screen > Field
attributes. For more details, please refer to the Rev-Trac 7
Advanced Guide to Customising Rev-Trac Screens
document via Rev-Trac support portal at www.xrsc.com.
Rej This field determines if the approval to the request can be

Status rejected.
(Optional) Choose one of the following options:
• Leave the field blank if the approval cannot be rejected.
• Enter the next status a request will change to when the
approval is rejected. When this status is specified, a Reject
button is displayed alongside the Sign button at approval
time. For more details on how to allow request rejection,
please read the Allowing users to reject requests
section at the end of this chapter.
Return Together with Rej Status field, this field is used to configure an
sta alternative route through a sequence of additional statuses that
(Optional) would not normally be part of the request's life cycle, but are
relevant after approval is rejected.
• Leave this field blank if Rej Status field is blank.
• Enter the status a request will change to when the
approval is rejected. Please read Configuring a post-
rejection status path section at the end of this chapter
before completing this field.

Field Value
Branch This field is used to configure a simple parallel approval path in

sta Rev-Trac to allow a request to be approved into two statuses
(Optional) that subsequently, an approver can choose to approve either
one of them.
Leave this field blank if this function is not required. This
functionality is not covered in this guide. For details, please
read How to configure simple parallel approval paths
2.2. Create a record for each status required in the status path of the strategy, i.e.:
• NEW (New)
• D-IP (In progress)

• D-CM (Development completed)
• D-MG (Approved for QA test)

• Q-IN (In QA)
• Q-PMIG (Approved for production)
• P-IN (In production)

• COMP (Complete)
2.3. Save your changes.
2.4. Proceed to How to configure Approvers and Work Flow message recipients
section.
3. To delete an existing status, select one or more statuses to be deleted.

Warning
Do not delete a status from a strategy until you have confirmed no requests using the
strategy are currently at the status to be deleted.
Since Rev-Trac 7.2.0 (SPS02), referential integrity has been improved and Rev-Trac will
validate and disallow deletion of the status if it is being referenced in the following
configuration areas:
• Request relationship rules
• Request complete rules
• Request cloning rules
• Release Management
3.1. Select Delete from the toolbar.
3.2. Select all entries or without dep. records on the dialog. If all entries option is
selected, an Information dialog will display the number of dependent entries deleted.
3.3. Press Enter and save your changes.

How to assign approvers and workflow message recipients

It is mandatory to specify the type of approval and who can approve them, for each status in a Rev-
Trac strategy.
1. At the ‘Change View "Status path”: Overview’ screen, select a status and double-click on
Approvers & WF message recipient from the Dialog Structure
The ‘Change View “Approvers & WF message recipients”: Overview’ screen is displayed.
2. To assign an approver, select New entries from the toolbar.
Field Value
App type This field determines the type of approval required from the
approver i.e. functional, technical, Basis, etc.
Select from predefined approval types.
Team Select from predefined Teams to which the approver belongs.
Position Select from predefined Positions of which the approver holds.

If no approval is required such as for COMP (Complete) status,
select <NO>.
Note:
If you select standard positions such as <CS>, <OW> or
<PG>, please verify that entries to the corresponding fields in
the request details screen such as request customiser, owner
and programmer are made mandatory. For details on how to
make a field mandatory, please read the Rev-Trac 7
Advanced Guide to Customising Rev-Trac Screens
WF Msg This field determines if Rev-Trac sends a workflow message

prompting the approver to approve the request’s status.
Click on Help (F1) to select the most relevant choice.
2.2. Press Enter to see the Team and Position descriptions in the Text columns.
2.3. Create a record for each different approval required for the status concerned. For
example, if the status needs approvals from two different approvers, you need to
create two records, one for each approval type. For more details, please refer to the
One approval type versus multiple approval types section.
3. To delete an approver, select one or more approvers to be deleted and select Delete from
the toolbar.

One approval type versus multiple approval types

Figure 1-1 below shows a status that requires only one approval type, FUNC (Functional) but the
approval can be given by either the development manager or any member from the management.
Figure 1-1: One approval type (FUNC) is configured for the D-QMIG status, hence, one approval is required
Some statuses may require multiple types of approval. The approval type indicates what approval is
required from the user and the number of approvals required is equal to the number of different
approval types configured for the status.
Figure 1-2 below shows a status that requires 2 types of approval (FUNC and SUPP). Therefore, two
approvals are required for this status.
Figure 1-2: Two approval types (FUNC and SUPP) are configured for this status, therefore, two approvals are
required, one for each approval type

How to assign FYI message recipients

It is optional to configure who will receive informative messages when a Rev-Trac request reaches a
particular status.
1. At the ‘Change View "Status path”: Overview’ screen, select a status and double-click on FYI
message recipients from the Dialog Structure.
The ‘Change View "FYI message recipients”: Overview’ screen is displayed. From here, you
can add, change or remove an informative message recipient.
2. To add a recipient, select New entries from the toolbar.
Field Value
Team Select from predefined Teams to which the recipient

belongs.
Position Select from predefined Positions of which the recipient holds.
FYI Msg This field determines if Rev-Trac sends a ‘For your

information’ message to the Position owner when the request
is in this Status.
Click on Help (F1) to select the most relevant choice.
2.2. Press Enter to see the description of the team and position in the Text columns.
2.3. Create a record for each recipient required.
3. To delete a recipient, select one or more recipients to be deleted and select Delete from the
toolbar.
Configuring an auto-approval process

In Figure 2-1 below, after the approval was given in the Approved for QAS status (migration status),
the two-step auto-migration process in Rev-Trac triggered the transports to be added into the
migration queue and then, the transports were migrated to destinations in QAS by a scheduled batch
migration job created using the Rev-Trac batch migration utility. Migration completed with return code
4 or less, therefore, Rev-Trac auto-approved the In QAS status (post-migration status). The approver
in the auto-approval process was AUTOMIG.

Figure 2-1: The In QAS status is auto-approved by AUTOMIG
In the auto-approval process:

• The approver in the auto-approval process is always AUTOMIG. It is recommended that you
use auto-approval and auto-migration processes together. For details on auto-migration
process, please read the Configuring an auto-migration process section.
• Rev-Trac treats a migration as successful if the return code is 4 or less (not configurable).
• Rev-Trac checks if all Rev-Trac requests that are currently in migration statuses (that is, a
status that triggers migration activity such as releasing or queuing a transport), are eligible to
be auto-approved in their next statuses (post-migration status).
• The Rev-Trac batch migration utility /RSC/MF_BATCH_MIGRATION_UTIL checks and auto-
approves the next statuses of eligible requests after their transports in the queue are
migrated successfully.
• Rev-Trac ignores the return codes for all migrations to destinations with Chk Level set to 9
(refer to How to assign destinations to a target group section). By verifying this setting, Rev-
Trac can still auto-approves the post-migration statuses of requests when the migrations to
these destinations fail or do not occur at all while migrations to other destinations within the
same target group succeed.
Figure 2-2 is an example how an auto-approval process is configured for a status.
Figure 2-2: Example of how auto-approval is configured
In Figure 2-2, only one type of approval (TECH) is configured for this status, therefore, only one
approval is required.
The approval can be give by any of the following:
• AUTOMIG (the Rev-Trac auto-approver in the auto-approval process)
• Any member of the Management team
• Any member of the Technical team
• Assuming Rev-Trac is configured to perform an automatic migration and the previous status
(migration status) is approved, Rev-Trac will check the result of the migration and
automatically approve the Q-IN status (post-migration status) if the migration succeeds.
• If the automatic migration does not succeed, Rev-Trac sends workflow notifications to the
Management and Technical staff. The Technical staff, for example, can investigate the
problem. If it becomes clear that the migration has actually succeeded despite a return code
more than 4, or if the transport is subsequently migrated successfully to this destination

using SAP's own migration tools, a member of the Management or Technical teams can
approve the Q-IN status manually.
To configure a status to be auto-approved i.e. Q-IN and PRD-IN, perform the steps below.
1. At the ‘Change View "Status path”: Overview’ screen, select a status and double-click on
Approvers & WF message recipient from the Dialog Structure
The ‘Change View “Approvers & WF message recipients”: Overview’ screen is displayed.
2. Change the existing record or add a new record with the following values:
Field Value
App type Select the approval type that could be given by the human
approver.
Team Type * (asterisk)
Position Select <AM> from the possible entries.
WF Msg Leave this field blank
3. In addition to the auto-approver, be sure to configure at least one human approver who can
give the same type of approval and receive a workflow notification if an error occurs, causing
the auto-approval process to fail. Look at previous Figure 2-2.
Allowing users to reject requests

You can configure Rev-Trac so that users can approve or reject requests at particular statuses.
Figure 3-1 below shows how a strategy is configured so that a Reject button will appear at the
‘Approved for QAS’ status and when the request is rejected, the status will revert to the ‘In progress’
status. To perform this configuration, please refer to the previous How to assign the status path of a
strategy section and complete the Rej status field.
Figure 3-1: Completing the Rej status field causes the Reject button to appear at the ‘Approved for QAS’ status
If a rejection is allowed, the Reject button is displayed alongside the Sign button during approval as in
Figure 3-2 below.

Figure 3-2: Reject button is displayed when a request is allowed to be rejected
Rev-Trac may be configured so that providing a rejection reason is mandatory. To do this, please refer
to the How to assign a strategy and organisation structure section in the next chapter and check
the Reject checkbox to ensure that entering a rejection reason is mandatory.
If a user chooses to reject a request, Rev-Trac displays a dialog that indicates what status the request
will move to after the request is rejected and the user can provide a rejection reason as shown in
Figure 3-3 below.
Figure 3-3: This dialog shows the In progress post-rejection status, and allows a rejection reason to be completed
After a user has rejected a request, Rev-Trac adds a Request Rejected node to the request's
approvals history. If a rejection reason has been provided, users may view it by clicking this node as
shown in Figure 3-4 below.

Figure 3-4: User may view rejection reason by clicking on the Request Rejected node
Configuring a post-rejection status path

When a Rev-Trac request is rejected, users may wish to route that request through a sequence of
additional statuses that would not normally be part of the request's life cycle, but that are relevant after
a rejection.
Figure 4-1 below shows the normal status path of a request. The request is currently in status 'In
QAS', and must pass through two more statuses (Approved for PRD and In PRD) before the cycle is
complete.
Figure 4-1: The normal status path for this request
Figure 4-2 below shows the same request after the 'Approved for PRD' status was rejected.
• The request is now in status 'Rejected for Production', a status this request would not
normally pass through.
• The next status to be approved is 'Release re-assigned', also a status this request would not
normally pass through.

• After the 'Release re-assigned' status has been approved, the request will return to one of
the statuses in its normal status path.
Figure 4-2: Two additional statuses were added after this request was rejected
Figure 4-3 below shows how a strategy is configured to specify the post-rejection status path as
shown in the previous Figure 4-2.
Figure 4-3: Rej status and Return sta settings to determine the post-rejection status path
In this example:
• A Reject button appears when users are asked to approve status 'Approved for PRD'
(Number 500) because the Rej status field is populated for this status.
• If status 'Approved for PRD' (Number 500) is rejected, the request will move to status
'Rejected for Production', because this is specified in the Rej status field for this status.
• Once the request is in status 'Rejected for Production' (Number 800), the next status to be
approved will be 'Release re-assigned', because this is the next status in the sequence.
• After status 'Release re-assigned' (Number 900) has been approved, the next status to be
approved will be 'Approved for PRD', because this is specified in the Return sta field.

Rev-Trac Target groups

In Rev-Trac, transports are migrated to the systems and clients defined in a target group.
A target group consists of one or more clients in one or more systems. Within each target group,
different destinations may be defined to receive client-dependent and client-independent changes.
A target group might, for example, include several different clients in a QAS system, plus one or two
clients in DEV to which changes will be "back flushed" whenever they are sent to QAS. In another
scenario, a target group might include only a single client in PRD for receiving both client-dependent
and client-independent changes.
Rev-Trac treats hybrid transports (transports containing both client-dependent and client-independent
changes) the same as client dependent transports. In a back flushing scenario, it is important to set
the Umodes correctly (i.e. 01 but do not include 2) in the target group to prevent overwriting of client
independent objects.
How to create a target group

1. From the Rev-Trac Console, go to menu path Configuration > Process > Migration.
The ‘Display View “Target groups”: Overview’ screen is displayed.
The ‘Change View “Target groups”: Overview’ screen is displayed.
3. You can choose either to:
• Create target group from scratch, OR
• Copy from an existing target group.

You may want to use this option to copy the destination clients and systems over to the
new target group and make changes.

How to create a target group from scratch

1. At the ‘Change View “Target groups”: Overview’ screen, select New Entries from the toolbar.
Field Value
Target grp Type the name of the target group. For example, E70_MAIN.
TG Status The field determines whether transports can be migrated to a

target group, and if so, via which method, manual migration or
auto-migration or both.
For more details on this field, press F1 (Help) to access the
online documentation.
For more information on migration methods, please read the
Rev-Trac 7 Advanced Guide to Migration document via Rev-
Trac support portal at www.xrsc.com.
Text Type the description of the target group. For example, Main
clients for E70.
Set Leave the field blank.

For more details on how to use this field, please read the
Preventing re-migration when replacing one target group
with another section in the Rev-Trac 7 Advanced Guide to
Migration document via Rev-Trac support portal at
www.xrsc.com.
3. Create a record for each target group required. For example:
• QAS (Migration of transports to the QA clients)
• PRD (Migration of transports to the Production clients)
5. Proceed to How to assign destinations to a target group section.
How to assign destinations to a target group

1. At the ‘Change View “Target groups”: Overview’ screen, select a target group and double-
click on Destinations from the Dialog Structure. The "Change View 'Destinations': Overview"
screen is displayed.

2. Click on New Entries from the toolbar and complete the following fields.
Field Value
ClDep Select X (Yes) if this destination is to receive client-dependent

changes.
Leave the field blank if this destination is to receive client-
independent changes.
Target Sys Type the destination system. For example, E70.
Cli Type 0 if ClDep field is blank.

Type the destination client if ClDep field is X. For example, 100.
You will need to create a record for each destination client in the
target system if ClDep field is X.
FTP Leave this field blank if the source and destination systems
share a common transport directory.
Select 1 if you want Rev-Trac to copy transport data files and
cofiles from the transport directory of the source system to the
transport directory of the target system before performing the
import, and not to copy the cofiles back to the transport directory
of the source system after the import.
Select 2 if you want Rev-Trac to behave the same as setting 1
above but you want Rev-Trac to copy the cofiles back to the
transport directory of the source system after the import.
Note: One effect of copying back the transport cofile after a
migration is to make an up-to-date summary of the transport
migration history available via standard SAP transactions in the
source system after the migration.
However, migrations to multiple destinations can only happen
sequentially instead of in parallel which can increase the total
migration time.
Umodes If this field is blank, Rev-Trac performs imports with Umodes 01

by default.
If you want to use a particular Umodes for a destination, enter a
value i.e. 016.
In a back flushing scenario, it is important to set the Umodes
correctly (i.e. 01 but do not include 2) to prevent overwriting of
client independent objects.
Note: If you type any value in this field, the default Umodes 01
no longer applies, and all imports to this destination are
performed using the current Umodes. If you want to use Umodes
01 again, enter the value again.
For more information on what different Umodes does, please
search
http://help.sap.com using the term ‘unconditional modes’.

Field Value
Chk Level Leave this field blank if this destination is usually available.
Select 9 if this destination is often unavailable i.e. a temporary
training system.
For more details, press F1 (Help) to access the online
documentation for this field. Also, for more explanation on the
effect of this option, please read the Making provision for
migration destinations that are sometimes unavailable
section in the Rev-Trac 7 Day-to-Day Administration Guide
Hold mode This field determines if an indefinite hold until date should be
set for all of transports sent to the Rev-Trac migration queue for
this destination.
Select 9 if you want Rev-Trac to send transports for this
destination to the Rev-Trac migration queue with a hold until
date 31 Dec 9999.
Rev-Trac will not migrate these items from the queue until their
hold until dates have been removed or changed using
transaction /RSC/MF09. For more details on how to change the
hold date, please refer to the How to set, change and remove
the ‘hold until’ date section in the Rev-Trac 7 Advanced
Guide to Migration document via Rev-Trac support portal at
www.xrsc.com.
This field takes no effect and does not delay migration when
transports are manually migrated to the target groups from the
Migration Workbench.
How to create a new target group by copying an existing target

group
1. Select the target group to be copied and select Copy As… from the toolbar.
The selected target group will appear in an entry screen allowing you to make appropriate
changes to the fields.
For example, change the Target grp and Target text fields.
2. Press Enter and the "Specify object to be copied" dialog is displayed.
3. Select copy all and an Information dialog displays the number of dependent entries copied.
4. Press Enter and make the necessary changes to the destination clients and systems.

Process assignments per Project and Request type

Process assignment is where you will tie in the strategy and organisation structure to a project/
request type combination, and define the appropriate migration methods and target groups for the
statuses defined in the strategy.
How to access the configuration area

1. From Rev-Trac Console, go to menu path Configuration > Process > Assign process.
The ‘Display View “Process assignment”: Overview’ screen is displayed.
2. Select a project and double-click on Assignments per project / request type from the Dialog
Structure.

The ‘Change View “Assignments per project / request type”: Overview’ screen is displayed.
How to assign a strategy and organisation structure

This section describes how to configure the approval process for a project/ request type combination
by assigning the appropriate Rev-Trac strategy and organisation structure.
1. At the ‘Change View “Assignments per project / request type”: Overview’ screen, select New
entries from the toolbar.

Fields Value
Req Type Select a predefined request type from the possible entries.
Org Struct Select a predefined organisation structure from the possible

entries.
Strategy Select a predefined strategy from the possible entries.
Requirement This field determines the request completion rule to be applied to

a request. Such rule can be created and the rule may specify, i.e.
certain request details fields to be completed before the status
can be approved.
• Leave the field blank if no rule is required.
• Select a predefined requirement from the possible entries.
For details on creating request completion rules, please refer to
the Rev-Trac 7 Advanced Guide to Request Completion,
Relationship and Cloning Rules document via Rev-Trac
support portal at www.xrsc.com.
Req Use This field determines if transports may be added to this type of
request.
Reject This field determines if the user is required to populate the Reject
checkbox status reason field when rejecting a Status.
Check the box if Reject reason is mandatory.
Uncheck the box if Reject reason is not mandatory.

checkbox Note:
When this approval process is no longer appropriate in the future,
check this field to deactivate it, rather than deleting the record, to
help to preserve data integrity of your configuration.

How to assign migration methods and target groups

Rev-Trac provides the following migration methods to determine the appropriate actions to be taken
upon a status approval.
Migration method Actions upon approval
0: No migration action No migration activity is carried out.
1: Release all related transports All unreleased transports will be released.
4: Manual migration Users are required to migrate transports manually. Rev-

Trac issues reminders about what needs to be moved,
and issues warnings if users try to approve a
subsequent status before the transports have been
migrated.
5: Queue all related transports Assuming all transports have been released, Rev-Trac
adds them to the Rev-Trac migration queue.
6: Release and queue all related Rev-Trac releases all unreleased transports and adds
transports them to the Rev-Trac migration queue.
Table 1-1: Rev-Trac migration methods
1. At the "Change View “Assignments per project / request type”: Overview’ screen, select the
request type and double-click on Migration method and target from the Dialog Structure.
The ‘Change View “Migration method and target”: Overview’ screen is displayed.
2. Select New entries from the toolbar and complete the following fields.
Field Value
Status Select a predefined status from the possible entries.

The statuses available for selection come from the strategy assigned
to this request type.
Mig This field is useful to specify separate migration targets for transports
Source attached to a request based on their source systems. This makes it
possible, for example, to send transports sourced from DEV to one
target, and transports sourced from DV2 to another target, following
approval of the same status.
Leave this field blank to trigger the same migration action for all
transports attached to a request, regardless of their source system.
Complete this field to trigger a migration action only for transports
from a specific source system. Select a source system from the
possible entries.
For more details on this field, press F1 (Help) to access the online
documentation.

Field Value
Mig This field determines what migration action to be performed when the
status has been approved.
Select a migration method from the possible entries.
For auto-migration process, select 5 or 6.
For information on migration methods available in Rev-Trac, see
Table 1-1 above.
Mig This field determines the destinations to which transports will be

target migrated or queued when the status is approved.
Select a predefined target group from the possible entries, OR,
Leave the field blank if transports from the specified Mig Source
system are not to be migrated at this status.
Configuring an auto-migration process

You can either manually migrate (if authorised) transports to their destinations or allow Rev-Trac to
migrate these transports using a two-step process known as 'auto-migration'.
In the first step, after a migration status of a request is approved, Rev-Trac adds the transports to its
own, internally maintained, migration queue. A migration status is a status, which on approval, triggers
migration activity such as releasing or queuing a transport, i.e. Approved for QAS and Approved for
PRD.
In the second step, the Rev-Trac batch migration utility migrates items in the queue to their
destinations via batch jobs.
To configure an auto-migration process:-
1. Select migration method 5 or 6 in the How to assign migration methods and target
groups step as described previously.
Using this method, Rev-Trac automatically adds the transports to the migration queue. When
transports are added to the queue, Rev-Trac raises an event /RSC/TRIGGER with
parameter IMPORT.
2. Define one or more batch jobs using Rev-Trac queue-processing program,
/RSC/MF_BATCH_MIGRATION_UTIL, to migrate the items in the queue to their
destinations.
The jobs may be created to run whenever items are added to the queue (event-driven) or at
fixed schedule. For information on how to set up batch jobs to process (migrate) items in the
migration queue, please read the Defining batch migration jobs section in the Rev-Trac 7
Advanced Guide to Migration document via Rev-Trac support portal at www.xrsc.com.

Advanced configurations
The following change control functions using the project/request type combination are not covered in
this guide. For details of these functions, please refer to the Rev-Trac 7 Advanced Guide to
Transport Management document available via Rev-Trac support portal at www.xrsc.com.
• Migration source restrictions
• To prevent users from adding transports from certain source systems to a Rev-Trac request.
• Bundling instructions
• To configure Rev-Trac to add contents of selected transports to a Rev-Trac request into a
newly created transport of copies (bundle) automatically, following an approval.
Implementing one-click approval

By default, users approving Rev-Trac requests are always prompted to type their SAP password at the
time of approval, as shown in Figure 4-1 below.
Figure 4-1: By default, approvers are prompted to type their SAP password
This facility allows users to approve Rev-Trac requests in a secure manner even via a colleague's
SAP session.
It is possible for users to approve requests in their own name without typing their SAP password,
provided they are logged onto SAP under the corresponding ID and the one-click approval feature has
been implemented in Rev-Trac. When this feature is implemented, users approving requests in their
own name simply click on the Sign button as shown in Figure 4-2 below.
Figure 4-2: When one-click approval is activated, approvers simply click on the Sign button

How to configure a one-click approval

1. From the Rev-Trac Console, select Configuration > Global > Advanced > Over-rides.
The ‘Display View “Over-rides”: Overview’ screen is displayed.
Field Value
Parameter Type ONE_CLICK_APPROVAL
Sub Type USER=*

Parameter 2
Value Type ON
Implementing two-component approval

For highly regulated environments such as the pharmaceutical industry, it is mandatory for users
approving requests to enter their SAP User ID and password as shown in Figure 5-1 below. This can
be achieved by implementing the two-component approval feature.
Figure 5-1: When two-component approval is activated, approvers must enter their SAP user ID and password
How to configure two-component approval

1. From the Rev-Trac Console, select Configuration > Global > Advanced > Over-rides.
The ‘Display View “Over-rides”: Overview’ screen is displayed.

Field Value
Parameter Type TWO_COMPONENT_APPROVAL
Sub Type USER=*

Parameter 2
Value Type ON

Rev-Trac 7 Basic Configuration Guide 1.02

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Rev-Trac 7 Basic Configuration Guide 1.02

Загружено:

Авторское право:

Доступные форматы

Basic Configuration Guide

Document version: 1.02

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

Advanced administrator guides........................................................................................................................... 1

Overview of Rev-Trac ............................................................................................................................................ 2

Configuring basic change management processes .......................................................................................... 3

Rev-Trac Projects .................................................................................................................................................. 5

Rev-Trac Request types ....................................................................................................................................... 6

Rev-Trac Organisation structures ....................................................................................................................... 7

Rev-Trac Strategies .............................................................................................................................................. 12

Rev-Trac Target groups ....................................................................................................................................... 29

Document version: 1.02 Page ii

How to create a new target group by copying an existing target group....................................................................... 32

Process assignments per Project and Request type ....................................................................................... 33

Implementing one-click approval ....................................................................................................................... 37

Implementing two-component approval ............................................................................................................ 38

Document version: 1.02 Page iii

Advanced administrator guides

Document version: 1.02 Page 1

Document version: 1.02 Page 2

Configuring basic change management processes

3. Create strategies to define approval processes consisting appropriate statuses, approval

Document version: 1.02 Page 3

Basic Rev-Trac change management

Configure Create users

Create statuses Assign status paths

Assign strategy and

Document version: 1.02 Page 4

2. Switch to Change mode and press Enter.

Project Name of the project. For example, PROD_SUP.

Text Description of the project. For example, Production support.

Deact Leave this field blank.

4. Save your changes.

Document version: 1.02 Page 5

5. Press Enter and the ‘Specify object to be copied’ dialog is displayed.

7. Press Enter and save your changes.

12. Press Enter and save your changes.

Rev-Trac Request types

Document version: 1.02 Page 6

How to create a request type

Deact Leave this field blank.

• DEV (ABAP/4 development)

• SAPS (SAP security)

• OSSNOTE (Apply OSS note)

5. Save your changes.

Rev-Trac Organisation structures

3. Define the organisation structure.

Document version: 1.02 Page 7

How to create a user

4. Complete the following fields for each Rev-Trac user.

Deact This field determines if the user is allowed to approve a Rev-Trac

UserType This field determines if the user is subject to system-wide

Email address Type the user’s email address.

5. Save your changes.

Document version: 1.02 Page 8

How to create a team

2. Double-click on Teams from the Dialog Structure.

6. Complete the following fields.

Text Enter a description of the team. For example, ABAP

Deact Leave this field blank.

• CONF (Configuration team)

• BASIS (Basis team)

Document version: 1.02 Page 9

How to create a position