Should SEND include carriage return and line feed?

[Ruth Berge]

Using mb 5.8,

does the SEND command also include a carriage return and line feed?

In the test tool, it does not appear to do this.

I have a large message breaking up into multiple smaller ones (not just a DSC).

Topic

[Levy Lazarre]

My personal experience is that there is no line feed. When a message is broken into multiples inside an Xlate, each message dispatched by “SEND” is terminated by a carriage return (which is the normal terminator for the last segment in the message).

To make this more apparent, you may want to do a route test instead of an Xlate test.

[Jim Kosloskey]

Ruth,

If you specify an output file for your Xlate tester, you can then look at the hex values therein and see exactly what is placed there.

Be aware also that in use inside the engine it is most likely your outbound protocol which will determine what surrounds each message as it is delivered.

Also, clearly understand the difference between SEND and CONTINUE.

Personally I use CONTINUE all the time unless there is a specific need to do a SEND.

SEND is to pass the message directly to the outbound thread bypassing post Xlate processing. CONTINUE indicates to move the messages on to the next step in the engine.

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

[Ruth Berge]

Thanks,  so i do not see a carriage return and line feed (0d, 0a) in the output

I also did change it to CONTINUE with the same result.  I had forgotton about the post processing.  Thanks.

I’m trying to read between the lines of what you are saying.  It appears that CONTINUE and SEND do not add the extra message delimiters.  Is there an easy way to do this?  I want to generate multiple messages from one message.  As it is, the message contents are correctly created but the delimiters between the messages are not there.

[Levy Lazarre]

Ruth,

I am not sure I understand the issue or why you would need delimiters betweeen the messages. I have Xlates that break ORM or DFT messages into multiple orders or charge messages and each one is a complete message that is sent separately to the receiving system when CONTINUE is executed.

However, if you have a need to add delimiters after each message, then an easy way would be to use CONTINUE instead of SEND and place a short post-Xlate tps that would add the carriage return / line feed at the end of the message.

Something like:

Code:

append msg “rn”
msgset $mh $msg

and CONTINUE the modified message as usual.

[Ruth Berge]

In the cases where you have this working, are you using only the xlate or are you using the tcl proc which I have seen posted here?

When I look at the help text, it certainly implies that CONTINUE will create a new message.

[Jim Kosloskey]

Ruth,

In HL/7 normally there is only a hex od after each segment and each message starts with the MSH segment.

The Xlate using CONTINUE and SEND places a hex od between each segment as expected (at least that is what I am getting).

Are you saying the receiving system is requiring a hex 0a after each message?

If so and this is not a real time exchange then you can set the file format in the protocol to New-lIne terminated and that should take care of it.

If this is a real time exchange, then you can either make your own PDL_MLP PDL and add the hex 0a there or use a Tcl proc in the post Xlate or Outbound TPS to add the hex0a.

However, if this is real time I would have a serious chat with the receiving vendor about undserstanding HL/7 (of course maybe this is a GE receiving application).

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

[Levy Lazarre]

Ruth,

I have done the message splitting in Xlates, not Tcl scripts. As mentioned by Jim, each resulting message ends with a hex 0d, which is per HL7 standard.

You cannot use the “append msg” snippet in an Xlate because the $msg variable is not available in Xlates. So you need to build a tps script with the append code. The tps can be post Xlate or OUTBOUND TPS, but if placed in outbound TPS it will apply to all the messages going through that thread, so post Xlate may be a better choice depending on your situation.

I hope this helps.

[Ruth Berge]

I looked again at the messages.  

First, I guess I was leaping in my first statement.  The issue that I see in the CCG testing tool is that even though the XLATE sorts the data into 4 messages, the testing tool labels all of them as Message 1.  I thought this was because there was no line feed after the hex 0d on the last segment.  This may not be true.  It just happens that a file I sent through with a single message does have hex0d and hex0a at the end of the message.

So I will then rephrase the question and ask what I should expect from the CCG testing tool?  If the XLATE being tested is successfully breaking out multiple messages from one, then should be output in the test tool label each message as “Message 1” “Message 2” etc.?

Then I will take the other information as very valuable as I continue (no pun intended).  And thanks for all the responses before and after this.

[Jim Kosloskey]

Ruth,

What the Tester does is identify the number of messages inbound not the number outbound. You can easily tell how many out are created by the number of MSH segments you see.

I do this a lot and I don’t have an issue with it.

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

[Author]

Replies