Designing NWDI Tracks

[Former Member]

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

[Former Member · Accepted solution]

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.

[Former Member · Accepted solution]

Chris. I got on a roll there and I'm not sure I totally answered your question.

Your main point was "how to go back to a specific version?" That's why we started creating separate tracks each time we put something in production. As I said, that got to be quite unmanageable.

Unfortunately, we were told by SAP that there was NO way to 'version' an application. Everything is versioned at the object level and even THAT is really not that useful. Who can possibly go through the DTR and get the version of EACH object from a specific date.

No matter how much we pushed, SAP kept coming back with "that's not possible" and even more frustrating they always seemed to say "Why do you want to do that?"

We discussed it here and decided that the overhead of all the tracks wasn't worth it. We were willing to live with the ability to only have two versions (development and current prod) of the app.

Wish there was a better way. If you DO find it please share!

David.

[Former Member · Accepted solution]

David:

Thanks for all the information! I am glad to see that I am not alone

I have also been in contact with someone from SAP that I met at TechED, and this is the answer that they gave to the original question I posted:

<b>The quick answer is yes (to creating multiple development and maintenance tracks), this is exactly how you would setup things if you wanted to save a code line for an earlier version…if I were to be developing a large product that had multiple versions this is exactly what I would do.</b>

Keeping that in mind, it is very beneficial to hear your experiences with maintaining multiple tracks, and with maintenance tracks as well.

When I first brought this up at company, the majority of people were worried about the overhead and administrative effort that it would cause, and your experiences verify that.

One other thought that I would like to throw out to the group........can this type of versioning that I am after also be accomplished by creating new software components?

For example, let's say I keep one track for development as David is doing, called DEVELOPMENT, and I develop SC version 1 in it. After it has moved to production and is stable, I want to develop SC version 2. So I define SC version 2 in the SLD, and make it dependant on SC version 1. In the DEVELOPMENT track, I add SC version 2 to the list of "Software Components for Development," and move SC version 1 down to the list of "Required Software Components."

If I want to "go back to the previous version" of SC version 1, I should still have it in my DEVELOPMENT track to look at, but not to develop.

If by chance I have an emergency fix that I need to put in for SC version 1, I could always create a new, temporary track that lists SC version 1 in "Software Components for Development." After the emergency fix is complete, I could re-import SC version 1 into my DEVELOPMENT track.

This may be administratively challenging as well......but could this be another option that is more straightforward than multiple tracks with track connections?

Thanks!

Chris

[Former Member · Accepted solution]

Chris. We did try the "different software component for each version" option too. I can't remember the details but we scrapped that idea also. Part of it was because it also required Basis to do a lot of extra work.

We came from WebSphere and there the developer could do their own versioning without having to involve some admin group. Our Bais team is short-handed and overworked so they balked at all the overhead.

Also, at some point someone just took a step back and said "Have we ever actually HAD to go back to an old version of the system?" The answer was No. So then it was obvious that, even though it is nice to have the feature, all the extra work just wasn't justifiable.

Of course, then you take a chance that some day in the future you WILL be asked to go back and you won't be able to.

Something we have on our todo list is to test restoring a system using the SCA file(s) that are generated during the transport. Apparently, those ARE versioned somewhere inside the CBS/CMS (I can't ever keep the two straight).

Also, from what I understand and what I've seen when watching the Basis team do transports, there are versions created internally as code is imported into some queue. I know I'm mangling the terminology but the point is that there may be some other options here.

The big problem is that there doesn't seem to be ANYONE who really knows the whole process, understands it, understands this requirement and can analyze it all to come up with a good solution.

If you'd like to share info offline let me know. It's really nice to finally see some other people on here who are going through the same things we are/were. When we started, it seemed that we were all alone. Last year at TechEd I roamed the halls and presentations : ) looking for people in the same situation but it just seemed there weren't any.

David.

[Former Member · Accepted solution]

David:

Thanks again for the information. Our teams have asked a similar question: "Have we ever actually HAD to go back to an old version of the system?" The answer for us as well is no.

Based on your's and Marc's comments, I'm going to recommend that we follow a simple track design, to avoid administrative headaches.

Thanks for your insights. It's nice knowing that others have gone through this as well!

I would be very interested in sharing information offline with you. Whenever you have a chance, please drop me a line at christopher.h.moore@monsanto.com.

Thanks!

[Stefan-EA · Accepted solution]

David,

Our NWDI is on Netweaver 04 SP20 and our tracks are setup according to this blog by <a href="/people/marion.schlotte/blog/2006/03/30/best-practices-for-nwdi-track-design-for-ongoing-development Schlotte</a>

Whenever we make a change in the maintenance track, an equivalent activity will show up in our development track under the Development tab. We then have the choice of importing the activity or rejecting it. If the activity is accepted, and then consolidated(Consolidation tab), an integration conflict will occur in the NWDS, which you can see in the DTR Perspective under the Integration Conflict view. You then can accept the active or current version or merge them.

>

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

>

[Stefan-EA · Accepted solution]

David,

I was at the last two Tech Eds in Las Vegas and did not meet anyone

doing pure custom development with J2EE, Web DynPro and the NWDI either.

The only Java developers I met were customizing ESS/MSS.

If you get a chance, please send me an email (Click on my user name to access my business card)

Thanks,

Stefan

> If you'd like to share info offline let me know. It's

> really nice to finally see some other people on here

> who are going through the same things we are/were.

> When we started, it seemed that we were all alone.

> Last year at TechEd I roamed the halls and

> presentations : ) looking for people in the same

> situation but it just seemed there weren't any.

>

> David.

[Former Member · Accepted solution]

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.

[Stefan-EA · Accepted solution]

David,

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

<a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e0f341af-e86e-2910-3e8a-d9e3c227d938">CMS</a>.

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.

[Former Member]

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)://<fqdn>:<port>/webdynpro/dispatcher/sap.com/tc_SLCMS~tsawebui/CmsTrackAuthority

Cheers,

Nico...

[Former Member]

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.

[Former Member]

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-cba52... [original link is broken]

reward point if helpful.

thanks

mrutyun^

[Former Member]

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

[Former Member]

Hi Marc.

Thanks for your reply.

The idea would be that development in "Development Track 1" would end after it has been released. "Development Track 1" would then only serve as a historical version of what code was implemented for "Development Track 1."

You're right....we would really not need to revert to a version that was implemented years ago. I am looking at this from an ABAP developer's perspective, so that is probably part of my problem

Let me explain:

In ABAP, if I am looking at a program, I can go to version management and get a list of all versions that have been created. I can then select a previous version, and look at the code that it implemented. It's very very rare to have to restore a previous version....but it is nice to be able to look at the differences between versions.....especially when working on a team with a large number of developers, to see what was implemented when and by whom.

I am trying to determine if this is also possible with NWDI. I know that versions are kept in the DTR, but because Web Dynpro for Java is broken down into individual files, and these are what are versioned, it could be very difficult to piece together what an application looked like in the past.

I hope that this clarifies what I am after.

Chris

[Former Member]

Hi Chris,

Regarding the multiple development tracks: I can understand your point about "going back", but I would assume that at the end of development there would be no difference between your DevTrack N and Maintenance Track N, i.e. you could always import the development configuration for the Maintenance Track into your developer studio and compare sources there.

If you move development to a completely new track you have to:

- create the new development track

- import everything from the old track into the new track

- have each and every developer import a new development configuration and stop using the old one

From an administrative point of view I regard that as dangerous. How do you ensure that really nobody keeps developing in the then outdated track? ACLs are one thing, but again you add some overhead. (Or developers have to manually maintain or at least integrate changes from one DevTrack into another).

Regarding going back to older versions: As mentioned above I would use the Maintenance configurations as (read-only) reference for the released versions. A not very comfortable other way is to use the DTR perspective in the NWDS and to sync sources to a specific date. There's no "Version" or at least "Label" so that one can easily identify a specific version, but maybe the revision history on some specific file combined with sync to date is sufficient.

I found one hint in the new CE documentation ( http://help.sap.com/saphelp_nwce10/helpdata/en/45/5c5fd5eedd2f95e10000000a155369/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.

Regards,

Marc

[Former Member]

Hi Marc.

That is a good point....the trick to this type of setup would be to "lock out" developers from using the previous tracks for development. Having said that, I'm not sure how one could allow developers to view a previous track, but not use it for development. Maybe the ACLs, as you mentioned, could help with this....but this is getting complicated quickly

Thanks for the information on the "fusion" feature. Hopefully this will pan out whenever we migrate to CE.

Based on the responses I've received so far, I am leaning towards as few tracks as possible, to prevent administrative trouble. The ability to quickly go back to a previous version of an application may just simply not be there in NWDI.

One other question for you....did you see my question in this thread on creating new software components? Could this be an alternative to creating multiple tracks, but still accomplishing the "versioning" that I am after?

Thanks,

Chris

[Former Member]

Hi Chris,

yes, that's a sore point: DTR has really fine-grained ACLs, but there's just no user management as part of NWDI that allows sensible administration... Anyway I think that giving a simple scenario to developers (and enough work to do) automatically keeps them from doing things in old/wrong tracks.

I agree with David that having new software components is not a good solution here. I'm not even sure if CMS can handle the same SC in two different versions in the same track, then as required SC you would not have sources for the old version in the same track and if you had you would probably have duplicate DCs in the same track which cannot help either (even if it is possible, which I doubt. SC Aliases were once at least intended for that purpose but I've never seen them used anywhere).

Anyway I'm surprised that SAP actually recommended having multiple development tracks . To me this goes against having as few tracks as possible. Especially since a track in turn contains a development system and then cons/approval for delivery. So you have two levels of granularity to fit your needs, but best practise and usage blogs here on SDN and what I've seen and heard from others the "track"-granularity is almost universally used and nobody ever really uses the cons-Development configuration in the studio.

Regards,

Marc

[Former Member]

Marc:

Thanks for all of the information you've given me. As I mentioned in my response to David, I am recommending to our teams that we follow a simple track design, based on your and David's feedback.

The administrative hassle and overhead of multiple tracks doesn't seem to be worth the extra "versioning" that we will most likely never use.

Thanks again!

Chris

[Stefan-EA]

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.