Show TOC

Replicating a Track into a Different DTR RepositoryLocate this document in the navigation structure

Use

Certain circumstances can make it necessary to relocate the Design Time Repository (DTR) content of some track from one DTR server to another. Here you will find a description of the steps that are necessary to achieve this. The procedure will take care to not only copy the current state of your development project but to also include the historical state of the sources, that is, the version history of the files. The replication can take place between DTR servers of different releases.

Replication Mechanism

The replication of a track is the process of copying all the workspaces present in the track from a source DTR to a target DTR. This operation works by applying all integrations (check-in of activities, integration of a propagation lists) that were previously performed on the source workspace, to the target workspace.

In addition to integrations, the replication process also copies the information that CMS stores in DTR about which activities were already released in a given track.

The time required for the whole replication operation depends on:

  • The number of software components (SCs) present in the track that is being replicated.
  • The number of integrations and the number of the development objects in each of the source workspaces of the track.

Since the replication may take a lot of time (up to a couple of hours for tracks that e.g. modify SAP_ESS or SAP_MSS), the replication mechanism provides the following features in order to ensure minimal downtime:

  • The copy process can be resumed in case it stops due to an error. The replication then proceeds from the point where it stopped and does not need to restart from scratch.
  • The source workspaces are available for modifications while the replication is in progress.
The ‘Replicate’ - Command in the DTR Console

When replicating a track, the basic operation is the replication of a DTR workspace (e.g. /ws/ TRACKID / vendor_SC /dev/inactive). This is a pure DTR operation which does not rely on quantities defined in CMS or CBS. The replication of a DTR workspace is done by means of the DTR console, a command line based administrative tool deployed on the AS Java system where the DTR is running. The tool is located in the folder ‘/usr/sap/SID/SYS/global/com.sap.dtr.console’, it can be started using the run.bat on Microsoft Windows operating systems. The DTR console is release-independent, a recent version containing several improvements and bug fixes can be downloaded from note 1377679 Information published on SAP site. Please download the SDA to some windows server, unpack it and start it using the run.bat file. Typing help replicate at the command prompt will list an overview of possible options and mandatory arguments of the command followed by some examples.

The replicate command will execute the following steps:

  1. It will create a list of all integrations in the source workspace

  2. One by one these integrations will be exported to disc, imported into the target DTR and integrated into the target workspace. These steps will be skipped for integrations that are already present in the target workspace.

  3. Finally all version set groups that refer to the source workspace (this is the mechanism to keep track of the released status of activities) will be re-created in the target DTR.

During the replication the state of the target workspace will be set to restricted thus preventing concurrent modifications to the workspace.

Procedure

  1. Before the replication can start it is convenient to create the necessary DTR workspaces by saving a CMS track with the appropriate configuration. The concrete steps depend on your development landscape, in the first step please either follow description 1A or 1B:

    1. 1A. Let us assume you have 2 complete NWDI landscapes (each running its own CMS, CBS and DTR) and you want to move the track TRACK1 from the source NWDI landscape DI1 to the target NWDI landscape DI2, and continue development of this track in the target landscape:

      1. Log on to the CMS Web UI of landscape DI2.

      2. In the Track Data – tab of the Landscape Configurator choose New.

      3. Enter the correct track ID (TRACK1 in case you want to keep the ID, but you can also choose a different ID), name and description.

      4. Enter the server URLs for DTR and CBS pointing to the respective servers of landscape DI2.

      5. Choose the same Developed Software Components as in the source track.

      6. Click Save.

        Note A simpler version of the above scenario consists in copying a track with ID TRACK1 to another track with ID TRACK2 within one and the same NWDI landscape. To achieve this using the ‘Save as…’ button on the source track is a shortcut to the steps described above. It will be necessary to provide a new track ID and track name, but the server URLs as well as the configured SCs will be copied automatically from the source track.
    2. 1B. Now let us assume that you do not dispose of a complete target landscape and you only want to move the DTR workspaces to a different DTR server while keeping CMS and CBS, e.g. for load balancing reasons.
      Note Before executing the below steps please make sure that no development takes place.

      1. Log on to the CMS Web UI.

      2. bIn the Landscape Configurator select the track that you have in mind and click Change in the Track Data – tab.

      3. Change the Design Time Repository URL so that it points to the target DTR.

      4. Choose Save.

        This will create the DTR workspaces in the target DTR and in addition trigger an Init Compartment – operation in CBS. As a consequence, since the target DTR workspaces are still empty, the number of DCs in the developed SCs displayed by CBS will be zero.

        To ensure minimal downtime you can now optionally change back the Design Time Repository URL to its previous value, save the track and reopen development. Again CBS will trigger an Init Compartment – operation, the duration of which depends on the size of your project.

  2. 2. Prepare the relocation script file and run it to populate the workspaces in the target DTR, see the example below. The relocation script must be run with the credentials of a user who has the privileges of the ACL role adminA on the target repository.

    The above step is carried out while the source DTR workspaces are still available to the end users (in case you changed back the DTR URL in scenario 1B). The integrations (check-ins and integrations of propagation lists) that took place while the replication was running have to be replicated by running the script a second time. Before, all developers must check in their pending changes and subsequently the source workspaces must be closed. This way no further integrations can take place and the replication can be completed.

  3. To close the workspaces, set ACLs on the workspaces so that only the user who is used for replication has access to the workspaces (in addition to any administrators, if present).

  4. Run the relocation script once more in order to copy the latest changes to the target workspaces.

    Note

    If you feel confident with closing the DTR for the entire duration of the replication (e.g. during the weekend) you can avoid running the script a second time.

  5. Now:

    1. 5A. In case you followed scenario 1A you can now import the required archives into the new track on the target system and finally trigger Initialize for all source compartments in CBS.

    2. 5B. In case you switched back the DTR URL before running the relocation script in scenario 1B, now is the time to switch it once again to point to the target DTR server. CBS will start the initialization of all source compartments automatically. In case you left the URL pointing to the new DTR during the replication you will need to trigger Initialize for all source compartments in CBS.

Result

Saving the track updates the development configuration that is used by the developers in the SAP NetWeaver Developer Studio. The developers must re-import the development configuration into their Developer Studio (or must have activated the automatic update of development configuration – mechanism) in order to get the latest version of the development configuration corresponding to the track. The updated development configuration will point to the new DTR.

Example

To run this example script, you have to store its content in a file, for example c:/temp/replicate.txt. Then start the DTR console and run the command:

script c:/temp/replicate.txt

Here is the content of the file:

connect targethost:targetport user password targetID
connect sourcehost:sourceport user password sourceID
replicate –r –d c:/temp/replicate /ws/TRACK1/SC1/dev/inactive targetID /ws/TRACK1/SC1/dev/inactive
replicate –r –d c:/temp/replicate /ws/TRACK1/SC1/dev/active targetID /ws/TRACK1/SC1/dev/active
replicate –r –d c:/temp/replicate /ws/TRACK1/SC1/cons/inactive targetID /ws/TRACK1/SC1/cons/inactive
replicate –r –d c:/temp/replicate /ws/TRACK1/SC1/cons/active targetID /ws/TRACK1/SC1/cons/active
replicate –r –d c:/temp/replicate /ws/TRACK1/SC2/dev/inactive targetID /ws/TRACK1/SC2/dev/inactive
replicate –r –d c:/temp/replicate /ws/TRACK1/SC2/dev/active targetID /ws/TRACK1/SC2/dev/active
replicate –r –d c:/temp/replicate /ws/TRACK1/SC2/cons/inactive targetID /ws/TRACK1/SC2/cons/inactive
replicate –r –d c:/temp/replicate /ws/TRACK1/SC2/cons/active targetID /ws/TRACK1/SC2/cons/active