Logging with Message Broker

Message Broker has several logging options all of which are valuable in different circumstances. First of all there is the new kid on the block: record and replay. This feature is designed to capture messages as they flow through Message Broker and store them in a database. Key fields can be selected and pulled out for searching and filtering. The Message Broker web application provides a nice easy to use UI for accessing the stored messages and replaying them if required. This is the ideal tool for auditing and long term storage.

Activity log is another very useful facility. It provides a high level view of key activities as they occur in Message Broker (file opened, message written, database updated etc). The key with activity log is that it is left on all the time. It consumes very little overhead and ensures there is always some diagnostics information available.

User trace is text based and a much lower level view of what Message Broker is up to as it processes your messages. User trace supports several levels of verbosity. There is a trace node provided in Message Broker which adds your information to the Message Broker trace. Trace can be controlled with the mqsichangetrace command and siblings (or equally through the Message Broker Java API and Message Broker Explorer). There is also service trace but that is really only intended for IBM to diagnose product issues.

So there is something of a gap for a more flexible way to log output from message flows. With that in mind I've knocked up a logging node which you can use to instrument your message flows. The node is configurable and outputs its messages through the most excellent Log4J logging framework.

You can read about what the node does in this PDF. The node works on Message Broker v8 Fix Pack 2 and later releases. Essentially the node writes messages to Log4J. The messages can contain anything including pieces of the actual message body being processing (for example, from an HL7 message). The output messages are collected into files according to their message flow, execution group and broker. You can switch logging on or off at any level at any time using a simple configuration file which is automatically reloaded. The node itself packaged as a JAR file here along with the source code here.

Healthcare Analytics with Message Broker

One feature I would like to call out in the new version of the Healthcare Connectivity Pack is our healthcare analytics capability. This feature makes it incredibly easy to find, search and extract meaningful data from a range of healthcare data sources (HL7 v2, DICOM and CDA). The tooling can do this because it understands these healthcare formats, not just at a syntactic level but the semantics as well. This knowledge of a standard is encapsulated in what we call a Data Analysis Profile (DAP).

For example, in the case of clinical documents, the CDA DAP understands the HL7 v3 RIM and structural attributes (such as templateID and root). With this understanding the tooling can pick apart clinical documents and show you the meaning of different sections (medications, procedures etc). This is just the tip of the iceberg, the tooling makes it a breeze to do really complex work with clinical documents.

Another example are HL7 v2 observation results, the HL7 DAP understands where the coding system is stored in the OBX segment. Armed with this information the tooling deciphers LOINC codes to present user friendly display names when you are working with your data. In fact you can plug in your own bespoke coding systems as well (a common requirement in providers).

Understanding and working with these healthcare standards is one big step forward, but the tooling goes way further. The tooling builds for you the Message Broker solution to validate inbound messages and extract the data you want. The data can be extracted into a simpler XML message format. This is the ideal approach if you want to send some extract of the healthcare data to a downstream application. Alternatively, the tooling can extract the data directly into database tables. In fact, the tooling will even design you the database table layout, key selection and everything else!

If you are interested to learn more, take a look through these slides I have posted.

Medical Imaging (DICOM) with Message Broker

One of the key things we focus on with the Healthcare Connectivity Pack is to have a single healthcare ESB which can work with a wide range of protocols, standards, transports and formats. This focus is becoming ever more important as healthcare organisations seek to join up more sources of data whether they be clinical, financial or anything else for that matter.

In many healthcare organisations I talk to DICOM has traditionally been kept separate from the main line integration of clinical applications (often using HL7). This legacy is quickly disappearing though accelerated by many factors not least of which is work being done by IHE (for example, the scheduled workflow profile which requires integration between HL7 and DICOM modalities).

The latest version of the Healthcare Connectivity Pack includes support for medical imaging (DICOM). This enables a wide range of high value use cases. The diagram below shows an example walk through of how the Healthcare Connectivity Pack can route DICOM instances to external experts for a second opinion. This scenario comes in various flavours. For example, perhaps you have several radiologists and you want to work load balance between them. Alternatively, radiologists with specialist skills might be geographically dispersed and so DICOM images can be routed to the correct location.

Another use case is to pre-fetch DICOM instances when a patient is admitted to a hospital:

This scenario uses the Healthcare Connectivity Pack to pull down DICOM images to the local PACS so that the right information is in the right place for a patient's effective treatment. These scenarios uses a range of DICOM capabilities including C-FIND, C-STORE and C-MOVE.

I've posted some slides here which walk through all the technical details of the DICOM integration.

Healthcare Integration with Message Broker

We have just released our latest and greatest healthcare integration product, the Message Broker Healthcare Connectivity Pack. In the last three years we have made huge steps forward in the healthcare integration space, indeed we have had four product releases in the last two years alone.

This new release comes packed with a host of new features:

• DICOM, the digital medical imaging standard, is now natively supported. It enables the integration of image archive systems (PACS) and imaging applications and also enables a broad range of high-value integration use cases such as  pre-fetch on admission.

• Analytics, the ability to glean clinical insight, is now made easy with integrated tooling that quickly and easily extracts meaningful information from a range of medical sources. These sources include clinical documents (C-CDA/CDA/CCD/HITSP), DICOM images, and HL7 v2 messages. Meaningful data from these sources can be filtered, captured and fed directly into downstream applications and data warehouses for healthcare intelligence applications. 

• HL7 data models that use the industry standard Data Format Description Language (DFDL), are included in support of the HL7 messaging standard. HL7 v2.3 through to the most recently approved HL7 v2.7 are provided in the pack. The graphical modeling tools bring a modern feel to HL7 data processing, provide excellent performance characteristics, and allow healthcare integrators to customize and develop healthcare integrations quickly and easily. 

• The ability to send IHE compatible Audit Trail and Node Authentication (ATNA) messages to an audit repository enables logging events across a healthcare network.

The new capabilities augment the existing capabilities of the Healthcare Connectivity Pack:

• Ready-to-use connectivity and time saving patterns for healthcare providers who seek to integrate clinical applications based on HL7 v2.x.

• Direct connectivity to bedside medical devices that includes patient monitors, infusion pumps, and more (the full list of medical devices is here).

• Pattern-based healthcare focused development tooling - rapid integration without detailed knowledge of integration engines or enterprise service bus (ESB) technologies.

• Healthcare-oriented, operational monitoring for connected clinical applications and devices.

I've posted some slides here which walk through the high level features now available.

Message Broker Goes Mobile!

Message Broker v8 FP1 shipped just a few weeks ago. One of the many new features in this release is close integration with mobile applications. The background to this work is an acquisition we made at the start of the year with Worklight. IBM Worklight is a mobile application development product that enables you to quickly and easily develop mobile applications for many devices (iOS, Android, Windows Phone, RIM Blackberry and more). Furthermore, mobile applications are written using well established web development skills (HTML, CSS and JavaScript).

Message Broker now has a host of patterns that address key integration challenges in the mobile space:

Mobile enablement for Microsoft .NET applications

In just a few easy clicks, convert any Microsoft .NET class (C#, VB.NET, F#) into a web service running in Message Broker. The pattern generates the integration logic for Worklight and a complete mobile application that can exercise the .NET service. 

Mobile service enablement

Take any Message Broker web service and mobile enable it. The pattern adds an HTTP/JSON binding to the service so that mobile applications through Worklight can integrate with back-end systems. The pattern also does a really great job of documenting (in HTML) the JSON format that the mobile developer should send to Worklight.

Push notifications to mobile devices

There are a whole host of use cases where pushing data out to mobile devices is incredibly useful. For example, perhaps you might want to send a meeting reminder to a client. This pattern creates all the integration logic for pushing notifications out to users on their mobile devices. The notifications themselves are sent out through Worklight using vendor specific push notification servers (for example, Apple APNS and Google C2DM).

Resource handler

This pattern brings a fresh look at the world of CRUD (Create, Read, Update and Delete). The pattern builds a Message Broker application that supports the CRUD operations as well as adding caching and security to complete the picture. Caching uses the WebSphere Extreme Scale (WXS) cache now available in Message Broker. Security supports authorisation and authentication against an LDAP server (such as Microsoft ActiveDirectory).

The source code for all these patterns is available so you are free to take these patterns and extend them in any way that makes sense to you!

More information on all these patterns is available here on my SlideShare account. If you are new to Message Broker, you might find the following introduction slides helpful. And finally, if you are looking for some guidance on how to build integrations with Message Broker, these slides provide lots of information.

Pattern Communities

Message Broker patterns are all about creating production ready connectivity solutions. The value of a pattern multiples hugely the more it is shared, and consequently the more it is used. In Message Broker fix pack 2 we added a significant capability to enable pattern communities. You can see some slides that walk through some of this work here.

Now it is worth saying that a community means different things to different people. For some organisations, a community might be private where patterns are created and shared within a development team. In this scenario, patterns offer consistency and time-to-value.

For other organisations, patterns are a way to deliver capability to the market in an easily consumable form. For example, you might want to develop a suite of patterns for a particular industry or technology area.

With this in mind you might be interested in a new global pattern community - mqseries.net has added a pattern community where you can find, download and share patterns. We will be putting some very cool example patterns up over the next few weeks to help get it started. Why mqseries.net? Well communities are all about people, and mqseries.net is where the Broker community go to find answers.

One particular thought to leave you with. We are very motivated to make your business succeed. So you might consider uploading a free starter version of your pattern to mqseries.net. In your pattern you can very easily include your own branding and links to your web site where the professional and enterprise versions can be purchased.

Pattern Authoring in Message Broker

Almost a year to the day, Message Broker v7 was released. Well it has been a busy year in the development team. One area I particularly wanted to highlight was the work the team has done around patterns.

Broker v7 introduced the first generation of patterns technology to the connectivity world. The v7 release shipped with an extensive set of built-in connectivity patterns. For example putting a web service front end on an existing application is a problem that comes up again and again in the field. Adding a production-ready pattern to the product made perfect sense.

Back in July we shipped Broker fix pack 1. Along with many new features, pattern authoring made its debut. Pattern authoring allows anyone to design, test, debug, package and distribute their own patterns. The patterns are presented in the Pattern Explorer alongside the built-in patterns provided by the product.

This capability has proved to be a big hit with our customers. We have talked to many customers this year who are now using patterns to simplify their development process, get more consistent solutions and to reduce costs.

Yesterday, Broker fix pack 2 was released. Fix packs are the way we release new functionality between our biennial major product releases. In fix pack 2 we have released the third generation of patterns technology. This includes major enhancements to pattern authoring. You can read about the pattern authoring capabilities in this slide show.

Pattern authors can now plug in their own Java and PHP code to their patterns which is called whenever pattern instances are created. Included in this is a major new Java API to programmatically manipulate message flows. You can browse the infocenter here and the new Java and PHP additions are documented here.

A couple of other links to mention. First there is an introductory article on developerWorks for pattern authoring. We also have a web site called the IBM Education Assistant, here you will find lots of short videos showing you how to use many of the features in the product.