Pass Through Thread Idea

[Michael Lacriola]

I’ve not done this type of setup before, so here’s the question: I want thread 1 to send data to thread 2 then thread 2 would send to threads 3, 4, and 5.

The routing between 1 and 2 would be strictly raw. I’m leaving out some additional routing information to keep example simple. All threads are considered in same engine process.

Anyone done this before?

Topic

[David Barr]

Yes.  I think the way that is typically done is to make thread 1 an outbound TCP/IP thread which connects to thread 2, an inbound TCP/IP thread.  They would both use “localhost” for the host name.

[Tom Rioux]

I’m curious….why would you want to set up an interface in this manner?  What are you attempting to achieve with this set up?  

🙄 Tom

[Vince Angulo]

Yes, we typically do this – but only in the case of one IB to many OB interfaces.  Except we have the IB thread in one process and each pair of PASS/OB threads in a separate processes.

Why?  This goes back to a problem we had when we were on ver 3.7.1.  When we had a problem with a single route in a one-to-many interface, Cloverleaf would stop sending to all the OB routes.  We learned of using the PASS/OB idea at the user group conference as a workaround so that the IB would still send to other PASS/OB processes while we worked on the problem process.

It might no longer be an issue with newer versions (we’re on 5.4), but it became our SOP.  We don’t do this with one-to-one or many-to-one interfaces.

[Tom Rioux]

We have a setup similar to what Vince describes with the use of different processes.  I’ve never seen it done in the way that Michael is describing, with everything in one process.  I’ve been on 5.2 for a while now and have never seen an incident in which Vince describes.

Six of one…half dozen of another I guess….   😀

[Robert Kersemakers]

We used to do this all the time: from thread 1 the messages were translated into a ‘known’ HL7 variant into thread 2. And from thread 2 these HL7 messages were further translated into different formats for the different target-systems (threads 3, 4 and 5). And all this in one process.

You need to OVER the message in thread 2. Include a tcl-proc in the TPS outbound in thread 2, that contains the following code:

Code:

           # Create a new message without any metadata (don’t use msgcopy!)
           set overmh [msgcreate -meta {USERECOVERDB true} [msgget $mh]]
           lappend dispList “OVER $overmh”

This way a copy of the message is created, which is inbound into thread 2. Now you can route/translate this message to threads 3, 4 and 5.

You also need to decide whether you want to CONTINUE or KILL the original message in thread 2.

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Richard Hart]

We do a similar thing, where we have one Cloverleaf site/process connected to one application (send, receive or both).

A message is received and is then sent to all interested applications (separate Cloverleaf sites).  In general, the translation is performed on the inbound application thread.

With this setup, a Cloverleaf process issue/maintenance only affects one application.

We did not go down the path of an HL7 superset as almost all of our translations are TCL based.

[Ian Morris]

Just wanted to say that this post made my day.  I was able to create a pass-through thread using your snippet, which is what I’ve been working on all afternoon.  Thanks so much.

Robert Kersemakers wrote:

We used to do this all the time: from thread 1 the messages were translated into a ‘known’ HL7 variant into thread 2. And from thread 2 these HL7 messages were further translated into different formats for the different target-systems (threads 3, 4 and 5). And all this in one process.

You need to OVER the message in thread 2. Include a tcl-proc in the TPS outbound in thread 2, that contains the following code:
[code]

[Robert Kersemakers]

Glad it was of use.

I’m not taking any credits though: the proc gc_transformOutboundToInbound has been there for ages and I’m only using it. I couldn’t have come up with that myself.

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[David Barr]

We’re doing something similar:

Code:

           msgmetaset $mh SOURCECONN $HciConnName
           lappend dispList “OVER $mh”

We don’t create a new message based on the original, we use the original.

[Ian Morris]

I just realized that my recovery database is getting cluttered with these messages that I am OVER-ing.  They are ending up in a state 10 even though they are getting to their destination.  I can’t say I’m completely suprised by this because my notes from training do say “Over -> Puts message in state 10”.

Is there a way to have the “Pass Through” messages just pass through without ending up in a state 10 in the recovery DB?  I know they are ultimately getting to their destination.  I suppose I could remove the USERECOVERDB option from my OVER command, but I don’t know if that’s a good idea.

Here’s my current OVER command:

set overmh [msgcreate -meta {USERECOVERDB true} [msgget $mh]]

[Ian Morris]

As a matter of fact, I just realized something else.

Every time I restart this pass through thread, all of the STATE 10 messages in the recovery database get resent!!!

!HELP!  😯

[Ian Morris]

Seems like no matter which do-not-use-recovery-database options I choose on the thread or the proc the messages go to a state 10?  Any way around this?

I considered clearing the recovery database on thread startup but I can’t get that going either.

👿

[Keith McLeod]

I think you are creating a second copy with your statement where you use msgcreate.  You then have a disposition for the one you created, but what about the original.  You will need to address the original $mh with a disposition also….  KILL $mh OVER $overmh

Hope this helps.

[Ian Morris]

That’s exactly what I needed to do.  Thank you!

[Author]

Replies