[Dennis Dunn]

Hi!

The signal-to-noise ratio on this forum is amazing!

I went with Ryan’s solution this time because it was so bloody easy.  Nothing like climbing over a mountain and then meeting someone who came through the tunnel.

Thanks for your help.

–dennis

[Dennis Dunn]

Hi,

That really irritates me when somebody posts to a forum asking for help but they haven’t done their research.   🙂

I figured out the problem with my second attempt, I had specified the pathname incorrectly.  Even though xpmfetch needs the tilde to indicate an output field name, xpmstore doesn’t.  Presumably because there is no other place to logically store a value except in the destination.

I’d still like to hear your comments about modifing the iteration variable.

Thanks again.

–dennis

[Dennis Dunn]

Hello,

Here is my second stab at trying to insert segments into a message.

set d [xpmfetch $xlateId {$%g1}]

set i [datget $d VALUE]

datdestroy $d

set j [expr $i + 18]

set k [expr $j + 1]

xpmstore $xlateId “~1(0).1(0).3(0).0($j).OBX(0).00569(0)” d -c $k

However, I get this error message when I test the translation

MESSAGE 1

[0:TEST] Mismatched IR Tags

Tcl callout error

erroCode: NONE

errorInfo:

error storing into “0(0).1(0).3(0).0(18).OBX(0).00569(0).[0].[0]”

   while executing

“xpmstore $xlateId “~1(0).1(0).3(0).0($j).OBX(0).00569(0)” d -c $k”

Where is the .[0].[0] coming from?  I tried specifing the complete path like this

set d [xpmfetch $xlateId {$%g1}]

set i [datget $d VALUE]

datdestroy $d

set j [expr $i + 18]

set k [expr $j + 1]

set path “~1(0).1(0).3(0).0($j).OBX(0).00569(0)”

append path {.[0]}

xpmstore $xlateId $path d -c $k

… but I still get the same error message.

MESSAGE 1

[0:TEST] Mismatched IR Tags

Tcl callout error

erroCode: NONE

errorInfo:

error storing into “0(0).1(0).3(0).0(18).OBX(0).00569(0).[0].[0]”

   while executing

“xpmstore $xlateId $path d -c $k”

Thanks again.

–dennis

[Dennis Dunn]

Thanks for the suggestion, I’ll look into the system command.  I’ve got a couple of Windows command line mailers I can try.

–dennis

[Dennis Dunn]

Hi Michael,

Thanks for the code! That seems somehow simpler than dealing with path specs and grm objects.

–dennis

[Dennis Dunn]

Hello Charlie,

>>You mention using parameters from xlateInVals, etc and at the

>>same time talk about using grmcreate.  

My library does not know about either xlateInVals or grmcreate.  It simply does the lookup based on the values of the parameters passed to the procedure.  In an xltp fragment, these values come from xlateInVals.  In a tps proc, these values would come from the message.

>>You cannot use GRM inside Xlate.

But I can use grm from the tcl shell, right?  According to the documentation I just need to make sure that I’ve done a setroot and that I call setHciDirs.

>>As for any differences between the testing tool and engine

>>when using GRM there are none.

That’s good to know.  So if the testing tool parses the message without any problems then grm should also be able to parse the message.

>>You must also look for the most maintainable method.

You make a very good point here, this is why I wanted to move my db lookup code to a package that I could use in different contexts.  

I probably shouldn’t have even mentioned db lookups or xlateInVals or any of that in my original post since they really aren’t important.  I might have been clearer if I had simply talked about my problem with grmcreate not parsing message data correctly when used from the tcl shell.

Thanks for your comments.

–dennis

[Dennis Dunn]

Hello Charlie,

>>We could make this work but question would be *WHY*?

I have some procedures in my package that perform database lookups based on values passed to the procedure.  If I use this package from within an xltp code fragment, I can pass in the parameters to my procedures via xlateInVals and get results to the translation via xlateOutVals.  To use the package from tps code, I was going to get the nessasary values from the message handle that is passed to the tps procedure in the args keyed list.  

My reading of the Cloverleaf Integration Services Reference Guide leads me to believe that the way to access the data of a message is through a grm object.  When I create a grm object from a message handle, the message data will be parsed and I can then access the field data using paths.  This does not seem to be happening.

I can think of a few reasons that the behaviour of the API and my expectations don’t mesh.

* I might not understand what the API is supposed to be doing.  This is very likely since I’ve only been using Cloverleaf for a few months.

* My original message could be malformed and grmcreate does it’s best to parse the message but ultimatly chokes.  This seems very unlikely since I can open the file that contains the message in the Cloverleaf HL7 testing tool and the testing tool parses the message just fine.  Perhaps the parser used in the testing tool is more lenient than the parser used by grmcreate and can handle malformed messages.

* Perhaps grmcreate has a bug that prevents it from parsing my message.  This seems very unlikely since Cloverleaf is a mature product and is well respected by the programming staff at the hospitals that I work with.

So, it looks like my problem is simply a lack of understanding which is why I post here.

>>HL7 is much better dealth with simply using Tcl splits, joins, etc.

I suppose I could write a little package that splits an HL7 message and gives me mechanisms to access the segments, fields and subcomponents but why bother?  Cloverleaf has already provided a really cool tcl extension that  does all of that as well as an addressing mechanism that takes into account things like multiple segments of the same type and repeating fields. However, since the ultimate goal is to get things done, I’ll look into this further.

Thanks for your help.

–dennis

[Dennis Dunn]

Hi Jim,

>It looks like you will always get the default message definitions from

That is correct, we don’t have a variant defined for these messages.

>the syntax for grmcreate is different for frl (and perhaps vrl and hrl) >than for hl7, x12, etc.

Yes, I am only dealing with HL7 messages so I don’t need to worry about the others.

>Also I know you have provided a subset of the entire proc, but I will >assume you have a grmfetch somewhere to get the actual fields.

Yes, I was getting null datums back which led me to the whole troubleshooting process.  It is as if the message is not being parsed correctly by grmcreate.  The thing that really throws me is that when I open the file using the testing tool in the IDE, the message is parsed just fine.  The proc was really so I didn’t have to type the same thing over and over and to show you the steps I went through to create my grm object.

Thanks for your help.

— dennis

[Dennis Dunn]

I am totally stoked on tcl!  After posting my request this morning for information I fired up http://www.tcl.tk and discovered that Yes! tcl can access UNC paths on Windows.  It took a couple of hours to write and test the little bit of tcl that does everything I need it to do.  Pretty much everthing was done with file and glob.

Thanks!

–dennis

{Sounds like a law firm – Phyle and Glob, LLP  :)}

[Dennis Dunn]

Hi,

Just wanted to get back to you and say thanks for all of the suggestions.  I really appreciate the help.

–dennis

[Dennis Dunn]

Thanks for your ideas, everybody.

We have multiple hospitals sending up HL7 messages, these different hospitals use different ID numbers for each provider.  Our billing system provides a canonical list of provider IDs and I need to map each of the hospital provider IDs to the canonical provider ID.  If there is no mapping from the hospital provider ID to the canonical provider ID then I need to notify operations to update a lookup table and save the message so that it can be resent once the table has been updated.

These provider IDs are sprinkled throughout the different message types in a bunch of different segments.  I need to perform the mapping on every provider ID so trying to do this in one grand filter on the thread seems like it would be hard to manage.

If I do the lookup of provider ID at the TPS Inbound Data point, can I edit the message data at that point?  If I’m looking up the provider ID anyway I might as well edit the message at the same time, the other option is to lookup the provider ID in the translation.  I guess at that point my worries are over since I would know for a fact that the value I want exists in the lookup table.

On another note, in the XLTP type of tclproc it looks like I don’t have access to the message handle of the message currently being processed by the $xlateId.  It doesn’t seem that $env exists, either.

Is this correct?  Or are there other ways to access this information?

Thanks again.

[Dennis Dunn]

Thanks everybody for your help.

Delete/recreate the site didn’t work so I removed / reinstalled the Cloverleaf software.  Everything is working now.

Dennis

[Dennis Dunn]

I tried your steps, Gary, but the result is the same.

Thanks for your help.

Dennis

[Dennis Dunn]

Thanks Gary,

I tried most of those suggestions but there were a couple that I missed.

Dennis

[Dennis Dunn]

Hi,

I’m afraid that I jumped the gun.  I did some more testing and the information in my previous post appears to be bogus.  Sorry.

I wonder how long it will take before the connection closes?

–dennis

[Author]

Replies