Web Services in LV2009SP1

[John Lokanis]

Are you using web services with LV2009SP1?

Have you deployed the web service to a target machine that only has the runtime system on it?

When you start your LV app (causing the web server to start on the target machine), how long does it take before you can successfully make web service calls to that machine?

I am porting my 8.6.1 code to LV2009SP1 and have found that the web server appears to be unresponsive for approximately 2 minutes after I start it by launching the app that has the server enabled in its ini file:

WebServer.Enabled=True

Under 8.6.1, the web server would be working immediately after the app was started.

thanks for any ideas or workarounds

-John

[John Lokanis]

Wow, nobody but me uses web services? I guess my session on web services at NI Week2010 will not be that popular...

[Francois Normandin]

Wow, nobody but me uses web services? I guess my session on web services at NI Week2010 will not be that popular...

I'm waiting to attend your session before I jump on the train... Don't give up yet!

[Rolf Kalbermatter]

Wow, nobody but me uses web services? I guess my session on web services at NI Week2010 will not be that popular...

sorry I'm working on my network library to allow clients to communicate with them over SSL before starting to work on them themselves .

[Rob Calhoun]

Wow, nobody but me uses web services? I guess my session on web services at NI Week2010 will not be that popular...

Any chance this LV 2009 Known Issue applies? They say it only happens when the properties page is open. http://zone.ni.com/devzone/cda/tut/p/id/9951#139588_by_Category

On a mostly unrelated issue, I've been debugging a web service for the last day. It is very slow going. Simple stuff works, more complicated stuff simply doesn't. It just returns http error 404. The only hints are in the LabView_Trace.log in %CommonAppDir%\NationalInstruments\Trace Logs. I'm starting to suspect the Windows path limit of 255 chars as the problem: LV puts web services 4 directory levels down in %CommonAppDir% with the result that ~170 chars are used up before you get to the first subvi.

A typical error is:

5/14/2010 4:12:47.316 PM | t=C38 | ERROR | ws_shared | Unzipper::do_extract_currentfile | error opening C:\Documents and Settings\All Users\Application Data\National Instruments\Web Services 2009 32-bit\UserServices\deployed\Test-3CA39ABB-844E-43A0-8F88-DD1C45D2FE7A\internal.llb\LabVIEW 2009\user.lib\_OpenG.lib\error\error.llb\Build Error Cluster__ogtk.vi

Pretty darn long, isn't it? Maybe that's why Microsoft still uses 8.3 filenames all over the place!

I'll post again once if/when I've isolated it.

-Rob

I'll post again once if/when I've isolated it.

Well, I can break it by saving a VI to a really long nested path, and un-break it by saving it higher up in the hierarchy, with the same filename. No warnings during the build process. Bug report time.

...

I have no idea how to reconfigure LabView to store the web services less deeply in the hierarchy, but I do have a code obfuscater that replaces files with their MD5 hash. Maybe that will be sufficient. Otherwise, this is a major barrier to using web services since there are only about 85 chars available for user paths.

[John Lokanis]

I have no idea how to reconfigure LabView to store the web services less deeply in the hierarchy, but I do have a code obfuscater that replaces files with their MD5 hash. Maybe that will be sufficient. Otherwise, this is a major barrier to using web services since there are only about 85 chars available for user paths.

Open the build settings for your web service, go to the Advanced category and find the check box labeled 'Use LabVIEW 8.x file layout'.

Make sure this is checked and then build and test again. Your problem should go away.

Any chance this LV 2009 Known Issue applies? They say it only happens when the properties page is open. http://zone.ni.com/d...588_by_Category

Nope. The issue is when the web server starts for the first time, it gets stuck for 2 minutes and then finished. Once it is up and running, the web service calls all work fine. I have a request in to get to the bottom of this so I hope to have an answer soon.

[Rob Calhoun]

Open the build settings for your web service, go to the Advanced category and find the check box labeled 'Use LabVIEW 8.x file layout'.

Make sure this is checked and then build and test again. Your problem should go away.

It did. I eventually figured this out by comparing a web service brought over from LV 8.6 that worked with one created under LV 2009 that didn't. (Of course I would have saved myself a day of hair-pulling if I'd just come back to LAVA to read your reply!)

Thanks, John. I'm trying to write this up on the ni.com forums so that the build & deploy process gets improved in future versions of LabView.

I haven't tried deploying on a machine that doesn't have LV on it yet.

-Rob

[Mariusz]

Wow, nobody but me uses web services? I guess my session on web services at NI Week2010 will not be that popular...

I'm currently using LabVIEW web services, and I'm really surprised that more people don't us it for their projects.

Well anyway, I just uploaded alpha version of my demo app and it's available from http://wsdemo.tekthi...bService/static

Currently it works with LabVIEW 8.6 and the same "application" was successfully deployed on cRIO 9002 and currently runs on PXI-1000B

Mariusz

[James Brunner]

Are you using web services with LV2009SP1?

Have you deployed the web service to a target machine that only has the runtime system on it?

When you start your LV app (causing the web server to start on the target machine), how long does it take before you can successfully make web service calls to that machine?

We have a web application that began life under LV6 and the Internet Toolkit/G Web Server. There was also a failed attempt at using remote panels thrown in for fun. Now we are running under LV2009 and have migrated to web services fairly well. I don't specifically notice the startup delay you mentioned, but I did also resort to putting a long timeout loop monitoring the server startup (via webserver.app properties) in the application launch frame. Our application starts as a system service, so this delay is probably quite masked for me, thus I didn't notice.

Other issues we faced migrating to web services was the separation between the main application instance and the instance running the web service VI's. This caused some head scratching, but we eventually turned on the main application VI server and called common and global resources held in main memory from application > VI > Call-by-reference wrappers.

Finally, we are now looking at LV2010 and have a big surprise - yet another web server architecture! I am still trying to learn how best to install and configure the Application Web Server for our deployments. I haven't learned very much, but am slowly building up knowledge through the Lava and NI forums. Thanks everyone for posting questions and information!

--

James