NWDI Server and Developer Studio Compatibility question

[Former Member]

My Portal landscape is 7.0 SP15, and so in my NWDI server and Developer Studio version. This, or course, works perfectly.

However I am planning to start building applications for a CE 7.2 applications. This requires an upgraded NWDI server. In order to minimize interruption of the development environment, I decided to build a new NWDI server rather than upgrade the existing one. This way I can just migrate the projects over. I also figured this way I can build the server at the latest version (7.2 SP04)

I created a new project on the new NWDI server (7.2 SP04). The target for this project is a 7.0 SP15 J2EE server. The problem is I can't connect to it with Developer Studio 7.0 SP15 ( I get a timeout error). However, I can connect fine with Developer Studio 7.2.

I thought the NWDI servers were backwards compatible. Am I missing something?

[ErvinSzolke]

Hi Christopher,

as I can see the development support is providing you a fix for this. If you have no further questions I kindly ask you to close the thread.

Thank you!

Best Regards,

Ervin

[Former Member]

Hello,

Sorry to reply back to this thread that is more than 2 years old but this is exactly the same problem that I am facing now and there are no other threads that deal with the same issue. If somebody have come across this issue or have a solution to the problem please post it which will be really helpful.

Thanks,

Nagarajan.

[ErvinSzolke]

Hi,

I attached the file to this message.

Cheers,

Ervin

[ErvinSzolke]

Hi Christopher,

can you please set up client side tracing as per the note for the DTR ?

#751640 - How To Configure Logging For NWDI Developer Studio

Thank you!

Regards,

Ervin

[Former Member]

Since the trace file is far too big to paste into the reply, I'm sharing it as a link.

[NWDS Trace file|https://docs.google.com/leaf?id=0BwNKkLJI8MpHNGJmMDI5YmItMDdhZS00YmNlLWJiNTEtNzhhMGRlN2Q4MWQy&hl=en]

[Former Member]

I have more information.

I put the NWDS 7.0 SP15 in debug mode to trace the connection to the 7.0 DTR and the 7.2 DTR to see if there are any differences.

It looks like the 7.2 DTR replies with a 302 redirect from /dtr to /dtr/ whereas the 7.0 DTR does not. The 7.0 DTR responds with the data. The 7.2 NWDS follows the redirect properly, but the 7.0 NWDS doesn't. It waits for the formatted data and times-out.

Has anyone heard of this? I couldn't find any notes that looked useful.

[Former Member]

Here's the error from NWDS:

Error Mon Jan 31 13:20:35 EST 2011 Jan 31, 2011 1:20:35 PM com.sap.dtr.client.lib.protocol.requests.RequestBase [Thread[main,5,main]] Error:

java.net.SocketTimeoutException: Read timed out

at java.net.SocketInputStream.socketRead0(Native Method)

at java.net.SocketInputStream.read(SocketInputStream.java:129)

at com.sap.dtr.client.lib.protocol.streams.ChunkedInputStream.fillUnchunked(ChunkedInputStream.java:666)

at com.sap.dtr.client.lib.protocol.streams.ChunkedInputStream.fill(ChunkedInputStream.java:592)

at com.sap.dtr.client.lib.protocol.streams.ChunkedInputStream.skipAvailable(ChunkedInputStream.java:759)

at com.sap.dtr.client.lib.protocol.streams.ChunkedInputStream.skipContent(ChunkedInputStream.java:418)

at com.sap.dtr.client.lib.protocol.streams.ChunkedInputStream.close(ChunkedInputStream.java:438)

at com.sap.dtr.client.lib.protocol.streams.ResponseStream.close(ResponseStream.java:340)

at com.sap.dtr.client.lib.protocol.streams.ResponseStream.release(ResponseStream.java:382)

at com.sap.dtr.client.lib.protocol.Connection.sendInternal(Connection.java:1626)

at com.sap.dtr.client.lib.protocol.Connection.send(Connection.java:1479)

at com.sap.dtr.client.lib.protocol.requests.RequestBase.perform(RequestBase.java:570)

at com.sap.dtr.client.lib.protocol.requests.RequestBase.perform(RequestBase.java:709)

at com.tssap.dtr.client.lib.deltavlib.impl.DeltavCommand.uncheckedExecute(DeltavCommand.java:138)

at com.tssap.dtr.client.lib.deltavlib.impl.DeltavCommand.uncheckedExecute(DeltavCommand.java:167)

at com.tssap.dtr.client.lib.deltavlib.impl.DeltavCommand.execute(DeltavCommand.java:49)

at com.tssap.dtr.client.lib.deltavlib.impl.AbstractResource$PropFinder.load(AbstractResource.java:1216)

at com.tssap.dtr.client.lib.deltavlib.impl.cache.HashmapPropCache.refresh(HashmapPropCache.java:284)

at com.tssap.dtr.client.lib.deltavlib.impl.cache.HashmapPropCache.getPropertyObjects(HashmapPropCache.java:461)

at com.tssap.dtr.client.lib.deltavlib.impl.AbstractResource.getPropertyObjects(AbstractResource.java:980)

at com.tssap.dtr.client.lib.deltavlib.impl.BaseResource.getPropertySet(BaseResource.java:876)

at com.tssap.dtr.client.lib.deltavlib.impl.BaseResource.getPropertySet(BaseResource.java:868)

at com.tssap.dtr.client.lib.vfs.config.impl.Server.initializeProperties(Server.java:449)

at com.tssap.dtr.client.lib.vfs.config.impl.Server.getProperty(Server.java:290)

at com.tssap.dtr.client.lib.vfs.config.impl.VfsContext.getServerProperty(VfsContext.java:278)

at com.tssap.dtr.client.lib.vfs.impl.VersionedFileSystemManager.clientVersionCheck(VersionedFileSystemManager.java:334)

at com.tssap.dtr.client.lib.vfs.impl.VersionedFileSystemManager.getVersionedFileSystemManager(VersionedFileSystemManager.java:245)

at com.tssap.dtr.client.lib.vfs.VersionedFileSystemFactory.getVersionedFileSystemManager(VersionedFileSystemFactory.java:46)

at com.tssap.dtr.client.eclipse.vfs.VfsManagerProvider.getVersionedFileSystemManager(VfsManagerProvider.java:251)

at com.sap.ide.eclipse.cbs.activation.internal.ActivationRuntimeDataStorage.getCurrentVfsManager(ActivationRuntimeDataStorage.java:1233)

at com.sap.ide.eclipse.cbs.activation.internal.ActivationRuntimeDataStorage.onUserLoggedIn(ActivationRuntimeDataStorage.java:1111)

at com.tssap.dtr.client.eclipse.vfs.VfsManagerProvider.fireLoginOrLogoutPerformed(VfsManagerProvider.java:152)

at com.tssap.dtr.client.eclipse.vfs.VfsManagerProvider.access$000(VfsManagerProvider.java:53)

at com.tssap.dtr.client.eclipse.vfs.VfsManagerProvider$1.invoke(VfsManagerProvider.java:102)

at $Proxy0.loginPerformed(Unknown Source)

at com.sap.ide.login.UserValidator$1.run(UserValidator.java:159)

at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)

at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:98)

at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:1999)

at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1733)

at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:136)

at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:261)

at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:357)

at com.sap.ide.login.UserValidator.getData(UserValidator.java:411)

at com.sap.ide.login.UserValidator.getDefaultServerData(UserValidator.java:131)

at com.sap.ide.login.UserValidator.getDefaultServerData(UserValidator.java:116)

at com.sap.ide.login.actions.LoginActionDelegate.run(LoginActionDelegate.java:79)

at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:251)

at org.eclipse.ui.internal.WWinPluginAction.runWithEvent(WWinPluginAction.java:207)

at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:456)

at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent(ActionContributionItem.java:403)

at org.eclipse.jface.action.ActionContributionItem.access$0(ActionContributionItem.java:397)

at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent(ActionContributionItem.java:72)

at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:81)

at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:840)

at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2022)

at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1729)

at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1402)

at org.eclipse.ui.internal.Workbench.run(Workbench.java:1385)

at com.tssap.util.startup.WBLauncher.run(WBLauncher.java:79)

at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:858)

at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)

at com.sap.ide.eclipse.startup.Main.basicRun(Main.java:291)

at com.sap.ide.eclipse.startup.Main.run(Main.java:789)

at com.sap.ide.eclipse.startup.Main.main(Main.java:607)

[Former Member]

The first thing I thought was authorizations, so I checked it and it's fine. As far as I can tell, the client is fine and the server is fine, just not together. Here are the cases I have tried:

DI 7.0 + DS 7.0 -> Success

DI 7.0 + DS 7.2 -> Success

DI 7.2 + DS 7.0 -> Fail

DI 7.2 + DS 7.2 - Success

Note: DI 7.0 and 7.2 are on different servers, DS 7.0 and 7.2 are on the same client PC using the same user (LDAP) with the same permissions (NWDI.Administrator and NWDI.Developer)

Both DI servers have their own SLD that is replicated from the 7.0 to the 7.2.

The SLD on the 7.0 DI server is the name reservation server.

The failure seems to indicate a communications timeout connecting to the DTR, but why would it fail only in the one case and not the others? I can only assume it's either an incompatibility or a mis-configuration, but I have no idea where to start looking.

[ErvinSzolke]

Hi Christopher,

usually this is due to wrong ACL settings (http://help.sap.com/saphelp_nwce72/helpdata/en/21/53882f3fee0243b6c774e26ebed880/frameset.htm)

http://<host>:<port>/dtr/ws/system/config/active/ACLs/byPath/acl.xml

Still, your error message is not about "Unauthorized" but

Accessing server root property (XCM_CLIENT:minVersion) failed: Communication error cause: Read timed out

So as if the DTR client (built into your NWDS on client side) could not properly communicate with the DTR on server side.

Best Regards,

Ervin

[Former Member]

It looks like it's getting the configuration from the SLD server, but when it tries to connect to the DTR, I get the following error:

Server response time for login to server http://usorlu29-1.chep.com:50000/dtr/ : 140 ms.

Accessing server root property (XCM_CLIENT:minVersion) failed: Communication error [cause: Read timed out]

This is a new track I created for this test. The strange thing is I can connect to the DTR fine with NWDS 7.2. I am also using the same user in both cases, and the user has NWDI. Administrator and NWDI.Developer.

Edited by: Christopher Esser on Jan 31, 2011 11:48 AM

[ErvinSzolke]

Hi Christopher,

indeed the version of the NWDI is not really important here. As mentioned it is only a framework allows you to develop for arbitary releases.

The question is that if you connect your NWDS 700 SP15, you should only work on tracks (import development configs) which have dependent software for 700 SP15.

If you use 720 SP<X> NWDS, you are allowed to import "720 SP<X> tracks" (again, more precisely tracks for which you have specified 720 SP<X> dependent SCs). AND of course needless to say, you are allowed to deploy these tracks later only and only to RunTime Systems which have the version 720 SP<X>.

Now If I understand properly your problem comes earlier, i.e. you cannot connect your 700 SP15 NWDS to a 720 NWDI.

As you know there are two ways to "binding" your NWDS to a j2ee engine:

1. for direct deployments (this way NWDI is not involved at all). This is the configuration you find in your 700 SP15 NWDS as: Window -- Preferences -- SAP J2EE Engine. (If you want to see whether it can be really "seen" from your NWDS, switch on the J2EE Engine view this way: Window -- Show View -- Other ... J2EE -- J2EE Engine). This has nothing to do with tracks, with NWDI (i.e. no source control, no central build, no central deployment), only used to deploy your software to an arbitary j2ee engine directly.

2. doing central development (this is team development, i.e. working with NWDI). In this scenario you bind the NWDS to an SLD (common misunderstanding, not to the NWDI server, but to the SLD. Often this is the same engine, but not necessarily).

This is the configuration: Window -- Preferences -- Java Development Infrastructure -- Development Configuration Pool.

This has nothing to do with the J2EE Engine view which I mentioned above and which is for direct deployment (also known as for "local tests"). The URL to the SLD to be specified is the one you have also defined on the Domain Data tab of the Landscapce Configurator of the CMS Webui.

If you still face problems, I kindly ask you to ensure that the 'Error Log' view is switched on:

Window u2013 Show View u2013 Other... u2013 PDE Runtime --> Error log and see whether there is error reported here after error reproduction. If yes, click twice on the report, and provide me the details.

Best Regards,

Ervin

[Former Member]

I created a new server for other reasons as well. Mainly to get newer, faster hardware and not interrupt ongoing development. Since I was building a new server anyway, I figured I should use the latest version.

I read the link you sent me, and it basically says my configuration should work: 7.2 SP04 NWDI with 7.0 SP15 NWDS.

My problem being that it doesn't work. I can connect to the NWDI server with NWDS 7.2 and import a track configuration, but when I try to connect to it with NWDS 7.0 it times-out.

Any suggestions?

[ErvinSzolke]

Hi Christopher,

However I am planning to start building applications for a CE 7.2 applications. This requires an upgraded NWDI server.

In order to develop for 720 as well as for 700 using the same NWDI, there's no need to upgrade the NWDI server. Please have a look at the below thread for details which I believe answers your question:

I hope this helps!

Best Regards,

Ervin