Rev-Trac SAP Change Management: Frequently Asked Questions
- Can Rev-Trac help us with Sarbanes-Oxley compliance?
- Can Rev-Trac prevent accidental overwriting of changes?
- Can Rev-Trac help us manage refreshes of QAS from PRD more easily?
- Can Rev-Trac manage multiple SAP releases within a single installation?
- How can Rev-Trac help us manage parallel production support and upgrade/project streams?
- Can Rev-Trac manage a landscape with many different systems and clients?
- Can Rev-Trac ensure developers are not unintentionally changing an object currently being tested in QAS?
- Does Rev-Trac require extensive and detailed TMS configuration?
- Does Rev-Trac manage all types of work using the same approval and migration process?
- If we decide to withhold a functional change from production, can Rev-Trac tells us what transports to hold back?
- How does Rev-Trac migrate transports?
- Does Rev-Trac include a migration backout function?
- Can Rev-Trac control the migration of sensitive objects like user profiles and number ranges?
- How easy is it to implement Rev-Trac?
Can Rev-Trac help us with Sarbanes-Oxley compliance?
Rev-Trac enforces whatever processes your organisation has defined for documenting, approving and progressing changes through your SAP installation.
Because Rev-Trac forces users to relate each technical change to a business issue(Rev-Trac request), the significance of each technical change is always clear to those approving the progression of the change.
Rev-Trac provides a complete audit trail of all change approvals (including approvals for migration), records all overwrite/overtake warnings issued or over-ridden for a given change, and logs all field level changes to the business issue record (Rev-Trac request).
The purpose of every technical change is visible and transparent at all times, and the full history of each change is visible to every user.
Can Rev-Trac prevent accidental overwriting of changes?
Yes.
Rev-Trac can automatically detect whether a proposed migration will cause a workbench object or configuration change in the target system to be overwritten before the migration occurs.
This is a very powerful safety feature.
In addition, if the effect of a proposed migration will be to skip an earlier released transport carrying the same object or configuration, Rev-Trac will report an overtake.
Rev-Trac may be configured to block automatic, on-approval migrations completely if a potential overwrite or overtake is detected. Alternatively, users may be given the discretion to proceed with the migration after receiving an overtake warning.
Can Rev-Trac help us manage refreshes of QAS from PRD more easily?
Yes.
Rev-Trac tracks the movements of all transports through your landscapes, automatically taking account of the effects of system or client copies or refreshes, and of perfect or imperfect system restores.
Immediately before refreshing QAS from PRD, you can run a Rev-Trac comparison report to tell you what transports are currently present in specific QAS clients that are not present in PRD.
After refreshing QAS from PRD, you can use Rev-Trac to re-migrate the missing transport to QAS.
Can Rev-Trac manage multiple SAP releases within a single installation?
Yes.
A single Rev-Trac installation may contain SAP instances on releases 4.0 through to the latest 700 releases, including Unicode instances.
There is no need to install separate release-specific Rev-Trac modules for different SAP releases. Rev-Trac software adapts automatically to the SAP release level of each environment in which it is installed.
How can Rev-Trac help us manage parallel production support and upgrade/project streams?
For more information on Rev-Trac features that help support you in these areas, request a copy of our white paper Managing an SAP Solution Upgrade with Rev-Trac
The approach outlined in this white paper is equally relevant to managing upgrades and projects while running a separate production support stream.
Can Rev-Trac manage a landscape with many different systems and clients?
Yes.
There is no theoretical limit to the number of SAP instances and clients within a single Rev-Trac installation.
We have a number of customers who are controlling thirty or more SAP instances, many with half a dozen clients, from within a single Rev-Trac installation.
Can Rev-Trac ensure developers are not unintentionally changing an object currently being tested in QAS?
Yes.
Rev-Trac extends SAP's own locking concept beyond the time of transport release, and extends the SAP locking concept to include configuration as well as workbench objects.
Rev-Trac's extended locking system ensures that a developer who starts to change an object or configuration that is currently awaiting testing in QAS is notified that the object or configuration is locked to a particular Rev-Trac request, and that all changes to this object or configuration should be recorded against the same Rev-Trac request.
A mechanism exists to loosen this restriction in specific circumstances, or on a case-by-case basis, if required.
Locks are dropped when a change reaches production.
Does Rev-Trac require extensive and detailed TMS configuration?
Rev-Trac requires that TMS be configured to the point where transportable (ie, non-local) transports may be created.
It is not necessary to establish a one-to-one relationship between development and production systems.
Nor does it matter how many TMS domain controllers are configured, where they are located, or whether systems have common or separate transport directories.
Does Rev-Trac manage all types of work using the same approval and migration process?
No.
One of Rev-Trac's strengths is the great flexibility with which approval and migration processes may be defined for different types of work.
If we decide to withhold a functional change from production, can Rev-Trac tell us what transports to hold back?
Yes.
Because each Rev-Trac request represents a single functional change to SAP, and because each Rev-Trac request is linked only to transports that implement this change, it is very easy to determine which transports to withhold from production in these circumstances.
How does Rev-Trac migrate transports?
Depending on your configuration, Rev-Trac performs migrations by calling an SAP function provided for this purpose, TMS functions or tp.
Rev-Trac can automatically migrate the transports linked to a business issue (Rev-Trac request) immediately after users have approved the migration. These migrations may occur either in the foreground or in the background. Alternatively, approved migrations can be scheduled to occur at set intervals (for example, nightly to QAS, weekly to PRD).
A specialist migration tool is available that allows Rev-Trac administrators freely to select transports for migration and send these to specific destinations, either in the foreground or using a background job.
After Rev-Trac has been installed, authorised users may continue to perform migrations using TMS or tp if this proves necessary. Rev-Trac automatically tracks all transport movements, regardless of whether they were initiated under Rev-Trac control or manually.
Does Rev-Trac include a migration backout function?
No. Rev-Trac does not offer a migration backout facility for use after a migration has failed.
Such a feature is virtually impossible to implement with a high degree of reliability, would have only limited scope for technical reasons, and would inevitably tend to offer a false sense of security.
The Rev-Trac philosophy is about preventing errors from occurring in the first place and building in quality from the beginning.
Change promotion errors typically arise from out-of-sequence transport migration (sometimes as the result of uncontrolled parallel development) and a failure to follow proper approval processes. The Rev-Trac Overtake and Overwrite Protection System (OOPS), extended locking system and approval mechanisms all have important roles to play in preventing such errors.
If a migration error does occur, Rev-Trac's powerful reports can help the Basis team quickly identify what remedial actions need to be taken.
Can Rev-Trac control the migration of sensitive objects like user profiles and number ranges?
Yes.
Rev-Trac can detect whether transports proposed for migration contain objects you have defined as requiring special approval for migration, or whose migration you want to prevent, and can automatically enforce your requirements for such objects.
How easy is it to implement Rev-Trac?
Most sites install Rev-Trac and begin full transport movement monitoring in one day.
Implementing Rev-Trac change management processes can take one or two weeks, as the organization finalizes decisions regarding workflow, approvers, migration targets etc.
Training time for a Rev-Trac administrator is typically five days, one-to-one. For users, training time is typically one to two hours in the classroom, or 30 minutes one-to-one.
You can also contact us to ask a Rev Trac question
Our Customers
“In one of our departments, our application vendor struggled for two years to deliver reports from an SQL Server OLAP structure without success. We completed the task in two days with xReports.”
Peter Cassell
Toyota Australia