{nule.org}

I’m really happy with the version of HL7 Comm that I’m testing. The screenshot of the version from the previous post is close to what it looks like, and the new feature list is pretty minimal, but it’s shaped up as being pretty much everything I’ve wanted HL7 Comm to be. Namely, a reliable, reasonably easy to use, yet powerful integration tool. As a result the next version will be a nule.org first – a version 1.0.

This next version features some modifications to the core and the integrate clients, specifically to make the threading much more robust and better behaved if you attempt to start and stop the clients. Part of that was the monitoring section of the screen you see below, and that really enabled me to nail the thread code. Now, when you tell it to stop, you can rest assured that processing is really going to stop as you expect. I’ve also added a few nice to have features. Right now the HL7 Client can be told to halt on NACKs (AR or AE), which provides a visible marker to you that something’s wrong with your integration. You can also name your configurations which is displayed in the title bar of the app.

I hope you’ll agree that these are welcome additions to HL7 Comm, but what I’m most excited about is what this lays the groundwork for. Already I have a version called HCM (or HL7 Comm Multi) which runs on top of a tomcat instance and lets you run as many HL7 Comm configurations as you’d like and control them and monitor them from your web browser. This code has a bit of a way to go before it’s easy for everyone to use, but because it’s built on the long-reliable HL7 Comm core (uses all the same integration logic and processing logic) it’s very robust long before it has all the polish I’d like. This is the version I’d like to see people using if they want their HL7 Comm to be a mini integration engine, and you can rest assured that I’m working to make it the easiest to use and most reliable engine around based upon my experiences with all the big names in the field.

The other thing having a 1.0 HL7 Comm clears the way for is to finish the integration clients that I’ve wanted to have all along. I’m really hoping for FTP clients relatively soon as well as a queuing mechanism, probably built on a lightweight database. Then all that’s left is an easier to use front end for the developers. If the interest is there, I’ll build that too.

I know a few of you out there are using HL7 Comm now (though I don’t know how many check this space for updates), but there’s an opportunity brewing were commercial support may become available for HL7 Comm. I know for a fact some of you are using it in your production environments, sometimes perhaps under the radar, so this might be an opportunity for come clean, so to speak, for those enterprises that demand commercial support be available for products. This may also help spur new enhancements that I’m working on like remote administration and monitoring for HL7 Comm.

So please, if you’re interested or might be in the future, hit that contact form over to the right and let me know. Any information you provide will be kept confidential, I’m just trying to gauge interest. Also, if you’re dying for support and need it right now, I can probably help out with that too.

Here’s a shot of an upcoming version, this one adds some useful information about that running state of the HL7 Comm and a number of other enhancements. This is a preview of a version that I’ll be calling HCM, and that’s all I’m going to tell you right now.

Some users of the 0.8 branch of HL7 Comm pointed out that logging clients weren’t exactly working the right way. They would act like any other outbound client and just log the messages sent outbound. It was a three letter typo on my part and it’s been corrected. It should now log properly both from saved configurations and unsaved configurations as well.

In addition to this correction, there’s a new inbound client to provide a way to produce timed events in HL7 Comm. The new client is called InboundTrigger and can be configured to generate a new inbound event on a schedule. This could be used to poll a database on a schedule and perform some action. It is also special in that if you are using it to implement a beanshell logic class in HL7 Comm, and your logic class responds to the inbound message with a NACK (i.e. ack = false), then a new event will be generated immediately, as opposed to waiting for the next poll. This lets you immediately process again in the event you’re polling a database and there are a number of records you wish to process. (A single inbound even can only generate a single outbound even using the beanshell script at the moment.)

One thing to keep in mind if you use the new InboundTrigger client – the sleep time specified is just that, the amount of time the client sleeps before sending a new message. It is not the same as the amount of time between when messages are triggered as there is some amount of time that occurs during the processing. Also, the content of the message generated will always be a timestamp of the yyyyMMddHHmmss.SSS format.

So I’ll have 0.8.5 uploaded in short order, but I do want to upgrade my wordpress first as it’s been buggy lately.

A user found out that due to the inclusion of the HAPI libraries with HL7 Browser 0.9.8, it doesn’t quite work on Java 1.4 at the moment. I’ve updated the JNLP (web start launcher) to reflect this, as well as the install icons on the site. This shouldn’t be a huge inconvenience to most users as many of you are no doubt on 1.5 or even 6 and those on 1.4 with internet access will download the 1.5 JRE automatically when webstart kicks in.

I’m going to investigate some for sure, but if the library requires 1.5 there’s not much I can do about it, and with heavy XML requirements and a number of dependencies I’m not too hopeful. 1.4 is also getting dated these days, so unless users really scream about it I may not investigate too thoroughly. If you’re concerned one way or the other let your opinion be known here.