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.

LabVIEW Web Services FAQ

Overview

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.

Contents

What LabVIEW versions/platforms support Web services?

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. 

Do Web services support soap or the ws-* Web service specifications?

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.

Do Web services work on Mac OSX or Linux?

Not at this time. 

Do Web services support SSL? 

LabVIEW 8.6 does not support invoking Web services using SSL.   LabVIEW 2009 and 2010 do support invoking Web services using SSL. 

Do Web services support any other type of encryption?

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.

How do I remotely invoke a Web service from my G-based applications?

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. 

How do I debug Web services?

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.

What happens when I build my Web service?

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 VIs, compiled for the target platform, collected inside the file 'internal.llb'. 
  • A configuration file called 'Webservice.ini'.

The .lvws file may also contain:

  • Folders and data files selected by the developer (in the Build Specification's Source Files category) to be 'Always Included'. These might include image files (.jpg, .gif, .png) as well as HTML files, XML files, or any other sort of static document. 
  • If any of the sub-VIs requires a separate shared library (DLL or .out file) for operation, these are included in the archive as well.

What happens when I deploy my Web service?

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.

How do I use server-side scripting to generate formatted output in a Web service?

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:

  1. Create an ESP script.
  2. Add the ESP script to the Web services project.
  3. In the Web method VI, use the Render ESP Template.vi. Wire the path of the ESP script, relative to the deployed web service root directory as input to the Render ESP Template.vi.
  4. Build and deploy the web service.

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.

How do I use HTML forms with my Web services application?

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.

How do I programmatically build and deploy my Web service?

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.

(LabVIEW 2010) How do I create and install a built application containing a Web server and Web services VIs?

  1. Create and test your Web Service on your development machine and ensure it has been appropriately validated. 
  2. Create a new Installer build specification by completing the following steps:
    1. Include your Web Service (LVWS) file in the Source Files category of My Installer Properties.
    2. Additional Installers: Include the following Installers in addition to those necessary for your application –
      1. NI LabVIEW 2010 Run-Time Engine
        1. NI LabVIEW 2010 Run-Time Engine Web Services
        2. NI SSL Support (if the Web service uses SSL)
        3. NI System Web Server
        4. NI Web Application Server
    3. Build your installer

Install the Built Application

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. 

How do I serve static documents from my Web service?

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:

  • A LabVIEW Project containing at least one VI 
  • A Web Service Build Specification for the above project, with the Service name set to hello 
  • An HTML file called hi_there.html
  1. Create a folder on disk called html and place the hi_there.html file (and any other HTML documents you'd like your service to be able to send) into the new folder.
  2. Create a virtual folder in the project by right-clicking the target (My Computer or an RT target) and select New»Virtual Folder. The folder can be named anything, but it helps to give it the name you wish to use in the URL. In this case, call the folder html.
  3. Convert the folder to an auto-populated folder, by right-clicking on it and selecting Convert to Auto-populating Folder from the shortcut menu. The folder icon in the project tree will change.  The auto-populated folder now contains references to the hi_there.html file and any other documents you placed into the folder.
  4. In your Web Service build specification, under the Source Files category, select the html folder itself (do not select the hi_there.html file or any other individual file inside the folder) and add it to the Always Included section on the bottom right of the Source Files page.

    Note: You cannot follow step 5, below, unless there is at least one VI in the project. This is an inconvenience that we will correct in a subsequent release of the Web services feature. If you do not have any VIs in your project at this time, create a VI that does anything at all, save it, and add it to the Source Files in the Web Service Build Specification.
  5. In the URL Mappings category of the Web Service Build Specification, click the blue '+' symbol to the right of the URL mappings list to add a URL map for the html folder. This URL mapping should match the name of the folder that contains the static documents, and should include a leading forward-slash, making it relative to the root of the web service. The URL mapping should not include the filenames of any specific static files. In this case, use '/html'. Press enter to save the new mapping then, keeping the '/html' mapping selected, click the Static document radio button to tell LabVIEW that this mapping refers to a static document instead of a Web method VI.
  6. Create a custom destination in the Web service for the 'html' folder. In the build specification's Destinations category, add a new destination called 'html'. Set its label to 'html', as well. The destination type should be set to 'Directory'.
  7. In the Source File Settings category of the build specification, select the 'html' folder in the displayed Project Tree, and check the box labeled 'Set destination for all contained items' Then, set the drop-down menu below to the custom destination 'html' that you created in step 6.


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'.

How do I invoke LabVIEW Web services using Ruby?

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.

Do request and session variables behave differently in LabVIEW 2009 and 2010?

Yes, both request and session variables in LabVIEW 2009 and 2010 handle capitalization differently than LabVIEW 8.6.

Related LabVIEW Web Services Documents on ni.com

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.

 

 

Was this information helpful?

Yes

No