Upgrade nw2004 sp16 to nw2004s sp10

[Former Member]

We've created a test JDI system based on nw2004 sp16, and we've upgraded it to nw2004s sp10. The tracks defined in the system all use the nw2004 sp16 build plugins.

My question is this: What are the steps to update the tracks to use the nw2004s sp10 plugins?

I've been hunting for documentation that illustrates the required steps, but so far, I haven't been that successful. My guess is that the SC definition has to be updated to specify the new nw2004s dependencies, followed by checking in the new plugins.

I would very much like to find the SAP suggested procedures for the upgrade. Is there such documentation? Does someone have an idea?

[Former Member · Accepted solution]

Let me add a bit more info:

We have four SC's, each currently under development. One of for WebAS development, one for Portal development, one for externally imported libraries (read: open source), and a fourth as a scratch area for developers to play around in. The scratch area does not have any defined runtime systems, nor does the external library SC. As part of the 2004s upgrade, the DC's installed in each track were deployed to the specified runtime systems as they were upgraded. However, the deployed DC's were compiled against 6.40 libs, not 7.0 libs.

In the SLD, each SC was initially created with a dependancy on the 6.40 versions of the SAP_BUILDT, SAP_JTECHS, and SAP-JEE SC's.

When migrating from nw2004 to nw2004s, do I:

- alter the depenancies in the SLD SC definition for each SC to point at the 7.x versions of the aforementioned SAP* SC's, followed by

- update CMS to pull the SLD data into the DI, then

- check-in the 7.x development SC's, then

- import the SC's into the dev and cons tracks

- possibly force an 'init comparment' to do a complete rebuild

Is that all I have to do, or is this too simple? I'm not worried about maintaining the 6.4 versions of the SC's since we haven't deployed anything into a 6.40 production environment.

Someone <b>must</b> have done this already. If so, please share what you did to migrate between major versions......

[Former Member · Accepted solution]

Hi Ken,

your idea sounds reasonable to me. I have some doubts if the CMS udpate will really work in that way (updating the version of used SCs) or if you have to remove the developed SCs from you track and re-add them to correctly update the version information.

I would rather

- create a new version of your developed SCs in SLD with new dependencies (e.g. you have SC WAS1 Version 1.00 depending on DI BUILD TOOL 6.40, I'd create a Version 2.00 for WAS1 that depends on DI BUILD TOOL 7.00). Maybe there are some new SC dependencies that you need. (EPBC? KM? BASETABLES?)

- define a new track in CMS using the newer versions

- transport all sources from your old track to the new track

- import new 04s/7.00 archives to trigger the rebuild.

That way you have a clean separation of you (test?) track and your new development and you can keep the old track for reference. If you don't care for that your procedure should also work.

Regards,

Marc

[Former Member · Accepted solution]

I think I like your idea better Marc. I'll report back on my findings.

[Former Member · Accepted solution]

Marc, should the second ns2004s specific SC be defined in a new product, or in the same product? I'm having problems getting the track connection to transport the code from the nw2004 track to the ns2004s track. I've defined a new SC in a different product....

[Former Member · Accepted solution]

Marc, now I'm a bit confused by your suggestion.

If I transport one SC to another track, the SC is not available for modifications, is it? When I've linked tracks together before, the DC's contained therein are only made available as active DC's - you can only use them, not modify them.

Am I missing something? I sure wish there was a migration guide out there.

Anyone else done this?

[Former Member · Accepted solution]

Ken, sorry about that. I always had developed SCs defined as "Sources and Archives", I guess you have "Archives" in your original track as CMS then only packs build- and deploy-archives, but you of course need sources to be able to modify the DCs in the new track...

I just rechecked with the documentation and I'm not sure if this really is connected. http://help.sap.com/saphelp_nw2004s/helpdata/en/24/1909dbc6024c8e81951b1e0d646910/frameset.htm

http://help.sap.com/saphelp_nw2004s/helpdata/en/13/602b27f6fb41b4a9eb4f72eabb9832/frameset.htm

The package types documentation does not mention any effect on transport, only shipping while the other package does not mention the package type. I have not tested this extensively, I only know that we used "Source and Archive" and that it did work for transporting sources via track connections.

Same or different product in SLD should be irrelevant as CMS doesn't know about products anyway, only SCs.

[Former Member · Accepted solution]

Well, all of my SC's are defined as Source and Archives, so that's not the issue. I think the track definition is the problem. Here's what I've done:

SC1 is the original SC, and has 6.40 dependencies. Code has been developed here that I want to migrate to 7.00. SC2 is the new SC, and has 7.00 dependencies. No code has been developed here.

I want to migrate the code from SC1 to SC2, thereby changing to 7.00 build libs.

In the track definition for SC2, I'm not sure what I need to do to with respect to dependencies. Do I add SC1 as a 'SC for Development', or as a 'Required SC'? If I drop it into the 'SC for Development' section, I'll end up with a build library conflict, since SC1 requires 6.40 libs, and SC2 requires 7.00 libs. If I place it into the 'Required SC' section, the SC is pulled into the track and can be used to build other code, but I can't make changes since the contained DC's do not show up as Inactive DC's.

As an experiment, I tried placing SC1 into the 'SC for Development' section for the Track for SC2. I was able to do that, and surprisingly, it did not pull in the 6.40 libs. It did, however, remove one of the dependant SC's: SAP_PRT. However, when I tried to save the track, I got this message:

Inconsistent variant mapping. Variant "default" of compartment "sap.com_SAP_BUILDT_1" is mapped to the not existing compartmet "sap.com_SAP_PRT_1"

I'm obviously doing something wrong....

[Former Member · Accepted solution]

Ah, I think I see the problem. I assumed that you are going to use the same SC (regarding name/id) but in another version (or "release" in CMS terms). In SLD you can assign dependencies to a version of an SC , but if you transport from one track to another CMS will basically ignore the version and only use the SC name/id/short name. Thus you can transport sources from one version/release of an SC to another one.

(Compare also this blog including the comments: /people/guenter.schiele/blog/2005/12/21/best-practices-for-running-the-nwdi )

(Personal rant: the terminology in SLD is not the same as in CMS, I found that very confusing in the past. An SC has a "(long) name" and some "technical name" in SLD, but in CMS you usually only see the "technical name" labeled as "name". SLD talks about "version", CMS "release". SLD identifies SCs by name and version, CMS uses only the name.)

If you have SC2 this is something completely different to CMS and since CMS maps by name you will never get your sources directly into this SC. For a source transport to work you need to have SC1 as "SC for development" ("Required SCs" are always archive only). You need to define a SC1 Version/Release 2.00 (with dependencies to 7.00) in SLD and use that instead of SC2.

If you don't want to keep the SC (-name) then the only way to transport the sources is probably to create a completely new track and create propagationlists and integrate thaem using the DTR commandline tool (not a nice solution).

I would guess that the error message you got when you put SC1 in "SC for development" is also caused by CMS ignoring (release-)versions of SCs within a track, thus calculating wrong dependencies.

[Former Member · Accepted solution]

Marc, thank you VERY much. I thought SC dependencies were set at the SC level, not at the SC/version level (although that should have been obvious by the way SC's are created). That's why I was confused, and thought I needed another SC. Creating a similarly named SC with a different version number allowed me to setup a track connection. Once I did an assembly and approved it, the DC's were placed into the import Q of the destination track. I can now transport DC's between versioned SC's, which is exactly what I originally wanted.

If you're ever in the neighborhood, look me up - I'll buy the beer

[Former Member · Accepted solution]

Ah, Canada. Be careful, I might take you up on that offer.

Glad I could help.

[Former Member · Accepted solution]

Dear Marc/Ken

We were reading through your discussion thread. Very intresting might I add. Actually we are planning to try out the same upgrade scenario here at our end. The thread gives us an insight into what difficulties we might face after the upgrade is complete, what we are looking at is a little helping hand for the upgrade process itself. Ken could you please elaborate on this.

Preferably we would like to set up a new NWDI '04s box and then migrate all our developments from NW04 SP16 to this. Reason being, we are currently facing difficulties in the current JDI system. Is there a way we can migrate all our developments from the current JDI '04 SP 16 to the new NWDI 04s?

Thanks in advance

Shobhan

[Former Member · Accepted solution]

Hmm, I'm not sure how you migrate from one physical JDI to another.

We upgraded in place to 04s/sp10. I then created new software component versions (based on the discussion above) which had 04s instead of 04 SC dependancies. I then created new tracks for the new SC's, created a track connection between the 04 and 04s development tracks, and after a build (restore system state?) I was able to import the DC's onto the new tracks, and proceed with development using the 04s libs.

If you really want to move from one system to another, I would suggest searching the notes database, or opening an OSS note.

[Former Member · Accepted solution]

Hi Shobhan,

I have no first-hand experience with an upgrade like that but since Ken successfully upgraded an existing installation maybe a system copy could help? (see note 877029). I'm not sure how else you could copy DTR content including all versions (CMS assembly and import would only copy the latest version of each resource).

On the other hand the NWDI servers are pretty much the same and since you state difficulties in the current JDI system as a reason for the upgrade I'm not sure if an upgrade will really solve your difficulties. What kind of difficulties do you have?

Regards,

Marc

[Former Member · Accepted solution]

Hi Marc/Ken,

Thanks for your inputs. However i guess i need to share some more inputs for better understanding about the issues i am facing and the reason i am going for the upgrade of NWDI.

We Started using JDI for R&D purpose with a minimum h/w. We upgraded the SP level to 16 and started using it for one live project. It was doing good however some how few roles get duplicated and started facing problem using it. So we spotted those duplicated roles and deleted them.

Now the issue is we are not able to create DCs with developer's ID with which we were creating DCs successfully previously. And also we are facing the issue regarding the external jars which is there in SP16.

So we thought of migrating it to a new h/w and NWDI 04s. And the reason why we are not preferring upgrading in the existing system is the issues might persist after it also.

Hope this will clear the idea and you can through some more light on it.

Waiting for your responce

Regards

Shobhan

[Former Member · Accepted solution]

Hi Shobhan,

this sounds a bit shaky to me. I can understand the hardware issues. I am aware of rather consistent problems with external library DCs but as far as I know there was a patch or at least workaround provided for all affected SPs. Permission issues might be most interesting.

As stated already I'm not sure how you can transport the whole content of one DTR to another (system copy?) without getting similar permission issues. Where exactly is the cause of the problem that developers cannot create DCs? DTR permissions, SLD permissions for reserving names, CBS issues for activation? If this was only for R&D purposes so far, can you live with losing file histories? (I.e.: is assembly and reimport with sources sufficient for you?)

Personally I would try to resolve the permissions and build issues before doing the upgrade.

Regards,

Marc