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
