Setup of 'compare' track in NWDI Landscape Configurator

[Matt_Fraser]

I've been using NWDI to manage customizations to ESS for several years now, but I still have some nagging questions about the best way to configure tracks for support packs, etc.  Yes, I've read the "NWDI for ESS" cookbook (not updated since 2007), and Marion Schlotte's (hope I got her name right) and others' excellent blog posts of a few years ago, and I've incorporated all of those concepts into our track design, and they work.

My real question is about some best practices, especially with regard to the "compare" tracks used during support pack application and re-application of customizations.  The compare track has no runtime systems, contains no modifications or customizations; it contains only original SAP-delivered SC's which the developers can then use for metadata compare against our old development track and against the new track with new support packs, and thus isolate where we've made changes, as well as where the support packs introduce changes, and thus decide how best to reintegrate our changes on top of the new support packs.

In this compare track, in the Landscape Configurator, what options do you normally use?  Do you include "Source and Archives" for package type, or only "Source"?  Do you need to include components for modification at all?  Or can you leave those out and just check-in and import the SCA's delivered by SAP?  Since it takes so long to import SCs into each track, it's difficult to find time to experiment with different settings to see if they work, and given that we're always under a time crunch, we just forge ahead with "tried and true," i.e. whatever we've done before, knowing that it's possible it's not the most efficient way to go.

Looking forward to opinions and advice.

Best regards,

Matt

[ErvinSzolke · Accepted solution]

by the way, I can also see now that the question is not in the NWDI forum but in Java Development. I am not moderator in that forum but I'll ask someone to move this thread to us (nwdi)

could you please move this thread to NWDI space (http://scn.sap.com/community/nwdi) ? Thank you!

[Matt_Fraser · Accepted solution]

Thanks, Ervin!

When I first posted the question, either the NWDI forum didn't exist, or I was not able to find it, so I picked the next closest available. Anyway, I see it is moved now, so I appreciate that!

I'll have to dig to find the links for the various blogs now, as this is a year-old question. Still, what I was really interested in was, what do other people do, as a best practice, in their own environments?

Regards,

Matt

[ErvinSzolke · Accepted solution]

Hi Matt,

the NWDI forum exists since 2005

Anyway, most likely these are the resources you checked so far:

Maintenance of an NWDI-Driven System Landscape - Using Java - SAP Library

#872892 - JDI/NWDI Cookbook for ESS/XSS

(fyi I wrote a more up-to-date on this topic here )

The concept of "compare-track" is new to me, is there any resource where you read about this, or this is only how you name it ?

I still try to understand the situation (perhaps if you could mention a concrete example) and if I can't answer, don't worry, I can involve my colleagues from development if necessary.

Cheers,

Ervin

[Matt_Fraser · Accepted solution]

Thanks, Ervin. Yes, those are the links I was referring to.

By "compare track" I meant the track(s) created in step 4.2 of the NWDI for ESS/MSS cookbook from Note 872892. These are the tracks that have no runtime systems associated with them; they just contain either the pure ESS/MSS components delivered by SAP, or the customer-modified components prior to application of support packs, for purposes of comparing in NWDS to differentiate custom vs standard code, and what was delivered in the new support pack being applied. They aren't otherwise used, as developers don't upload their modifications or developments to them, and modifications or support packs are not migrated to downstream systems (QAS, PRD, etc) via them. I guess we just got so used to calling these "compare tracks" in my shop that I forgot this isn't standard terminology.

So, the concrete example is pretty much exactly as described in the cookbook. In our case, for instance, we have made some minor modifications to the ESS component. We are currently on ERP 6.0 EhP4 sps13, so as an example here is the way we handled moving from sps10 to sps13.

We had an 'active' track called 604.10 to which our runtime systems were connected, and in which our modifications existed. This track contained SAP_ESS as modified by us, plus SAP_MSS (unmodified today, but was at the time), SAPPCUI_GP, etc etc -- the usual prerequisites. Prior to importing sps13, we created two parallel tracks, 604.10c and 604.13. In 604.10c (c for 'compare') we imported the sps10 versions of the components, but no modifications. In 604.13 we migrated the runtime systems and imported the sps13 versions of the components (first only to DEV, of course). Then our developer could compare the versions of the components between the three tracks: 604.10c with 604.13 to see what sps13 delivered, and 604.10c with 604.10 to see what we had modified, and reapply the modifications to 604.13.

All pretty standard, although we use one fewer compare track than the cookbook suggests, as it seemed to us that there was a completely redundant track being recommended.

The problem was that, even without runtime systems, importing all those components to each track in NWDI was very time-consuming, taking many, many hours. Obviously, anything we could do to optimize that process would be desirable. As we only had one Java developer working on it, we couldn't justify huge amounts of hardware resources for NWDI (we are about to migrate it to newer hardware now, which should help).

So, today, in the Landscape Configurator, we have the 604.13 track (our 'active' track with runtime systems and modifications), defined as having SAP_ESS and SAP_MSS in the list of "developed software components." The package type for each is "Source and Archive" and the "Developed" box is checked. MSS is in there because we used to have modifications in this component, too, but we have since dropped those. It's not clear to me right now if I need to keep this in future tracks or can simply let JSPM (or SUM) handle it without NWDI.

So, next time we apply support packs (likely this summer), when I set up a 604.13c (or 'compare') track, which will have no runtime systems and no modifications, should I still choose "Source and Archive" for package type? Or would "Source" be a better and more efficient option? And do I need to mark the "Developed" checkbox, or should I leave it unchecked? As SAP_ESS is a huge component that takes many hours to import all by itself, I don't really have a lot of luxury for experimenting with different options, so that is why I hoped that someone else would be able to suggest (with some authority of experience) a best practice for this.

Hmm, now that I look back at this and my original post, I'm not sure I've stated the question much differently, but hopefully the extra detail of the example of how we use the tracks will help clarify the situation.

By the way, your updated "NWDI vs NWDI Content" blog post was new to me (I had seen Marion's older JDI version in the past), and is very helpful. Thank you!

Regards,

Matt

[ErvinSzolke · Accepted solution]

Hi Matt,

the option ‘Source and Archive’ applies to the assembly of this SC.

Either setting will do (for the ‘compare track’ where no assembly is done), but there will also be no benefit of one over the other. In contrast, the ‘Developed’-flag needs to be set, since for the comparison the sources need to be imported.

As per your description I assume you don't need RTSs, and consolidation import, since no development will take place in these compare tracks (even the "development system only" option could be set in CMS). You only use the track as "source" storage of SAP delivered SPs for comparison with other tracks. This means you can import only the sources, no need to import required archives (a.k.a build archives / a.k.a build plugins / a.k.a dependent SCs) with the long running builds.

Source compare should be possible even if only the sources are imported. To exclude archives from the import either do not check them in (I mean here CMS' check-in feature in Transport Studio) for the compare track, or if you do so, then do not import them. You could even remove the dependency in SC settings in track data but that would lead just to extra overhead and would confuse you by displaying the track in yellow because CMS Track config would be suddenly out of sync with SLD.

So as a summary for source comparison I suggest to:

Import only the Source SCs into the Development space of the compare track (no need for cons import, no need for RTSs).

Sidenote:

Most likely in your case the bad performance is due to old hardware, a couple of years back the ESS import indeed frequently took several hours, but today normally it takes only roughly half an hour. The DTR performance reflects the performance of the DB, so what might help is if you update DB statistics time to time.

I hope this helps.

Best Regards,

Ervin

[Matt_Fraser · Accepted solution]

Thanks, Ervin, this is really helpful.

Ok, to summarize, for the 'compare' track, marked 'development system only' and with no RTS, I should still tick the 'Developed' flag, but can set the Package Type to 'Source' instead of 'Source and Archive.' In the past I have also checked 'Exclude from Deployment' as, after all, nothing is being deployed in this track (no RTS).

I'm a little confused about your statement of not checking in or importing the components to the 'compare' track ('Development' system only) in the Transport Studio, as I understood this to be a requirement (the ESS/MSS cookbook specifically states to import the components into the compare track, if I recall correctly). I'm not quite sure how NWDS can do the compare between tracks if the sources aren't present in both tracks. However, I think this is probably a minor point. My main question is answered.

We are migrating NWDI onto new hardware this spring, so that will happen before our next round of support packs. I do expect that to make a big difference, as the new hardware is considerably more powerful than the old.

Thanks again!

--Matt

[ErvinSzolke · Accepted solution]

Hi Matt,

yes, "Developed" flag has to be used, "Source" or "Source and Archive" does not count in your case , "Development System Only" is not a must either, it was just a sidenote. No need for RTSs, "Exclude from deployment" does not matter either, since no deployment will take place here, we did not even added RTSs as just mentioned.a

Regarding SCs: there are three type of them. SOURCEARCHIVES, DEPLOYARCHIVES and BUILDARCHIVES.

If you open any SCAs (they are just zip-like archives) then you'll see these 3 folders (or various combinations of them, depends on what the SC is meant for).

What you have to make sure for source comparison is that you import the SCs that have sources (folder SOURCEARCHIVES) and you just ignore the rest of the SCs. This way the time invested into import is minimized, and you don't need to wait for builds. You use the track only for source comparison anyway.

Cheers,

Ervin

[ErvinSzolke · Accepted solution]

by the way only for the record, many thanks for and who where helping me in this.

[ErvinSzolke]

Hi Matt,

could you please refer all the guides (links) and notes you were checking regarding this topic?

Thank you and Regards,

Ervin