From Saturday, Nov 23rd 7:00 PM CST - Sunday, Nov 24th 7:45 AM CST, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Saturday, Nov 23rd 7:00 PM CST - Sunday, Nov 24th 7:45 AM CST, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
This article applies to LabVIEW 8.6, 2009, and 2010. In LabVIEW 2013 and later, you can more easily create, debug, and publish LabVIEW Web services. Refer to the LabVIEW Help for your version of LabVIEW to learn about LabVIEW Web services capabilities.
Support for Web services was introduced in LabVIEW 8.6 for Windows and LabVIEW Real-Time Targets. The Web services runtime engine in 8.6 and 2009 is loaded and run by LabVIEW's built-in Web Server. The Web Server is also available for use on Macintosh and Linux versions of LabVIEW, but without Web services support. Web services development requires a Windows version of LabVIEW 8.6, 2009 or 2010 with a Full or Professional license.
In LabVIEW 2010 the Application Web Server is installed and runs by default on Windows PCs. This web server hosts all LabVIEW-built Web services and launches at system boot. Unlike earlier versions of the LabVIEW Web Server, the Application Web Server does not require LabVIEW to be running. The Application Web Server can be configured through the NI Web Configuration and Monitoring utility in a web browser. To use this utility you must install Microsoft Silverlight®. To launch the Web Configuration and Monitoring utility for your local machine, point a web browser to http://localhost:3580. From here you must select the Web Server Configuration Tool.
To enable the Application Web Server for Real-Time targets, you must install the NI Application Web Server to the target. In order to remotely configure the Application Web Server on an RT system, you must also install NI System Configuration, NI System Configuration network support, and NI Web-based Configuration and Monitoring.
LabVIEW Web services do not support the SOAP or the WS-* specifications. LabVIEW publishes VIs as server-side RESTful Web services. For an explanation of REST, see the Wikipedia article on Representational State Transfer at: http://en.wikipedia.org/wiki/Representational_State_Transfer.
Not at this time.
LabVIEW 8.6 does not support invoking Web services using SSL. LabVIEW 2009 and 2010 do support invoking Web services using SSL.
LabVIEW Web services supports digitally-signed requests. If you wish to encrypt data sent to or from a Web method VI, you can add encryption to the content-bodies of HTTP requests using publicly-available encryption algorithms.
You can invoke Web services in LabVIEW 2010 by using the LabVIEW HTTP Client API. This API is not available for LabVIEW 8.6 or 2009. To access this API, select Functions Palette»Data Communication»Protocols»HTTP Client. SSL support (HTTPS) for the HTTP client requires the LabVIEW Internet Toolkit 2010.
In LabVIEW you can debug Web services in the same manner as debugging any LabVIEW built stand-alone application or shared library. Use the following procedure to enable debugging features on a Web service deployed to either Windows or LabVIEW Real-Time targets.
1. In the Web service build specific property page, go to the Advanced category and check the Enable Debugging checkbox.
2. Add a breakpoint to your Web method VI.
3. Build and deploy the Web service.
4. Go to Operate»Debug Application or Deployed Library and select the Web service.
5. Using any HTTP client to call a Web method that includes a breakpoint.
LabVIEW will open the Web method VI and pause at the breakpoint. You can add probes, single step through the VI, or use any other standard LabVIEW debugging tools.
A LabVIEW Web service is built from the LabVIEW Project Tree when you right-click a Web service build specification and click Build. During the build process, LabVIEW loads each of the VIs selected for publishing as Web services (the Web Method VIs) and auxiliary VIs (LabVIEW 2010 only).
LabVIEW then builds a tree of all the sub-VIs used by these top-level VIs, and continues loading these sub-VIs, until it identifies all the sub-VIs that can possibly be referenced by the Web Method VIs. LabVIEW then prepares the VIs for runtime, applying any options selected in the property pages of each VI, and cross-compiling (if necessary) the VI for the target processor and runtime environment. For Web service applications, the ultimate output of this build step is a .lvws file where the name of the .lvws file is the same as the Web service name. This file is actually an archive in the .zip format containing, at minimum, the following:
The .lvws file may also contain:
Web services are typically deployed by right-clicking on the build specification in the Project and clicking Deploy.
Note 1: There is no 'Build and Deploy' option; so any time you make a change to a Web service application, be sure to build first, and then deploy. Forgetting to do this is a common errors when using LabVIEW Web services.
Note 2: Before deploying your Web service application, be certain to enable the Web server and the Web services feature for the target. Forgetting to do this is another common error when using LabVIEW Web services.
If the VIs, shared libraries, and data files contained in the .lvws file are complete and self-contained, the output file can be manually deployed (via FTP or copy) to any directory on the target machine as-is. Once the output file is manually deployed, it is automatically detected, unzipped, and installed by the NI System Web Server.
Some Web service applications, however, require non-VI project items, such as Shared Variables and DAQ Channels. Due to how these non-VI project items are deployed, they cannot be built into the .lvws files. Instead, they must be deployed through the project. Unfortunately, there is no current mechanism to tell whether a given application requires deployment this way or not. The safest approach is to always deploy Web services from the Project.
See also Scripting in LabVIEW Web Services
The Web Server supports HTML pages with embedded scripting. The scripting language it supports is called Embedded Server Pages (ESP), which is very similar to JavaScript. You can use server side scripts to separate the business and presentation logic in a web application.
In order to execute an ESP script from a Web method VI, use the Render ESP Template VI. This VI can be found in the Web Services palette. To use an ESP script in a Web method VI, follow these steps:
When the Web method VI is executed by an HTTP request, the ESP script is executed by the Web method.
You can pass parameters to the ESP script by setting them in the Web method VI using the Set ESP Variable VI, which is also found on the Web Services palette. This VI takes the name and value of the parameter to be set and creates a form variable that you can access from the ESP script.
The accompanying labview_esp_demo.zip, attached below, contains a LabVIEW 8.6 project and Web service that demonstrate using server-side scripting to generate output. A brief reference for our implementation of Javascript is included in a separate online tutorial for Scripting in LabVIEW Web Services.
When a Web method is invoked to process an HTML form, the fields in the form are sent to the Web Server. HTML forms support HTTP GET, POST, PUT and DELETE methods.
When the form method is GET or DELETE, the parameters are encoded query parameters in the URL. For POST and PUT methods, the parameters are sent as the content of the request.
The accompanying HTML_Form_Example.zip, attached below, contains an example LabVIEW project that demonstrates how forms can be setup to generate GET and POST requests for a Web service. The example also shows how you can use VIs on the Web services palette in a Web method VI to access the query string (for a GET/DELETE request), and the ‘postdata’ and the values of individual form elements (for a POST/PUT request).
Web services in LabVIEW 8.6 supports only GET and POST requests. LabVIEW 2009 and 2010 also support PUT and DELETE.
In addition to the Build and Deploy menus on the project tree, you can also build and deploy a Web service programmatically using a VI.
LabVIEW provides G APIs to open a project and access all members defined within the project. Using the invoke node, you can programmatically open a project. You can also access the targets defined in the project using a property node.
LabVIEW provides VIs that can create a build specification defined on each target. The invoke node provides methods to deploy the built specifications. Libraries included in a project can be deployed via an invoke node using the 'Library.Deploy Library' function defined on the Application class.
The accompanying Build_and_Deploy_Example.zip, attached below, contains a sample LabVIEW 8.6 project and Web service, along with a VI called Build Sample Project - Desktop and RT.vi. This VI demonstrates how to programmatically build and deploy a Web service build specification defined within the sample project.
NOTE: This example demonstrates how to programmatically build and deploy a Web services build specification. The behavior of this example for other build specification types has not been tested.
Unlike previous versions of LabVIEW, Web services built in LabVIEW 2010 do not require the LVWS file to be installed in a particular directory in order for final deployment to occur. Users can install the LVWS file in whatever directory they find to be the most appropriate for their installer.
Static document refers to any document that is complete and ready to deploy as-is at build time. Static documents can be included in the LabVIEW Project in order for an HTTP client to request it directly with a URL. Once requested, the Web Server and the Web service runtime would transmit the entire content of the document to the requester without modification. The most common examples of static documents are HTML documents, XML documents that are known at build time, server-side script source code (.esp), and media files (.jpg/jpeg, .gif, .png, etc.).
For example, you have an HTML document called hi_there.html that you would like to be displayed from a Web service called hello. Here is the method we recommend:
Now, when you build and deploy your Web service, it will contain a folder called 'html', which contains all the files that were inside the 'html' virtual folder when you built the project.
To retrieve 'hi_there.html' from the web service 'hello', open a browser and enter the URL:
http://<IP address or DSN name>/hello/html/hi_there.html
If you have image documents you would like to include with your Web service application, they should be included in the project. Follow the above procedure to create an 'images' virtual folder and an 'images' custom destination in your project. Then, you can include these images from your static or auto-generated web pages using the relative path '/images', as in '/images/image_name.jpg'.
The accompanying Ruby_Security_Client.zip, attached below, contains a LabVIEW 8.6 project and Web service, along with a Ruby client program that demonstrates invoking the included Web services from Ruby. The Ruby client also contains the logic necessary to digitally sign HTTP requests for invoking secured Web services.
Yes, both request and session variables in LabVIEW 2009 and 2010 handle capitalization differently than LabVIEW 8.6.
LabVIEW Web Services Help
Official documentation for LabVIEW 8.6 Web Services.
LabVIEW Web Services Security
Additional information on securing your Web service.
Default Values for the LabVIEW Web Server
Describes some default values that the LabVIEW Web Server on desktop and LabVIEW Real-time systems.