Some basic questions (pre-purchase) of the web development module.

[DoctorAutomatic]

Hi, I'm intrigued by the Web Development module and plan to pitch it to our team but just want some clarifications and answers on a few things. I've made a list of my questions below and would appreciate any user experience or official NI answers/feedback.

The main immediate driver for my interest in this module is that we have a bunch of people that would benefit from various "tool" vi's that our LV team can make. Most would involve the user setting a few config options, providing a raw data file, and receiving back a new file(s) that has been processed in some way. We could install runtime on each person's PC but our enterprise IT policies make this difficult, far too much work, and slow. The idea would be to instead have a single server PC host a variety of these tool applications on the intranet that are then accessed via a browser. The way I envision this would look is that we just give them a link to a main page, let's call it "Handy Department Tools Main Page" which has a list of links to various tools we make, they click on the link for the one they need and up pops the front panel for that application.

1) Is the scenario mentioned above appropriate and easily implemented via the web development module?

2) Assuming we know nothing about hosting a web server, does the module come with everything we'd need to start hosting these pages from a Windows 10 Pro PC?

3) No plugins are necessary, right? A default install of Edge or Chrome will render and allow these web applications to work for the end user?

4) Are there any user/access # limitations to the license?

5) Is the scenario outlined previously (user browses to a local file on their PC to upload to the web app and then receives/downloads a file in return) something that can be implemented easily within the web module or would this require some outside software/infrastructure to move files like that? Is it as simple as placing a typical path control on a front panel and some sort of additional function in the palette to send the client back a file in return?

ETA:

6) How would concurrent access to an application work? Would applications need to be built with reentrancy in mind or does a new siloed application instance get executed for each client accessing the same tool application page?

[IlluminatedG]

1) Possible but you'd need to create or use community tooling to enable things like file uploads. There's no built-in mechanisms in G Web to accomplish this but some examples at https://github.com/rajsite/webvi-experiments can give you an idea of what that looks like. You're going to need to know some web development to get some of this stuff working. There also isn't a great built-in mechanism for page templating so if you want links to other pages within the G Web app itself, you need to add them to every app page that needs to link somewhere else. This isn't much of a problem if you'll only ever want 1 or 2 pages.

2) Yes, though you'll want someone with some IT skills to make sure everything is up to snuff for your company network security requirements. Even within a company secured network it's a good idea to have websites encrypted and using SSL certs.

3) Correct, consumers of a deployed G Web app need no plugins.

4) No restrictions on clients.

5) See #1 🙂

6) G Web applications (all web applications) are not something that runs somewhere and people connect to. Web apps are files that get sent to a client and then run in the client's browser. Though you would have a "backend" application that needs to be written that accepts requests from these apps and assuming that application is written in LabVIEW, all the implementation is up to you. You'd likely create a bunch of LabVIEW Web Services that can handle the requests from the clients such as file POSTs and other data, that then perform the work, or queue up the work to be done somewhere else in the application. If the processing takes some time, for a better user experience you'd want to build something that accepts the file and responds immediately that the web app can then periodically make requests to check the processing status, and then finally download the results once completed.

This is all *possible* in G Web but you'll still need a web developer (someone that knows JavaScript and web communication) to complete this kind of project. G Web is great for simpler UIs for centralized applications but there isn't much built in to get beyond this. It provides the means the integrate JavaScript to expand its capabilities and for something like this you'd be leveraging that a lot. You could eventually get to a point where everything is in place so that someone that only knows LabVIEW and isn't very experienced with the web can build these apps in G Web but that'll be after some initial investment by someone that knows G Web and web development.

[MilanR]

If just starting out I'd highly recommend going through the presentation and doing the exercises shown in How to Build a Web UI for Your LabVIEW-Based Test System. The presentation will help clarify what WebVIs are and the different types of services included in G Web Development Software. It will also help you make a web application end-to-end which is a good starting point to get working and then make iterative changes for your specific goals.

An important take-away (as Derrick describes) is that WebVIs are applications that run on the client in a web browser. Your diagram code is executing on the system itself (PC, phone, tablet, smart fridge) in the web browser on the device. The diagram can do logic completely locally on that device or communicate to other services using network protocols to get the services to do some work.

G Web Development Software includes the editor for making WebVI front panels and diagrams as well as some data services that you can use as part of your application. The presentation gives an overview of those parts and different ways you could choose to setup your application.

After going through the presentation, here are some specific examples that might be helpful:

The way I envision this would look is that we just give them a link to a main page, let's call it "Handy Department Tools Main Page" which has a list of links to various tools we make, they click on the link for the one they need and up pops the front panel for that application.

---

In a web application I'd expect that workflow to look like a page with links to the different tools that a user can click and navigate to (versus a pop-up on the same page). The benefit is having URLs for each tool you can navigate to. The Multiple Top-Level WebVIs example shows that kind of application organization.

Most would involve the user setting a few config options, providing a raw data file, and receiving back a new file(s) that has been processed in some way.

---

Derrick is right that WebVIs don't have file concepts built-in. Part of the reason is that web browsers treat files very differently than desktop applications. For security, web applications running in browsers can't navigate the file directories on disk and open arbitrary content or make changes to arbitrary files.

Instead, you have to use the workflow you have probably seen of explicitly navigating to specific files, manipulating it in the browser web application, and triggering downloads of the new file. Web applications running in all the modern web browsers don't use file paths and can't overwrite files on disk directly.

So G Web Development Software does not have File operations built-in but there are community libraries such as File for WebVI that are pretty good (I'm biased since I posted that one 🙂).

With the File for WebVI library there are several different workflows that I think are relevant to your application:

1. Using the library to have users select a file, load the contents of the file as a value in the WebVI diagram, use logic in the diagram to edit the value, and trigger a download of the new value as a file.
   
   The diagram functions for string manipulation are pretty limited in WebVIs (it is a restricted subset of what is available on LabVIEW desktop) but if you have relatively small or simple to parse files this approach may work and removes the complexity of sending files to a web service for processing.
   
   The File for WebVI library includes a demo app you can try online  that allows you to load text file from the local machine and show the contents in an indicator. It also has a download button that downloads a text file with a custom string.
2. Another workflow enabled by the File for WebVI library is leveraging the File service that is included with G Web Development software. The How to Build a Web UI for Your LabVIEW-Based Test System presentation goes into detail about data services generally. The file service included with G Web Development software gives you a web service where you can upload files and access them from different applications.
   
   The workflow supported by G Web Development software directly is that test software on the network uploads measurement tdms files to the file service and then the WebVI has read-only access to the tdms files. The File for WebVI library gives you additional APIs to more completely utilize the features of the file service in a WebVI.
   
   In that workflow you use the File for WebVI library in your WebVI to have the user select a file, then use the included File Transfer Extension VIs to send the files to the NI Web Server hosting the file service on your local network or to SystemLink Cloud if you want to enable applications that can be used securely over the public internet.
   
   You can then have different applications (LabVIEW, Python, .NET, etc) that talk to the file service and other data apis like tags and messages to download the file and upload new files, update tags, send messages, etc.
3. The last major workflow that comes to mind is creating a LabVIEW web service that has a Web Method capable of receiving files in an HTTP Post Multipart request, doing some logic on the diagram, and responding to the HTTP request with the new result. See Derrick's NI Web Intro - HTTP, GET, & Dynamic Images presentation for a great introduction to LabVIEW Web Services concepts and development as well as the Processing POST Data, Form Data, and Uploaded Files: Accepting Uploaded Files from a Web Client LabVIEW Web Service docs.
   
   In that workflow you use the File for WebVI library on your WebVI diagram to have the user select a file, then use the Post Multipart Ex VI included in File for WebVI to send an HTTP request including a file to your LabVIEW Web Service, wait for the response and trigger a download of the response file.

Hopefully those are useful references for getting started and I think the workflows you are describing are doable leveraging community libraries and examples. As shown G Web Development Software doesn't try to abstract away the concepts of building web applications, you'll have to be knowledgeable about web concepts like web services, HTTP communication, etc.

In addition the community File library or something like it is probably needed for these workflows but it is a community example and not a shipping feature. So as Derrick mentioned you may have to be prepared to dive into the library and make tweaks or add features you need to the JavaScript code that it is built on.