Tracking the message flow

[Andreas Lieb]

Improvements in the control of the message flow would be nice:

1. If you want to check what happened to a specific message in a productive environment, you first check the IB SMAT file (if you have one), then take a look in the OB SMAT file and try to identify the resulting / translated message, but you have no ‘discrepancy list’. What about a tool showing the message in the different transformation states (a kind of message-related list) to be able to track what hapened to a certain message in one view?

2. Graphical debugger for translations, so you see the filling of the OB fields and the results of the actions taken in a translation?

3. Tool for catching (certain) messages in the message flow (e.g. when calling the TPS interface) to inspect the contents / metadata of these messages – might be a good tool to get an environment to life as you can e.g. catch ADT^A18 messages as these always seem to cause a problem on the receiving system …

Topic

[Anonymous]

I can see how this could be a great help when recovering from a crash if the database is corrupt and needs to be initializated.

If the inbound messages have a unique ID that is keept through the flow, we can figure out what was sent and what was in the queue when the chrash happened. Right now, we rely on the control ID of the message or some other value but it is not the same in all the interfaces. This should be kept in the metadata…. We could even automate the rebuild of the database!

[Jim Kosloskey]

Doesn’t the METADATA already contain the message ID? I think there may even be one that is assigned when the message first enters the Engine that stays with the message until it leaves the engine.

However, I think the METADATA only exists as long as the message is actually in the engine.

There is a SRCMID key in the SMAT .idx file but I don’t ever recall seeing it populated.

I think the Recovery DB does exactly what you want — unless you have a complete system crash such that the Recover DB gets completely corrupted but I am not sure what could be done to protect against that. It probably should not be occurring in the first place.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Richard Hart]

We have simple code that logs the HL7 message control id and thread name to a date stamped file with the same name as the thread.

eg file eds_prod_rp_adt_out_20050923.log

contains eds_prod_rp_adt_out PJ@RP0913410875 …

We perform almost all of our translations in TCL code and display the message in its pre and post translation state.

This could also be performed before and after the normal Xlate

[Mark Thompson]

Running version 5.3, the SMAT .idx file contains the CL message ID’s for the final and original messages.

       {MID {{DOMAIN 0} {HUB 0} {NUM 1327014}}}

       {SRCMID {{DOMAIN 0} {HUB 0} {NUM 1326961}}}

These must be combined (e.g. 0.0.1326961) to produce the format displayed in process logs, etc.

- Mark Thompson
HealthPartners

[Author]

Replies