Inbound Replies not receiving reply messages

[Stephen Bull]

Hi,

I’m setting up a couple of new threads in our engine, both of which require acknowledgment messages for each outbound message.

Within Thread Configuration and the Outbound tab, I have selected Await Replies for the Inbound Replies section. Timeout is set to 900 (i.e. 15 mins), I have a Tcl TPS proc for Reply ‘generation’, a Tcl TPS for TPS Inbound Reply (for reply message processing) and the Trx id determination Format is Health Level Seven (hl7) version 2.3, with a custom variant ACK message requiring just an MSH and an MSA segment.

The sending facility is sending reply messages for every message they receive from our engine, but we don’t appear to be receiving the replies (and thus pending all other messages on our end). We already have dozens of other threads within our engine that work just fine with reply messages. These have been around for some time and were setup by the previous employee here. I have mimicked their setup and triple-checked the configs for correctness. The Tcl TPS code used for handling replies etc. are pre-existing global code-sets that are in use and working with all other threads. I even added a small Tcl TPS that outputs the reply message in its raw form to a log file before processing with any other TPS. This works OK with other threads (as soon as a reply is received I see it in our log files), but for my two new threads I don’t see anything. This is why I’m thinking I’m just not receiving the reply messages, but the two systems that are replying to me know for sure the reply messages are going out.

I also created a Java server socket for receiving messages from our engine and replying to them. I am now seeing firsthand with my socket code that a message is received OK, and a reply message is sent, but our engine just doesn’t seem to receive it. (I also created a Java client socket which does receive the reply from my server socket OK, so I know that is working.)

I’m tearing my hair out!! Any help is greatly appreciated!

We are running QDX5.3 on Windows Server 2003.

Thanks!

Topic

[Tom Rioux]

On your outbound thread, try turning on your Inbound SMAT to catch the replies.  They should hit the SMAT file first (I think) if you are actually getting them.  Maybe you are getting them but aren’t processing them correctly.  It could be the replies are not formatted properly from the recieiving system.  Also, check your error database for any possible messages there for this thread.

Hope this helps…

Tom

[Jim Kosloskey]

Stepehn,

If you have not already done this, try turning the Engine ‘noise’ level up all the way so you can track what is happenning.

That combined with SMAT as Tom sugggested should give you all the information you need to prove you are or are not receiving replies and how good they are.

It is possible, the other side is seeing a reply being generated but do not have the tools to determine if it actually went out the socket.

Also make sure they are sending their reply on the same port they are receiving the message.

Next step might be to do IP traces on both sides.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Rob Abbott]

Make sure the reply is framed in MLP ([0x0b][data][0x1c][0x0d])

Otherwise, it’s not considered a message and you won’t see the reply hit the engine.

Your Java code should see the framing as well as turning up EO will show this as well.

Rob Abbott
Cloverleaf Emeritus

[Gary Atkinson]

I am experiencing not receiving acks correctly encapsulated on one of implementations.  The messages show up nicely in hex with enable_all turned on.  It took some time to pin point this as problem.

[Stephen Bull]

Rob Abbott wrote:

Make sure the reply is framed in MLP ([0x0b][data][0x1c][0x0d])

Otherwise, it’s not considered a message and you won’t see the reply hit the engine.

Your Java code should see the framing as well as turning up EO will show this as well.

This resolved my issue! I did not know about the MLP wrapping, but I’ve added these characters around my ACK messages and they are now being accepted by the engine.

Thanks so much to all of you for your help and quick responses! There is a lot of good information here for future reference too!

Cheers,

Stephen

[Stephen Bull]

Jim Kosloskey wrote:

Stepehn,

If you have not already done this, try turning the Engine ‘noise’ level up all the way so you can track what is happenning.

That combined with SMAT as Tom sugggested should give you all the information you need to prove you are or are not receiving replies and how good they are.

It is possible, the other side is seeing a reply being generated but do not have the tools to determine if it actually went out the socket.

Also make sure they are sending their reply on the same port they are receiving the message.

Next step might be to do IP traces on both sides.

Just out of curiosity (I fixed my issue; added MLP wrapping to the msgs), how do I turn the Engine ‘noise’ level up? And is this what outputs to the log file for each interface?

Thanks for your help!

Cheers,

Stephen

[Stephen Bull]

Thomas Rioux wrote:

On your outbound thread, try turning on your Inbound SMAT to catch the replies.

[Gary Atkinson]

You can turn this on from the network monitor,  It’s under Full.

[Stephen Bull]

Gary Atkinson wrote:

You can turn this on from the network monitor,

[Author]

Replies