Published on September 19, 2022.

One of the projects that I've been working on recently is a "reboot" of a client's Tulip implementation. I'm using Tulip to build an app that will help streamline my client's manufacturing process, including the picking of parts, the build process, quality control and inspection, packing, and more. The app tightly integrates with NetSuite, and makes heavy use of Tulip custom widgets.

The Mixed Content Issue

While working on the project, I ran into an interesting and challenging issue involving printing to their Zebra printers. These printers can be connected to workstations using USB cables, where print requests are sent directly, or connected wirelessly, where requests are sent as HTTP POST requests. My client is using the HTTP method, which allows then to easily route print requests to specific printers in their warehouse. If a printer becomes unavailable for some reason, the operator will be able to route requests to an alternate printer. Additionally, this will give them the option to print specific labels on printers that are setup with the necessary label types.

The issue that I ran into had to do with "mixed content." The Tulip app is essentially a Web app that is served up over HTTPS, while the Zebra printers are only designed to accept HTTP requests. The error that I could see via the Tulip console was:

Mixed Content: The page at 'https://developer-tim-dietrich.tulip.co/w/1/player' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://192.168.1.154/pstprnt'. This request has been blocked; the content must be served over HTTPS.

While researching the issue, I stumbled upon this post. There's a solution mentioned in that post, which involves loading an SSL certificate on to the Zebra printers. However, the printer model mentioned is what my client is using - and this solution seems less than ideal, because we'd need to load certificates on to each of my client's printers, and also renew them.

Xojo to the Rescue

My solution was to use Xojo to develop a custom Web application that essentially acts as a proxy between Tulip and the Zebra printers. The Web app listens over HTTPS for POST requests, and then routes them to a printer over HTTP.

I'm using the Xojo Web Application framework's "App.HandleURL" event handler to listen for incoming HTTP POST requests and process them. I then use an instance of the URLConnection class to send an HTTP request to the specified Zebra printer. To determine what printer the request should be sent to, the Tulip custom widget sends the request to the Xojo Web app using a special "X-Relay-To" HTTP header. The Xojo app looks at that header value, and then relays the request to the printer at that address.

There are several benefits of using Xojo for this solution. One is that we only need a single instance of the Web app running on the client's local network. That single instance can serve all of the Tulip workstations. The app is compiled and can run on a low-cost Raspberry Pi device, so the deployment cost is very low. And finally, we're able to use a wildcard certificate issued by Let's Encrypt, so our certificate cost is zero.

This is a great example of how you can use Xojo to quickly, easily, and inexpensively develop highly customized solutions that meet your very specific needs.