Messages ‘clumping’ together

Carole,

I assuming HL/7 messages.

Does your Receiving System send an HL/7 Acknowledgment for each message?

Do you have Clovereaf(R) configured to Await Replies for the Receiving System thread?

Do you have acknowledgment handling implemented (Recover33 procs)?

Have you turned up the Engine ‘Noise’ level (EO Config) so that you can see in the log what Cloverleaf(R) is sending (and maybe what is coming back)?

Give us as much detail as you can.

Jim Kosloskey

Is this a new system/new vendor? We had a problem with similar symptons on a feed from a new vendor. They were placing multiple HL7 messages within a single MLP envelope. Instead of sending

x0b HL7message x1c x0d

they were sending

x0b HL7message HL7message HL7message HL7message x1c x0d

Cloverleaf kept reporting segments out of sequence. You would have to turn up the Engine Output to see the individual bytes coming in.

Carole.

We had a similar issue with a new vendor sending imaging (text) results.  We didn’t receive a full explanation, but it appeared to be an issue between the applications message ‘generator’ and message ‘communicator’.  The ‘fix’ was to add a further segment terminator.

We now have no issue, BUT all message end with two ^M (x0d) rather than one!

I’ve also seen something like this, only with a little different scenario.  I’ve seen the engine clump messages together whenever a vendor inadvertently sends some sort of control character in a free text field within the message.  This usually happens due to some sort of user error.  Usually when the message with the control character is run through the tester, you can notice it right away because it shows up as an abnormal character within the message, usually something like a small triangle or small box.

Hope this helps….

Tom Rioux

Go to the particular thread, select EO Config and then select enable_all. This will put more information than you ever wanted to know into the log file for that process. Be warned that your log file will increase rapidly until you select disable_all.

Part of what you will see in the log is a hex dump of the messages and replies. You will see all characters, including the non-printable ones, that are in the messages as well as the MLP envelope characters.

Carole,

With the EO up sufficiently to see the PDL display of the message you should be able to detect if there is something other than normal ASCII characters or x0D in the segment in question.

The ASCII side of the display in the engine log will get you to the offending OBX, then if you see a . in the ASCII display before the end of the segment that is an indication of a non displayable hex set. Look at the corresponding location in the hex portion of the message display and see what the value is.

I would then look at the PDL display of the sending system message in the process log and see if the same character exists there (meaning it is coming from the sending system).

If there is an offending character and it is in the inbound message, then you have 2 choices.

1. Get the sending system to send ‘clean’ messages. That is not always easy to do.

2. Use a Tcl proc to try and surgically remove the offending character. I would tend to think of doing this on the Inbound Data Tps.

Be aware if this is coming from the sending system, then it islikely there could be other non-display characters coming from the sending system – since I doubt they are ‘cleaning’ anything. So your Tcl solution should take into account all of the potential offending patterns.Otherwise, you will have this one fixed and suddenly later on another will appear.

By the way, if the sending system still wants the offending characters to exist there is a mechanism defined within the HL/7 standard to accomplish that.

It is unlikely the vendor will know that mechanism exists much less understand it or be willing to deploy it.

Good luck,

Jim Kosloskey

From your last post, it almost sounds as if the recieving systems has a limitation on the size of the inbound messages.   It may be that the message is too large for the recieving system and you may have to split it into multiple messages.  I’ve seen this before and have built interfaces to handle this.

Thanks….

Tom Rioux