Skip to Content

This article describes the usage of Tracks (in JDI) to address a few branching use-cases. A simple branching pattern is first used to indicate what is possible with Tracks, and the two concrete use-cases that follow provide detailed descriptions on how to structure a JDI landscape to develop multiple releases of a product.


The article assumes familiarity with JDI related abstractions, espectially the functions of CMS surrounding setting up and maintaining a landscape (like Track Creation, Import, Assembly, Approval). It also expects the reader to be familiar with aspects of Software Configuration Management (SCM) surrounding branching.

General SCM terms used:

Mainline : Code-line where main development is done.
Branch : Code-line parallel to Mainline; used for parallel (concurrent) development.
Merge : The operation of bringing together changes made in two branches.


The following extract from a paper on Branching Patterns describes two kinds of branching models supported by SCM (or Version Control) tools:

Most VC tools supporting branches do so at the granularity of a lone file or element. The revisions and branches for each file form a version tree which depicts the evolution of a single file. This is called file-oriented branching. Branches are used and organized and viewed in the context of a single file. While there may be a loose or coincidental similarity between the version trees of different files, file-oriented branching focuses primarily on physical modifications to individual files as the unit of change and change-flow.

But branching is most conceptually powerful when viewed from a project-wide or system-wide perspective; the resultant version tree reflects the evolution of an entire project or system. We call this project-oriented branching. With project-oriented branching, branches are used and organized and viewed in the context of an entire project, product, or system. Project-oriented branching imposes a more or less uniform structure on the version trees for all the files in the system. Instead of emphasizing modifications to individual files, project-oriented branching focuses primarily on the flow of logical changes across the entire system. Logical changes flow through and between streams of work in which product and component versions are integrated, built, baselined, and released.

DTR supports branching at the level of a Workspace (which is a collection of versions representing Files and Folders) – so in this sense it follows the Project oriented branching model mentioned in the above extract. In the context of scenarios using all parts of JDI (DTR, CBS and CMS), branching happens at the level of a Track. This article describes Track-based branching, and hence is not applicable for the scenario using only DTR (For this scenario – using only DTR for versioning – branching involves creating a new Workspace – that represents a branch – and integrating Closed Activities from the source to this target Workspace).

The branching pattern and use-cases listed below describe different Track-based landscapes with the following options for propagation (transport) of sources between them (In traditional SCM terminology, these options describe the different ways you can “merge” changes across different “branches”):

(A) Automatic Propagation

Automatic Propagation between tracks is achieved through Track Connections (which can be configured from the CMS Landscape Configurator). There are two kinds of connections possible:

Transport : This connection type transports all the Assembled and Approved SCAs to the target track. Thus, the granularity of transport is an SC.

Repair : This connection type transports Change Requests that were released (from the “Transport View” of the NetWeaver Developer studio). These Change Requests are placed in the import queue of the target track’s “Dev” system. Thus, the granularity of transport here is a Change Request (which can contain one or more activities pertaining to an SC).

(B) Manual Propagation

You can also manually forward SCs that have been Assembled and Approved in a Track. (The forwarding functionality is available in the “History” view of the “Approval” tab in the CMS Transport Studio.)

Note: All the above transports will lead to “Integration Conflicts” for files modified in both tracks. These conflicts can be viewed and resolved through the “Integration Conflicts” view in the DTR Perspective of NetWeaver Developer Studio. To resolve these conflicts, you can (a) accept existing version or (b) accept incoming version or (c) perform a 3-way merge.

Basic Pattern: Development in parallel branches

Summary: Branch from Mainline, develop in parallel and merge back into Mainline. (This allows you to isolate development of some functionality in a parallel branch, while continuing to develop in the Mainline).

Pre-requisites (Initial State): Existing track (Track A, representing Mainline) containing currently ongoing development.


Steps for branching:

(1) In Track A, assemble and approve the SCs containing sources that need to be branched.
(2) Create a new track (Track B) as a copy of existing track. (Use “Save as..” option in CMS Landscape Configurator).
(3) Forward the approved SCs from Track A to Track B.
(4) Import these SCs into the Track B.
(5) Import development configuration of the “dev” system of Track B into your Developer Studio -> this environment represents the branch where you can develop in parallel to the Mainline.

Steps for propagating changes back to Mainline:

Option A: Frequent propagation using “Repair” connection

(1) Create a track connection of type “Repair” from Track B to Track A
(2) While developing in Track B, check-in and activate your changes, but perform a release (from the “Transport View”) only when you wish to propagate your changes back to the Mainline (Track A). The released Change Requests will automatically be transported into the DEV system of Track A.

Note: Use this option if you wish to merge back to the Mainline on a regular basis.

Option B: Automatic propagation after approval of changes

(1) Create a connection of type “Transport” from Track B to track A.
(2) Each time you wish to merge changes back to the Mainline (Track A), assemble the SCs and approve them. Then import them into Track A.

Option C: Manual propagation

(1) Each time you wish to merge changes back to the Mainline (Track A), assemble, approve and forward the SCs. Then import them into Track A.

General Remarks:

(1) A Track is a very coarse granular abstraction for branching. Creating a new track to represent a branch implies creating a new environment for all the SCs developed in the track – this may be too much when the parallel development involves, for example, only a few files in a DC. One way around this limitation is to keep the SCs small and develop each SC in a separate track (and bring them together in a final track) – but this increases the complexity of the track landscape.

(2) “Merging” changes across code-lines requires support from appropriate merge-tools. Currently, DTR detects conflicts at the file level and provides file-based merge tools for such conflict resolution. Merge tools for model-based development (using WebDynpro, for example), are currently not available.

Use Case 1: Parallel development in old and new release branches

Summary: After release of product developed in one branch, continue development (or maintenance) on side branch, in parallel to new release development in original branch.

Pre-requisites (Initial State): Existing track (Track DEVLP) containing sources of a release (which will now move into maintenance phase)


Details :

(1) For branching, follow the steps listed above in the Basic Pattern. (The second track is referred to as the MAINT track here).

(2) To ensure constant flow of the changes made from old release branch into the new release development branch, create a connection of type “repair” from Track MAINT to Track DEVLP. Once such a connection is setup, the release of Change Requests (from the “Transport View” of the NetWeaver Developer studio) in the MAINT track will result in the Change Request being available in the import queue of the “dev” system of the DEVLP Track. The conflicts that are caused by parallel development must be resolved in the “dev” system of the DEVLP track.

General Remarks:

The automatic transport of changes from older to newer release code-lines is a feature that eliminates the need for “double-maintenance”. In most Version Control tools, such fixes must be manually re-implemented in all the relevant code-lines, and this can be error-prone. By configuring “repair” connections between Tracks, you only need to implement the fix once. (Note: If the fix is not relevant in new release, that Change Request can be deleted from import queue of the target track.)

Use Case 2: Multiple maintenance branches in parallel to the development branch

Summary: Maintenance is done in multiple branches (each corresponding to one state of the older release), while new release development goes on in parallel.

Pre-Requisites (Initial State): Two tracks – one for new release, and another for maintenance of older release.

Details :

This use-case will highlight the way a company can work on new release development and also in parallel develop Support Packages (SPs) of the older releases. The requirement is simple: there will be an SP delivered every few months, and the company needs to support two older SPs (i.e., provide patches for these delivered SPs, if needed).

The initial state, as described above, is displayed below:


In this landscape, the development of the new release happens in the DEVLP track, while the changes for the next SP of the older release are being made in the 1.0_SPx track. The “repair” connection ensures the propagation of fixes done in the old release to the new release track.

When the SP is ready for delivery, a new track 1.0_SPx-1 is created – this will be track where this delivered SP will be maintained (while the development of the next SP will proceed in the 1.0_SPx track). This is shown below:


To reach such a state, you need to perform the following steps:

1) Create a copy of track 1.0_SPx (using the “Save as.” function in the CMS Landscape Configurator) and name it 1.0_SPx-1
2) Forward the Assembled and Approved SCs from 1.0_SPx to 1.0_SPx-1
3) Import these SCs into the 1.0_SPx-1 track.
4) Setup a track connection of type “repair” from 1.0_SPx-1 to 1.0_SPx

Now, you can develop the next SP in the 1.0_SPx track, and for patches needed in the released SP you can use the 1.0_SPx-1 track

When the second SP is ready for delivery, a similar process is followed. This is shown again in the following diagram:


This will be the final track structure that will meet the original requirement (of developing a new release and maintaining an old release with the ability to patch two released SPs). When the third SP is released, the contents of the first SP (until then maintained in track 1.0_SPx-2 will be overwritten with the contents of the second SP which is present in track 1.0_SPx-1). In this fashion, you will retain the ability to patch the previous two released SPs (If more SPs need to be maintained, more tracks are necessary – but the pattern will be the same as described above).

Concluding remarks

The use-cases described above describe how to configure a Track-based landscape to achieve parallel development of SCs across multiple releases. Aspects surrounding layered development (involving working with multiple SCs with different release cycles) are beyond the scope of this article. However, the basics of track configuration and connections described here provide the foundation for building more complex landscapes.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Pran Bhas
    Great weblog !!! . I had to read it couple of times to get all the concepts , A question if we had to initiate conflict resolution of changes from one track to another should it always be a ‘repair’ connection?
    1. Pran Bhas
      I meant , should it be a repair connection in the context of better control. Also is there plans for merge tools for webdynpro. What is the workaround for now?
    2. Manohar Sreekanth Post author
      Apart from offering a smaller granularity of transport, repair connections offer better control over which repair (fix) goes where – so they are meant to be used for “repair scenarios” (where you make a repair – bugfix – in one codeline and that should also be available in another codeline). But the other ways of propagating changes can also lead to conflicts, as mentioned in the article. Which connection you use depends on the requirement of propagation.

      I must add that Repair connections in their current form have a limitation. When a Change Request that has arrived over a repair connection is imported into the “dev” system of a track, it is immediately activated as well. Now if you consider the general rule that activation also picks up predecessor activities, this means that certain activities that were not meant to be activated (because the change is not tested fully, for example) can also get activated when this Change Request is imported. (This can happen when an activity and the Change Request contain common files or folders).

  2. Sistemi Open SAP
    sorry maybe this is just noise but I have following questions:

    1) I’m using JDI SP13 and I’m not able to find the forward functionality on the Approve tab.It’s a button or what ?

    2) The minimun number of different runtime systems i need for scenario 1 (parallel development in old and new release) can be 2 ?
    I mean: 1 rts as develop for the DEVLP track and 1 rts as develop for the MAINT track ?
    Or I need at least 3 rts (develop and test for the DEVLP track, only develop for the MAINT track) ?

    1. Marion Schlotte
      1) Please click the History button and then the “Forward to Another Track” button will appear.
      2) Both scenarios are possible. But a test RTS within the DEV track is one additional QM step to have a separate system where you can test the assembled software component. The DEV RTS only is ok, but there you can’t be sure which status you are testing. Developers might deploy when activating their changes in the meantime, if the auto-deployment is enabled. An other possibility is, to use the DEV RTS without auto-deployment and deploy the actual active archives of the DEV system manually via SDM.
      Kind regards,
  3. Sistemi Open SAP
    Hi, please, I have another issue on your post.

    When you says there are no merge tools for the model -based development (Web DYnpro) you mean the DTR is not able at all to detect conflict for these objects ?
    If we work in scenario 1 (parallel development in old and new releases branches) with WebDynpro how we should merge back the changes made into the MAINT track into the “dev” system of the DEVLP track ?


  4. Sistemi Open SAP
    I have a new question on scenario ‘Parallel dev in old and new release branches’.

    After forwarwed the approved SC ver. 1.0 to the MAINT track we want to start to develop the version 2.0 o this SC.
    As I understood I have to develop this new version 2.0 on the same DEVLP track where I created the previous version 1.
    BUt that track is assigned into the CMSto SC version 1.
    1) I need to clarify if to start to develop the version 2 I have to define a new Product ver. 2 and a new SC ver. 2 into the SLD and I have to update the DEVLP track, removing the SC ver. 1 and adding the new one ver. 2.

    2) When the version 2 is ready, after the assempble step the SCA for ver. 2 will be produced.
    Suppose we want to deploy the ver. 2 on the same system where the ver. 1 of the same Product is already deployed.
    What happen ? All the object of ver. 1 are overwritten or is possible to keep both the versions active on the same system ?


    1. Marion Schlotte
      1) Yes, you have to define a new Product version, a new SC version and you have to remove the SC version 1.0 from your track definition and add the new SC version. Make sure that all dependencies are maintained.
      2) You are right. All objects are overwritten, if the SC contains the same DCs as the previous version.
      Regards, Marion
  5. Sistemi Open SAP
    We developed an SC on our JDI, managed by a own SLD.
    We are going to pick-up the SCA file after the Assembly step and to import it into another track on another JDI landscape, not connected to the previous where the application has been written.

    I’m asking if before to do the check-in of my SCA on the second JDI I have to do the followig actions too:

    1) to align the second SLD with the SC definition coming from the first SLD

    2) to update the track where the SCA file is supposed to be checked-in with this SC

    THe SCA we are going to pick-up from the first JDI is supposed to be distributed in more systems into the second target JDI landscape.

    If we do not align the target JDI and the target cms track I’m not sure we will be able to move this SCA into the target landscape using the CMS functionalities, but I’m not sure of that.

    Regards and thanks in advance

  6. Som kolli
    Hi Sreekanth,

    Could you please let me know if you have any information on merge tools for Model based development like webdynpro?

    We are using NW 2004s SP7 .


  7. Giorgio Varda
    Following up on Mauro’s question (about how to develop a software component version 2 in the DEVLP track) and Marion’s reply, can you please detail how sources (originally in version 1) are added to version 2 to set up the “initial state” before developments can start on version 2?

    1) Does this happen automatically because we are using the same track (and henceforth the same workspace and buildspace), and the new track definition does not impact the workspace/buildspace if the software component *NAME* stays the same (only the version changes)?
    2) Do we need to copy the DCs with sources manually via Dev Studio?
    3) Or something else?


    1. Marion Schlotte
      yes, you are right.The process is the following when using the same track:
      1) Create a new software component version in SLD with exactly the same SC name.
      2) Go to CMS – Landscape Configurator – Domain Tab – Update CMS
      3) Go to CMS – Landscape Configurator – Track Data – and remove the SC with the old version. Add the same SC with the new version.
      4) Save and Restore System State. The DTR workspaces remain the same, which means the sources are not deleted. The Buildspaces are deleted and you need to import the dependent SCAs again into your development system.

      You do not need to copy the sources manually. Because of the same SC name, the “old” sources are now linked to the new SC version.
      Best regards,

      1. Giorgio Varda
        Thanks Marion, all clear.

        So, assume that we have changed the track definition as specified above to start the development of version 2.0.

        Assume also that the development is ongoing for version 2.0 in the Development environment only, and we need a urgent production fix to version 1.0.

        We could perform the fix in the Consolidation system. Correct?

        If so, when we assemble, will the assembly be “tagged” as SPx to version 1.0, or SPx to version 2.0 (considering that the track definition shows now SC version 2.0)?

        Thanks a lot in advance for your help!


        1. Marion Schlotte
          Hi Giorgio,
          with the definition of a track you decide for which release of a software component (SLD version) you will develop. Within a track it is not possible to have different versions/releases of a software component. When you assemble your software component, the release information is retrieved from the track definition.
          If you need to maintain the old version and develop a new version in parallel, you need at least two tracks. In general it is recommended to use an additional track for maintaining the productive version of an application, please see Weblog Best Practices for NWDI: Track design for ongoing development for track design.

          Instead of using SLD versions, you can use the Support Package numbering in CMS (assembly step) to distinguish between versions of your software. The SLD version is intended to be used when the software component dependencies must be changed in the new version (e.g. the new version requires an additional SC dependency). In all other cases the SLD version should not be changed.


Leave a Reply