Custom Dashboard to Show Connection Information on LLP Listeners

I’ve chatted to four people and nailed down these as interesting projects for tomorrow.

Steven L  from Company G is going to have a go a building out a custom dashboard for Iguana that can display some more information that he wants to see. In Iguana for LLP listener components they display as green when the port is up and listening.  But that doesn’t necessary mean that the counterparty is connected to you.

So Steven wants a dashboard that does that.  This is path I would suggest to getting there:

1. Start off with the channel manager application as the base point.
2. Write a From Translator channel which can use the restful API for the Iguana logs to query the entire logs for messages that related to connections being created and dropped.  The polling should keep a track of when it last polled probably using the store module.
3. The results from query can be munched in Lua to give data what LLP listeners have connections and what do not.
4. This information can be stored in the SQLlite database that drives the custom dashboard.
5. And the custom dashboard can be tweaked to display this data.
6. It will probably be helpful to splice in some auto-update logic for the channel manager dashboard so it auto updates and might well get the nice filter plugin that Bret did.  Looking at the article on jQuery datatable will be helpful here.

It Steven get’s all that done would would be really fun would be to make a link he can click on a channel that could give another page which could give the connection history for that channel.  Should be really straightforward to do that – just a matter of formatting the data coming back from the rest API call for polling Iguana logs.

If one of the dev team is feeling adventurous we might even hack in some extra information into the channel status report to include this extra bit of information – although getting the connection history still makes it a worthwhile activity looking at the results from the restful API for the log.

Hacking the Channel Manager to Export to Two Active-Active Iguana Instances

This is a project that James is going to have a hack at.  So he’s going to start with the Channel Manager and see if can make it possible to push an Iguana channel out to two Iguana ‘production’ instances.  Basically going ahead and running with this idea.

To start with to make it easy what he could do is hack out the information that Iguana already can store in the IguanaConfiguration.xml file that it gets from Settings > Remote Iguana Settings:

That’s will make pretty easy to get going with.  The place that he should start to look at is the guts of the library which actually does the work in the Channel manager which is iguana.channel.  Once he get’s that done he could have some fun making a configuration interface for it with the channel manager and with playing with some of the ideas for enhancements to the channel manager in Iguana Recipes.

Resubmitting messages with a custom form based workflow

So this is something Jaspinder is going to try out.  It’s really common in healthcare to get this type of workflow issue:

• Someone does something in an upstream system.  Maybe they left some fields blank, maybe it’s a lab and there is some kind of unusual lab procedure that has been ordered that has an error with an ICD9 or SNOMED code.
• This results in an HL7 messages which creates an exception
• Some interface person or ‘subject matter expert’ with clinical or administrative expertise has to go into Iguana and manually edit the HL7 message and re-submit it through the system.

So instead of this the idea is to make a nicer work flow.

• We have a filter which picks up the HL7 transaction with an issue.
• We drop it into a SQLlite database.
• We use the net.smtp.send{} to send an email with a URL that goes to a custom dash board that
• (we could even be clever and hack the information out of IguanaConfiguration.xml to get the email addresses of a group of users we want to notify)
• In the custom dashboard the operator would see a dashboard of all the messages that they need to deal with.  Might as well hack the bed monitor application as a starting point.  In fact hacking all three channels from that app would be a good starting point.
• Clicking on a message would take you to a screen that not only shows you the raw HL7 message but also gives you a friendly form which has nice fields that the user can edit to change the data in the message.  It shows the form of the HL7 message going out.  When it’s all good the user clicks on a ‘submit’ button and…
• A good way to achieve that – do a bit of trivial HL7 –> JSON mapping on the Lua side – map out 5 key fields.
• Display the the 5 key fields + raw message in the field.
• The HL7 message is resubmitted back to the channel in question.

He can use the resubmit API module I wrote back a while ago.

I’m excited to see this idea come to fruition – it’s a really common work flow problem.

Reverse engineering a python based vmd to regression test it.

This is a fun one!  Sergei is going to try his hand at this one working with Bret Dawson our resident Lua Spin Class expert to hack the regression testing utility Bret wrote to try and help replace some older python/vmd based code he has.

The code takes a large HL7 message and spits out some text files.  So this what we have in mind doing:

• Take the regression testing application which already looks at the Iguana dashboard.
• Find the channel with the vmd in question.
• Locate the vmd on disc.
• Convert the vmd into XML format.  Maybe it could uploaded into Iguana’s channel API.  Maybe use popen to call out to the command line vmd_tool to convert it into XML.
• Use a bit of trickery to modify the XML of the vmd file to overwrite the python code which writes to a file.
• Instead have use ‘log’ or print from Python.
• Then we grab the output we get from chm.parse or chm.transform to see what came out.
• Then we can modify the regression testing app to look at this output as our ‘expected output’ and compare it to an equivalent Lua routine.

Lot of neat APIs to use in that one!

Get the global monitor to request back configuration information

This is a project that Ryan will be working on.  It should be quite do-able.

The concept is just changing the global monitor and agents to that you can have an agent receive commands from the global monitor when they phone home. To start with an easy incremental step would be to make it so that one could stop and start a channel on one of these remote Iguanas.

How would you do it?

1. The central application just needs to maintain a data structure in memory or in SQLlite that stores commands that it wants a remote agent to execute.
2. When the remote agent connects, in the response it get’s back the commands from the server.
3. The agent then executes the commands.
4. And sends the results back to the server afterwards.

Now if you really wanted to get fancy it would be possible to use the iguana.channel library to do upgrades of the agent code on the fly from the central server…

Managing code contributions from many disparate sources

This is project for Laurie.  Simple but a really useful goal to figure out how to leverage the channel manager combined with a tool like GIT to manage a large set of interface code to make it possible to work with a distributed team.

So that’s going to involve some sitting down and learning how to use GIT and see how the work flow could work with such a tool.

Filtering errors from Iguana and ignoring unimportant ones

So Casey will be building a non graphical monitoring utility with the following goals. There are lots of errors that are spurious that no one wants to be woken up to deal with.  i.e. someone logs in with the wrong user name.

So Casey we having a go at building a From Translator instance which wakes up periodically and uses the restful API to query the errors out of Iguana.  There will some Lua logic to go through and filter those errors to screen out the spurious ones.  Then a nicely formatted email will be put together which get mailed out.

So need to look at the restful API for the Iguana logs and the code will use net.smtp to send the email.  Another nice flourish at the end would be to extract the email addresses of the people that the email should be sent to from IguanaConfiguration.xml.

Another nice trick might be to do what James is doing to get the list of remote instances from IguanaConfiguration.xml.

Custom Portal Dashboard for Clients

Roberta is from a very large laboratory that support real time requests for lab procedures outbound into their business and sends the results of these lab procedures back to their clients.

Being a highly service orientated business Roberta’s lab want’s give clients a lot of visibility into custom dashboards which show the status of their interfaces. They not only want to show things like whether or not TCP/IP are up or down but be able to drill down and show detailed information on the status of particular orders.

i.e. imagine a lab order comes in, it has some key statistics on it like an ascension number, patient id and then we want to be able to see key things like was the lab order received, has it been done, was the result successfully send back to the sending system.

That’s quite a lot to do given it’s 11:30 🙂 So we’ll start small.

Roberta’s goal is to hack the channel manager so that it show a sub set of channels which belong to a client and show green light/red light status.

The first hack will be to figure out how to limit what channels are shown.  We’ll go for a cheap and simple solution to this which is we’ll put some tags into the description field and use that to filter out channel information.  i.e. “user:jono”.

We’ll get the user name from the basic authentication and then filter channels we show based on that user name.

The channel manager doesn’t do live updates so for extra points we’ll enable that in the code by copying some tricks from the bed manager.

Caching an authentication token

This is a challenge for Laura – one of the systems she needs to talk to via webservices has an API which needs to be called to get an authentication token.

There are some performance problems with the back end system which doesn’t want this call to be done too often.  They need Laura to cache the token for 60 minutes before re-issuing the command.

So during production it would be great to cache this in memory for performance and avoid having moving parts that could make the channel less reliable.  In the Iguana sandbox it needs to persist this information to disc since the script is constantly being recompiled.  It would be really handy to have basically a ‘store’ module which is persistent to disc while in test mode, but is in memory while in production.  If fact one could probably write this an 5 lines of code on top of the store module…