TCP MLP end of message string

[Jerry Jermain]

We have an outbound HL7 interface configured to use the mlp_tcp.pdl routine for transmitting the message in which each message is bound by a “0b” start character and “1c 0d” stop string.  I have been informed the receiving interaface is expecting a start character of “0b” but their end of message is “0d 1c 0d”.  Is it possible to somehow modify the mlp_tcp.pdl routine to include the extra “0d” in the stop string?  If so, would it be a matter of copying it from the “pdls” folder withinin integrator to the “pdls” folder within the specific site, renaming the file to have a unique name and then modifying it to include the extra ; entry?   Here is the content of the mlp_tcp.pdl routine and what would the actual change need to look like?  Thank you for your assistance!

define phrase basic-msg;

   ;

   field data = variable-array( not( ) );

   ; ;

end phrase;

/**********************************************************************

* End of declarative section, TCL management functions start here.   *

**********************************************************************/

#{#

# This can be handled completely using the “basic” style.

hci_pd_msg_style basic phrase:basic-msg

field:data

resync:\xb

#}#

Topic

[Rob Lindsey]

One way to not change the PDL would be to just be sure that there is always a at the end of the data message.  Then the receiving system should like it.

[Jerry Jermain]

Hi Rob,

That was sort of an initial thought I had, but didnt’ really know how to add a just to the end of the message.  I am still somewhat of a newbie on certain areas within Cloverleaf and would appreciate any recommendations you may have.  Thanks for the quick response!

[Jerry Jermain]

I was able to resolve the issue based upon Rob’s suggestion.  I finally realized that we had a TCL proc manipulating the HL7 message after it was translated and I just added a to the end of the message just prior to it being returned.  I got hung up on thinking it needed to be done in the pdl routine and lost sight of other available options.  Rob, thanks again for pointing me to the easiest way to resolve the issue.

[Max Drown (Infor)]

The 0d they are expecting is actually the standard HL7 segment delimiter. This is often dropped from the last segment in the message either by the sending application or by a tps proc that’s not written “correctly”. The receiving application should just be checking for the ending 1c0d. But, since they aren’t, you can write a tps proc and place it in the Outboud TPS that checks to make sure there is a 0d (r in tcl) at the end of the message, and if not, adds one.

-- Max Drown (Infor)

[Author]

Replies