• Introduction
• Bed Monitor
• Channel Manager
• Monitor Iguana
• Unit Test
• Web Service

Introduction

One of the cool things about Iguana is that it is actually a fully fledged development environment. Because of this you can do so much more with it than you can with a traditional interface engine. For example it’s easy to build mini applications and utilities on top of Iguana.

We noticed that many of our customers were implementing very similar utilities to manage what they do with Iguana. This inspired us to build and share the Iguana apps that are available in this repository.

Simply add this repository from github https://github.com/interfaceware/iguana-apps and import the channels that you are interested in. Then review the comments in the code, and read the corresponding sections (below) in this article. These apps were originally created for Iguana 5, so you may also find the Iguana Apps (Iguana 5 documentation) section interesting.

If you need help with creating your own apps, or are simply wondering if what you are thinking of is even possible (clue: it probably is…), please contact us at support@interfaceware.com.

Bed Monitor [top]

The application consists of three channels:

1. Bed Monitor – 1.Fake ADT Feed: Generates a dummy ADT feed.
2. Bed Monitor – 2.ADT In: Processes this feed and populates a SQLite database with the bed status information.
3. Bed Monitor – 3.Web Dashboard: Presents this information in the web dashboard.

This is a simple dashboard application for viewing bed statues in an (imaginary) ER department. It’s a good starting point for creating custom dashboards, just adapt the code for your own needs.

To see the dashboard in action just run all three channels, and connect to the bedmonitor url: http://l<iguana address>:<port>/bedmonitor/ (default = http://localhost:6544/bedmonitor/).

The dashboard will take a few minutes to fully to populate, as the (imaginary) patients continue to arrive.

Channel Manager [top]

The application consists of one channel:

1. Channel Manager: This is the complete channel manager app.

The Channel Manager application has been superseded by Iguana 6’s built in ability to import and export channels.

However the (Git) repository structure we are using in Iguana 6 is different from the one we used for the Iguana 5 Channel Manager. This means Iguana 6 cannot import channels from repositories created by the Iguana 5 Channel Manager.

To get around us we updated the channel manager to you allow you to import from version 5 repositories. However there is a catch, the save milestone API changed in Iguana 6 so that it requires a list of files. This version of the channel manager works around this change by not saving a milestone. In some ways this is better since you can then check what has been imported and make sure it doesn’t overwrite any useful modules you have.

The version 6 Channel Manager is really only intended to help you migrate existing Iguana 5 channels.

Monitor Iguana [top]

The application consists of two channels:

1. Monitor – 1.Agent: This is the channel that posts status home.
2. Monitor – 2.Dashboard: Presents this information in the web dashboard.

A common problem for any vendor of significant size is how to monitor a large number of Iguana instances that are located behind firewalls at customer sites. We created this monitoring app to solve exactly this problem.

How it works is simple:

1. On each monitored instance of Iguana you install a Agent Monitor channel as a From Translator channel.
2. Every few minutes this wakes up, queries the status of the local instance of Iguana using the monitor API.
3. It then uses HTTP to post that data back to a central instance of Iguana.
4. The central instance of Iguana listens for incoming HTTP requests from the agents and logs that data into a simple SQLite database.
5. The same central instance also is used to serve up an HTML dashboard which shows the status of the Iguana instances.

Here’s a screenshot of the dashboard:

Only one row is showing in this case. If you click on that row you’ll see all the low level health statistics of the particular Iguana instance

The  exciting thing is not the pretty dashboard, but what you can do with it. Think about the possibilities:

1. The agents are all simple and dumb.
2. All the data is easy to get to in a central location, and thanks to Iguana translator – dead easy to manipulate.
3. So that makes it simple to run automated checks on the data so that you can power automated alerts which instead of bombarding you with incomprehensible email notification spam can instead point to this dashboard.
4. You can customize what is displayed in the dashboard to your heart’s delight.

Unit Test [top]

The application consists of two channels:

1. Unit Test – 1. GUI: xxx.
2. Unit Test – 2. Tests: xxx.

One thing that became pretty darned obvious to us early on with these apps is that a solid regression testing system is a necessity.

One area I felt the pain was in some of the work I did with refactoring the first version of the Channel Manager.  I’d fix a bug on Windows and introduce a bug on Mac OS X, then go edit stuff on a Mac and break it on Windows, and so on. Putting in a file abstraction layer (Iguana 5 documentation) to smooth over some of the differences between Windows and the rest of world helped, but one truth remains: for non trivial development, you need to have regression testing in place. Without it, it’s tough to know what you’re breaking as you develop new features.

We have a lot of regression testing in place in the core of Iguana, but we don’t have a really nice blueprint for how to do unit testing with Lua in the Iguana translator. So when our QA engineer, Wade, announced he’d run out of work last week, I taught him how to write an Iguana web app and pointed him at the spinner library Bret wrote for our first regression testing application. In less than a day Wade had a working prototype of what has the potential to be an amazing regression testing system.

The spinner library (Iguana 5 documentation) basically makes it a doddle to spin up a translator instance on a remote Iguana instance, populate it with Lua code, and breathe the beastie into life (Prometheus unbound anyone ? ).

Wade was able to do is clip that library together with a unit test I wrote for the file abstraction library (Iguana 5 documentation) and build an app that at the click of a button:

1. Loads the unit test off disk.
2. Installs it on to a mini farm of Iguana servers running on Windows, Linux and Mac.
3. Call the unit test on each server.
4. Brings back the results and reports them.  Ta da!

Obviously it’s a starting point, since we want to make this run automatically as commits come into the repository. But we should have no trouble doing all sorts of neat things with it. Because it’s so easy to grab data using HTTP, it should be possible to point it at an arbitrary repo with Iguana channels in it and have it run tests.

The application is in the Iguana app repository now.  Wade has made it configurable so you can add as many Iguana hosts to test against as you like:

 

Wade has also styled the output to go into a data table:

We may change this over to use a tree control later.  Wade is working on adding support for triggering the unit test suite when GIT commits are made.

Web Service [top]

The application consists of two channels:

1. Webservice – 1. Service: xxx.
2. Webservice – 2. Client: xxx.