Log ALL messsages for a particular thread

Ryan,

If you have SMAT turned on for the thread – there is your log. If you do not have it turned on, turn it on.

Now it is not easily usable as it sits by non Cloverleaf(R) folks. So if that is important, simply add a Tcl proc to extract the messages from the SMAT file to your periodic archival of SMAT scripts to a flat file and do what you want.

Maybe even use the Fileset/FTP protocol to deliver the flat file to other users?

Jim Kosloskey

I am trying to log all messages for a single thread.

No SMAT would not get those message on the outbound side.

If you have a TCL proc that kills it which it appears you do. Then you should just be able to open a file in TCL and write it out from there.

If not then I would need to better understand how you are killing the message to tell you how to log the message.

Duy,

If you have SMAT on the inbound thread you have the message as received by Cloverleaf(R). However that would be ALL messages – those KILLed and CONTINUEd.

Of course you could locate the messages KILLed by a number of mechanisms but maybe that is more than you want.

If filtering at the Route Messages, you could set one route to KILL and th other route to use the same logic but do the complement. In other words CONTINUE the messages KILLED and KILL the messages CONTINUEd in the first route. The message for the second route could go to a File protocol thread. You could either have the File protocol send to /dev/null and use the outbound SMAT; go to a real file and use the actual file; go to a real file and use outbound SMAT.

Or… you could do your own write to a file inside the filtering proc and assume all of the I/O responsibility yourself.

What I do is to have the SMAT on the inbound and make sure I have coordinated testing with the inbound system to test all of the appropriate filtering scenarios. I then use the SMAT files and whatever my filtering proc echoed to the log (I have one filtering proc and it has a debug switch so I can control when logging occurs) to prove or disprove the efficacy of the filtering process.

Once testing is done, if there is an issue regarding filtering I use the SMAT files with the documented and configured (my filter proc is argument driven so I can tell what is supposed to occur by looking at the arguments) filter knowledge determine whether the filtering is working correctly.

The inbound SMAT is the real PROOF of what you received from the vendor..

Jim Kosloskey

No SMAT would not get those message on the outbound side.

If you have a TCL proc that kills it which it appears you do. Then you should just be able to open a file in TCL and write it out from there.

If not then I would need to better understand how you are killing the message to tell you how to log the message.

Yes, we are using a TCL proc that kills the message.

Duy,

If you have SMAT on the inbound thread you have the message as received by Cloverleaf(R). However that would be ALL messages – those KILLed and CONTINUEd.

Of course you could locate the messages KILLed by a number of mechanisms but maybe that is more than you want.

If filtering at the Route Messages, you could set one route to KILL and th other route to use the same logic but do the complement. In other words CONTINUE the messages KILLED and KILL the messages CONTINUEd in the first route. The message for the second route could go to a File protocol thread. You could either have the File protocol send to /dev/null and use the outbound SMAT; go to a real file and use the actual file; go to a real file and use outbound SMAT.

Or… you could do your own write to a file inside the filtering proc and assume all of the I/O responsibility yourself.

What I do is to have the SMAT on the inbound and make sure I have coordinated testing with the inbound system to test all of the appropriate filtering scenarios. I then use the SMAT files and whatever my filtering proc echoed to the log (I have one filtering proc and it has a debug switch so I can control when logging occurs) to prove or disprove the efficacy of the filtering process.

Once testing is done, if there is an issue regarding filtering I use the SMAT files with the documented and configured (my filter proc is argument driven so I can tell what is supposed to occur by looking at the arguments) filter knowledge determine whether the filtering is working correctly.

The inbound SMAT is the real PROOF of what you received from the vendor..

Jim Kosloskey

Do you think modifying the TCL proc to write to a file or using the SMAT method would be more effective?   Which one would be easier/quicker to implement?  Thanks, Jim.

Duy,

That depends on your capabilities with Tcl.

Defining a new thread and specifying the route to the new thread (and include the complement filtering) should only take about 10 minutes I would think. If you think you can modify your filtering proc in the same time frame than it is a wash – except – you cannot reuse your filtering proc unless you build in controls for when logging happens and when it does not – that might take longer.

Let say, if I were to do this configuratiion, I would only set it up in test, I would not tend to migrate that to Production (after all if your filtering starts failing in Production, in my opinion, you did not test effectively).

If you are asking me how I would do it, I would use the inbound SMAT file and find the message(s) which is/are suspect (either KILLed or CONTINUEd in error) and use those to confront the inbound system. After all since these are the messages exactly as received from the sending system, there can be no question about whether the message had been modified in any way by something you did and the onus lies squarely on the sending system.

Jim Kosloskey

Duy,

That depends on your capabilities with Tcl.

Defining a new thread and specifying the route to the new thread (and include the complement filtering) should only take about 10 minutes I would think. If you think you can modify your filtering proc in the same time frame than it is a wash – except – you cannot reuse your filtering proc unless you build in controls for when logging happens and when it does not – that might take longer.

Let say, if I were to do this configuratiion, I would only set it up in test, I would not tend to migrate that to Production (after all if your filtering starts failing in Production, in my opinion, you did not test effectively).

If you are asking me how I would do it, I would use the inbound SMAT file and find the message(s) which is/are suspect (either KILLed or CONTINUEd in error) and use those to confront the inbound system. After all since these are the messages exactly as received from the sending system, there can be no question about whether the message had been modified in any way by something you did and the onus lies squarely on the sending system.

Jim Kosloskey

Well, Jim, if you put it that way…I will definitely have to use the SMAT method.  🙂  Thanks for everyone’s input.

Actually, Jim, what I think we’re trying to do is log the full HL7 message if it is killed.  We want to be able to write this to a file, separate from the process log.  We will be using this file to look at why the messages got killed so we can go back to the vendor and discuss.  We don’t want to log the HL7 message  if it is succesfully passed through the engine (not killed). Would this still involve using SMAT or a different method?

If I were you Duy, I would take the existing tps and when you decide to

kill then echo the message to the log and email the message to a  select group of people who care right when it happens.

No muss, no fuss.

Duy:

If you do decide on creating an extra route for messages that are killed you may find my post at the following URL of interest:

http://clovertech.infor.com/viewtopic.php?t=1562

I posted the details on how I used a trxID proc to create a route for messages that I wanted killed.

In your case you would simply not use the message kill (hcitpsmsgkill) on the route like I did so your killed message could CONTINUE to SMAT on a complement route or wherever.

Duy.

We have requirements to save ‘dodgy’ messages for investigation and use a similar method to Russ’s above.

In some cases, we have perfomed some message translation already and in these cases, we store variables in the messasge user data, so the trx code can grab these which saves a message parse.

We perform almost all of our translations in TCL and our standard is for a translation to display the following in the log file.

DEL:>message< OLD:>message< NEW:>message< Collecting deleted messages is then a Perl one liner.

You already have some tcl code that is killing the message, and you want to write that message to a file so you can examine/reprocess it. One simple way to do that is to add a few lines of code before you kill it.

At some point you have grabbed the message with something similar to:

keylget args MSGID mh

set msg [msgget $mh]

Later in the proc you are probably killing the message with:

lappend dispList “KILL $mh”

Just prior to the kill add three lines of code so it looks like:

set out [open BadMessageFilename a]

lappend dispList “KILL $mh”

The BadMessageFilename file will be in the process’s directory and will contain the killed messages in a newline-delimited format.

Chris

Thanks for everyone’s input.  I’m always interested in learning different methods.  Have a great Labor Day weekend!