Replicating a Track into a Different DTR Repository 

Use

If you use a sandbox track in which you develop your applications, you may need to move this test track to a productive SAP NetWeaver Development Infrastructure (NWDI) landscape at a later point in time. Here you will find a description of the steps that you have to take to move the sources of an NWDI track from one Design Time Repository (DTR) repository to another repository (including the historical state of the sources, that is, the version history of the files).

The data stored in the Change Management Service (CMS) such as development configuration, or build-results, is basically derived from the data stored in the System Landscape Directory (SLD) and Component Build Services (CBS).  The data which is stored in the CBS, that is, the build results, is derived from sources stored in the DTR.

When the replication of a track takes place, the data in the new CMS and CBS can be restored if the data in the DTR can be restored. You can also use these steps if you simply want to move the track from an existing DTR repository to another DTR repository without having to relocate the CBS and CMS. In this case, the data in the CMS and CBS have to be re-initialized to synchronize them with the new DTR repository.

Replication Mechanism

The replication of a track is the process of copying all the workspaces present in the track from a source DTR repository to a target DTR repository. This operation works by replicating from the source workspace to the target workspace every single integration (check-in of an activity, integration of propagation lists) that was performed on the source workspace.

In addition to the 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.

For example, each SC can contain four workspaces that need to be replicated (DEV inactive, DEV active, CONS inactive and CONS active).

●      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 (for example, few hours in the case of ESS/MSS workspaces), the replication mechanism provides the following features:

●      You can resume the copying process in case it stops due to any errors. The replication then proceeds from the point where it stopped and you do not need to start the replication process from scratch.

●      The source workspaces is available for modifications while the replication is in progress.

DTR Console

The DTR console is a command line based administrative tool deployed on to the AS Java system where the DTR is running. The tool is located under /usr/sap/<SID>/SYS/global/com.sap.dtr.console folder. It is platform-independent. For Microsoft Windows OS, use the run.bat to start the console application. You use this tool to trigger the replication process on the individual workspaces.

Procedure

Let us assume that we want to move the track TRACK1 from the source DTR SRCDTR to the target DTR TGTDTR.  This use case assumes that the CMS and CBS repositories are not being relocated but only the DTR workspaces corresponding to the tracks need to be relocated.

...

       1.      Log on to the CMS Web UI.

In a Web browser, open the following URL: http://<host name>:<port number>/devinf. Choose the Change Management Service link.

       2.      Choose the Landscape Configurator link and change the DTR URL in the track configuration of TRACK1 from SRCDTR to TGTDTR.

       3.      To create a copy of TRACK1, choose Save As. Name the track TRK1CPY

The reason for performing this save as operation is to make the CMS create the target workspaces for the replication. The DTR console replicate operation assumes that the target workspace has already been created since the target workspace can be named differently to the source workspace, and the path to the target workspace may also look quite different from that of the source. The copy operation does not affect the source track in any way.

       4.      Delete the copied track TRK1CPY from the CMS Web UI. 

The reason for copying the track is to easily create all the necessary workspaces on the target DTR repository. Deleting the track only deletes the track information from the CMS and CBS, it does not delete the workspaces in the DTR.

       5.      Rename the folder /ws/TRK1CPY to /ws/TRACK1 in the target DTR repository.

                            a.      Open Internet Explorer. From the menu path choose File → Open…

                            b.      Specify the URL of the DTR where the copy of the repository is located.

                            c.      Activate the Open as Web Folder check box. Choose Open.

                            d.      Browse to the specified folder and use the context menu to rename the folder.

       6.      Prepare the relocation script file and run it to populate the workspaces in the target DTR repository TGTDTR.

The above steps are carried out while the source DTR workspaces still available to the end users. The integrations (check-ins and integrates) that took place in the meantime while the replication is running have to be replicated through a second run of the whole procedure. Hence the source workspaces need to be closed for further changes so that the replication can complete replicating the remaining workspaces. All developers must check in any pending changes and then the workspaces should be closed for any further check-ins:

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

       8.      Run the relocation script once more so that any pending changes in the source workspaces are copied to the target. The relocation script must be run with the credentials of a user who has ADMINA privileges on the target repository.

Running the relocation script again can be avoided by ensuring that no user has access to the source repository (controlled using ACLs) during the time that the replication is running.

       9.      Using the CMS Web UI, change the DTR URL in the track TRACK1 from SRCDTR to TGTDTR.  Save and restore the track.

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 in their Developer Studio, or must have activated the automatically update of development configuration mechanism to get the latest version of the development configuration corresponding to the track. Now they work with the new DTR repository.

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