Disposition OVER, SEND, CONTINUE…

This topic has 10 replies, 7 voices, and was last updated 15 years, 8 months ago by Tom Rioux.

Creator

Topic
April 9, 2009 at 6:47 pm #50790
Tom Rioux
Participant
I have multiple inbound threads sending to one outbound thread. I have 3 procs in my outbound TPS stack of the outbound thread. I’m adding a new inbound thread that needs to go to the same port on the outbound thread but I don’t want it to go through the outbound TPS stack. Is there a way to do this? Every way I have tried either errors out or just loops through the engine without ever getting sent out.

Thanks…Tom
Creator

Topic

Viewing 9 reply threads

Author

Replies
- April 9, 2009 at 6:57 pm #67528
  Max Drown (Infor)
  Keymaster
  Could you put a filter in your procs maybe? Or move the procs to xlate post procs?
  
  -- Max Drown (Infor)
- April 9, 2009 at 7:39 pm #67529
  Tom Rioux
  Participant
  That is a possibility. However, the different inbound threads each represent a separate facility. I was hoping I could put something in place for this new thread that would cause me having to get the other facilities involved in the testing or having to manipulate the other procs. I thought maybe there was some sort of global I could set in a new proc that would cause it to skip all the others.
  
  Thanks for the suggestion Max. I will take that in to consideration.
  
  Tom
- April 9, 2009 at 7:43 pm #67530
  Sergey Sevastyanov
  Participant
  Maybe you can set up a new pair of threads – let’s call them NewIn and NewOut.
  
  Route everything from NewIn to NewOut as raw details. Configure NewOut similar to current outbound thread but without TPS Out procedures.
  
  Reconfigure current outbound to send to NewIn via local port, and NewIn to receive from that local port.
  
  Then you can route messages from your 4th inbound thread directly to NewOut thread.
  
  Does it make sense?
- April 10, 2009 at 2:03 pm #67531
  Mike Grieger
  Participant
  One possible thing… probably not quite what you wanted, but maybe better than having to modify the existing procs if you keep your existing structure…
  
  If there is a way to identify the messages from your new thread from the others, you could write a new proc – to be placed first on the OB stack – that does a PROTO disp for those specific msgs and a CONTINUE for the rest. I believe that would cause your identified messages to jump right to the protocol, effectively by-passing the rest of the tps stack.
  
  I don’t think I like this suggestion, but I guess it may be a possibility?
- April 10, 2009 at 2:52 pm #67532
  Tom Rioux
  Participant
  Thanks for all the replies guys but I solved the problem. I thought the problem was because the new messages coming from the new thread, while they are HL7, were a different structure. I thought that this was the reason the message was failing during the outbound TPS stack. After further research, I found that it was failing in one of the procs. This proc was written by a former worker here at Baylor who is no longer worker. The code had a bug in it that I had to correct. Once I corrected the bug then the message went through perfectly.
  
  However, it does seem like there could be something like this can be done. It would be nice not to have the message go through the whole TPS stack if it didn’t have to. In this case, the new messages don’t have to go through those other procs but at the same time, it won’t affect the message if it does.
  
  Thanks for all the input.
  
  Tom Rioux
- April 10, 2009 at 4:27 pm #67533
  James Cobane
  Participant
  Thomas,
  
  By setting the disposition of a message to SEND, this puts the message directly onto the outbound data queue (state 11), skipping any outbound TPS processing.
- April 10, 2009 at 5:36 pm #67534
  Tom Rioux
  Participant
  Jim,
  
  I created a proc and placed it in the top of the outbound TPS stack. I gave the disposition of either CONTINUE or SEND, based on certain criteria. With the disposition of SEND, it kept looping through the engine and would never get past the outbound TPS stack.
  
  As I said, I’ve not used the SEND or OVER or PROTO at all. I’ve never had a need to up to this point….so I’m definitely no expert on it.
  
  Thanks…Tom
- April 10, 2009 at 6:10 pm #67535
  Jim Kosloskey
  Participant
  Here is my .02…
  
  I only put procs in the Outbound TPS that I KNOW I want to affect EVERY message going out that thread.
  
  So I won’t put procs in the Outbound TPS that modify the message or do actions based on specific content for a message – for example.
  
  For those things if I cannot do them in an Xlate, I do them in the post_xlate or pre_xlate.
  
  Doing things this way I might have the same proc defined in multiple routes but I can control what happens to each discreet message.
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- April 10, 2009 at 10:56 pm #67536
  Charlie Bursell
  Participant
  If you use SEND you ^MUST* set the SKIPXLATE flag to 1 or it will not work
- April 13, 2009 at 1:13 pm #67537
  Tom Rioux
  Participant
  I feel the same way Jim but unfortunately, that was not an option here.
Author

Replies

Viewing 9 reply threads

The forum ‘Cloverleaf’ is closed to new topics and replies.