SAP standard transport system

   Usually, an SAP environment consists of several instances (for example, a development system, a test system and a production system; Figure 1). Each change needs to be made in the development system (DEV) and then transferred through the transport request to the test system (TST). If the change turns out to be insufficient, another transport request must be created in the development system (DEV) and after acceptance transferred to the test system (TST).

   When all changes are correct, all transport requests must be transferred to the production system in the same sequence in which they were transferred to the test system. Problems appear when one transport request is skipped. The situation is even worse when several consultants are changing objects at the same time - then, it is often difficult to determine a correct sequence of transferred changes and sometimes it is necessary to manually create another transport request to avoid collision of transferred object versions.

   Difficulties in monitoring individual changes (who made what and when) and the sequence and time of the object transfer to the downstream system are typical of such a system. Other disadvantages include the necessity to identify on which system the current object versions are and to manually approve and export changes to the downstream system. In large developments, it is difficult to identify whether the development system status is the same as the test and production system status.

SAP system with the Polylogic Change Manager

   Majority of the problems described in the previous section disappear or are almost unnoticeable when a transport management system is used. There is a wide range of programs from many different vendors available on the market.

   The Polylogic Change Manager was developed by the company whose main field of activity is the SAP system administration for large international enterprises. The system contains the set of tools and functions enabling a quick and straightforward transport management and ensuring the quality of transferred changes. The system is easy to use both for the administrator and for the consultant.

   The figure below presents the situation described in the previous section with the use of the Change Manager. The first evident difference is the sequence of making changes. The changes made in the test system (TST) are always consistent with the changes transferred to the production system (PRD). This minimizes the problem with the conflict of objects. The changes may by transferred to the systems in a pre-defined sequence. These changes are made incrementally, not differentially. At any moment, it is possible to check on which system a transport request currently is and who and when released it. It is also possible to force the user to enter a comment to the transferred changes and to attach a relevant documentation.

   This system, as opposed to a standard SAP transport system, can start automatically or inform a person responsible (e.g. through an electronic message) that he/she must accept or reject a relevant transport to a downstream system. In addition, enhancements to check the correctness of the changed objects can be built in, so as to minimize the risk of transferring the objects that do not conform to the quality assurance rules or that may jeopardize the system security or lead to problems in the production system.

   Another important fact is that this system is coded entirely in ABAP and does not require any additional computer or any separate management. It is based on the SAP transport system. It can be installed on the SAP system 4.6 and above, including Netweaver Basis 6.40 and Unicode systems.

General features

   The Polylogic Change Manager for SAP R/3R is designed to control and manage the changes and to ensure the quality of changes made.

   All business changes are grouped in so called work packages, and the class to which a relevant package is assigned is defined by the transport route, i.e. a list of systems and clients to which a relevant change should be transferred.

Feature 1 - Transport packages:

  • Any changes to the SAP system that need to be transferred from the source system to the target systems (test, production etc.) are grouped in work packages that make up a business change.
  • Transfer of the transport package means the transfer of the content copy to the target systems. Original SAP changes (contained in a transport package) are locked against changes in a source system for the time of tests conducted in downstream systems.
  • If tests are unsuccessful, a transport package simply needs to be reset so that further changes made in the source system could be registered in it. As opposed to the standard SAP transport system, there is no need to create new transport requests, release them and transfer them to target systems.
  • When a business change is tested correct, it may be transferred to the production system. If no further changes are planned, the transport package may be released to unlock objects in the source (development) system.
  • A sequence of transports to target systems is not important, because changes are always transferred incrementally, not differentially.
  • Elements of the documentation and attachments can be saved in transport packages as freely formatted documents to make up a full package that identifies the character and a version of the business change.

Feature 2 - Control of released transport packages:

  • Working with transport packages consists in releasing of relevant steps in the package that depend on the package class.
  • Authorizations are checked at each release step and may be based on a standard SAP and Change Manager authorizations; additional, more detailed checks may be built in.
  • It is possible to define special objects with an additional authorization control to ensure that potentially troublesome objects are approved solely by a right person (e.g. numeric scopes).
  • Each release of the transport package is registered and may be viewed in a release history.
  • For each release, a password authentication may be initiated.
  • Each release step may contain an additional check list with items that should be considered or analyzed to ensure quality. In the release history, time, user ID and his answers to the questions are registered.
  • It is possible to turn on the messages to the next person or persons in the release sequence.

Feature 3 - Automatic transfer of changes:

  • Transports are started through the release of relevant steps in a transport package (steps are defined by the class to which the package is assigned).
  • Changes are transported in accordance with the pre-defined transport route. It is possible to define many routes to meet the business requirements as regards testing and authentification (e.g. one release may transfer changes to the test system TST1 clients 010 and 020 and to the test system TST2, client 010).
  • Transports may be transferred immediately after the release or in accordance with the pre defined schedule.
  • Transfer of a package means a transfer of a copy of the current content of the package. It locks the objects until the package is reset or released.
  • Transport is created and exported again from each SAP system. This ensures that only exactly what was tested on the current system, from which the transport to the downstream system is initiated, will be transferred.
  • While defining a transport route, there no restrictions as regards the transport direction; each system on which the Change Manager is installed can be defined as the system transporting to a downstream system and/or client. However, during the transport release, the user cannot ignore any systems.

Feature 4 - Other functions and characteristics:

  • Compatibility with each release from 4.6x up to Basis 6.40, including Unicode.
  • The Change Manager is coded only in ABAP to enable improvements and to ensure a hardware platform independence.
  • There is no limit of the number of systems that can be defined in the transport route. The changes can be transferred simultaneously to the selected systems and/or clients.
  • The program makes it possible to define a series of enhancements to meet a specific customer's requirements.
  • Each step release is registered with the releases for transport, results of the quality control check list, resetting work packages etc. Many evaluations and reports are available to allow reviewing the changes made.
  • A rich set of tools facilitating the implementation of SAP changes and making them more intuitive.

Current reference list:

  • Philips, Eindhoven, Holland
  • Novartis Consumer Health, Bern, Switzerland
  • Novartis OTC, Munich, Germany
  • Knoll AG (Abbott Laboratories), Liestal, Switzerland
  • Mittal Steel Poland - in the test phase

PDF version - download a PDF file