Structuring tracks to support a complex landscape

[Former Member]

We are in the process of installing portal environments for our nw70 BI systems. We already have a set of portal environments that hosts non-BI content. As part of the initial setup, some portal components were developed, and hosted in the DI. Now, with the addition of the additional BI portal environments, I could conceivably have 14 portal environments that require deployments from the DI for a single software component.

With the current track configuration, I can have a maximum of 4 runtime systems associated with a single track.

So, I'm left with having at least four tracks so I can encompass all the portal environments; however, I only want one track to be able to perform development. Can I structure the follow-on tracks in such a way so that development is not possible, yet the archives can be imported to each runtime system?

I've read the blogs regarding track structures, but they don't go into detail on how to support a landscape like this - they're simpler, where you always have a dev, cons, test and production as part of your landscape. Well, in our case, we have two sandboxes, a development, two product qa's, a test, and a production environment.

Some advice would be appreciated.

[Former Member]

You can indeed use follow-up tracks to deploy to more than 4 runtime systems. All you need to do is add your developed software components into the Required Software Components table (the bottom one) of the track definition. Make sure you turn OFF the 'Exclude for deployment' option. What remains are the transport and repair connections between your tracks.

PS. Is there a special to setup a separate portal landscape for the BI systems? Why don't you incorporate that into your existing Portal landscape?

[Former Member]

Thanks for the info Pascal. I'm not sure what you mean by this statement, however:

What remains are the transport and repair connections between your tracks.

Transport connections make sense, but I don't think there would be any repair connections, since the development would take place in the 'source' track. Or, are you referring to something else?

Regarding the BI landscape, we're looking at implementing a federated portal network, since we want to segregate the various bits of content into their own portal. There are various reasons for doing this, such as:

- loose coupling of portals, which means that patching becomes easier

- offload high-load content to it's own portal

Also, SAP states that BI and the associated BI portal must be at the same SP level. This dependency can cause all sorts of grief when you're trying to upgrade your landscape, so it seems (to us, anyways) that it's best to treat BI and the BI portal as one 'system'. This way, it lessens the impact on the rest of the landscape.

There are downsides, of course - you increase the number of portals in your landscape, for one

[Former Member]

Couple of other questions

When I setup the follow-on tracks, do I add the components as an 'Archive' only dependency? I only want to do development on the 'source' track...

If the SC is added as 'Archive' only, will this work for deployments to the development system?

For a production deployment track for another SC, we've configured it without a DTR or CBS URL, since it's only used for deployment to a production system. Do I do the same thing for these tracks, where I'll be deploying to each stage (D,C,T, and P) in the track?

[Former Member]

About the repair connections: Depending on your track setup you may need these. If you setup a separate track for every runtime system, you may want to have a repair connection from the second to the first track for example.

Thanks for the landscape clarification. Those are some good reasons to go for this setup. But how Johan Cruijf always puts it: "Every advantage has a disadvantage".

[Former Member]

What version of NWDI are you using, since I don't see the "Archive only" option in our 2004s NWDI. We've got "Exclude for deployment" which in your case should of course be turned off for your own SCs (but on for the base SCs).

You only need the CBS and DTR URLs if you have SCs added to the top SC table of the track definition.

[timo_renner]

Hi Ken,

what Pascal forgot to mention:

When using a NWDI Track only for transports then you better do not use DTR and CBS. Means: when creating the tracks for transports, leave the URL for DTR and CBS blank.

If there is no DTR, no source code is available in this track. Another (positive) effect is that without DTR/CBS, there is no more (unnecessary) build performed for your SCs, so it will only deploy the SCAs.

Best regards,

Timo