Skip to Content

Netweaver upgrade 7.4 to 7.5 - Effect on NWDI tracks


We are upgrading NW system which is used for NWDI(CMS, tracks, DTR, etc.).

The upgrade is going to be a live upgrade. No migration or system copy involved.

There are many tracks with different Java Runtimes. Mostly Java 1.6. The connected run time systems will not be upgraded. The NW system is used only for NWDI and not hosting applications.

Since NW 7.5 is based on Java 1.8, Will the upgrade cause any effect on the tracks which are already present?

Can the tracks be used as such the day after the upgrade? What remediation activities are involved?



Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

1 Answer

  • Best Answer
    May 06 at 03:38 PM

    Hello Bhaskar,

    You can absolutely upgrade your NWDI to 7.5, but in order to keep tracks associated with older systems that require a downlevel JDK, you do need to make a few configuration adjustments.

    NWDI itself, once on NW 7.5, will require JDK 1.8, as you pointed out, so that needs to exist in the normal location (i.e. \usr\sap\<SID>\SYS\exe\jvm\<platform>\ The upgrade itself should take care of that, and the regular SAPCPE process will replicate it to the Jxx instances.

    You also need to provide the downlevel JDK to support the tracks, so that has to be somewhere on your server's filesystem, perhaps in its own path such as E:\sapjvm6.

    Then, in NetWeaver Administrator, navigate to Configuration -> Infrastructure -> Java System Properties. Expand the top-level (probably ZATPL_AIO) template to find your instance (i.e. IDxxxxx). In the details, choose the Services tab, and select the Component Build Service (aka tc.CBS.Service). In the properties for the service, find property JDK_HOME_PATHS, and modify it to a custom value that includes both your JVM 1.6 and JVM 1.8 paths, i.e. something like this:


    Save that, and launch your CMS. Navigate into the Landscape Configurator. Select your track that requires JDK 1.6, and in Track Data choose the Build Variants tab. Add a build variant under the default called and set its value to JDK6.1_HOME.

    Now, any components you build in the CBS for that track should use the JDK 1.6. Any for which you don't specify such a build variant should use the NWDI's default JDK, which will now be 1.8. And NWDI itself will use 1.8 to run.


    Add comment
    10|10000 characters needed characters exceeded

    • Bhaskar B ,

      You shouldn't have to do anything else with regard to your custom components. The prerequisite components you include in the track depend upon the release of the runtime system the tracks represent, not the release of the NWDI. So, as best practice, your NWDI should always be on a release and sp level as high as the highest of whatever you're building for, but even that is not necessarily an absolute requirement. Just a very good idea.

      From the developer side, there is an additional requirement. Your developers will need to install NWDS in a version and sp level that matches your NWDI, so they will have to upgrade their clients. Your developers do still need to keep SAPJVM versions on their workstations that match the JDK of the tracks they're building for, so they may potentially need multiple SAPJVMs installed, and NWDS configured appropriately to call the right ones for the right projects.

      When we upgraded our NWDI from 7.01 to 7.5 a few years ago, I got some mild complaining from our developers because the look and feel and basic layout of the NWDS changed from what they were used to. It took them a little while to get used to the new layout of the tool, but after a while they did and the complaints stopped. That's normal for any upgrade, really; end users always complain when you change something, and in the case of NWDI, the developers are your end users. :) One of the arguments I used with them was that this new layout was similar to how their ABAP work would be in a few years when they switched to ABAP in Eclipse instead of using the ABAP Workbench. I pointed out that many developers in the community seemed to feel this was an improvement, but my developers didn't really agree. What can I say, we're kind of old school in our shop.