Revelation Software Concepts: SAP Change Management Software

Managing the migration of multiple projects or project releases

This Rev-Trac Tip featured in RSC’s SAP Change Control eNewsletter discusses how most organisations handle change that can be categorised as either Business As Usual (BAU) or Project change. Of these organisations, the majority will in fact handle multiple projects or multiple project releases at the same time. This article touches on techniques for ensuring safe handling of the go-live (migration to production) of multiple projects or multiple releases of a single project.

Read Rev-Trac Tip

Managing Approved Change Migrations

This Rev-Trac Tip featured in RSC’s SAP Change Control eNewsletter discusses some of the deeper technical decisions required around when to deploy technical changes, their timing and surrounding controls to meet ITIL change request requirements.

Read Rev-Trac Tip

Initiating an ITIL compliant change request

This Rev-Trac Tip featured in RSC’s SAP Change Control eNewsletter provides guidelines and considerations for the implementation and initiation of an ITIL compliant change management process using Rev-Trac.

Read Rev-Trac Tip

How can I automatically record my Rev-Trac configuration changes to a transport?

If you have the requirement to record your Rev-Trac configuration changes to a transport, then this is the Tip to read! There are two components to enable this feature:

1. On the Rev-Trac Master instance use transaction SE04 - client settings, then modify the Rev-Trac client where all configuration is maintained. The setting must be enabled for changes and captured in a transport.
2. Next, on the Rev-Trac Master instance from the Rev-Trac console, go to the Global parameters (Configuration - Global - Advanced) and add the following parameter:
• AUTORECORD_RSC_VIEW_CHANGES
• Sub-parameter 1: (leave blank)
• Sub-parameter 2: VIEW = *
  You can specify a Rev-Trac view name, but only that view name would be captured to a transport when the contents were updated
• Value = ON

Note: Changes to system parameters and number ranges are never saved to a transport.

For more information about this feature, refer to the Rev-Trac Administrator guide available for download from the support area.

Re-queuing transports

If a transport migration fails into a target system following an approval, In-status approvers can re-send only the failed transport to the Rev-Trac migration queue by selecting Request > Re-queue transports.

This feature is particularly handy for users who have received a workflow prompt from Rev-Trac asking them to investigate the cause of a migration failure and who, after doing so, would like to simply re-migrate the failed transport without resetting the request status and then reapproving the migration status.

For more information about this feature, refer to the section "Re-queuing transports" in the Rev-Trac Administrator guide available for download from the support area.

Rev-Trac’s background and foreground migration methods - a brief review

There are two migration methods available in Rev-Trac: Background and foreground. They perform the migration in two steps.

In the first step, users send transports to the Rev-Trac migration queue usually via an approval step on a Rev-Trac request. In the second step, Rev-Trac's batch (background) migration utility migrate items in the queue to their destinations. This utility usually runs in the background.

Rev-Trac's non-queued (foreground) method migrate transports immediately using a foreground (dialog) process. This method of migrating transports is less flexible than queued migration and is not recommended.

Following is a summary of the differences between the two methods:

As mentioned above, the recommended migration method is background as the logs produced by this method make problem determination and resolution easier to diagnose.

For more detail on this topic, see the section "Migration" in the current version of the Rev-Trac Administrator guide available for download from the support area.

Alternatively, for advanced usage recommendations, please feel free to contact the Rev-Trac support team at support@xrsc.com.

Collateral (documentation) enforcement - What types of documents and fields can be enforced prior to status approval?

Rev-Trac administrators can configure request completion rules that enforce the following conditions be met before a request of a particular type and project is approved into a set status:

• A defined Rev-Trac request fields must be completed
• A defined attachment type must be added
• A defined reference type must be added

This makes it possible to configure rules such as the following for a request of a selected project and request 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

These rules can cause a user to experience an "information only" message or an enforced requirement.

For more detail on this topic, see the section "Request completion rules" in the current version of the Rev-Trac Administrator guide available for download from the support area.

Alternatively, for advanced usage recommendations, please feel free to contact the Rev-Trac support team at support@xrsc.com.

Receive an email notification when an approval status has been reached in a specific workflow

Rev-Trac workflow includes the ability to send email notifications upon reaching a status approval, called ‘FYI notification’.

The configuration for the FYI notification is found in the strategy configuration menu path (Configuration – Process – Strategies).

Select the Strategies folder, click on the strategy name, then click on the Status path folder. In the view of the status list, the folder ‘FYI message recipients’, you may configure a single team and position or multiple teams and positions to receive the notification.

Also, there is an FYI Message flag : 5 = Send an FYI msg to this position (to inform status reached); 6 = Send an FYI msg to this position and standins.

By using this feature, the teams are informed via email that a status has been reached, improving communications and avoiding delays!

For more detail on this topic, see the Rev-Trac Administrator guide available for download from the support area.

Alternatively, for advanced usage recommendations, please feel free to contact the Rev-Trac support team at support@xrsc.com.

Deleted Requests - How can I bring them back into existence again?

When a user selects the menu path Request > Delete Request, while in the workbench view of the request, the status of the request will be set to deleted (DELT). By default, it cannot be modified or reversed.

This may be an issue if the request should be required to migrate transports or progress in its lifecycle. Any attempt to change the status of the request will often result in an error message advising that ‘Request has status “Deleted” (DELT), no changes allowed’.

If your organization would prefer that a user is able to get around this error message and change the status of the Rev-Trac request, this can be achieved by adding a status of “DELT” with a valid approver to the strategy affecting the request.

NOTE: “DELT” should be defined after the status of “COMP”

Once DELT has been defined as a status within the strategy, you will be able to manually change the status of the deleted Rev-Trac request.

For more detail on this topic, see the Rev-Trac Administrator guide available for download from the support area.

Alternatively, for advanced usage recommendations, please feel free to contact the Rev-Trac support team at support@xrsc.com.

Send transports in a request to multiple systems / clients with a single approval

Each target group can handle multiple target systems. A separate entry should be added to the migration target group for each destination system/client. An additional entry should be included to handle the migration of client independent transports to each system. The menu path for the target group setting is: Configuration > Process > Migration.

With a correctly configured target group, a single approval can therefore trigger the migration of transports to multiple destinations.

Once the target group has been created, you can assign the target group to the approval status using the Assign Process configuration. The menu path is: Configuration > Process > Assign Process.

NOTE: The same target group can be assigned to many migration statuses on different strategies.

For more detail on this topic, see the section ‘Migration’ > ‘Target Groups’ in the current version of the Rev-Trac Administrator guide available for download from the support area.

Alternatively, for advanced usage recommendations, please feel free to contact the Rev-Trac support team at support@xrsc.com.

Controlled Migration Sequencing

Often a complicated SAP environment requires the use of advanced transport migration sequencing. Rev-Trac has two mechanisms to help control the sequence in which transports are migrated.

The first is the use of “Dependency Checking Smart References” (DCSR). The effect of the DCSR is that a defined status will not be able to be signed until a referenced request has met its defined status.

For some purposes, this can be a very effective way of managing the sequence of transport migrations within or across landscapes.

In the later releases of Rev-Trac (RT5 SPS17+) the DCSR can be configured via
Rev-Trac menu path:
Configuration - Process - Advanced - Request Dependency Rules

In earlier versions of Rev-Trac, the DCSR rules can be activated via override.

The second function is an individual transport sequence feature which is enforced at the time of migration. This mechanism is known as ‘Transport Dependencies’. The transport dependency is easily assigned to a transport from the Rev-Trac workbench, and will be honored when the transports are migrated.

Combining transport dependencies with DCSR’s, it is possible to achieve a highly complex scenario of dependencies across your various SAP landscapes. For example, the above mentioned facilities are a perfect way to manage R/3 and BW transports while ensuring that the R/3 transports are migrated before the BW cube transports.

For more information about Dependency Checking Smart References or Transport Dependencies, please consult the Rev-Trac Administrator Guide. Alternatively, for advanced usage recommendations, please feel free to contact the Rev-Trac support team at support@xrsc.com.

GlobalView Statistics

It is often quite difficult to understand the real life value a technology brings once implemented. Often during the procurement process an ROI is promised, or estimated or perhaps even made up, but with Rev-Trac’s GlobalView online support tool this can be very easily calculated post implementation.

The GlobalView Statistics report, available to Rev-Trac customers through GlobalView access, provides a deep understanding of the how Rev-Trac is used and what level of previous manual activity has been automated, making accurate ROI calculations possible.

With statistical reports covering things like the following, simple calculations can be carried out against the information to quickly, and accurately, determine the value Rev-Trac has provided.

Some of the statistical reports provided include:

• Total number of Rev-Trac requests
• Total number of approved statuses
• Total number of transports managed by Rev-Trac
• Total number of migrations to a target destination performed by Rev-Trac
• Total number of references associated with Rev-Trac requests
• Total number of attachments associated with Rev-Trac requests
• Total number of locking messages delivered to end users
• Total number of OOPS report errors / warnings delivered to end users

Many of these reports can be manipulated to display data using variables or ranges.

For those with access, GlobalView can be accessed by logging into the support area and following the links.

For further information, or to request access to GlobalView, please contact the
Rev-Trac support team at support@xrsc.com.

Informing multiple users or groups of an approval

Quite often our customers will ask how to inform a group of users of a particular status being reached.

This can easily be done by creating a distribution group on the organisations email server, and adding this mail group to a “fake user” in the Rev-Trac configuration.

Configuration > Process > Organisations -> Users

If this “fake user” were to be added as an FYI recipient to the status in question, the entire distribution group would be notified upon approval of the status.

Configuration > Process > Strategies -> Strategies -> Status Path -> FYI Message recipients

NOTE:
Unlike an approver, the user name in the Rev-Trac Organisation user list for an FYI recipient, does not require a corresponding SAP logon to receive the FYI emails. This makes it possible for non SAP users to receive an FYI message as explained above.

For any further information about the Rev-Trac workflow emails, please consult the
Rev-Trac Administrator Guide, available for download from the support area.

Controlling and delaying queued migrations using a hold mode

It is possible to place an indefinite "hold until" date for all transports sent to the Rev-Trac migration queue for a particular destination. This can be configured in the target destination via Rev-Trac menu path:
Configuration > Process > Migration

Setting an indefinite "hold until" date (Hold Mode = 9) for a destination allows items to be sent to the Rev-Trac migration queue for this destination, but not migrated until an authorised user has removed or changed the "hold until" date.

To remove or alter a "hold until" date, follow these steps:

1. Display the Rev-Trac migration queue in change mode via Rev-Trac menu path: Migration > Migration Queue > Manage / view queue
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

NOTE: Completing this field has no effect when using non-queued migration, and does not delay migration in this case.

For any further information and advice, please consult the Rev-Trac Administrator Guide, available for download from the support area.

Plan vs Reality Report

The plan vs reality report identifies discrepancies between the destinations that transports should have reached and where these transports are actually present.

The report is created in accordance with the current status of a Rev-Trac request and the associated transports and their target destinations determined by the migration strategy.

Rev-Trac itself runs this report in the background every time a human approver signs a request into a post-migration status where an approver has been configured (such as "In QAS" or "In PRD"). If the report determines that the required transports do not exist in their target destination, Rev-Trac will notify the user.

A responsible user will correct any discrepancies before approving the post migration status.

For any further information and advice, please consult the Rev-Trac Administrator Guide, available for download from the support area.

Rev-Trac and HP Quality Center

Available as one of the Rev-Trac Add-on Suite products, the Rev-Trac Quality Center Synchronizer Adapter enables bi directional information exchange between Rev-Trac and Quality Center via the Quality Center Synchronizer to enhance standard Rev-Trac SAP change management processes.

For any further information or advice about the Rev-Trac QC synchronizer, please feel free to contact the Rev-Trac support desk at support@xrsc.com or download the datasheet

Rev-Trac Landscape Snapshots

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

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

The “set” can be defined at a target group level via Rev-Trac menu path:
Configuration > Process > Migration

For any further information or advice about target groups, please consult the Rev-Trac Administrator Guide, available for download from the support area.

Using a target group “set” to assist with the replacement of a target group

Every 24 hours, a Rev-Trac background job saves information about which transports are present in which systems and clients, throughout all landscapes under Rev-Trac control.

The job that performs this task is /RSC/LANDSCAPE_SNAPSHOT.

Several Rev-Trac migration reports can be run against landscape snapshot data. Also, 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.

Landscape snapshots can be very useful when performing comparative tasks, where a retrospective landscape snapshot can be queried against the live environment.

For example, if used in conjunction with the comparison report, it is possible to determine which transports were in a deleted system but are not currently in a live system.

Many other migration reports will have a ‘Landscape snapshot ID’ field for querying retrospective data instead of live data.

For further information and advice about the Rev-Trac landscape snapshots or migration reports, please consult the Rev-Trac Administrator Guide, available for download from the support area.

Advice for dealing with a planned outage of a Rev-Trac master system

From time to time, for whatever reason, a customer may require that the Rev-Trac master system is brought down perhaps for an upgrade or a system refresh.

For obvious reasons it is necessary to protect the current and historical Rev-Trac data which exists in the Rev-Trac master system, while continuing to track changes during the outage. Specific methods should be used to move the Rev-Trac master system (and data) to a safe location while the refresh/upgrade is underway.

A simplified outline of our recommended approach is to:

• Perform the steps to "Move a Rev-Trac master system" to another environment
• Perform the system refresh
• Reinstall the Rev-Trac software on the refreshed system (specifically including the Rev-Trac field exit and BADI)
• Perform the steps to "Move a Rev-Trac master system" back to the development environment

Although the above steps are not overly detailed, Rev-Trac administrators should understand that there are specific guidelines for performing such tasks, most of which are documented in the Rev-Trac Administrator Guide available from the support area.

For any further information or advice about performing such tasks, please contact the Rev-Trac support team at support@xrsc.com.

GlobalView – Process Viewer

Often Rev-Trac customers have difficulties grasping the interactions and relevance of different areas of Rev-Trac configuration.

With the use of the GlobalView process viewer, it is possible for customers to verify changes to configuration and ensure that their processes have been modified as expected. The Interactive Process Viewer also makes Rev-Trac configuration easy to browse and understand.

For those with access, GlobalView can be accessed by logging into the support area and following the links.

For further information, or to request access to GlobalView, please contact the
Rev-Trac support team at support@xrsc.com.

Approval Authorisation Checks

Different organizations have different approval policies and various SOPs which may require that particular authorization checks are performed when a Rev-Trac request status is approved.

Rev-Trac's standard approval approach requires the selected approver to type in their SAP password in order to approve a request status (the logged on SAP user is not considered in this scenario).

In order to cater for various levels of authorization checks, Rev-Trac has two other options for signing Rev-Trac requests.

For convenience and ease of use, we offer the One-click Approval approach:
If the approver is the logged on SAP user, no password is required. The user only has to hit the "Approve" or "Reject" button. Otherwise, Rev-Trac falls back to the standard approval approach.

For organizations with strict approval policies we offer the Two-component Approval approach:
The approver must enter the SAP user ID and corresponding password in order to sign a request status (the logged on SAP user is not considered in this scenario).

In order to implement either of the above two options, the appropriate over-ride will need to be configured as follows:

For further information about approval authorization checks, please consult the Rev-Trac Administrator Guide. The latest version of the Guide can be downloaded from the support area.

Can Rev-Trac be used as a change management tool for the general IT industry (and systems)?

With the use of RT-xDeploy, Rev-Trac customers are able to apply their Rev-Trac infrastructure to processes that cater for the deployment of non-ABAP changes.

RT-xDeploy users can:

• Associate Java and other non-ABAP software packages and CTS transports with a Rev-Trac change request, and automatically deploy them in the correct sequence to any combination of destinations, following approvals
• Specify and enforce sequence dependencies between non-ABAP Java packages, or between these and CTS transports
• Track and manage the deployment of multiple versions of non-ABAP Java packages
• Specify, enforce and report on migration and deployment sequence dependencies between non-ABAP Java package transports, or between ABAP and non-ABAP Java package transports
• Display a range of deployment reports, including matrix-like views that represent visually what destinations each non-ABAP Java package has reached
• See the component list of each Java package
• Configure deployment methods for non-ABAP Java packages
• Choose to use with or without CTS+
• Deploy other types of non-ABAP packages

Effectively, your ABAP and non-ABAP changes can be managed by the same system and if necessary even the same Rev-Trac request (this is a major benefit when dealing with changes affecting multiple environments/system types).

For further information about Rev-Trac or xDeploy, please feel free to contact the support team at support@xrsc.com.

Sensitive Objects

Some objects require particularly careful approval or migration treatment. "sensitive" in Rev-Trac, and for each such object ensure that it is managed using a particular type of request.

By defining an appropriate strategy for this Rev-Trac request type, you can ensure that changes to this object are approved and transported using a suitably customised process.

The granularity of the sensitive objects is determined by a combination of the following:
Program ID > Object > Object Name
Each entry can be assigned to a different request type if required.

For further information about sensitive objects, please consult the Rev-Trac Administrator Guide under heading: Defining objects that require sensitive approval or migration treatment. The latest version of the Guide can be downloaded from the support area.

GlobalView – What are the Health Check errors and warnings, and how can I remove these?

When a system diagnostic report is loaded into GlobalView, some key statistical and configuration information is analysed for the reports. The Health Check displayed on the GlobalView dashboard shows the number of registered errors and warnings contained within the system diagnostic report, which represents recognisable configuration errors and known system/software issues within your Rev-Trac environment/s.

By selecting the Health Check icon, a list of the errors and warnings will be displayed with a short description.
By double clicking an error/warning message, a list of issues causing the error/warning is displayed.
By selecting the issue, a detailed solution message is displayed which will instruct you how to repair the issue.

Health Check > Error/Warning > Issue > SOLUTION

When using GlobalView it is possible for (and we encourage) our customers to attempt to self-diagnose and fix problems/errors occurring within their Rev-Trac environment/s using this mechanism. Most of our customers currently have less than 3 errors or warnings. It is best to ensure that there are as few as possible.

For further information on Rev-Trac GlobalView or to request access for your organisation, please contact our support team at support@xrsc.com.

Is it possible to approve a Rev-Trac request via Blackberry?

If setup correctly, it is possible to perform approvals via Blackberry, however would require utilisation of the email approval option in the Rev-Trac xPack add-on.

Setup requirements

The Rev-Trac web application and xPack add-on are required to be installed and associated with the Rev-Trac master system.

Also if the user was on the road they would either require VPN access to an organisation's network or a port would need to be opened to the Rev-Trac web application, in order for the web approval to work.

There are a few limitations implemented mainly for security purposes, which prevent a remote user from approving Migration or Post migration statuses.

For further information on Rev-Trac add-on functionality, please see the add-ons section of our website or contact our support team at support@xrsc.com.

Unavailable system rules

Inevitably, SAP systems sometimes become unavailable or inactive, due to maintenance or upgrades, or something less planned. When this occurs, migration to the system obviously cannot occur, however you may wish to continue adding transports for migration to the system to the Rev-Trac migration queue. Normally this would not be possible, but available from Support Package Stack 17, the Rev-Trac "Unavailable system rules" feature provides a solution.

Unavailable system rules determine what behaviour Rev-Trac should observe when attempting to add a transport to the Rev-Trac migration queue at a time when a system is not currently available, either as a result of the system being flagged "Not active" in the Rev-Trac system configuration, or if Rev-Trac is unable to communicate with the system when a function requires Rev-Trac to do so.

When creating a rule, there are four options for how Rev-Trac should behave:

• 01 - Disallow add to queue if system unreachable or set to inactive;
• 02 - Allow add to queue if system set to inactive;
• 03 - Allow add to queue if system unreachable; or
• 04 - Allow add to queue if system unreachable or set to inactive.

For further information on unavailable system rules, please consult the Rev-Trac Administrator Guide. The latest copy of the guide can be downloaded from the support area.

How can I manage non-ABAP change with Rev-Trac?

There are two options for managing non-ABAP (e.g. Java) changes with Rev-Trac: SAP CTS+ and the Rev-Trac xDeploy add-on.

SAP CTS+ allows you to migrate SAP-based non-ABAP changes inside your regular workbench transports. As Rev-Trac utilises CTS/TMS for migration, there is little Rev-Trac configuration required to take advantage of CTS+, once your SAP systems are configured. However, CTS+ will only handle SAP-based non-ABAP changes that are supported by CTSDEPLOY/SDM, and there is little flexibility when it comes to package management and sequencing.

Rev-Trac xDeploy allows you to handle any non-ABAP changes, whether they reside within the SAP solutions environment or not, with packages managed as individual entities attached to a Rev-Trac request. This provides full change logging, as well as support for flexible sequencing. Normal transports can be managed on the same Rev-Trac request, and dependencies can be configured between all of the components to ensure that dependent multi-stack changes are migrated and deployed in the correct sequence every time. Finally, while xDeploy provides out-of-the-box support for many common deployment scenarios, including SAP package deployment via CTSDEPLOY/SDM, its extensible architecture allows new deployment actions to be defined quickly and easily with an appropriate script, giving xDeploy the ability to deploy change to any third-party system.

For further information about managing non-ABAP change with Rev-Trac, please read our whitepaper "Rev-Trac and SAP CTS+: Extending Transport Management to the SAP Java Environment" or download the Rev-Trac xDeploy add-on data sheet.

How will the application of an SAP support pack affect my installation of Rev-Trac?

As Rev-Trac resides within its own SAP namespace (/RSC/), Rev-Trac software and data will not be affected by the import of a SAP support pack.

However, by ensuring that your Rev-Trac installation is always on the latest Rev-Trac Support Package Stack your installation will be in the best possible state regarding support if any problem does arise.

Please note: before applying a SAP support pack in any of your development systems, it is also a good idea to deactivate the Rev-Trac field exits and BADI in these systems.

The following information is available from the Rev-Trac console menu:
Administration -> Read Me Before SAP upgrade

Before performing an SAP upgrade in a development system, be sure to deactivate the Rev-Trac field exits and BADI.

If you fail to do so, you may be unable to create transports required during the SAP upgrade.

To deactivate the Rev-Trac field exits, run program RSMODPRF and deactivate field exits for data elements TRKORR and TRORDERTXT.

Deactivate the Rev-Trac BADI using transaction SE19. Depending on your installation, your Rev-Trac BADI is named either Z_RSC_EP_TX_BADI or /RSC/DEV_EP_PLUS_TX.

After completing your SAP upgrade, reactivate the Rev-Trac field exits and BADI.

If you need any help with these steps, contact support@xrsc.com. If you plan on applying a SAP support pack to the Rev-Trac master system, you will need to take some special precautions to allow for development to continue in other slave systems. For further information, please consult the Rev-Trac Administrator Guide from the support area under heading:
Preparing for a planned outage of the Rev-Trac master system.

Delegating Approvals

It is possible for a Rev-Trac user to delegate his/her approval authority to another Rev-Trac user. This is in many cases useful when a key approval user is unexpectedly absent or on scheduled leave.

The delegates can be assigned via Rev-Trac menu path:
Request Management > Delegate Approvers

The delegated approver can be assigned for a period of time defined by the 'From Date' and 'To Date'.

The authorisation associated with delegates can be controlled at various levels including:

GLOBAL PARAMETERS
    - No Delegates allowed
    - Assign own delegates
    - Assign own delegates & others via authorisation

USER AUTHORISATION
    - Y/RSC/CE06 (Delegation)

This authorisation may be used to control the scope within which a user may delegate others to approve Rev-Trac requests on behalf of third-parties. It can be assigned to the user’s SAP authorisation profile.

For further information on delegate approvers, please consult the Rev-Trac Administrator Guide. The latest copy of the guide can be downloaded from the support area.

I've heard about Rev-Trac's key level locking - How can I activate key level locking in my Rev-Trac installation?

The risks associated with overtaking and overwriting 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.

By default, the Rev-Trac locking system checks and enforces locks only at a table level not at a table key level.

From support package stack 18 onward, Rev-Trac includes a facility to have the Rev-Trac locking process enabled for table objects at the key level. This feature is available for SAP systems running SAP Basis 4.6C or greater.

Revelation Software Concepts has developed a simple procedure to implement and activate the use of key level locking. The procedure requires the import of a single transport along with a few activation steps to any Rev-Trac installation of SPS18+.

The latest support package stack can be downloaded from the support area.

Please contact the Rev-Trac support desk in order to obtain the transport and documentation required to implement key level locking, also from the support area.

Managing the sequence of dependant transport migrations

Rev-Trac has two optional mechanisms to help control the sequence in which these related transports are migrated.

The first is “Dependency Checking Smart References” (DCSR) which is activated through an over-ride by referencing one Rev-Trac request from another.
The effect of DCSR is that Rev-Trac will not allow a defined status to be signed until a defined status of the referenced request has been signed. For some purposes, this can be a very effective way of determining when items can be added to the migrations queue.

However, for some customers, the DCSR is not enough as this is only managed at a request level and will not be considered when migrating transports.

For a more accurate sequencing of transports which is also honored at the time of transport migration, Rev-Trac has a feature known as ‘Transport Dependencies’.

This is a perfect means to, for example, manage R/3 and BW transports while ensuring that the R/3 transports are migrated before the BW cube transports.
The transport dependency is easily assigned to a transport from the Rev-Trac workbench, and will be honored when the transports are migrated.

For further information on transport dependencies or dependency checking smart references, please consult the Rev-Trac Administrator Guide. The latest copy of the guide can be downloaded from the support area.

How does Rev-Trac determine the dynamic sequence?

The recommended and most common way our customers perform migrations is using the “Frozen sequence then dynamic” option on the migration variant.

The frozen sequence is used to manually sequence transports, and will be given priority if there are transports in the queue that have been frozen.

The dynamic sequence however does warrant some explanation. The steps taken by Rev-Trac in order to determine the dynamic sequence are as follows:

1.       1. Sequence transports in order of release;
2.       2. Adjust sequence to honor the Rev-Trac request order; then
3.       3. Adjust sequence to honor transport dependencies

This is a very powerful method of determining sequences, as it firstly minimizes the risk of an overtake or overwrite by sequencing in release order.The second adjustment will reorder the queue items to honor the order in which they appear on their respective Rev-Trac requests, in relation to other queue items that are also attached to the same request.The third adjustment ensures that the migration queue sequence will honor any dependencies between queue items.

For further information on dynamic sequencing, please consult the Rev-Trac Administrator Guide, which can be downloaded from the support area.

Rev-Trac transport 'Sent Indicators'

A Rev-Trac sent indicator is a small tag added to a transport upon the approval of a migration status, which indicates to which target group the transport has been sent.

• The sent indicator will remain in synchronization with the transport’s current status in the migration queue and update accordingly
• When the transport has been sent to the queue the sent indicator will appear yellow (in queue)
• When the transport leaves the migration queue the sent indicator will change to Green (sent)

A transport that has a sent indicator will not be re-queued if the migration status is approved again. In this case a customer must specifically re-queue the transports, either manually or from the Rev-Trac workbench via menu path:
    Request > Re-queue transports

The tricky part is that the sent indicator will turn green (sent) if the transports are removed from the queue in any way (deletion, migration, etc.). As such, when a user is adding and removing transports from the migration queue, they will need to ensure that the sent indicators are updated accordingly.

To remove a sent indicator:
    From the Rev-Trac workbench – Menu path:
    Transports > Remove sent indicator

To add a sent indicator:
    From the Rev-Trac console – Menu path:
    Migration > Tools > Update sent indicators

For further information on sent indicators, see the Rev-Trac Administrator Guide available for download from the support area.

What is the difference between an OOPS 'overwrite' message and an OOPS 'overwrite foreign' message?

Rev-Trac's OOPS feature will trigger an overwrite message when you attempt to import a transport that will wipe out all or part of the contents of another, more recently released, transport that is already present in the system. If a transport is overwritten, the affected object is often not left in the intended state.

An 'overwrite foreign' however will only occur when you import a transport which will overwrite another transport that exists in the target system, but does not exist in the source (development) system.

Although cases vary from site to site, often the overwriting of a transport which does not exist in the development environment will need to occur to ensure that the change can be effective in the production system. For this very reason, there are several ways that OOPS 'overwrite foreign' messages can be bypassed (if found to be appropriate).

If you are experiencing OOPS 'overwrite foreign' messages, please feel free to contact the Rev-Trac support team, to discuss whether there is an appropriate solution.

For further information on OOPS messages, please consult the Rev-Trac Administrator Guide, which can be downloaded from the support area.

How do I add a system to a target group?

In most cases our customers use a target group to direct transport migrations, and scheduled background migration jobs to perform the migrations to each system.

When a target group is modified by adding a system or client, it is necessary to make sure a background migration job has been scheduled with a variant to migrate transports targeted for the new destination. It is common for customers to forget this second step.

For further information on scheduling background migration jobs and target groups, please consult the Rev-Trac Administrator Guide, which can be downloaded from the support area.

Transport Lists

Transport lists are a very powerful way to perform standard Rev-Trac functions en masse. This includes:

• Running comparison reports with the ability to exclude a specified list of transports
• Updating Sent indicators en masse
• Quarantining and un-quarantining transports en masse
• Releasing transports en masse
• Manually add many transports to the migration queue
• And more...

There are also several ways that a transport list can be created, varying in practicality, generally dependant on the intended use of the transport list.

Some of the ways to create a transport include via:

• The Rev-Trac migration workbench
• The output of the Rev-Trac chronological report
• The output of the Rev-Trac comparison report
• And more...

Using each of the above listed methods, a transport list can be created by selecting menu path: List > Transport List

For more detail on this topic, see the Rev-Trac Administrator Guide available for download from the support area.

Control whether a Rev-Trac request field can be modified, viewed only or mandatory

It is possible to keep track of all Rev-Trac requests which have not changed status within a defined period of time via a standard Rev-Trac report ‘WF pending action’.

• A normal input field
• A mandatory input field
• A suppressed field (i.e. not displayed at all)
• A display only field

The field attribute can be modified via Rev-Trac menu path:

• Configuration > Process > Request Screen > Field Attributes

The value in the ‘Attr’ field of configuration will control how the request field is used.

For more detail on this topic, see the section “Setting custom attributes for specific Rev-Trac request fields” in the current version of the Rev-Trac Administrator guide available for download from the support area.

How can I keep track of requests which are not progressing?

The attribute of each field on a Rev-Trac request can be changed via standard Rev-Trac configuration to be either:

The report can be accessed via Rev-Trac menu path:
Request Management > Tools > WF pending action

The report can be filtered by Project, Request Type, Class, Severity, Current Status, Next Status and Hrs since last status change.

Further to this, the report can trigger workflow email to be resent to the approvers, prompting for a status approval.

For further information on Rev-Trac's reporting capabilities, please consult the Rev-Trac Administrator Guide available for download from the support area.

Require multiple approvals on a single status

It is possible to configure multiple approvals on a single status via standard Rev-Trac configuration.

This can be performed at a status approver assignment level:

Configuration > Process > Strategies
Strategies -> Status Path -> Approver & WF message recipients

The controlling factor is the value of ‘App Type’ on an AND/OR basis.

To allow an OR scenario, enter all approvers with the same ‘App Type’.

To allow an AND scenario (requiring multiple approvals), enter each or multiple approvers with different ‘App Type’.

When multiple approval types have been assigned to a single status, the Rev-Trac request will show multiple approval nodes, displayed by approval type.

When selecting an approval node of a particular approval type, Rev-Trac will generate the list of approvers based on only the entries with the correct 'App type' in the 'Approvers & WF message recipients' configuration for the strategy/status.

For more detail on this topic, see Tutorial 2 in the current version of the Rev-Trac Administrator guide available for download from the support area.

How do I suppress OOPS overtake alerts messages occurring for a transport I do not intend to migrate?

It is common for changes to be abandoned without being migrated to production. Often these abandoned transports can trigger OOPS overtake errors as new changes effecting the same objects are migrated into production.

It is possible to prevent the OOPS overtake alerts from being displayed by quarantining the transport.

The Rev-Trac quarantining facility can be accessed via Rev-Trac menu path:

Migration > Tools > Quarantine Transports

Effectively the facility removes the data file from the transport data directory, which allows Rev-Trac to suppress the related OOPS overtake alert.

For further information, see the heading ‘Transport Management -> Quarantining Transports’ in the current version of the Rev-Trac Administrator guide available for download from the support area.

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 (e.g. production support) are tracked as candidates for subsequent application to another project (e.g. system upgrade or a separate project landscape).

Request cloning can be initiated in Rev-Trac in one of two ways:

• Implement a Rev-Trac customer exit that is called every time a request's status is changed.
• As of SPS17, it is now possible to implement the Rev-Trac cloning function using a configuration dialog. Using the “Request cloning rules” configuration dialog, it is possible to instruct Rev-Trac to create a clone of a Rev-Trac request assigned to a specific Project/Request type combination at an appropriate point in the request’s lifecycle.

For more detail on this topic, see the section ‘Setting up request cloning’ in the current version of the Rev-Trac Administrator guide available for download from the
support area.

Migrate to multiple destinations on single approval

Rev-Trac determines the migration destination by the target group assigned to a migration status within a Project/Request type.

Configuration > Process > Assign Process

• Process Assignment
• Assignments per project/request type
• Migration method and target

The same target group can be assigned to many migration statuses on different strategies.

It is possible to define more than one destination system within a single target group.

Configuration >Process > Migration

• Target Groups

With a correctly configured target group, a single approval can therefore trigger the migration of transports to multiple destinations.

For more detail on this topic, see the section ‘Migration’ > ‘Target Groups’ in the current version of the Rev-Trac Administrator guide available for download from the support area.

How to change the status of a request from complete back to operational

The status of COMP (complete) is a hardcoded status, automatically approved once the last customer defined status within a strategy has been approved.

It is quite common for a Rev-Trac Administrator to define a strategy that does not include COMP as a status. If so, when a user attempts to manually change the status of the request while in a status of COMP, an error message is given:

Request has status “Complete” (COMP), no changes allowed

In order to allow the status of a request to be changed while in a status of COMP, the strategy will need to be configured to include the status COMP as the final status in the strategy.

Once the status of COMP has been defined in the strategy, the status will take on the normal hardcoded behaviour as well as the ability to manually change a request in and out of the status of COMP.

Day to day admin

Since the release of Rev-Trac Support Package Stack 15 (SPS15) the Rev-Trac Administrator Guide has been modified to include a new section: Day to day admin.

This section of the guide is intended to assist a Rev-Trac administrator in keeping a tidy and smooth running system. It includes information on the following:

• Rev-Trac License Key Management
  • Requesting a license key
  • Loading a license key
  • Checking a license key
• The Rev-Trac health check report
  • Running the report
  • Reviewing the report output
• Running the Rev-Trac diagnostic utility
• Saving a copy of your current Rev-Trac configuration
• Archiving obsolete migration queue entries

A Rev-Trac administrator should familiarise themselves with the content of this section in the guide. It is worth ensuring that some of the procedures found under day to day admin are carried out on a regular basis.

The latest copy of the Rev-Trac Administrator guide is available for download from the support area.

Backing up your Rev-Trac configuration prior to making changes

Are you concerned that when you make a change to the Rev-Trac configuration you may inadvertently corrupt the current configuration and not be able to recover back to a state prior to making the current change?

Prior to making any change you can backup your entire Rev-Trac configuration to a tab delimited text file by selecting:

• Configuration > Tools > Download / upload configuration
• Accept all defaults and save the output file in case of emergency

If you should need to restore the configuration from this download file you can do so by selecting:

• Configuration > Tools > Download / upload configuration
• Action: Upload configuration (Presentation server)
• Upload Configuration Option:
• Delete Existing and Add New Configuration Table entries

Please be aware that if you restore the settings from the backup file, all of your current settings will be overwritten with the settings stored in the downloaded file.

Downloading your configuration prior to making major configuration changes is a good habit to get into.

Is it possible to customise the Rev-Trac request details screen?

It is possible to customise the request details screen in various ways. For example:

• You can add custom Rev-Trac request fields to the request details screen and, if desired, display these fields on their own tabs
• You can control the behaviour of, and access to, individual fields on the request details screen, including custom Rev-Trac request fields

For more detail on this topic, see the section "Customising Rev-Trac screens" in the current version of the Rev-Trac Administrator guide available for download from the support area.

Do you want to force a user to add collateral to a Rev-Trac request prior to signing a status?

Rev-Trac administrators can configure rules that prescribe the following before a request of a particular type and project reaches a particular status:

• Which Rev-Trac request fields must be completed
• Which types of attachments must be added
• Which types of references must be added

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

For more detail on this topic, see the section "Request completion rules" in the current version of the Rev-Trac Administrator guide available for download from the
support area.

Is it possible to create a template for use when attaching a document to a Rev-Trac request?

Users may design and load into Rev-Trac their own attachment templates which can be used when attaching a document to a Rev-Trac request.

You could for instance load an attachment template to be used for such things as:

• Functional specifications
• Test results

Use the following menu path to load an attachment template:

• Configuration > Tools > Load template

When creating an attachment select the "Template" radio button on the Create attachment dialog.

It is also possible to enforce rules related to a particular attachment type by configuring a suitable "Request completion rule".

For more detail on this topic, see the section "Request completion rules" in the current version of the Rev-Trac Administrator guide available for download from the
support area.

Do you want to display the current location, System/Client of every transport currently attached to a Rev-Trac request?

When you display a Rev-Trac request on the Rev-Trac Workbench, you can instantly display the current location of every transport attached to the request by selecting the menu option:

• Transport > Show propagation or by selecting the Propagation icon on the toolbar.

It is also possible to run the same report for a range of transports or Rev-Trac requests from the Rev-Trac console menu option:

• Migration > Reports > Propagation.

Sending transports to PRD in the same order they went to QAS

Rev-Trac can sequence the background migration of changes to another system using several different algorithms.

If you are satisfied that the import sequence of transports used to build QAS has been ultimately successful, then a good option to consider when migrating the same transports to PRD is the "Previous import sequence... to..." option on the Rev-Trac batch migration utility. By using this option, you could ensure, for example, that transports are migrated to PRD client 400 in the same order they were migrated to QAS 300.

If a transport was imported multiple times into the previous import system, then Rev-Trac would use the final import when sequencing transports.

Requeuing failed transports

If a migration failed following an approval, eligible users can re-send the failed transport to the Rev-Trac migration queue by selecting Request > Re-queue transports.

This feature is particularly handy for users who have received a workflow prompt from Rev-Trac asking them to investigate the cause of a migration failure and who, after doing so, would like to re-migrate the failed transport without formally reapproving the migration.

Backing up your Rev-Trac data and configuration

This could never happen to you - though it did happen to one of our customers. Lost their entire Rev-Trac master system because of database corruption problems.

Actually, it turned out the Rev-Trac tables were not corrupted, so the customer was able to restore Rev-Trac data into a new system - but it was a narrow escape.

There is an easier way. You can backup all your Rev-Trac data (including attachments) plus your configuration to a transport by selecting Configuration > Tools > Backup data to transport. It's a good habit to get into (and don't forget to release the transport).

Who changed that Rev-Trac change request?

Not sure who changed that Rev-Trac change request, or when? Just display the request on the Rev-Trac Workbench, then select Extras > Show change log (5.0) or Extras > Display changes (4.2).