Rev-Trac_5_0_Administrator_Guide2

Rev-Trac Administrator Guide

Version 5.0 DC 08

May 2006

Rev-Trac Administrator Guide V5.0 DC08


Copyright © 1998, 2006 Revelation Software Concepts Pty Ltd. All rights reserved.

Document version: 1.00

ii


Table of Contents Before you begin ......................................................................................................................... 1

Rev-Trac 101: Introduction to configuring change management processes........................ 3 Technical pre-requisites ................................................................................................................ 3 Preparing for the tutorials .............................................................................................................. 4

Loading the tutorial configuration ............................................................................................. 4 Configuring SID-specific details ............................................................................................... 5

Defining tutorial system as a single, stand-alone master.................................................... 5 Defining tutorial system as migration target ........................................................................ 6

Tutorial 1: Creating and approving a demonstration Rev-Trac request ........................................ 8 Creating a demonstration request ............................................................................................ 8 Displaying the demonstration request on the Rev-Trac Workbench........................................ 9 Adding a transport to your demonstration request ................................................................. 10 Rev-Trac Workbench view of added transport ....................................................................... 12 Approving a migration............................................................................................................. 13

Tutorial 2: Understanding the configuration behind the demonstration request ......................... 16 Understanding how the statuses a request will pass through are defined............................. 16 Understanding how request approvers are defined ............................................................... 18

Role of strategy in determining who can give an approval ............................................... 19 Role of organisation in determining who can give an approval......................................... 20

Understanding how automatic migration behaviour is defined............................................... 23 Understanding how autoapproval is defined .......................................................................... 25

Tutorial 3: Creating and using your own project.......................................................................... 28 Creating a new project by copying an existing project's configuration................................... 28 Removing unwanted request types from a project................................................................. 28 Using your new project ........................................................................................................... 30

Tutorial 4: Creating and applying your own strategy ................................................................... 32 Creating a new strategy by copying an existing strategy ....................................................... 32 Adding statuses to new strategy ............................................................................................ 32

Creating statuses SPEC and D-TS ................................................................................... 33 Adding new statuses to your new strategy........................................................................ 33 Defining approvers for your new statuses......................................................................... 35

Assigning new strategy to existing request type in your project............................................. 37 Test driving the new strategy ................................................................................................. 38

Tutorial 5: Extending your organisation....................................................................................... 40 Adding users........................................................................................................................... 40 Creating a team and position ................................................................................................. 41 Adding users to your organisation structure........................................................................... 42 Displaying your organisation .................................................................................................. 43

Tutorial 6: Further common adjustments..................................................................................... 44 Creating and using new request type..................................................................................... 44 Creating and using a new target group with request type XAPP ........................................... 45

Putting the new target group to use .................................................................................. 46 Requiring an additional signature........................................................................................... 47

How many signatures are required for a status? .............................................................. 47 Requiring two signatures for status SPEC in strategy TUTSTR_2................................... 48

Creating a new approval type ....................................................................................... 48 Adding requirement for additional approval .................................................................. 49

Activating one-click approval .................................................................................................. 50 Defining statuses when no transports may be added to a request ........................................ 51 Making a field mandatory ....................................................................................................... 52 Reviewing your processes...................................................................................................... 53

iii


Inter-system communications.................................................................................................. 54 Terminology: landscape, master, slave and monitored system .................................................. 54 RFC destinations to support transport movement monitoring..................................................... 56

RFC destination name............................................................................................................ 56 RFC destination user.............................................................................................................. 56

RFC destinations to support transport release, and drilldown to transports and components.... 56 RFC destination name............................................................................................................ 57 RFC destination user.............................................................................................................. 57

RFC destinations to support activities on development system other than master .................... 58 RFC destination name............................................................................................................ 59 RFC destination user.............................................................................................................. 59

RFC destinations to support remote logon to Rev-Trac master from non-development systems........................................................................................................................................ 59

RFC destination name: remote logon..................................................................................... 60 RFC destination user: remote logon....................................................................................... 60 RFC destination name: password- and authorisation-checking............................................. 61 RFC destination user: password- and authorisation-checking............................................... 61

Migration..................................................................................................................................... 62 Rev-Trac Console migration summaries ..................................................................................... 64 Target groups .............................................................................................................................. 65

Defining target groups ............................................................................................................ 65 Making provision for systems that are sometimes unavailable.............................................. 67 Sent indicators........................................................................................................................ 68

Role of sent indicators in preventing inadvertent re-migration of transports..................... 69 Colour coding of sent indicators ........................................................................................ 69 Adding and removing sent indicators manually................................................................. 70

Preventing re-migration when replacing one target group with another ................................ 70 Automigration............................................................................................................................... 71 Autoapproval................................................................................................................................ 72

Configuring an autoapprover for a post-migration status ....................................................... 73 Reviewing migration configuration............................................................................................... 74 Rev-Trac migration queue ........................................................................................................... 75

Displaying the queue.............................................................................................................. 75 Understanding the queue display........................................................................................... 76

One transport: many queue items..................................................................................... 76 The queue in change mode............................................................................................... 77 Other factors affecting queue appearance........................................................................ 77

Controlling the queue sequence............................................................................................. 79 Dynamic queue sequence................................................................................................. 80 Changing the Rev-Trac migration queue .......................................................................... 83

Adding items to the queue ............................................................................................ 83 Displaying the Rev-Trac migration queue in change mode .......................................... 84 Deleting items from the queue ...................................................................................... 84 Changing the 'hold until' date ........................................................................................ 84 Changing the queue sequence ..................................................................................... 85 Freezing all or part of the queue ................................................................................... 86 Unfreezing the queue.................................................................................................... 87

Migrating items from the queue.............................................................................................. 88 Display of items currently being migrated ......................................................................... 88 Migration sequence ........................................................................................................... 88 Autoapproval of requests when using queued migration .................................................. 89 Migration job naming conventions..................................................................................... 89 Migration job user.............................................................................................................. 89

iv


Preventing contention between multiple instances of the same migration job ................. 89 What happens to items sent to queue while migration job is running? ............................. 90 Event /RSC/TRIGGER ...................................................................................................... 90 Scheduling queue migration jobs to run /RSC/MF_BATCH_MIGRATION_UTIL ............. 90

Rev-Trac Migration Workbench................................................................................................... 92 Populating the Workbench ..................................................................................................... 92

Populating Migration Workbench from filtered list of transports on Rev-Trac requests.... 92 Populating Migration Workbench from a text file............................................................... 93 Populating Migration Workbench from a transport list ...................................................... 94

Performing migrations from the Rev-Trac Migration Workbench........................................... 94 Migrating transports in the foreground .............................................................................. 94 Sending transports to the Rev-Trac migration queue ....................................................... 95

Creating a transport list using the Migration Workbench ....................................................... 95 Other migration tools ................................................................................................................... 96

Capturing and reading landscape snapshots......................................................................... 96 Adding or removing sent indicators ........................................................................................ 96 Quarantining transports .......................................................................................................... 97 Releasing transports............................................................................................................... 98 Uploading and downloading transports from PC.................................................................... 98 Archiving historical Rev-Trac migration queue data for performance improvement .............. 98 Removing special migration instructions ................................................................................ 98

Migration-related workflow........................................................................................................... 98 Technical insight into Rev-Trac migration ................................................................................... 99 Migration reports........................................................................................................................ 100

Reports ................................................................................................................................. 100 Propagation report........................................................................................................... 100 Chronological migration report ........................................................................................ 101 System/client comparison report ..................................................................................... 102 Plan vs reality report........................................................................................................ 103 Migration log.................................................................................................................... 104 Quarantined transports report ......................................................................................... 104

Using landscape snapshots and transport lists with migration reports ................................ 105

Accident prevention ................................................................................................................ 107 Overtake and Overwrite Protection System (OOPS) ................................................................ 107

What are overtaking and overwriting?.................................................................................. 107 Role of OOPS when migrating with tp or TMS..................................................................... 108 When does Rev-Trac perform an automatic OOPS check? ................................................ 108 Example screens and dialogs .............................................................................................. 109 Some table data automatically excluded from OOPS checking........................................... 110 OOPS pre-requisites ............................................................................................................ 110 Configuring OOPS................................................................................................................ 111

'OOPS' global parameter................................................................................................. 111 OOPS over-rides ............................................................................................................. 112 OOPS rules ..................................................................................................................... 113

Why am I getting this OOPS message?............................................................................... 114 'Overtake' of transport already migrated to target ........................................................... 114 'Will overwrite foreign'...................................................................................................... 114 'OOPS has not checked actual table entries' .................................................................. 116 Imp (import) date in OOPS report shows future date...................................................... 116

OOPS procedures ................................................................................................................ 117 How to perform a manual OOPS check .......................................................................... 117 How to perform a retrospective OOPS check ................................................................. 118 How to retrieve historical OOPS messages and action records ..................................... 119 How to quarantine a transport ......................................................................................... 120 How to suppress 'will overwrite foreign' warnings for specific foreign transports ........... 121

v


The Rev-Trac locking system .................................................................................................... 122Example screens and dialogs .............................................................................................. 123 Rev-Trac locks table data at table, not table key, level........................................................ 125 Rev-Trac locking of logical transport objects ....................................................................... 126 Rev-Trac locking system pre-requisites ............................................................................... 126 Configuring the Rev-Trac locking system............................................................................. 126

System-wide setting: the 'Lock' system parameter ......................................................... 127 Per status setting: the status 'Lock mode'....................................................................... 127 Rev-Trac locking system over-rides................................................................................ 128

Rev-Trac locking system procedures ................................................................................... 130 How to permit parallel development in another Rev-Trac request.................................. 130 How to rescind a parallel development permission granted in error ............................... 133 How to identify parallel development permissions granted, rescinded or currently active133 How to retrieve historical lock messages ........................................................................ 134 How to turn off locking for table data, while enforcing locks for workbench objects ....... 134

OOPS and Locking rules ........................................................................................................... 135 How to activate OOPS or lock checking for only a small number of tables or objects ........ 136 How to exclude a specific object or table data from OOPS or lock checking ...................... 136 About OOPS table- versus key-level checking .................................................................... 136 How to activate table-level OOPS checking......................................................................... 137 Which rule 'wins' if there is a conflict? .................................................................................. 137 Auditing of locking exclusions .............................................................................................. 138

Authorisation ........................................................................................................................... 139 Quick start guide: how to perform common authorisation tasks ............................................... 139 Overview of Rev-Trac authorisation model ............................................................................... 140 Preventing automatic inclusion of authorisations in customer namespace in SAP_ALL .......... 140 Reference data .......................................................................................................................... 142

Profiles.................................................................................................................................. 142 Authorisations per profile...................................................................................................... 143 Authorisation objects ............................................................................................................ 145

Y/RSC/CE02 (Field level)................................................................................................ 145 Y/RSC/CE03 (User privileges) ........................................................................................ 145 Y/RSC/CE04 (Tools / utilities) ......................................................................................... 146 Y/RSC/CE05 (Configuration)........................................................................................... 147 Y/RSC/CE06 (Delegation)............................................................................................... 148 Y/RSC/RM01 (Migration Workbench target groups) ....................................................... 149

References ............................................................................................................................... 150 Features common to all references ........................................................................................... 150

Reference type, ID, text and priority..................................................................................... 150 Basic validation..................................................................................................................... 151 Visibility on request details screen ....................................................................................... 152 Visibility on Rev-Trac Workbench ........................................................................................ 152 Dynamic linking of requests with a common reference........................................................ 153 Rev-Trac requests may be searched by reference .............................................................. 153 Rev-Trac Workbench may display requests by reference type and ID................................ 154 Controlling automatic display of "Reference index" dialog................................................... 154

Additional features available in smart references...................................................................... 154 Possible entries (F4) help..................................................................................................... 155 More powerful validation than for simple references............................................................ 155 Reference launching............................................................................................................. 156

Additional features available in dependency-checking references ........................................... 157 Example of single dependency check .................................................................................. 157 Example of multiple dependency checks ............................................................................. 158

vi


Procedures ................................................................................................................................ 160 Creating a reference type for simple references .................................................................. 160 Creating a reference type for smart references ................................................................... 161 Creating a reference type for dependency-checking references ......................................... 162 Defining actual dependency checks for a dependency-checking reference type ................ 162

Request completion rules....................................................................................................... 166 Defining request completion rules ............................................................................................. 166 Associating rules with a project / request type combination...................................................... 168 The rules in action ..................................................................................................................... 168

Appendices .............................................................................................................................. 170 Upgrading SAP: Steps required in Rev-Trac............................................................................. 170 Moving Rev-Trac master to another system ............................................................................. 171

Pre-requisites ....................................................................................................................... 171 SAP releases................................................................................................................... 171 Rev-Trac versions ........................................................................................................... 171 Transport creation freeze during move ........................................................................... 171 Internet email................................................................................................................... 171

Background: What is unique about the Rev-Trac master? .................................................. 171 What does a Rev-Trac data backup transport include? ....................................................... 173 Overview of procedure for moving a Rev-Trac master ........................................................ 173 Step 1: Install Rev-Trac software in new master.................................................................. 174

Do I need to install software?.......................................................................................... 174 Do I need to import the Rev-Trac BADI and field exits? ................................................. 175

Step 2: Block Rev-Trac activity in current master ................................................................ 175 Step 3: Extract data and settings from current master......................................................... 176 Step 4: Import or recreate data and settings in new master ................................................ 177 Step 5: Adjust and activate system-specific configuration in new master............................ 178 Step 6: Reschedule non-migration jobs and rebuild OOPS database in new master ......... 179 Step 7: Create new RFC destinations .................................................................................. 180 Step 8: Unlock new master .................................................................................................. 181 Importing or creating and activating Rev-Trac BADI............................................................ 181

Continuing development in other systems when Rev-Trac master is unavailable.................... 183 Preparing for a planned outage of the Rev-Trac master system ......................................... 183 Restoring enforcement settings in Rev-Trac master after planned outage.......................... 183 Allowing creation of new transports following unplanned outage of Rev-Trac master ........ 184

Deactivating Rev-Trac field exits and BADI .................................................................... 184 Reactivating Rev-Trac field exits and BADI ......................................................................... 185

Setting up request cloning ......................................................................................................... 186 Implementation overview...................................................................................................... 186 Differences between original request and its clone.............................................................. 186 Cloning options..................................................................................................................... 187 Implementing user exit /RSC/EI_CUSTOMER_EXIT_004 .................................................. 187 Sample customer exit code .................................................................................................. 187 Enabling the Rev-Trac status change customer exit............................................................ 189

Adding fields to the Request Details screen.............................................................................. 190 Adding a tab to the Rev-Trac Console screen .......................................................................... 191

Creating a subscreen for new tab ........................................................................................ 192 Creating a program of type 'module pool' ....................................................................... 192 Creating a subscreen within the module pool ................................................................. 192 Laying out the subscreen ................................................................................................ 192 Writing flow logic and ABAP code for the subscreen...................................................... 192

Entering over-rides to display new tab and (optionally) to suppress standard tabs............. 193

vii


Before you begin

This guide explains in detail how to configure Rev-Trac inter-system communications, and how to use and configure Rev-Trac's migration and accident prevention features.

Future editions of this guide will cover additional Rev-Trac features of interest to a Rev-Trac administrator.

The most recent version of this guide is available to registered support users of www.xrsc.com at any time for download. This guide is located in the Support > Download files > Guides area.

Intended audience

This guide is intended to be read by Rev-Trac administrators.

The document assumes that the reader is familiar with standard SAP migration techniques, and with creating and monitoring jobs

How this guide is organized

This guide is organised as follows:

Rev-Trac 101: Introduction to configuring change management processes

Structured as a sequence of tutorials, this chapter explains the basics of configuring your own change management processes in Rev-Trac by defining what steps each type of change will pass through, who may approve each change, and how changes will be migrated.

Inter-system communications

Describes what RFC destinations Rev-Trac requires.

Migration

Describes how to use Rev-Trac to migrate transports manually and automatically. Explains the difference between queued and non-queued migration in Rev-Trac, and how to manage the Rev-Trac migration queue. Explains how to create target groups that define migration destinations, and describes migration-related tools, including the Rev-Trac Migration Workbench, available in Rev-Trac. Introduces all Rev-Trac's migration reports.

Accident prevention

Describes in detail how to configure and fine-tune two mechanisms Rev-Trac provides that protect workbench objects and configuration data accidental damage:

•

•

Overtake and Overwrite Protection System (OOPS)

The Rev-Trac locking system

Authorisation

Contains quick procedures and detailed reference information to help you control who can do what in Rev-Trac via SAP authorisation.

Before you begin 1


References

Describes how to work with and create simple references to external information sources, as well as references that can be launched with a mouse-click, and references that can enforce inter-request dependencies such as "transports from that request must be in R/3 QAS before transports on this one are moved to BW QAS".

Appendices

Appendix items explain:

•

•

•

•

•

•

Steps to take in Rev-Trac before and after upgrading an SAP development system

How to move the Rev-Trac master to another system

How to continue development in other systems when the Rev-Trac master is unavailable

How to set up automatic cloning of Rev-Trac requests

How to add custom fields to the request details screen

How to add and remove tabs on the Rev-Trac Console screen

2 Before you begin


Rev-Trac 101: Introduction to configuring change management processes

Caution

This chapter assumes that you will be responsible for configuring your Rev-Trac installation, but have not yet begun to do so.

Please do not proceed with the tutorials in this chapter if you have already created Rev-Trac configuration settings that you wish to preserve, or if others are already using your Rev-Trac installation.

Using a tutorial format, this chapter explains how to configure basic change management processes in Rev-Trac.

In this chapter you will learn how to create and adjust configuration settings that determine:

•

•

•

•

•

•

•

What statuses (steps) Rev-Trac requests will pass through during their lifetime

Who can approve each status, and how many approvals are required

When and how migration will occur

Which change management processes are used for which requests

Before starting the tutorials, check that the technical pre-requisites listed below have been met, then perform the tasks described in Preparing for the tutorials on page 4

Technical pre-requisites

Although Rev-Trac is designed to manage changes in multiple systems, the tutorials in this chapter have been designed to work in a single, stand-alone system. This simplifies the set-up requirements for the tutorials. Furthermore, when migrations of harmless Rev-Trac demonstration table entries occur in the tutorials, they occur within the one system.

This chapter assumes that the following technical pre-requisites have been met for the tutorial system:

The Rev-Trac Mon Core, Mon Dev and profiles components have been successfully imported into the relevant clients

The RFC destinations required to monitor transport movements within a Rev-Trac master system and to support transport release within a Rev-Trac master system have been created in the tutorial system

For more detail on these destinations, see RFC destinations to support transport release, and drilldown to transports and components and RFC destinations to support transport movement monitoring starting on page 56.

Dialog user RSCADMIN exists in the main development client, and has the following profiles:

S_A.SYSTEM

A profile such as S_ABAP_ALL that contains authorisation object S_GUI with ACTVT = *

Rev-Trac 101: Introduction to configuring change management processes 3


•

•

•

•

•

•

•

Dialog user RSCLEARNER exists in the main development client, and has the following profiles:

S_A.SYSTEM

A profile such as S_ABAP_ALL that contains authorisation object S_GUI with ACTVT = *

Rev-Trac basic user profile Y:/RSC/USR01

The following Rev-Trac technical installation steps need NOT have occurred before you proceed through these tutorials:

Setup of communications to other systems

Loading of historical transport movement information

OOPS database build

Submission of standard Rev-Trac jobs

Preparing for the tutorials

Once the technical pre-requisites listed above have been met, you will need to perform the following tasks before beginning the tutorials:

Load the tutorial configuration

Enter some SID-specific configuration details

The following topics describe these tasks in more detail.

Loading the tutorial configuration

Caution: Do not proceed with this task if you have already begun to configure your Rev-Trac installation.

The tutorials in this chapter assume that you have a defined set of configuration settings loaded into the tutorial system, and that no other configuration settings are present.

The required settings are contained in a file called RSC_TUTORIAL.txt that is supplied by Revelation Software Concepts with the Rev-Trac component transports.

To remove any existing configuration settings and replace these with the tutorial configuration, perform the following steps:

1. Logon to the main development client of the tutorial system as RSCADMIN.

2. Start transaction /RSC/RM22. The "RSC – Download /upload configuration” screen is displayed.

3. Complete the following fields:

Field Description

Upload Configuration (Presentation server)

Select.

Delete Existing and Add New Configuration Table Entries

Select.

4 Rev-Trac 101: Introduction to configuring change management processes


4. Execute the program. The "All Entries Confirmation" dialog is displayed.

5. Click the Yes button. A file selection dialog is displayed.

6. Select RSC_TUTORIAL.txt A list of tables and records uploaded is displayed.

Note: The SAP GUI may be unable to upload RSC_TUTORIAL.txt if the path to the file is too long. Ensure the total path, including the filename itself, is less than 128 characters

Configuring SID-specific details

The tutorials in this chapter assume that the tutorial system is configured as a single, stand-alone master system and that migrations are performed internally within the tutorial system only. (For an explanation of the term "master system", see Terminology: landscape, master, slave and monitored system on page 54.)

While this is not a realistic way of configuring Rev-Trac for practical use, it simplifies the configuration requirement for tutorial purposes, and allows you to learn how to configure a basic change management process in Rev-Trac using only a single SAP system.

Defining tutorial system as a single, stand-alone master

Perform the following steps:


2. Start transaction /RSC/CF20. The "Display View 'System names': Overview" screen is displayed. There are no system names displayed.

3. Select Table View > Display->Change to put the screen in change mode, then select Edit > New entries.


Field Description

Sys. Name SID of the tutorial system.

Text A brief description of this system. Example: R/3 development

5. Double-click System parameters. The "Change View 'System parameters': Overview" screen is displayed.

6. Select Edit > New entries, then complete the following fields:

Field Description

Sys. Name The SID you entered in step 4.

Landscape Select TUTORIAL.



Rep Type "1".

Func Select "1" (Rev-Trac master).

Enforce Leave this field blank.

Lock Leave this field blank.

Active Select "X" (Active)

7. Select Table view > Save.

8. Start transaction /RSC/CE14. The "RSC - Activate Changes (Parameter Export/Import)" screen is displayed.

9. Clear the Include Parameters list checkbox, then execute the program. Rev-Trac silently activates the configuration changes you have just made.

Defining tutorial system as migration target

The tutorial configuration you loaded in a previous step contains two empty target groups called TUTOR_QAS and TUTOR_PRD.

When configured for productive use, such target groups would normally comprise destinations in your actual QAS and PRD systems. (For a detailed discussion of the role of target groups and how to configure them, see Target groups on page 65.)

To ensure that any migration you perform while working through these tutorials occurs internally in the stand-alone tutorial system, you must configure target groups TUTOR_QAS and TUTOR_PRD to point to your tutorial system.

Do the following:


2. Start transaction /RSC/RT. The Rev-Trac Console is displayed.

3. Select Configuration > Process > Migration. The "Display View 'Target Groups': Overview" screen is displayed.

Figure 1-1: These target groups are displayed when the user completes step 3 above



4. Select Table view > Display->Change to put the screen in change mode.

5. Select TUT_QAS, then double-click Destinations. The "Change View 'Destinations': Overview" screen is displayed.

6. Select Edit > New entries, then complete the following fields for one row:

Field Description

ClDep Leave this field blank.

Target Sys SID of tutorial system.

Cli Main development client in tutorial system.

Umodes Type "012".

7. Complete a second row with the following values:

Field Description

ClDep Select "X" (Yes).

Target Sys SID of tutorial system.

Cli Select client in tutorial system to which you will migrate harmless Rev-Trac configuration data for tutorial purposes.

Umodes Leave this field blank.

Figure 1-2: Example of destinations for target group TUT_QAS when tutorial system is A50.

8. Double-click Target groups. Select TUT_PRD, then double-click Destinations. The "Change View 'Destinations': Overview" screen is displayed.

9. Repeat steps 6 and 7, typing exactly the same values.




Tutorial 1: Creating and approving a demonstration Rev-Trac request

In this tutorial, you will create a Rev-Trac request and add a harmless demonstration transport to it. You will then approve the request into a status that will cause Rev-Trac to migrate the demonstration transport automatically in the foreground.

In the subsequent tutorial, you will examine some of the Rev-Trac configuration settings that control the behaviour of this request.

Creating a demonstration request

To create a demonstration Rev-Trac request, complete the following steps:

1. Logon to the main development client of the tutorial system as RSCLEARNER and start transaction /RSC/RT. The Rev-Trac Console is displayed.

2. Click the Create request button. The "Create request details" screen is displayed.

Figure 1-3: Complete these fields to create your first Rev-Trac request



3. Complete fields on the screen as shown in Figure 1-3 above, then select Request > Save. An Information dialog indicates that Rev-Trac has sent workflow messages to several users.

4. Click the Continue (green tick) button to close the dialog. The Rev-Trac Console is displayed. The number of the Rev-Trac request you just created appears in the Request field. Take a note of this number, as you will need it for the next task.

Displaying the demonstration request on the Rev-Trac Workbench

There are two main ways to display information about a Rev-Trac request.

The request details screen (shown in Figure 1-3 above) contains request "header" information.

The Rev-Trac Workbench presents another view. To display this view, do the following:

1. While logged onto the main development client of the tutorial system as RSCLEARNER, display the Rev-Trac Console.

Note: The transaction code for the Rev-Trac Console is /RSC/RT. From now onwards, we will assume you know how to display this screen.

2. In the Request field, type the number of the demonstration Rev-Trac request you created in the previous topic, then click the icon to the right of the Request field (see Figure 1-4 below).

Figure 1-4: User is about to display request 42 on the Rev-Trac Workbench

The request is displayed on the Rev-Trac Workbench.



3. Select the request by clicking its number once, then select Edit > Expand all. Every node of your demonstration request is expanded (see Figure 1-5 below).

Note: If the request details screen is displayed, you double-clicked the request number instead of clicking it once. Click the Cancel (red cross) button to return to the Rev-Trac Workbench and try again.

Figure 1-5: Expanding nodes of demonstration request shows the approvals that will be required during its lifetime

So far, the Rev-Trac Workbench view of this request is relatively simple.

The nodes labelled "In progress", "Migrate to QAS" etc are the statuses this request will pass through during its lifetime. In the next tutorial you will see how these are configured.

The subnodes "ABAP/4", "Functional", "Technical" and so on represent the types of approval that are required for each status.

Most statuses require only one type of approval, and hence only one signature. However the status "Migrate to PRD" will require two approvals.

Adding a transport to your demonstration request

You will now add a customising transport to your first Rev-Trac request, using a function in Rev-Trac that creates innocuous transports that contain table entries for Rev-Trac table /RSC/T_DEMO_CUST. These transports can be safely migrated to any system where Rev-Trac is installed. Rev-Trac does not read these table entries other than for demonstration purposes.



Do the following:

1. While logged onto the main development client of the tutorial system as RSCLEARNER, display the Rev-Trac Console, then select Configuration > Check configuration > Create test data > Customising transport. The "Change View 'Demo CUST Transports': Overview" screen is displayed.

2. Select Edit > New entries, then complete the following fields for a single row:

Field Description

Date Select any date.

Time Select any time.

Char 20 Type any text.

Char 20 Type any text.

3. Select Table View > Save. The standard SAP "Prompt for Customizing request" dialog is displayed (see Figure 1-6 below).

Figure 1-6: This standard SAP prompt is displayed when you save a customising change

4. Click the Create request button. The "Rev-Trac - Add a customising transport to a request" dialog is displayed (see Figure 1-7 below).

Note: If this dialog is not displayed, check the UserType setting for RSCLEARNER via Rev-Trac Console > Configuration > Process > Organisations > Users. This setting should be "2" (Training user).



Figure 1-7: This dialog is also known as the "Rev-Trac enforcement popup"

5. In the open field, select the number of the Rev-Trac request you created previously, then click the Generate the transport from Rev-Trac request number button. The "Automatic status change" dialog is displayed to indicate that this action will cause the status of the Rev-Trac request to change.

6. Click the Continue button. The number and text of the new transport are displayed on the "Prompt for Customizing request" dialog.

7. Click the Continue button. The change is saved to the transport.

Rev-Trac Workbench view of added transport

Adding a transport to a Rev-Trac request changes the display of the request on the Rev-Trac Workbench.

To see how, display your demonstration request on the Rev-Trac Workbench now. (If you're not sure how to do this, see Displaying the demonstration request on the Rev-Trac Workbench on page 9.) After expanding several nodes, you should see a display similar to that below:

Figure 1-8: Rev-Trac Workbench view of demonstration request after adding a transport



As a result of adding a transport to the request, the status of the request − displayed alongside the request number − has changed from NEW to D-IP (In progress).

Rev-Trac now shows details of the transport you added to this request (including its type and client), and details of the transport's components (for more details of these, expand the Components node.)

There have also been some changes under the Approvals node. In particular, a message indicates that user "Rev-Trac learner" added a transport, and shows when this occurred.

Approving a migration

Your last task in this tutorial is to approve the Rev-Trac request you created into a status that causes Rev-Trac to release and migrate the transport linked to this request.

When you give your approval, Rev-Trac will migrate your configuration change to a target group called TUT_QAS.

For demonstration purposes, you have configured this target group so that it actually points to the main development client in your tutorial system (see Defining tutorial system as migration target on page 6). While the net effect of this migration will be nil, the steps you will take here are the same as you would perform when migrating changes to another client or system in a productive Rev-Trac installation.

To approve your demonstration request into a status that will trigger a migration, do the following:

1. While logged onto the main development client of the tutorial system as RSCLEARNER, display the demonstration request to which a transport has been added on the Rev-Trac Workbench.

2. Expand the "Approvals" node and "Migrate to QAS" node so your screen looks similar to Figure 1-8 above.

3. Click the "Functional" node beneath "Migrate to QAS". The "Please select the appropriate signatory" dialog is displayed, indicating what migration will occur (see Figure 1-9 below).

Figure 1-9: Before approving a request, user clicks his or her name here



4. Click one of the lines where the name "Rev-Trac learner" appears. The "Sign a document" screen is displayed, and the request header details are visible.

5. Type the SAP password of user RSCLEARNER in the open Signed field, then click the Sign button. An Information dialog is displayed indicating this request is now in status "Migrate to QAS".

6. Click the Continue (green tick) button on the Information dialog. The status bar of the "Sign a document" screen is updated with messages indicating that the transport attached to this request is being released and migrated. When the migration is complete (this may take a minute or two), the "Migration Workbench" dialog is displayed, and the Information dialog now indicates that the request is in status "In QAS".

7. Click the Continue button on the Information dialog. An Information dialog indicates that Rev-Trac has sent workflow messages to several users.

8. Click the Continue button on the Information dialog. The Information dialog is closed, and you can now see the "Migration Workbench" dialog clearly (see Figure 1-10 below).

Figure 1-10: "Migration Workbench" dialog after successfully migrating a single transport



9. Click the Cancel (red cross) button. The request is displayed on the Rev-Trac Workbench.

10. Fully expand the "Transports" node and both green approval nodes so the screen appears as in Figure 1-11 below.

Figure 1-11: Rev-Trac Workbench view of request after successful migration of a single transport

Several significant changes have occurred to the request.

First, a green "sent indicator" has been added to the transport to flag that this transport has been sent to target group TUT_QAS and will not need to be sent again. Rev-Trac will not automatically resend this transport to this target group while this indicator is present. (For more details, see Sent indicators on page 68.)

Second, the request has received two approvals.

The first was the approval you gave when you typed in your SAP signature. As a result of that approval, the request entered the status "Migrate to QAS".

Rev-Trac itself approved the request into the status "In QAS" soon afterwards using the name AUTOMIG, after the migration of this transport succeeded. This Rev-Trac feature is known as "autoapproval".

In the above example, you migrated a change using foreground migration. While this migration method is the easiest to set up and demonstrate, background migration is usually a better option for productive use of Rev-Trac. For more information, see Migration on page 62.



Tutorial 2: Understanding the configuration behind the demonstration request

In this tutorial, you will examine the Rev-Trac configuration settings that determine:

•

•

•

•

What statuses a Rev-Trac request passes through in its lifetime

Who can approve each status

When, where and how Rev-Trac automatically migrates transports associated with a request

Whether Rev-Trac automatically approves a post-migration status such as "In QAS"

Understanding how the statuses a request will pass through are defined

A Rev-Trac request's project and request type determine what strategy will be used to manage that request.

The strategy, in turn, determines what statuses (steps) the request will pass through.

The demonstration request that you created in the previous tutorial:

•

•

Belonged to a Rev-Trac project called TUT

Had a request type of CUST (Customisation)

You set these properties when you completed the "Create request details" screen (see Figure 1-3 on page 8).

The configuration area that associates a project and request type with a strategy is shown in Figure 1-12 below.

To display this configuration area from the Rev-Trac Console, select Configuration > Process > Assign process. When the "Display View 'Process assignment': Overview" screen is displayed, select TUT, then double-click Assignments per project / request type.

The arrow in Figure 1-12 points to the setting we are interested in here.

Figure 1-12: This configuration area defines what set of statuses each project / request type combination will pass through



The effect of the setting pointed to by the arrow is to cause Rev-Trac to use the strategy called TUTSTR for all requests of type CUST in project TUT.

So what does the TUTSTR strategy look like? To display this strategy, do the following:

1. From the Rev-Trac Console, select Configuration > Process > Strategies. The "Display View 'Statuses': Overview" screen is displayed.

2. Double-click Strategies. The "Display View "Strategies': Overview" screen is displayed.

3. Select TUTSTR, then double-click Status path. The "Display View "Status path": Overview" screen is displayed (see Figure 1-13 below).

Figure 1-13: Status path for strategy TUTSTR

The statuses that appear in the status path for the TUTSTR strategy in Figure 1-13 correspond to the statuses you saw on the Rev-Trac Workbench for your demonstration request (see Figure 1-14 below). This is because the status path for the strategy determines what steps all requests using this strategy will pass through.



Figure 1-14: Statuses for demonstration request correspond to status path for the associated strategy, as seen in Figure 1-13

The only status in the status path for strategy TUTSTR that does not appear on the Rev-Trac Workbench is "New". This status does not appear on the Workbench because the request is already in this status, and does not require approval to move into this status.

Understanding how request approvers are defined

As well as determining what statuses a request will pass through, a strategy also helps to determine who may approve each status.

When you approved your demonstration request into the status "Migrate to QAS" in the previous tutorial, Rev-Trac displayed a dialog similar to the following:

Figure 1-15: These users can approve request into status "Migrate to QAS"



To determine what users should appear on this list, Rev-Trac reads two groups of configuration settings:

Settings associated with the organisation used for this request •

Settings associated with the strategy used for this request •

Figure 1-16 shows the configuration area where both an organisation (left arrow) and a strategy (right arrow) have been assigned to request type CUST within project TUT.

Figure 1-16: The organisation and strategy assigned to a request type within a project jointly determine who can approve each status

Role of strategy in determining who can give an approval

To see what role strategy TUTSTR plays in determining who may approver the status "Migrate to QAS" for your demonstration request, do the following:

1. From the Rev-Trac Console, select Configuration > Process > Strategies. The "Display View 'Statuses': Overview" screen is displayed.

2. Double-click Strategies. The "Display View "Strategies': Overview" screen is displayed.

3. Select TUTSTR, then double-click Status path. The "Display View "Status path": Overview" screen is displayed.

4. Select the row corresponding to status "Migrate to QAS", then double-click Approvers & WF message recipients. The "Display View 'Approvers & WF message recipients': Overview" screen is displayed (see Figure 1-17 below).



Figure 1-17: Approvers for status D-QMIG "Migrate to QAS" in strategy TUTSTR

The configuration settings shown here help to determine who may approve status "Migrate to QAS" for all Rev-Trac requests that use this strategy.

These settings indicate the following:

• Only one signature will be required to approve this status − because only one App type (Approval type) is listed

The number of approvals required for any status always matches the number of different approval types defined in this area.

•

•

The type of approval to be given is FUNC (Functional)

Any of the following people could give this approval:

Anyone who holds the position of DMAN (Development manager) in the MANG (Management) team, or

Anyone who holds the position of MEMB (Member) in the Management team

What is not clear from these settings is who actually holds these positions in these teams.

For that information, you need to look at the organisation used for this request type in this project. As you can see from Figure 1-16 on page 19, this is an organisation called TUTORG.

Role of organisation in determining who can give an approval

A Rev-Trac organisation is a map that shows what Rev-Trac users hold what positions in what teams.

You initially define all of these elements separately in Rev-Trac, then map them in an organisation.

To review how these elements are defined in the tutorial configuration, and to see how these are related in the TUTORG organisation, do the following:

From the Rev-Trac Console, select Configuration > Process > Organisations. The "Display View 'Users': Overview" screen is displayed (see Figure 1-18 below).



Figure 1-18: Rev-Trac users, their types and their email address details, are defined here

Only SAP users listed in this configuration area may create Rev-Trac requests. The values in the UserType and AdminAuth columns help to determine what privileges each user has, which are not determined solely by their SAP security settings. Rev-Trac sends workflow messages for users to the email addresses entered in the rightmost part of this screen (not visible in this screenshot).

Double-click Teams. The "Display View 'Teams': Overview" screen is displayed (see Figure 1-19 below).

Figure 1-19: Your teams are defined here

The teams defined here represent parts of your organisation.

The teams * (asterisk) and <TM> are special built-in teams required internally by Rev-Trac, and should not be deleted. You can add or remove other teams as you see fit.

Now double-click Positions. The "Display View 'Positions': Overview" screen is displayed (see Figure 1-20 below).



Figure 1-20: You define your organisation's positions here. Positions matching the pattern <XX> are special built-in positions required by Rev-Trac.

For the purpose of approving Rev-Trac requests, users in your organisation are defined as holding a position within a team. This area is where you define what positions are available.

The positions <AM>, <NO>, <OW> and <PG> are special built-in positions required internally by Rev-Trac, and should not be deleted. However, you can add or remove other positions.

Now double-click Organisation names. The "Display View 'Organisation names': Overview" screen is displayed. Select TUTORG, then double-click Organisation structure. The "Display View 'Organisation structure': Overview" screen is displayed (see Figure 1-21 below).

Figure 1-21: A Rev-Trac organisation places users in positions within teams



An organisation structure brings together all the elements you have just been examining. It maps what users hold what positions in what teams.

The main purpose of these settings is to help Rev-Trac to determine who may give particular approvals for requests, in conjunction with status-specific strategy settings such as those shown in Figure 1-17 on page 20.

You saw in Figure 1-17 that the Rev-Trac users who hold the positions of DMAN (Development manager) and MEMB (Member) in the Management team are eligible to approve the status "Migrate to QAS" for the demonstration request.

The configuration settings for the relevant organisation as shown in Figure 1-21 above allow Rev-Trac to determine exactly who these users are.

A further point worth noting here is the use of "standins". A user who holds a position in a "standin" capacity would be expected to approve a request only if regular holders of that position were unable to do so − for example, because they were absent from work.

As user RSCLEARNER, you were able to approve the status "Migrate to QAS" in the previous tutorial only because RSCLEARNER is defined in the organisation structure as a standin for both the DMAN and MEMB positions in team MANG.

Understanding how automatic migration behaviour is defined

When you prepared to approve the status "Migrate to QAS" for the demonstration request, Rev-Trac displayed a dialog indicating that this approval would cause Rev-Trac to migrate transports for this request to the destination defined in target group TUT_QAS (see Figure 1-9 on page 13).

Rev-Trac subsequently migrated the demonstration transport to this destination.

You have already seen how to define the systems and clients that make up a target group (see Defining tutorial system as migration target on page 6).

So what configuration settings define when a migration will occur?

You have seen that the status path for the strategy used with the demonstration request contains statuses "D-QMIG" (Migrate to QAS) and "Q-PMIG" (Migrate to PRD). Although the names of these statuses suggest that migration activity will occur when these statuses have been approved (see Figure 1-22 below), these statuses do not in themselves cause migration to occur.



Figure 1-22: Statuses D-QMIG and Q-PMIG in this status path imply migration will occur after these approvals have been given - but do not in themselves trigger migration

The configuration settings that actually cause the migration to occur are part of the "process assignment" configuration area.

To display the relevant settings for the demonstration request, do the following:

1. From the Rev-Trac Console, select Configuration > Process > Assign process. The "Display View 'Process assignment': Overview" screen is displayed.

2. Select TUT, then double-click Assignments per project / request type. The "Display View "Assignments per project / request type": Overview" screen is displayed (see Figure 1-23 below).

Figure 1-23: Drilling down to Migration method and target for request type in strategy



3. Select CUST, then double-click Migration method and target. The "Display View 'Migration method and target': Overview" screen is displayed (see Figure 1-24 below).

Figure 1-24: These settings determine the migration destination and method for the demonstration Rev-Trac request

The settings in Figure 1-24 above determine:

•

•

To what target groups Rev-Trac will migrate transports on the demonstration request when it is approved into the statuses D-QMIG and Q-PMIG respectively (see settings in Mig target column)

What migration method will be used for these migrations (see settings in Mig column)

When the setting in the Mig column is "3", Rev-Trac releases all transports associated with this request, then performs the migration in the foreground while the user waits for it to complete. This is the easiest migration method to use for your first learning experiences with Rev-Trac.

For a listing of ALL migration methods available in Rev-Trac, see Table 3-2 on page 71.

You can create and define target groups by selecting Configuration > Process > Migration from the Rev-Trac Console.

Understanding how autoapproval is defined

After you approved the demonstration request into the status "Migrate to QAS", Rev-Trac successfully migrated the transport and then automatically signed the next status of the request to indicate the change was now "In QAS".

On the Rev-Trac Workbench, the approver of status "In QAS" was listed as AUTOMIG (see Figure 1-25 below).



Figure 1-25: An example of autoapproval: Rev-Trac itself has approved the "In QAS" status

This behaviour is known as "autoapproval".

Autoapproval needs to be configured explicitly. To see an example of how, display the status path for strategy TUTSTR again (as described on page 17), select status Q-IN (In QAS), then double-click Approvers & WF message recipients. The "Display View 'Approvers & WF message recipients': Overview" screen is displayed (see Figure 1-26 below).

Figure 1-26: Example of how autoapproval is configured

Because only one type of approval (TECH) is configured for this status, only one signature is required for this status.

This signature can be give by any of the following:

•

•

•

Rev-Trac itself (Position = <AM>)

Any member of the Management team

Any member of the Technical team

Assuming Rev-Trac is configured to perform an automatic migration when the status before this one is approved (and it is), Rev-Trac will



automatically check the result of the migration and approve this status if the migration succeeds.

If the automatic migration does not succeed, technical staff can investigate the problem. If it becomes clear that the migration has actually succeeded despite a bad migration return code, 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 sign the request into status Q-IN manually.

For a more detail discussion of this feature, see Autoapproval on page 72.



Tutorial 3: Creating and using your own project

In this tutorial, you will copy project TUT − used for the demonstration request you created in Tutorial 1: Creating and approving a demonstration Rev-Trac request − to create a new project called TUT_2.

While assigning work to different projects allows you to report separately on different grouping of work, this is not the main purpose of Rev-Trac projects.

As you will see in this and later tutorials, many aspects of Rev-Trac configuration are project-specific. Assigning work to different projects therefore allows you to manage different types of work using different processes.

Although you will perform some minor customisation of project TUT_2 in this tutorial (by removing unwanted request types), requests created in project TUT_2 will initially behave similarly to requests created in project TUT.

However, in later tutorials, you will make further configuration changes that will substantially modify the behaviour of requests created in your new project.

Creating a new project by copying an existing project's configuration

To create project TUT_2 as a copy of project TUT, follow these steps:

1. As user RSCADMIN, display the Rev-Trac Console.

2. Select Configuration > Process > Assign process. The "Display View 'Process assignment': Overview" screen is displayed.

3. Select Table View > Display -> Change to put the screen into change mode.

4. Select project TUT, then select Edit > Copy As... The colour of the selected item changes.

5. In the Project column, change TUT to TUT_2. In the Text column at right, change "Tutorial project" to "Tutorial project 2"

6. Click the Copy (green tick) button on the toolbar. The "Specify object to be copied" dialog is displayed.

7. Click the copy all button on the dialog. An Information dialog displays the number of dependent entries copied.

8. Click the Continue (green tick) button on the dialog to close it, then select Table View > Save.

Removing unwanted request types from a project

Users may create only certain types of Rev-Trac requests within each project.

The list of available requests is part of the project's configuration.

Because project TUT_2 was created as a copy of project TUT, the list of available request types is initially identical for each project.



Figure 1-27 below shows the dropdown lists of available request types within project TUT and TUT_2 respectively, as displayed by a user in the act of creating a request in each project. As you can see, both dropdown lists are identical.

Figure 1-27: Request types available in project TUT (left) and TUT_2 (right) immediately after creating project TUT_2 as a copy of TUT.

You will now remove request types CONV (Conversions) and INTF (Interface) from project TUT_2. To do so, follow these steps:




4. Select project TUT_2, then double-click Assignments per project / request type. The "Change View 'Assignments per project / request type': Overview" screen is displayed.

5. Select CONV and INTF, then click the Delete button on the toolbar (see Figure 1-28 below). The "Specify objects to be deleted" dialog is displayed.



Figure 1-28: Deleting unwanted request types from project TUT_2

6. Click the all entries button.

An Information dialog displays the number of dependent entries deleted.


Using your new project

As either RSCLEARNER or RSCADMIN, create one or more Rev-Trac requests in project TUT_2. If you are unsure how to proceed, see Creating a demonstration request on page 8.

You should notice the following points:

•

•

When you create a request, the dropdown list of request types on the "Create request details" screen does not include request types CONV and INTF if you selected TUT_2 in the Project field.

This is because you have deleted these request types from the configuration for project TUT_2.

When you display a request that you created in project TUT_2 on the Rev-Trac Workbench, the Approvals subnodes are similar to what you have already seen from requests in project TUT (see Figure 1-29 below).

This is because request types in project TUT_2 are configured to use strategy TUTSTR (see Figure 1-28 above) − and this, in turn, determines what Approvals subnodes are displayed.



Figure 1-29: A new request created in project TUT_2 (right) requires similar approvals to a request created in project TUT (left)



Tutorial 4: Creating and applying your own strategy

In this tutorial, you will create a new strategy that includes some additional statuses to those used in TUTSTR.

You will define approvers for the new statuses in such a way that the actual approvers depend on details entered on the request details screen.

You will associate the new strategy with request type DEV (ABAP/4 Development) in project TUT_2. This will allow a different change management process to be applied requests of type DEV in project TUT_2 from other types of requests.

Creating a new strategy by copying an existing strategy

An easy way to create a new strategy is to copy an existing one and then modify the copy.

That is the approach you will take in this tutorial.

To create strategy TUTSTR_2 by copying strategy TUTSTR, do the following:


2. Select Configuration > Process > Strategies. The "Display View 'Statuses': Overview" screen is displayed.


4. Double-click Strategies. The "Change View 'Strategies': Overview" screen is displayed.

5. Select TUTSTR, then select Edit > Copy As... The colour of the selected item changes.

6. In the Strat column, change TUTSTR to TUTSTR_2. In the Text column, change "Tutorial strategy" to "Tutorial strategy 2".



9. Click the Continue (green tick) button on the dialog to close the dialog, then select Table View > Save.

Adding statuses to new strategy

You are now going to change strategy TUTSTR_2 by adding two further request statuses:

•

•

SPEC (Spec complete)

A user will approve this status to indicate that a specification has been completed and added to a request.

D-TS (Tested in DEV)

A user will approve this status to indicate that testing of a change in the development system has been completed.



Most request statuses in Rev-Trac are user-defined. To see what request statuses are currently defined in Rev-Trac (and thus available for use within a strategy), select Configuration > Process > Strategies from the Rev-Trac Console. The "Display View 'Statuses': Overview" screen is displayed (see Figure 1-30 below).

Figure 1-30: You can use any of the statuses listed on this screen in a strategy

As you can see, statuses SPEC and D-TS have not yet been defined. You will therefore need to create these statuses before you can add them to your new strategy.

Creating statuses SPEC and D-TS

To create these statuses, do the following:

1. As user RSCADMIN, display the "Display View 'Statuses': Overview" screen, as described above.


3. Select Edit > New Entries. The "New Entries: Overview of Added Entries" screen is displayed.

4. In the first row: Type "SPEC" in the Status column Type "Spec complete" in the Text column

5. In the second row: Type "D-TS" in the Status column Type "Tested in DEV" in the Text column

6. Select Table View > Save.

Adding new statuses to your new strategy

You will now add the statuses SPEC and D-TS to strategy TUTSTR_2.

Figure 1-31 below shows the status path for this strategy before the new statuses have been added.



Figure 1-31: Status path for strategy TUTSTR_2 before adding statuses SPEC and D-TS

You will place status SPEC immediately after NEW.

You will place status D-TS immediately after D-IP.

To make these changes, do the following:

1. As user RSCADMIN, select Configuration > Process > Strategies from the Rev-Trac Console. The "Display View 'Statuses': Overview" screen is displayed.

2. Select Table View > Display -> Change to put the screen in change mode.


4. Select TUTSTR_2, then double-click Status path. The "Change View 'Status path': Overview" screen is displayed (see Figure 1-31 above).

5. Select Edit > New entries. The "New Entries: Overview of added entries" screen is displayed.

6. In the first row: Type "150" in the Number column Select "SPEC" in the Status column Select "D-IP" in the TX Status column

Note: Whenever a transport is added to a request, Rev-Trac will automatically change the status of the request from the value in the Status column to the value in the TX Status column.

If the TX Status column is blank, no transport may be added to a request at this point in its lifecycle.

7. In the second row: Type "250" in the Number column Select "D-TS" in the Status column Select "D-IP" in the TX Status column



8. Select Table View > Save. An Information dialog reports that status SPEC has no approvers in this strategy.

9. Click the Continue button to close the dialog. A second dialog reports that status D-TS has no approvers in this strategy.

10. Click the Continue button to close the dialog. Your changes are saved

11. To view the new status path for this strategy, repeat steps 1 to 4. The status path is now as shown in Figure 1-32 below.

Figure 1-32: Status path for strategy TUTSTR_2 after adding statuses SPEC and D-TS.

As you can see, the values you entered in the Number column determine the position of the additional statuses in the overall status path sequence.

Defining approvers for your new statuses

Your next task is to define approvers for the statuses you have just added to strategy TUTSTR_2.

You will configure Rev-Trac so that:

•

•

The Team Leader of the request team can give Functional approval for status SPEC (Spec complete)

The request team is the team whose name appears in the Team field of the request details screen.

The request programmer can give Technical approval for the status D-TS (Tested in DEV).

The request programmer is the person whose ID appears in the Programmer field of the request details screen.







4. Select TUTSTR_2, then double-click Status path. The "Change View 'Status path': Overview" screen is displayed.

5. Select the row for status SPEC, then double-click Approvers & WF message recipients. The "Change View 'Approvers & WF message recipients': Overview" screen is displayed.

6. Select Edit > New entries to open the screen for input, then complete the following fields:

Field Description

App type This is the type of approval to be given for status SPEC. Select FUNC.

Team This is the team to which the approver belongs. Select <TM>. This is a runtime variable that Rev-Trac will populate at approval time with the name of the request team.

Position This is the position the approver holds. Select TL (Team leader).

WF Msg The value selected here determines if Rev-Trac will send workflow messages to this approver, and possibly also to his/her standins. Select "1" to send workflow messages prompting approval to the holder of this position, but not to standins.

7. Double-click Status path. Select the row for status D-TS, then double-click Approvers & WF message recipients. The "Change View 'Approvers & WF message recipients': Overview" screen is displayed.



8. Select Edit > New entries to open the screen for input, then complete the following fields:

Field Description

App type This is the type of approval to be given. Select TECH.

Team This is the team to which the approver belongs. Because this is irrelevant for the request programmer, select "*" (asterisk).

Position This is the position the approver holds. Select <PG>. This is a runtime variable that Rev-Trac will populate at approval time with the user whose name appears in the request Programmer field.

WF Msg Select "1".


Assigning new strategy to existing request type in your project

So far in this tutorial you have:

•

•

•

Created strategy TUTSTR_2 by copying strategy TUTSTR

Created two new statuses SPEC and D-TS

Added the new statuses to strategy TUTSTR_2 and defined approvers for these statuses

However, there is still no way of using this new strategy in Rev-Trac. To do so, you need to associate the strategy with one or more request types within a project.

You will now configure Rev-Trac so that requests of type DEV in project TUT_2 use strategy TUTSTR_2, while requests of type DEV in project TUT will continue to use strategy TUTSTR.

Do the following:





5. Change the Strat field for Req type DEV to TUTSTR_2 (see Figure 1-33 below).




Figure 1-33: Assigning strategy TUTSTR_2 for use with requests of type DEV in project TUT_2

Test driving the new strategy

To see your new strategy in action, create two requests of type DEV in project TUT_2, as shown in Figure 1-34 below.

Make sure that:

•

•

The first request is for the FI team, and specifies no Programmer

The second request is for the SD team, and specifies RSCLEARNER as the Programmer

Figure 1-34: Requests of type DEV in project TUT_2. Note different Team and Programmer entries.

Next, display these requests on the Rev-Trac Workbench (see Figure 1-35 below).



Figure 1-35: Rev-Trac Workbench view of requests shown in Figure 1-34

Note the following points:

•

•

•

The new statuses "Spec complete" and "Tested in DEV" are now present for both requests

A different approver is required to sign the status "Spec complete" for each request

Strategy TUTSTR_2 requires the team leader of the request team to approve this status. Because each request has a different value in the Team field, this is a different person in each case.

The text "No approvers found" is displayed for the "Tested in DEV" status for the request with the blank Programmer field

Strategy TUTSTR_2 requires the request programmer to approve this status. Because the Programmer field has not been completed for this request, Rev-Trac cannot determine an approver. Later, you will learn how to make this field (or any other field on the request details screen) mandatory. See Making a field mandatory on page 52.



Tutorial 5: Extending your organisation

In this tutorial you will add a new team to organisation TUTORG.

You will populate this team with three new Rev-Trac users, one of whom holds a new position that you will also need to create.

In the following tutorial, you will use this new team and position when defining who may approve a request status.

Adding users

Your first task is to create the following people as Rev-Trac users:

•

•

•

TUT_USER_AA (Axel Anderson)

TUT_USER_BB (Bonnie Bellingen)

TUT_USER_CC (Clarence Collins)

Assuming these users are created in SAP and have suitable authorisation profiles, completing this step will allow these users to create Rev-Trac requests. (See also Authorisation on page 139.)

To create these Rev-Trac users, do the following:


2. Select Configuration > Process > Organisations. The "Display View 'Users': Overview" screen is displayed.


4. Select Edit > New entries, then complete the following fields in the first row:

Field Description

User id SAP user ID of the user. Type "TUT_USER_AA"

Name of user User's name. Type "Axel Anderson".

UserType The value selected here determines whether or not this user is subject to system-wide settings that control whether a new transports must be associated with a Rev-Trac request. Leave this field blank. This will allow the system-wide settings to apply.

Ref user The SAP user (preferably, a reference type user) against which this user's Rev-Trac authorisation will be checked. Complete this field only if this user will be accessing Rev-Trac solely via the optional xPack add-on to Rev-Trac.

AdminAuth Together with the user's security profile, the value selected here helps to determine whether this user has special privileges to administer Rev-Trac. Leave this field blank. The user will not have special privileges to administer Rev-Trac.



Recip.type The value selected here determines how Rev-Trac will pass workflow messages to this user. To prevent the inadvertent sending of tutorial workflow messages, leave this field blank.

Email address To prevent the inadvertent sending of tutorial workflow messages, leave this field blank.

5. Complete the following fields in the second row:

Field Description

User id Type "TUT_USER_BB".

Name of user Type "Bonnie Bellingen".

6. Complete the following fields in the third row:

Field Description

User id Type "TUT_USER_CC".

Name of user Type "Clarence Collins".


Creating a team and position

User Axel Anderson actually holds the position of Content co-ordinator in his organisation's Training & Documentation team.

However, neither this team nor this position is yet defined in Rev-Trac.

Before you can add Axel Anderson to your organisation, you will need to create both the Training and Documentation team and the Content co-ordinator position.

To create these, do the following:




4. Double-click Teams. The "Change View 'Teams': Overview" screen is displayed.


Field Description

Team Type "T&D".

Text Type "Training & Doc".

6. Double-click Positions. The "Change View 'Positions': Overview" screen is displayed.




Field Description

Position Type "TUT_COCO".

Text Type "Content co-ordinator".

8. Select Table View > Save. Adding users to your organisation structure

You will now add the following users to your organisation:

•

•

•

Bonnie Bellingen (TUT_USER_BB) as the Team leader of the Training & Documentation team

Axel Anderson (TUT_USER_AA) as Content co-ordinator of the Training & Documentation team

Clarence Collins (TUT_USER_CC) as a Member of the Training & Documentation team

You will also add RSCLEARNER as a standin for each of these positions in the Training & Documentation team. This will allow RSCLEARNER to approve any requests that these users could sign in these capacities.

To add these users to your organisation structure, do the following:




4. Double-click Organisation names. The "Change View 'Organisation names': Overview" screen is displayed.

5. Select TUTORG, then double-click Organisation structure. The "Change View 'Organisation structure': Overview" screen is displayed.

6. Select Edit > New entries, then add entries as shown in Figure 1-36 below.

Figure 1-36: New entries for the TUTORG organisation structure



7. Click the Enter (green tick) button to display the names of the users you have added in the Name of user column.


Displaying your organisation

You can display the structure of your organisation(s) by selecting Configuration > Check configuration > Display organisations from the Rev-Trac Console.

The "Organisation structures" dialog is displayed.

You can then expand different nodes to see how your organisation is structured, as shown in Figure 1-37 below.

Figure 1-37: Graphic display of organisation structure, expanded to show the users recently added



Tutorial 6: Further common adjustments

Rev-Trac configuration rarely remains completely static.

In this tutorial, you will make some adjustments to your Rev-Trac configuration that are typical of the changes you may be required to make from time to time in a real Rev-Trac installation.

In this tutorial, you will:

•

•

•

•

•

•

•

Create a new request type, and define the process that will be used to manage this new request type

Define a new set of migration destinations ("target group") to be used with your new request type

Reconfigure approvers for a status in strategy TUTSTR_2 to ensure two approvals are required instead of one

Redefine when transports may and may not be added to requests that use strategy TUTSTR_2

Make a previously optional request field mandatory

You will also run a report that displays a "plain English" description of the change management processes you have configured.

Creating and using new request type

Occasionally you may need to create a new request type.

The most common reasons for creating a new request type are:

You want an easy way of categorising work into different subsets for reporting processes

You want to use a new process (eg, different statuses, different approvers or a different migration path) for certain types of work

You will create a new request type called XAPP (Cross-application).

Requests of this type in project TUT_2 will use strategy TUTSTR_2, and so will have the same steps (statuses) and approvers as requests of type DEV in this project.

Later, you will ensure that requests of type XAPP have their own unique migration path.

As request type XAPP does not currently exist in Rev-Trac, you first need to create this request type. Do the following:


2. Select Configuration > Process > Request types. The "Display View 'Request types': Overview" screen is displayed. There is no entry for request type XAPP (Cross-application).

3. Select Table View > Display -> Change to put the screen in change mode, then select Edit > New entries. The "New Entries: Overview of Added Entries" screen is displayed.




Field Description

Req type Type "XAPP".

Text Type "Cross-application"


Next, you will make this request type available for use in project TUT_2, and will assign an organisation and strategy. Do the following:


2. Select Configuration > Process > Assign process. The "Display view 'Process assignment': Overview" screen is displayed.

3. Select Table View > Display -> Change to put the screen in change mode,

4. Select TUT_2, then double-click Assignments per project / request type. The "Change View 'Assignments per project / request type': Overview" screen is displayed.

5. Select Edit > New Entries, then complete the following fields:

Field Description

Req type Select XAPP.

Org Select TUTORG.

Strat Select TUTSTR_2.


Creating and using a new target group with request type XAPP

While you could now create a request of type XAPP in project TUT_2, you would be unable to migrate transports attached to this request to any destination.

This is because you have not yet defined the migration methods or targets to be used at the relevant statuses for this type of request.

You will now create a new target group to represent the destinations to which transports on requests of type XAPP are migrated after the status D-QMIG (Migrate to QAS) is approved.

You will call this target group TUT_QAS_2.

For learning purposes, to ensure that transports are not migrated outside the tutorial system you will create the new target group by copying target group TUT_QAS. In real use, however, a new target group would normally contain different destinations from an existing target group.



To create the new target group by copying target group TUT_QAS, do the following:


2. Select Configuration > Process > Migration. The "Display View 'Target groups': Overview" screen is displayed.


4. Select target group TUT_QAS, then select Edit > Copy As... The colour of the selected item changes.

5. Change Target grp to TUT_QAS_2. Change Text column "QA target for XAPP""




Putting the new target group to use

You will now define the migration behaviour of requests of type XAPP in project TUT_2 to achieve the following outcome:

•

•

When requests of type XAPP in project TUT_2 are approved into status D-QMIG (Migrate to QAS), the associated transports are migrated in the foreground to target group TUT_QAS_2

This is the target group you just created.

When the same requests are approved into status Q-PMIG (Migrate to PRD), the associated transports are migrated in the foreground to target group TUT_PRD

This target group existed previously.

To achieve this result, do the following:





5. Select request type XAPP, then double-click Migration method and target. The "Change View 'Migration method and target': Overview" screen is displayed.



6. Select Edit > New entries, then complete the following fields in the first row:

Field Description

Status Select D-QMIG (Migrate to QAS).

Mig Select 3 (Release & Migrate all related transports).

Mig target Select TUT_QAS_2 (QA target for XAPP)

7. Complete the following fields in the second row:

Field Description

Status Select Q-PMIG (Migrate to PRD).

Mig Select 2 (Migrate all related transports).

Mig target Select TUT_PRD (Tutorial PRD targets)


Requiring an additional signature

The next adjustment you will make is to require two signatures for the status SPEC (Spec complete) in strategy TUTSTR_2. This status currently requires only one signature.

How many signatures are required for a status?

The number of signatures required for any status matches the number of different approval types configured for that status.

Figure 1-38 below shows a status configured to require only a single approval type − in this case, approval type FUNC (Functional).

Figure 1-38: Because only one App type (Approval type) is configured for this status, only one signature is required

It doesn't matter how many rows have been configured in Figure 1-38. As long as each row includes the same approval type, only a single signature will be required for this status. Any of the approvers defined here could give that one signature.



The situation is different in Figure 1-39 below. Here, two different approval types are listed (FUNC and SUPP). Two signatures are therefore required for this status.

Figure 1-39: Because two App type (approval types) are configured for this status, two signatures are required, one for each approval type

Requiring two signatures for status SPEC in strategy TUTSTR_2

You will now change the approver configuration for status SPEC (Spec complete) in strategy TUTSTR_2 to ensure that an additional approval is required for this status from the Content co-ordinator of the Training & Documentation team.

Because no suitable approval type currently exists to represent an approval from someone in the Training & Documentation team, your first step will be to create a new approval type.

It is not usually necessary to create an additional approval type in order to require an additional signature. You can normally use an existing approval type for this purpose.

Creating a new approval type

You will create approval type T&D (Training & Doc) to represent the type of approval to be given in this case.

To do so, follow these steps.




4. Double-click Approval types, then select Edit > New entries. The "New Entries: Overview of Added Entries" screen is displayed.




Field Description

App type Type "T&D".

Class Type "*" (asterisk) to force a requirement for this approval in all instances, regardless of the contents of the request's Class field.

Note: The use of request classes is an advanced topic not covered in this chapter. For more detail, press the F1 key for this field.

Text Type "Training & Doc".


Adding requirement for additional approval

You will now change strategy TUTSTR_2 so that an additional approval of type T&D is required for status SPEC (Spec complete).

The additional approval will be given by the Content co-ordinator of the Training & Documentation team.

To do so, follow these steps:





5. Select strategy TUTSTR_2, then double-click Status path. The "Change View 'Status path': Overview" screen is displayed.

6. Select the row for SPEC (Spec complete), then double-click Approvers & WF message recipients. The "Change View 'Approvers & WF message recipients': Overview" screen is displayed.




Field Description

App type This is the type of approval to be given. Select T&D.

Team This is the team to which the approver belongs. Select T&D.

Position This is the position the approver holds. Select TUT_COCO (Content co-ordinator).

WF Msg Select "1" to send workflow messages prompting approval to the holder of this position, but not to standins.


Activating one-click approval

By default, users approving Rev-Trac requests are always prompted to type their SAP password in a field provided for this purpose at the time of approval, as shown in Figure 1-40 below..

Figure 1-40: By default, approvers are prompted to type their SAP password in a field provided for this purpose

This facility allows users to approve Rev-Trac requests in a secure manner even via a colleague's SAP session. However, it also involves typing extra keystrokes that are unnecessary in many situations.

It is possible for users to approve requests in their own name without typing their SAP password, provided they are logged onto SAP under a corresponding ID, and provided Rev-Trac's one-click approval feature has been activated. When this feature is active, users approving requests in their own name are shown a screen like the one in Figure 1-41 below.



Figure 1-41: When one-click approval is activated, approvers simply click the Sign button for their own approvals

To approve the request, users simply clicks the Sign button.

To activate one-click approval for all users, do the following

1. As user RSCADMIN, display the Rev-Trac Console.,

2. Select Configuration > Global > Advanced > Over-rides. The "Display View 'Over-rides': Overview" screen is displayed.

3. Select Table View > Display -> Change to put the screen in change mode

4. Select Edit > New entries, then complete the following fields.

Note: To view the Value column, you may need to resize the other columns.

Field Description

Parameter Type "ONE_CLICK_APPROVAL".

Sub Parameter 2 Type "USER=*".

Value Type "ON".


Defining statuses when no transports may be added to a request

There are phases in the life-cycle of a Rev-Trac request when you may not want users to add transports to a request.

You will now change strategy TUT_STR2 so that users may not add transports to a request that uses this strategy when the request is in:

•

•

Status NEW

Status Q-PMIG (Migrate to PRD)







4. Select TUTSTR_2, then double-click Status path. The "Change View 'Status path': Overview" screen is displayed.

5. In the row for status NEW, clear the TX Status field. Do the same for status Q-PMIG.


To test the effect of this change, create a new Rev-Trac request of type DEV in project TUT_2. (This request uses strategy TUT_STR2.)

Display the new request on the Rev-Trac Workbench, select the request by clicking its number once, then select Transport > Insert transport.

Rev-Trac displays in the status bar the error message shown in Figure 1-42 below:

Figure 1-42: Rev-Trac displays this error message if user tries to add transport to request in status where this action is not permitted

Making a field mandatory

You saw previously that if you define the person whose ID appears in the request details screen Programmer field as a request approver, Rev-Trac may be unable to determine an actual approver in some circumstances if this field is left blank (see Test driving the new strategy on page 38).

One solution is to make this field mandatory. To do so, follow these steps.


2. Click the Create request button. The "Create request details" screen is displayed.

3. To identify the technical name of the Programmer field, place your cursor in the field, then press the F1 key to display help for the field. Depending on what version of SAP you are running, either press the F9 key or click the Technical information icon to display the "Technical Information" dialog. Note the name of the screen field.

4. Display the Rev-Trac Console, then select Configuration > Process > Request screen > Field attributes. The "Display View 'Field attributes': Overview" screen is displayed.

5. Select Table View > Display->Change to put the screen into change mode, then select Edit > New Entries.


Field Description

Screen field The value you noted in step 3. For the Programmer field, the value is /RSC/T_RM_3A-PGMER.

Attr Select "1" (Obligatory field).




To test the effect of this change, create a new request. You will find the Programmer field is now mandatory.

You can make any field on the Rev-Trac request details screen mandatory using the method described above.

Alternatively, you may wish to define a request completion rule that specifies that a particular field should be completed by the time a request reaches a particular status. For details on how to do this, see Request completion rules on page 166.

Using the configuration area described above, you can also suppress a field (by setting Attr = 2).

And by completing the Req type field, you can make a field mandatory, or suppress a field, for a specific request type.

Reviewing your processes

You can print a report that describes in plain English the effect of many of the configuration settings you have reviewed, changed or created in these tutorials. Figure 1-43 below shows an excerpt from such a report.

Figure 1-43: The Check Rev-Trac Configuration report describes the effect of many configuration settings in plain English

To run this report, follow these steps:

1. As either RSCLEARNER or RSCADMIN, display the Rev-Trac Console.

2. Select Configuration > Check configuration > Check configuration. The "RSC - Check Rev-Trac Configuration" selection screen is displayed.

3. Clear the Check existing requests checkbox, then execute the program.



Inter-system communications

This chapter explains what RFC destinations need to exist in each system to support Rev-Trac inter-system communications.

Correctly set up communications allow Rev-Trac users to:

•

•

•

•

•

•

Display Rev-Trac migration reports

Release and migrate transports from any development system

Display transports, and software components carried in those transports, from the Rev-Trac master system, regardless of what system the transport or component was created in

Logon to the Rev-Trac master system remotely from other systems

The RFC destinations described in this chapter should be created in transaction SM59 in each of the relevant systems.

There is no need to configure Rev-Trac explicitly to use any of these RFC destinations. Rev-Trac automatically senses what RFC destinations are present, and uses the most appropriate destination available for its purpose.

Terminology: landscape, master, slave and monitored system

The terms "landscape", "master", "slave" and "monitored system" are used widely in this Guide.

This section explains the meaning of each term in Rev-Trac.

Master

A single Rev-Trac "master" system controls every other system in a Rev-Trac installation.

The Rev-Trac master is normally a heavily-used development system, but does not have to be a development system.

The Rev-Trac master system controls and co-ordinates migration and record-keeping activities on every other system in the installation.

Users logon to the Rev-Trac master system, either directly or indirectly via another system, to work with Rev-Trac requests.

Most Rev-Trac data is stored on the Rev-Trac master system. Some migration-related records are also stored on all other systems in the installation.

Slave

In Rev-Trac, a "slave" system is any development system that is not the Rev-Trac master.

Monitored system

In Rev-Trac, a "monitored" system is every system where Rev-Trac is installed that is neither a master system nor a slave system.

Landscape

In Rev-Trac, a "landscape" is a grouping of one or more functionally-related systems that includes either:

The Rev-Trac master system, or

One (and only one) development system

54 Inter-system communications


The same landscape may not include:

•

•

•

Both the Rev-Trac master system and a separate development system

More than one development system

Figure 2-1 below shows four Rev-Trac landscapes in a single Rev-Trac installation.

DEV QAS PRD

MAS

DV2 QA2

BWD BWQ

Master landscape

R/3 Production support landscape

R/3 Project landscape

BW landscape BWP

Figure 2-1: A single Rev-Trac installation containing four Rev-Trac landscapes. Development systems are shown in bold.

The master landscape in this example comprises a single system, which is the Rev-Trac master MAS. In this example, the Rev-Trac master is not a development system. This is an uncommon setup.

Each of the other landscapes contains a single development system.

Note that:

• No landscape contains more than one development system

No landscape contains both the Rev-Trac master system AND a further development system

In the diagram above, MAS is the Rev-Trac master system. DEV, DV2 and BWD are slave systems. All the other systems are monitored systems.

A more common setup is the one shown in Figure 2-2 below. In this Rev-Trac installation, DEV is a development system, and is also the Rev-Trac master. The role of all other systems is the same as in the previous example.

The remainder of this chapter describes how to set up RFC destinations for the installation shown in Figure 2-2 below.

R/3 Production support landscape QAS PRD DEV

R/3 Project landscape QA2 DV2

BW landscape BWQ BWP BWD

Figure 2-2: Rev-Trac installation discussed in the remainder of this chapter

Inter-system communications 55


RFC destinations to support transport movement monitoring

Figure 2-3 below shows the RFC destinations required in the Rev-Trac master system to support the monitoring of transport movements throughout the installation.

One RFC destination is required in the Rev-Trac master system to connect to client 000 in every other other system in the installation.

DEV QAS PRD 000 RSCREMOTE 000 RSCREMOTE 000 RSCREMOTE

DV2 QA2 000 RSCREMOTE 000 RSCREMOTE

BWD BWQ BWP 000 RSCREMOTE 000 RSCREMOTE 000 RSCREMOTE

Figure 2-3: RFC destinations to support transport movement monitoring

RFC destination name

The name of each RFC destination that supports transport movement monitoring should match the pattern:

Y/RSC/RFC_SSS_000

where SSS is the SID of the destination system.

Example: Y/RSC/RFC_QA2_000.

RFC destination user

The RFC user for each RFC destination shown in Figure 2-3 above is RSCREMOTE.

The user type of RSCREMOTE is System (if this user type is available) or CPIC.

RSCREMOTE should have user profile Y:/RSC/RFC00.

RFC destinations to support transport release, and drilldown to transports and components

Figure 2-4 below shows the RFC destinations required in the Rev-Trac master system to release transports on any development system, and to allow drilldown from the Rev-Trac master system to transports and their components, regardless of what development system these are located on.

One RFC destination is required in the Rev-Trac master system to every client on every development system where transports are created.

If the Rev-Trac master is a development system (as in our example), RFC destinations are required to every client in the Rev-Trac master where transports are created.



In the Rev-Trac installation shown in Figure 2-4 below, transports are created in DEV clients 200 and 210, in DV2 clients 200 and 210, and in BWD clients 300 and 310.

DEV QAS PRD 000

200 RSCREMOTED

210 RSCREMOTED

DV2 QA2 000

200 RSCREMOTED

210 RSCREMOTED

BWD BWQ BWP 000 300 RSCREMOTED

310 RSCREMOTED

Figure 2-4: RFC destinations to support transport release, and drilldown to transport and components


The name of each RFC destination to support transport release, and drilldown to transports and components, should match the pattern:

Y/RSC/RFC_SSS_CCC_DIALOG

where SSS is the SID of the destination development system and CCC is the destination development client.

Example: Y/RSC/RFC_BWD_310_DIALOG.


The RFC user for each RFC destination shown in Figure 2-4 above is RSCREMOTED.

The user type of RSCREMOTED is Service (if this user type is available) or Dialog.

RSCREMOTED should have user profile Y:/RSC/RFC00.

RSCREMOTED should have user parameter SIN (Progress indicator on/off) set to 0 (zero). If this parameter is not set, a user logged into the Rev-Trac master from another system may experience problems releasing and queueing transports via approval if communications between the remote system and the Rev-Trac master are slow. For more details, see SAP Note 51373 "Problems with WAN link progress indicator".



RFC destinations to support activities on development system other than master

Figure 2-5 below shows the RFC destinations required to support activities on any development system that is not also the Rev-Trac master system.

These RFC destinations:

•

•

•

Support the Rev-Trac "enforcement" process whereby users are required to associate new transports with Rev-Trac requests

Allow users who are creating new transports on systems other than the Rev-Trac master to create new Rev-Trac requests to be linked to these transports, without requiring a separate logon to the Rev-Trac master system

Allow users who may have logons to development systems other than the Rev-Trac master to display, change and approve Rev-Trac requests from these development systems by starting transaction /rsc/rt, without requiring a separate logon to the Rev-Trac master system

DEV QAS PRD 000

200 RSCREMOTED

210 RSCREMOTED

DV2 QA2 000

200 RSCREMOTED

210 RSCREMOTED

BWD BWQ BWP 000 300 RSCREMOTED

310 RSCREMOTED

Figure 2-5: RFC destinations to support activities on development systems other than the Rev-Trac master

One RFC destination is required In each development system (other than the Rev-Trac master) to connect to the main client in the Rev-Trac master.

In fact, additional RFC destinations are also required to permit password and authorisation checking for Rev-Trac users working on development systems other than the Rev-Trac master. Rev-Trac can use the RFC destination shown in Figure 2-4 (RFC destinations to support transport release, and drilldown to transport and components) for this purpose.




The name of each RFC destination to support activities on any development system that is not also the Rev-Trac master as shown in Figure 2-5 should match the pattern:


where SSS is the SID of the Rev-Trac master system, and CCC is the main client in the Rev-Trac master system (that is, the client least likely to be deleted).

Example: Y/RSC/RFC_DEV_200_DIALOG.


The RFC user for each RFC destination shown in Figure 2-5 is RSCREMOTED.



RFC destinations to support remote logon to Rev-Trac master from non-development systems

When a user starts transaction /rsc/rt on any system other than the Rev-Trac master, a screen similar to the following is displayed:

Figure 2-6: "Rev-Trac Monitored System" screen.

If suitable RFC destinations have been set up, the user can logon to the Rev-Trac master system by clicking the button on this screen.

When logged onto Rev-Trac in this way, the user can approve Rev-Trac requests using his or her SAP password on the originating system and client, and Rev-Trac checks the user's authorisation on the originating system and client. A user may not perform Rev-Trac administrative functions using this method, however.

For development systems, no extra RFC destinations are required to support this feature provided the RFC destinations described in RFC



destinations to support transport release, and drilldown to transports and components (see page 56) and RFC destinations to support activities on development system other than master (see page 58) have been created.

For non-development systems, however, additional RFC destinations are required to enable this feature.

For illustration purposes, we will assume that users need to logon to the Rev-Trac master system from PRD client 200.

Figure 2-7 below shows the RFC destinations required to support remote logging on in this example.

DEV QAS PRD 000 000

200 RSCREMOTED 200 RSCREMOTE

Figure 2-7: RFC destinations to support remote logon to Rev-Trac master from PRD 200

For each non-development system and client for which a remote logon is to be enabled, two RFC destinations need to be created:

•

•

A connection from the remote system to the main client in the Rev-Trac master to permit a logon from the remote system (shown with a solid line in Figure 2-7)

A connection from the Rev-Trac master to the the remote system and client to permit password and authorisation checking on the remote system (shown with a broken line in Figure 2-7)

RFC destination name: remote logon

The name of each RFC destination that supports a remote logon to the Rev-Trac master from another system should match the pattern:


where SSS is the SID of the Rev-Trac master system, and CCC is the main client in the Rev-Trac master system (that is, the client least likely to be deleted).

Example: Y/RSC/RFC_DEV_200_DIALOG.

RFC destination user: remote logon

The RFC user for the RFC destination shown in Figure 2-7 with a solid line (that is, from remote system to master system) is RSCREMOTED.





RFC destination name: password- and authorisation-checking

The name of each RFC destination that supports password- and authorisation-checking on the remote non-development system should match the pattern:

Y/RSC/RFC_SSS_CCC

where SSS is the SID of the remote system and CCC is the client from which remote logon is supported.

Example: Y/RSC/RFC_PRD_200.

RFC destination user: password- and authorisation-checking

The RFC user for the RFC destination shown in Figure 2-7 with a broken line (that is, from master system to remote system) is RSCREMOTE.

The user type of RSCREMOTE is System (if this user type is available) or CPIC.

RSCREMOTE should have user profile Y:/RSC/RFC00.



Migration

Rev-Trac includes a powerful set of migration features.

This topic provides an overview of these features. The remainder of this chapter describes each feature in greater detail.

SAP and Rev-Trac migration functions

After Rev-Trac has been installed, users may migrate transports using tp or TMS, or they may use Rev-Trac's migration features.

While Rev-Trac itself ultimately releases and migrates transports by calling TMS or tp, Rev-Trac wraps these calls with additional functions. Only by using Rev-Trac's migration features is it possible to:

•

•

•

Perform overtake and overwrite checking automatically before each import

Approve the post-migration status of a Rev-Trac request automatically following a successful migration

Audit who approved each migration (as opposed to who actually migrated the transport)

For this reason, it is common to withdraw authorisation for the use of tp and TMS from most SAP users some time after Rev-Trac has been installed.

Rev-Trac accurately reports all migrations, regardless of whether they are performed using tp or TMS directly, or under Rev-Trac control.

For more information on how Rev-Trac performs migrations, see Technical insight into Rev-Trac migration on page 99.

Rev-Trac migration methods: queued and non-queued

Two migration methods are available in Rev-Trac.

Rev-Trac's queued migration method migrates transports in a two-step process.

In the first step, users send transports to the Rev-Trac migration queue. In the second step, Rev-Trac's batch migration utility migrates items in the queue to their destinations. This utility usually runs in the background.

Rev-Trac's non-queued method migrates transports immediately using a foreground (dialog) process.

Table 3-1 below summarises the differences between the two methods.

Queued migration Non-queued migration Two step process One step process Import usually occurs in background. May occur in foreground.

Import occurs in foreground

Import may occur immediately, or may be deferred.

Import occurs immediately

Import may be scheduled Import may not be scheduled Users may view and edit Rev-Trac migration queue before import occurs

Transports are never sent to Rev-Trac migration queue

Transports sent for migration at one moment may be imported at different times

Transports sent for migration at one moment are all imported at the same time

Table 3-1: Differences between Rev-Trac's queued and non-queued migration methods

62 Migration


It is possible to mix-and-match these methods, using the more appropriate method in each situation.

For more information on how to display the Rev-Trac migration queue and migrate items from the queue, see Rev-Trac migration queue on page 75.

Manual migration and automigration

Rev-Trac can migrate changes automatically as soon as a user has approved a request into a status such as "Approved for QAS". This feature is known as automigration.

Automigration may employ either the queued or non-queued migration method. For more details on how to configure automigration, see Automigration on page 71.

Authorized users may migrate transports manually from within Rev-Trac using the Migration Workbench. The Migration Workbench is a specialist tool not intended for general use. For details on how to use the Migration Workbench, see Rev-Trac Migration Workbench on page 92.

It is possible to prevent accidental automigration of transports associated with a request by adding special migration instructions, also known as transport instructions, to the request by selecting Documentation > Transport instr from the request details screen. After such instructions have been added to a request, transports associated with this request may be manually migrated using the Migration Workbench, but cannot be automigrated unless a utility has been run to remove the instructions. For details on how to remove special migration instructions from a request, see Removing special migration instructions on page 98.

Target groups

Rev-Trac migrates each change to all the destinations that have been defined in a "target group".

A target group consist of one or more clients in one or more systems. Different destinations may be defined within a target group to receive client-dependent and client-independent changes.

For further details, see Target groups on page 65

Autoapproval

After a migration has been attempted, Rev-Trac can check the result of the migration and automatically approve the next status of the relevant Rev-Trac request if the migration succeeds.

For example, if a user approves migrating changes to QAS, Rev-Trac can be configured to approve the status "In QAS" automatically as soon as it has verified that the migration to QAS has succeeded.

This feature is known as autoapproval. For more details on how to configure autoapproval, see Configuring an autoapprover for a post-migration status on page 73.

If a target group includes a system that is not always available (eg, TRN) , you can configure Rev-Trac to autoapprove a request if migrations to other destinations within the same target group succeed, while exempting the unavailable system from result-checking for the purpose of autoapproval. For more details, see Making provision for systems that are sometimes unavailable on page 67.

Migration reports

Rev-Trac includes a range of powerful migration reports. Several of these can be run against historical data as well as live data. In addition, it is

Migration 63


possible to save some report data in transport lists for later re-use. For more details, see Migration reports on page 100.

Tools

Rev-Trac includes a range of migration-related tools and utilities. For an introduction to these, see Other migration tools on page 96.

Rev-Trac Console migration summaries

The Queue Statistics area of the Rev-Trac Console (see Figure 3-1 below) displays the number of items currently in the Rev-Trac migration queue that were sent there by the current user, and the total number of items in the queue.

Figure 3-1: Queue statistics show how many queue items were sent by current user, plus queue total

Clicking either button displays the Rev-Trac migration queue items concerned.

In addition, if the All tab is selected on the left panel, the Rev-Trac Console may display two buttons relating to Rev-Trac requests that are currently in a migration status (that is, a status that should cause some migration activity to occur such as "Approved for QAS").

Figure 3-2 below shows these buttons.

Figure 3-2: These buttons may be displayed on the left panel of the Rev-Trac Console if the All tab is selected

The lower button shows the total number of Rev-Trac requests that are currently in a migration status.

The top button shows the number of Rev-Trac requests for which migration has apparently failed. A request is included in this figure if:

•

•

The request is in a migration status, and

There are no items in the Rev-Trac migration queue for this request

Any request that is in a migration status but has no transports attached will be counted in this figure.

Clicking either button displays the Rev-Trac requests concerned.

For more information on the Rev-Trac migration queue, see Rev-Trac migration queue on page 75.

64 Migration


Target groups

When users migrate transports in Rev-Trac, either by sending them to the Rev-Trac migration queue or by migrating them using the non-queued method, Rev-Trac sends these transports to the systems and clients defined in a specific "target group".

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 "backflushed" whenever they are sent to QAS. Or a target group might include only a single client in PRD for receiving both client-dependent and client-independent changes.

Within each target group, different destination may be defined to receive client-dependent and client-independent changes.

Rev-Trac sends hybrid transports (that is, transports that contain both client-dependent and client-independent changes) to all destinations defined within a target group.

If one destination within a target group (for example, a training system) is not consistently available, you can configure Rev-Trac to compensate for the non-availability of this system in some regards. See Making provision for systems that are sometimes unavailable on page 67.

"Sent indicators" are, in effect, flags that Rev-Trac adds to a transport to indicate it has already been sent to a particular target group, and therefore should not be sent again. In some circumstances it may be necessary to add or remove sent indicators manually. For more detail, see Sent indicators on page 68.

During the life of a project you may sometimes need to replace one target group with another that includes some of the same destinations. If this change is not handled carefully, Rev-Trac may resend transports to some destinations. For more details on how to handle this situation, see Preventing re-migration when replacing one target group with another on page 70.

After a target group has been defined, you may configure Rev-Trac to migrate changes to this target groups automatically after a particular approval has been given. For more details, see Automigration on page 71.

It is possible to define special OOPS behaviour for a particular target group. For details, see OOPS over-rides on page 112.

Defining target groups

To define a new target group, follow these steps:

1. From the Rev-Trac Console, select Configuration > Process > Migration. The "Display View 'Target groups': Overview" screen is displayed.

2. Select Table view > Display->Change to put the screen in change mode, then select Edit > New entries.


Field Description

Target grp Name of target group.

TG Status Type 0 (zero) to open the target group for both queued and non-queued migration.

Migration 65


Text Description of target group.

Set Complete this field only if this target group is being created to replace another. If this is the case, see Preventing re-migration when replacing one target group with another on page 70 for more details on how to use this field.


At the right of screen, select the target group you have just created, then double-click Destinations. The "Change View 'Destinations': Overview" screen is displayed.

5. Select Edit > New entries, then add a row for each destination in the target group by completing the following fields.

Note: You will need to create no more than one destination for client-independent changes for each target system.

Field Description

Cli Dep If this destination is to receive client-dependent changes, select X (Yes). If this destination is to receive client-independent changes, leave blank.

Target Sys Destination system.

Cli Destination client.

FTP If the source system and destination system share a common transport directory, leave this field blank. If you want Rev-Trac to copy data and cofiles from the source system to the target system before the import, and not to copy back the cofile after the import, select 1. If you want Rev-Trac to copy data and cofiles from the source system before the import, and then to copy the cofile back to the source system's transport directory after the import, select 2.

Note: One effect of copying back the 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.

Umodes If you leave this field blank, Rev-Trac performs imports with Umodes 01. If you type any Umodes in this field, the default Umodes of 01 no longer apply, and all imports to this destination are performed using the Umodes you have entered in this field.

66 Migration


Chk Level If you are using non-queued migration to this destination, or if this destination is usually available, leave this field blank. If you are using queued migration to this destination, and this destination is sometimes unavailable and you want Rev-Trac to ignore the return codes for migrations to this destination when determining whether to approve the post-migration status automatically, select 9. For more details on this setting, see Making provision for systems that are sometimes unavailable on page 67.

Hold mode If you are using this target group for queued migration and select 9 in this field, Rev-Trac will send items for this destination to the Rev-Trac migration queue with a "hold until" date of 31 Dec 9999. Rev-Trac will not migrate these items from the queue until their "hold until" date has been changed manually. For details on how to do this, see Changing the 'hold until' date on page 84Completing this field has no effect when using non-queued migration, and does not delay migration in this case.


Making provision for systems that are sometimes unavailable

Some target group destinations are not always available.

Training systems, for example, may not always be up. Or a quality assurance system may be unavailable for some hours while it is refreshed from a production system.

If Rev-Trac is unable to communicate with a target group destination when a user approves a migration to this destination:

•

•

Rev-Trac cannot perform an OOPS check to determine whether the proposed migration would result in an overtake or overwrite

Rev-Trac cannot perform the actual migration to this destination

Because of these difficulties, Rev-Trac normally treats a situation where one or more destinations within a target group is unavailable as an error condition, and does not send items to the Rev-Trac migration queue for any destination within the target group (even if the target group contains destinations that are currently available).

However, if one or more destinations within a target group destination is configured with Chk Level = 9 and a user sends items to the Rev-Trac migration queue, either by approval or directly from the Migration Workbench, Rev-Trac:

Migration 67


•

•

•

•

•

•

•

Warns if the destination system is unavailable

Skips OOPS checking for destinations with Chk Level = 9 that are unavailable

Adds items to the Rev-Trac migration queue for every destination defined in the target group, including items for destinations that are unavailable

Ignores the background migration job return code for each unavailable destination with Chk Level = 9 when determining whether or not to autoapprove the following status (eg, "In PRD") if an <AM> approver has been configured for that status

A common way of using this feature is to define a target group such as PRD_TRN that includes both PRD and TRN destinations. The TRN destinations are configured with Chk Level = 9. If TRN is unavailable when users approve migration to this target group via the Rev-Trac migration queue, all items will be sent to the queue regardless. If a background migration job successfully migrates all items to PRD (but not to TRN, which remains unavailable), Rev-Trac will automatically approve the following status (eg, "In PRD") if an <AM> approver has been configured, even though items are still waiting to be migrated to TRN.

Caution: OOPS checking for destinations where Chk Level = 9

As noted above, Rev-Trac cannot perform overtake or overwrite checking of items being sent to a system that is unavailable.

If a destination in a target group has Chk Level = 9, the Rev-Trac migration queue may contain items that, if migrated, could cause an overtake or overwrite to occur. Before allowing migration of these items to proceed, a user should perform a manual OOPS check of the Rev-Trac migration queue. For details, see How to perform a manual OOPS check on page 117.

Sent indicators

Rev-Trac displays a target group sent indicator for a transport on the Rev-Trac Workbench whenever a transport has been:

Migrated in the foreground, or

Sent to the Rev-Trac migration queue, or

Approved into a post-migration status such as "In QAS" or "In PRD"

Figure 3-3 below shows a transport to which Rev-Trac has added two target group sent indicators, TAR_QAS (green) and TAR_PRD (yellow).

Figure 3-3: Transport with two target group sent indicators

68 Migration


Rev-Trac adds a sent indicator to the transport regardless of whether the transport was:

•

•

•

•

•

•

Sent or queued following an approval of a Rev-Trac request, or

Sent or queued directly from the Migration Workbench

Rev-Trac does not add a sent indicator to a transport that was migrated using tp or TMS directly (that is, outside Rev-Trac control).

The text of the sent indicator matches the name of the target group to which a transport has been sent or queued.

Role of sent indicators in preventing inadvertent re-migration of transports

The main purpose of target group sent indicators is to prevent Rev-Trac automatically re-migrating transports following the approval of a request.

When a user approves a Rev-Trac request into a status that triggers migration to a target group, Rev-Trac sends or queues only transports attached to that request for which no corresponding sent indicator is displayed.

On the other hand, if a user sends or queues a transport to a target group from the Migration Workbench, Rev-Trac resends or requeues the transport, regardless of whether a sent indicator is already displayed for this transport and target group.

If you need to resend a transport to a target group to which it has already been sent, you have two options:

Use the Migration Workbench to migrate the transport in the foreground or to send it to the Rev-Trac migration queue

If using the Migration Workbench, it is not necessary to remove the sent indicator from the transport in order to force a resend.

Remove the sent indicator for the target group concerned from the transport, and re-approve the request into a status that will cause the migration to be repeated

For details on how to remove a sent indicator, see Adding and removing sent indicators manually on page 70.

Colour coding of sent indicators

A sent indicator may be either green or yellow.

Green sent indicator

A sent indicator is green if either:

The transport was migrated (sent) to this target group in the foreground, or

The transport was sent to the Rev-Trac migration queue, and is no longer in the queue

A green sent indicator does not imply that a migration actually occurred. If a transport was sent to the Rev-Trac migration queue and then deleted from the queue before it was migrated, the sent indicator would be green.

Furthermore, a green sent indicator does not signify that a migration has been successful.

Migration 69


To determine whether a transport displayed on the Rev-Trac Workbench was migrated successfully, select the transport, then select Transport > Show Migration Log.

Yellow sent indicator

A sent indicator is yellow if the transport has been sent to the Rev-Trac migration queue and is still present in the queue.

Adding and removing sent indicators manually

Occasionally it is desirable to add or remove a target group sent indicator from one or more transports.

For example:

• You may have sent transports to a system using tp or TMS directly

To ensure Rev-Trac does not resend some of these transports inadvertently when a user approves a request, you will need to add a sent indicator to all the transports migrated using tp or TMS directly.

• QAS has been refreshed from PRD, and as a result, some transports sent previously to QAS are no longer present

To ensure Rev-Trac does resend transports to QAS when users re-approve the relevant requests, you will need to remove the sent indicators that are currently present for these transports.

You can remove a sent indicator from a single transport directly from the Rev-Trac Workbench.

On the Rev-Trac Workbench, select the target group sent indicator concerned for the transport in question, then select Transport > Remove sent indicator.

A confirmation dialog is displayed. Click the Yes button to remove the sent indicator.

For details on how to add or remove sent indicators for multiple transports, see Adding or removing sent indicators on page 96

Preventing re-migration when replacing one target group with another

As we have seen, the main purpose of target group sent indicators is to prevent Rev-Trac automatically re-migrating transports following the approval of a request.

If you replace one target group with a differently-named target group that includes some of the same destinations as the original, Rev-Trac may resend transports to destinations that are included in both the new and the old target groups.

You can prevent unwanted resending in this situation by including both the new and the old target groups in the same target group "set".

If a transport has already been sent to target group AAA, Rev-Trac will not subsequently send this transport to any destination within target group BBB if both AAA and BBB belong to the same target group set.

To assign a set to a target group, follow these steps:

1. From the Rev-Trac Console, select Configuration > Migration > Target Groups. The "Display View 'Target Groups': Overview" screen is displayed.

70 Migration


2. Put the screen into change mode, then type the same unique number in the Set field for both the previously-used target group and the target group that has replaced it.


Automigration

Rev-Trac can migrate changes automatically when a user approves a request into a status such as "Approved for QAS".

This feature is known as automigration.

Rev-Trac may be configured to use either the queued or non-queued migration method when automigrating changes. Table 3-1 on page 62 summarises the differences between the two methods.

Rev-Trac can perform any of the following automigration actions following an approval:

Automigration action Result No migration action Approval does not trigger any migration activity. Manual migration Users are required to migrate transports for this request using

manual processes. 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.

Release all related transports

Rev-Trac releases all previously unreleased transports for this request.

Release and queue all related transports

Rev-Trac releases all previously unreleased transports for this request and sends them to the Rev-Trac migration queue. It is assumed that one or more queue-processing jobs is scheduled to migrate items in the queue either immediately or later.

Queue all related transports

Rev-Trac sends transports for this request to the Rev-Trac migration queue. It is assumed the transports have been released previously.

Migrate all related transports

Rev-Trac migrates transports for this request immediately using a foreground dialog process. It is assumed the transports have been released previously.

Release and migrate all related transports

Rev-Trac releases transports for this request and migrates them immediately using a foreground dialog process.

Table 3-2: Rev-Trac automigration options

Some of these options involve migrating transports immediately in the foreground.

Other options involve sending transports to the Rev-Trac migration queue, from where they may be migrated immediately or later in the background by Rev-Trac's queue processing program. For more information on how to set up such queue processing jobs, see Migrating items from the queue on page 88.

You can define different automigration actions and targets for each project / request type / status combination.

To define new automigration actions and targets, or to edit existing ones, perform the following steps:

Migration 71


1. From the Rev-Trac Console, select Configuration > Process > Assign process. The "Display View 'Process assignment': Overview" screen is displayed.

2. Select a project, then double-click Assignments per project/request type. The "Display View 'Assignments per project / request type': Overview" screen is displayed.

3. Select a request type, then double-click Migration method and target. The "Display View 'Migration method and target': Overview" screen is displayed. The screen shows any automigration actions and targets that have already been defined for this project / request type combination.

4. Select Table view > Display-> Change to put the screen in change mode.

5. If you want to add an automigration action and target for a status that is not already listed on this screen, select Edit > New entries.

6. Complete some or all of the following fields:

Field Description

Status The status whose approval will trigger an automigration action.

Mig Select an automigration action. For an explanation of each option, see Table 3-2 above.

Mig Target The target group to which transports will be migrated after this status is approved.


Autoapproval

After all transports associated with a request have been successfully migrated to each destination in a target group, Rev-Trac can automatically approve the request's next status. This feature is known as autoapproval.

Figure 3-4 below shows a request that Rev-Trac has autoapproved into status "In QAS". The approver's name is always shown as AUTOMIG on this screen.

Figure 3-4: This request was autoapproved into status "In QAS" by the Rev-Trac autoapprover

72 Migration


Automigration and autoapproval are frequently used together. In a typical situation, Rev-Trac might automatically migrate transports on a request to four destinations in QAS after the status "Approved for QAS" has been signed off. If each migration succeeds, Rev-Trac autoapproves the request into the status "In QAS".

Rev-Trac's autoapproval feature treats a migration as successful if the migration return code is 4 or less. This setting is not configurable.

Whenever Rev-Trac performs an autoapproval check, it actually checks all Rev-Trac requests that are currently in a migration status (that is, in a status that triggers migration activity such as releasing or migrating a transport), and checks if these are eligible to be autoapproved into their next status.

This autoapproval checking behaviour is triggered whenever:

•

•

nce

s.

Configuring an autoapprover for a post-migration status

To configure an autoapprover for a post-migration status such as "In QAS"

1. From the Rev-Trac Console, select Configuration > Process >

gies': Overview" screen is displayed.

2.

path': Overview" screen is displayed.

3.

essage recipients':

4. hange to put the screen in change mode.

Rev-Trac migrates a transport in the foreground as the result of a user's approving a request

Batch migration utility /RSC/MF_BATCH_MIGRATION_UTIL migrates items in the queue in either the background or foreground

Migrating a transport in the foreground using the Rev-Trac Migration Workbench does not trigger this behaviour.

Rev-Trac's autoapproval check ignores the return codes for all migrations to destinations that have a Chk Level of 9 (see Making provision for systems that are sometimes unavailable on page 67). If a migration to one of these destinations fails or does not occur at all, but migrations to all other destinations with a target group succeed, then Rev-Trac can autoapprove the next status.

When configuring an autoapprover for a post-migration status, be sure to configure at least one alternative human approvers who can give the same type of approval if necessary.

Rev-Trac sends workflow notifications to this human approver if a migration fails and the autoapprover therefore cannot approve the next status. For more details, see Migration-related workflow on page 98. Osatisfied that the required change really has reached its destination, the alternative human approver can then sign the request into the next statu

or "In PRD", follow these steps:

Strategies > Strategies. The "Display View 'Strate

Select the strategy in which you want to insert an autoapprover, then double-click Status path. The "Display View 'Status

Select the post-migration status for which you want to create an autoapprover (eg, "In QAS" or "In PRD"), then double-click Approvers and WF message recipients. The "Display View 'Approvers and WF mOverview" screen is displayed.

Select Table view > Display-> C

Migration 73


5. If any human approver is currently defined for this status, note the Approval type (leftmost column) for this approver. (The autoapprover

6.

will need to use the same Approval type.)

Select Edit > New entries, then complete the following fields to configure the Rev-Trac autoapprover:

Field Description

App. type If a human approver has already been configured us, select here the approval type given for this stat

by the human approver.

Team Position

g ank.

Type * (asterisk)

<AM>

WF Ms Leave this field bl

7. an app igured for this status, add row of c uman approver using the

8.

Reviewing migration configuration

migration-related configuration in Rev-Trac uration report (Rev-Trac Console >

ed lete listing of

If no humanother

rover has yet been confonfiguration defining a h

same approval type as you used for the Rev-Trac autoapprover.

Select Table View > Save.

A convenient way of reviewingis to run the Check Rev-Trac ConfigConfiguration > Check configuration > Check configuration).

Among other things, this report shows what migration activity is associatwith statuses such as "Approved for QAS", and gives a compall migration destinations for such a status.

Figure 3-5 below shows an extract from this report.

Figure 3-5: Check Rev-Trac Configuration report lists migration actions and destinations for statuses where these have been configured

74 Migration


Rev-Trac migration queue

As noted above, Rev-Trac uses two migration methods.

With one of these methods, items are sent to the Rev-Trac migration queue, and are subsequently migrated by Rev-Trac's queue-processing program. This method is known as queued migration.

Items may be added to the Rev-Trac migration queue in two ways:

•

•

•

•

•

•

•

•

•

•

A user may approve a Rev-Trac request into a status that causes this to occur

For more details on how to configure this option, see Automigration on page 71.

A user − typically a user with special authorisation such as a Rev-Trac administrator − may send items to the queue from the Rev-Trac Migration Workbench

For details on how to do this, see Performing migrations from the Rev-Trac Migration Workbench on page 94.

Once in the Rev-Trac migration queue, items are removed in one of two ways:

The Rev-Trac queue-processing program removes them after migrating them

Note that Rev-Trac removes items from the queue after migration, regardless of whether the migration succeeds.

A user manually deletes items from the queue

For details, see Deleting items from the queue on page 84.

The following topics describe:

How to display the Rev-Trac migration queue

How the visual appearance of the queue changes in different circumstances

Different ways of sequencing the queue, both when displaying the queue and when migrating items from the queue to their destinations

How to set up background jobs to migrate queued items

Displaying the queue

There are two ways to display the Rev-Trac migration queue:

From the Rev-Trac Console, select Migration > Migration queue > Manage / view queue

From the Rev-Trac Console, click the relevant button on the Queue Statistics area (see Figure 3-6 below)

Clicking the top button the Queue Statistics area displays only items sent to the queue by the current user, while clicking the lower button displays all items currently in the queue.

Migration 75


Figure 3-6: Queue Statistics show total number of items in Rev-Trac migration queue, and number of items sent to queue by current user

Understanding the queue display

Figure 3-7 below shows a typical view of the Rev-Trac migration queue.

Figure 3-7: Typical view of Rev-Trac migration queue

The order in which queue items are displayed on this screen depends on a several factors, including:

•

•

•

•

•

Import sequence options selected for the queue display program

Whether a user has frozen the sequence of any items in the queue

When each transport was released

The Rev-Trac transport sequence number of each transport

Similar factors determine the order in which queued items are migrated.

For more details on how the Rev-Trac migration queue is sequenced, see Controlling the queue sequence on page 79.

One transport: many queue items

When a user sends a transport to the Rev-Trac migration queue, more than one item may be added to the queue. For example, in Figure 3-7 above C46K900131 was sent to the queue only once, but the queue holds four items for this transport. This is because:

• C46K900131 is client-dependent (as indicated by the X in the Cli Dep column), and

Target group TAR_QAS includes four different destinations for client-dependent transports

76 Migration


Each item in the queue thus represents a separate import action that will need to be performed when a transport is migrated.

The system and client to which each item will be migrated are displayed in the System/Client columns.

The queue in change mode

The Rev-Trac migration queue may be displayed in change mode by selecting Migration > Migration queue > Manage / view queue from the Rev-Trac Console, then selecting the Change mode option on the selection screen.

Figure 3-8 below shows the Rev-Trac migration queue displayed in change mode.

Figure 3-8: Rev-Trac migration queue can be edited when displayed in change mode

Items in the queue are now selectable, and additional menu and toolbar options are available.

When the queue is displayed in this mode users may delete or resequence items, freeze the sequence of a group of items, or set a "Hold until" date on items, blocking their migration until a particular date. For more details, see Changing the Rev-Trac migration queue on page 83.

Other factors affecting queue appearance

The appearance of the Rev-Trac migration queue may change if users perform actions that affect the queue.

Figure 3-9 below shows the appearance of the queue after the sequence of some items has been frozen. The items whose sequence has been frozen are displayed with a green background.

Migration 77


Figure 3-9: Items whose sequence is frozen are displayed in green

Items for which a "Hold until" date has been set are displayed in brown or beige, as seen in Figure 3-10 below.

Figure 3-10: Items for which a "Hold until" date is set are displayed in brown or beige

For details on how to set an initial indefinite "Hold until" date for a queue item, see Defining target groups on page 65.

Items which are currently being migrated are displayed with a matchstick icon next to the sequence number, and are usually coloured red, as seen in Figure 3-11 below.

Figure 3-11: Items flagged with a matchstick are currently being migrated

A red colour for these items is normal, and does not indicate that an error has occurred. After the migration is complete, these items will disappear from the queue.

78 Migration


Controlling the queue sequence

The Rev-Trac programs that display and migrate Rev-Trac migration queue items have almost identical selection options for controlling the queue sequence.

Figure 3-12 below shows these options for the migration queue display program:

Figure 3-12: Import sequence options for queue display program

Figure 3-13 below shows the comparable options for the batch migration utility. There is one extra option available: "Only fixed (locked) sequence".

Figure 3-13: Import sequence options for batch migration utility

Because the two sets of options are almost identical, a user can readily see the order in which queue items will be migrated by displaying the queue using the same import sequence options that will be used for the import.

Several selection options refer to a "dynamic" queue sequence. For details on how Rev-Trac sequences the queue dynamically, see Dynamic queue sequence on page 80.

Table 3-3 below explains the effect of each import sequence option.

Migration 79


Option Effect Frozen sequence then dynamic

First display or migrate items whose sequence has been frozen. Display or migrate these items in their frozen order. Then display or migrate any other eligible items that may be present in the queue, sorted dynamically.

Treat frozen as dynamic Ignore the fact that the sequence of some items in the queue has been frozen. Display or migrate all items in the queue in dynamic sequence.

Ignore Rev-Trac request TX sequence when calculating dynamic sequence

When sequencing all or some of the items in the queue dynamically, sort these items by release order only. Do not allow this sequence to be over-ridden if it is inconsistent with each Rev-Trac request's transport sequence.

Only fixed (locked) sequence This option is available for the batch migration utility, but not for the queue display program. When this option is selected, only items whose place in the queue has been frozen are migrated.

Sequence added to queue Display or migrate items in the same order they were added to the queue.

Previous import sequence to Display or migrate items in the same order in which they were previously migrated to the specified system and client. If a transport was migrated to this system or client more than once, base the sequence on the time of its most recent migration.

Table 3-3: Import sequence options for queue display and queue migration programs

Dynamic queue sequence

As noted above, the first and second options shown in Figure 3-12 refer to Rev-Trac's ability to display all or part of the Rev-Trac migration queue in a "dynamic" sequence.

What does this mean?

When Rev-Trac sequences items in the queue dynamically, it orders them initially in transport release order.

Figure 3-14 below shows five transports dynamically sequenced in the queue. None of these transports has been attached to a Rev-Trac request. Rev-Trac has sequenced the items in the same order in which each transport was released.

Figure 3-14: Transports not added to Rev-Trac requests are dynamically sequenced in release order

If transports in the queue are added to Rev-Trac requests, dynamic sequencing becomes more complex, as the sequence of transports on each request now comes into play.

80 Migration


Let's assume the first, third and fifth transports in the above screenshot have been added to Rev-Trac request 11, and have been added in a sequence that matches their release order. In other words, the transport that was released first is the first one added to the request, and so on.

After all three transports have been added to the request, Rev-Trac displays them on the Rev-Trac Workbench in the order in which they were added, as seen in Figure 3-15 below.

Figure 3-15: These three transports were added to request in their release order

The sequence in which the Rev-Trac Workbench displays transports for a request is known as the "request transport sequence".

By default, this sequence is the order in which transports were added to a request. However, it is possible to change this sequence.

Whenever a transport is added to a request, Rev-Trac assigns a transport sequence number to the transport automatically. The first transport added to a request has sequence number 10, the second transport has sequence number 20, and so on.

You can display the transport sequence number of any transport by double-clicking the transport on the Rev-Trac Workbench, as seen in Figure 3-16 below.

Figure 3-16: To display a transport's sequence number, double-click the transport on the Rev-Trac Workbench

If we add the second and fourth transports shown in Figure 3-14 to request 12, also in release order, and resend all these transports to the Rev-Trac migration queue, the queue when sorted dynamically will appear as in Figure 3-17 below.

Migration 81


Figure 3-17: Queue when transport release order is consistent with request transport sequences

As it happens, this sequence coincides with the release order of the transports because the request transport sequence for each request is consistent with the release order of each transport.

It is possible, and in some cases desirable, to change the transport sequence number of a transport after it has been added to a request. As a result, the transport sequence numbers for this request may no longer be consistent with the release order of the transports.

Changing transport sequence numbers is typically necessary where it becomes clear that a transport added later to a request should be migrated before a transport that was added previously to the same request. In such a case, we might say that one transport "depends on" another, and requires the other transport to be migrated first.

It is possible to change the transport sequence number of a transport after it has been added to a Rev-Trac request by editing the Sequence field directly, as seen in Figure 3-18 below.

Figure 3-18: Editing Sequence number to change request transport sequence

In this example, the user is changing the Sequence from 30 to 5.

After this change has been made, the Rev-Trac Workbench displays the new request transport sequence as seen in Figure 3-19 below.

Figure 3-19: Request transport sequence has changed after editing Sequence number for C46K900145

82 Migration


When the queue is sorted dynamically now, it appears as in Figure 3-20 below.

Figure 3-20: Queue sorted dynamically where request transport sequence has over-ridden release order

The icons next to the last two items indicate that these items have been moved out of release order because the request transport sequence has over-ridden the release order.

Changing the Rev-Trac migration queue

Suitably authorized users may change the Rev-Trac migration queue directly by:

• Adding items

•

•

•

•

Deleting items

Freezing or unfreezing the migration sequence of items in the queue

Changing or removing the "hold until" date of items

The following topics describe how to perform these tasks.

Note that some changes to the queue may cause transports to overtake or overwrite other transports when the queue is migrated. Be sure to perform an OOPS check on the altered queue after completing any changes. For details, see How to perform a manual OOPS check on page 117.

Adding items to the queue

There are two ways to add items to the Rev-Trac migration queue:

• Add items manually, using the Rev-Trac migration workbench

Using this technique, it is possible to send transports to the queue whether or not they are attached to a Rev-Trac request. For more details, see Sending transports to the Rev-Trac migration queue on page 95.

Configure Rev-Trac to add items to the Rev-Trac migration queue automatically after a request has reached a particular status, then sign a request with transports attached into this status

For more details, see Automigration on page 71.

Migration 83


Displaying the Rev-Trac migration queue in change mode

You must display the Rev-Trac migration queue in change mode before performing queue changes.


1. From the Rev-Trac Console, select Migration > Migration queue > Manage / view queue. The "RSC − Manage / view Rev-Trac migration queue" screen is displayed.

2. Select Change mode (at the bottom of the screen), then select Program > Execute. The screen is displayed in change mode.

Figure 3-8 on page 77 shows the appearance of the queue as displayed in change mode.

Deleting items from the queue

It is possible to delete an item from the Rev-Trac migration queue before it has been migrated.

Effect of deletion on sent indicator

If the transport about to be deleted from the queue is attached to a Rev-Trac request, and if the Rev-Trac Workbench currently displays this transport with a yellow sent indicator, the colour of the sent indicator will change to green after this transport has been removed from the queue.

This shows that the transport went to the queue, and is no longer there.

To remove an item from the Rev-Trac migration queue, follow these steps:

1. Display the Rev-Trac migration queue in change mode. For details, see Displaying the Rev-Trac migration queue in change mode on page 84.

2. Select the item(s) to be deleted, then select Edit > Delete from queue. Trash can icons are displayed next to each item to be deleted.

3. Select Edit > Save. A dialog is displayed advising you to perform an OOPS check of the queue.

4. Perform an OOPS check of the queue. For details, see How to perform a manual OOPS check on page 117.

Changing the 'hold until' date

You can set a "hold until" date on items in the Rev-Trac migration queue. The Rev-Trac queue processing program does not migrate these items until the "hold until" date has been reached.

84 Migration


If the Hold mode for a target group destination is 9, Rev-Trac sets the "hold until" date for items sent to this destination to 31 Dec 9999 when they are first sent to the queue.

To remove or alter a "hold until" date, follow these steps.


2. Select the item(s) whose "hold until" date you want to remove or alter, then do one of the following:

To remove the "hold until" date, select Transport > Hold > Remove hold

To change the "hold until" date, select Transport > Hold > Hold until, then select a new date from the calendar

To hold the item(s) indefinitely, select Transport > Hold > Hold indefinitely

The Hold Date is updated.



Changing the queue sequence

By default, Rev-Trac sequences items in the queue "dynamically", based on the release date and Rev-Trac request transport sequence number of each transport (see Dynamic queue sequence on page 80).

Figure 3-21 below shows five queue items sorted dynamically.

Figure 3-21: Queue before manual sequence change. All items are sorted dynamically.

There may be occasions where you want to ensure some items are migrated in a sequence different from the dynamic sequence.

You can move items in the queue to ensure this occurs.

Figure 3-22 below shows the effect of moving transport C46K900141 one place higher in the queue.

Migration 85


Figure 3-22: After moving C46K900141, sequence of first two items is frozen (green)

After the sequence change:

•

•

A "manually moved" icon is displayed next to the item that has been moved

The first two items in the queue are displayed in green, indicating that their sequence is frozen

After any item has been moved, Rev-Trac freezes as much of the queue sequence as necessary to accommodate the move, always starting from the first item in the queue.

To move an item in the queue, perform the following steps:


2. Select the item you want to move, then select Edit > Cut (for paste). The item is removed from the queue.

3. Select the row below which you want the item to appear, then select Edit > Paste. The item is pasted into the queue below the selected position.



Freezing all or part of the queue

When the Rev-Trac migration queue is sequenced dynamically, it is possible that as new items are added these may be inserted between items that were previously adjacent.

There may be occasions where you want to ensure that queued items will be migrated exactly in the order currently displayed, regardless of what other items are subsequently added to the queue.

You can achieve this result by freezing all or part of the queue.

Another reason you may want to freeze all or part of the queue is to control dynamically when a set of queued changes will be migrated without the need to change the schedule of a batch migration utility job.

86 Migration


You can achieve this result by setting up a batch migration utility job that runs regularly (eg, nightly), but which migrates only queue items whose sequence has been frozen.

To freeze all or part of the Rev-Trac migration queue, follow these steps:


2. Select the items whose sequence you want to freeze, then select Queue > Free sequence. The items whose sequence has been frozen are displayed in green.



Unfreezing the queue

To unfreeze the Rev-Trac migration queue and restore it to a wholly dynamic sequence, perform the following steps

1. From the Rev-Trac Console, select Migration > Migration queue > Manage / view queue. The "RSC − Manage / view Rev-Trac migration queue" selection screen is displayed.


Field Description

Treat frozen as dynamic

Select

Change mode Select

3. Select Program > Execute. The queue is displayed in dynamic sequence.



Migration 87


Migrating items from the queue

Rev-Trac's queued migration method handles migration in a two-step process.

In the first step, users send transports to the Rev-Trac migration queue. In the second step, Rev-Trac's batch migration utility sends (migrates) queued items to their destinations.

Rev-Trac's batch migration utility is /RSC/MF_BATCH_MIGRATION_UTIL.

Typically, several different queue migration jobs are created. Each job runs on a different schedule, and migrates items to selected destinations, while leaving items for other destinations in the queue. Some jobs may migrate only items whose sequence in the queue has been frozen.

Each time an item is added to the Rev-Trac migration queue, Rev-Trac raises event /RSC/TRIGGER three times:

•

•

•

With event parameter IMPORT

With event parameter IMPORT_SYSTEM_SSS, where SSS is the SID of the system to which the item is being sent

With event parameter IMPORT_TARGROUP_TTT, where TTT is the Rev-Trac target group to which the item is being sent

By creating and using suitable selection variants for the Rev-Trac batch migration utility, and by scheduling event-driven migration jobs using different event parameters, a Rev-Trac administrator can exercise fine-grained control over what event-driven migration jobs will run to perform migrations to specific systems.

It is also possible, of course, to schedule recurrent, periodic migration jobs to run at set intervals.

In practice, one site may choose to migrate queued items to QAS every hour, and to migrate queued items to PRD every Friday night.

Another site may choose to migrate items to QAS and selected clients in DEV whenever items for these destinations are added to the queue, while migrating items to PRD weekly.

While /RSC/MF_BATCH_MIGRATION_UTIL is normally scheduled to run in the background, you can also run the program in the foreground.

Display of items currently being migrated

When the batch migration utility is running, Rev-Trac's queue display program highlights items that have been selected for migration but not yet migrated in red and with a matchstick icon, as shown in Figure 3-11 on page 78.

This is not a cause for alarm.

Migration sequence

The sequence in which queued items are migrated is determined by selections in the Import sequence area of the /RSC/MF_BATCH_MIGRATION_UTIL variant (see Figure 3-12 on page 79).

The options available here exactly match the options for Rev-Trac's queue display program. This means one way to see in what order queued items will be migrated by a particular migration job is to display the queue using the same Import sequence options you are using for the migration job.

88 Migration


For details on how Rev-Trac sequences the queue, see Controlling the queue sequence on page 79.

Another way of seeing in what order queued items will be migrated for a particular job is to execute /RSC/MF_BATCH_MIGRATION_UTIL with the Test (no update) field selected. When the program is run in this mode, it displays a list of all items selected for migration in the order in which migration will occur, but does not perform the actual migration.

Autoapproval of requests when using queued migration

Rev-Trac's autoapproval function works with queued migration as well as with non-queued migration.

After migrating all selected transports, the Rev-Trac migration utility checks every Rev-Trac request that is currently in a migration status to see whether the request can now be autoapproved into the next status.

By default, the Rev-Trac migration utility performs this check only if it actually migrated any items. However, you can force this check to occur each time the program runs by selecting the "Always do autoapproval check" option.

A request is in a "migration status" if a migration method has been defined for its project/request type/status combination via Rev-Trac Console > Configuration > Process > Assign process > Process assignment > Assignments per project / request type > Migration method and target.

Migration job naming conventions

While the name chosen for queue migration jobs does not affect Rev-Trac operation in any way, we recommend migration job names follow the pattern

/RSC/MF_BATCH_MIGRATION_UTIL_XXXXXXX

where XXXXXXX is an identifier of any length distinguishing this migration job from another.

Examples: /RSC/MF_BATCH_MIGRATION_UTIL_DEV /RSC/MF_BATCH_MIGRATION_UTIL_PRD

Migration job user

A migration job user is the SAP user under whose authorisation a migration job runs (not the user who scheduled the job).

We recommend the name of the migration job user be RSCBATCH.

The migration job user must be defined as as a Rev-Trac user (Rev-Trac Console > Configuration > Process > Organisations > Users) with an AdminAuth value of 01 or 03.

Rev-Trac authorisation profiles suitable for this user include Y:/RSC/BTC02 (RSC - Batch: Import Job) and Y:/RSC/BTC00 (RSC - Batch: All).

Preventing contention between multiple instances of the same migration job

As noted above, it is possible to create a queue migration job that will run whenever Rev-Trac raises event /RSC/TRIGGER with:

Migration 89


•

•

•

Parameter IMPORT, or

Parameter IMPORT_SYSTEM_SSS, where SSS is the SID of the system to which the item is being sent, or

IMPORT_TARGROUP_TTT, where TTT is the Rev-Trac target group to which an item is being sent

Rev-Trac raises this event with these parameter each time an item is added to the Rev-Trac migration queue. This means that in some environments, this event is raised quite frequently.

If a new instance of a queue migration job was started each time this event was raised, a situation could arise where multiple jobs were contending to migrate the same queue items to the same destinations simultaneously.

To prevent this occurring, each newly-started migration job checks to see whether another job is already running that has the same "lock key" as the newly-started job, and if so, ceases to run.

The lock key is specified as a selection parameter in the /RSC/MF_BATCH_MIGRATION_UTIL variant used for the job.

When a Rev-Trac administrator creates a migration job, it is important to specify a unique key for each different job, rather than to accept the default value "FULL_QUE".

What happens to items sent to queue while migration job is running?

If there are many items in the Rev-Trac migration queue, or if these items contain extensive changes, a queue migration job may take some time to run.

While the job is running, other items may be added to the queue that are eligible for migration to the same destinations. What happens to these items?

Before it finishes running, /RSC/MF_BATCH_MIGRATION_UTIL checks to see whether there are any more items in the queue that are also eligible for migration. If more items are found, the program migrates them, and again rechecks the queue, repeating this process until more eligible items are found.

Event /RSC/TRIGGER

Whenever an item is added to the Rev-Trac migration queue, Rev-Trac raises event /RSC/TRIGGER three times, with the parameters described above.

This can occur only if user event /RSC/TRIGGER already exists in the Rev-Trac master system.

This event is normally created at the time Rev-Trac is installed.

To check whether this event is still present in the Rev-Trac master system, and to create it if necessary, use transaction SM62.

Scheduling queue migration jobs to run /RSC/MF_BATCH_MIGRATION_UTIL

This manual assumes the user responsible for scheduling queue migration jobs to run program /RSC/MF_BATCH_MIGRATION_UTIL is familiar with how to schedule a job, including how to schedule a job to run that will run

90 Migration


when event /RSC/TRIGGER is raised with one of the IMPORT parameters listed above.

This manual therefore does not include detailed instructions in how to perform the actual scheduling of queue migration jobs.

The menu path to /RSC/MF_BATCH_MIGRATION_UTIL from the Rev-Trac Console is Migration > Migration queue > Migrate queue items.

Table 3-4 below is a partial listing of /RSC/MF_BATCH_MIGRATION_UTIL selection options that may be completed when creating a variant for use with a background migration job. For options in the Import sequence area, see Table 3-3 on page 80.

Field Description Target system System(s) to which queued items are to be migrated. Target client Client(s) to which queued items are to be migrated. Target group Rev-Trac target group(s) to which queued items are to be migrated. Migration Check Level Complete this field if you want to select items for migration based on

the value in the target group destination's Chk Level field. For the use of this field, see Making provision for systems that are sometimes unavailable on page 67.

Transport number SAP transport number. Project release This field corresponds to the Proj. rel. field on the Rev-Trac request

details screen. Stop if RC greater than Replace the default value in this field with another if you want the

program to stop running when a migration results in a return code greater than the value entered here.

If stopped, notify this user Rev-Trac sends a workflow message to the Rev-Trac user whose SAP ID appears in this field if the program stops because the "Stop if RC greater than" condition has been met. Ensure the user ID entered in this field is a Rev-Trac user as well as an SAP user. See Rev-Trac Console > Configuration > Process > Organisations > Users.

Lock key (stop a parallel run)

A meaningful alphanumeric value. Make sure the value entered here is different for each migration job. For the purpose of this field, see Preventing contention between multiple instances of the same migration job on page 89.

Program to launch on complete

To launch an ABAP program after the migration job runs, type the name of the program here.

Always do autoapproval check

Select this checkbox if you want the program to check if any requests are eligible for autoapproval even if the program finds no transports to migrate in the Rev-Trac migration queue.

Send fail WF ->owner/programmer

Select this checkbox if you want Rev-Trac to send a workflow message to the owner and programmer of every Rev-Trac request for which a migration has failed. For more detail, see Migration-related workflow on page 98.

Test (no update) Select this checkbox to run the program in test mode. When run in test mode in the foreground, the program lists queued items it has selected for migration, but does not perform a migration. Clear this checkbox to perform migrations using this program.

Table 3-4: Selection parameters for /RSC/MF_BATCH_MIGRATION_UTIL

Migration 91


Rev-Trac Migration Workbench

The Rev-Trac Migration Workbench is an expert tool that allows an authorized user to:

•

•

•

•

Migrate transports in the foreground

Send transports to the Rev-Trac migration queue

Perform "what if" OOPS checks to determine if migrating transports in a particular sequence will result in overtaking and overwriting

Create transport lists from text files for later re-use

Figure 3-23 is a screenshot of the Rev-Trac Migration Workbench populated with five transports.

Figure 3-23: Rev-Trac Migration Workbench, populated with five transports

You can migrate and queue transports with the Rev-Trac Workbench regardless of whether these transports have been added to Rev-Trac requests.

Populating the Workbench

There are several ways to populate the Rev-Trac Workbench with a list of transports. These include:

•

•

•

•

Manually typing the transport number of each transport in the Transport column

Selecting from a filtered list of transports on Rev-Trac requests

Importing transports saved in a Rev-Trac transport list

Importing a list of transports saved in a text file

Populating Migration Workbench from filtered list of transports on Rev-Trac requests

A quick way of populating the Migration Workbench with transports that are already on Rev-Trac requests is to select these transports from a filtered list that can be displayed from within the Workbench.

92 Migration


An example of such a list is shown in Figure 3-24 below.

Figure 3-24: Users can populate Migration Workbench by selecting from a filtered list of transports on Rev-Trac requests such as this

To populate the Migration Workbench this way, perform the following steps:

1. From the Rev-Trac Console, select Migration > Migration Workbench. The "Migration WorkBench" screen is displayed.

2. Click the Rev-Trac data button in the top right corner of the screen. The "RSC - Transports per Rev-Trac Request" screen is displayed.

3. Complete enough fields to define a list of transports from which to make a final selection, then select Program > Execute. A list of transports is displayed similar to that shown in Figure 3-24 above.

4. Select the transports you want to display on the Migration Workbench, then click the Export selected button. The Rev-Trac Workbench is populated with details of the selected transports.

Populating Migration Workbench from a text file

The Migration Workbench can read transports from a text file if:

•

•

Each transport number is listed on a separate file line

Each transport number is ten characters long

Use the following procedure to populate the Rev-Trac Migration Workbench from such a text file.


2. Select Lists > Import PC list. An information dialog is displayed indicating that Rev-Trac will read only the first ten characters of each file line.

Migration 93


3. Close the information dialog. A file selection dialog is displayed.

4. Select the text file to be imported, then click the Open button. The Rev-Trac Workbench is populated with details of the selected transports.

Populating Migration Workbench from a transport list

A Rev-Trac transport list is a named list of transports saved internally in Rev-Trac for later reuse.

You can create a transport list from within several Rev-Trac migration reports. For details, see Using landscape snapshots and transport lists with migration reports on page 105.

Use the following procedure to populate the Rev-Trac Migration Workbench from an existing Rev-Trac transport list.


2. Select Lists > Transport lists. The "Please enter list id" dialog is displayed.

3. In the List field, select the transport list. Select Import list, then click the Enter button. The Rev-Trac Workbench is populated with details of the transports in the list.

Performing migrations from the Rev-Trac Migration Workbench

After populating the Rev-Trac Migration Workbench using one of the methods described above, you can:

•

•

Migrate all the transports listed in the workbench to a target group in the foreground

Transports are migrated in the order in which they appear on the Workbench.

Send all the transports listed in the workbench to the Rev-Trac migration queue for the selected target group

Note that transports must already have been released before attempting either of these actions. If you need to release multiple transports before migrating them from the Rev-Trac Workbench, considering using Rev-Trac's mass release function (Rev-Trac Console > Migration > Tools > Release transports).

If OOPS is enabled, Rev-Trac performs an automatic OOPS check whenever you use the Migration Workbench to send transports to the queue or to migrate transports in the foreground.

Migrating transports in the foreground

To migrate transports from the Rev-Trac Migration Workbench in the foreground, follow these steps:

94 Migration


1. Populate the Migration Workbench using any of the methods described in the preceding topics.

2. On the "Migration Workbench" screen, complete the Target group field, then select Transport > Migrate all. The status bar is updated to show the progress of the migration.

Sending transports to the Rev-Trac migration queue

To send transports to the Rev-Trac migration queue from the Migration Workbench, follow these steps:

1. Populate the Migration Workbench using any of the methods described in the preceding topics.

2. On the "Migration Workbench" screen, complete the Target group field, then select Transport > Add to migration que. An information dialog displays the number of items added to the queue.

Creating a transport list using the Migration Workbench


Several Rev-Trac migration reports include facilities for creating transport lists. For details, see Using landscape snapshots and transport lists with migration reports on page 105.

You can also create a transport list using the Migration Workbench. To do so, follow these steps:

1. Populate the Migration Workbench using any of the methods described in Populating the Workbench on page 92.

2. Select Lists > Transport lists. The "Please enter list id" dialog is displayed.


Field Description

List ID of new transport list.

Title Title of new transport list.

4. Select Create list, then click the Enter button on the dialog. An information dialog displays the number of entries inserted in the list.

Migration 95


Other migration tools

The following topics explain how to use other Rev-Trac migration-related tools. These include:

•

•

•

•

•

•

A utility for capturing "snapshots" that show the location of all transportable changes throughout the landscape at a given moment.

A tool for adding or removing sent indicators en masse

A tool for quarantining and unquarantining transports

A tool for mass releasing transports

A tool for moving transports between your PC and the application server's transport directory

A utility that archives historical data from the Rev-Trac migration queue

Capturing and reading landscape snapshots

Every 24 hours, a Rev-Trac job saves information showing what transports are present in what systems and clients throughout all landscapes under Rev-Trac control.

The job that performs this task is /RSC/LANDSCAPE_SNAPSHOT.

Each "landscape snapshot" is saved with an ID indicating the day of the week the information was captured. Every Monday, last Monday's snapshot is overwritten, and so on. As a result, there are no more than seven of these daily snapshots stored in the system at any one time.

Several Rev-Trac migration reports can be run against landscape snapshot data.

A user may capture an additional snapshot at any time using Rev-Trac's landscape snapshot function. From the Rev-Trac Console, the menu path is Migration > Tools > Landscape snapshot.

Normal landscape snapshots are stored in Rev-Trac tables. It is also possible to save a landscape snapshot to a text file, and to read this into Rev-Trac at a later time.

Adding or removing sent indicators

Rev-Trac adds a sent indicator to a transport after it has been migrated in the foreground, sent to the Rev-Trac migration queue, or approved into a post-migration status such as "In QAS" or "In PRD".

For more details on the appearance and purpose of sent indicators, and on how to remove single sent indicators, see Sent indicators on page 68.

Rev-Trac includes a function for adding or removing multiple sent indicators. To do either of these tasks, complete the following steps:

1. From the Rev-Trac Console, select Migration > Tools > Update Sent indicators. The "RSC - Update sent indicators" screen is displayed.

96 Migration


2. Do one of the following: To add a sent indicator to one or more transports, select Add

sent indicator To remove a sent indicator from one or more transports, select

Remove sent indicator

3. In the Target Group field, enter the target group for which sent indicators are to be added or removed.

4. Do one of the following: To add or remove a sent indicator for a single transport, type the

number of the transport in the Transport number field To add or remove a sent indicator for all transports in a Rev-Trac

transport list, select the ID of the transport list in the List id field To add or remove a sent indicator for all transports in a Rev-Trac

request, complete the Rev-Trac request field

5. Select the Test (no update) field to ensure the program runs initially in test mode, then select Program > Execute. A report is displayed indicating what actions will be performed, and the reasons for any possible failures (if applicable).

6. Click the Back button to return to the selection screen. Make any necessary adjustments to the selection criteria, then clear the Test (no update) field, and select Program > Execute. A report is displayed indicating what actions have been performed.

Quarantining transports

It is sometimes a good idea to move data and log files for particular transports from their standard location in the transport directory in order to prevent their accidental migration.

In Rev-Trac, this process is known as "quarantining" the transports.

You can quarantine transports manually using operating system commands. An alternative approach is to use Rev-Trac's own quarantine function.

Rev-Trac's quarantine function identifies and moves all single step log files associated with a transport, as well as the transport data file. The cofile and action log are not moved.

Transports can be selected in several ways, including from a Rev-Trac transport list. This means the function can perform a mass quarantine.

Rev-Trac's quarantine function can restore a quarantined transport to its previous location.

Rev-Trac's quarantine function works with transports located in any system's transport directory, quarantining these to a central location.

The menu path for this function from the Rev-Trac Console is Migration > Tools > Quarantine transports.

Rev-Trac can also report quarantined transports. For details, see Quarantined transports report on page 104.

Migration 97


Releasing transports

Rev-Trac's transport release function can release single or multiple transports, including transports contained in a Rev-Trac transport list.

The menu path for this function from the Rev-Trac Console is Migration > Tools > Release transports.

Uploading and downloading transports from PC

Rev-Trac's transport upload and download function allows you to move transport files between your PC and your Rev-Trac master system's transport directory.

Among other things, this can help you move ("upload") transports that contain Rev-Trac hotpacks from your PC onto your system's transport directory when you need to upgrade your Rev-Trac installation.

The menu path for this function from the Rev-Trac Console is Migration > Tools > Upload / download transports.

Archiving historical Rev-Trac migration queue data for performance improvement

When items are removed from the Rev-Trac migration queue following migration or deletion using Rev-Trac's queue deletion function, they remain physically present in Rev-Trac migration queue tables /RSC/T_MF_4H and /RSC/T_MF_4HI.

Although they can no longer be displayed or migrated, these items can still be reviewed by direct table read for audit or support purposes.

Allowing these tables to grow very large can eventually result in a performance degradation. In particular, the Rev-Trac Console may become slower to display as Rev-Trac takes longer to calculate the number of items in the queue for display on the Rev-Trac Console.

To move old items from the Rev-Trac migration queue to Rev-Trac's queue archive tables, run program /RSC/MF_ARCHIVE_QUE_REC_UTIL.

On sites where the queue is used heavily, we recommend this program be scheduled to run weekly.

Removing special migration instructions

If special migration instructions, also known as transport instructions, have been added to a Rev-Trac request, transports associated with the request may be migrated using the Rev-Trac Workbench, but cannot be automigrated after approval.

A Rev-Trac administrator may remove special migration instructions from a request using the function at Rev-Trac Console > Migration > Tools> Remove special mig instructions.

Migration-related workflow

Rev-Trac can send several different types of workflow messages when a migration fails.

Table 3-5 below summarises the different types of migration-related workflow messages that are available, and the conditions under which they may be sent.

98 Migration


Condition Message subject / title Message text Recipient(s)

"Send fail WF->owner/programmer" is selected for batch migration utility. Migration fails.

Please resolve migration errors in Rev-Trac NNN

Rev-Trac NNN requires investigation due to migration errors

Request owner and programmer

"Stop if RC greater than" and "If stopped, notify this user" are completed for batch migration utility. "RC greater than" condition is met.

Rev-Trac job JOBNUMBER stopped on bad RC=NNN

Rev-Trac: NNN, transport: XXX

Rev-Trac user whose ID appears in the "If stopped, notify this user" field of batch migration utility selection screen.

An <AM> approver has been defined for a post-migration status (eg, "In QAS"). The <AM> approver cannot approve the status because a migration has failed.

Please sign Rev-Trac request NNN (PROJ MOD REQTYPE).

Please approve status STATUS on Rev-Trac NNN.

All human (ie, non <AM>) approvers for post-migration status

Table 3-5: Overview of Rev-Trac migration-related workflow messages

Note that this table is not a complete description of all the pre-requisites that must be satisfied to set up Rev-Trac workflow.

Technical insight into Rev-Trac migration

Rev-Trac releases and migrates transports by calling SAP function modules.

Based on a range of circumstances, Rev-Trac decides dynamically whether to call:

•

•

•

•

•

Function modules that comprise the CTS application programming interface (API)

SAP's TMS function modules

SAP's tp interface or tp function modules

Rev-Trac calls the relevant function modules on the migration target system, not on the source system.

Rev-Trac does not disable or interfere with any of the standard SAP migration functions listed above. All of these are still available for use when Rev-Trac is in operation, although obviously their use should be restricted in order to control the dissemination of changes effectively.

SAP documentation describes in detail the requirements that must be met for the CTS API to function correctly. In particular, Rev-Trac requires that:

All systems where Rev-Trac is installed are contained in a TMS domain (not necessarily the same domain)

One and only one consolidation route has been defined to a virtual or real system for each development client

Rev-Trac always adds a transport to the target system's import buffer immediately before performing an import, regardless of whether the transport has already been added to the buffer (for example, as a result of directly releasing the transport).

Furthermore, Rev-Trac performs all imports singly. Rev-Trac never issues the equivalent of a tp import all command.

If the migration destination system does not share a transport directory with the source system, Rev-Trac should be configured automatically to copy the transport data file and cofile to the destination system before

Migration 99


performing the import. For more details, see Defining target groups on page 65. It is not necessary to use TMS functions to transfer the data file and cofile under these circumstances.

Rev-Trac may also be configured to copy the cofile back to the source system after the migration is complete.

Rev-Trac's own migration logs typically include tp return codes. In the case of some error conditions, however, Rev-Trac migration logs may include return codes above 900. Return codes above 900 are always Rev-Trac's own error codes.

Migration reports

The following topics:

•

•

Briefly introduce Rev-Trac's migration-related reports

Describe the roles that landscape snapshots and Rev-Trac transports lists may play in migration reporting

Reports

Propagation report

Menu path: Rev-Trac Console > Migration > Reports > Propagation

This report shows at a glance all systems and clients where selected transports are present, either as a result of migration or client or system copy, using a terse matrix view.

Figure 3-25: below shows an example of typical report output.

Figure 3-25: Typical output from Propagation report

100 Migration


When displayed in Distinguish mode, as shown in Figure 3-26 below, the report shows the system and client where each transport originated (triangle icons), and whether a transport reached a client by migration (tick) or client or system copy (dual pages icon).

Figure 3-26: Propagation report after user has clicked the Distinguish button. Special icons indicates where changes originated, and mark destinations that change has reached via client or system copy.

This report can display either live data or an historic "snapshot" of the environment. See Capturing and reading landscape snapshots on page 96.

The report's horizontal sort order is determined by the value entered for each system at Rev-Trac Console > Configuration > Systems > Systems > System parameters > Rep. Only systems for which a Rep value has been entered are included in the report.

You can run the same report from the Rev-Trac Workbench screen by selecting a single Rev-Trac request or the Requests node (for multiple requests), then clicking the Propagation button.

Chronological migration report

Menu path: Rev-Trac Console > Migration > Reports > Chronological

This report displays a chronological listing of transport movements within the environment, including exports (releases), imports and client copies. This report shows the date, time and destination of each movement.

This report can display either live data or an historic "snapshot" of the environment. See Capturing and reading landscape snapshots on page 96.

You can save transports listed in this report to a Rev-Trac transport list. See Using landscape snapshots and transport lists with migration reports on page 105.

Migration 101


This report does not show the result of each migration. For this detail, see Migration log on page 104.

Only systems for which a value has been entered at Rev-Trac Console > Configuration > Systems > Systems > System parameters > Rep are included in the report.

Figure 3-27: Chronological report - example output

System/client comparison report

Menu path: Rev-Trac Console > Migration > Reports > Comparison

This report shows all transports present in a particular system and client that are not present in another system and client.

This report can help you identify actions needed to match one system/client with another.

You can run this report using live data or an historic "snapshot" of the environment. Using the latter technique it is possible, for example, to list all the transports that are in QAS 220 today that were not in QAS 200 last Tuesday. For more details, see Capturing and reading landscape snapshots on page 96.

You can save transports listed in this report to a Rev-Trac transport list. See Using landscape snapshots and transport lists with migration reports on page 105.

102 Migration


Figure 3-28: System/client comparison report selection screen

Figure 3-29: System/client comparison report example output

Plan vs reality report

Menu path: Rev-Trac Console > Migration > Reports > Plan vs reality

This report identifies any discrepancies between what destinations transports should have reached (according to the current status of Rev-Trac requests, their associated transports and their migration strategies), and where these transports are actually present.

Rev-Trac itself runs this report silently every time a human approver signs a request into a post-migration status such as "In QAS" or "In PRD". If the report detects that the required changes are not actually present in their destination, Rev-Trac alerts the user.

Migration 103


Figure 3-30: Plan vs reality report example output

Migration log

Menu path: Rev-Trac Console > Migration > Reports > Migration log

The report displays a chronologically-order list of imports, showing the import system and client, the return code and the text of any import error message.

This report is useful for quickly identifying any migrations that have failed. These are displayed in red.

You can also run this report from the Rev-Trac Workbench screen by selecting a single Rev-Trac request or the Requests node (for multiple requests), then clicking the Migration Log button.

Figure 3-31: Migration log example output

Quarantined transports report

Menu path: Rev-Trac Console > Migration > Reports > Quarantined transports

104 Migration


This report lists transports from any system whose data files are no longer present, either because:

•

•

They have been moved manually (eg, by operating system command), or

They have been quarantined using Rev-Trac's built-in quarantine function (Rev-Trac Console > Migration > Tools > Quarantine transports)

If transports were quarantined using Rev-Trac's built-in function, the report shows who performed the quarantine, and when.

Limitations

This report does not list orphan transports (that is, transports not on Rev-Trac requests) that were quarantined using operating system commands.

Using landscape snapshots and transport lists with migration reports

Every 24 hours, a Rev-Trac job saves information showing what transports are present in what systems and clients throughout the landscape. In addition, a Rev-Trac migration tool allows you to capture ad-hoc landscape snapshots at any time (see Capturing and reading landscape snapshots on page 96).

You can run the Rev-Trac Propagation, Chronological and System/client comparison reports using a landscape snapshot as all or part of the input.

This makes it possible, for example, to compare the systems and clients which a change has currently reached with the systems and clients it had reached last Friday. To do so, you would run the Propagation report first against live data, and then a second time against last Friday night's landscape snapshot. For more details, see Propagation report on page 100.

You could also list all the transports that are in QAS 220 today that were not in QAS 200 last Tuesday by running the System/client comparison report using Tuesday's landscape snapshots as input. For more details, see System/client comparison report on page 102.


A selection option is available for several Rev-Trac migration reports that allows you to exclude transports from a specific transport list. This may be helpful if, for example, you want to exclude from a report all transport that have been quarantined, and you have a transport list that includes these.

You can create a Rev-Trac transport list directly from the output screen of the Chronological migration report, System/client comparison report and Plan vs reality report.

To do so, perform the following steps:

1. From the output screen of the Chronological migration, System/client comparison or Plan vs reality report, select List > Transport lists. The "Please enter list id" dialog is displayed.


Migration 105


Field Description

List ID of new transport list.

Title Title of new transport list.

3. Select Create list, then click the Enter button on the dialog. An information dialog displays the number of entries inserted in the list.

106 Migration


Accident prevention

Two related mechanisms in Rev-Trac help protect workbench objects and SAP configuration from accidental damage:

•

•

The Overtake and Overwrite Protection System (OOPS)

OOPS prevents the accidental overtaking or overwriting of changes during migration.


The aim of the Rev-Trac locking system is to minimise the risk 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 maintains locks on objects and tables even after the relevant transport has been released.

The following topics describe the operation of OOPS and the Rev-Trac locking system in detail, and explain the full range of configuration options.

Overtake and Overwrite Protection System (OOPS)

The Rev-Trac Overtake and Overwrite Protection System (OOPS) helps prevent accidental damage to workbench objects and SAP configuration settings when you migrate changes using Rev-Trac.

At a global level, you can configure OOPS to block all potentially dangerous migrations for most users, merely to warn users of potentially dangerous migrations − or you can turn off OOPS altogether (see 'OOPS' global parameter on page 111).

By default, OOPS automatically excludes from checking data in certain tables that is highly prone to benign overtaking and overwriting. See Some table data automatically excluded from OOPS checking on page 110.

In addition, you can fine-tune the operation of OOPS by defining special behaviour for particular users or systems (see OOPS over-rides on page 112), or for particular objects or table data (see OOPS rules on page 113).

Rev-Trac automatically logs all OOPS-related messages, and these messages can be retrieved later for audit purposes (see How to retrieve historical OOPS messages and action records on page 119).

A user who has determined it is safe to migrate a later version of an object or data without first migrating a previous version may suppress the OOPS warning Rev-Trac would normally give in such a situation by quarantining the transport carrying the previous version (see How to quarantine a transport on page 120).

Regardless of what global OOPS setting is in force, suitably authorized users may perform a "what if" check at any time to determine whether a particular migration may result in damage to an object or data in the migration target system (see How to perform a manual OOPS check on page 117).

What are overtaking and overwriting?

Overwriting occurs when you import a transport that obliterates all or part of the contents of another, more recently released transport that is already present in the system. The over-written object or data is left in an unintended state.

Accident prevention 107


Overtaking occurs when you import a transport before another transport that contains a previous version of the same object or data.

Overtaking may not immediately damage an object or data, but creates a potentially dangerous situation. If the overtaken transport is subsequently imported, it will overwrite the changes introduced by the chronologically later transport, thus potentially damaging objects or data they have in common.

Role of OOPS when migrating with tp or TMS

If you use tp or TMS to migrate changes directly (ie, without assistance from Rev-Trac), OOPS cannot issue alerts at the time of migration. OOPS issues migration-time alerts only when you are performing migrations under Rev-Trac control.

However, it is possible to use Rev-Trac OOPS to check whether migrating transports in a particular sequence will result in an overtake or overwrite, and then perform the actual migration using tp or TMS.

Furthermore, when determining if an overtake or overwrite may occur, Rev-Trac analyses data concerning all past migrations, regardless of whether these took place under Rev-Trac control. This means that migrating changes using tp or TMS directly does not invalidate future OOPS checks.

When does Rev-Trac perform an automatic OOPS check?

Rev-Trac performs an automatic OOPS check whenever:

• A request is approved into a status that causes a migration to occur in the foreground, or that causes one or more items to be sent to the Rev-Trac migration queue

• A users sends items to the Rev-Trac migration queue from the Rev-Trac Migration Workbench

Rev-Trac does not perform an automatic OOPS check at the time the batch migration utility migrates items in the Rev-Trac migration queue to their destinations.

It is also possible to perform a manual OOPS check of one or more transports. For details, see How to perform a manual OOPS check on page 117.

108 Accident prevention


Example screens and dialogs

Figure 4-1 below shows a typical OOPS overtake warning.

Figure 4-1: Example of OOPS overtake warning

In this example, user PDANN is proposing to migrate transport C46K900014 to system A47.

OOPS has detected that this transport shares some common contents with transport C46K900010, which was released earlier but has not yet been migrated to A47.

The OOPS report shows the release dates of both transports, and shows that both transports share in common one or more entries in table /RSC/T_DEMO_SYST.

In this particular case, Rev-Trac is configured to allow users to ignore certain types of OOPS warnings. Consequently, when the user clicks the Back button on the SAP toolbar, OOPS displays the following dialog:

Figure 4-2: This dialog may be displayed if users are permitted to ignore some OOPS warnings

If the user clicks the Continue button, Rev-Trac allows the migration to proceed, and adds messages to the Approvals node for the Rev-Trac request concerned (see Figure 4-3 below) showing that:

•

•

OOPS detected a conflict

The user choose to proceed with the migration

Figure 4-3: Rev-Trac adds messages to the request Approvals node showing that a conflict was detected, and what the user chose to do

At the same time, Rev-Trac adds similar information to the Rev-Trac system log.



Some table data automatically excluded from OOPS checking

By default, OOPS checks both workbench objects and table data at a key level.

It is possible to turn off all OOPS checking of table data by entering a suitable over-ride (see OOPS over-rides on page 112).

Even when this over-ride has not been created, Rev-Trac excludes from OOPS checking certain tables whose contents are highly prone to benign overtaking and overwriting. These include:

• Tables with a delivery class of "A" (Application)

•

•

•

•

Tables whose names match the masks USR*, UST* and AGR_*

Table SPERS_OBJ

It is possible to turn to activate or deactivate OOPS checking of data from specific tables or groups of tables by entering a suitable OOPS rule. See How to exclude a specific object or table data from OOPS or lock checking on page 136 and How to activate OOPS or lock checking for only a small number of tables or objects on page 136.

OOPS pre-requisites

For OOPS to operate successfully, Rev-Trac needs to know which transports are located where in the landscape, what they contain, and when each transport was released.

Rev-Trac derives some of this information from standard SAP tables and tracks and stores other parts of this information in its own database.

Understanding how these details are captured and stored provides a valuable insight into the pre-requisites of successful OOPS operation.

When installing Rev-Trac, the installer runs a program that loads details of past transport movements in the landscape into a transport movement history database that is present in every system.

This database holds information about the source and date of every transport movement in a given system. The Rev-Trac Chronological, Active Matrix and System/Client Comparison reports read information in this database.

The transport movement history database comprises tables /RSC/T_MFM_4B and /RSC/T_MFM_4C.

After loading the transport movement history, the installer runs a second program that builds an OOPS database in every system. The OOPS database identifies what objects and data were carried by every transport.

The OOPS database comprises tables /RSC/T_MFM_4S and /RSC/T_MFM_4T.

Once Rev-Trac is operational, a Rev-Trac migration monitoring job runs in every target system after every migration. This job:

Updates the transport movement history database in the target system

Updates the OOPS database in the target system with details of what objects and data were migrated

An OOPS database refresh job runs nightly in the Rev-Trac master to ensures the OOPS database in every system is completely up-to-date.



Successful OOPS operation requires that:

• A complete (or reasonably complete) history of transport movements before the time Rev-Trac was installed has been loaded

If no migrations occurred in the landscape before Rev-Trac was installed, this is not required.

•

•

•

•

Rev-Trac's migration monitoring job is running in every target system after every migration

The OOPS refresh job is running nightly in the Rev-Trac master system

If you are unsure whether an adequate history of transport movements has been loaded, contact [email protected].

The migration monitor job is named /RSC/MIGRATION_MONITOR.

To determine whether this job is running regularly in every target system, execute the System health check report (Rev-Trac Console > Administration > Health check) in the Rev-Trac master system and select "Include Monitor Jobs report". The section of the report headed "Checking Monitor jobs (last date/time)" shows when the job last ran in each system.

The OOPS refresh job is named /RSC/OOPS_REFRESH.

To determine when the OOPS refresh job last ran in the Rev-Trac master system, search for a job running program /RSC/OP_CREATE_TX_SUMM_SUBMIT.

Configuring OOPS

OOPS behaviour in all systems under Rev-Trac control is determined by three areas of configuration in the Rev-Trac master system:

• The "OOPS" global parameter

This setting determines whether Rev-Trac will issue a warning or error if a users performs an action that could result in an overtake or overwrite.

Over-rides

By creating an over-ride, it is possible to define special OOPS behaviour for a particular system or user.

OOPS rules

By creating an OOPS rule, it is possible to define special OOPS behaviour for selected objects or tables.

The following sections describe these configuration areas in more detail.

'OOPS' global parameter

The "OOPS" global parameter is configured by selecting Configuration > Global > Global parameters from the Rev-Trac Console.

Four options are available:

Figure 4-4: OOPS global parameter options



In the Short text for this selection dialog, the term "migration" means migrations performed via the Rev-Trac Migration Workbench, while the term "auto-migration" or "Auto-Mig" means migrations performed automatically by Rev-Trac following the approval of a Rev-Trac request.

When OOPS = 0, Rev-Trac does not display any OOPS messages when it detects an overtake or overwrite will occur as the result of a migration via the Rev-Trac Migration Workbench or following the approval of a request.

When OOPS = 1, Rev-Trac issues an information message whenever it detects a potential overwrite or overtake, but allows the migration to proceed, regardless of how the migration is being performed.

Of the remaining options, OOPS = 2 is the more restrictive. When this option is selected, Rev-Trac blocks migration following the approval of a request if it detects that either an overwrite or overtake will occur.

The options OOPS = 3 is slightly more lenient. When this option is selected, Rev-Trac issues a warning following an approval if an overtake is detected, but displays the "OOPS Monitor Alert" dialog (see Figure 4-2 on page 109) and allows the migration to proceed if the user clicks the Continue button. However, Rev-Trac blocks migration unconditionally if it detects a potential overwrite following approval.

Regardless of what "OOPS" global parameter setting is selected, suitably authorized users can perform a "what if" check at any time to determine whether a particular migration action will result in an overtake or overwrite. For details, see How to perform a manual OOPS check on page 117.

Because it is always possible for force a migration to occur when migrating via the Rev-Trac Migration Workbench, even if this will result in an overtake or overwrite, access to the Rev-Trac Migration Workbench should be restricted.

OOPS over-rides

One way of fine-tuning the operation of OOPS is to enter an over-ride. Over-rides typically define special OOPS behaviour for a particular system or user.

To configure an over-ride from the Rev-Trac Console, select Configuration > Global > Advanced > Over-rides. Note that the Value column may be hidden by default. To expose this field, double-click anywhere within a row.

The following table lists over-rides that affect OOPS behaviour:



Parameter Sub Parameter 1

Sub Parameter 2

Value Effect

OOPS_CONFIG USER=* OFF Exempt all SAP configuration from OOPS checking.

OOPS_TAR_XXXXXX USER=* 0, 1, 2, or 3 Set the OOPS mode for the target group whose ID is XXXXX to the value entered in the Value field.

OOPS_SID_XXX USER=* 0, 1, 2, or 3 Set the OOPS mode for the system whose SID ID is XXX to the value entered in the Value field. This over-ride has no effect if user is performing a manual OOPS check (eg, from the Migration Workbench or from the Manage / view Rev-Trac migration queue function). If the OOPS mode for a specific target group is set to 0 (see OOPS_TAR_XXXXXX), the target group setting takes precedence over this setting).

OOPS_ID_XXXXXX USER=XXXXXX

0, 1, 2, or 3 Set the OOPS mode for the user whose SAP user ID is XXXXXX to the value entered in the Value field. This over-ride has no effect if user is performing a manual OOPS check (eg, from the Migration Workbench or from the Manage / view Rev-Trac migration queue function). If the OOPS mode for a specific target group or system is set to 0, these settings take precedence over this one.

OOPS_CHECK_DFE USER=* OFF OOPS normally does not report an overtake if the transport data file is missing from its normal location (for example, if the transport has been quarantined). If OOPS detects an overtake and this over-ride is present with a value of OFF, OOPS will report the overtake.

BUILD_CONFIG_SUMMARY USER=* OFF If Value is OFF, the Rev-Trac OOPS refresh job, scheduled to run every night, does not build configuration summary information in table /RSC/T_MFM_4T. Rev-Trac requires this information if either OOPS or Locking for SAP configuration are active. However, if neither is in use, it is possible to set this parameter to OFF.

OOPS_REVERT_STATUS USER=* ON If Value is ON, Rev-Trac automatically reverts the status of a request following an unsuccessful post-approval OOPS check. Otherwise, the user is given the option whether to revert the request's status or not.

Table 4-1: Over-rides that affect OOPS behaviour

OOPS rules

Another way of fine-tuning OOPS behaviour is to create entries in the OOPS and Locking rules list that define special OOPS behaviour for particular objects or tables.



By creating entries in this list you can, for example:

•

•

•

Cause OOPS to check data at a table (high) level, rather than at a table key (low) level for all tables, or for particular groups of tables, thus improving OOPS performance

Exclude specific tables or objects from OOPS checking

Force OOPS checking for specific objects, while excluding all other objects of a similar type from checking

The OOPS and Locking rules list defines rules that control the behaviour of both OOPS and the Rev-Trac locking system.

For details, see OOPS and Locking rules on page 135.

Why am I getting this OOPS message?

Rev-Trac users occasionally receive OOPS messages that appear puzzling at first sight, but for which there is a legitimate explanation.

The following sections describe several common situations.

'Overtake' of transport already migrated to target

For discussion's sake, assume that DEVK900033 contains an early version of an ABAP program, and DEVK900044 contains a later version of the same program.

DEVK900033 was migrated to QAS in June.

When a user attempts to migrate DEVK900044 to QAS in November, Rev-Trac reports that this transport will overtake DEVK900033.

Why is Rev-Trac reporting an overtake when DEVK900033 has already gone to QAS?

Possible explanations

One possible explanation is that although DEVK900033 was migrated to QAS in June, the changes carried by this transport are no longer present in QAS because QAS was refreshed from another system or because QAS has been imperfectly restored.

To determine whether DEVK900033 is still present in QAS, the user should attempt to display the object list of DEVK900033 in QAS (not in DEV) via transaction SE01. If the transport's object list cannot be displayed, this normally indicates that the transport's contents are not present in this system.

Another possible explanation is that while the transport was imported into QAS, the migration did not succeed.

A third possibility is that the Rev-Trac migration monitor job may not be scheduled in QAS. If this is the case, Rev-Trac might be unaware of DEVK900033's presence in that system.

To check when the migration monitor job last ran in any system, run the Health check report (Rev-Trac Console > Administration > Health check), selecting the option Include Monitor Jobs report.

'Will overwrite foreign'

Under some circumstances, Rev-Trac may issue an OOPS message such as "DV2K900200 will overwrite foreign DEVK900100".



Figure 4-5 below illustrates a typical situation in which Rev-Trac may issue a "Will overwrite foreign" message. A transport is about to be migrated from DV2 to QAS that contains object ZZ_TAX. A transport was previously migrated from DEV to QAS that also contains an object called ZZ_TAX. This DEV transport is not present in DV2.

DEVK900100 ZZ_TAX

QA2

Func = 2

DV2

PRD DEV QAS

Func = 2

DV2K900200 ZZ_TAX

Landscape 1

Landscape 2

Figure 4-5: Example of migration that could trigger "Will overwrite foreign" OOPS message

OOPS issues a "Will overwrite foreign" message if it detects that the last transport in the destination system that affected an object or table entry about to be transported is a "foreign" transport.

A transport is "foreign" if it is not present in the "OOPS source system". This is the system Rev-Trac searches for potential overtaking and overwriting transports when migrating a transport to a target.

Rev-Trac uses the following logic to determine the OOPS source system:

•

•

If the transport being migrated was created in a Rev-Trac development system, the OOPS source is the system where the transport was created.

In the example shown in Figure 4-5 above, the OOPS source is DV2.

If the transport was created in an external system not under Rev-Trac control, the OOPS source is the development system belonging to the same Rev-Trac landscape as the target, provided the external transport has previously been imported into this development system. If it has not, the OOPS source is the first Rev-Trac development system into which the transport was imported.

In the example above, because the last transport to affect object ZZ_TAX in QAS (DEVK900100) is not present in DV2, OOPS issues a message indicating that DV2K900200 will overwrite the "foreign" transport DEVK900100 in QAS.

Rev-Trac issues an overwrite warning in these circumstances because there is no guarantee the objects present in both transports are in fact two different versions of the same object or data. They may actually be two quite different entities that happen to share the same object ID or key.

The only way to determine for certain whether the migration can proceed safely is to examine manually the apparently conflicting contents of each transport and determine whether the contents currently in the destination system may safely be changed.



You can suppress 'will overwrite foreign' OOPS warnings for specific foreign transports by including these in a Rev-Trac transport list and adding a suitable over-ride. For details, see How to suppress 'will overwrite foreign' warnings for specific foreign transports on page 121.

'OOPS has not checked actual table entries'

Under some circumstances, Rev-Trac may issue an OOPS message with the text "Possible conflict only. OOPS has not checked actual table entries."

This occurs only if OOPS is configured to perform table level, rather than key level, checking for the table concerned. In effect, Rev-Trac is warning that a potential overwrite or overtake is about to occur.

After seeing a warning of this kind, the user should either:

• Check manually if a key-level conflict exists between two transports carrying table data (to see whether an actual overtake or overwrite would occur), then change the migration sequence if necessary, or

• Change the migration sequence without checking for a key level conflict in order to avert any possibility of an overtake or overwrite

For details of how to activate table level OOPS checking, see How to activate table-level OOPS checking on page 137.

Imp (import) date in OOPS report shows future date

An OOPS report may show the date and time when a transport being overwritten or overtaken was - or, notionally, will be - imported into the migration target system. This real or notional import date is shown with an entry beginning "Imp" in the OOPS report (see Figure 4-6 below).

Figure 4-6: Example of OOPS report where Imp dates occur later than time when OOPS report was generated

In some situations, the date listed as the Imp date may be a date in the future.

For example, in Figure 4-6 above, the OOPS check was performed at 9 June 2005 at 11:16 (see top line of report), while the OOPS report shows the import times of both transports into QAS as occurring approximately 12 hours after this time.

A notional future date/time appears as the Imp date in an OOPS report only in situations where the transport reported as being overtaken or overwritten is itself one of transports being checked.

In the example shown in Figure 4-6, a user was proposed to migrate both DEVK900790 and DEVK900788 at the same time (but in the wrong sequence).



When determining whether the proposed migration sequence for all the transports being checked is correct, Rev-Trac assigns a notional future date and time of import to each transport based on their proposed migration sequence. If Rev-Trac detects a sequencing error, the OOPS report shows this notional future import date.

OOPS procedures


• How to perform a manual OOPS check of the Rev-Trac migration queue, or of transports listed on the Migration Workbench

•

•

•

•

•

How to retrieve past OOPS messages

How to quarantine a transport

How to list quarantined transports

How to perform a manual OOPS check

From time to time, users may want to check whether migrating a particular transport or transports in a given sequence will result in an overtake or overwrite without actually committing themselves to migrating the transport/s.

There are two ways to perform such a check:

Populate the Rev-Trac Migration Workbench with the transport/s and target group, then select Analyse > OOPS check

For details on how to populate the Rev-Trac Migration Workbench, see Populating the Workbench on page 92. Note that the OOPS check result is valid only if the transport or transports being checked originate from the system that normally supplies transports for this target group.

To perform an OOPS check on all transports currently in the Rev-Trac migration queue, display the queue, then select Queue > OOPS check

For details on how to display the Rev-Trac migration queue, see Displaying the queue on page 75.

If Rev-Trac determines that the transports being checked need to be analysed in different OOPS source systems, a dialog like the one shown in Figure 4-7 below is displayed, and users are required to check discreet subgroups of transports separately. (For a discussion of how Rev-Trac determines the OOPS source system, see 'Will overwrite foreign' on page 114.)



Figure 4-7: This dialog is displayed for a manual OOPS check if transports need to be analysed in different OOPS systems

How to perform a retrospective OOPS check

It is possible to perform a retrospective OOPS check showing what overtakes and overwrites occurred in the past in regard to a specific migration destination.

Using this method, it is possible to identify overtakes and overwrites that took place before Rev-Trac was installed, provided the transport movement history for the period concerned has been loaded.

To perform a retrospective OOPS check, follow these steps:

1. In transaction SE38, execute program /RSC/OP_OVERTAKE_REPT. The "RSC - Check for overtake/overwrite" selection screen is displayed.


Field Description

Target system The migration destination system.

Migration date The range of dates for which you want to perform the check.

Include component detail

Select this checkbox if you want Rev-Trac to display details of the transport component(s) where a conflict occurred.

3. Execute the program. If no overtakes or overwrites are detected, no output is displayed. Otherwise, Rev-Trac displays details of past overtakes and overwrites.



How to retrieve historical OOPS messages and action records

Rev-Trac stores the detailed texts of all OOPS messages it has ever displayed, together with action records, where appropriate, indicating whether or not a user proceeded with a migration when given a choice.

These details can be retrieved later in two ways:

•

•

By expanding the Approvals node of the Rev-Trac request concerned when the request is displayed on the Rev-Trac Workbench

This approach is useful if the relevant Rev-Trac request number is known.

By searching the Rev-Trac system log

This is the best approach if the approximate date of the warning or the ID of the user who received the warning are known, but the Rev-Trac request number is unknown or no Rev-Trac request is involved.

Retrieving OOPS messages and action records via the Rev-Trac Workbench

If Rev-Trac has displayed an OOPS message as the result of a user's approving a request, the Approvals node of the request as displayed on the Rev-Trac Workbench will contain one or more entries similar to the following:

Figure 4-8: OOPS audit trail displayed under Approvals node of Rev-Trac request

The first entry in Figure 4-8 above is a link to the actual OOPS message that Rev-Trac originally displayed to the user named in the text.

Double-clicking this entry displays the original OOPS message text:

Figure 4-9: The original OOPS message text can be displayed by double-clicking the first "Message logged" line

The second entry in Figure 4-8 is an OOPS action record. In this example, the action record shows that the user chose to proceed with the migration after seeing the OOPS warning.

Retrieving OOPS messages and action records via the Rev-Trac system log

The Rev-Trac system log contains details of all past OOPS messages and action records, including messages that were displayed to users working with the Rev-Trac Migration Workbench.

To retrieve OOPS messages and action records via the Rev-Trac system log, perform the following steps:



1. From the Rev-Trac Console, select Administration > System log. The "RSC - Display Rev-Trac system log" screen is displayed.

2. Complete some or all of the following fields:

Field Description

Date Date of OOPS message.

Time Time of OOPS message.

User id User ID of user whose action triggered the OOPS message.

Message number

To display only "OOPS conflicts found" messages, type 454. To display only "Stop button selected" messages, type 475. To display only "Ignore button selected" messages, type 476.

Rev-Trac Request

Number of Rev-Trac request containing transport which has been subject of an OOPS message

3. Select Program > Execute. The selected Rev-Trac system log entries are displayed.

4. Optional: To display the actual OOPS error message for an "OOPS conflict found" message, click the page icon to the right of the logged user ID. The full OOPS error message is displayed.

How to quarantine a transport

If a user has determined that it is safe to migrate a later version of an object or data without first migrating an earlier version of the same object or data, then it makes good sense to remove from the transport directory the data file of the transport carrying the earlier version.

This process is known as "quarantining" the transport.

Quarantining a transport ensures it is never migrated accidentally. Furthermore, because OOPS by default does not report an overtake of a transport whose data file is missing from the transport directory, quarantining a to-be-overtaken transport can be a legitimate way of addressing an OOPS overtake warning.

It is possible to quarantine a transport using operating system commands.

An alternative approach is to use Rev-Trac's quarantine utility to perform this action. This utility quarantines files from all development systems in a central location. The utility allows for the selection of transports by Rev-Trac request number, by target system and by transport list, and takes a consistent approach to removing − and, if necessary restoring − both the transport data and the single-step log files.

Before using Rev-Trac's quarantine utility for the first time, create an operating system directory accessible to your Rev-Trac master system where the quarantined files will be stored (eg, /usr/sap/trans/quarantine). The system account of your Rev-Trac master system must be able to read and write to this directory.



To quarantine one or more transports using the Rev-Trac quarantine utility, perform the following steps:

1. From the Rev-Trac Console of the master system, select Migration > Tools > Quarantine transports The "RSC - Quarantine transports" screen is displayed.

2. Select the transport/s to be quarantined by completing one or more of the following fields:

Field Description

Transport number

Transport number.

Rev-Trac request

Rev-Trac request number.

Transport list Rev-Trac transport list. For details on how to create a Rev-Trac transport list from within some Rev-Trac migration reports, see Using landscape snapshots and transport lists with migration reports on page 105.

Transport into system / more than x days ago

SID of system concerned. Number of days.

3. If necessary, modify the default entry in the App svr quarantine directory field. This path represents the location where the quarantined transport files will be stored.

4. Clear the Test (no update) checkbox. Ensure Archive files is selected, then select Program > Execute. The "RSC - Quarantine transports" screen lists the files moved with the text "move verified".

How to suppress 'will overwrite foreign' warnings for specific foreign transports

You can suppress 'overwrite foreign' OOPS warnings for specific foreign transports by including the foreign transports in a Rev-Trac transport list, then entering a suitable Rev-Trac over-ride.

For details on how to create a Rev-Trac transport list, see Creating a transport list using the Migration Workbench on page 95.

To enter a suitable over-ride, do the following:

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

2. Put the screen into change mode, select Edit > New entries, then complete the following fields.

Note: The Value column may be hidden by default. To expose this field, double-click anywhere within a row.

Field Description



Parameter Type " OOPS_SUPPRESS_FOREIGN "

Sub Parameter 1 Type "TRANSPORT_LIST".

Sub Parameter 2 Type "USER=*".

Value Type the ID of the Rev-Trac transport list that contains foreign transports to be excluded from OOPS overwrite foreign checking.


For more information on 'will overwrite foreign' warnings, see 'Will overwrite foreign' on page 114.


The risks associated with overtaking and overwriting (see What are overtaking and overwriting? on page 107) are significantly reduced if all transports that affect a particular object or set of configuration are attached to the same Rev-Trac request.

Consistently following this work practice helps ensure that transports affecting a particular object or set of configuration are migrated in the correct sequence, and reduces the incidence of OOPS warnings or errors.

The primary purpose of the Rev-Trac locking system is to help enforce this work practice.

A further benefit of compelling users to associate all transports affecting a particular object or set of configuration with the same Rev-Trac request is that this minimises the risk of inadvertent parallel development.

What exactly is the risk?

Let's assume two developers are working more or less concurrently on different parts of a large program. Neither has become aware of the other's interest in the program through the SAP locking system, as each developer has been rapidly releasing the relevant transports to allow testing in QAS to proceed.

Following successful testing of her own set of changes in QAS, the first developer decides these changes are ready to be migrated to PRD. She is unaware that the other developer's unrelated changes to another part of the same program have not yet been tested.

If the program was now migrated to PRD following the first developer's "successful" testing, the results could be very unfortunate as the untested changes are moved into production.

It may be helpful to view the Rev-Trac locking system as an extension of the SAP locking mechanism. However, there are some significant differences between the two, and the technologies used to implement each are quite different. The following table outlines some key areas of difference:



SAP locking mechanism Rev-Trac locking system Workbench objects may be locked, but table data (eg, SAP configuration) may not

Both workbench objects and table data may be locked

Objects are locked to a transport Objects and table data are locked to a Rev-Trac request Locks are permanently relinquished when a transport is released.

Locks are relinquished when a Rev-Trac request enters a status where locks are not held, but are reactivated if the request subsequently enters a status where locks are held

An object may be locked to only one transport An object or table data may be locked to multiple Rev-Trac requests

Table 4-2: Key differences between SAP locking concept and Rev-Trac locking system

While the primary purpose of the Rev-Trac locking system is to ensure that all transports affecting a particular object or table data are associated with the same Rev-Trac request, this is not always feasible for practical reasons. It is therefore possible for a suitably authorized user to work around this restriction by permitting parallel development of the object or table data in another Rev-Trac request where necessary. For details, see How to permit parallel development in another Rev-Trac request on page 130.

SAP locks are released when a transport is released, and cannot be reapplied to the same transport. By contrast, Rev-Trac locks are released when a request reaches the status "Complete" or any status that has been explicitly configured to release locks, and are reactivated if the request subsequently enters a status where locks are held. For more details, see Per status setting: the status 'Lock mode' on page 127.

Rev-Trac automatically logs details of locking system messages and user actions such as the granting of parallel development permissions in the Rev-Trac system log, and these details can be retrieved later for audit purposes (see How to retrieve historical lock messages on page 134).

It is possible to fine tune the behaviour of the Rev-Trac locking system for particular users or systems (see Rev-Trac locking system over-rides on page 128), or for selected objects or tables (see OOPS and Locking rules on page 135).

Example screens and dialogs

When a user makes a change to an object or table data that is already locked to a Rev-Trac request, the Rev-Trac enforcement popup displays the name of the object or table data and the number of the Rev-Trac request/s to which this object or table data is already locked, as seen in the screenshot below.



Figure 4-10: Rev-Trac enforcement popup with message indicating that particular CDAT data is locked to Rev-Trac request number 2

In such a situation, a user would normally type the number of the Rev-Trac request to which the object or table data is already locked (in this case, 2") in the empty field at the right of the popup, then click the Generate the transport from Rev-Trac request number button.

If this was not an appropriate course of action for any reason, the user could seek to initiate a parallel development of this object or data in another Rev-Trac request, normally after discussing the situation with the owner of the original Rev-Trac request to which the object or data is locked. For details of how to perform this procedure, see How to permit parallel development in another Rev-Trac request on page 130.

In the following screenshot, a user is about to open the object already locked to Rev-Trac request number 2 for parallel development in Rev-Trac request number 4:

Figure 4-11: User is about to permit development of R3TR-CDAT-/RSC/C_DEMO_SYST in Rev-Trac request number 4

After permission for parallel development has been granted, Rev-Trac displays the following dialog to confirm the change.



Figure 4-12: Rev-Trac confirms that permission has been granted for parallel development of the named item to occur in Rev-Trac request number 4

Once permission has been granted to develop an object or table data in another Rev-Trac request, the locking message on the Rev-Trac enforcement popup is updated to reflect this change.

In the example below, the user can now choose to generate and insert a transport carrying changes to R3TR-CDAT-/RSC/C_DEMO_SYST in either Rev-Trac number 2 or 4.

Figure 4-13: Locking message on Rev-Trac enforcement popup shows object is locked to multiple Rev-Trac requests after permission has been granted for parallel development

As noted previously, Rev-Trac automatically logs details of locking system messages and user actions such as the granting of parallel development permissions.

The following screenshot shows two such messages saved in the Rev-Trac system log:

Figure 4-14: The Rev-Trac system log tracks the granting of parallel development permissions, and all instances of locking messages

Rev-Trac locks table data at table, not table key, level

OOPS may be configured to check for overwrites and overtakes at either the table level, or at the table entry (key) level. For details, see About OOPS table- versus key-level checking on page 136.

By contrast, the Rev-Trac locking system checks and enforces locks only at a table level.



Rev-Trac locking of logical transport objects

Certain transportable objects are recorded in the object list for a transport under an object type and name, but are actually transported as table entries, usually for multiple tables. These objects are known as logical transport objects. Transaction SOBJ shows the underlying tables for every logical transport object. SAP locks some logical transport objects (for example, SAPScript forms R3TR-FORM) but does not lock others (for example, asset history sheet definitions R3TR-AM10). The Rev-Trac locking system treats lockable logical transport objects just like workbench objects, and checks and reports locks at the object directory level (ie, as seen in the transport object list). For non-lockable logical transport objects, Rev-Trac's locking behaviour now depends on whether the transport carrying the object has been released. If the transport has been released, the Rev-Trac locking system treats the object like a workbench object, and reports locks at the object directory level. If the transport has not been released, the Rev-Trac locking system checks to see if there are other Rev-Trac requests currently in a lock-holding status (see Per status setting: the status 'Lock mode' on page 127) that will transport any data from the same underlying table(s). If so, Rev-Trac enforces a table level (not object directory level) lock, and each Rev-Trac request against which a table-level lock is being enforced is flagged with a preceding asterisk in the locking message displayed to the user.

Rev-Trac locking system pre-requisites

The following pre-requisites must be satisfied for successful Rev-Trac locking system operation:

•

•

•

•

•

•

Rev-Trac enforcement must be active for the user concerned

The instance parameter "abap/fieldexit" must be set to "yes" and active in each development system

Field exits for data elements TRKORR and TRORDERTXT must be activated in each development system.

Rev-Trac's migration monitoring job must be running in every target system after every migration

The Rev-Trac OOPS refresh job must be running nightly in the Rev-Trac master system

For more details on the migration monitoring and OOPS refresh jobs, see OOPS pre-requisites on page 110.

Configuring the Rev-Trac locking system

Provided the relevant prerequisites have been satisfied (see Rev-Trac locking system pre-requisites on page 126), the behaviour of the Rev-Trac locking system in all development systems under Rev-Trac control is determined by four areas of configuration in the Rev-Trac master system:

The "Lock" system parameter for the system concerned



This setting determines whether Rev-Trac locking system is activated in the system, and if so, whether locks are checked only for transports present in the same development system, or across all development systems under Rev-Trac control

• The lock mode (ie, lock-holding behaviour) set for each request status

Rev-Trac locks are released when a Rev-Trac request reaches a non-lock-holding status, and are reactivated if the request subsequently enters a lock-holding status.

•

•

•

•

Over-rides

By creating an over-ride, it is possible to define special Rev-Trac locking system behaviour for a particular user, or for a particular combination of systems.

For example, it is possible to configure the CRM development to check locks against the R/3 development system, but not against BWD. Or it is possible to exempt a particular user from all lock checking.

It is also possible to turn off locking for table data (eg, SAP configuration).

Rev-Trac locking system rules

By creating a Rev-Trac locking system rule, it is possible to define special locking behaviour for particular objects or tables, or for groups of objects or tables.

The following sections describe the first three of these configuration areas.

Rev-Trac locking system rules are discussed jointly with OOPS rules. See OOPS and Locking rules on page 135.

System-wide setting: the 'Lock' system parameter

The Lock parameter for each system determines whether the Rev-Trac locking system is activated in the system concerned, and if so, whether Rev-Trac checks locks:

Only within that system (intra-landscape locking), or

Between that system and all other systems (cross-landscape locking)

The Lock parameter for every system is configured in the Rev-Trac master system via Rev-Trac Console > Configuration > Systems > Systems > System parameters.

When locking is turned on via the Lock system parameter, it is turned on for both workbench objects and table data.

Per status setting: the status 'Lock mode'

As discussed previously, there are significant differences between the way SAP manages its locks on workbench objects, and the way Rev-Trac manages locks on workbench objects and table data. Table 4-2 on page 123 summarises these differences.

One such difference is that while SAP locks are released when a transport is released, and cannot be reapplied to the same transport, Rev-Trac locks are released when the relevant Rev-Trac request reaches a non-lock-holding status, and are reactivated if the request subsequently enters a lock-holding status.

The Rev-Trac status "Complete" is automatically defined in Rev-Trac code as non-lock-holding. This means that whenever a Rev-Trac request



reaches the status "Complete", all locks associated with the request are released.

However, it is possible to define any Rev-Trac status as non-lock-holding. To do so, follow these steps:

1. From the Rev-Trac Console, select Configuration > Process > Strategies > Statuses. The “Display View ‘Status types’: Overview” screen is displayed.

2. Select Table view > Display -> Change to put the screen in change mode.

3. In the Lock mode column, select 1 (Don't lock objects on Rev-Trac requests in this status) for each status you want to define as non-lock-holding.


Rev-Trac locking system over-rides

The table below lists over-rides that affect Rev-Trac locking system behaviour.





Sub Parameter 2 Value Effect

LOCK_CONFIG USER=* OFF, WARNING

If Value is OFF, Rev-Trac silently exempts all SAP configuration from checking by the Rev-Trac locking system. If Value is WARNING, Rev-Trac warns that an SAP configuration change is locked to another Rev-Trac request, but allows the change to be placed in a different request. A limitation of the WARNING setting is that it is effective only the first time contents are added to a new transport. Rev-Trac does not issue warnings for any further objects added to the same transport, even if these objects are, in fact, locked to other Rev-Trac requests.

LOCK_ID_XXXXXX USER=XXX OFF Turn off locking error messages for the user whose SAP user ID is XXX.

LOCK_CROSS_FSY>TSY USER=* OFF, ON If intra-landscape locking is active ("Lock" system parameter = 2) this over-ride can force lock checking between systems where lock checking would otherwise not occur. Conversely, if cross-landscape locking is active ("Lock" system parameter = 1) this over-ride can prevent lock checking between specific systems. For the letters FSY (From System) and TSY (To System) substitute the SIDs of the systems concerned. To turn off lock checking that would otherwise occur, enter a Value of OFF. To turn on locking that would not otherwise occur, enter a Value of ON. Example: LOCK_CROSS_DV1>DV2 USER=* OFF When user makes a change in DV1, Rev-Trac will not check if the same object or table data has been changed in DV2. However, if a user makes a change in DV2, Rev-Trac will continue to check if the same object or table data has been changed in DV1.

LOCK_PROJ_PPPP>SYS USER=* OFF Unwanted locking messages may occur when making changes in a system (eg, CRD) whose "Lock" system parameter is set to "intra-landscape locking" if a transport containing the changed object is also present in another system (eg, DEV) − for example, as the result of a migration or because one system is a clone of another. Thus, when a user changes an object in CRD, Rev-Trac may indicate the object is locked to a Rev-Trac request that is part of project MINX in DEV if a transport affecting the changed object is also present in DEV. In this example, the unwanted locking messages could be eradicated by creating the Parameter LOCK_PROJ_MINX>CRD with the Value OFF. When creating the Parameter for this over-ride, substitute the Project code of the Rev-Trac project whose requests are holding




Sub Parameter 2 Value Effect

unwanted locks for PPPP. Substitute the SID of the system being changed when the unwanted lock message is displayed for SYS.

LOCK_PROJECT_STATUS PPPP>SSSS USER=* OFF Turns off locking messages for Rev-Trac requests in project PPPP that are in status SSSS. For PPPP, substitute the name of a Rev-Trac project. For SSSS, subtitute a request status. Use this over-ride if status SSSS should usually hold Rev-Trac locks, but should not hold locks in project PPPP.

BUILD_CONFIG_SUMMARY

OFF If Value is OFF, the Rev-Trac OOPS refresh process, scheduled to run every night, does not build configuration summary information in table /RSC/T_MFM_4T. Rev-Trac requires this information if either OOPS or Locking for SAP configuration are active.

Table 4-3: Over-rides that affect Rev-Trac locking system behaviour

Rev-Trac locking system procedures

The following topics describe how to:

•

•

•

•

•

Permit parallel development in another Rev-Trac request

Rescind a parallel development permission granted in error

Identify parallel development permissions granted, rescinded or currently active

Retrieve historical lock messages

Turn off locking for table data, while enforcing locks for workbench objects

How to permit parallel development in another Rev-Trac request

When a user attempts to change an object or table data already locked to a Rev-Trac request, Rev-Trac displays a popup such as this:



Figure 4-15: Locking message on Rev-Trac enforcement popup shows table data is already locked to a Rev-Trac request

In this example, R3TR CDAT /RSC/C_DEMO_SYST is locked to Rev-Trac request number 2. The user must place any new transport carrying this data in request number 2.

The procedure below describes how to permit parallel development of an object or table data in an additional Rev-Trac request.

After this has occurred, Rev-Trac will display a popup such as this, showing that development is now permitted in an additional request:

Figure 4-16: Rev-Trac enforcement popup showing development is now permitted in an additional Rev-Trac request

If a user has accidentally permitted parallel development of an object or data in the wrong Rev-Trac request, it may be possible to rescind this permission. See How to rescind a parallel development permission granted in error on page 133.

Pre-requisites

Before permitting parallel development of an object or table data in an additional Rev-Trac request, the additional Rev-Trac request must already exist.

Steps

1. Seek the consent of the owner of the Rev-Trac request to which the object or data is currently locked for permitting parallel development of this object or data in a separate Rev-Trac request.

2. Do one of the following: If Rev-Trac has already displayed a locking message like the one

shown in Figure 4-15, go to step 3 Otherwise, go to step 8

3. From the Rev-Trac Console, select Administration > System log. The "RSC − Display Rev-Trac system log" screen is displayed.

4. Complete some or all of the following fields to select a locking message Rev-Trac has previously displayed for this object or table data:

Field Description

Date Date of locking message.

Time Time of locking message.



User id ID of user to whom Rev-Trac displayed locking message.

Show parallel devel. messages

Select.

5. Select Program > Execute. Rev-Trac lists previously-displayed locking messages..

6. Select a line in the log that refers to the object or table data for which you want to permit parallel development, then select Parallel Development > Allow parallel dev. An information dialog is displayed with the message "Please select the execute button on the following screen". Close the dialog box. The "RSC - Parallel development of objects" screen is displayed with the Program ID, Object type and Object Name values completed.

7. In the Request field, enter the number of the Rev-Trac request where you intend to allow parallel development of this object, then select Program > Execute. A dialog box indicates that parallel development of this object is now allowed in this Rev-Trac request. No further action is required.

8. [This step succeeds step 2.] From the Rev-Trac Console, select Request Management > Tools > Develop in parallel. The "RSC − Develop in parallel" screen is displayed.


Field Description

Allow parallel development

Select.

Program ID The program ID of the object or data for which parallel development is to be permitted. Example: R3TR

Object type The object type of the object or data. Example: CDAT

Object Name The object name of the object or data. Example: /RSC/C_DEMO_SYST

Rev-Trac Request

The number of the additional Rev-Trac request in which parallel development is to be permitted.

Note: This is not the number of the Rev-Trac request to which the object or data is currently locked.

10. Select Program > Execute. A dialog is displayed indicating that parallel development of this object or table data is now permitted in the Rev-Trac request specified in the previous step.



How to rescind a parallel development permission granted in error

If a user has accidentally permitted parallel development of an object or data within a given Rev-Trac request, but has not yet inserted a transport containing that object or data into the request, it is possible to rescind permission for this parallel development by using the following procedure:

1. From the Rev-Trac Console, select Administration > System log. The "RSC − Display Rev-Trac system log" screen is displayed.

2. Complete some or all of the following fields to select the message Rev-Trac previously displayed when permitting parallel development for this object or table data:

Field Description

Date Date when permission for parallel development was granted.

Time Time permission was granted.

User id ID of user who permitted parallel development to occur.

Show parallel devel. messages

Select.

3. Select Program > Execute. Rev-Trac lists previously-displayed messages relating to parallel development.

4. Select the line in the log that refers to permission you want to rescind, then select Parallel Development > Disallow par'l dev. A dialog is displayed with the message "Please select the execute button on the following screen". Close the dialog box. The "RSC - Parallel development of objects" screen is displayed with the Rev-Trac Request, Program ID, Object type and Object Name values completed.

5. Select Program > Execute. A dialog is displayed indicating that parallel development in this request for this object is now disallowed.

How to identify parallel development permissions granted, rescinded or currently active

It is possible to identify all occasions where a user has either permitted parallel development to begin, or has rescinded permission for parallel development, by searching the Rev-Trac system log (Rev-Trac Console > Administration > System log).

Messages logged when permission has been granted for parallel development have message number 37.

Messages logged when permission for parallel development has been rescinded have message number 38.



No report is currently available that lists all currently-effective parallel development permissions (that is, permissions that have been granted which have not also been rescinded). However, this information is stored in table /RSC/T_MF_4L, and may be viewed in its raw form using transaction SE16.

How to retrieve historical lock messages

Locking messages such as those shown in Figure 4-10 on page 124 are saved in the Rev-Trac system log with message number 34.

To retrieve an historical lock message, search the Rev-Trac system log (Rev-Trac Console > Administration > System log) for messages with this number.

How to turn off locking for table data, while enforcing locks for workbench objects

1. From the Rev-Trac Console, select Configuration > Systems > Systems > System parameters. The "Display View 'System parameters': Overview" screen is displayed.

2. Select Table view > Display -> Change to put the screen in change mode.

3. For each system where you want to turn off locking for table data while enforcing locks for workbench objects, type either "1" or "2" in the Lock field.

Note: The effect of this setting on its own is to turn on locking for both workbench objects and table data.

4. Return to the Rev-Trac Console, then select Configuration > Global > Advanced > Over-rides. The "Display View 'Over-rides': Overview" screen is displayed.



Field Description

Parameter Type "LOCK_CONFIG"

Value To suppress locking system messages for SAP configuration entirely, type "OFF". To display locking system warning messages for SAP configuration while still permitting parallel development, type "WARNING".




OOPS and Locking rules

You can fine-tune the operation of both OOPS and the Rev-Trac locking system by creating entries in the OOPS and Locking rules list (Rev-Trac Console > Configuration > Global > Advanced > OOPS & Locking rules).

By doing so, you can:

•

•

•

Exclude specific tables or objects from OOPS or lock checking

Cause OOPS to check table data at a table (high) level, rather than at a table key (low) level − resulting in faster checking

Force OOPS or lock checking for specific objects, while excluding all other objects of a similar type from checking

For example, you can force lock checking for data in specific tables, while excluding data in all other tables from lock checking.

As OOPS and Locking rules allow objects to be defined using wildcards, it is possible to define rules for large groupings of tables (even for all tables) and workbench objects using this technique.

Furthermore, because fully-qualified rules (ie, rules specified without wildcards) are evaluated with a higher priority than rules containing wildcards, it is possible to turn on OOPS checking or lock checking for specific items, while turning off checking for all other items in the same category.

The following table represents a set of OOPS and Locking rules that illustrates these possibilities. The contents of this table are discussed in more detail below.

Program ID Obj Object ID OOPS mode Lock mode

R3TR REPS ZZ123456 1 1 R3TR TABU * 1 1 R3TR TABU T00* 2 0 R3TR TABU T001 0 1 R3TR VDAT V_T308 0 0 R3TR TABU T308 2 1

Legend OOPS mode = 0 OOPS check at key level OOPS mode = 1 No OOPS check OOPS mode = 2 OOPS check at table level Lock mode = 0 Lock check Lock mode = 1 No lock check

Table 4-4: Example of OOPS and Locking rules



How to activate OOPS or lock checking for only a small number of tables or objects

To activate OOPS or lock checking for a small number of tables or objects:

1. Turn on checking centrally. To do so for OOPS, see 'OOPS' global parameter on page 111 To do so for the Rev-Trac locking system, see System-wide

setting: the 'Lock' system parameter on page 127.

Turn off checking for all objects or tables by entering a wildcard entry in the OOPS and Locking rules list

2.

Turn on checking for a specific object or group of objects by entering a more specific entry in the OOPS and Locking rules list

3.

Table 4-4 above illustrates how to perform the second and third of these steps.

The second entry in the OOPS and Locking rules list turns off OOPS checking for all ("*") TABU entries. If we assume that OOPS checking is turned on globally, the effect of this setting will be to exclude all table data from OOPS checking.

However, the third, fourth and sixth entries also affect TABU entries, and in each case the effect is to turn on OOPS checking, either at table level or key level, for the tables specified.

The net effect of this configuration is to turn off OOPS checking for all table data other than for the tables specifically listed for inclusion.

A similar approach may be used with lock checking.

How to exclude a specific object or table data from OOPS or lock checking

By adding suitable entries to the OOPS and Locking rules list, you can exempt certain objects or table data from OOPS or lock checking.

Some table data is automatically exempted from OOPS checking without the need to create explicit OOPS and Locking rules (see Some table data automatically excluded from OOPS checking on page 110).

There may be other types of table data, too, that are prone to benign overtaking and overwriting which it would also make sense to exempt from OOPS checking.

The first entry in Table 4-4 on page 135 illustrates how to exclude an object (in this case a specific program) from OOPS and lock checking.

Both the OOPS mode and Lock mode for program ZZ123456 have been set to "1" in the OOPS and Locking rules list.

As a result, Rev-Trac will not perform either OOPS or lock checking for this object.

About OOPS table- versus key-level checking

As the legend of Table 4-4 on page 135 indicates, an option is available within OOPS and Locking rules that requires Rev-Trac to perform OOPS checks of table data at a table level, rather than at a key level.

This results in much faster OOPS checking for table data, although with some trade-off in precision.



If Rev-Trac detects a potential table-level overtake or overwrite when this setting is in effect, the OOPS warning text includes the following alert:

Figure 4-17: Rev-Trac issues this alert as part of any OOPS warning when table (not key) level checking is active for the table concerned

In effect, Rev-Trac is issuing a warning that a potential overwrite or overtake is about to occur.

After seeing a warning of this kind, a user should either:

• Check manually if a key-level conflict exists between two transports carrying data for a particular table (to determine whether an actual overtake or overwrite would occur), then change the migration sequence if necessary, or

•

•

Change the migration sequence without checking for a key level conflict in order to avert any possibility of an overtake or overwrite

It is not possible to turn on table level OOPS checking for table data via the "OOPS" global parameter.

How to activate table-level OOPS checking

The third entry in Table 4-4 above illustrates how to activate table-level, rather than key-level, OOPS checking for a range of tables.

In this example, the OOPS mode for all table data whose name matches the mask "T00*" has been set to "2". OOPS will check all tables in this name range at table-level, rather than at key-level. This will result in much faster OOPS checking for this group of table data.

The sixth entry in Table 4-4 illustrates how to force table-level, rather than key-level, OOPS checking for a single table − in this case, table T308.

Which rule 'wins' if there is a conflict?

Entries in the OOPS and Locking rules list may state conflicting rules.

We have just discussed one example of such a conflict: the second line of Table 4-4 turns off OOPS checking for all TABU entries, while the final line activates table-level OOPS checking for TABU entries for table T308.

The list in Table 4-4 contains other instances of similar conflicts.

For example, the fifth line of the list activates key-level OOPS checking for V_T308 view data. However, this data is actually transported as TABU entries for table T308, and the effect of the sixth line is to activate table- (not key-) level OOPS checking for these TABU entries.

Which rule "wins" when such conflicts occur?

Rev-Trac enforces OOPS and Locking rules in the following order of precedence:

A rule for a fully-qualified object ID (ie, one that does not end in a wildcard) always takes precedence over a rule for an object ID that ends with a wildcard

For example, the third entry in Table 4-4 (TABU T001) takes precedence over the second entry (TABU *).



•

•

If two rules contain object IDs that end with a wildcard, the rule for the object ID with more characters before the wildcard takes precedence

For example, the third entry in Table 4-4 (TABU T00*) takes precedence over the second entry (TABU *).

If a rule for a CDAT, TDAT or VDAT object conflicts with a rule for an equivalent TABU entry, the TABU rule takes precedence

For example, the third entry in Table 4-4 (TABU T001) takes precedence over the fifth entry (VDAT V_T308), even though this VDAT data actually contains TABU entries for T001.

Auditing of locking exclusions

In situations where Rev-Trac would normally have enforced a lock but has not done so because of a setting in the OOPS and Locking exclusions list, Rev-Trac writes a message to the Rev-Trac system log indicating this.

Rev-Trac does not currently log OOPS warnings or errors suppressed because of a setting in the OOPS and Locking exclusions list.



Authorisation

This chapter provides all the information you should need in order to control what tasks users may perform in Rev-Trac through authorisation.

Quick start guide: how to perform common authorisation tasks

Table 5-1 below provides simple instructions in how to perform common authorisation-related tasks in Rev-Trac.

If you need to achieve a result not listed here, please read the remainder of this chapter, including the reference data towards the end of the chapter, for further information on how to fine-tune Rev-Trac behaviour through authorisation.

To achieve this result… follow these steps… Allow an SAP user to create, change or sign Rev-Trac requests

Add profile Y:/RSC/USR00 to the user master. Create the user in Rev-Trac (Rev-Trac Console > Configuration > Process > Organisations > Users).

Restrict the ability of Rev-Trac users to create and/or change Rev-Trac requests and preselect approvers to: • •

Requests of a particular type and/or class Requests for a particular team and/or project

Activate general authorisation. To do so, from the Rev-Trac Console select Configuration > Global > Global parameters. Set Gen Auth to "X" (Yes). Remove from all your users any authorisation based on authorisation object Y/RSC/CE03 (User privileges). Create a new authorisation based on object Y/RSC/CE03. Assign values to the new authorisation that match your needs, then give this authorisation to your users.

Allow all Rev-Trac users to delete transports from Rev-Trac requests

From the Rev-Trac Console select Configuration > Global > Global parameters. Set “TX Del" to blank (No).

Allow an individual user to delete transports from Rev-Trac requests, while preventing all others from doing so

From the Rev-Trac Console select Configuration > Global > Global parameters. Set “TX Del" to "X" (Yes). Create an authorisation based on authorisation object Y/RSC/CE03 (User privileges). Assign value "85" to the authorisation’s Activity field. Give this authorisation to your user.

Allow only certain Rev-Trac users to access particular fields on the request details screen for: • •

Requests of a particular type and/or status Requests for a particular project

From the Rev-Trac Console select Configuration > Process > Request screen > Field attributes. For the fields concerned, enter an arbitrary code (for example, "74") to represent an “authorisation group” in either the Cre Auth field (to allow access to the field when creating a request) or Chg Auth field (to allow access to the field when changing a request). Create a suitable authorisation based on Y/RSC/CE02. Assign a value to the authorisation’s /RSC/AGRP field that matches the value you entered in the Cre Auth or Chg Auth field in the previous step. Give this authorisation to your users.

Allow an SAP user to administer and configure every aspect of Rev-Trac

Add profile Y:/RSC/ADM00 to the user master. Create the user in Rev-Trac and assign an AdminAuth setting of "3" (Rev-Trac Console > Configuration > Process > Organisations > Users)

Allow a user to delegate another person's ability to approve requests

Activate delegation by others via authorisation. To do so, from the Rev-Trac Console select Configuration > Global > Global parameters. Set Delegate to "2" (Assign own delegates & others via authorisation). Create a suitable authorisation based on Y/RSC/CE06. Assign values to the /RSC/TEAM and /RSC/POSIT fields to limit as necessary the teams and position holders on whose behalf delegation may be performed. Give this authorisation to your user.

Table 5-1: Quick start guide to performing common authorisation tasks

Authorisation 139


Overview of Rev-Trac authorisation model

Three different kinds of settings may affect whether or not a user can perform certain actions in Rev-Trac:

•

•

The authorisations included in the user master

The user's AdminAuth setting. Together with the user master, this setting helps to determine whether the user is permitted to perform administrative functions.

This setting is located at Rev-Trac Console > Configuration > Process > Organisations > Users.

• Several global switches that determine whether Rev-Trac should check the user master before allowing an action to proceed. These include:

The Gen Auth global parameter

This setting determines whether the user master is checked whenever a user creates or changes a request. See Rev-Trac Console > Configuration > Global > Global parameters.

The TX Del global parameter

This setting determines whether the user master is checked whenever a user deletes a transport from a Rev-Trac request. See Rev-Trac Console > Configuration > Global > Global parameters.

The Delegation global parameter

This setting determines whether the user master is checked whenever a user seeks to delegate the ability to approve requests on behalf of a third party. See Rev-Trac Console > Configuration > Global > Global parameters.

Field level Chg Auth and Cre Auth settings for individual request details screen fields

Whether these fields are populated determines whether the user master is checked whenever a user seeks to populate or change request details fields. See Rev-Trac Console > Configuration > Process > Request screen > Field attributes.

The reason Rev-Trac checks both the user master and a user's AdminAuth setting before allowing a user to perform administrative functions is that some organisations widely distribute a version of the SAP_ALL profile that includes all authorisation objects in the customer namespace.

Requiring users also to have a non-default AdminAuth setting helps to limit the number of people who can act as Rev-Trac administrators in such an environment.

Note that it is possible to prevent the automatic inclusion of authorisation objects in the customer namespace (such as Rev-Trac's) in SAP_ALL. For details, see the next topic.

Preventing automatic inclusion of authorisations in customer namespace in SAP_ALL

By default, SAP systems include all authorisation objects from the customer namespace in profile SAP_ALL. At user sites where this profile is widely distributed, this can result in users acquiring the ability to perform tasks in Rev-Trac to which access should be restricted.

140 Authorisation


One approach to resolving this problem without removing SAP_ALL from users is to prevent the inclusion of Rev-Trac authorisation objects in SAP_ALL.

Because this can can be done only by preventing the inclusion of all authorisation objects in the customer namespace, it is best to check what authorisation objects exist in the customer namespace before proceeding further.

To perform this check, do the following:

1. From transaction SE38, run program RSUSR040 in your Rev-Trac master system. The "Authorization Objects by Complex Selection Criteria" screen is displayed.

2. Using the Multiple Selection function, select all Authorisation objects whose names match Y* or Z*, then select Program > Execute.

A list of all authorisation objects in the customer namespace is displayed.

If you are willing to exclude all the authorisation objects listed above from SAP_ALL, perform the following steps:

1. Use transaction SM30 to maintain table PRGN_CUST in your Rev-Trac master system. The "Change View 'Customizing settings for authorization process': overview" screen is displayed.


Field Description

Name ADD_ALL_CUST_OBJECTS

Value NO

3. Save your changes.

4. In transaction SE38, run program AGR_REGENERATE_SAP_ALL. SAP regenerates profile SAP_ALL in every client.

Note: Program AGR_REGENERATE_SAP_ALL regenerates SAP_ALL in every client simultaneously. If you would prefer to regenerate SAP_ALL only in specific clients, run program RSUSR406 only in the clients concerned.

Authorisation 141


Reference data

The following topics provide detailed reference information on

•

•

•

User profiles supplied with Rev-Trac

Authorisations contained in each profile supplied with Rev-Trac

Rev-Trac authorisation objects

Profiles

Table 5-2 below lists all the user profiles supplied with Rev-Trac, and provides brief information about the purpose of each.

For information on the authorisation objects and authorisations included in each profile, see Table 5-3 on page 144.

Profile name Profile description Comment Y:/RSC/ADM00 Admin: All This composite profile contains all authorisations present in the

Y:/RSC/ADMnn and Y:/RSC/USRnn profiles. Y:/RSC/ADM01 Admin: Basic access This profile contains authorisations derived only from standard SAP

authorisation objects, and does not confer any privileges to administer Rev-Trac or execute Rev-Trac utility programs or perform migrations. This profile is intended to be combined with other Y:/RSC/ADMnn profiles.

Y:/RSC/ADM02 Admin: Configuration Provides SAP authorisation to change most aspects of Rev-Trac configuration. User cannot create or change user settings, cannot perform delegations and cannot perform migrations from the Migration Workbench.

Y:/RSC/ADM03 Admin: User management and delegation

Provides SAP authorisation to create and change Rev-Trac user settings, and to delegate another user's ability to approve requests to a third party.

Y:/RSC/ADM04 Admin: Queue management Provides SAP authorisation to edit the Rev-Trac migration queue. Does not authorise user to add items to the Rev-Trac migration queue via the Migration Workbench, or to perform migrations directly using this tool.

Y:/RSC/ADM05 Admin: Migration Workbench

Provides SAP authorisation to add items to the Rev-Trac migration queue and to migrate items in the foreground using the Migration Workbench.

Y:/RSC/ADM06 Admin: Utilities Provides SAP authorisation to execute all administrative functions listed in Table 5-6 on page 148.

Y:/RSC/BTC00 Batch: All This composite profile contains all the authorisations present in the other Y:/RSC/BTCnn profiles.

Y:/RSC/BTC01 Batch: Import job Provides all SAP authorisations required to migrate items in the Rev-Trac migration queue by executing program /RSC/MF_BATCH_MIGRATION_UTIL.

Y:/RSC/BTC02 Batch: All (except import job)

Provides all SAP authorisations required to run standard Rev-Trac jobs, other than queue-processing background migration jobs.

Y:/RSC/RFC00 RFC User: All This composite profile contains all the authorisations present in the other Y:/RSC/RFCnn profiles.

Y:/RSC/RFC01 RFC User: Basic Provides all SAP authorisations required to call Rev-Trac functions and access Rev-Trac transactions remotely. Does not contain authorisations required to release or import transports.

Y:/RSC/RFC02 RFC User: Transport release

Provides all SAP authorisations required to release a transport remotely.

Y:/RSC/RFC03 RFC User:Transport import Provides all SAP authorisations required to import a transport remotely.

142 Authorisation


Profile name Profile description Comment Y:/RSC/USR00 User: Unrestricted Provides all SAP authorisations required to create and change

Rev-Trac requests, add attachments and transports, approve requests and access all Rev-Trac fields regardless of whether General authorisation is activated (Rev-Trac Console >

Configuration > Global > Global parameters > Gen Auth) Authorisation checks are required before entering data in specific

request details fields (Rev-Trac Console > Configuration > Process > Request screen > Field attributes)

Y:/RSC/USR01 User: Basic If general authorisation is deactivated (Rev-Trac Console > Configuration > Global > Global parameters > Gen Auth), this profile provides authorisations required to create and change Rev-Trac requests, add attachments and transports, and approve requests. If general authorisation is activated, a user with this profile can approve requests, but can perform none of the other tasks listed in the preceding paragraph.

Table 5-2: Profiles supplied with Rev-Trac

Authorisations per profile

Table 5-3 on the following page shows what authorisations are included in each of the standard profiles listed in Table 5-2 above.

The profiles listed with a grey background are composites.

Authorisation 143


144 Authorisation

Authorisation Authorisation ADM BTC RFC USR Authorisation description object 00 01 02 03 04 05 06 00 01 02 00 01 02 03 00 01

Y/RSC/CE02 Y:/RSC/CE020 Field level access: All Y/RSC/CE03 Y:/RSC/CE030 User privileges: All Y/RSC/CE04 Y:/RSC/CE040 Utilities: All Y/RSC/CE04 Y:/RSC/CE041 Utilities: Manage queue Y/RSC/CE04 Y:/RSC/CE042 Utilities: Batch import job Y/RSC/CE04 Y:/RSC/CE043 Utilities: Batch Y/RSC/CE05 Y:/RSC/CE051 Configuration: User admin Y/RSC/CE05 Y:/RSC/CE052 Configuration: All except user admin Y/RSC/CE06 Y:/RSC/CE060 Delegation: All Y/RSC/RM01 Y:/RSC/RM010 Migration Workbench target groups: All S_TCODE Y:/RSC/STCD1 Transaction codes: All Rev-Trac S_USER_GRP Y:/RSC/SUSR1 User Groups: Read values S_RFC Y:/RSC/SRFC1 RFC execute S_RFC Y:/RSC/SRFC2 RFC execute: RSC & SAP S_TABU_DIS Y:/RSC/STBU1 Config: Modify: No auth class S_TABU_CLI Y:/RSC/STBC0 Config Cli Indep Maintenahce: All S_DATASET Y:/RSC/SDTS2 Dataset read / write / delete S_C_FUNCT Y:/RSC/SCFN0 C calls in ABAP programs: All S_CPIC Y:/RSC/SCPC0 CPIC calls from ABAP programs: All S_PATH Y:/RSC/SPTH0 File system access via ABAP: All S_DEVELOP Y:/RSC/SDEV1 ABAP Workbench display S_TRANSPRT Y:/RSC/STRN1 Transport: Create S_TRANSPRT Y:/RSC/STRN2 Transport: Release S_TRANSPRT Y:/RSC/STRN3 Transport: Display S_TRANSPRT Y:/RSC/STRN4 Transport: Import S_BTCH_ADM Y:/RSC/SBAD0 Background administrator

authorisation S_BTCH_JOB Y:/RSC/SBOP0 Background job operations S_BTCH_NAM Y:/RSC/SBUN0 Background user name S_CTS_ADMI Y:/RSC/SCTS1 Transport import

Table 5-3: Authorisation objects and authorisations used in each standard Rev-Trac profile. Shaded profiles are composites


Authorisation objects


•

•

Describe the purpose and structure of Rev-Trac authorisation objects

Lists possible authorisation field values, where relevant

Y/RSC/CE02 (Field level)

This authorisation may be used to control who can access specific Rev-Trac request details fields when a request is being created or changed.

This authorisation is checked only if a value has been entered in the Cre Auth or Chg Auth column for a specific request details screen field (Rev-Trac Console > Configuration > Process > Request screen > Field attributes).

The object has four fields.

The /RSC/AGRP field represents an authorisation group. If an arbitrarily-defined authorisation group (for example, "74") has been entered in the Chg Auth or Cre Auth column for a request details screen field at Rev-Trac Console > Configuration > Process > Request screen > Field attributes, only a user whose profile contains an authorisation containing the same authorisation group in this authorisation field can change or create data in this request details screen field.

The /RSC/PRJ, /RSC/STAT and /RSC/TYP fields allow permission to create or change data in specific request details screen fields to be restricted by request project, status and type.

Y/RSC/CE03 (User privileges)

The authorisation may be used to control who can create or change Rev-Trac requests, pre-select request approvers, or delete transports from Rev-Trac requests.

The object has five fields.

The /RSC/CLASS, /RSC/PRJ, /RSC/TEAM and /RSC/TYP fields allow permissions for the activities described above to be restricted to requests of a particular class, project, team or type.

The fifth field is /RSC/ACT (Activity). Table 5-4 below lists possible values in this field, and notes switches that control whether this authorisation is checked.

Authorisation object: Y/RSC/CE03 (User privileges)

Activity Authority Notes 01 Create Rev-Trac request Rev-Trac checks for this Activity only if Gen Auth = X (Rev-

Trac Console > Configuration > Global > Global parameters) 02 Change Rev-Trac request Rev-Trac checks for this Activity only if Gen Auth = X 77 Pre-select approvers for Rev-Trac request 85 Delete transport from Rev-Trac request Rev-Trac checks for this activity only if TX Del = X (Rev-Trac

Console > Configuration > Global > Global parameters)

Table 5-4: Possible values for /RSC/ACT (Activity) in authorisation object Y/RSC/CE03

Authorisation 145


Y/RSC/CE04 (Tools / utilities)

This authorisation object supports fine-grained control over what tools and utilities an administrative user may access.

By creating a customised authorisation derived from this object, you can grant different subsets of permissions from those granted by the default administrative profiles listed in Table 5-2 on page 143.

The object has a single field, /RSC/AREA, in which you enter a value that corresponds to the tool or utility to be checked. Table 5-5 below lists the possible values for this field.

Two conditions must be satisfied before a user can execute the tools and utilities listed in this table:

•

•

The user must have the appropriate SAP authorisation

The user's AdminAuth setting (Rev-Trac Console > Configuration > Process > Organisations > Users) must be either:

01 (Authority to execute Rev-Trac Utility/Maintenance functions), or

03 (All - authority for both Configuration & Utility functions)

Authorisation object: Y/RSC/CE04 (Tools / utilities) Area Authority CE_000 Lock and unlock Rev-Trac (Rev-Trac Console > Administration > Lock / unlock) CE_001 Copy Rev-Trac text elements to another language using program

/RSC/INTERNAL_COPY_TXELEM_UTIL. Note that this program is not part of a standard Rev-Trac installation. You can obtain a copy of this program from [email protected].

CE_002 Backup Rev-Trac data and configuration to transport (Rev-Trac Console > Configuration > Tools > Backup data to transport)

CE_003 Submit standard jobs (Rev-Trac Console > Administration > Submit standard jobs) CE_004 Turn off Rev-Trac enforcement and/or locking system field exits in emergency by

using program /RSC/CE_DISABLE_INTEGRATN_UTIL. CE_005 Upload or download transports from PC (Rev-Trac Console > Migration > Tools >

Upload / download transports) CE_007 Remove sent indicator from transport via Rev-Trac Workbench > Transport >

Remove sent indicator CE_008 Upload Rev-Trac configuration (Rev-Trac Console > Configuration > Tools >

Download / upload configuration) CE_009 Send workflow prompts to next approvers of selected Rev-Trac requests (Rev-Trac

Console > Request Management > Tools > Oustanding approval) MF_001 Migrate items in Rev-Trac migration queue using program

/RSC/MF_BATCH_MIGRATION_UTIL (Rev-Trac Console > Migration > Migration queue > Migrate queue items)

MF_002 Edit Rev-Trac migration queue (Rev-Trac Console > Migration > Migration queue > Manage / view queue)

MF_003 Load history of transport movements using program /RSC/MF_SIMULATE_MIG_EVNT_UTIL

MF_004 Capture landscape snapshot using program /RSC/MF_BACKUP_MIG_HIST_UTIL MF_005 Mass release transports (Rev-Trac Console > Migration > Tools > Release

transports) MF_006 Add or remove sent indicators to transports via Rev-Trac Console > Migration >

Tools > Update sent indicators. MF_007 Quarantine or unquarantine transports (Rev-Trac Console > Migration > Tools >

Quarantine transports)

146 Authorisation


Authorisation object: Y/RSC/CE04 (Tools / utilities) Area Authority MF_009 Check and adjust transport classifications (eg, client-independent, hybrid etc) using

program /RSC/MF_CHECK_TX_CLASS_UTIL MF_010 Populate transport movement database from file containing landscape snapshot

using program /RSC/MF_TX_MIGRATION_TOOL_UTIL RM_001 Permanently delete Rev-Trac request from database using program

/RSC/RM_DELETE_REQ_DATA_UTIL RM_003 Open request details Status field for input when Chg status field for this request

status is blank in corresponding strategy (Rev-Trac Console > Configuration > Process > Strategies > Strategies > Status path).

RM_004 Perform mass status change using specialist administrator program /RSC/RM_MASS_STATUS_CHNG_UTIL

RM_005 Change request status forward by directly changing Status field on request details screen.

RM_006 Delete special migration instructions by running program /RSC/RM_DEL_SPEC_MIG_INST_UTIL

CR_001 Create clone of existing Rev-Trac request by directly executing program /RSC/CR_COPY_REQUEST_UTIL_01. Authorisation is not checked if this program is correctly called via user exit.

CR_002 Create clone of existing Rev-Trac request by directly executing program /RSC/CR_COPY_REQUEST_UTIL_02. Authorisation is not checked if this program is correctly called via user exit.

CR_003 Create Rev-Trac requests by uploading data from spreadsheet using program /RSC/CR_UPLOAD_REQUEST_UTIL

OP_001 Permit parallel development (Rev-Trac Console > Request Management > Tools > Develop in parallel).

Table 5-5: Meaning of Area values in authorisation object: Y/RSC/CE04

Y/RSC/CE05 (Configuration)

This authorisation object supports fine-grained control over what areas of Rev-Trac configuration an administrative user may change.


The object has a single field, /RSC/AREAC, in which you enter a value that corresponds to the area of configuration to be checked. Table 5-6 below lists the possible values for this field.

Authorisation 147


Two conditions must be satisfied before a user can execute the tools and utilities listed in this table:

•

•

The user must have the appropriate SAP authorisation

The user's AdminAuth setting (Rev-Trac Console > Configuration > Process > Organisations > Users) must be either:

"02" (Authority to perform Rev-Trac Configuration functions), or

"03" (All - authority for both Configuration & Utility functions)

Authorisation object: Y/RSC/CE05 (Configuration) Area Authority BD_00 Load attachment template (Rev-Trac Console > Configuration > Tools > Load

template) CF_00 Configure parameters for program that loads history of transport movements using

transaction /RSC/CF00. CF_10 Change global parameters using transaction /RSC/CF10 CF_20 Configure system or landscape names, or system-specific parameters including

enforcement and locking settings using transaction /RSC/CF20 CF_30 Configure project names using transaction /RSC/CF30 CF_31 Configure request types using transaction /RSC/CF31 CF_32 Configure users (including their privileges), teams, positions and organisation

structure using transaction /RSC/CF32 CF_33 Configure strategies, including workflow message recipients, using transaction

/RSC/CF33 CF_34 Configure target groups and the destinations they comprise using transaction

/RSC/CF34 CF_35 Assign strategies, request completion rules, organisation structures and migration

behaviour to request types within specific projects using transaction /RSC/CF35 CF_40 Configure request details "master data", including SAP modules, attachment and

reference types, user statuses, severity codes and project releases using transaction /RSC/CF40

CF_41 Configure attributes of specific request details screen fields using transaction /RSC/CF41

CF_50 Configure request completion rules using transaction /RSC/CF50 CF_51 Configure transport creation rules using transaction /RSC/CF51 CF_52 Configure sensitive objects using transaction /RSC/CF52 CF_53 Configure pre-import comparison using transaction /RSC/CF53 (deprecated) CF_54 Configure special approvers using transaction /RSC/CF40

Table 5-6: Meaning of Area values in authorisation object Y/RSC/CE05

Y/RSC/CE06 (Delegation)

This authorisation may be used to control the scope within which a user may delegate others to approver Rev-Trac requests on behalf of third parties.

The objects has two fields, /RSC/POSIT and /RSC/TEAM. The contents of these fields specify the positions and teams of third party users whose ability to approve requests a user with this authorisation may delegate to others.

This authorisation is checked only if global parameter Delegate is "2" (Assign own delegates & others via authorisation).

148 Authorisation


Y/RSC/RM01 (Migration Workbench target groups)

This authorisation may be used to control the Rev-Trac target groups to which a user may migrate transports or queue transports using the Migration Workbench.


The activity has a single field, /RSC/TAR, in which you enter the names of one or more Rev-Trac target groups.

Authorisation 149


References

A Rev-Trac request may contain references to other records or information sources. You can create three different kinds of reference:

•

•

•

Simple reference

A simple reference notes the existence of an external information source such as an OSS note or a Help Desk record that is relevant to a request.

Smart reference

A smart reference is a simple reference with additional functions. Typically, a smart reference may be selected from a dropdown list, its existence may be validated, and the reference itself may be launched by a mouse click.

Dependency-checking reference

A dependency-checking reference is a special form of smart reference to another Rev-Trac request designed to ensure that the two requests progress in accordance with certain rules about which should advance first.

This chapter describes the behaviour of all three kinds of reference, and explains how to configure each.

Features common to all references

The following topics describe features common to all three kinds of reference.

Reference type, ID, text and priority

Every reference has a reference type, an ID, a text and a priority.

Figure 6-1 below shows a dialog through which a user is adding two references to a Rev-Trac request.

The reference types of these two references are CORR (Correspondence) and HELP (Help desk).

The ID of each reference has been entered in the column labelled "Reference".

The Text supplements the ID, describing the contents of the reference.

The priority, in the Pri column, dictates (within limits) the order in which references are displayed on the request details screen.

150 Referrences


Figure 6-1: Adding a reference to a Rev-Trac request

Each organisation may define its own reference types. The main purpose of a reference type is to indicate to the user the kind of information source that is being referred to. In addition, as we will see below, references of the same type share basic length and character-type validation rules.

There is no connection between the concept of a reference type, as discussed here, and the three different kinds of reference (simple, smart and dependency-checking) described above.

Basic validation

The length and content of the reference ID is subject to some basic validation checking at the time a reference is added to a request.

Different validation rules may be set for each reference type.

In Figure 6-2 below, the user has attempted to add a reference to a help desk code, but has entered an invalid code.

Figure 6-2: Simple validation is available for all references

References 151


Visibility on request details screen

The IDs of the two highest priority references added to a Rev-Trac request are displayed on the References button on the request details screen.

Thus, in Figure 6-3 below, the reference IDs entered previously are visible in the bottom right corner of the screenshot.

Figure 6-3: The request details screen displays brief information about references (at bottom right of screenshot)

Visibility on Rev-Trac Workbench

All references added to a Rev-Trac request are displayed on the Rev-Trac Workbench screen under a References node (see Figure 6-4 below). This node is displayed only if a reference has been added to a request.

Figure 6-4: The Rev-Trac Workbench screen displays each request reference

152 Referrences


References 153

Dynamic linking of requests with a common reference

If two or more Rev-Trac requests each contain a reference to the same item, Rev-Trac automatically creates a "dynamic link" between the two requests. This situation is illustrated in Figure 6-5 below.

Figure 6-5: Rev-Trac automatically creates dynamic links between requests that share a common reference

In this example, two Rev-Trac requests include a reference to the same help desk ticket. Because it is likely the two requests relate to the same matter, Rev-Trac has dynamically (that is, automatically) linked each request to the other.

Each of the dynamic links is a hyperlink: clicking the link displays the other request.

Rev-Trac requests may be searched by reference

It is possible to search Rev-Trac requests by reference type and/or reference number (ie, reference ID) from the Rev-Trac Workbench selection screen. Figure 6-6 below shows the relevant selection fields.

Figure 6-6: Searching Rev-Trac requests by reference type and ID


Rev-Trac Workbench may display requests by reference type and ID

It is possible to display requests on the Rev-Trac Workbench using their first or second priority reference type and ID rather than request number.

Figure 6-7 below shows the same two requests seen in Figure 6-5 above, now displayed in this manner.

Figure 6-7: Rev-Trac Workbench has displayed these two Rev-Trac requests by their reference type and ID, rather than by Rev-Trac request number

To achieve this result, the user selects Reference number 1 or Reference number 2 in the Number display options area of the Rev-Trac Workbench selection screen.

Controlling automatic display of "Reference index" dialog

By default, Rev-Trac displays the "Reference index" dialog (see Figure 6-1 on page 151) whenever a user saves a Rev-Trac request if a reference has not already been provided. However, Rev-Trac does not, by default, require a user to add a reference.

It is possible to vary this behaviour by entering a suitable over-ride (Rev-Trac Console > Configuration > Global > Advanced > Over-rides). Table 6-1 below lists the possible options. Note that the Value column may be hidden by default. To expose this field, double-click anywhere within a row.

Parameter Sub Parameter 1 Sub Parameter 2 Value Effect

MSG_/RSC/CE03 USER=* E "Reference index" dialog is displayed whenever a request is saved if no reference has been added to a request. User must add a reference before saving the request.

MSG_/RSC/CE03 USER=* DEFAULT "Reference index" dialog is displayed whenever a request is saved if no reference has been added to a request. User is not forced to add a reference.

MSG_/RSC/CE03 USER=* S "Reference index" dialog is not displayed when request is saved.

Table 6-1: Over-rides for controlling automatic display of "References index" dialog

Additional features available in smart references

Rev-Trac smart references share all the properties described above, but have some additional "intelligence" built in. Smart references are particularly suitable for referencing other Rev-Trac requests, and file or web urls.

As with all other kinds of references, organisations may define their own types of smart references. For example, the reference types SCRS (screenshot) and FILE might both point to files on a LAN.

154 Referrences


The following topics describe additional features available in smart references.

Possible entries (F4) help

For all smart references, possible entries (F4) help is available for the Reference column of the References index dialog (see Figure 6-8 below).

Figure 6-8: Possible entries (F4) help is available for all smart references

If the smart reference points to other Rev-Trac requests, a list of Rev-Trac requests is displayed. If the smart reference points to a url, a file selection dialog is displayed (see Figure 6-9 below).

Figure 6-9: File selection dialog available with smart references pointing to url

More powerful validation than for simple references

If a smart reference points to a local or LAN file, or to another Rev-Trac request, Rev-Trac validates the existence of the reference before allowing it to be added to the request (see Figure 6-10 below).

References 155


Figure 6-10: Rev-Trac has performed a validation check to determine if this files URL actually exists

For an internet url (eg, www.xrsc.com), it is necessary to turn off this validation checking explicitly, as Rev-Trac is unable to determine whether a resource pointed to by an internet url actually exists. For details, see Creating a reference type for smart references on page 161.

Reference launching

Another difference between simple and smart references is that users may launch a smart reference by double-clicking it on the Rev-Trac Workbench screen.

In Figure 6-11 below, for example, a user has launched a web browser to display a web URL entered as a reference for a Rev-Trac request.

Figure 6-11: User has launched smart reference by clicking entry on Rev-Trac Workbench

156 Referrences


Additional features available in dependency-checking references

A dependency-checking reference is a special kind of smart reference.

A dependency-checking reference is always a reference to another Rev-Trac request. The purpose of the reference is to ensure that the two requests progress in accordance with certain rules. The rules themselves are configurable. Each dependency-checking reference type polices its own set of rules.

Dependency-checking references are particularly useful in situations where different but related changes in two different types of landscapes (for example, R/3 and BW) need to be synchronised.

Example of single dependency check

The operation of dependency-checking references is best illustrated by example. Figure 6-12 below illustrates the use of a dependency-checking reference to enforce a single dependency rule.

D-IN

D-AP

Q-IN

Q-AP

P-IN

D-IN

D-AP

Q-IN

Q-AP

P-IN

In development

Approved for QAS

In QAS

Approved for PRD

In PRD

BW

?

Before request 20 is "Approved for QAS", request 21 must be "In QAS"

Presence of reference forces a pre-approval dependency check.

Request 21

Request 20 contains a single dependency checking reference to request 21

Request 20

R/3

Figure 6-12: Dependency-checking reference enforces a simple dependency rule

In this example, the Rev-Trac request at left contains a dependency-checking reference to the request at right.

As a result, the request at left, which contains BW changes, may not be approved into the status "Approved for QAS" until the request at right, which contains related R/3 changes, has reached the status "In QAS".

Figure 6-13 below shows how the Rev-Trac Workbench displays such a dependency-checking reference. There is no immediate visual difference between this type of reference and any other.

References 157


Figure 6-13: Example of dependency-checking reference as displayed on Rev-Trac Workbench

If a user seeks to approve a Rev-Trac request that contains a dependency-checking reference prematurely, Rev-Trac displays a message like the one shown in Figure 6-14 below.

Figure 6-14: Example of Rev-Trac message displayed at approval time if a dependency has not been satisfied

Depending on how the dependency check is configured, this message may block the approval from proceeding, or may merely alert the user that the dependency has not been satisfied.

Example of multiple dependency checks

A single dependency-checking reference may police multiple dependencies. Figure 6-15 below illustrates this situation.

158 Referrences


D-IN

D-AP

Q-IN

Q-AP

P-IN

D-IN

D-AP

Q-IN

Q-AP

P-IN

After configuring more dependency rules, presence of reference forces multiple pre-approval dependency checks

?

?


Request 21Request 20

R/3 BW

In development

Approved for QAS

In QAS

Approved for PRD

In PRD

Figure 6-15: Multiple pre-approval dependency checks

As before, the Rev-Trac request at left contains a single dependency-checking reference to the request at right.

However, following configuration changes, two dependency rules for the request at left are now policed:

•

•

The request at left may not be approved into the status "Approved for QAS" until the request at right has reached the status "In QAS"

The request at left may not be approved into the status "Approved for PRD" until the request at right has reached the status "In PRD"

It is possible to police each dependency rule with a different degree of rigour. Figure 6-16 below illustrates a typical situation. Here, a user has attempted to approve a request that has failed two dependency checks. The user has been permitted to ignore the first failure, but not the second.

Figure 6-16: Each dependency rule may be policed with a different degree of rigour

Note that Rev-Trac continues to issue alerts regarding the first failed dependency even after the request has passed the status at which that alert was first issued − provided, of course, the dependency is still not satisfied.

References 159


Procedures


•

•

How to create simple, smart and dependency-checking reference types

How to configure specific dependency checks once a suitable dependency-checking reference type has been created

Creating a reference type for simple references

Use the following procedure to create a new reference type to be used for simple references.

1. From the “Rev-Trac console” screen, select Configuration > Process > Request screen > Master data to display the "Display View 'SAP modules': Overview" screen.

2. In Dialog Structure, double-click Reference Types, then select Table View > Display ->Change to put the screen in change mode.


Field Description

RefT A short code representing the reference type. Example: HELP, CORR, OSS

Text A description of the reference type.

Len The maximum number of characters permitted in the reference ID for references of this type.

Edit From the dropdown list, select a value that determines what kinds of characters are valid in a reference ID for references of this type.

4. Select Table View > Save to save the change.

160 Referrences


Creating a reference type for smart references

Use the following procedure to create a new reference type to be used for smart references.




Field Description

RefT A short code representing the smart reference type. Example: REQ, FILE, WEB

Text A description of the reference type.

Len The maximum number of characters permitted in the reference ID for references of this type. For a reference to a url, type 132 (the maximum permissible length). For a reference to a Rev-Trac request, type 10.

Edit For a reference to a url, type 5. For a reference to a Rev-Trac request, type 4.


5. Perform the following steps only if the reference type is to be used for internet urls (eg, www.xrsc.com).

6. From the “Rev-Trac console” screen, select Configuration > Global > Advanced > Over-rides). to display the "Display View Over-rides: Overview" screen.



Field Description

Parameter EXIT_REF_VALIDATE

Sub Parameter 1 The reference type to be used for internet urls. Example: WEB

Sub Parameter 2 USER=*

Value OFF


References 161


Creating a reference type for dependency-checking references

Use the following procedure to create a new reference type to be used for dependency-checking references.

After creating a suitable reference type for such references, it will also be necessary to define the specific checks that the reference will enforce. See Defining actual dependency checks for a dependency-checking reference type below.




Field Description

RefT A short code representing the dependency-checking reference type. Example: CHEK

Text A description of the reference type. e.g. “Dependency checking”

Len Type 10.

Edit Type 4.


Defining actual dependency checks for a dependency-checking reference type

Once a dependency-checking reference type has been created, you can define the dependency-checking behaviour of references using this type by entering suitable over-rides.


Table 6-2 below illustrates the kind of over-rides that would need to be created to enforce the first of the two dependency checks depicted in Figure 6-17 on page 164.

162 Referrences



Sub Parameter 2 Value

EXIT_REF_PGM_SMART CHEK USER=JBLOGGS /RSC/CE_DEP_REF_EXITS_PGM EXIT_REF_DPREFERENCE CHEK REFEREE_STATUS D-AP EXIT_REF_DPREFERENCE CHEK REFERENCE_STATUS Q-IN EXIT_REF_DPREFERENCE CHEK MESSAGE_TYPE W EXIT_REF_DPREFERENCE CHEK USER=JBLOGGS ON

Table 6-2: Example of over-rides suitable for enforcing the first of the dependency checks illustrated in Figure 6-17

The value in the Parameter column (EXIT_REF_PGM_SMART) tells Rev-Trac to call the validating program (/RSC/CE_DEP_REF_EXITS_PGM) referred to in the Value column for the reference type (CHEK) referred to in the Sub Parameter 1 column.

The value in the Parameter column (EXIT_REF_DPREFERENCE) indicates that these entries refer to a dependency checking reference.

The value in the Sub Parameter 1 column (CHEK) indicates the type of reference for which this particular dependency-checking behavior is active.

The entry where Sub Parameter 2 = REFEREE_STATUS specifies the status of the request on the left in Figure 6-17 at which a dependency check occurs.

The entry where Sub Parameter 2 = REFERENCE_STATUS specifies what status the request on the right in Figure 6-17 must have reached to satisfy the dependency.

Taken together, these two entries mean that before the request on the left is approved into status D-AP, the request on the right should have reached the status Q-IN.

The entry where Sub Parameter 2 = MESSAGE_TYPE specifies in the Value field the type of message that Rev-Trac will issue if the dependency is not satisfied.

Possible values are:

I (information): If dependency is not satisfied, display information message but allow approval to proceed.

W (warning): If dependency is not satisfied, display warning message but allow approval to proceed.

E (error): If dependency is not satisfied, display error message and block approval.

The final entry specifies the user or users for whom dependency checking is active. To activate checking of this dependency for all users, type USER=* in the Sub Parameter 2 field.

References 163


D-IN

D-AP

Q-IN

Q-AP

P-IN

D-IN

D-AP

Q-IN

Q-AP

P-IN

?

?


Request 21Request 20

BW R/3

In development

Approved for QAS

In QAS

Approved for PRD

In PRD

Figure 6-17: This dependency-checking reference enforces two dependencies when suitable over-rides are configured

Table 6-3 below lists (in bold) over-rides that would enforce the second of the two dependency checks depicted in Figure 6-17.


Sub Parameter 2 Value

EXIT_REF_PGM_SMART CHEK USER=JBLOGGS /RSC/CE_DEP_REF_EXITS_PGM EXIT_REF_DPREFERENCE CHEK REFEREE_STATUS D-AP EXIT_REF_DPREFERENCE CHEK REFERENCE_STATUS Q-IN EXIT_REF_DPREFERENCE CHEK MESSAGE_TYPE W EXIT_REF_DPREFERENCE CHEK USER=JBLOGGS ON EXIT_REF_DPREFERENCE CHEK NUMBER_OF_SETS 2 EXIT_REF_DPREFERENCE CHEK REFEREE_STATUS(02) Q-AP EXIT_REF_DPREFERENCE CHEK REFERENCE_STATUS(02) P-IN EXIT_REF_DPREFERENCE CHEK MESSAGE_TYPE(02) E

Table 6-3: Over-rides suitable for enforcing the second of the dependency checks illustrated in Figure 6-17 are displayed in bold

The entry where Sub Parameter 2 = NUMBER_OF_SETS specifies the total number of dependency checks associated with this reference type. If only one dependency check is required, no NUMBER_OF_SETS entry is required. The maximum number of dependency checks per reference type is 99.

The remaining entries in bold illustrate how additional checks are configured.

In this example, the value (02) has been appended to the entry in the Sub Parameter 2 field to indicate that these settings affect the second dependency check. For a third check, the value (03) would be used here,

164 Referrences


and so on. Otherwise, the meaning of REFEREE_STATUS, REFERENCE_STATUS and MESSAGE_TYPE in each case is unchanged.

References 165


Request completion rules

Rev-Trac administrators can configure rules that prescribe:

• What Rev-Trac request fields must be completed

•

•

•

•

What types of attachments must be added

What types of references must be added

before a request of a particular type and project reaches a particular status.

This makes it possible to configure rules such as the following for a request of a particular project and type:

Before the request reaches the status "Budget approved", the "Estimated" field must be completed, and a reference of type "Help desk" should be attached

Before the request reaches the status "In progress", the user should be prompted to complete the Programmer field, and a reference of type "Help desk" must be attached

•

•

•

Before the request reaches the status "Tested in QAS", an attachment of type "Test results" must be attached

By default, Rev-Trac's completion rule-checking behavior is regressive and retrospective, in that:

If a non-mandatory completion rule remains unsatisfied, Rev-Trac continues to alert the user of this at every approval until the condition is met

If completion rules change during the lifetime of a request, Rev-Trac verifies whether past approvals are consistent with the new rules.

If not, Rev-Trac issues an appropriate information, warning or error message based on the new rules

However, it is also possible to restrict the scope of a completion rule to a single status. If the scope of a non-mandatory rule is restricted, Rev-Trac does not continue to alert the user at subsequent steps if the condition has not been met.

This chapter describes how to define request completion rules and enforce their use for particular combinations of project and request type. The final section shows examples of Rev-Trac completion rule messages.

Defining request completion rules

Figure 7-1 below shows part of the configuration required to implement the rules described above.

166 Request completion rules


Figure 7-1: Example request completion rules

In this example, a "requirement" called DEMO has been defined by selecting Configuration > Process > Advanced > Request completion rules from the Rev-Trac Console.

This requirement contains five rules.

•

•

•

•

The first rule states that before a request can be approved into status BUDG (Budget approved), the DAYSEST (Number of days: Estimated) field must be completed.

If this field is not completed, Rev-Trac will display an E (error) message, preventing the request from being approved.

The second rule states that before a request can be approved into status BUDG, a reference of type HDSK (Help desk) should be attached to the request.

If a reference of this type has not been attached to the request, Rev-Trac will display a W (warning) message, but will allow the request to be approved.

• The third rule causes Rev-Trac to display an I (information) prompt asking the approver to complete the Programmer field before approving the status D-IP (In progress).

The scope of this rule is limited to a single status. Rev-Trac will not continue to alert the user at subsequent steps if this condition is not met.

The fourth rule again relates to a reference of type HDSK, and states that before a request reaches status D-IP it must contain a reference of type HDSK.

This rule is more stringent than the previous rule involving an HDSK reference type. Rev-Trac will issue an E (error) message if a reference of the correct type has not been added before approval, preventing the request from being approved.

The fifth rule states that an attachment of type TEST (Test results) must be added to a request before it is approved into status Q-TS (Tested in QAS).

While the example above use only E (error) and W (warning) messages, it is possible also to configure completion rules using I (information)

Request completion rules 167


messages. Rules configured with information messages, like those with warning messages, are advisory only and do not prevent approval.

Note that the only purpose of the Number field seen in Figure 7-1 is to prescribe the order in which Rev-Trac displays completion rule messages for a given status. There is no connection between this field and the Number field used when configuring a strategy.

Associating rules with a project / request type combination

The rules defined via the configuration shown above in Figure 7-1 have no effect until they are associated with a project / request type combination.

From the Rev-Trac Console, the menu path to define this association is Configuration > Process > Assign process > Process assignment > Assignments per project/ request type.

Figure 7-2 below illustrates how the rules shown above in requirement DEMO have been applied to all requests of type CONFIG in project AJAX.

Figure 7-2: To activate the rules shown in Figure 7-1, they must be associated with a project / request type combination by completing the Requirement field here

Note that the Requirement field (lower right corner of screenshot) contains the name of the requirement defined in Figure 7-1.

The rules in action

The screenshots below show messages Rev-Trac displays after completion rules have been defined and activated.

The text of rule information messages (Msg. Type = I) is similar to the text shown in Figure 7-4 for a warning message.

168 Request completion rules


Figure 7-3: Rev-Trac displays this error message when a user seeks to approve status "Budgeted" because the Days Estimated field has not been completed. The user will not be able to approve the request until this rule has been satisfied.

Figure 7-4: A warning message such as this does not prevent approval, but prompts the user to supply further request details

Request completion rules 169


Appendices

Upgrading SAP: Steps required in Rev-Trac

Before performing an upgrade of the SAP application layer (not kernel), be sure to deactivate the Rev-Trac field exits and, if installed, the Rev-Trac BADI.

If you fail to do so, you may be unable to create transports required during the SAP upgrade.

After completing your SAP upgrade, reactivate the Rev-Trac field exits and BADI.

For details on how to deactivate the Rev-Trac field exits and BADI, see Deactivating Rev-Trac field exits and BADI on page 184.

For details of how to reactivate the Rev-Trac field exits and BADI, see Reactivating Rev-Trac field exits and BADI on page 185.

170 Appendices


Moving Rev-Trac master to another system

This section describes how to move the Rev-Trac master (the "current master") to another system (the "new master") where Rev-Trac software may or may not already be present.

Pre-requisites

SAP releases

It is not possible to move a Rev-Trac master from SAP release 6.10 or higher to SAP release 4.6 or lower.

Moving a Rev-Trac master involves exporting Rev-Trac data, including Rev-Trac request attachment data, from the current master and importing this transport into the new master. Data relating to Rev-Trac attachments is not downwardly compatible from SAP 6.10 to 4.6 or lower. For more details, see SAP Note 888451 Problems with use of export/import as a transfer format.

This is the only known cross-release compatibility issue affecting the move of a Rev-Trac master from one system to another.

Rev-Trac versions

Before moving your Rev-Trac master, ensure the same versions of the required Rev-Trac software components are installed on every system.

To determine what versions of each Rev-Trac component are currently installed, select Administration > Health check from the Rev-Trac Console. Select Include System Versions report and clear all other checkboxes. Execute the report.

Transport creation freeze during move

No new transports should be created on any development system under Rev-Trac control from the time the current Rev-Trac master is locked until the new master is unlocked.

Internet email

If the current master sends Rev-Trac workflow messages to internet email addresses (eg, [email protected]), you will need to ensure SAPConnect is configured in the new master to send internet email messages.

Background: What is unique about the Rev-Trac master?

Understanding the unique properties of a Rev-Trac master should help you recognise the purpose of the various activities involved in moving a Rev-Trac master.

Software

A Rev-Trac installation may contain up to three different kinds of systems:

•

•

•

A master system

Slave systems

Monitored systems

Appendices 171


For the meaning of these terms, see Terminology: landscape, master, slave and monitored system on page 54.

The Rev-Trac software that needs to be installed on a master system is exactly the same as the software required on any slave (ie, development) system.

Configuration settings

A Rev-Trac master system contains many Rev-Trac configuration settings that are not normally present in any other system in the Rev-Trac installation.

It is possible for two systems in a Rev-Trac installation to contain extensive Rev-Trac configuration settings. This will be the case, for example, after you have moved your Rev-Trac master from one system to another.

The fact that a system contains extensive Rev-Trac configuration settings does not necessarily make it behave like a Rev-Trac master.

A system behaves like a Rev-Trac master when:

•

•

It contains an internal configuration setting (Rev-Trac Console > Configuration > Systems > Systems > System parameters > Func) that defines this system as the master, and

This setting has been distributed to every other system in the installation (Rev-Trac Console > Configuration > Activate changes)

Data

The Rev-Trac master system is the only system where data for new Rev-Trac requests is stored.

On the other hand, every system in a Rev-Trac installation has its own transport movement database and OOPS database. (For more details on these databases, see OOPS pre-requisites on page 110.)

Rev-Trac migration queue

The Rev-Trac migration queue is stored only on the Rev-Trac master.

Communications

The Rev-Trac master needs to be able to communicate with every other system in the Rev-Trac installation via RFC destinations.

In addition, every system from which a user needs to logon to the Rev-Trac master needs to be able to communicate with the Rev-Trac master via an RFC destination.

These communication requirements are unique to the Rev-Trac master.

For a complete account of Rev-Trac's communication requirements, see Inter-system communications on page 54.

Jobs

The migration monitoring job (see OOPS pre-requisites on page 110) runs on every system in a Rev-Trac installation.

All other Rev-Trac jobs run only on the Rev-Trac master.

Most jobs that run on the Rev-Trac master system require no special variant, and are easily rescheduled from within Rev-Trac.

172 Appendices


The only exception is jobs that migrate items in the Rev-Trac migration queue. Each of these jobs has its own variant.

Customer exits

If you have created your own Rev-Trac customer exits, the code for these exits is stored and runs on the Rev-Trac master only.

Email

The Rev-Trac master is the only system in the Rev-Trac installation that sends workflow messages to users.

If these messages are to be sent to internet email addresses (eg, [email protected]), SAPConnect must be configured in the Rev-Trac master.

What does a Rev-Trac data backup transport include?

As part of the process of moving your Rev-Trac master, you will backup Rev-Trac data to a transport. You can do this from the Rev-Trac Console by selecting Configuration > Tools > Backup data to transport.

The transport created in this way contains:

•

•

•

•

•

•

•

•

•

All Rev-Trac configuration

All request-related data

The Rev-Trac migration queue

The OOPS database

for the current Rev-Trac master.

This transport does not contain:

The Rev-Trac transport movement database for the current master

Job definitions or variants

RFC destinations

Rev-Trac customer exit code

Rev-Trac event /RSC/TRIGGER

It is not appropriate to move the transport movement database for the current master to the new master, as this information is system-specific and should remain in situ.

All the other items listed above will need to be moved to the new master or recreated there by other means.

Overview of procedure for moving a Rev-Trac master

The following is an overview of procedure for moving a Rev-Trac master. Each of the steps listed here is explained in greater detail below.

1. Install Rev-Trac software in new master.

2. Block Rev-Trac activity in the current master.

Appendices 173


3. Export or copy from the current master: Any customer exits RFC destinations Details of all migration jobs Rev-Trac data and configuration (via transport)

4. Recreate or import in the new master: Any customer exits Rev-Trac users Previously existing RFC destinations Migration jobs Rev-Trac data and configuration (via transport) The Rev-Trac event

5. Adjust and activate system-specific configuration in new master.

6. Reschedule non-mgration jobs and rebuild OOPS database in new master.

7. Create new RFC destinations.

8. Unlock the new master.

Step 1: Install Rev-Trac software in new master

The Rev-Trac software components that need to be installed in a Rev-Trac master system are detailed in the shaded area of Table 7-1 below.

As discussed below, it will not be necessary in many cases to install the Rev-Trac software in the new master, as these will be present already.

Import only in SAP versions 4.6+ Components Profiles Dev Core Mon Core Dev Enjoy Mon Enjoy

Master system Slave system Monitored system

Table 7-1: Rev-Trac software components required on each type of system

In addition to these software components, two additional transports should be present in any Rev-Trac development system:

•

•

A transport containing the Rev-Trac BADI (SAP 4.6+ systems only)

A transport containing the Rev-Trac field exits

Do I need to install software?

If the new master is a system copy of the current master, or is already functioning as a slave, you will not need to install any additional software in the new master, as this software is already present.

If the new master is already part of your Rev-Trac installation but functioning in another capacity, you can confirm what software components are currently present in that system by selecting Administration > Rev-Trac version from the Rev-Trac Console of the current master.

174 Appendices


If no Rev-Trac component has ever been installed or copied into the new master, or if the new master was previously functioning as a monitored system, you will need to install at least some Rev-Trac software components in the new master before proceeding further.

To obtain the correct versions of the software components required, the BADI and field exit transports (if required), plus import instructions, please contact [email protected].

Before importing the transport containing the Rev-Trac field exits, set the value of the system's abap/fieldexit instance parameter to YES and bounce the system.

Do I need to import the Rev-Trac BADI and field exits?

You need to install the Rev-Trac BADI and field exits in the new master only if the new master is a development system and the Rev-Trac field exits and BADI are not already present in the new master.

You may install the Rev-Trac BADI only in systems running SAP release 4.6C and above.

The Rev-Trac field exits and BADI will be present in the new master already if:

•

•

The new master is a development system already running under Rev-Trac, or

The master is a system copy of the current master, and the current master is a development system

Step 2: Block Rev-Trac activity in current master

2a. Lock the current master to prevent users from changing or creating Rev-Trac requests. From the current master Rev-Trac Console, select Administration > Lock/unlock. A dialog asks for confirmation that you want to lock Rev-Trac. Click the Yes button.

2b. Using transaction SM37 in the current master, ensure that jobs that run the following programs are set never to run again in this system:

/RSC/MF_BATCH_MIGRATION_UTIL /RSC/CE_SEND_MAIL_SUBMIT /RSC/OP_CREATE_TX_SUMM_SUBMIT /RSC/MF_BACKUP_MIG_HIST_SUBMIT

Table 7-2 shows details of these jobs. Note that after this change, the /RSC/MIGRATION_MONITOR job should continue to run on this system.

Appendices 175

mailto:[email protected]


Program Default job name Event driven? Action

/RSC/MF_BATCH_MIGRATION_UTIL << Customer defined >> Sometimes Stop /RSC/CE_SEND_MAIL_SUBMIT /RSC/SEND_EMAIL Yes Stop /RSC/OP_CREATE_TX_SUMM_SUBMIT /RSC/OOPS_REFRESH No Stop /RSC/MF_BACKUP_MIG_HIST_SUBMIT /RSC/LANDSCAPE_SNAPSHOT No Stop /RSC/CEM_MIGRATION_MON_SUBMIT /RSC/MIGRATION_MONITOR Yes Keep

Table 7-2: Rev-Trac jobs. After locking Rev-Trac,use SM37 to prevent all but the last job in this table from running again in the current master

Step 3: Extract data and settings from current master

3a. If: The new master is a system copy of the current master, and No Rev-Trac related RFC destinations, customer exits or

migration jobs were created in the current master after the time of the system copy

go straight to step 3e.

3b. Either export or take screen dumps of Rev-Trac RFC destinations. For the names and distribution of RFC destinations that Rev-Trac requires, see Inter-system communications on page 54. The names of all Rev-Trac RFC destinations begin "Y/RSC/RFC". You may be able to export Rev-Trac RFC destinations to a transport request by exporting objects “R3TR TABU RFCDES” and “R3TR TABU RFCDOC” with the key "Y/RSC/RFC*"

3c. Either export or capture as text files any Rev-Trac customer exits you have implemented. Customers implement Rev-Trac exits by creating includes whose name begin "ZX_RSC_EI_CUST_EXIT". These includes are not supplied as part of the Rev-Trac software, and are not exported in a Rev-Trac data backup transport (see What does a Rev-Trac data backup transport include? on page 173). You will therefore need to recreate them manually in the new master. If you have implemented any Rev-Trac customer exits you will be able to display the includes using transaction SE38, and download them as text files. Alternately, you may export these includes to a transport by exporting objects matching the pattern R3TR-PROG-ZX_RSC_EI_CUST_EXIT_*

3d. Capture details of any jobs in your current master that run program /RSC/MF_BATCH_MIGRATION_UTIL (the Rev-Trac batch migration utility). Take screen dumps of the details of such jobs (including dumps of the selection variants used with each job) in enough detail to allow you to recreate the jobs manually on the new master.

176 Appendices


3e. Create a transport that holds your Rev-Trac configuration and data by running program /RSC/CE_EXTRACT_RSC_TO_TX_UTIL in your current master (Rev-Trac Console > Configuration > Tools > Backup data to transport). After running the program, check that a transport has been created and populated. Release the transport. Check in /usr/sap/trans/data and /usr/sap/trans/cofiles that the transport data file and cofile have been created.

Step 4: Import or recreate data and settings in new master

4a. If: The new master is a system copy of the current master, and There were no changes to Rev-Trac related users, trigger,

customer exits, RFC destinations or jobs in the current master after the time of the system copy

go straight to step 4g.

4b. In the new master, create the following users in SU01: RSCADMIN

This Dialog user has built-in "magic" powers for administering Rev-Trac. Create this user in the main client (for example, the client where SAPconnect has been configured as the email gateway). Assign a typical general Basis profile such as S_A.SYSTEM.

RSCBATCH This Service or Background user runs all batch jobs on the Rev-Trac master system. Create this user in the main client where SAPconnect has been configured as the email gateway. Assign profile Y:/RSC/BTC00. To ensure Rev-Trac can send workflow message correctly to internet email addresses, and to help users understand the origin of these messages, ensure that in the user master record: • •

•

•

This user's Last name is "Rev-Trac" This user's email address is completed, and has a valid email format (eg, “Rev-Trac@<yourcompany>.com”).

RSCREMOTED This Service or Dialog user supports transport release, drilldown to transports and components, and remote logon to the new master from other systems. For details on where this user is required and profile details, see:

RFC destinations to support transport release, and drilldown to transports and components on page 56 RFC destinations to support remote logon to Rev-Trac master from non-development systems on page 59

4c. Using transaction SM62, create event /RSC/TRIGGER with description "Rev-Trac batch job trigger".

Appendices 177


4d. In the new master, re-create any Rev-Trac customer exits you are using. Do one of the following:

Import the transport you created in step 3c Recreate the exit includes manually

To recreate the exit includes manually, identify the relevant exit functions in transaction SE37 (the names of Rev-Trac customer exits all begin "/RSC/EI_CUSTOMER_EXIT"). Drill into the relevant includes where these are referenced in the function source code (the includes themselves will not yet exist, so you will be prompted to create each one), then populate each include from the data you saved in step 3c.

4e. In the new master system, re-create the RFC destinations you exported to a transport or documented in step 3b. Do one of the following:

Import the transport you created in step 3b Recreate these RFC destinations manually using transaction

SM59

4f. In the new master, use transactions SM36 or SM37 to recreate the batch migration utility jobs whose details you captured in step 3d.

4g. Import into the new master the transport containing Rev-Trac configuration and data you created and released in step 3e. Check the return code. Issue a /$SYNC command to update the SAP buffers.

Step 5: Adjust and activate system-specific configuration in new master

5a. Logon to the main client of the new master as RSCADMIN.

5b. Define the new master as the Rev-Trac master. To do so: Start transaction /RSC/CF20 in the new master. The "Display

View 'System names': Overview" screen is displayed. Select Table view > Display->Change to put the screen in

change mode, then double-click “System names” to display the "Change View 'System names': Overview" screen.

If necessary, create an entry for the new master Double-click “RSC – System parameters” to display the "Change

View 'System parameters': Overview" screen If necessary, create an entry for the new master For the new master, set Func=1

5c. Do one of the following: If the previous master will no longer be part of the Rev-Trac

installation, delete the record for the previous master. Otherwise, change the Func value for the previous master on the

"Change View 'System parameters': Overview" screen of the new master to a value other than "1".

178 Appendices


5d. Verify the new master can communicate correctly with other systems in the Rev-Trac installation. To do so:

Start transaction /RSC/CE01 in the new master. The "RSC - System health check" selection screen is displayed.

Select the Perform RFC check checkbox, clear all other checkboxes, then execute the program. The report output is displayed. If inter-system communications are set up correctly in the master, you are not prompted to logon to any system while the report runs, and the report displays no errors (ie, no red traffic lights). If there is a problem: • Check if the RFC destination user exists in the destination

system/client and is suitably authorised •

•

Check if the RFC user's password has been entered correctly in the RFC destination Correct any problems, then repeat this step

5e. Distribute the new system settings to every other system in the Rev-Trac installation. To do so:

Start transaction /RSC/CE14 in the new master. The "RSC – Activate changes" selection screen is displayed.

Clear the Include parameters list checkbox, and execute the program The program silently distributes the new system settings to every other system in the Rev-Trac installation.

5f. In the new master, review the settings that determine where Rev-Trac creates, and expects to locate, transports associated with particular projects and request types. From the Rev-Trac console, select Configuration > Process > Advanced > Transport creation rules. Check whether these settings are still valid following the change of master and any other changes in system roles that may have occurred at this time. Make any adjustments that are necessary.

5g. In the new master, review the settings that limit what transports may be added to particular project / request type combinations. From the Rev-Trac console, select Configuration > Process > Assign process > Project > Assignments per project / request type > Req type > Migration source restrictions. Check whether these settings are still valid following the change of master and any other changes in system roles that may have occurred at this time. Make any adjustments that are necessary.

Step 6: Reschedule non-migration jobs and rebuild OOPS database in new master

In this step, you will reschedule Rev-Trac non-migration jobs, and rebuild the OOPS database in the new master only.

Rebuilding the OOPS database is necessary because the transport imported into the new master in step 4g contained the OOPS database for the previous master. As a result, the OOPS database for the new master may currently contain inaccuracies.

Appendices 179


Building or rebuilding an OOPS database may load a considerable amount of data into Rev-Trac tables, and this can cause space issues.

If using Oracle, or another database with a similar space allocation model, please ensure you have at least 200 MB free in tablespace PSAPUSER1D/I or SAP<SCHEMA_ID>USR in each system before performing the following steps:

6a. In the new master, reschedule Rev-Trac non-migration jobs. To do so:

Logon to the main client of the new master as RSCADMIN Start transaction /RSC/CE07.

The "RSC - Submit jobs" selection screen is displayed. Type "RSCBATCH" in the Background job user (master) field.

Select all checkboxes, then execute the program. Rev-Trac displays a report confirming that the jobs have been scheduled.

6b. In the new master, execute program /RSC/OP_CREATE_TX_SUMM_UTIL from transaction SE38. The "RSC – Create transport summary for OOPS" screen is displayed.

6c. Complete the following fields:

Field Description

System id SID of the new master

Add all OOPS information

Select

Delete DB first Select

6d. Select Program > Execute in background.

6e. After the program has run, review the job log and spool output to check whether any errors occurred.

Step 7: Create new RFC destinations

7a. Do either of the following, if appropriate: If the previous master is a development system and will continue

to operate under Rev-Trac control, create RFC destinations in the new master pointing to the previous master to support both: • •

Transport movement monitoring, and Transport release and drilldown to transports and components

If the previous master is not a development system and is to operate under Rev-Trac control in future, create an RFC destinations in the new master pointing to the previous master to support transport movement monitoring.

For details on what RFC destinations are required to support these functions, see Inter-system communications on page 54.

180 Appendices


7b. For each system from which users need to logon to Rev-Trac, create two new RFC destinations to support this function:

An RFC destination in the logon system, pointing to the new master

An RFC destination in the new master, pointing to the logon system

For a detailed description of the requirements, see RFC destinations to support remote logon to Rev-Trac master from non-development systems on page 59.

Step 8: Unlock new master

Unlock the new master to allow users to create and change Rev-Trac requests.

From the current master Rev-Trac Console, select Administration > Lock/unlock.

A dialog asks for confirmation that you want to unlock Rev-Trac. Click the Yes button.

Importing or creating and activating Rev-Trac BADI

Use this procedure to import or create and activate the Rev-Trac BADI if necessary (see Step 1: Install Rev-Trac software in new master on page 174).

The Rev-Trac BADI is called whenever a user creates a transport. The BADI is part of the Rev-Trac "enforcement" mechanism that requires users to associate each new transport with a Rev-Trac request.

There are two possible methods of installing the Rev-Trac BADI:

•

•

Import a transport − available on request from [email protected] − that contains the Rev-Trac BADI

Perform the manual procedure described below. (This method requirs no transport.)

Install the Rev-Trac BADI only in development systems, and only in systems running SAP release 4.6c or greater.

1. Start transaction SE19. The "Business Add-Ins Initial implementation Maintenance screen" is displayed.

2. Type "Z_RSC_EP_TX_BADI" in the Implementation name field, then select Implementation > Create. The "Business Add-ins: Definition" dialog is displayed.

3. Type "CTS_REQUEST_CHECK" in the Definition name field, then click the Continue button. The "Business Add-In Builder: Change Implementation Z_RSC_EP_TX_BADI" screen is displayed.

4. Type "RSC - Transport Request BADI" in the Implementation short text field, then select Implementation > Save. You are prompted to assign the BADI to a development class or package, and to a transport.

Appendices 181


5. After doing so, click the Interface tab, then double-click CHECK_BEFORE_CREATION.

The method IF_EX_CTS_REQUEST_CHECK~CHECK_BEFORE_CREATION is displayed for editing.

6. Edit the code so it appears as follows: Method IF_EX_CTS_REQUEST_CHECK~CHECK_BEFORE_CREATION. INCLUDE /RSC/EP_GEN_TX_VIA_BADI_INCL. Endmethod.

7. Select Method > Activate. The "Inactive objects for <<user ID>>" dialog is displayed.

8. Select all objects where Obj. Name is ZCL_IM__RSC_EP_TX_BADI, then click the Continue button. The class components are activated.

9. Click the Back button on the Class Builder screen. The "Business Add-In Builder: Change Implementation Z_RSC_EP_TX_BADI" screen is displayed.

10. Select Implementation > Activate. A status bar message indicates the BADI has been activated.

11. Type /$SYNC in the command field, then click the Continue button. A status bar message indicates all buffers were reset.

182 Appendices


Continuing development in other systems when Rev-Trac master is unavailable

If the Rev-Trac master system becomes unavailable, users creating transports in other development systems where Rev-Trac enforcement is turned on will still be forced to associated new transports with Rev-Trac requests, but will be unable to do so.

If these users are unable to save their work to existing transport requests, such a situation could stop them from working.

If the outage of the Rev-Trac master system is planned beforehand, it is possible to avoid this situation by taking precautions in the master system before it becomes unavailable.

On the other hand, if the outage is unplanned, it is possible to take steps in each development system after the outage has occurred to allow developers to create new transports without Rev-Trac intervention.

In either case, once the Rev-Trac master system becomes available, users will need to link any new transports created during the outage to Rev-Trac requests. This will be a manual process.

Preparing for a planned outage of the Rev-Trac master system

If you know that the Rev-Trac master system will be unavailable for a period of time, complete the following steps just before the master system is brought down.

The effect will be to turn off Rev-Trac enforcement in your other development systems, thus allowing developers to continue creating transports in these systems.

The changes you make with the following steps will remain in effect until your master system is brought up again and you undo these changes.

1. From the Rev-Trac Console on your master system, select Configuration > Systems > Systems > System parameters. The "Display View 'System parameters': Overview" screen is displayed.


3. Take and save a screenshot that shows the Enforce settings for all development systems.

Note: Development systems are those where Func=2.

4. For each development system at right, set Enforce to "00" (None).


Restoring enforcement settings in Rev-Trac master after planned outage

After your Rev-Trac master is brought up again following a planned outage, set the Enforce value for each development system back to the values shown in in the screenshot you took in step 3 above.

Appendices 183


Allowing creation of new transports following unplanned outage of Rev-Trac master

If the Rev-Trac master becomes unavailable expectedly at a time when the Enforce settings for other development systems are set to "01" (Create all transports using Rev-Trac) in the master, users will be unable to create new transports on these development systems.

To allow users to create new transports in a development system other than the Rev-Trac master under these circumstances, you will need to deactivate both the Rev-Trac BADI and Rev-Trac field exits in that system while the Rev-Trac master is unavailable.

Deactivating Rev-Trac field exits and BADI

To deactivate the Rev-Trac field exits and BADI, perform the following steps.

Note that the Rev-Trac BADI is an optional feature that is never installed on SAP releases below 4.6c.

1. To determine the name of your Rev-Trac BADI in a given development system:

Run the Health Check report (Rev-Trac Console > Administration > Health check) in your Rev-Trac master with "Include Parameters list" selected.

Search for a line in the Rev-Trac Parameters section of the report output that includes the entries, for the system concerned, "BADI_STATUS", "CTS_REQUEST_CHECK" and "IMPLEMENTATION". The Rev-Trac BADI name is the rightmost value on the line. Depending on whether the BADI was installed manually or via transport, it will be either Z_RSC_EP_TX_BADI or /RSC/DEV_EP_PLUS_TX.

2. Start transaction SE19 in the development system concerned. The "Business Add-Ins: Initial Implementation Maintenance Screen" is displayed.

3. In the Implementation name field, type the name of the BADI you identified in the first step, then select Implementation > Deactivate. A message in the status bar indicates this BADI has been deactivated.

4. Issue a /$SYNC command. The system buffers are reset, ensuring the BADI deactivation takes proper effect.

5. In transaction SE38, execute program RSMODPRF. The "Field Exits for Data Elements" selection screen is displayed.

6. Execute the program. A list of data elements and their program and screen assignments is displayed.

7. Select data elements TRKORR and TRORDERTXT, then select Field exit > Deactivate. The standard SAP "Prompt for Workbench request" dialog is displayed for screens with field exit TRKORR.

184 Appendices


8. Click the Create request button on the dialog. A new transport is created. The Request field contains the number of the new transport. The text of the new transport is "*" (asterisk).

9. Click the Continue button on the "Prompt for Workbench request" dialog. The standard SAP "Prompt for Workbench request" dialog is redisplayed, this time for screens with field exit TRORDERTXT.

10. Click the Continue button on the "Prompt for Workbench request" dialog to save the change on the same transport created previously. The list of data elements shows the status of field exits for the two data elements is now INACTIVE.

Reactivating Rev-Trac field exits and BADI

If you performed the procedure described above in Allowing creation of new transports following unplanned outage of Rev-Trac master, you will need to restore the Rev-Trac field exits and reactivate the Rev-Trac BADI in each development system as soon as the master system is again available in order to reactivate Rev-Trac transport enforcement.


1. In transaction SE38, execute program RSMODPRF. The "Field Exits for Data Elements" selection screen is displayed.

2. Execute the program. A list of data elements and their program and screen assignments is displayed.

3. Select data elements TRKORR and TRORDERTXT, then select Field exit > Activate. You are prompted twice to associate each activation with a transport. Either select an existing transport, or create a new transport using the standard SAP transport creation method. The list of data elements shows the status of field exits for the the two data elements is now ACTIVE.

4. Start transaction SE19. The "Business Add-Ins: Initial Implementation Maintenance Screen" is displayed.

5. Type Z_RSC_EP_TX_BADI in the Implementation name field, then select Implementation > Activate. A message in the status bar indicates this BADI has been activated.

6. Issue a /$SYNC command. The system buffers are reset, ensuring the BADI activation takes proper effect.

Appendices 185


Setting up request cloning

Automatically cloning requests from one Rev-Trac project into another is a convenient and reliable way of ensuring that all changes made in one project (for example, production support) are tracked as candidates for subsequent application to another project (eg, system upgrade).


•

•

•

•

•

•

•

•

Provide an overview of the steps involved in setting up request cloning

Explain the differences between a cloned request and its original

Describe options available when cloning requests

Provide sample code for a Rev-Trac customer exit that clones requests

Implementation overview

To activate request cloning, users implement and then enable a Rev-Trac customer exit that is called every time a request's status is about to change.

The customer exit code determines whether it is appropriate to clone the Rev-Trac request whose status is about to change at this point in its lifecycle, and if so, calls the Rev-Trac cloning program with appropriate parameters.

The Rev-Trac customer exit that needs to be implemented is /RSC/EI_CUSTOMER_EXIT_004.

The Rev-Trac cloning program is /RSC/CR_COPY_REQUEST_UTIL_02.

For details of how to enable the customer exit after it has been coded and generated, see Enabling the Rev-Trac status change customer exit on page 189.

Differences between original request and its clone

A cloned Rev-Trac request contains the same request header information and references as the original request, except that:

The cloned request belongs to a different Rev-Trac project from the original

The cloned request is created with the status New, regardless of the status of the original request

The ID of the "Changed by" user in the cloned request is normally different from the original

The cloned request contains a reference to the original request

The original request's history log, special approvers and attachments are not cloned, and the original request's approval history and change log are discarded in the clone.

186 Appendices


Cloning options

The Rev-Trac program that performs the actual cloning (/RSC/CR_COPY_REQUEST_UTIL_02) requires parameters that determine:

•

•

•

•

Whether the cloned request should include the transports attached to the original request

What reference type should be used for the reference to the original request

The "Changed by" user ID for the cloned request

Which Rev-Trac project the cloned request will belong to

The Rev-Trac customer exit that calls /RSC/CR_COPY_REQUEST_UTIL_02 needs to provide these parameters.

Implementing user exit /RSC/EI_CUSTOMER_EXIT_004

To implement Rev-Trac's "on status change" user exit /RSC/EI_CUSTOMER_EXIT_004, perform the following steps.

1. In transaction SE38, create an include named ZX_RSC_EI_CUST_EXIT_004_INCL with the title "Include for Rev-Trac Customer Exit - On Request Status Change". Save the include as a local object.

Note: If a warning message is displayed indicating that the name of this include is reserved for other uses, press Enter to continue.

2. Type or copy and edit the required user exit code in the include. For a code example, see the next topic.

3. Activate the include.

Note: A syntax warning beginning "The field 'REQUEST' is unknown..." may be expected, and can be safely ignored.

Sample customer exit code

The following is an example of how Rev-Trac customer exit /RSC/EI_CUSTOMER_EXIT_004 many be coded to clone Rev-Trac requests:

Appendices 187


DATA: W_REQUEST LIKE /RSC/T_RM_3A, BEGIN OF W_MSG, MSGID LIKE SY-MSGID, MSGTY LIKE SY-MSGTY, MSGNO LIKE SY-MSGNO, MSGV1 LIKE SY-MSGV1, MSGV2 LIKE SY-MSGV2, MSGV3 LIKE SY-MSGV3, MSGV4 LIKE SY-MSGV4, END OF W_MSG, W_MEMID(10) VALUE 'RTCLONE'. * Clone Rev-Trac request if required. * * In this example, request must be in * Project "SUPP" (Support) * and Status must be "Q-MG" (Approved for PRD). IF REQUEST-PROJECT = 'SUPP' AND REQUEST-STATUS = 'Q-MG'. * Send Rev-Trac header via memory W_REQUEST = REQUEST. EXPORT W_REQUEST TO MEMORY ID W_MEMID. * Launch customer exit program (called in separate data area) SUBMIT /RSC/CR_COPY_REQUEST_UTIL_02 AND RETURN WITH P_MEMID = W_MEMID WITH P_REQ = W_REQUEST-REQUEST * Adjust the following four parameters to suit * your own requirements WITH P_ADDTX = 'X' "ATTACH TRANSPORTS WITH P_RTYPE = 'MY_TYPE' "REFERENCE TYPE WITH P_TOPROJ = 'MY_PROJ' "NEW PROJECT Reapplication) WITH P_USER = 'AUTO-COPY'. "NAME OF CREATING USER * * Get return Message via memory IMPORT W_MSG FROM MEMORY ID W_MEMID. * Send Message IF NOT W_MSG IS INITIAL. MESSAGE ID W_MSG-MSGID TYPE 'I' NUMBER W_MSG-MSGNO WITH W_MSG-MSGV1 W_MSG-MSGV2 W_MSG-MSGV3 W_MSG-MSGV4. ENDIF. ENDIF.

The sample code above uses the value W_REQUEST in the EXPORT... TO MEMORY statement, and uses the value W_MSG in the IMPORT ... FROM MEMORY statement.

The values W_REQUEST and W_MSG may not be varied.

188 Appendices


Enabling the Rev-Trac status change customer exit

After you have provided a code body for Rev-Trac status change customer exit /RSC/EI_CUSTOMER_EXIT_004, you will need to enable this exit by entering a suitable over-ride.

To do so, perform the following steps:

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



Field Description

Parameter CUSTOMER_EXIT

Sub Parameter 1 004

Sub Parameter 2 To enable cloning for a single user, type "USER=NNNNNN", where NNNNNN is the user ID of the single user. To enable cloning for all users, type "USER=*", where the last character is an asterisk.

Value ON


Appendices 189


Adding fields to the Request Details screen

An organisation can add its own custom fields to the Rev-Trac "Request Details" screen.

A user of the "Request Details" screen can access these fields at any time by selecting Request > Custom fields from the "Request Details" screen. Rev-Trac displays the custom fields in a separate window.

If any custom field has been configured as mandatory (via Rev-Trac Console > Configuration > Process > Request screen > Field attributes > Attr), Rev-Trac displays the custom fields window and requires the user to complete the mandatory fields before the user is able to save the request.

If change logging has been activated for the field concerned (by selecting "Change document" for the underlying data element), Rev-Trac tracks changes to the contents of the field. A user can display such changes from the Rev-Trac Workbench ("tree") screen by selecting a request, then selecting Extras > Show Change Log.

By default, all custom fields are accessible for all types of requests in all projects. You can configure individual custom fields (for example, to make them mandatory, or to restrict access via authorisation) just the same as for any other fields on the "Request Details" screen, by selecting Rev-Trac Console > Configuration > Process > Request screen > Field attributes.

Perform the following steps only if you are familiar with the SAP data dictionary.

Steps

1. Using transaction SE11, show table /RSC/T_RM_3H in display mode (not change mode).

2. Add an append structure by selecting Go to > Append structure from the menu. Use a structure name such as ZARSCT_RM_3H.

3. Populate this new structure with all your custom fields.

4. If required, link in F4 values and documentation using standard SAP data dictionary functions.

5. Assign the new structure to one of your own development classes.

6. To define any custom field as mandatory, or to define any other field-specific attributes for a custom field, select Configuration > Process > Request screen > Field attributes from within transaction /RSC/RT, then set the appropriate attributes for field /RSC/T_RM_3H-NEWFIELD, where NEWFIELD is the name of your custom field.

190 Appendices


Adding a tab to the Rev-Trac Console screen

You can add one or more tabs to the Rev-Trac Console screen to make additional system functions readily available to Rev-Trac users.

You can also suppress the display of any of the standard Rev-Trac tabs on this screen. You may find this helpful if you want to give greater prominence to your custom tabs.

Figure 7-1 below shows a Rev-Trac Console screen where a tab called Extra functions has been added, and where the standard My Scratchpad tab has been suppressed.

In this example, the Extra functions tab contains a single button labelled SAP System Log. When a user clicks this button, the standard SAP System Log transaction begins.

Figure 7-1: An extra tab has been added to the Rev-Trac Console screen, and one standard tab has been suppressed

The following topics describe the process used to add this tab, and to suppress a standard tab.

The process has two main phases:

•

•

An ABAP programmer (preferably a person familiar with programming SAP dialog screens) creates and programs a subscreen that implements whatever functions you want to make available on the new tab

The Rev-Trac administrator enters over-rides to cause the subscreen to appear on a new tab, and optionally enters further over-rides to suppress any unwanted standard tabs

Appendices 191


Creating a subscreen for new tab

To create a suitable subscreen for a new Rev-Trac Console tab, an ABAP programmer will need to perform the following steps:

•

•

•

•

Create a program of type "module pool"

Create a subscreen in this module pool

Layout the subscreen components

Write the flow logic and ABAP code for the subscreen

The following topics describe these steps in greater detail.

This discussion assumes the person performing these tasks is an ABAP programmer who has some familiarity with programming SAP dialog screens.

Creating a program of type 'module pool'

Using transaction SE80, the developer creates a program of type "module pool".

For the example shown in Figure 7-1 above, the program was called Z_RT_TAB.

For a simple tab, no top include is required.

Creating a subscreen within the module pool

Using transaction SE80, the developer adds a screen of type "subscreen" to the module pool created in the previous step.

For the example shown in Figure 7-1 above, the subscreen was numbered 9999.

Laying out the subscreen

Using a screen editor within SE80, the developer lays out components on the subscreen.

For the example shown in Figure 7-1 above, the developer added a single push button.

The text of the push button was set to "SAP_System_Log". The FctCode was set to "LOG". The Name of the push button was set to "GW_LOG".

The developer saves and activates the subscreen.

Writing flow logic and ABAP code for the subscreen

In the main part of the module pool, the developer creates any necessary data declarations.

For the example shown in Figure 7-1 above, the developer added the following line:

DATA: OK_CODE TYPE SY-UCOMM.

The developer then creates and programs suitable modules to implement the subscreen logic.

For the example shown in Figure 7-1 above, the developer uncommented the line

* MODULE USER_COMMAND_9999.

192 Appendices


in the flow logic for screen 9999, then created a suitable PAI module by double-clicking USER_COMMAND_9999.

In module USER_COMMAND_9999, the developer then wrote the following code:

OK_CODE = SY-UCOMM. CASE OK_CODE. WHEN 'LOG'. CALL TRANSACTION 'SM21'. ENDCASE.

The developer saves and activates all changes.

Entering over-rides to display new tab and (optionally) to suppress standard tabs

Table 7-3 below lists the over-rides used to achieve the result shown in Figure 7-1 once the programming described above was completed.

Parameter Sub Parameter1 Sub Parameter2 Value TABSTRIP_DISPLAY TS_RT_MY_RT_TAB6 USER=* ON TABSTRIP_PROGRAM TS_RT_MY_RT_TAB6 USER=* Z_RT_TAB TABSTRIP_SUBSCREEN TS_RT_MY_RT_TAB6 USER=* 9999 TABSTRIP_TABTITLE TS_RT_MY_RT_TAB6 USER=* Extra functions TABSTRIP_DISPLAY TS_RT_MY_RT_TAB4 USER=* OFF

Table 7-3: Over-rides used to add new tab and suppress a standard tab, as seen in Figure 7-1

To create or edit over-rides from the Rev-Trac Console screen, select Configuration > Global > Advanced. Note that the Value column may be hdden by default. To expose this field, double-click anywhere within a field.

Entries similar to the first four in Table 7-3 above are required to display the new tab. The fifth entry suppresses the display of the standard My Scratchpad tab.

Rev-Trac has five standard tabs, numbered 1 to 5 from left to right. Thus the My Scratchpad tab is referred to a tab 4 in the Sub Parameter1 column. The first custom tab you add is tab 6. If you were to add further custom tabs, these would be numbered 7, 8 etc.

The entries in the Value column should be largely self-explanatory.

For the TABSTRIP_PROGRAM over-ride, the Value is the name of the relevant module pool program.

For the TABSTRIP_SUBSCREEN over-ride, the Value is the number of the subscreen to be displayed on the tab.

For the TABSTRIP_TABTITLE over-ride, the Value is the tab text to be displayed to users.

When initially testing the new tab, you may prefer to expose the tab only to yourself. To achieve this result, type an entry in the Sub Parameter2 column that references your own user ID. For example, if your SAP user ID is JSMITH, type USER=JSMITH in the Sub Parameter2 column for each entry, rather than USER=*. When you are ready for all users to see the tab, replace these entries with their USER=* equivalents.

Appendices 193


[This page is intentionally blank.]

Page 194 Index


/RSC/MIGRATION_MONITOR job ............. 111 User administration, for.......................... 142 Utility programs, for................................ 146 /RSC/OOPS_REFRESH job ....................... 111

/RSC/TRIGGER event Creating................................................... 90 Recreating after moving master ............ 177 With parameter IMPORT etc, when raised

........................................................... 88

Authorisation objects Y/RSC/CE02 (Field level) .............. 139, 145 Y/RSC/CE03 (User privileges)....... 139, 145 Y/RSC/CE04 (Tools / utilities)................ 146 Y/RSC/CE05 (Configuration) ................. 147 Y/RSC/CE06 (Delegation) ............. 139, 148 <AM> AUTOMIG approver....See Autoapproval Y/RSC/RM01 (Migration Workbench target

groups) ............................................. 149 <NO> No approval required ........ See Positions <OW> Request owner................. See Positions <PG> Request programmer........ See Positions <TM> Request team ....................... See Teams abap/field exit instance parameter ..... See Field

exits

Autoapproval .................................................72 Alternative human approver also required73 Autoapprover

<AM> position .............................................. 74 AUTOMIG displayed on Rev-Trac Workbench

................................................................ 72 AdminAuth setting......................... 21, 139, 140 Automigration, often combined with.........73

Migration job user, value required for ...... 89 Append structure for /RSC/T_RM_3A......... 190 Approval type

Creating................................................... 48 Effect on total number of approvals......... 20

Batch migration utility invokes..................89 Configuring ........................................ 26, 73 Display on Rev-Trac Workbench .............26 Migration return code

Ignored where Chk Level=9 ................... 67, 73 Required before approval............................. 73 Approvers Tutorial demonstration .............................15 Configuring ........................................ 19, 35 When triggered ........................................73 Requiring multiple approvals ................... 47

AUTOMIG approver ..............See Autoapproval Approving request Activating one-click approval ................... 50 Automigration

Autoapproval, often combined with..........73 Autoapproval ...................See Autoapproval Configuring ..............................................71 Manually after failed migration............... 103 Overview..................................................71 Tutorial demonstration............................. 13 Tutorial demonstration ....................... 13, 23 Archiving

Backup transport Rev-Trac migration queue items .. See Rev-Trac migration queue

Assignment .............. See Project / request type assignment

Asterisk in Rev-Trac locking message ........ 126 Auditing

Contents ................................................ 173 Creating ................................................. 177

BADI Creating and activating .......................... 181 Deactivating when master unavailable ..184 Purpose ................................................. 181

OOPS messages................................... 119 Where required ...................................... 175 Parallel development..................... 125, 134 Rev-Trac locking system messages..... 123,

134

Batch migration utility ....................................88 /RSC/MF_BATCH_MIGRATION_UTIL....88 Adding queue items while program is

running ...............................................90 Autoapproval with ....................................89 Effect on display of Rev-Trac migration

queue .................................................88 Lock key (stop a parallel run) field ...........89

Messages suppressed by rules ................. 138 Rev-Trac migration queue history ........... 98

Authorisation AdminAuth setting ......................... 139, 140 Authorisation objects ....... See Authorisation

objects Overview of job setup options..................88 Authorisations per profile....................... 144 Selection parameters...............................91 Workflow..................................................91 Chg Auth setting............................ 139, 140

Cre Auth setting............................. 139, 140 Change management process Creating and change requests, for ........ 139

Defining, explained by tutorials ..................3 Plain English report..................................53

Check Rev-Trac Configuration report ............74

Delegate setting .................................... 139 Delegation, for ....................................... 148 Field level .............................................. 139 Gen Auth setting............................ 139, 140 Chg Auth setting.................................. 139, 140 Migration, for ......................................... 146 Chk Level field..................... See Target groups

Chronological report ........See Migration reports Cloning ...............See Rev-Trac request cloning Cofiles

Copying back to master after migration to remote transport directory .......... 66, 100

Not moved by quarantine utility................97

Overview ............................................... 140 Preselecting approvers, for.................... 139 Profiles ..................................... See Profiles Quick start guide ................................... 139 Reference data...................................... 142 Remote logon, how checked ................... 59 SAP_ALL not sufficient.......................... 140

Communications............. See RFC destinations Switches affecting authorisation checking......................................................... 140 Complete status .......................................... 127

TX Del setting................................ 139, 140

Index 195


Completion rules See Request completion rules Components..................See Rev-Trac software Configuration................. See SAP configuration Cre Auth setting .................................. 139, 140 CTS

API called by Rev-Trac............................ 99 Setup required by Rev-Trac .................... 99

Custom fields, adding.................................. 190 Customer exits

/RSC/EI_CUSTOMER_EXIT_004 ......... 187 Exporting ............................................... 176 Recreating in new master...................... 178 Stored on master................................... 173

Data file......................... See Transport data file Delegate configuration setting..................... 139 Dependency checking............... See Reference Destinations .........................See Target groups Distinguish button ........... See Migration reports Dynamic links............................ See Reference Dynamic queue sequence........... See Rev-Trac

migration queue Email ........................................... See Workflow Emergency

Creating transports when master unavailable....................................... 183

Enforcement........... See Rev-Trac enforcement Event...................... See /RSC/TRIGGER event Failed statistics ............................................. 64 Field

Adding to Request details screen.......... 190 Authorisation checks for specific fields.. 139 Mandatory for all statuses .......See Request

details screen Mandatory for certain statuses See Request

completion rules Suppressing ............................................ 53

Field exits abap/field exit instance parameter......... 126 Disabling in emergency ......................... 146 FIELD_EXIT_TRKORR function module126 FIELD_EXIT_TRORDERTXT function

module............................................. 126 TRKORR data element ......................... 126 TRORDERTXT data element ................ 126

FIELD_EXIT_TRKORR..............See Field exits FIELD_EXIT_TRORDERTXT ....See Field exits Foreground migration.................. See Migration Foreign transport...... See OOPS (Overtake and

Overwrite Protection System) Freezing queue .See Rev-Trac migration queue FTP setting...........................See Target groups FULL_QUE .. See Lock key (stop a parallel run)

field Gen Auth setting ................................. 139, 140 History............See Transport movement history Hold date...........See Rev-Trac migration queue Hold mode setting ................See Target groups Hybrid transports

Migrated to which destinations ................ 65 Imp entry on OOPS report .......................... 116

Import buffer, SAP.........................................99 In Migration statistics .....................................64 Include Monitor Jobs report checkbox......... 111 Jobs

/RSC/LANDSCAPE_SNAPSHOT job .....96, 105

/RSC/MIGRATION_MONITOR job110, 114, 126

/RSC/OOPS_REFRESH job .. 110, 113, 126 Job users

Batch migration utility ................................... 89 Migration monitor ................... 110, 114, 126 Migration queue, processing....... See Batch

migration utility Naming conventions

Batch migration utility ................................... 89 OOPS refresh ........................ 110, 113, 126 Optional job to archive historical Rev-Trac

migration queue data .........................98 Required by Rev-Trac locking system ...126 Role of master in running....................... 172 Scheduling non-migration jobs............... 180

Landscape Defined ....................................................54

Landscape snapshot Capturing manually..................................96 Daily job capturing ........................... 96, 105 Landscape snapshot ID field....................96 Migration reports, examples of use with 105

Landscape snapshot ID field .... See Landscape snapshot

Lock.................... See Rev-Trac locking system Lock key (stop a parallel run) field.................89 Lock mode setting ...........See Rev-Trac locking

system Lock/unlock master ............................. 175, 181 Logical transport objects.............................. 126 Mandatory field, defining ....................... 52, 166 Master system

Defined ....................................................54 Moving ...................................................171 Role in running jobs ............................... 172 Setting ...................................................178 Shutdown, coping with........................... 183 Unique properties .................................. 171

Mig setting ......................................... 25, 71, 72 Mig target setting...........................................25 Migration

Automatic........................See Automigration Configuration in Rev-Trac, reviewing.......74 From Rev-Trac Migration Workbench....See

Rev-Trac Migration Workbench Method and target, defining .....................23 Non-queued.............................................62 Overview..................................................62 Preventing unintended re-migration.........70 Queued.............................................. 62, 75 Queued and non-queued compared ........62 Reports ......................See Migration reports Tools............................. See Migration tools Underlying mechanisms in Rev-Trac .......99 Use of tp and TMS after installing Rev-Trac

...........................................................62 Workflow............................................ 73, 99

Page 196 Index


Migration log ................... See Migration reports Quarantining, effect on overtake warnings......................................................... 120 Migration monitor job ......................... See Jobs

SAP configuration, exempting from OOPS checking...........................................113

Migration queue See Rev-Trac migration queue Migration reports

Chronological report .............................. 101 SID, defining special OOPS mode for.... 113 Table data

Activating table-level checking ................... 137 Data automatically excluded from checking110 Excluding or including specific ................... 136

Target group, defining special OOPS mode for.....................................................113

Troubleshooting

Migration log.......................................... 104 Plan vs reality report.............................. 103 Propagation report................................. 100

Distinguish button....................................... 101 Landscape snapshot, using with................ 105 Sort order ................................................... 101 System Rep setting, effect on .................... 101

Quarantined transports report ............... 104 "OOPS has not checked actual table entries".............................................................. 116

Limitations .................................................. 105 "Overtake" of transport already sent .......... 114 User ID, defining special OOPS mode for

......................................................... 113 Warning

Ignoring ...................................................... 109 Screenshot ................................................. 109

OOPS and Locking rules Order of evaluation ................................ 137 Overview................................................ 135 Wildcards, using in rules ........................ 135

Organisation Adding users............................................42 Assigning to project / request type...........19 Displaying ................................................43 Organisation structure .............................23 Overview..................................................20 Standin ..................................................See

Over-rides BUILD_CONFIG_SUMMARY........ 113, 130 CUSTOMER_EXIT ................................ 189

System/client comparison...................... 102 Landscape snapshot, using with................ 105

Transport lists, creating from within reports......................................................... 105

Migration source restictions Reviewing after moving master ............. 179

Migration tools Adding and removing sent indicators ...... 96 Archiving historical Rev-Trac migration

queue data......................................... 98 Capturing a landscape snapshot ............. 96 Overview ................................................. 96 Quarantining transports ........................... 97 Releasing transports ............................... 98 Uploading and downloading transports from

PC...................................................... 98 Migration Workbench ...See Rev-Trac Migration

Workbench Monitored system

Defined.................................................... 54 EXIT_REF_DPREFERENCE................. 163 EXIT_REF_PGM_SMART..................... 163 LOCK_CONFIG ..................................... 129 LOCK_CONFIG ..................................... 135 LOCK_CROSS_FSY>TSY .................... 129 LOCK_ID_XXXXXX ...............................129 LOCK_PROJ_PPPP>SYS..................... 129 LOCK_PROJECT_STATUS .................. 130 MSG_/RSC/CE03 .................................. 154 ONE_CLICK_APPROVAL .......................51 OOPS_CHECK_DFE............................. 113 OOPS_CONFIG .................................... 113 OOPS_ID_XXXXXX ..............................113 OOPS_REVERT_STATUS.................... 113 OOPS_SID_XXX ...................................113 OOPS_SUPPRESS_FOREIGN............. 122 OOPS_TAR_XXXXXX........................... 113 TABSTRIP_DISPLAY ............................ 193 TABSTRIP_PROGRAM......................... 193 TABSTRIP_SUBSCREEN..................... 193

Non-queued migration method...................... 62 Number setting.............................................. 35 One-click approval ........................................ 50 OOPS

Database, rebuilding ............................. 179 OOPS (Overtake and Overwrite Protection

System) Checks

Automatic, when performed ....................... 108 Manual, performing .................................... 117 Retrospective, performing .......................... 118 When migrating from Rev-Trac Migration

Workbench.............................................. 94 Chk Level=9, special OOPS check required

........................................................... 68 Database............................................... 110 Fine-tuning via over-rides...................... 112 Foreign transports

Meaning of OOPS message ...................... 115 Suppressing OOPS messages .................. 121 TABSTRIP_TABTITLE .......................... 193

Imp date and time.................................. 116 Overtake.. See OOPS (Overtake and Overwrite Protection System)

Overwrite . See OOPS (Overtake and Overwrite Protection System)

Owner.............................See Rev-Trac request Parallel development

Permissions Granting.............................................. 124, 131 Identifying ................................................... 134 Logged ....................................................... 125 Rescinding.................................................. 133

Risks associated with ............................ 122

Messages Retrieving ................................................... 119 Written to Rev-Trac system log.................. 109

No alerts when using native SAP migration functions .......................................... 108

OOPS global parameter ........................ 111 OOPS Monitor Alert dialog .................... 109 Overview ............................................... 107 Performance, boosting via table level

checking .......................................... 137 Pre-requisites ........................................ 110

Index 197


Password How checked when logged on remotely.. 59

Performance, improving ................................ 98 Plan vs reality report ....... See Migration reports Positions

<AM> Auto-approver ............................... 22 <NO> No approval required .................... 22 <OW> Request owner............................. 22 <PG> Request programmer .............. 22, 37 Creating................................................... 41 Overview ................................................. 21

Possible conflict only OOPS message........ 116 Pre-requisites

OOPS.................................................... 110 Rev-Trac locking system ....................... 126

Profiles SAP_ALL............................................... 140 Y:/RSC/ADM00 ............................. 139, 142 Y:/RSC/ADM01 ..................................... 142 Y:/RSC/ADM02 ..................................... 142 Y:/RSC/ADM03 ..................................... 142 Y:/RSC/ADM04 ..................................... 142 Y:/RSC/ADM05 ..................................... 142 Y:/RSC/ADM06 ..................................... 142 Y:/RSC/BTC00 ...................................... 142 Y:/RSC/BTC01 ...................................... 142 Y:/RSC/BTC02 ...................................... 142 Y:/RSC/RFC00 .........56, 57, 59, 60, 61, 142 Y:/RSC/RFC01 ...................................... 142 Y:/RSC/RFC02 ...................................... 142 Y:/RSC/RFC03 ...................................... 142 Y:/RSC/USR00.............................. 139, 143 Y:/RSC/USR01...................................... 143

Programmer ................... See Rev-Trac request Programs

/RSC/CE_DISABLE_INTEGRATN_UTIL......................................................... 146

/RSC/CE_SEND_APP_REMINDER_UTIL......................................................... 146

/RSC/CR_COPY_REQUEST_UTIL_01 147 /RSC/CR_COPY_REQUEST_UTIL_02 147,

186 /RSC/CR_UPLOAD_REQUEST_UTIL.. 147 /RSC/INTERNAL_COPY_TXELEM_UTIL

......................................................... 146 /RSC/MF_ARCHIVE_QUE_REC_UTIL... 98 /RSC/MF_BACKUP_MIG_HIST_UTIL .. 146 /RSC/MF_BATCH_MIGRATION_UTIL 146,

See Batch migration utility /RSC/MF_CHECK_TX_CLASS_UTIL ... 147 /RSC/MF_SIMULATE_MIG_EVNT_UTIL

......................................................... 146 /RSC/MF_TX_MIGRATION_TOOL_UTIL

......................................................... 147 /RSC/OP_CREATE_TX_SUMM_SUBMIT

......................................................... 111 /RSC/OP_CREATE_TX_SUMM_UTIL.. 180 /RSC/OP_OVERTAKE_REPT............... 118 /RSC/RM_DEL_SPEC_MIG_INST_UTIL

......................................................... 147 /RSC/RM_DELETE_REQ_DATA_UTIL 147 /RSC/RM_MASS_STATUS_CHNG_UTIL

......................................................... 147 Authorisation checks for specific programs

......................................................... 146

Project Copying....................................................28 Rationale for using...................................28 Request types available within.................28

Project / request type assignment Organisation ............................................19 Overview..................................................16 Requirement (completion rules)............. 168 Strategy ............................................. 16, 37

Propagation button ...................................... 101 Propagation report...........See Migration reports Quarantine..............See Transport quarantining Quarantined transports report .....See Migration

reports Queue............... See Rev-Trac migration queue Queue Statistics ...................................... 64, 76 Queued migration..........................................75 Ref user field .................................................40 Reference

Button on request details screen ........... 152 Dependency-checking ................... 157, 162 Dynamic links......................................... 153 F4 dropdown list when selecting............ 155 Launching ..............................................156 Mandatory before saving request .......... 154 Mandatory for certain statuses See Request

completion rules Over-rides for controlling display of

'Reference index' dialog ................... 154 Over-rides for dependency checks ........ 162 Searching requests by ........................... 153 Smart .....................................................154 Type....................................................... 151 Type, creating ................................ 160, 161 URL, to .......................................... 156, 161 Validation, advanced ............................. 155 Validation, basic..................................... 151

Releasing transports................. See Transports Remote logon to Rev-Trac master, enabling .59 Reports

Check Rev-Trac Configuration........... 53, 74 Migration ....................See Migration reports

Request ..........................See Rev-Trac request Request completion rules

Example messages ............................... 168 Overview................................................ 166 Requirement, assigning to project / request

type .................................................. 168 Requirement, defining............................ 166

Request details screen Adding custom fields.............................. 190 Mandatory field, defining..........................52 References button .......................................

Request transport sequence ............. 80, 81, 82 Request type

Adding to project......................................45 Creating ...................................................44

Requirement...... See Request completion rules Return codes

Codes above 900................................... 100 Reported in Migration log....................... 104 Required for autoapproval .......................73

Rev-Trac Console screen

Page 198 Index


Adding and removing tabs..................... 191 Rev-Trac enforcement

Disabling when master unavailable ....... 183 Enforcement popup ......................... 12, 124

Rev-Trac locking system Compared with SAP locking .................. 122 Complete status, effect on locking......... 127 Configuring, overview............................ 126 Cross-landscape locking ....................... 127 Intra-landscape locking ......................... 127 Lock mode for statuses, effect of........... 127 Lock system setting............................... 127 Logging of lock messages..................... 123

Suppressed by rules .................................. 138 Logical transport object ......................... 126 Message

Retrieving ................................................... 134 Screenshot ................................................. 124

Options.................................................. 126 Over-rides affecting ............................... 130 Pre-requisites ........................................ 126 Purpose................................................. 122 Releasing and reactivating locks ........... 127 Table data

Disabling locking for all SAP configuration 134 Excluding or including specific ................... 136

Rev-Trac migration queue Adding items

From Rev-Trac Migration Workbench.......... 95 Overview ...................................................... 75 When batch migration utility running............ 90

Archiving.................................................. 98 Batch migration utility .. See Batch migration

utility Changing ..................................... 77, 83, 84 Deleting items.......................................... 84 Displaying................................................ 75 Dynamic sequence.................................. 80 Effect on colour of sent indicator ............. 69 Green items............................................. 78 Hold date

Changing or deleting.................................... 84 Display of items with hold date set............... 78 Setting .......................................................... 67

Migrating items ... See Batch migration utility Multiple items in....................................... 76 OOPS check of queue, performing........ 117 Red items ................................................ 78 Sequence

Changing...................................................... 85 Factors affecting..................................... 76, 79 Freezing ................................................. 77, 86 Unfreezing.................................................... 87

Rev-Trac Migration Workbench Authorisation ......................................... 146 Creating transport lists from .................... 95 OOPS check, performing....................... 117 Overview ................................................. 92 Performing migrations from ..................... 94 Populating ............................................... 92 Screenshot .............................................. 92 Sending items to Rev-Trac migration queue

........................................................... 95 Rev-Trac Monitored System Screen ............. 59 Rev-Trac request

Adding custom fields ............................. 190 Creating..................................................... 8

Details screen .. See Request details screen Owner

Notified on migration failure.............................. Programmer

Notified on migration failure.............................. Rev-Trac request cloning

/RSC/EI_CUSTOMER_EXIT_004 ......... 186 Cloning program .................................... 186 Differences between original request and

clone ................................................ 186 Enabling customer exit via over-ride...... 189 Options .................................................. 187 Overview................................................ 186 Sample customer exit code.................... 187

Rev-Trac software Components for different system types .174

Rev-Trac system log Locking system messages logged ......... 123 Locking system messages, suppressed

Logged ....................................................... 138 OOPS messages

Retrieving ................................................... 119 Parallel development permissions

Logged ....................................................... 125 RFC destinations

Authorisation checking via .......................59 Drilldown to transport components via.....56 Exporting................................................ 176 Naming convention .......... 56, 57, 59, 60, 61 Password checking via ............................59 Purpose ...................................................54 Restoring in new master ........................ 178 Transport movement monitoring via ........56 Transport release via ...............................56

RSC_TUTORIAL.txt ........................................4 RSCREMOTE .................................. See Users RSCREMOTED................................ See Users SAP configuration

Changes locked by Rev-Trac at table, not key, level .......................................... 125

SAP Notes 51373 Problems with WAN link progress

indicator .............................................57 SAP_ALL profile

Preventing inclusion of Rev-Trac authorisation objects in .................... 140

Rationale for AdminAuth setting ............ 140 Searching for requests

By reference .......................................... 153 Security .................................See Authorisation Sent indicators

Adding and removing......................... 70, 96 Consequence of deleting queued items...84 Overview..................................................68 Significance of colour...............................69

Sequence field............... See Request transport sequence

Set setting ........................... See Target groups Signature ................................... See Approvers Signer ........................................ See Approvers SIN user parameter .......................................57 Slave system

Creating transports when master system down ................................................ 183

Index 199


Defined.................................................... 54 Snapshot................... See Landscape snapshot SOBJ........................................................... 126 Special migration instructions

Adding to a request ................................. 63 Removing from a request ........................ 98

Standin...................................See Organisation Status

Adding to strategy ................................... 33 Complete, effect on locking ................... 127 Creating new status................................. 33 Displaying all statuses............................. 33 Lock mode setting ................................. 127 Migration............................................ 73, 89 Post-migration ................................. 73, 103 Status sequence defined in strategy ....... 17

Status path....................................See Strategy Strategy

Adding statuses to................................... 33 Assigning to project / request type .... 16, 37 Copying ................................................... 32 Displaying................................................ 17

System parameters Lock....................................................... 127

System/client comparison report. See Migration reports

Table data ..................... See SAP configuration Table-level OOPS checking .............See OOPS

(Overtake and Overwrite Protection System) Tables

/RSC/T_DEMO_CUST ............................ 10 /RSC/T_MF_4H....................................... 98 /RSC/T_MF_4HI...................................... 98 /RSC/T_MF_4L ..................................... 134 /RSC/T_MFM_4B .................................. 110 /RSC/T_MFM_4C.................................. 110 /RSC/T_MFM_4S .................................. 110 /RSC/T_MFM_4T .................. 110, 113, 130 AGR_* ................................................... 110 Delivery class A excluded from OOPS .. 110 SPERS_OBJ ......................................... 110 USR* and UST*..................................... 110

Target groups Assigning................................................. 46 Chk Level setting............................... 67, 73 Defining ............................................. 45, 65 FTP setting .............................................. 66 Hold mode setting ................................... 67 Identifying plan vs reality mismatches ... 103 Overview ................................................. 65 Preventing unintended remigration.......... 70 Set setting ......................................... 66, 70 Special OOPS mode for ........................ 113 Tutorials, defining for................................. 6 Umodes setting

Default.......................................................... 66 Per destination ............................................. 66

Teams * (asterisk) ............................................... 21 <TM> Request team.......................... 21, 36 Creating................................................... 41

TMS Called by Rev-Trac.................................. 99 Sent indicators not added when using..... 69

Use after Rev-Trac has been installed.....62 tp

Called by Rev-Trac ..................................99 Import all not used in Rev-Trac................99 Sent indicators not added when using .....69 Use after Rev-Trac has been installed.....62

Transport creation rules Reviewing after moving master.............. 179

Transport data file Bypassing existence check for OOPS ...113

Transport directory Migrations to systems with separate

transport directory ..............................66 Transport instructions ..... See Special migration

instructions Transport lists

Creating via migration reports................ 105 Creating via Rev-Trac Migration Workbench

...........................................................95 Populating Migration Workbench from.....94 Suppressing foreign overwrite messages

via ....................................................121 Transport movement history

Database ...............................................110 Loading.................................................. 111 Required for OOPS........................ 111, 118

Transport quarantining Benefits.................................................. 120 Defined .................................................. 120 Quarantined transports report................ 104 Restoring files from quarantine ................97 Suppresses OOPS overtake warnings ..120 Via operating system ............................. 120 Via Rev-Trac utility........................... 97, 121

Transport, demonstration Creating ...................................................10

Transports Creating when master unavailable......... 183 Demonstration, creating...........................10 Logical transport objects ........................ 126 Migrating ........See Migration, Automigration Preventing addition to Rev-Trac request .51 Preventing deletion from Rev-Trac request

......................................................... 139 Releasing

RFC destinations for..................................... 56 Via Rev-Trac utility ....................................... 98

Remigrating .............................................69 Sequence on Rev-Trac request .............See

Request transport sequence Uploading and downloading from PC ......98

Trigger .................... See /RSC/TRIGGER event TX Del setting...................................... 139, 140 Umodes ............................... See Target groups Unavailable systems

Master....................................................183 Migration destinations, providing for ........67

URL Using as reference............... See Reference

User exits ...........................See Customer exits Users

AdminAuth setting....................................21 Configuring ..............................................21 Creating ...................................................40

Page 200 Index


Ref user setting ....................................... 40 RSCADMIN special user ................... 3, 177 RSCBATCH........................................... 177 RSCLEARNER.......................................... 4 RSCREMOTE ................................... 56, 61 RSCREMOTED................... 57, 59, 60, 177 UserType setting ..................................... 21

UserType setting...............................See Users WF Msg setting ........................... See Workflow

Workbench objects Locking without locking SAP configuration

......................................................... 134 Workflow

Migration failure ........................... 73, 91, 99 Prompt for approval, configuring..............36 Sent from master ................................... 173 WF Msg setting........................................36

xPack add-on to Rev-Trac.............................40

Index 201

Rev-Trac_5_0_Administrator_Guide2

Documents