Skip to Content
avatar image
Former Member

Designing NWDI Tracks

We are just getting started with NWDI, and are considering how to design our tracks. The majority of our custom development will be in Web Dynpro for Java. My question is on how many tracks to create over the lifecycle of a piece of software.

For example, let’s say that you have developed a Web Dynpro for Java application, and expect its total useful life to be 3 years, with a major release of changes every year, and bug fixes occurring frequently throughout its lifecycle.

Would you create tracks such as follows?

<u>Year 1:</u>

Development Track 1

Maintenance Track 1 (repair track connection to Development Track 1)

<u>Year 2:</u>

Development Track 2 (track connection from Development Track 1)

Maintenance Track 2 (repair track connection to Development Track 2)

<u>Year 3:</u>

Development Track 3 (track connection from Development Track 2)

Maintenance Track 3 (repair track connection to Development Track 3)

This (I think) would create a version of the delivered code for each major release in the Development Tracks, and allow for parallel development for bug fixes in the Maintenance Tracks….but I’m not sure if this is overkill.

Ideally what we want is an easy way to go back to a previous version of a piece of software if we have to, without having to dig through the DTR and revert changes at the file level.

Does anyone have a way to do this?

Thanks in advance,

Chris

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

5 Answers

  • Best Answer
    avatar image
    Former Member
    Oct 10, 2007 at 03:20 PM

    Chris. Oh man, I feel your pain! This brings back memories of when we started with Netweaver and NWDI.

    We had sooo many conversations with various SAP consultants and even spoke to the NWDI development team in Germany.

    One of the big issues we had was "how do we go back to a previous version of the system?" Amazingly, SAP never really seemed to grasp the importance of that. My impression was that they felt that you never go back. If you have a problem you fix it and go forward.a

    After much, much discussion we finally decided to try the one track per business unit and a separate track for each version. This was reviewed by SAP and they thought it was OK but it quickly got out of hand. As you can imagine, the number of tracks was unmanageable and caused all kinds of problems for our Basis team and our common code developers.

    Our next approach was to put all the Software Components in one track and have one development and one maintenance track with a repair connection between the two.

    At first, the repair connection concept seemed ideal. However, we soon realized that we didn't like the lack of control we had in the development track. Some of the details are fuzzy to me now because this happened awhile ago but I do remember that changes from the maintenance track would just be incorporated into the development track without any kind of warning to the developer.

    For example, we were worried about a situation where development had been ongoing for quite some time in the developjment track. Then a production bug would be discovered and fixed in maintenance track. This would cause the repair connection to update development track's code. However, the fix wasn't necessarily how we wanted to proceed longterm in the development track.

    What we had hoped for was that we would get some kind of prompt that there were changes available from repair connection and then have the ability to accept or reject them one at a time.

    So we ended up removing the repair connection. The downside of this is that we have to manually make the same change(s) to the development track when a production bug is fixed in the maintenance track. This use case is not frequent and we were willing to live with it so that we would have more control of our code.

    Sorry for the book. Hope this helps.

    David.

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      David,

      Take a look at this document for setting up different roles for the

      CMSwww.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e0f341af-e86e-2910-3e8a-d9e3c227d938">CMS>.

      Maybe you can get a lead developer to be assigned a role of Transport Manager to occasionally manage the activities between tracks?

      I saw a session at Tech Ed on NWDI SP 13 and you can now define permissions at the track level. This may be useful to restrict access and allow only certain actions that a

      lead developer may perform.

      > Stefan, I could be wrong but the ability to do what

      > you're describing requires special kind of security

      > rights in the CBS/CMS (can't remember which).

      >

      > In our installation only Basis team has the ability

      > to do that. Unfortunately, our Basis team is way over

      > worked and there were a lot of issues trying to get

      > all this done with a developer trying to instruct

      > Basis which to accept or reject. Also, in some cases

      > Basis would just accept all the items in Development

      > without asking.

      >

      > Then the developer wouldn't even know that something

      > had changed.

      >

      > If there was some way that a developer could do this

      > but without having all the Admin access it would be a

      > nice feature. THere may be a way TO do that but it

      > just didn't seem to be a big enough priority to

      > assign a Basis person to spend time researching it.

  • avatar image
    Former Member
    Oct 10, 2007 at 07:49 AM

    Hi Chris,

    are you really developing in "Development Track 1" after that year's release?

    I would only use multiple development tracks if you want are different target releases. If there is some continuous development I would keep development in one track and only create maintenance tracks after your product has been released.

    With "go back to a previous version" you really mean reverting (potentially multiple) changes that were done in the past? I don't think there is an easier way with the current tools, but it also sounds like an awful waste of effort to me. How could those (obviously troublesome) changes make it into the product at all?

    Regards,

    Marc

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      I saw this presented at Tech Ed and it is available starting with NWDS 7.0 SP 13, but only under CE (CE uses the 7.0 NWDI ).

      >

      > I found one hint in the new CE documentation (

      > http://help.sap.com/saphelp_nwce10/helpdata/en/45/5c5f

      > d5eedd2f95e10000000a155369/content.htm ) where the

      > glossary defines a "fusion" which sounds much better

      > suited for such a purpose (having 1 version for

      > multiple files within the same folder). But of course

      > this probably doesn't help with "legacy" code and I

      > don't see that concept anywhere else.

  • avatar image
    Former Member
    Oct 10, 2007 at 01:21 PM

    hi

    good

    go through this link ,hope this would helpful for you.

    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/webcontent/uuid/f6eb8e9e-0901-0010-8abb-cba5279db9b6 [original link is broken]

    reward point if helpful.

    thanks

    mrutyun^

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Nov 09, 2007 at 10:14 PM

    The reason Chris has multiple tracks is that he has about 8 systems in his landscape including 2 development tracks.

    The reasons Basis normally does not get involved is that most Basis people do not have the experience and appear to balk at the chance which I find strange being a Basis person and sadly like NWDI for all its sluggishness.

    As for track design in the future I think you will find that NWDI systems will consist on 1 track for each development environment in a landscape if you want to ensure consistency. However the advent of CTS+ now makes life of transporting past Assembly in NWDI a thing of the past and STMS will be used.

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Dec 10, 2007 at 11:15 AM

    Hi Stefan,

    just to let you know, the setting permissions on track level was already available before SP13 (at least already on NW 7.0 SP10). However, at SP13 they found out that it would be handy to create an link for it :S). If you want to reach the permission settings of an track on a system before SP13 just open the URL:

    http(s):// : /webdynpro/dispatcher/ sap.com/tc SLCMS~tsawebui/CmsTrackAuthority

    Cheers,

    Nico...

    Add comment
    10|10000 characters needed characters exceeded