IG HTTP Library

Recently, I wrote about running LabVIEW in a Docker Container inside Linux. I've also been playing around with LabVIEW Web Services for one of my clients. I thought, "Hey, it would be cool to put some LabVIEW web services in a Docker Container." Well, not so fast. Even though LabVIEW Web Services will run on ni-linux-rt, apparently they don't work on Desktop Linux. Why? Who knows? Boo.

Then I remembered that my friend, Derrick Bommarito, had created this IG HTTP server library. I have to say, when I first looked at the Readme in the GitHub Repo, I thought, "This looks a little complicated." I was overwhelmed as Derrick's web server does way more than what I wanted to do. It does appear to be quite flexible, and as it turns out, it was plenty capable of doing exactly what I wanted.

Once I discovered what needed to be done, creating a web service was actually pretty easy. Create a class with two overrides and a boilerplate VI to spin everything up, and that was pretty much it. All the info is in the Readme in the GitHub Repo, but it still took a little time to figure it all out. So I decided to write down what I discovered here so that perhaps others can benefit and Derrick's tool can get a little more traffic.

Initial setup

First of all, you need to install the IG HTTP library from VIPM. That will get you an IG HTTP palette. From there, you need to recreate the VI up above. That part is pretty straightforward until you get to that object cube, which we'll talk about in a second. Once you get that set up, that is your main server VI. That is what you are going to run when you want to start up your server. It's basically simple boilerplate stuff.

The Controller

In order to mimic LabVIEW's built-in web services, you are going to need to create a Controller. Note, I am just using one controller, but you can have multiple. Your Controller is a class that needs to inherit from the HTTP Server:Controller Interface. Then you need to create 2 overrides: Do Request and Get Path Regex.

The get path regex.vi tells the server what URLs you want to be serviced by this controller. You could do something simple like index.html, or you can get way more complicated. One thing to note is that if you create capture groups here, those become available when processing the request. This regex simply matches anything and creates a capture group for everything after the first slash.

The do request.vi is what gets called when a request hits a URL matching the previously defined regex. The main thing you need to do here is set the response. There is a set generic response VI - the blue one - that lets you set the response text and a status code. In this example, I just take capture group 1 - everything after the first slash, and just echo that back along with Hello.

At this point, we've built our web service. Now we need to test it. You need to pick an unused port. You also need to turn off the always secure boolean, since we haven't set up an SSL Cert yet (although apparently support for HTTPS is built-in - you just need to supply the cert). If you just run this main VI, then your web service will be up and running.

You can test your web service by going to localhost on whatever port you entered above. It should echo hello, followed by whatever comes after the first slash.

Congratulations, you've now created a web service that can run on a Linux Desktop and also inside a Linux Docker Container! Of course, now you can go make your Do Request do something more interesting. It can do pretty much anything you can do in LabVIEW. Have fun! Derrick did want me to add that if you build this into an executable, you may run into some issues with some classes not getting included in the build. If so, make sure you try cube-dropping any classes that you made.

Need Help?

Need help setting up web services for your LabVIEW project? We can help. Let's talk. Use the button below to reach out.