DashBoards

[Robert Denny]

I am part of a project to create Dashboards that list the number of inbound messages sent to an inbound thread, and then also list the number of those messages killed, along with the number of successful messages sent to various outbound threads.

Does anyone know of any TCL procs that do the first step of this process?

Writing the number of inbound messages that are sent to an inbound thread, to a text file?

Topic

[Jim Kosloskey]

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.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 61 years IT – old fart.

[James Cobane]

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 Denny]

I do not understand much about the .idx file. Here is an example of the last entry of our ADT inbound .idx file for one day.

What shows the inbound adt count?

{MID {{DOMAIN 0} {HUB 0} {NUM 29872483}}}

[Jim Kosloskey]

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.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 61 years IT – old fart.

[Robert Denny]

If I understand you correctly this last segment of data that I listed, which was bracketed unto itself, within the med_adt_in.idx file, represents data for one message? In reading the .idx file within a text editor, all is see are these segments over and over again. Here is an example of the previous bracket segment in the .idx that appears just before the last segment I posted.

{

       {MID {{DOMAIN 0} {HUB 0} {NUM 29872460}}}

       {SRCMID {{DOMAIN {}} {HUB {}} {NUM {}}}}

       {TYPE DATA}

       {SOURCECONN med_adt_in}

       {ORIGSOURCECONN med_adt_in}

       {DESTCONN {{}}}

       {ORIGDESTCONN {{}}}

       {TIME 1312181737}

       {PRIORITY 5120}

       {DATAFMT {}}

       {SAVECONTEXT inbound}

       {OFFSET 3731123}

       {LENGTH 1530}

}

What I hear you saying is that this data represents meta-data for one inbound ADT message?

[Jim Kosloskey]

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.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 61 years IT – old fart.

[Richard Hart]

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 Denny]

James,

I was checking out your proc. Do you know or have any ideas of how to pull the transaction ID of a message from the database, by using a proc?

we want to be able to pull data from the database, not the HL7 message.

[Robert Denny]

Richard,

Can you clearify what specifically are MSI details? I went to that site, and looked around, but read nothing about its use with Cloverleaf.

Did I miss something or is the level of knowledge over my head?

[James Cobane]

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

[Peter Heggie]

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

Peter Heggie
PeterHeggie@crouse.org

[Robert Denny]

Thanks Peter,

I’ll check that out.

[Author]

Replies