Revelation Software Concepts: SAP Change Management Software

Informing multiple users or groups of an approval

29 July 2010

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 WF emails, please consult the
Rev-Trac Administrator Guide, available for download from the support area.

Controlling and delaying queued migrations using a hold mode

30 June 2010

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

31 May 2010

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

30 April 2010

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

23 March 2010

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

25 February 2010

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

21 January 2010

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.

Rev-Trac 6.0

26 November 2009

As of July 2009, all further offerings of the Rev-Trac 5.0 product will be rebadged under the name Rev-Trac 6.0.

In all other aspects they are the same product and should be treated as such when applying the latest Support Package Stack.

No conversion of any kind is required when applying Rev-Trac 6.0 SPS 01 or above to an existing Rev-Trac 5.0 installation.

The reason for Revelation Software Concepts choosing to re-badge the product is due to a new development process that complies with: US FDA Quality System Regulation (21CFR Parts 11, 210, 211 & 820).

For further information or to download Rev-Trac 6.0 SPS01, please login to the support area and follow the links.

GlobalView – Process Viewer

21 October 2009

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

24 September 2009

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)?

24 September 2009

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

19 August 2009

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?

19 August 2009

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.

Granular Authorisation - Rev-Trac Queue management

29 July 2009

The ability to access and manipulate the Rev-Trac Migration Queue is considered an expert function which should only be performed by an appropriately authorised member of an organisation.

As this is an expert facility Rev-Trac will limit the ability to edit the queue to users with specific administrative authority. In situations where a company may have strict guidelines regarding segregation of duties it is possible to allow access to this facility without allowing the user to have full administrative authorisation for other Rev-Trac functions.

Two different settings affect whether or not a user can modify the Rev-Trac Migration queue:

• The authorisations included in the SAP user master record; and
• The user's Rev-Trac 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.

SAP User Authorisation Profile

Add a profile based on the sample profile Y/RSC/ADM04 (Admin: Migration Queue) to the user's SAP user master record (adjusting the target group limitations and potentially the project/req type to the organisational requirements).

When used in conjunction with the appropriate user AdminAuth, this authorisation may be used to allow a user to edit, remove and manipulate items within the Rev-Trac migration queue.

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

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

29 July 2009

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

25 June 2009

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?

25 June 2009

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.

Granular Authorisation - Rev-Trac Migration Workbench

28 May 2009

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

As this is an expert tool the use of the tool is limited to users with specific administration authority. In situations where a company may have strict guidelines regarding segregation of duties it is possible to allow access to this tool without allowing the user to have full administrative authorization for other Rev-Trac functions.

Two different settings affect whether or not a user can access the Rev-Trac Migration workbench:

• The authorisations included in the SAP user master record
• The user's Rev-Trac 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

SAP User Authorisation Profile

Add a profile based on the sample profile Y/RSC/ADM05 (Admin: Migration Workbench) to the user's SAP user master record (adjusting the target group limitations to your requirements).

When used in conjunction with the appropriate user AdminAuth, this authorization may be used to allow a user to add items to the Rev-Trac migration queue and to migrate items in the foreground or to perform immediate manual migrations using the Migration Workbench.

Rev-Trac AdminAuth setting

Ensure the user has a setting of AdminAuth = 01 in the Rev-Trac user configuration area.

This setting is located at:
Rev-Trac Console > Configuration > Process > Organisations > Users

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

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

28 May 2009

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

29 April 2009

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?

29 April 2009

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

18 March 2009

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?

18 March 2009

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'

25 February 2009

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?

25 February 2009

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.

Reviving a deleted Rev-Trac request

29 January 2009

Once a Rev-Trac request is put into a deleted status (DELT), it cannot be modified.

This can however become a problem if the request should be required to migrate transports.

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'

In order to get around this error message and change the status of the Rev-Trac request, you will need to define DELT as a status within the strategy (normally after COMP) and provide a valid approver.

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

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

How do I add a system to a target group?

29 January 2009

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.

How to prevent deleted Rev-Trac requests from locking objects

17 December 2008

It is not possible to delete a Rev-Trac request. Instead, Rev-Trac requests can be assigned to a deleted status (DELT). This is an auditing requirement for many customers.

A Rev-Trac request with status DELT may continue to lock objects which are included in its transports.

To prevent Rev-Trac requests with status DELT from locking objects, check the following configuration from the Rev-Trac console menu:
Configuration > Process > Strategies > Statuses

Look for "DELT" in the Status column:
- The "Lock mode" entry for "DELT" should be 1
  (Don't lock objects on Rev-Trac requests in this status)

What is the difference between a ‘No Approver’ and an
‘Auto-Approver’?

17 December 2008

There are two circumstances where it can be desirable to have Rev-Trac automatically approve a status:

• Automatic approval of a ‘post migration’ status
• Automatic approval of a ‘non post migration’ status

There are two automatic approvers built into Rev-Trac:

• <AM> Auto Approver
• <NO> No Approval Required

The following is an overview of the two different automatic approvals and the correct approver to use in each case. It is important to use the appropriate approver.

Automatic approval of a ‘post migration’ status
An example of this could be the automatic approval of the ('post migration') status 'In QAS' after transports have been successfully migrated to QAS. The approver will be shown as AUTOMIG.

In this case the <AM> Auto Approver should be included as an approver of the post migration status. This makes sure the approval is dependent on the successful migration of transports initiated in the previous step.

Note: a status should always include at least one real person approver able to approve the status should manual intervention be required to correct a failed migration.

Automatic approval of ‘non post migration’ status
The <NO> No Approval Required is typically used to automatically approve statuses NEW and COMP. In this case Rev-Trac will detect that no approver is required, and automatically approve the status.

NOTE: The <NO> No Approval Required should be used with caution, as it may have undesired results if used incorrectly.

Where do I configure this?
From the Rev-Trac master console, you can access this area of configuration from the menu:
Configuration > Process > Strategies > Status Path Approvers & WF recipients (Position).

For further information refer to the Rev-Trac Administrator Guide, under section autoapproval. Also search for "<NO>". The Administrator Guide is available for download from the support area.

Transport Lists

26 November 2008

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

• Running comparison reports with many specified 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.

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

26 November 2008

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.

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

30 October 2008

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.

Rev-Trac enforcement is not working, where should I check to ensure that my environment is correctly configured to ensure all transports are attached to a Rev-Trac request?

30 October 2008

There are several areas you can check to see if the enforcement issue you are encountering can be corrected via standard Rev-Trac maintenance and configuration checks.

1. 1. Is the change a local change or a transportable change request?
   Rev-Trac will not enforce the attachment of local change requests to a Rev-Trac request. Please ensure that you are creating a transportable change request and not a local change request.
2. 2. Are the field exits active in the development system?
   Verifying that instance parameter: abap/fieldexit = yes has been set and that the system has been restarted since this parameter was set. If this parameter is not present: Add the parameter to the system's instance profile via transaction RZ10 and restart the system
3. 3. Are the Rev-Trac field exits active?
   To check if the Rev-Trac field exits are active, run program RSMODPRF and check the status of field exits for data elements TRKORR and TRORDERTXT.
4. 4. Is the Rev-Trac BADI active (SAP 4.6C+)?
   Check if the Rev-Trac BADI /RSC/DEV_EP_PLUS_TX is active using transaction SE19.
5. 5. Are all RFC destinations functioning correctly?
   Rev-Trac menu path: Administration > Health Check
   Deselect all options except ‘Perform RFC check’
   A list of all RFC destinations should return without any errors.
6. 6. Is Rev-Trac enforcement enabled at a system level?
   Rev-Trac menu path: Configuration > Systems > Systems -> System Parameters
   For the system in question, ensure that ‘Enforce’ = 1
7. 7. Is Rev-Trac enforcement enabled for the user experiencing the problem?
   Rev-Trac menu path: Configuration > Process > Organizations
   For the user in question, ensure that ‘UserType’ = 0

If you have confirmed that all of the above has been checked and enforcement is still not working, please send a problem report to support@xrsc.com and include a copy of your Rev-Trac diagnostics file.

Require multiple approvals on a single status

08 September 2008

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?

08 September 2008

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

20 August 2008

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.

What are the differences between Rev-Trac’s background and foreground migration methods and which do you recommend?

20 August 2008

Two migration methods are available in Rev-Trac. Rev-Trac's queued migration method migrates transports in a two-step process (this is the recommended method).

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 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. This method of migrating transports is less flexible than queued migration and is no longer recommended.

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 further information and a summary of the differences between the two methods, see the heading ‘Migration’ in the current version of the Rev-Trac Administrator guide available for download from the support area.

Migrate to multiple destinations on single approval

04 July 2008

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

04 July 2008

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

04 June 2008

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.

When I perform a check configuration in Rev-Trac why do I get error ‘Auto-Migration should not be alone in status’?

04 June 2008

The Auto-Migration Approver is assigned to a post migration status to automate the confirmation of a successful migration e.g. 'In QA'.

If the approver is the only approver assigned to a status, the Check configuration utility will return an error.

Configuration > Check configuration > Check configuration

In this case it is required that an additional manual approver of the same approval type is assigned to the status.

The secondary approver will receive a workflow message advising that the post migration status requires manual approval in a case where the migration return code indicates errors or failure, causing the approval to fail. It will then be up to the manual approver to investigate any migration errors, and if necessary approve the post migration status.

The manual approver on a post migration status is also the only non-admin user who will have the authorisation to re-queue transports from a failed migration.

The manual approver can be derived from a team/position in the org structure, or a request defined position such as owner or programmer.

For further information please consult the Rev-Trac Administrator Guide under the heading: Migration > Autoapproval

Transport Dependencies

22 May 2008

As of Rev-Trac Support Package Stack 16 (SPS16) it is now possible to configure a direct dependency between one or more transports attached to the same or different Rev-Trac requests related to the same or different landscapes. The ability to configure a dependency between one or more transports could be useful in situations where for example:

• Different but related changes in the same landscape (for example, DDIC data elements & program changes that reference the data elements) need to be migrated in a specific sequence.
• Different but related changes in two different types of landscapes (for example, R/3 and BW) need to be synchronized.

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

Is it possible to tell who made a change to a Rev-Trac configuration table?

22 May 2008

To enable the auditing of changes to the Rev-Trac configuration tables, the "Log data changes" technical settings has been set for all of the main Rev-Trac configuration tables.

As of Rev-Trac Support Package Stack 15 (SPS15), anyone wishing to enable auditing of Rev-Trac configuration changes can now do so by activate SAP table auditing in their Rev-Trac master system. A full list of which tables will be logged can be viewed via SAP transaction SCU3.

Table change logging is controlled by the rec/client parameter in the SAP system profile RZ10. The parameter can take the following values:

• rec/client = off (default)
• rec/client = all
• rec/client = ...

Setting the REC/CLIENT parameter to All can seriously impair SAP system performance. SAP recommends you do not use the value All. You should limit automatic logging to one client.

Be aware that by turning on SAP table auditing you will be activating table auditing for other SAP tables as well as for the Rev-Trac tables where we have activated the "Log data changes" technical setting.

Backing up your Rev-Trac configuration prior to making changes

19 Mar 2008

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?

19 Mar 2008

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?

15 Feb 2008

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?

15 Feb 2008

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?

24 Dec 2007

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

17 Dec 2007

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

10 Dec 2007

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

03 Dec 2007

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?

26 Nov 2007

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).

Running migration jobs more often than you need?

19 Nov 2007

Each time an item is added to the Rev-Trac migration queue a Rev-Trac event is raised:

• With parameter IMPORT

• With parameter IMPORT_SYSTEM_SSS (where SSS is the destination SID), and

• With parameter IMPORT_TARGROUP_TTT (where TTT is the destination target group)

Instead of scheduling all your background migration jobs to run whenever the Rev-Trac event is raised with parameter IMPORT (which can result in the running of many migration jobs that find nothing to migrate) you can schedule your migration jobs to run only when the Rev-Trac event is raised with the relevant parameter.