Skip to Content

“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. image

To report this post you need to login first.

30 Comments

You must be Logged on to comment or reply to a post.

  1. Anonymous
    From your weblog if my understanging is correct is that NWDS and WAS will be maintained on same SP level say for example SP12,where as JDI SP 13 can be very well used with NWDS and WAS SP12.
    At the same time tracks which are created in JDI SP12 can be used if at all if we enhance JDI SP 12 to SP13.
    (0) 
          1. RK RK
            Marion,

            thanks for the reply, what if the SLD version is below the JDI level, do you mean that it is completely independent?

            thanks
            Reddy

            P.S: one more question, ofcourse not related to this weblog directly. i.e. we specify username and password when creating a domain. is it OK, if we keep on changing this password once a week/month. posted already in forums, but couldnt get a reply..would be greatful if you can let me know.

            (0) 
            1. Marion Schlotte Post author
              Hi,
              yes, that mean the SLD server version is independent from the NWDI server version. It can be older or newer, but the recommendation is to keep it up to date.

              The question concerning changing the CMS-User password is not that easy. Is it possible in general, but not recommended. It is a very expensive operation and you really have to know what you have to do afterwards. With future releases it should be possible without any drawbacks.
              Regards, Marion

              (0) 
              1. RK RK
                Hi Marion,

                Thanks for the reply. But, It is mandatory for us to change the password, as currently the dev team knows this password and security team doesnt wants them to know. so there is no other choice other than changing the password.

                AFAIK, The only steps that I need to do are just to change the password of “CMSadm” in UME of JDI and SLD. or do you think if i need to do change this password somewhere else?

                Thanks

                P.S: sorry for extending the discussion as if it is posted in a forum, but I promise this is my last query 🙂

                (0) 
                1. Marion Schlotte Post author
                  Hi,
                  the steps are the following.
                  1. Change the password of the “CMSadm” user in UME of JDI and SLD.
                  2. Change and save the password in the Domain configuration of the CMS Landscape Configurator.
                  3. Save all tracks.
                  4. Restore system state of all tracks.

                  Best regards, Marion

                  (0) 
                  1. Catherine Velez
                    Hi Marion,
                    We are upgrading our SLD to 7.1 (CE 7.1), and the rest of our apps (NWDI, EP, ESS and NWDS) will remain in netweaver 7.0.  Will NWDS work with SLD being on CE 7.1?

                    Hope to hear from you soon.

                    Thanks,
                    Catherine

                    (0) 
                      1. Gopala krishna Gundu
                        Hi Marion,
                        We have WAS and JDI 6.40SP24 (NW04SP24) on the same development server and its having two tracks
                        1.ESS track with ESS100 SP20 and did custom changes
                        2.Custom track for developing custom applications, we have developed some applications in that with SCAs SP24.
                        3.Having NWDS 2.0 SP18

                        Now we want upgrade SP24 to SP25 both WAS and JDI.
                        We have following concern before upgrade.
                        1.Is this ESS track will work without any issues and changes
                        2.Custom track will it work without changing SCAs for build space as it is
                        Please provide some guidance about this

                        Thanks & regards
                        Gopal

                        (0) 
  2. Matthew Harding
    I heard a rumour that the New York(?) release will be on JDK1.5, and was wondering how this will impact NWDI?  i.e. Is there plans to support both 1.4 and 1.5 for CBS when this occurs?
    (0) 
    1. Eduard Bartsch
      Yes. Moreover, CBS supports different JDKs (1.3, 1.4, 1.5) starting with 6.40 SP15.

      You can use different JDKs in different buildspaces on the same CBS. You can even configure different JDKs for every Software Component in one buildspace individually.

      Best regards,
      Eduard

      (0) 
  3. Anonymous
    In our case SPS Y is greater than SPS Z
    NW DS           2004s ( WAS 7 )
    NWDI server(CMS,CBS,DTR) 2004 sp14 (WAS 640)
    Track CONS,TEST,PROD     2004s ( WAS 7 )

    Would this combination work, we loaded verion 7.o build-plugins and since then it messed up the total NDWI server.

    (0) 
    1. Marion Schlotte Post author
      Yes, this combination works as well.
      Which version did you import. It seems to me as if you used the wrong SCA file for SPS4. There are two files with the same name. Please choose the one, that is smaller in size or import the newest SPS5 SCAs?
      Best regards,
      Marion
      (0) 
  4. Rich Batchelor
    Marion,
    We have a very simple setup where we currently have our NWDI running on the TEST server in our landscape (CONS/TEST/PROD).  For our developer studio (NWDS) we do not yet run with a local Web AS, we simply deploy to a common DEV system to test. Our Web AS 640 Java and NWDI are at SPS12.  The NWDS is 2.0, SPS12.  I would like to apply SPS16 to the WAS and the NWDI.  Is it also required to apply the current SPS to NWDS (The current NWDS SPS is 15)?  Is there a place on SAPNet where these type of software dependencies are maintained? 

    Thank you.

    Kind regards,
    Rich Batchelor

    (0) 
    1. Marion Schlotte Post author
      Hi Rich,
      the recommendation is to keep WAS and NWDS always on the same SPS level, especially for Web Dynpro developments. The NWDI server SPS level can be different, but the track content (build plugins and dependent SCAs) should be SPS16 in your case. I don’t know a place where that recommendation is documented.
      Best regards,
      Marion
      (0) 
  5. Jay Kapadia

    Hi, plug-ins (according to the SAP documentation) into the inbox folder, checked them into the track and imported them to the Development and Consolidation runtime systems. Now these dependent SCs show SP16 which is consistent with the rest of the landscape SP. On doing this, we found that most of the DCs of the SAP_ESS SC were broken. To resolve this issue, we even tried to rebuild all the DCs in the compartment using the “Initialize Compartment” button in the Compartments view, CBS Buildspace Details. Still no positive result. Can you help us on this??

    (0) 
    1. Marion Schlotte Post author
      Hi,
      I hope you have still a track with your SP7/SP11 SCAs to compare the changes as described in the ESS Cookbook (Attachement in Note 872892).
      The broken DCs are because of changed dependencies. When you import SPS16 WAS SCAs, you have to import the corresponding SPS12 ESS SCAs into your track. But please keep in mind, that this will override your buildspaces with your changes/modifications.
      So please follow the Cookbook. If you remember all your changes you can continue and re-implement it in the upgraded track. If not, you should ask for advise from our support team to go back to your old configuration before importing the new ESS SCAs into the track.
      Best regards,
      Marion
      (0) 
  6. Kiran Gollapudi
    Hi,

      In your blog you mentioned that NWDI should be greater than or equal to NWDS and later in one of your replies to a query you said that its ok to have NWDS greater than or equal to NWDI. They are both contradicting unless the constraint of version levels of NWDI and NWDS no longer exist.

    Thanks
    Kiran

    (0) 
    1. Marion Schlotte Post author
      Hi,
      the recommendation is to keep NWDI always on the highest SP level. But it is also possible to have an NW’04 NWDI for NW2004s developments inside the tracks.
      Best regards,
      Marion
      (0) 
      1. Hans-Juergen Hennrich
        Hi,
        I like to add one comment. The most important thing is that NWDS fits to the content (build plugins and libs) of the development configurations respectively tracks. Therefore NWDS and the SCAs (software component archives) which are imported into a track must have the same NW release and SP level. Otherwise there might be build errors if a developer tries to work with a development configuration which doesn’t fit to his NWDS version.

        On the other hand, the JDI client within NWDS and the JDI server software are upward and downward compatible as much as possible. As described in this weblog it’s a major feature of JDI, that one central JDI server can support development of various releases. That means that in a typical landscape there will be a lot of different NWDS versions working against the different tracks of one single JDI server. But because this compatibility can’t be guaranteed between arbitrary releases the recommendation is to use a JDI server on the highest available NW release and SP level.

        Best regards,
        Hans-Jürgen

        (0) 
  7. Benjamin de Rijke
    Hello Marion,

    We are using the JDI Cookbook for ESS Customers as attached to note 872892.

    We now get errors during the import of ESS SP11. And SAPPCUI_GP. Please see below for more details from the log.

    Do you have any idea?

    Thanks in advance,
    Benjamin de Rijke

    SAP Change Management Service
    Software Component sap.com/SAP_ESS
    Version MAIN_xss04PAT_C.20060508043004
    Label 100 Level 11 Update xss04PAT.05080429
    System ESSTrack-Development
    Step Repository-import
    Log /usr/sap/trans/JTrans/CMS/log/ESSTrack_D@MDF/ESSTrack_D@MDF200703270705150219Repository-import.log

    Info:Starting Step Repository-import at 2007-03-27 07:07:11.0653 +0:00
    Info:Component:sap.com/SAP_ESS
    Info:Version  :MAIN_xss04PAT_C.20060508043004
    Info:1. PR is of type TCSSoftwareComponent
    Fatal:Unexpected exception ‘com.tssap.dtr.client.lib.deltavlib.xcm.IExternalResourceFactory: method createImportable(Lcom/tssap/dtr/client/lib/deltavlib/connection/IConnectionIdentifier;Ljava/io/InputStream;)Lcom/tssap/dtr/client/lib/deltavlib/impl/IImportable; not found’ occurred. Stopping processing.
    Fatal Throwable:java.lang.NoSuchMethodError: com.tssap.dtr.client.lib.deltavlib.xcm.IExternalResourceFactory: method createImportable(Lcom/tssap/dtr/client/lib/deltavlib/connection/IConnectionIdentifier;Ljava/io/InputStream;)Lcom/tssap/dtr/client/lib/deltavlib/impl/IImportable; not found:com.tssap.dtr.client.lib.deltavlib.xcm.IExternalResourceFactory: method createImportable(Lcom/tssap/dtr/client/lib/deltavlib/connection/IConnectionIdentifier;Ljava/io/InputStream;)Lcom/tssap/dtr/client/lib/deltavlib/impl/IImportable; not found
    java.lang.NoSuchMethodError: com.tssap.dtr.client.lib.deltavlib.xcm.IExternalResourceFactory: method createImportable(Lcom/tssap/dtr/client/lib/deltavlib/connection/IConnectionIdentifier;Ljava/io/InputStream;)Lcom/tssap/dtr/client/lib/deltavlib/impl/IImportable; not found
         at com.sap.cms.tcs.client.DTRCommunicator.import_(DTRCommunicator.java:566)
         at com.sap.cms.tcs.client.DTRCommunicator.writeChangelistData(DTRCommunicator.java:260)
         at com.sap.cms.tcs.core.RepositoryImportTask.processRepositoryImport(RepositoryImportTask.java:259)
         at com.sap.cms.tcs.core.RepositoryImportTask.process(RepositoryImportTask.java:500)
         at com.sap.cms.tcs.process.ProcessStep.processStep(ProcessStep.java:77)
         at com.sap.cms.tcs.process.ProcessStarter.process(ProcessStarter.java:179)
         at com.sap.cms.tcs.core.TCSManager.importPropagationRequests(TCSManager.java:376)
         at com.sap.cms.pcs.transport.importazione.ImportManager.importazione(ImportManager.java:216)
         at com.sap.cms.pcs.transport.importazione.ImportQueueHandler.execImport(ImportQueueHandler.java:585)
         at com.sap.cms.pcs.transport.importazione.ImportQueueHandler.startImport(ImportQueueHandler.java:101)
         at com.sap.cms.pcs.transport.proxy.CmsTransportProxyBean.startImport(CmsTransportProxyBean.java:583)
         at com.sap.cms.pcs.transport.proxy.CmsTransportProxyBean.startImport(CmsTransportProxyBean.java:559)
         at com.sap.cms.pcs.transport.proxy.LocalCmsTransportProxyLocalObjectImpl0.startImport(LocalCmsTransportProxyLocalObjectImpl0.java:1252)
         at com.sap.cms.ui.wl.Custom1.importQueue(Custom1.java:1170)
         at com.sap.cms.ui.wl.wdp.InternalCustom1.importQueue(InternalCustom1.java:2162)
         at com.sap.cms.ui.wl.Worklist.onActionImportQueue(Worklist.java:880)
         at com.sap.cms.ui.wl.wdp.InternalWorklist.wdInvokeEventHandler(InternalWorklist.java:2338)
         at com.sap.tc.webdynpro.progmodel.generation.DelegatingView.invokeEventHandler(DelegatingView.java(Compiled Code))
         at com.sap.tc.webdynpro.progmodel.controller.Action.fire(Action.java(Compiled Code))
         at com.sap.tc.webdynpro.clientserver.task.WebDynproMainTask.handleAction(WebDynproMainTask.java(Inlined Compiled Code))
         at com.sap.tc.webdynpro.clientserver.task.WebDynproMainTask.handleActionEvent(WebDynproMainTask.java(Compiled Code))
         at com.sap.tc.webdynpro.clientserver.task.WebDynproMainTask.execute(WebDynproMainTask.java(Compiled Code))
         at com.sap.tc.webdynpro.clientserver.cal.AbstractClient.executeTasks(AbstractClient.java(Compiled Code))
         at com.sap.tc.webdynpro.clientserver.cal.ClientManager.doProcessing(ClientManager.java(Compiled Code))
         at com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doWebDynproProcessing(DispatcherServlet.java(Compiled Code))
         at com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doContent(DispatcherServlet.java(Compiled Code))
         at com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doPost(DispatcherServlet.java(Compiled Code))
         at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code))
         at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code))
         at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.runServlet(HttpHandlerImpl.java(Compiled Code))
         at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.handleRequest(HttpHandlerImpl.java(Compiled Code))
         at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java(Inlined Compiled Code))
         at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java(Compiled Code))
         at com.sap.engine.services.httpserver.server.RequestAnalizer.invokeWebContainer(RequestAnalizer.java(Compiled Code))
         at com.sap.engine.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java(Compiled Code))
         at com.sap.engine.services.httpserver.server.Client.handle(Client.java(Compiled Code))
         at com.sap.engine.services.httpserver.server.Processor.request(Processor.java(Compiled Code))
         at com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java(Compiled Code))
         at com.sap.engine.core.cluster.impl6.session.MessageRunner.run(MessageRunner.java(Compiled Code))
         at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java(Compiled Code))
         at java.security.AccessController.doPrivileged1(Native Method)
         at java.security.AccessController.doPrivileged(AccessController.java(Compiled Code))
         at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java(Compiled Code))
         at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java(Compiled Code))
    Info:Step Repository-import ended with result ‘fatal error’ ,stopping execution at 2007-03-27 07:07:17.0046 +0:00

    ====================================
    SAP Change Management Service
    Software Component sap.com/SAPPCUI_GP
    Version MAIN_xss04PAT_C.20060426110432
    Label 100 Level 11 Update xss04PAT.04261103
    System ESSTrack-Development
    Step CBS-make
    Log /usr/sap/trans/JTrans/CMS/log/ESSTrack_D@MDF/ESSTrack_D@MDF200703261351190082CBS-make.log

    Info:Starting Step CBS-make at 2007-03-26 13:51:58.0395 +0:00
    Info:wait until CBS queue of buildspace MDF_ESSTrack_D is completely processed, before starting the import
    Info:waiting for CBS queue activity
    Info:build process already running: waiting for another period of 30000 ms

    Info:build process already running: waiting for another period of 30000 ms
    Info:no changes on the CBS request queue (MDF_ESSTrack_D) after a waiting time of 14430000 ms
    Fatal:The request queue is not processed by the CBS during the given time intervall => TCS cannot import the request because queue is not empty
    Fatal:There seems to be a structural problem in the NWDI. Please look after the operational status of the CBS.
    Fatal Exception:com.sap.cms.tcs.interfaces.exceptions.TCSCommunicationException: communication error: The request queue is not processed during the given time intervall. There seems to be a structural problem in the NWDI. Please look after the operational status of the CBS.:communication error: The request queue is not processed during the given time intervall. There seems to be a structural problem in the NWDI. Please look after the operational status of the CBS.
    com.sap.cms.tcs.interfaces.exceptions.TCSCommunicationException: communication error: The request queue is not processed during the given time intervall. There seems to be a structural problem in the NWDI. Please look after the operational status of the CBS.
         at com.sap.cms.tcs.client.CBSCommunicator.importRequest(CBSCommunicator.java:369)
         at com.sap.cms.tcs.core.CbsMakeTask.processMake(CbsMakeTask.java:120)
         at com.sap.cms.tcs.core.CbsMakeTask.process(CbsMakeTask.java:347)
         at com.sap.cms.tcs.process.ProcessStep.processStep(ProcessStep.java:77)
         at com.sap.cms.tcs.process.ProcessStarter.process(ProcessStarter.java:179)
         at com.sap.cms.tcs.core.TCSManager.importPropagationRequests(TCSManager.java:376)
         at com.sap.cms.pcs.transport.importazione.ImportManager.importazione(ImportManager.java:216)
         at com.sap.cms.pcs.transport.importazione.ImportQueueHandler.execImport(ImportQueueHandler.java:585)
         at com.sap.cms.pcs.transport.importazione.ImportQueueHandler.startImport(ImportQueueHandler.java:101)
         at com.sap.cms.pcs.transport.proxy.CmsTransportProxyBean.startImport(CmsTransportProxyBean.java:583)
         at com.sap.cms.pcs.transport.proxy.CmsTransportProxyBean.startImport(CmsTransportProxyBean.java:559)
         at com.sap.cms.pcs.transport.proxy.LocalCmsTransportProxyLocalObjectImpl0.startImport(LocalCmsTransportProxyLocalObjectImpl0.java:1252)
         at com.sap.cms.ui.wl.Custom1.importQueue(Custom1.java:1170)
         at com.sap.cms.ui.wl.wdp.InternalCustom1.importQueue(InternalCustom1.java:2162)
         at com.sap.cms.ui.wl.Worklist.onActionImportQueue(Worklist.java:880)
         at com.sap.cms.ui.wl.wdp.InternalWorklist.wdInvokeEventHandler(InternalWorklist.java:2338)
         at com.sap.tc.webdynpro.progmodel.generation.DelegatingView.invokeEventHandler(DelegatingView.java(Compiled Code))
         at com.sap.tc.webdynpro.progmodel.controller.Action.fire(Action.java(Compiled Code))
         at com.sap.tc.webdynpro.clientserver.task.WebDynproMainTask.handleAction(WebDynproMainTask.java(Inlined Compiled Code))
         at com.sap.tc.webdynpro.clientserver.task.WebDynproMainTask.handleActionEvent(WebDynproMainTask.java(Compiled Code))
         at com.sap.tc.webdynpro.clientserver.task.WebDynproMainTask.execute(WebDynproMainTask.java(Compiled Code))
         at com.sap.tc.webdynpro.clientserver.cal.AbstractClient.executeTasks(AbstractClient.java(Compiled Code))
         at com.sap.tc.webdynpro.clientserver.cal.ClientManager.doProcessing(ClientManager.java(Compiled Code))
         at com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doWebDynproProcessing(DispatcherServlet.java(Compiled Code))
         at com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doContent(DispatcherServlet.java(Compiled Code))
         at com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doPost(DispatcherServlet.java(Compiled Code))
         at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code))
         at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code))
         at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.runServlet(HttpHandlerImpl.java(Compiled Code))
         at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.handleRequest(HttpHandlerImpl.java(Compiled Code))
         at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java(Inlined Compiled Code))
         at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java(Compiled Code))
         at com.sap.engine.services.httpserver.server.RequestAnalizer.invokeWebContainer(RequestAnalizer.java(Compiled Code))
         at com.sap.engine.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java(Compiled Code))
         at com.sap.engine.services.httpserver.server.Client.handle(Client.java(Compiled Code))
         at com.sap.engine.services.httpserver.server.Processor.request(Processor.java(Compiled Code))
         at com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java(Compiled Code))
         at com.sap.engine.core.cluster.impl6.session.MessageRunner.run(MessageRunner.java(Compiled Code))
         at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java(Compiled Code))
         at java.security.AccessController.doPrivileged1(Native Method)
         at java.security.AccessController.doPrivileged(AccessController.java(Compiled Code))
         at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java(Compiled Code))
         at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java(Compiled Code))

    Info:Step CBS-make ended with result ‘fatal error’ ,stopping execution at 2007-03-26 18:14:27.0711 +0:00

    (0) 
    1. Marion Schlotte Post author
      Hi,
      the ESS problem has nothing to do with this weblog. Therefore I can not answer your question here. Please open a customer message (service.sap.com) as it is a support question.
      Thanks and kind regards,
      Marion
      (0) 
  8. Faraz Siddiqui
    Hi,

    Can you tell me whether NWDS 7.1 will work with NWDI 7.0. We want to implement a project using this configuration but would like an official answer from somebody in SAP before we go ahead.

    Thanks
    Faraz

    (0) 
  9. Doug Steckel
    Thanks Marion for this excellent blog.

    We have a simple setup. We are not running local WAS on development boxes. We deploy to out DEV application servers. We are on WAS 640 for both application servers and NWDI. They are all 32 bit hardware & Windows OS. I’m trying to understand the prerequisites for NWDI as we think about upgrading to 64 but (x64) hardware and OS for our application servers. Must NWDI be upgraded to 64 bit versions as well. Can we simply import into our tracks the common SC’s now found on the 64 bit app servers and rebuild? We have a mix of straight java and Web Dynpro.

    Thanks in advance for your help.

    Kind Regards,
    Doug Steckel

    (0) 

Leave a Reply