DashBoards

Robert,

How ‘real time’ does this reporting need to be?

If it does not need to approach real time, you can use the .idx file of the SMAT file set to gather raw counts.

If you did that for the inbound threads you would get your inbound counts.

You can even concatenate the .idx files together then count the lists inside.

Robert,

You probably want to look at utilizing some of the MSI Tcl extensions within Cloverleaf to extract this info if you need it near real-time.  We have a Tcl script that we run every 5 minutes to capture thread stats and create an .html page which can be viewed.  The script is attached.

You can extract all the various information that is available in the ‘Status’ window in NetMonitor via these extensions.

Hope this helps.

Jim Cobane

Henry Ford Health

Robert,

The .idx file contains lists of keyed lists. What you see is one list element (with the keyed list inside).

There is one list per message. If you count up the number of lists in the file you have a count of the number of messages in that SMAT session.

So each list entry does not contain a count, but rather the count of the lists in the .idx gives you the number of messages.

As Jim Cobane indicated, you can use the MSI Stats if you need to be more real time – with the caveat that you will probably need to synch your clearing of the MSI Stats to get periodic counts – again this will not be real time – unless you periodically retrieve without clearing and do a delta.

Then you will need to consider what to do about your non real time integrations.

For raw message counts, we use counting the .idx entries useful and more simple than the MSI Stats.

Assuming this is the SMAT from an ADT only inbound then that is correct.

So using a command line Tcl proc, you open the .idx file, read each list in and add one to a counter, keep repeating until end of file is reached and close the file. The counter now reflects the number of messages collected in that SMAT set.

There are some useful features available with Nagios <a href="http://www.nagios.org&#8221; class=”bbcode_url”>www.nagios.org, and its possible to send threads MSI details (we use cron) for useful info.

Robert,

The MSI data doesn’t contain ‘message specific’ information, but only statistic information related to a thread.  Essentially, the information that you see in the ‘Status’ window from NetMonitor (or if you do a ‘hcimsiutil -dd threadname’ command) is what is available via the msi extensions.

Hope that helps.

James Cobane

Henry Ford Health

The transaction ID is part of the message data and is not stored in the IDX file. You can use the message ID (ex: 29872460) in the meta data, use that to perform a lookup in the IDX file to get the offset (ex: 3731123) and length (ex: 1530) of the message data, and then open the .msg file (med_adt_in.msg), reading from the offset for length bytes to get the message data, and then parse the message data to get the transaction id.

I’d hesitate to read the Smat file from within a tclproc that is part of a message transaction which is also updating that same Smat file. There might be a timing issue and there might be a contention issue. But it could be done. It might be more efficient to have an inbound tcl proc parse incoming messages, get the transaction id and store it in a Sqlite table. I am doing something similar in a test environment – its been running for five months without a problem, for our primary inbound thread, but I can’t say its been put into production yet. See previous discussion on an audit proc.

Peter