NWDI vs. NWDI content
- the version of the following components have to match to each other:
– Local AS (optional but if it is used it also has to match regarding its version)
– RunTime Systems (further referred as RTSs)
- NWDI itself can have any version (there are couple of exceptions see below).
- SLD is not part of NWDI, but it is part of each NWDI scenarios; its version can be any
Details on the Versions
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 ?
This version means Release 730 SP5 Patch Level
- 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 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.
- 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>.
- 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:
|- SAP_BUILDT 730 SP1
|- WD-RUNTIME 730 SP1
|- ENGFACADE 730 SP1
|- ENGINEAPI 730 SP1
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.
So elegantly you have explained every possible horizon of NWDI.
Excellent blog, Ervin!
Thank you, Guys! 😉
Very nice blog! Missed that information here 🙂
Much Needed blog !! thanks
Thank you Ervin.
good blog... thanks
This blog is quite handy. I use it very frequent in the initial analysis.
It is really amazing how extreme is the version mismatch sometimes (for example building a project with NWDS 7.31 following by an attempt to deploy it on RTS 7.01).
It's great blog for getting to know about NWDI. Thanks!
This blog is so relevant for us (customers), even after, more than 6 years of writing this!
Thanks Ervin! 🙂
I am happy to hear that Akhil ?
We have upgraded our complete landscape (all the Dev + Test + Production Servers) only NWDI Server is on older version (7.4).
We are planning to upgrade NWDI Server as well, just to keep all systems up to the latest versions.
Are there any SAP Notes/ documents which can guide on recommendation/ consideration while Upgrading NWDI to 7.5 version. E.g. folders to take backup, fields parameters important from NWDI perspective.
Thanks in Advance!