Disposition OVER, SEND, CONTINUE…

[Tom Rioux]

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

Topic

[Max Drown (Infor)]

Could you put a filter in your procs maybe? Or move the procs to xlate post procs?

-- Max Drown (Infor)

[Tom Rioux]

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

[Sergey Sevastyanov]

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?

[Mike Grieger]

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?

[Tom Rioux]

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

[James Cobane]

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.

[Tom Rioux]

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

[Jim Kosloskey]

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.

[Charlie Bursell]

If you use SEND you ^MUST* set the SKIPXLATE flag to 1 or it will not work

[Tom Rioux]

I feel the same way Jim but unfortunately, that was not an option here.

[Author]

Replies