Maximum number of DCs in a single track?

[Former Member]

Hello!

I have a question about how many DCs are considered "OK" to have in a single track.

We are currently using 7 tracks in the NWDI for development and one for maintainance. Three of the tracks contains supporting components that are used by other DCs in the remaining four tracks that contains the applications used by the customer. We have set up transport track connections from the support tracks to the application tracks.

We are considering moving all DCs to the same track to create a less complex landscape without the dependencies.

I realize that build time for the SC would go up as well as the time for importing into different runtime systems would be longer, but I would save some time not having to import the supporting tracks. (The largest track is 33MB and takes a few minutes to build and import).

In total we are using 80-100 DCs, and the total size of all the deployed SCs is around 100MB. Would it be a problem to have all this in the same track?

Is there any reason we shouldn't do this migration?

Sincerely,

Richard Linnander

Edited by: Richard Linnander on Mar 20, 2008 11:08 AM

[Former Member · Accepted solution]

There would not be a problem to have that many in a track.

7 tracks is not that many, especially in landscapes where there are more than 4 systems and I do not imagine the complexity between them is that much.

Things like restoring system states happen less often now but they will take longer when they do occur. Tis also means Synching will take longer afterward.

I imagine security is not an issue for you to consiuder this.

If the SC's you develop could have different target systems in the future I would keep them seperate.

If the SC's you develop could end up on different releases I would keep them seperate.

If a subset of SC's could end up being develpoped by a satellite it may be worth keeping separate.

I don't imagine multiple variants would cause any future issues (just trying to cover everything)

In my view, if the reason you are merging is just because of sc archive imports into tracks being a pain then I would not until I had about 15 tracks.

Hopefully you are up to speed with the value of CTS+ also

[Former Member · Accepted solution]

Hi Graham!

Thanks for your reply.

I would like to explain what our problems are so that you understand why we want to have as few tracks as possible. Maybe there is another fix for our problem.

Lets say track A contains a class for formatting telephone numbers. A has a transport connection to tracks B,C and D.

If I change the class I need to forward it to B,C and D.

That is annoying if we are making several changes, but the real problem is that sometimes the changes doesnt show up in B,C and D.

If I create a new class for formatting social security numbers and forward track A to B and import it in development, consolidation, assembly and test I still cannot use it in my web dynpro DC in B. I have tried sync used DCs, reload, rebuild, delete the local files and read them again from DTR, even reimporting the configuration.

Nothing helps. After a while we do the necessary formatting directly in the DC, thus loosing the benefit of having the same formatting rules in every DC.

Is there a way to work with shared classes/DCs so that we dont need to forward tracks at all?

We are using NW2004 sp19, so I dont think CTS+ is an option for us.

Thanks for your help!

[Former Member · Accepted solution]

As long as all your SC's have the same target runtime systems, you can safely move all your current SC's into one track. This should at least resolve your track forwarding issue.

[Former Member · Accepted solution]

You can also do a back connection. This will allow DC's released from Dev to go to the other track instead of a Transport connection that means the entire SC is forwarded only after Test.

It worries me that the change does no show up. The manifest in the SCA should show the correct version. Perhaps you are assuming that a release from dev will send it on while it must be after assembly and QA..... something like that.

Anyway, back to the question, merge em if you want, it seems like the most elegant solution.... just trying to give alternatives.

You do have to wonder though as merging dependent developments will increase the risk of incompatibilities... you have 4 seperate SC's for your developments.... You sure they should not all have been one in the first place

[Former Member · Accepted solution]

Why are we using several tracks for development? Its for historical reasons. This has been a long running project, about three years.

I dont know the reasoning behind the track setup but currently there is a track for each core business process, as well as the supporting tracks containing shared components.

The project is over now and the product is in a maintainance life cycle and I am therefore trying to simplify future development.

There is a possibility of different future production runtime systems (external web and internal), but the current structure doesn't support it either. We figured we might as well transport everything to both systems then and just disable the components that shouldn't be running.

A compromise would be to merge all support tracks to one and have one track for external and internal components respectivley. This would probably not help with my second problem where changes doesnt show up.

I have been thinking of using a repair connection, but I haven't yet had time to play with it.

Thanks for your replies, I am marking this question as answered now, but feel free to reply anyway

*Update: I had forgotten to add a public part entity for the new class, thats why I couldn't use it after the transport

Edited by: Richard Linnander on Mar 26, 2008 5:16 PM