Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert


Very often customers are confused regarding the Release and SP version of NWDS, Local AS (local test server), NWDI, SLD and the Runtime Systems. This blog intends to clarify how to deal with versions.

Big Picture

I am going to start with an abstract picture so at this point we are only talking about versions (VER) and then I detail the Release version and the SP version as we proceed.

Basic Rules

  1. the version of the following components have to match to each other:
    - NWDS
    - Local AS (optional but if it is used it also has to match regarding its version)
    - Track
    - RunTime Systems (further referred as RTSs)
  2. NWDI itself can have any version (there are couple of exceptions see below).
  3. SLD is not part of NWDI, but it is part of each NWDI scenarios; its version can be any

Details on the Versions

A version stands of a Release , SP and Patch Level.
Release  can be at the moment 700, 701, 702, 710,711, 720, 730, 731, 740 and 750. (for the sake of completeness: for 640 even the extended maintenance has ended i.e. this release is not supported any more).
SP version can be any number say SP1, SP2… SP<N>.
Patch Level does not need to be considered in this scenario, it can be any version.

How to find the versions ?

You find it in NWDS – Menu -- Help – About.
Local AS, SLD, NWDI, RTSs:
on releases 640/70X: http://<host>:<port>/monitoring/ComponentInfo
on releases >=710: Check the “Components” tab of http://<host>:<port>/nwa/sysinfo

This version means Release 730 SP5 Patch Level

Further rules

General rules on Release and SP versions
  • The Release always has to match as described in the Basic Rules.
    Example: if NWDS release is 720, then the Track and the RTSs have to be 720 as well, and vica  versa, if you have a 720 RTS, then it determines the NWDS version as well as the Track’s, RTS’. This is important to keep in mind if you plan upgrading the RTSs, then consequently you need to update the track and eventually the NWDS. See more below at "Upgrade related rules".
  • The SP version of the NWDS, Local AS, Track and RTSs has to be also the same.
NWDS specific rules:
  • NWDS also has to match regarding Release and SP especially when it comes to modeling tools like WebDynpro Java (see also note 718949 ) or BPM (in case of bpm it is recommended to keep even the patch level in sync).
  • If there are 2 tracks with different releases (and SP), then consequently 2 separate NWDS instances have to be used on client side.
    Example1:  TrackA is 702, TrackB is 720. On client side this case we need to have two separate NWDS installations one for 702 development and another one for 720.
    Example2: TrackA is 730 SP1 while TrackB is 730 SP2. The official recommendation is to have two separate NWDS installations serving development for TrackA and TrackB.
  • Exceptions:
    • There is no dedicated NWDS 7.40, the NWDS 7.31 is also to be used for NW 7.40 (see also the note 1791485).
    • For NW server 7.40 SP<X> one has to use NWDS 7.31 SP<X+5>.

Track specific rules:
  • When we talk about the version of the Track, we mean the version of the Build Plugins (a.k.a. Dependent SCs, Required SCs).
    The version of the Build Plugins in the same track have to match exactly to each other, i.e. it is not allowed that SAP_BUILDT is 730 SP1 while WD-RUNTIME is 730 SP2.

Example: A Track setup might look as follows:
MYSC 1.0
In this example MYSC is a custom Software Component (further: SC)  which has 4 build plugins where each of them are on the same Release 730 and SP 1.

RTS specific rule:

  • The RTSs are optional, but if they are available they have to have the exact same version, i.e. it is not allowed that DEV has a different version than say CONS, etc. When you upgrade for instance DEV, then of course temprarily it'll differ from the version of the rest of the RTSs, but when using it productively make sure they match to each other regarding their Release and SP. See more below at "Upgrade related rules".

NWDI specific rules:

  • When we talk about NWDI we mean the software components DI_CMS, DI_CBS, DI_DTR of the J2EE Engine where NWDI resides.
    As discussed above NWDI is a framework and normally it can serve any developments, so if the above 3 SCs are on 720 SP1, it does not mean that it can differ from the version of the rest of the SCs on the same engine. It only means it does not need to match to the NWDS, Track, and RTS versions.

    If we develop for 640 or 70X then Software Deployment Manager (further: SDM)  has to be used as deployer when we configure the RTSs. If we develop for >= 710 then the Deploy Controller has to be used. Lower versions of NWDI like any 640 and versions lower than 700 SP15 only knew SDM and that time the Deploy Controller was not known. We learnt that we can use any NWDI version, so we might think we can use a 640 NWDI to develop for 740, but this is not true, since older NWDI releases have no functionality to deploy using the deploy controller.

    Other restriction is that there is no NWDI version available for 710 so if you consider introducing NWDI at your company then make sure the engine where you install it is not 710. When you introduce NWDI it is recommended to use a recent version like 730 or 740.

Upgrade related rules

  • Upgrading NWDI separately is fine, it has no effect on the Tracks , RTSs ,NWDS , LocalAS as also pointed out in "Basic Rules point 2" (i.e. it is fine if NWDI's version differs from the version of the previously listed items). See also Maintenance of an NWDI-Driven System Landscape
  • When upgrading an RTS (e.g. DEV), NWDI does not need to be upgraded, but all the other RTSs (i.e. CONS, TEST, PROD), NWDS, LocalAS and the Build Plugins of the involved Track(s) have to be upgraded as well.

Related Blog