LabVIEW Web Services

What LabVIEW versions/platforms support Web services?

LabVIEW 8.6 introduces support for Web services for Windows and LabVIEW RT targets. The Web services runtime engine is loaded and run by LabVIEW's new, built-in Web Server. The Web Server itself is also available for use on Macintosh and Linux versions of LabVIEW 8.6, but without Web services support. Web services development requires a Windows version of the LabVIEW 8.6 ADE with a Full, Professional, or Student Edition license.

At runtime, on both Windows and RT systems, you must specifically enable both the Web Server and the Web services feature. To enable and configure the Web Server and Web services on Windows go to Tools>>Options>>Web Server: Configuration. To enable and configure the Web Server and Web services on a LabVIEW RT target, add the target to a LabVIEW project, right-click the target, and go to Properties>>Web Server: Configuration. Once they are configured, the Web Server and Web services runtime engine start when LabVIEW starts. All previously deployed Web services are loaded and available.

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

LabVIEW 8.6 Web services do not support the SOAP or the WS-* specifications. LabVIEW publishes VIs as server-side RESTful Web services. See the Wikipedia article on Representational State Transfer at: http://en.wikipedia.org/wiki/Representational_State_Transfer for an explanation of REST.

Does Web services work on Mac OSX or Linux?

Not at this time. 

Does Web services support ssl? 

LabVIEW 8.6 does not support invoking Web Services using SSL.

Does the Web services feature support any other type of encryption?

LabVIEW 8.6 does not support any built-in encryption for Web Services requests. Instead, we opt for digitally-signed requests. If you wish to encrypt data sent to or from a Web Method VI, you could 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?

We do not currently have an HTTP client implemented as a LabVIEW VI. We are evaluating options for HTTP clients at this time.

How do I debug Web services?

Debugging a deployed LabVIEW Web service can be a challenge. VIs running in an active LabVIEW Web service are no longer linked to the VIs in the original project and, as a user, you have little access to the LabVIEW Web services runtime engine executing the Web service VIs. Debugging Web service VIs on Windows platforms is possible, but debugging on LabVIEW Real-Time platforms is not directly supported. This article will outline several options and strategies for debugging LabVIEW Web services.

Debugging Web services on Windows

You can use standard LabVIEW debugging tools to debug a Web service deployed to the local Windows target. Use the following procedure to enable debugging features on a Web service. 

• On the Source File Settings page of the Web service build specification, manually disable the options to remove the block diagram and front panel, either for particular VIs of interest or globally.
• Add a break-point to the source VI
• Build and deploy the Web service

LabVIEW should catch the breakpoint the next time you invoke the Web service from your HTTP client. You can add probes or single step through the VI. 

You can debug an already deployed Web service if the Web service VIs were built without removing the VI block diagrams. Find the deployed Web service on disk and open the VI you want to debug. Make sure the original source project is closed before opening the deployed version or you will likely run into crosslinking issues. Add a break-point and then save the VI. The next time you invoke the Web service LabVIEW should stop at the breakpoint.

It's worth noting that in some cases you can just run and debug your source VI directly prior to deploying the Web service that contains it, if the VI does not functionally depend on running within the Web services runtime context. This essentially means that the Web method VI does not use the httpRequestID input terminal and any of the Web services VIs (Connectivity>>Web Services palette) that require it as an input.

 

Debugging Web services On Labview Real-Time targets

You cannot use standard LabVIEW debugging tools to debug a Web service deployed to a LabVIEW Real Time target. Instead, you must devise other methods of debugging your Web service.

• Write diagnostic output data to a shared variable deployed on the same target.

• Write diagnostic output to a log file on the target.

• Write diagnostic output to an output terminal if your Web method uses terminal output mode, or to the end of your content body if it uses streaming output.

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

LabVIEW then builds a tree of all the sub-VIs used by these top-level VIs, and continues loading their sub-VIs, etc..., until it has identified 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 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'. This 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'; so any time you make a change to a Web service application, be sure to build first, then deploy. Forgetting to do this is one of the most 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 of the most common errors we've seen when using LabVIEW Web Services.

On Windows, the Web server configuration is in the Tools>>Options menu of LabVIEW. In the Web Server configuration, enable the Web Server and the Web services feature, and then apply your changes. The Web Server starts automatically as soon as you click OK.

For RT targets, such as cRIO and FieldPoint controllers, the Web Server configuration is in the Web Server category of the target's Properties menu in the Project. In the configuration dialog, after enabling the Web Server and the Web services feature, you must right-click the target in the Project and click Deploy before the Web Server and the Web services engine are enabled. You MUST do this BEFORE attempting to deploy the Web services application.

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 the installation directory on the target machine as-is, where it is automatically detected, unzipped, and installed by the Web services runtime engine.

Some Web service applications, however, require non-VI project items (Shared Variables, DAQ Channels, etc...). 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), and is very similar to JavaScript. Server side scripts can be a handy tool to use to be able 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.

Parameters can be passed to the ESP script by setting them in the Web method VI using the Set ESP Variable VI, also found on the Web Services palette. This VI takes the name and value of of the parameter to be set and creates a form variable that can be accessed from the ESP script.

The accompanying esp_demo.zip 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 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 support only GET and POST requests. We will include support for PUT and DELETE requests in a subsequent maintenance release.

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 also can 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 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.

How do I create and install a built application containing a Web server and Web services VIs?

Create the built application and installer

1. Enable the LabVIEW Web Server and Web Services features under Tools >> Options >> Web Server: Configuration.
2. In your LabVIEW project, create, build, deploy, and test the web service you want to include in your built application.
3. Create a copy of niwbeserver.conf in your project directory. LabVIEW's niwebserver.conf is located in the same directory as LabVIEW.ini. Copy the LabVIEW.ini to the project directory. Add these copies of LabVIEW.ini and niwebserver.conf to the project.
4. Before proceeding, disable the LabVIEW Web Server. This will prevent LabVIEW from overwriting the contents of the local copy of niwebserver.conf when you create the built application. Important: Remember to turn back on the LabVIEW Web Server later on when you need it!
5. Edit the niwebserver.conf file...
   - CustomLog "./logs/access.log" "%h %l %u %t \"%r\" %>s %b"
   - DocumentRoot "c:/www" (you'll need to manually create this folder on the target machine).  This folder can be anywhere but you should specify an absolute path here.
6. Create a VI in your project that will be the startup VI of your built application, so that the LabVIEW runtime engine will load (and load the web server and web services runtime) when your built application starts.
7. Create a new Application (EXE) build specification...
   1. Information: name your Target Filename (example: Application.exe)
   2. Source Files: add the startup VI you created above. Also, add niwebserver.conf to the Always Included list.
   3. Destinations: add a new destination (example: root) that points to same directory your EXE (e.g. Application.exe) is in.
   4. Source File Settings: For niwebserver.conf, set Destination to the directory your created in the previous step, e.g. root.
   5. Advanced: uncheck 'Use the default LabVIEW Configuration file (LabVIEW.ini)' and instead specify the copy of LabVIEW.ini in your project.
   6. Build your application executable
8. Create a new Installer build specification...
   1. Source Files: In the Destination View manually create the following directory hierarchy under the [CommonAppDataFolder] directory: National Instruments >> Web Services >> UserServices (no space!) >> install. This is illustrated in the screenshot below. Select the web service build specification from the Project View, and click the arrow to add the .lvws file from your web service to this install folder.  Next add your application build spec to the[ProgramFilesFolder] >> [<your project name>] folder.
   2. Build your installer

[+] Enlarge Image

Install the Built Application

1. Install the application on the target machine.
2. Remember to create the DocumentRoot directory (e.g. c:\www) on the target machine.
3. Run the application on the target machine.

How do I serve static documents from my Web service?

Static document refers to any document that is known at build time (is complete and ready to deploy as-is) and can be included in the LabVIEW Project, with the intention that an HTTP client would 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, if 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:

Ingredients

• 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 choose 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-populate folder, by right-clicking on it and selecting 'Convert to Autopopulating Folder...' from the shortcut menu. The folder icon in the project tree will change and contain references to '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.
   
   Important: Note that 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 have no VIs in your project at this time, create a VI that does anything at all, save it, and add add it to the Source Files in the Web Service Build Specification.
   
5. In the URL Mappings category of the Web Service's 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, we 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. It's 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', setting the drop-down menu below to your the custom destination 'html' that you created in step 6.

That's it!

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://machinename/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 same procedure as above 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 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.

 

Related LabVIEW Web Services Documents on ni.com

LabVIEW Web Services Help
Official documentation for LabVIEW 8.6 Web Services.

Scripting in LabVIEW Web Services
A guide to ESP scripting using LabVIEW Web services and the LabVIEW Web Server.

LabVIEW Web Services Security
Additional information on securing your Web service.

Reader Comments | Submit a comment »