Pass Through Thread Idea

Homepage Clovertech Forums Read Only Archives Cloverleaf Cloverleaf Pass Through Thread Idea

  • Creator
    Topic
  • #49784
    Michael Lacriola
    Participant

    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?

Viewing 13 reply threads
  • Author
    Replies
    • #63582
      David Barr
      Participant

      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.

    • #63583
      Tom Rioux
      Participant

      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

    • #63584
      Vince Angulo
      Participant

      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.

    • #63585
      Tom Rioux
      Participant

      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….   😀

    • #63586
      Robert Kersemakers
      Participant

      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

    • #63587
      Richard Hart
      Participant

      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.

    • #63588
      Ian Morris
      Participant

      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]

    • #63589
      Robert Kersemakers
      Participant

      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

    • #63590
      David Barr
      Participant

      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.

    • #63591
      Ian Morris
      Participant

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

    • #63592
      Ian Morris
      Participant

      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!  😯

    • #63593
      Ian Morris
      Participant

      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.

      👿

    • #63594
      Keith McLeod
      Participant

      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.

    • #63595
      Ian Morris
      Participant

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

Viewing 13 reply threads
  • The forum ‘Cloverleaf’ is closed to new topics and replies.

Forum Statistics

Registered Users
4,965
Forums
28
Topics
9,104
Replies
33,616
Topic Tags
248