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.
cancel
Showing results for 
Search instead for 
Did you mean: 

“On which SPS level do I have to run my JDI server when I develop applications for a specific SP stack?”


This is a question that came up several times in the past. It shows that the difference between JDI software and JDI content (software that is built inside the JDI) is not clear. A key feature of the JDI is that it allows you to develop and build software spanning several releases, which is tested and run within the configured runtime systems on different (even older) SPS levels. The JDI software (JDI server) should preferably run on the highest SP level available, independent of the SP level of the software inside the configured tracks. This recommendation guarantees a working, reliable environment, since the JDI is designed to be compatible to its former releases and to be decoupled from its configured runtime systems. But it is not always necessary to upgrade the JDI software to the highest available version. Please check the specific SPS release notes for enhancements of the JDI software. If there is no need to upgrade, you can run an “older” JDI SPS version and develop software for newer releases. This should work in most cases, but there is no guarantee for all possible combinations of releases. There might be some exceptions to the rule. Furthermore, the recommendation is to run the JDI server on a separate host, hence the decision to upgrade is independent on the requirements to upgrade specific NetWeaver components on the runtime systems(DEV, CONS, TEST or PROD). As already mentioned, the JDI, and especially the CBS, is designed and implemented in a way to allow development of software (maintain sources and builds) for different releases (SP versions) within one JDI server. The complete release and SP version dependent logic is part of the build plug-ins (which are shipped through the SAP-BUILDT software component). Therefore, a CBS server can build components for different SPS levels (for example for Web Dynpro applications) depending on the build-plugins imported into a track. During the upgrade of JDI software from one release to another, the content of the JDI server - like the build plug-ins (SAP-BUILDT) and other SCs you are using - remains the same. As described above, this is the correct behaviour, as the content belongs to the configured runtime systems, which of course can run on different SPS levels. But please keep in mind, that the SAP NetWeaver Application Server on which the JDI is deployed and the JDI software itself has to be the same SPS level. For the NetWeaver Developer Studio, the scenario looks slightly different. While the JDI related parts in the studio (the DTR and Development Configurations perspective) are mostly backward and forward compatible, the dependencies are more strict in the area of different technologies, like Web Dynpro. Here it is recommended to use the Developer Studio version that corresponds to the configured runtime system. The picture below should demonstrate a scenario, with a JDI on SPS level Z that has a configured track for software development on SPS level Y. The corresponding Developer Studio and its local SAP J2EE engine is on SPS level Y, where SPS Y is older than SPS Z.

30 Comments